PostgreSQL-säkerhetskopieringsmetodfunktioner i AWS S3

Amazon släppte S3 i början av 2006 och det första verktyget som gjorde det möjligt för PostgreSQL-backupskript att ladda upp data i molnet – s3cmd – föddes bara ett år senare. Senast 2010 (enligt mina Google-sökkunskaper) Öppna BI-bloggar om det. Det är då säkert att säga att några av PostgreSQL DBA:erna har säkerhetskopierat data till AWS S3 så länge som 9 år. Men hur? Och vad har förändrats under den tiden? Även om s3cmd fortfarande refereras av vissa i sammanhanget med kända PostgreSQL-säkerhetskopieringsverktyg, har metoderna sett förändringar som möjliggör bättre integration med antingen filsystemet eller PostgreSQL inbyggda säkerhetskopieringsalternativ för att uppnå de önskade återställningsmålen RTO och RPO.

Varför Amazon S3

Som påpekats i hela Amazon S3-dokumentationen (S3 FAQs är en mycket bra utgångspunkt) är fördelarna med att använda S3-tjänsten:

99,999999999 (elva nior) hållbarhet
obegränsad datalagring
låga kostnader (ännu lägre i kombination med BitTorrent)
inkommande nätverkstrafik gratis
endast utgående nätverkstrafik är fakturerbar

AWS S3 CLI Gotchas

AWS S3 CLI-verktygslådan innehåller alla verktyg som behövs för att överföra data in och ut ur S3-lagringen, så varför inte använda dessa verktyg? Svaret ligger i Amazon S3-implementeringsdetaljerna som inkluderar åtgärder för att hantera begränsningar och begränsningar relaterade till objektlagring:

maxstorlek 5 TB per lagrat objekt
Max storlek på 5 GB för ett PUT-objekt
uppladdning med flera delar rekommenderas för objekt större än 100 MB
välj en lämplig lagringsklass i enlighet med S3-prestandadiagrammet
utnyttja S3-livscykeln
S3 Data Consistency Model

Som ett exempel, se aws s3 cp-hjälpsidan:

--expected-size (sträng) Detta argument specificerar den förväntade storleken på en ström i termer av byte. Observera att detta argument endast behövs när en stream laddas upp till s3 och storleken är större än 5 GB. Underlåtenhet att inkludera detta argument under dessa villkor kan resultera i en misslyckad uppladdning på grund av för många delar i uppladdningen.

Att undvika dessa fallgropar kräver djupgående kunskap om S3-ekosystemet, vilket är vad de specialbyggda PostgreSQL- och S3-säkerhetskopieringsverktygen försöker uppnå.

PostgreSQL Native Backup-verktyg med stöd för Amazon S3

S3-integrering tillhandahålls av några av de välkända säkerhetskopieringsverktygen, som implementerar PostgreSQL inbyggda säkerhetskopieringsfunktioner.

BarmanS3

BarmanS3 är implementerat som Barman Hook-skript. Den förlitar sig på AWS CLI, utan att ta itu med rekommendationerna och begränsningarna som anges ovan. Den enkla installationen gör den till en bra kandidat för små installationer. Utvecklingen har avstannat något, senaste uppdatering för ungefär ett år sedan, vilket gör denna produkt till ett val för dem som redan använder Barman i sina miljöer.

S3-dumpar

S3dumps är ett aktivt projekt, implementerat med Amazons Python-bibliotek Boto3. Installation utförs enkelt via pip. Även om man förlitar sig på Amazon S3 Python SDK, avslöjar inte en sökning av källkoden efter regex-nyckelord som multi.*part eller storage.*class någon av de avancerade S3-funktionerna, såsom flerpartsöverföringar.

pgBackRest

