PostgreSQL-sikkerhedskopimetodefunktioner i AWS S3

Amazon udgav S3 i begyndelsen af 2006, og det første værktøj, der gør det muligt for PostgreSQL backup-scripts at uploade data i skyen - s3cmd - blev født blot et år senere. Inden 2010 (ifølge mine Google-søgefærdigheder) Åbn BI-blogs om det. Det er da sikkert at sige, at nogle af PostgreSQL DBA'erne har sikkerhedskopieret data til AWS S3 i så længe som 9 år. Men hvordan? Og hvad har ændret sig i den tid? Mens s3cmd stadig refereres til af nogle i forbindelse med kendte PostgreSQL-sikkerhedskopieringsværktøjer, har metoderne set ændringer, der muliggør bedre integration med enten filsystemet eller PostgreSQL native backup-muligheder for at opnå de ønskede gendannelsesmål RTO og RPO.

Hvorfor Amazon S3

Som påpeget i hele Amazon S3-dokumentationen (S3 ofte stillede spørgsmål er et meget godt udgangspunkt), er fordelene ved at bruge S3-tjenesten:

99,999999999 (elleve nire) holdbarhed
ubegrænset datalagring
lave omkostninger (endnu lavere, når det kombineres med BitTorrent)
indgående netværkstrafik gratis
kun udgående netværkstrafik kan faktureres

AWS S3 CLI Gotchas

AWS S3 CLI-værktøjssættet indeholder alle de nødvendige værktøjer til at overføre data ind og ud af S3-lageret, så hvorfor ikke bruge disse værktøjer? Svaret ligger i Amazon S3-implementeringsdetaljerne, som omfatter foranstaltninger til håndtering af begrænsninger og begrænsninger relateret til objektlagring:

maks. 5 TB størrelse pr. gemt objekt
maks. 5 GB størrelse af et PUT-objekt
multipart upload anbefales til objekter større end 100 MB
vælg en passende lagerklasse i overensstemmelse med S3-ydelsesdiagrammet
udnyt S3 Lifecycle
S3-datakonsistensmodel

Se som et eksempel til aws s3 cp hjælpesiden:

--expected-size (streng) Dette argument angiver den forventede størrelse af en strøm i form af bytes. Bemærk, at dette argument kun er nødvendigt, når en stream bliver uploadet til s3 og størrelsen er større end 5 GB. Undladelse af at inkludere dette argument under disse betingelser kan resultere i en mislykket upload på grund af for mange dele i upload.

At undgå disse faldgruber kræver indgående kendskab til S3-økosystemet, hvilket er, hvad de specialbyggede PostgreSQL- og S3-sikkerhedskopieringsværktøjer forsøger at opnå.

PostgreSQL Native Backup-værktøjer med Amazon S3-understøttelse

S3-integration leveres af nogle af de velkendte sikkerhedskopieringsværktøjer, der implementerer PostgreSQL native backup-funktioner.

BarmanS3

BarmanS3 er implementeret som Barman Hook Scripts. Den er afhængig af AWS CLI, uden at adressere de anbefalinger og begrænsninger, der er anført ovenfor. Den enkle opsætning gør den til en god kandidat til små installationer. Udviklingen er noget gået i stå, sidste opdatering for omkring et år siden, hvilket gør dette produkt til et valg for dem, der allerede bruger Barman i deres miljøer.

S3 Dumps

S3dumps er et aktivt projekt, implementeret ved hjælp af Amazons Python-bibliotek Boto3. Installation udføres nemt via pip. Selvom den er afhængig af Amazon S3 Python SDK, afslører en søgning i kildekoden efter regex-nøgleord såsom multi.*part eller storage.*class ingen af de avancerede S3-funktioner, såsom multipart-overførsler.

pgBackRest

pgBackRest implementerer S3 som en lagermulighed. Dette er et af de velkendte PostgreSQL-sikkerhedskopieringsværktøjer, der giver et funktionsrigt sæt sikkerhedskopieringsmuligheder såsom parallel backup og gendannelse, kryptering og understøttelse af tablespaces. Det er for det meste C-kode, som giver den hastighed og gennemstrømning, vi leder efter, men når det kommer til at interagere med AWS S3 API, kommer dette til prisen for det ekstra arbejde, der kræves for at implementere S3-lagringsfunktionerne. Den seneste version implementerer S3 multi-part upload.

