Функции на метода за архивиране на PostgreSQL в AWS S3

Amazon пусна S3 в началото на 2006 г. и първият инструмент, позволяващ на скриптове за архивиране на PostgreSQL да качват данни в облака — s3cmd — се роди само една година по-късно. До 2010 г. (според моите умения за търсене в Google) Отворете BI блогове за това. Тогава е безопасно да се каже, че някои от PostgreSQL DBA архивират данни в AWS S3 в продължение на цели 9 години. Но как? И какво се промени през това време? Докато s3cmd все още се споменава от някои в контекста на известни инструменти за архивиране на PostgreSQL, методите са претърпели промени, позволяващи по-добра интеграция или с файловата система, или с оригиналните опции за архивиране на PostgreSQL, за да се постигнат желаните цели за възстановяване RTO и RPO.

Защо Amazon S3

Както е посочено в документацията на Amazon S3 (често задавани въпроси за S3 са много добра отправна точка), предимствата на използването на услугата S3 са:

99,999999999 (единадесет деветки) издръжливост
неограничено съхранение на данни
ниски разходи (дори по-ниски, когато се комбинират с BitTorrent)
входящ мрежов трафик безплатно
само изходящ мрежов трафик се таксува

Разбира AWS S3 CLI

Инструментариумът AWS S3 CLI предоставя всички инструменти, необходими за прехвърляне на данни във и извън хранилището на S3, така че защо да не използвате тези инструменти? Отговорът се крие в подробностите за внедряването на Amazon S3, които включват мерки за справяне с ограниченията и ограниченията, свързани със съхранението на обекти:

5TB максимален размер на съхранен обект
5 GB максимален размер на PUT обект
многочастно качване се препоръчва за обекти, по-големи от 100 MB
изберете подходящ клас за съхранение в съответствие с графиката за производителност на S3
възползвайте се от жизнения цикъл на S3
Модел за съгласуваност на данни S3

Като пример вижте помощната страница на aws s3 cp:

--expected-size (низ) Този аргумент указва очаквания размер на поток по отношение на байтове. Имайте предвид, че този аргумент е необходим само когато поток се качва в s3 и размерът е по-голям от 5 GB. Невключването на този аргумент при тези условия може да доведе до неуспешно качване поради твърде много части в качването.

Избягването на тези клопки изисква задълбочени познания за екосистемата S3, което се опитват да постигнат специално създадените инструменти за архивиране на PostgreSQL и S3.

Инструменти за архивиране на PostgreSQL с поддръжка на Amazon S3

Интеграцията на S3 се осигурява от някои от добре познатите инструменти за архивиране, внедряващи естествените функции за архивиране на PostgreSQL.

BarmanS3

BarmanS3 е реализиран като скриптове за кука на Barman. Той наистина разчита на AWS CLI, без да се занимава с препоръките и ограниченията, изброени по-горе. Простата настройка го прави добър кандидат за малки инсталации. Разработката е донякъде в застой, последна актуализация преди около година, което прави този продукт избор за тези, които вече използват Barman в своите среди.

S3 Dumps

S3dumps е активен проект, реализиран с помощта на Python библиотеката на Amazon Boto3. Инсталацията се извършва лесно чрез pip. Въпреки че разчита на Amazon S3 Python SDK, търсенето в изходния код за ключови думи с регулярни изрази като multi.*part или storage.*class не разкрива нито една от разширените функции на S3, като например прехвърляне на много части.

pgBackRest

pgBackRest прилага S3 като опция за хранилище. Това е един от добре познатите инструменти за архивиране на PostgreSQL, предоставящ богат на функции набор от опции за архивиране, като паралелно архивиране и възстановяване, криптиране и поддръжка на пространства за таблици. Това е предимно C код, който осигурява скоростта и пропускателната способност, които търсим, но когато става въпрос за взаимодействие с AWS S3 API, това идва с цената на допълнителната работа, необходима за внедряване на функциите за съхранение на S3. Най-новата версия имплементира качване от няколко части на S3.

WAL-G

WAL-G, обявен преди 2 години, се поддържа активно. Този стабилен инструмент за архивиране на PostgreSQL прилага класове за съхранение, но не и многочастно качване (търсенето в кода за CreateMultipartUpload не откри никакво събитие).

PGHoard

pghoard беше пуснат преди около 3 години. Това е ефективен и богат на функции PostgreSQL инструмент за архивиране с поддръжка за S3 многочастни трансфери. Той не предлага нито една от другите функции на S3, като например клас за съхранение и управление на жизнения цикъл на обекта.

S3 като локална файлова система

Възможността за достъп до хранилището на S3 като локална файлова система е силно желана функция, тъй като отваря възможността за използване на собствените инструменти за архивиране на PostgreSQL.

За Linux среди Amazon предлага две опции:NFS и iSCSI. Те се възползват от AWS Storage Gateway.

NFS

Локално монтиран NFS дял се предоставя от файловата услуга на AWS Storage Gateway. Според връзката трябва да създадем файлов шлюз.