pgBackRest implementerar S3 som ett lagringsalternativ. Detta är ett av de välkända PostgreSQL-säkerhetskopieringsverktygen, som ger en funktionsrik uppsättning säkerhetskopieringsalternativ som parallell backup och återställning, kryptering och stöd för tabellutrymmen. Det är mestadels C-kod, som ger den hastighet och genomströmning vi letar efter, men när det kommer till att interagera med AWS S3 API kommer detta till priset av det extra arbete som krävs för att implementera S3-lagringsfunktionerna. Den senaste versionen implementerar S3 flerdelad uppladdning.

WAL-G

WAL-G som annonserades för 2 år sedan underhålls aktivt. Det här stenhårda PostgreSQL-säkerhetskopieringsverktyget implementerar lagringsklasser, men inte flerdelad uppladdning (det gick inte att söka efter koden för CreateMultipartUpload).

PGHoard

pghoard släpptes för cirka 3 år sedan. Det är ett presterande och funktionsrikt PostgreSQL-säkerhetskopieringsverktyg med stöd för S3 flerdelade överföringar. Den erbjuder inte någon av de andra S3-funktionerna som lagringsklass och objektlivscykelhantering.

S3 som ett lokalt filsystem

Att kunna komma åt S3-lagring som ett lokalt filsystem är en mycket önskvärd funktion eftersom det öppnar upp för möjligheten att använda PostgreSQL inbyggda säkerhetskopieringsverktyg.

För Linux-miljöer erbjuder Amazon två alternativ:NFS och iSCSI. De drar fördel av AWS Storage Gateway.

NFS

En lokalt monterad NFS-resurs tillhandahålls av tjänsten AWS Storage Gateway File. Enligt länken måste vi skapa en filgateway.

Välj Amazon EC2 på skärmen Välj värdplattform och klicka på knappen Starta instans för att starta EC2-guiden för att skapa instansen.

Nu, bara av denna Sysadmins nyfikenhet, låt oss inspektera AMI som används av guiden eftersom det ger oss ett intressant perspektiv på några av AWS interna delar. Med bild-ID:t kända ami-0bab9d6dffb52fef5 låt oss titta på detaljer:

Som visas ovan är AMI-namnet aws-thinstaller — så vad är en "thinstaller"? Internetsökningar avslöjar att Thinstaller är ett IBM Lenovo-programvarukonfigurationshanteringsverktyg för Microsoft-produkter och det refereras först i denna blogg från 2008 och senare i detta Lenovo-foruminlägg och denna begäran om service från skoldistriktet. Jag hade inget sätt att veta det, eftersom mitt Windows-systemadministratörsjobb avslutades tre år tidigare. Så var denna AMI byggd med Thinstaller-produkten. För att göra saken ännu mer förvirrande är AMI-operativsystemet listat som "Annan Linux", vilket kan bekräftas av SSH-ing i systemet som admin.

A wizard gotcha:trots installationsinstruktionerna för EC2-brandväggen tog min webbläsare timeout när jag ansluter till lagringsgatewayen. Att tillåta port 80 dokumenteras i Port Requirements — vi skulle kunna hävda att guiden antingen bör lista alla nödvändiga portar eller länka till dokumentation, men i molnets anda är svaret "automatisera" med verktyg som CloudFormation.

Guiden föreslår också att man börjar med en instans av xlarge storlek.

När lagringsgatewayen är klar konfigurerar du NFS-resursen genom att klicka på Skapa fildelningsknapp i Gateway-menyn:

När NFS-resursen är klar följer du instruktionerna för att montera filsystemet:

I skärmdumpen ovan, notera att monteringskommandot refererar till instansens privata IP adress. För att montera från en offentlig värd, använd bara instansens allmänna adress som visas i EC2-instansdetaljerna ovan.

Guiden kommer inte att blockera om S3-bucket inte existerar när filresursen skapades, men när S3-bucket har skapats måste vi starta om instansen, annars monteras kommandot misslyckas med:

[[email protected] ~]# mount -t nfs -o nolock,hard 34.207.216.29:/s9s-postgresql-backup /mnt