WAL-G

WAL-G annonceret for 2 år siden bliver aktivt vedligeholdt. Dette bundsolide PostgreSQL-sikkerhedskopieringsværktøj implementerer lagerklasser, men ikke upload af flere dele (der blev ikke fundet nogen forekomst ved at søge i koden for CreateMultipartUpload).

PGHoard

pghoard blev udgivet for omkring 3 år siden. Det er et effektivt og funktionsrigt PostgreSQL-sikkerhedskopieringsværktøj med understøttelse af S3 multipart-overførsler. Den tilbyder ikke nogen af de andre S3-funktioner såsom opbevaringsklasse og objektlivscyklusstyring.

S3 som et lokalt filsystem

At være i stand til at få adgang til S3-lagring som et lokalt filsystem, er en meget ønsket funktion, da det åbner muligheden for at bruge PostgreSQL native backup-værktøjer.

For Linux-miljøer tilbyder Amazon to muligheder:NFS og iSCSI. De drager fordel af AWS Storage Gateway.

NFS

En lokalt monteret NFS-share leveres af AWS Storage Gateway File-tjenesten. Ifølge linket skal vi oprette en fil-gateway.

Vælg Amazon EC2 på skærmen Vælg værtsplatform og klik på knappen Start forekomst for at starte EC2-guiden til oprettelse af forekomsten.

Nu, bare ud fra denne Sysadmins nysgerrighed, lad os inspicere den AMI, der bruges af guiden, da den giver os et interessant perspektiv på nogle af de interne AWS-dele. Med billed-id'et kendt ami-0bab9d6dffb52fef5 lad os se på detaljer:

Som vist ovenfor er AMI-navnet aws-thinstaller — så hvad er en "thinstaller"? Internetsøgninger afslører, at Thinstaller er et IBM Lenovo-softwarekonfigurationsstyringsværktøj til Microsoft-produkter og refereres først til i denne blog fra 2008 og senere i dette Lenovo-forumindlæg og denne anmodning om service fra skoledistriktet. Jeg havde ingen mulighed for at vide det, da mit Windows-systemadministratorjob sluttede 3 år tidligere. Så var denne AMI bygget med Thinstaller-produktet. For at gøre tingene endnu mere forvirrende er AMI-operativsystemet opført som "Andet Linux", hvilket kan bekræftes ved at SSH-inge ind i systemet som admin.

A wizard gotcha:på trods af EC2 firewall-opsætningsinstruktionerne fik min browser timeout, da den oprettede forbindelse til storage-gatewayen. At tillade port 80 er dokumenteret i Port Requirements - vi kunne argumentere for, at guiden enten skulle liste alle nødvendige porte eller linke til dokumentation, men i skyens ånd er svaret "automatiser" med værktøjer som CloudFormation.

Guiden foreslår også at starte med en instans af xlarge størrelse.

Når storage-gatewayen er klar, skal du konfigurere NFS-delingen ved at klikke på Opret fildelingsknap i Gateway-menuen:

Når NFS-sharet er klar, skal du følge instruktionerne for at montere filsystemet:

I ovenstående skærmbillede skal du bemærke, at mount-kommandoen refererer til forekomstens private IP adresse. For at montere fra en offentlig vært skal du blot bruge instansens offentlige adresse som vist i EC2 instansdetaljerne ovenfor.

Guiden blokerer ikke, hvis S3-bøtten ikke eksisterer på tidspunktet for oprettelse af fildelingen, men når først S3-bøtten er oprettet, skal vi genstarte instansen, ellers skal mount-kommandoen fejler 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

Bekræft, at delingen er gjort tilgængelig:

[[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

Lad os nu køre en hurtig test:

[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

Bemærk, at det sidst ændrede tidsstempel på S3-bøtten er cirka et minut senere, hvilket som tidligere nævnt er nødvendigt med Amazon S3-datakonsistensmodellen.

Her er en mere udtømmende 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

Et andet problem, der er værd at nævne:efter at have spillet med forskellige konfigurationer, oprettet og ødelagt gateways og delinger, på et tidspunkt, da jeg forsøgte at aktivere en fil-gateway, fik jeg en intern fejl:

Kommandolinjen giver nogle flere detaljer, selvom den ikke peger på noget 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~ $

Dette forumindlæg påpegede, at mit problem kan have noget at gøre med det VPC-endepunkt, jeg havde oprettet. Min rettelse var at slette det VPC-slutpunkt, jeg havde opsat under forskellige iSCSI-prøve- og fejlkørsler.

Mens S3 krypterer data i hvile, er NFS-trådtrafikken almindelig tekst. For at vide, her er et tcpdump-pakkedump:

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

Indtil dette IEE-udkast er godkendt, er den eneste sikre mulighed for at oprette forbindelse uden for AWS ved at bruge en VPN-tunnel. Dette komplicerer opsætningen, hvilket gør den lokale NFS-indstilling mindre tiltalende end de FUSE-baserede værktøjer, som jeg vil diskutere lidt senere.

iSCSI

Denne mulighed leveres af AWS Storage Gateway Volume-tjenesten. Når tjenesten er konfigureret, gå til Linux iSCSI-klientopsætningssektionen.

Fordelen ved at bruge iSCSI frem for NFS består i muligheden for at drage fordel af Amazons cloud native backup, kloning og snapshot-tjenester. For detaljer og trinvise instruktioner, følg linkene til AWS Backup, Volume Cloning og EBS Snapshots

Selv om der er masser af fordele, er der en vigtig begrænsning, som sandsynligvis vil afvise mange brugere:det er ikke muligt at få adgang til gatewayen via dens offentlige IP-adresse. Så ligesom NFS-indstillingen tilføjer dette krav kompleksitet til opsætningen.

På trods af den klare begrænsning og overbevist om, at jeg ikke vil være i stand til at fuldføre denne opsætning, ønskede jeg stadig at få en fornemmelse af, hvordan det gøres. Guiden omdirigerer til en AWS Marketplace-konfigurationsskærm.

Bemærk, at Marketplace-guiden opretter en sekundær disk, dog ikke stor nok i størrelse, og derfor mangler vi stadig at tilføje de to påkrævede volumener som angivet af værtsopsætningsinstruktionerne. Hvis lagerkravene ikke er opfyldt, vil guiden blokere på den lokale diskkonfigurationsskærm:

Her er et glimt af Amazon Marketplace-konfigurationsskærmen:

Der er en tekstgrænseflade tilgængelig via SSH (log ind som bruger sguser) som giver grundlæggende netværksfejlfindingsværktøjer og andre konfigurationsmuligheder, som ikke kan udføres via web-GUI:

~ $ 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:

Og et par andre vigtige punkter:

I modsætning til NFS-opsætningen er der ingen direkte adgang til S3-lageret som angivet i Volume Gateway FAQ-sektionen.
AWS-dokumentation insisterer på at tilpasse iSCSI-indstillingerne for at forbedre forbindelsens ydeevne og sikkerhed.

SIKRING

I denne kategori har jeg angivet de FUSE-baserede værktøjer, der giver en mere komplet S3-kompatibilitet sammenlignet med PostgreSQL-sikkerhedskopieringsværktøjerne, og i modsætning til Amazon Storage Gateway tillader dataoverførsler fra en lokal vært til Amazon S3 uden yderligere konfiguration. En sådan opsætning kunne give S3-lagring som et lokalt filsystem, som PostgreSQL-sikkerhedskopieringsværktøjer kan bruge for at drage fordel af funktioner såsom parallel pg_dump.

s3fs-fuse

s3fs-fuse er skrevet i C++, et sprog, der understøttes af Amazon S3 SDK-værktøjssættet, og er som sådan velegnet til implementering af avancerede S3-funktioner såsom multipart-uploads, caching, S3-lagerklasse, server- sidekryptering og områdevalg. Den er også yderst POSIX-kompatibel.

Applikationen er inkluderet i min Fedora 30, hvilket gør installationen ligetil.

For at teste:

~/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

Bemærk, at hastigheden er noget langsommere end at bruge Amazon Storage Gateway med NFS-indstillingen. Det kompenserer for den lavere ydeevne ved at levere et meget POSIX-kompatibelt filsystem.

S3QL

S3QL giver S3-funktioner såsom lagerklasse og serversidekryptering. De mange funktioner er beskrevet i den udtømmende S3QL-dokumentation, men hvis du leder efter multipart-upload er det ingen steder nævnt. Dette skyldes, at S3QL implementerer sin egen filopdelingsalgoritme for at levere de-duplikeringsfunktionen. Alle filer er opdelt i 10 MB blokke.

Installationen på et Red Hat-baseret system er ligetil:installer de nødvendige RPM-afhængigheder 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

Installer derefter Python-afhængighederne ved hjælp af pip3:

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

Et bemærkelsesværdigt kendetegn ved dette værktøj er S3QL-filsystemet, der er oprettet oven på S3-bøtten.

Fedtmule

goofys er en mulighed, når ydeevne overtrumfer POSIX-overensstemmelsen. Dets mål er det modsatte af s3fs-fuse. Fokus på hastighed afspejles også i distributionsmodellen. Til Linux er der forudbyggede binære filer. Når den er downloadet, kør:

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

Og backup:

~/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

Bemærk, at objektoprettelsestiden på S3 kun er 3 sekunder fra filens tidsstempling.

ObjectFS

ObjectFS ser ud til at være blevet vedligeholdt indtil for omkring 6 måneder siden. Et tjek for multipart-upload afslører, at det ikke er implementeret. Fra forfatterens forskningsartikel lærer vi, at systemet stadig er under udvikling, og siden papiret blev udgivet i 2019, tænkte jeg, at det ville være værd at nævne det.

S3-klienter

Som tidligere nævnt, for at bruge AWS S3 CLI, skal vi tage flere aspekter i betragtning, der er specifikke for objektlagring generelt, og Amazon S3 i særdeleshed. Hvis det eneste krav er evnen til at overføre data ind og ud af S3-lageret, så kan et værktøj, der nøje følger Amazon S3-anbefalingerne, gøre jobbet.

s3cmd er et af de værktøjer, der bestod tidens tand. Denne Open BI-blog fra 2010 fortæller om det på et tidspunkt, hvor S3 var det nye barn på blokken.

Bemærkelsesværdige funktioner:

kryptering på serversiden
automatiske multipart-uploads
båndbredderegulering

Gå til S3cmd:FAQ og Knowledge Base for at få flere oplysninger.

Konklusion

De tilgængelige muligheder for at sikkerhedskopiere en PostgreSQL-klynge til Amazon S3 adskiller sig i dataoverførselsmetoderne, og hvordan de stemmer overens med Amazon S3-strategierne.

AWS Storage Gateway komplementerer Amazons S3-objektlagring på bekostning af øget kompleksitet sammen med yderligere viden, der kræves for at få mest muligt ud af denne service. For eksempel kræver det omhyggelig planlægning at vælge det korrekte antal diske, og en god forståelse af Amazons S3-relaterede omkostninger er et must for at minimere driftsomkostningerne.

Selv om det er relevant for enhver cloud-lagring, ikke kun Amazon S3, har beslutningen om at gemme dataene i en offentlig sky sikkerhedsimplikationer. Amazon S3 giver kryptering til hvilende data og data under transport, uden garanti for nul viden eller ingen vidensbeviser. Organisationer, der ønsker at have fuld kontrol over deres data, bør implementere kryptering på klientsiden og gemme krypteringsnøglerne uden for deres AWS-infrastruktur.

For kommercielle alternativer til at kortlægge S3 til et lokalt filsystem er det værd at tjekke produkterne fra ObjectiveFS eller NetApp.

Endelig bør organisationer, der søger at udvikle deres egne sikkerhedskopieringsværktøjer, enten ved at bygge på grundlaget fra de mange open source-applikationer, eller ved at starte fra nul, overveje at bruge S3-kompatibilitetstesten, som er stillet til rådighed af Ceph-projektet.