На екрана Избор на хост платформа изберете Amazon EC2 и щракнете върху бутона Стартиране на екземпляр за да стартирате съветника EC2 за създаване на екземпляр.

Сега, просто от любопитство на този сисадмин, нека да проверим AMI, използван от съветника, тъй като ни дава интересна гледна точка върху някои от вътрешните части на AWS. С идентификатора на изображението, известен ami-0bab9d6dffb52fef5, нека разгледаме подробностите:

Както е показано по-горе, името на AMI е aws-thinstaller — така че какво е „инсталатор“? Търсенията в интернет разкриват, че Thinstaller е инструмент за управление на конфигурацията на софтуера на IBM Lenovo за продукти на Microsoft и е споменат първо в този блог от 2008 г., а по-късно в тази публикация във форума на Lenovo и тази заявка за услуга в училищния район. Нямах начин да знам това, тъй като работата ми за системен администратор на Windows приключи 3 години по-рано. И този AMI беше създаден с продукта Thinstaller. За да направи нещата още по-объркващи, операционната система AMI е посочена като „Друг Linux“, което може да бъде потвърдено чрез SSH-включване в системата като администратор.

Разбирам съветника:въпреки инструкциите за настройка на защитната стена EC2, браузърът ми изтичаше при свързване към шлюза за съхранение. Разрешаването на порт 80 е документирано в Изисквания за портове – бихме могли да твърдим, че съветникът трябва или да изброи всички необходими портове, или да направи връзка с документация, но в духа на облака отговорът е „автоматизиране“ с инструменти като CloudFormation.

Помощникът също така предлага да започнете с екземпляр с размер xlarge.

След като шлюзът за съхранение е готов, конфигурирайте споделянето на NFS, като щракнете върху Създаване бутон за споделяне на файлове в менюто на шлюза:

След като споделянето на NFS е готово, следвайте инструкциите за монтиране на файловата система:

В горната екранна снимка имайте предвид, че командата за монтиране препраща към частния IP адрес на екземпляра адрес. За да монтирате от публичен хост, просто използвайте публичния адрес на екземпляра, както е показано в подробностите за екземпляра EC2 по-горе.

Помощникът няма да блокира, ако S3 bucket не съществува към момента на създаване на споделяне на файлове, но, след като S3 bucket бъде създадена, трябва да рестартираме екземпляра, в противен случай командата mount неуспешно с:

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

Уверете се, че споделянето е предоставено:

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

Сега нека проведем бърз тест:

[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

Обърнете внимание, че последното модифицирано времеви отпечатък в сегмента S3 е около минута по-късно, което, както споменахме по-рано, е свързано с модела за съгласуваност на данните на Amazon S3.

Ето по-изчерпателен тест:

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

Друг проблем, който си струва да се спомене:след игра с различни конфигурации, създаване и унищожаване на шлюзове и споделяния, в някакъв момент, когато се опитвах да активирам файлов шлюз, получавах вътрешна грешка:

Командният ред дава някои повече подробности, въпреки че не сочи към проблем:

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

Тази публикация във форума посочи, че проблемът ми може да има нещо общо с VPC крайната точка, която създадох. Моята корекция беше изтриването на VPC крайната точка, която бях настроил по време на различни пробни и грешки на iSCSI.

Докато S3 криптира данните в покой, NFS трафикът е обикновен текст. А именно, ето дъмп на пакети tcpdump:

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

Докато тази IEE чернова не бъде одобрена, единствената сигурна опция за свързване извън AWS е чрез използване на VPN тунел. Това усложнява настройката, което прави локалната опция за NFS по-малко привлекателна от инструментите, базирани на FUSE, които ще обсъдя малко по-късно.

iSCSI

Тази опция се предоставя от услугата AWS Storage Gateway Volume. След като услугата е конфигурирана, отидете на секцията за настройка на Linux iSCSI клиента.

Предимството на използването на iSCSI пред NFS се състои във възможността да се възползвате от услугите за архивиране, клониране и моментни снимки в облака на Amazon. За подробности и инструкции стъпка по стъпка следвайте връзките към AWS Backup, Volume Cloning и EBS Snapshots

Въпреки че има много предимства, има важно ограничение, което вероятно ще отблъсне много потребители:не е възможен достъп до шлюза през неговия публичен IP адрес. Така че, точно както опцията NFS, това изискване добавя сложност към настройката.

Въпреки ясното ограничение и убеден, че няма да мога да завърша тази настройка, все пак исках да усетя как се прави. Помощникът пренасочва към екран за конфигурация на AWS Marketplace.

Обърнете внимание, че съветникът на Marketplace създава вторичен диск, но не достатъчно голям в размер и следователно все още трябва да добавим двата необходими тома, както е посочено от инструкциите за настройка на хоста. Ако изискванията за съхранение не са изпълнени, съветникът ще блокира на екрана за конфигуриране на локални дискове:

Ето един поглед върху екрана за конфигуриране на Amazon Marketplace:

Има текстов интерфейс, достъпен чрез SSH (влезте като потребител sguser) който предоставя основни инструменти за отстраняване на неизправности в мрежата и други опции за конфигуриране, които не могат да бъдат изпълнени чрез уеб 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:

И няколко други важни точки:

Противно на настройката на NFS, няма директен достъп до хранилището на S3, както е отбелязано в раздела с често задавани въпроси за Volume Gateway.
Документацията на AWS настоява за персонализиране на iSCSI настройките с цел подобряване на производителността и сигурността на връзката.

ПРЕДОХРАНИТЕЛ

В тази категория изброих инструментите, базирани на FUSE, които осигуряват по-пълна съвместимост със S3 в сравнение с инструментите за архивиране на PostgreSQL и за разлика от Amazon Storage Gateway позволяват прехвърляне на данни от локален хост към Amazon S3 без допълнителна конфигурация. Такава настройка може да осигури S3 съхранение като локална файлова система, която PostgreSQL инструменти за архивиране могат да използват, за да се възползват от функции като паралелен pg_dump.

s3fs-предпазител

s3fs-fuse е написан на C++, език, поддържан от инструментариума на Amazon S3 SDK, и като такъв е много подходящ за внедряване на разширени S3 функции като качване на множество части, кеширане, клас за съхранение S3, сървър- странично криптиране и избор на регион. Освен това е силно съвместим с POSIX.

Приложението е включено в моята Fedora 30, което прави инсталацията лесна.

За тестване:

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

Обърнете внимание, че скоростта е малко по-бавна от използването на Amazon Storage Gateway с опцията NFS. Той компенсира по-ниската производителност, като предоставя високо съвместима с POSIX файлова система.

S3QL

S3QL предоставя S3 функции като клас за съхранение и криптиране от страна на сървъра. Многото функции са описани в изчерпателната S3QL документация, но ако търсите качване от няколко части, това не е споменато никъде. Това е така, защото S3QL прилага свой собствен алгоритъм за разделяне на файлове, за да осигури функцията за премахване на дублирането. Всички файлове са разбити на блокове от 10 MB.

Инсталацията на базирана на Red Hat система е проста:инсталирайте необходимите RPM зависимости чрез 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

След това инсталирайте зависимостите на Python с помощта на pip3:

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

Забележителна характеристика на този инструмент е файловата система S3QL, създадена върху кофата на S3.

Глупости

goofys е опция, когато производителността превъзхожда съответствието с POSIX. Неговите цели са противоположни на s3fs-fuse. Фокусът върху скоростта се отразява и в модела на разпространение. За Linux има предварително изградени двоични файлове. След като изтеглите, стартирайте:

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

И резервно копие:

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

Обърнете внимание, че времето за създаване на обект на S3 е само на 3 секунди от времевия печат на файла.

ObjectFS

ObjectFS изглежда е бил поддържан до преди около 6 месеца. Проверката за многочастно качване разкрива, че не е внедрена. От изследователската статия на автора научаваме, че системата все още е в процес на разработка и тъй като документът беше пуснат през 2019 г., реших, че си струва да го спомена.

S3 клиенти

Както споменахме по-рано, за да използваме AWS S3 CLI, трябва да вземем предвид няколко аспекта, специфични за съхранението на обекти като цяло и за Amazon S3 в частност. Ако единственото изискване е възможността за прехвърляне на данни в и извън хранилището на S3, тогава инструмент, който следва внимателно препоръките на Amazon S3, може да свърши работа.

s3cmd е един от инструментите, издържали изпитанието на времето. Този блог за Open BI от 2010 г. говори за това, във време, когато S3 беше новото дете в блока.

Забележителни характеристики:

криптиране от страна на сървъра
автоматични качвания от няколко части
ускоряване на честотната лента

Отидете към S3cmd:ЧЗВ и база знания за повече информация.

Заключение

Наличните опции за архивиране на PostgreSQL клъстер към Amazon S3 се различават по методите за пренос на данни и как те са в съответствие със стратегиите на Amazon S3.

AWS Storage Gateway допълва обектното хранилище на Amazon S3 с цената на повишена сложност, заедно с допълнителни знания, необходими, за да извлечете максимума от тази услуга. Например, изборът на правилния брой дискове изисква внимателно планиране и доброто разбиране на разходите, свързани с Amazon S3, е задължително, за да се сведат до минимум оперативните разходи.

Въпреки че е приложимо за всяко облачно хранилище, не само за Amazon S3, решението за съхраняване на данните в публичен облак има последици за сигурността. Amazon S3 осигурява криптиране на данни в състояние на покой и данни в транзит, без гаранция за нулево знание или без доказателства за знания. Организациите, които желаят да имат пълен контрол върху своите данни, трябва да внедрят криптиране от страна на клиента и да съхраняват ключовете за криптиране извън тяхната AWS инфраструктура.

За търговски алтернативи на съпоставянето на S3 в локална файлова система си струва да проверите продуктите от ObjectiveFS или NetApp.

И накрая, организациите, които се стремят да разработят свои собствени инструменти за архивиране, или чрез изграждане на основата, предоставена от много приложения с отворен код, или започвайки от нула, трябва да обмислят използването на теста за съвместимост S3, предоставен от проекта Ceph.