mount.nfs: mounting 34.207.216.29:/s9s-postgresql-backup failed, reason given by server: No such file or directory

Verifiera att delningen har gjorts tillgänglig:

[[email protected] ~]# df -h /mnt

Filesystem                            Size Used Avail Use% Mounted on

34.207.216.29:/s9s-postgresql-backup  8.0E 0 8.0E 0% /mnt

Låt oss nu köra ett snabbtest:

[email protected][local]:54311 postgres# \l+ test

                                                List of databases

Name |  Owner | Encoding |   Collate | Ctype | Access privileges |  Size | Tablespace | Description

------+----------+----------+-------------+-------------+-------------------+---------+------------+-------------

test | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                   | 2763 MB | pg_default |

(1 row)

[[email protected] ~]# date ; time pg_dump -d test | gzip -c >/mnt/test.pg_dump.gz ; date

Sun 27 Oct 2019 06:06:24 PM PDT



real    0m29.807s

user    0m15.909s

sys     0m2.040s

Sun 27 Oct 2019 06:06:54 PM PDT

Observera att den senast ändrade tidsstämpeln på S3-skopan är ungefär en minut senare, vilket som nämnts tidigare måste ha med Amazon S3-datakonsistensmodellen.

Här är ett mer uttömmande test:

~ $ for q in {0..20} ; do touch /mnt/touched-at-$(date +%Y%m%d%H%M%S) ;

sleep 1 ; done



~ $ aws s3 ls s3://s9s-postgresql-backup | nl

    1      2019-10-27 19:50:40          0 touched-at-20191027194957

    2      2019-10-27 19:50:40          0 touched-at-20191027194958

    3      2019-10-27 19:50:40          0 touched-at-20191027195000

    4      2019-10-27 19:50:40          0 touched-at-20191027195001

    5      2019-10-27 19:50:40          0 touched-at-20191027195002

    6      2019-10-27 19:50:40          0 touched-at-20191027195004

    7      2019-10-27 19:50:40          0 touched-at-20191027195005

    8      2019-10-27 19:50:40          0 touched-at-20191027195007

    9      2019-10-27 19:50:40          0 touched-at-20191027195008

   10      2019-10-27 19:51:10          0 touched-at-20191027195009

   11      2019-10-27 19:51:10          0 touched-at-20191027195011

   12      2019-10-27 19:51:10          0 touched-at-20191027195012

   13      2019-10-27 19:51:10          0 touched-at-20191027195013

   14      2019-10-27 19:51:10          0 touched-at-20191027195014

   15      2019-10-27 19:51:10          0 touched-at-20191027195016

   16      2019-10-27 19:51:10          0 touched-at-20191027195017

   17      2019-10-27 19:51:10          0 touched-at-20191027195018

   18      2019-10-27 19:51:10          0 touched-at-20191027195020

   19      2019-10-27 19:51:10          0 touched-at-20191027195021

   20      2019-10-27 19:51:10          0 touched-at-20191027195022

   21      2019-10-27 19:51:10          0 touched-at-20191027195024

Ett annat problem som är värt att nämna:efter att ha spelat med olika konfigurationer, skapat och förstört gateways och resurser, någon gång när jag försökte aktivera en filgateway, fick jag ett internt fel:

Kommandoraden ger lite mer information, även om den inte pekar på något problem:

~$ curl -sv "http://107.22.30.30/?gatewayType=FILE_S3&activationRegion=us-east-1"

*   Trying 107.22.30.30:80...

* TCP_NODELAY set

* Connected to 107.22.30.30 (107.22.30.30) port 80 (#0)

> GET /?gatewayType=FILE_S3&activationRegion=us-east-1 HTTP/1.1

> Host: 107.22.30.30

> User-Agent: curl/7.65.3

> Accept: */*

>

* Mark bundle as not supporting multiuse

< HTTP/1.1 500 Internal Server Error

< Date: Mon, 28 Oct 2019 06:33:30 GMT

< Content-type: text/html

< Content-length: 14

<

* Connection #0 to host 107.22.30.30 left intact

Internal Error~ $

Det här foruminlägget påpekade att mitt problem kan ha något att göra med VPC-slutpunkten som jag skapade. Min fix var att ta bort VPC-slutpunkten som jag hade konfigurerat under olika iSCSI-test- och felkörningar.

Medan S3 krypterar data i vila, är NFS-trådtrafiken vanlig text. För att säga, här är en tcpdump-paketdump:

23:47:12.225273 IP 192.168.0.11.936 > 107.22.30.30.2049: Flags [P.], seq 2665:3377, ack 2929, win 501, options [nop,nop,TS val 1899459538 ecr 38013066], length 712: NFS request xid 3511704119 708 getattr fh 0,2/53

[email protected]@.......k.......        ...c..............

q7s..D.......PZ7...........................4........omiday.can.local...................................................5.......]...........!....................C...

..............&...........]....................# inittab is no longer used.

#

# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.

#

# Ctrl-Alt-Delete is handled by /usr/lib/systemd/system/ctrl-alt-del.target

#

# systemd uses 'targets' instead of runlevels. By default, there are two main targets:

#

# multi-user.target: analogous to runlevel 3

# graphical.target: analogous to runlevel 5

#

# To view current default target, run:

# systemctl get-default

#

# To set a default target, run:

# systemctl set-default TARGET.target

.....   .........0..

23:47:12.331592 IP 107.22.30.30.2049 > 192.168.0.11.936: Flags [P.], seq 2929:3109, ack 3377, win 514, options [nop,nop,TS val 38013174 ecr 1899459538], length 180: NFS reply xid 3511704119 reply ok 176 getattr NON 4 ids 0/33554432 sz -2138196387

Tills detta IEE-utkast har godkänts är det enda säkra alternativet för att ansluta utifrån AWS att använda en VPN-tunnel. Detta komplicerar installationen, vilket gör det lokala NFS-alternativet mindre tilltalande än de FUSE-baserade verktygen som jag kommer att diskutera lite senare.

iSCSI

Det här alternativet tillhandahålls av AWS Storage Gateway Volume-tjänsten. När tjänsten är konfigurerad, gå till avsnittet för installation av Linux iSCSI-klient.

Fördelen med att använda iSCSI framför NFS består i möjligheten att dra fördel av Amazons molnbaserade backup-, klonings- och ögonblicksbildtjänster. För detaljer och steg-för-steg-instruktioner, följ länkarna till AWS Backup, Volume Cloning och EBS Snapshots

Även om det finns många fördelar, finns det en viktig begränsning som troligen kommer att kasta bort många användare:det är inte möjligt att komma åt gatewayen via dess offentliga IP-adress. Så, precis som NFS-alternativet, ökar detta krav komplexiteten till installationen.

Trots den tydliga begränsningen och övertygad om att jag inte kommer att kunna slutföra den här installationen, ville jag ändå få en känsla av hur det går till. Guiden omdirigerar till en AWS Marketplace-konfigurationsskärm.

Observera att Marketplace-guiden skapar en sekundär disk, dock inte tillräckligt stor i storlek, och därför behöver vi fortfarande lägga till de två nödvändiga volymerna som anges av värdinställningsinstruktionerna. Om lagringskraven inte uppfylls kommer guiden att blockeras på konfigurationsskärmen för lokala diskar:

Här är en glimt av Amazon Marketplace-konfigurationsskärmen:

Det finns ett textgränssnitt tillgängligt via SSH (logga in som användare sguser) som tillhandahåller grundläggande nätverksfelsökningsverktyg och andra konfigurationsalternativ som inte kan utföras via webbgränssnittet:

~ $ ssh [email protected]

Warning: Permanently added 'ec2-3-231-96-109.compute-1.amazonaws.com,3.231.96.109' (ECDSA) to the list of known hosts.

'screen.xterm-256color': unknown terminal type.




      AWS Storage Gateway Configuration



      #######################################################################

      ##  Currently connected network adapters:

      ##

      ##  eth0: 172.31.1.185

      #######################################################################



      1: SOCKS Proxy Configuration

      2: Test Network Connectivity

      3: Gateway Console

      4: View System Resource Check (0 Errors)



      0: Stop AWS Storage Gateway



      Press "x" to exit session



      Enter command:

Och ett par andra viktiga punkter:

Tvärtemot NFS-inställningen finns det ingen direkt åtkomst till S3-lagringen som anges i avsnittet med vanliga frågor om volymgateway.
AWS-dokumentationen insisterar på att anpassa iSCSI-inställningarna för att förbättra anslutningens prestanda och säkerhet.

SÄKRING

I den här kategorin har jag listat de FUSE-baserade verktygen som ger en mer komplett S3-kompatibilitet jämfört med PostgreSQL-säkerhetskopieringsverktygen, och i motsats till Amazon Storage Gateway, tillåter dataöverföringar från en lokal värd till Amazon S3 utan ytterligare konfiguration. En sådan installation skulle kunna tillhandahålla S3-lagring som ett lokalt filsystem som PostgreSQL-säkerhetskopieringsverktyg kan använda för att dra fördel av funktioner som parallell pg_dump.

s3fs-säkring

s3fs-fuse är skrivet i C++, ett språk som stöds av Amazon S3 SDK-verktygssatsen, och är som sådan väl lämpad för att implementera avancerade S3-funktioner som flerpartsuppladdningar, cachning, S3-lagringsklass, server- sidokryptering och regionval. Den är också mycket POSIX-kompatibel.

Applikationen ingår i min Fedora 30, vilket gör installationen enkel.

För att testa:

~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz

real    0m35.761s

user    0m16.122s

sys     0m2.228s

~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup

2019-10-28 03:16:03   79110010 test.pg_dump-20191028-031535.gz

Observera att hastigheten är något långsammare än att använda Amazon Storage Gateway med NFS-alternativet. Det kompenserar för den lägre prestandan genom att tillhandahålla ett mycket POSIX-kompatibelt filsystem.

S3QL

S3QL tillhandahåller S3-funktioner som lagringsklass och kryptering på serversidan. De många funktionerna beskrivs i den uttömmande S3QL-dokumentationen, men om du letar efter flerdelad uppladdning nämns det ingenstans. Detta beror på att S3QL implementerar sin egen fildelningsalgoritm för att tillhandahålla de-dupliceringsfunktionen. Alla filer är uppdelade i 10 MB-block.

Installationen på ett Red Hat-baserat system är enkel:installera de nödvändiga RPM-beroendena via yum:

sqlite-devel-3.7.17-8.14.amzn1.x86_64

fuse-devel-2.9.4-1.18.amzn1.x86_64

fuse-2.9.4-1.18.amzn1.x86_64

system-rpm-config-9.0.3-42.28.amzn1.noarch

python36-devel-3.6.8-1.14.amzn1.x86_64

kernel-headers-4.14.146-93.123.amzn1.x86_64

glibc-headers-2.17-260.175.amzn1.x86_64

glibc-devel-2.17-260.175.amzn1.x86_64

gcc-4.8.5-1.22.amzn1.noarch

gcc48-4.8.5-28.142.amzn1.x86_64

mpfr-3.1.1-4.14.amzn1.x86_64

libmpc-1.0.1-3.3.amzn1.x86_64

libgomp-6.4.1-1.45.amzn1.x86_64

libgcc48-4.8.5-28.142.amzn1.x86_64

cpp48-4.8.5-28.142.amzn1.x86_64

python36-pip-9.0.3-1.26.amzn1.noarch

python36-libs-3.6.8-1.14.amzn1.x86_64

python36-3.6.8-1.14.amzn1.x86_64

python36-setuptools-36.2.7-1.33.amzn1.noarch

Installera sedan Python-beroendena med pip3:

pip-3.6 install setuptools cryptography defusedxml apsw dugong pytest requests llfuse==1.3.6

En anmärkningsvärd egenskap hos detta verktyg är S3QL-filsystemet som skapats ovanpå S3-hinken.

Långben

fången är ett alternativ när prestanda överträffar POSIX-efterlevnaden. Dess mål är motsatsen till s3fs-fuse. Fokus på hastighet återspeglas också i distributionsmodellen. För Linux finns förbyggda binärer. När du har laddat ned kör:

~/temp/goofys $ ./goofys s9s-postgresql-backup ~/mnt/s9s/

Och säkerhetskopiering:

~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz



real    0m27.427s

user    0m15.962s

sys     0m2.169s



~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup

2019-10-28 04:29:05   79110010 test.pg_dump-20191028-042902.gz

Observera att objektskapningstiden på S3 bara är 3 sekunder från filens tidsstämpel.

ObjectFS

ObjectFS verkar ha underhållits tills för ungefär 6 månader sedan. En kontroll för flerdelad uppladdning avslöjar att det inte är implementerat. Från författarens forskningsartikel får vi veta att systemet fortfarande är under utveckling, och eftersom uppsatsen släpptes 2019 tyckte jag att det skulle vara värt att nämna det.

S3-klienter

Som nämnts tidigare, för att kunna använda AWS S3 CLI, måste vi ta hänsyn till flera aspekter som är specifika för objektlagring i allmänhet, och Amazon S3 i synnerhet. Om det enda kravet är förmågan att överföra data in och ut ur S3-lagringen, kan ett verktyg som noga följer Amazon S3-rekommendationerna göra jobbet.

s3cmd är ett av verktygen som stod emot tidens tand. Den här Open BI-bloggen från 2010 talar om det, vid en tidpunkt då S3 var den nya ungen på blocket.

Anmärkningsvärda funktioner:

kryptering på serversidan
automatiska flerdelade uppladdningar
bandbreddsbegränsning

Gå till S3cmd:FAQ och Knowledge Base för mer information.

Slutsats

De tillgängliga alternativen för att säkerhetskopiera ett PostgreSQL-kluster till Amazon S3 skiljer sig åt i dataöverföringsmetoderna och hur de överensstämmer med Amazon S3-strategierna.

AWS Storage Gateway kompletterar Amazons S3-objektlagring, till priset av ökad komplexitet tillsammans med ytterligare kunskap som krävs för att få ut det mesta av denna tjänst. Att välja rätt antal diskar kräver till exempel noggrann planering, och ett bra grepp om Amazons S3-relaterade kostnader är ett måste för att minimera driftskostnaderna.

Även om det är tillämpligt på alla molnlagringar, inte bara Amazon S3, har beslutet att lagra data i ett offentligt moln säkerhetskonsekvenser. Amazon S3 tillhandahåller kryptering för data i vila och data under överföring, utan garanti för noll kunskap eller inga kunskapsbevis. Organisationer som vill ha full kontroll över sina data bör implementera kryptering på klientsidan och lagra krypteringsnycklarna utanför sin AWS-infrastruktur.

För kommersiella alternativ till att mappa S3 till ett lokalt filsystem är det värt att kolla in produkterna från ObjectiveFS eller NetApp.

Slutligen bör organisationer som vill utveckla sina egna säkerhetskopieringsverktyg, antingen genom att bygga på den grund som tillhandahålls av de många applikationerna med öppen källkod, eller genom att börja från noll, överväga att använda S3-kompatibilitetstestet, som gjorts tillgängligt av Ceph-projektet.