Fitur Metode Pencadangan PostgreSQL di AWS S3

Amazon merilis S3 pada awal tahun 2006 dan alat pertama yang memungkinkan skrip cadangan PostgreSQL untuk mengunggah data di awan — s3cmd — lahir setahun kemudian. Pada tahun 2010 (menurut kemampuan pencarian Google saya) Buka blog BI tentang hal itu. Maka aman untuk mengatakan bahwa beberapa DBA PostgreSQL telah mencadangkan data ke AWS S3 selama 9 tahun. Tapi bagaimana caranya? Dan apa yang berubah selama itu? Sementara s3cmd masih direferensikan oleh beberapa orang dalam konteks alat pencadangan PostgreSQL yang dikenal, metode telah melihat perubahan yang memungkinkan integrasi yang lebih baik dengan sistem file atau opsi pencadangan asli PostgreSQL untuk mencapai tujuan pemulihan yang diinginkan RTO dan RPO.

Mengapa Amazon S3

Seperti yang ditunjukkan di seluruh dokumentasi Amazon S3 (FAQ S3 menjadi titik awal yang sangat baik) keuntungan menggunakan layanan S3 adalah:

• 99.999999999 (sebelas sembilan) daya tahan
• penyimpanan data tak terbatas
• biaya rendah (bahkan lebih rendah jika digabungkan dengan BitTorrent)
• lalu lintas jaringan masuk gratis
• hanya lalu lintas jaringan keluar yang dapat ditagih

AWS S3 CLI Gotcha

Toolkit AWS S3 CLI menyediakan semua alat yang diperlukan untuk mentransfer data masuk dan keluar dari penyimpanan S3, jadi mengapa tidak menggunakan alat tersebut? Jawabannya terletak pada detail implementasi Amazon S3 yang mencakup langkah-langkah untuk menangani batasan dan kendala yang terkait dengan penyimpanan objek:

• Ukuran maksimum 5 TB per objek yang disimpan
• Ukuran maksimum objek PUT 5 GB
• upload beberapa bagian disarankan untuk objek yang lebih besar dari 100MB
• pilih kelas penyimpanan yang sesuai dengan bagan kinerja S3
• manfaatkan Siklus Hidup S3
• Model Konsistensi Data S3

Sebagai contoh lihat halaman bantuan aws s3 cp:

--expected-size (string) Argumen ini menentukan ukuran aliran yang diharapkan dalam satuan byte. Perhatikan bahwa argumen ini diperlukan hanya ketika aliran sedang diunggah ke s3 dan ukurannya lebih besar dari 5 GB. Kegagalan untuk menyertakan argumen ini dalam ketentuan ini dapat mengakibatkan  unggahan yang gagal karena terlalu banyak bagian yang diunggah.

Menghindari jebakan tersebut membutuhkan pengetahuan mendalam tentang ekosistem S3 yang ingin dicapai oleh alat pencadangan PostgreSQL dan S3 yang dibuat khusus.

Alat Pencadangan Asli PostgreSQL Dengan Dukungan Amazon S3

Integrasi S3 disediakan oleh beberapa alat pencadangan terkenal, yang mengimplementasikan fitur pencadangan asli PostgreSQL.

BarmanS3

BarmanS3 diimplementasikan sebagai Skrip Barman Hook. Itu bergantung pada AWS CLI, tanpa membahas rekomendasi dan batasan yang tercantum di atas. Pengaturan sederhana menjadikannya kandidat yang baik untuk instalasi kecil. Pengembangannya agak terhenti, pembaruan terakhir sekitar setahun yang lalu, menjadikan produk ini pilihan bagi mereka yang sudah menggunakan Barman di lingkungan mereka.

S3 Dumps

S3dumps adalah proyek aktif, diimplementasikan menggunakan pustaka Python Boto3 Amazon. Instalasi mudah dilakukan melalui pip. Meskipun mengandalkan Amazon S3 Python SDK, pencarian kode sumber untuk kata kunci regex seperti multi.*part atau storage.*class tidak mengungkapkan fitur S3 lanjutan apa pun, seperti transfer multipart.

pgBackRest

pgBackRest mengimplementasikan S3 sebagai opsi repositori. Ini adalah salah satu alat pencadangan PostgreSQL yang terkenal, menyediakan serangkaian opsi pencadangan yang kaya fitur seperti pencadangan dan pemulihan paralel, enkripsi, dan dukungan tablespace. Sebagian besar adalah kode C, yang memberikan kecepatan dan throughput yang kami cari, namun, saat berinteraksi dengan AWS S3 API, ini harus dibayar dengan pekerjaan tambahan yang diperlukan untuk mengimplementasikan fitur penyimpanan S3. Versi terbaru mengimplementasikan unggahan multi-bagian S3.

WAL-G

WAL-G yang diumumkan 2 tahun lalu sedang aktif dipertahankan. Alat pencadangan PostgreSQL yang kokoh ini mengimplementasikan kelas penyimpanan, tetapi bukan pengunggahan multi-bagian (mencari kode untuk CreateMultipartUpload tidak menemukan kemunculan apa pun).

PGHoard

pghoard dirilis sekitar 3 tahun yang lalu. Ini adalah alat pencadangan PostgreSQL yang berkinerja dan kaya fitur dengan dukungan untuk transfer multi-bagian S3. Itu tidak menawarkan fitur S3 lainnya seperti kelas penyimpanan dan manajemen siklus hidup objek.

S3 sebagai sistem file lokal

Mampu mengakses penyimpanan S3 sebagai sistem file lokal, adalah fitur yang sangat diinginkan karena membuka kemungkinan menggunakan alat pencadangan asli PostgreSQL.

Untuk lingkungan Linux, Amazon menawarkan dua opsi:NFS dan iSCSI. Mereka memanfaatkan AWS Storage Gateway.

NFS

Bagian NFS yang dipasang secara lokal disediakan oleh layanan File AWS Storage Gateway. Menurut tautan, kita perlu membuat File Gateway.

Pada layar Select host platform pilih Amazon EC2 dan klik tombol Launch instance untuk memulai wizard EC2 untuk membuat instance.

Sekarang, hanya karena penasaran Sysadmin ini, mari kita periksa AMI yang digunakan oleh wizard karena memberi kita perspektif yang menarik tentang beberapa bagian internal AWS. Dengan ID gambar yang diketahui ami-0bab9d6dffb52fef5 mari kita lihat detailnya:

Seperti yang ditunjukkan di atas, nama AMI adalah aws-thinstaller — jadi apa seorang "penginstal"? Pencarian internet mengungkapkan bahwa Thinstaller adalah alat manajemen konfigurasi perangkat lunak IBM Lenovo untuk produk Microsoft dan direferensikan pertama kali di blog 2008 ini, dan kemudian di posting forum Lenovo ini dan permintaan layanan distrik sekolah ini. Saya tidak tahu itu, karena pekerjaan sysadmin Windows saya berakhir 3 tahun sebelumnya. Begitu juga AMI ini dibangun dengan produk Thinstaller. Untuk membuat masalah semakin membingungkan, sistem operasi AMI terdaftar sebagai "Linux Lain" yang dapat dikonfirmasikan dengan SSH ke dalam sistem sebagai admin.

Penyihir Gotcha:meskipun ada instruksi penyiapan firewall EC2, browser saya kehabisan waktu saat menghubungkan ke gateway penyimpanan. Mengizinkan port 80 didokumentasikan di Persyaratan Port — kami dapat berargumen bahwa wizard harus mencantumkan semua port yang diperlukan, atau menautkan ke dokumentasi, namun dalam semangat cloud, jawabannya adalah “otomatis” dengan alat seperti CloudFormation.

Wizard juga menyarankan untuk memulai dengan instance ukuran xlarge.

Setelah gateway penyimpanan siap, konfigurasikan NFS share dengan mengklik Create tombol berbagi file di menu Gateway:

Setelah berbagi NFS siap, ikuti petunjuk untuk memasang sistem file:

Pada tangkapan layar di atas, perhatikan bahwa perintah mount mereferensikan instance IP pribadi alamat. Untuk me-mount dari host publik cukup gunakan alamat publik instance seperti yang ditunjukkan pada detail instance EC2 di atas.

Wizard tidak akan memblokir jika bucket S3 tidak ada pada saat membuat berbagi file, namun, setelah bucket S3 dibuat, kita perlu memulai ulang instance, jika tidak, perintah mount gagal dengan:

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

Verifikasi bahwa pembagian telah tersedia:

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

Sekarang mari kita jalankan tes cepat:

[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

Perhatikan bahwa stempel waktu terakhir yang diubah pada bucket S3 adalah sekitar satu menit kemudian, yang seperti yang disebutkan sebelumnya berkaitan dengan model konsistensi data Amazon S3.

Inilah tes yang lebih lengkap:

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

Masalah lain yang perlu disebutkan:setelah bermain dengan berbagai konfigurasi, membuat dan menghancurkan gateway dan berbagi, di beberapa titik ketika mencoba mengaktifkan File gateway, saya mendapatkan Kesalahan Internal:

Baris perintah memberikan beberapa detail lebih lanjut, meskipun tidak menunjukkan masalah apa pun:

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

Pos forum ini menunjukkan bahwa masalah saya mungkin ada hubungannya dengan Titik Akhir VPC yang saya buat. Perbaikan saya adalah menghapus titik akhir VPC yang telah saya siapkan selama berbagai percobaan dan kesalahan iSCSI berjalan.

Sementara S3 mengenkripsi data diam, lalu lintas kabel NFS adalah teks biasa. Singkatnya, inilah dump paket 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

Sampai draf IEE ini disetujui, satu-satunya opsi aman untuk menghubungkan dari luar AWS adalah dengan menggunakan terowongan VPN. Ini memperumit penyiapan, membuat opsi NFS on-premise kurang menarik daripada alat berbasis FUSE yang akan saya bahas nanti.

iSCSI

Opsi ini disediakan oleh layanan AWS Storage Gateway Volume. Setelah layanan dikonfigurasi, buka bagian penyiapan klien iSCSI Linux.

Keuntungan menggunakan iSCSI dibandingkan NFS terdiri dari kemampuan memanfaatkan cadangan asli cloud Amazon, kloning, dan layanan snapshot. Untuk detail dan petunjuk langkah demi langkah, ikuti tautan ke AWS Backup, Volume Cloning, dan EBS Snapshots

Meskipun ada banyak keuntungan, ada batasan penting yang kemungkinan akan membuat banyak pengguna tersingkir:tidak mungkin mengakses gateway melalui alamat IP publiknya. Jadi, seperti opsi NFS, persyaratan ini menambah kerumitan penyiapan.

Meskipun ada batasan yang jelas dan yakin bahwa saya tidak akan dapat menyelesaikan penyiapan ini, saya masih ingin mengetahui cara melakukannya. Wizard dialihkan ke layar konfigurasi AWS Marketplace.

Perhatikan bahwa wizard Marketplace membuat disk sekunder, namun tidak cukup besar di size, dan oleh karena itu kita masih perlu menambahkan dua volume yang diperlukan seperti yang ditunjukkan oleh instruksi penyiapan host. Jika persyaratan penyimpanan tidak terpenuhi, wizard akan memblokir di layar konfigurasi disk lokal:

Berikut ini sekilas layar konfigurasi Amazon Marketplace:

Ada antarmuka teks yang dapat diakses melalui SSH (login sebagai pengguna pengguna) yang menyediakan alat pemecahan masalah jaringan dasar dan opsi konfigurasi lain yang tidak dapat dilakukan melalui GUI web:

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

Dan beberapa poin penting lainnya:

• Bertentangan dengan pengaturan NFS, tidak ada akses langsung ke penyimpanan S3 seperti yang disebutkan di bagian FAQ Volume Gateway.
• Dokumentasi AWS menekankan pada penyesuaian pengaturan iSCSI untuk meningkatkan kinerja dan keamanan koneksi.

FUSE

Dalam kategori ini, saya telah mencantumkan alat berbasis FUSE yang menyediakan kompatibilitas S3 yang lebih lengkap dibandingkan dengan alat pencadangan PostgreSQL, dan berbeda dengan Amazon Storage Gateway, memungkinkan transfer data dari host lokal ke Amazon S3 tanpa konfigurasi tambahan. Pengaturan seperti itu dapat menyediakan penyimpanan S3 sebagai sistem file lokal yang dapat digunakan alat pencadangan PostgreSQL untuk memanfaatkan fitur-fitur seperti pg_dump paralel.

s3fs-fuse

s3fs-fuse ditulis dalam C++, bahasa yang didukung oleh toolkit Amazon S3 SDK, dan karena itu sangat cocok untuk menerapkan fitur S3 tingkat lanjut seperti unggahan multi-bagian, caching, kelas penyimpanan S3, server- enkripsi sisi, dan pemilihan wilayah. Ini juga sangat kompatibel dengan POSIX.

Aplikasi disertakan dengan Fedora 30 saya sehingga penginstalan menjadi mudah.

Untuk menguji:

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

Perhatikan bahwa kecepatannya agak lebih lambat daripada menggunakan Amazon Storage Gateway dengan opsi NFS. Itu menebus kinerja yang lebih rendah dengan menyediakan sistem file yang sangat kompatibel dengan POSIX.

S3QL

S3QL menyediakan fitur S3 seperti kelas penyimpanan, dan enkripsi sisi server. Banyak fitur dijelaskan dalam Dokumentasi S3QL lengkap, namun, jika Anda mencari unggahan multi-bagian, itu tidak disebutkan di mana pun. Ini karena S3QL mengimplementasikan algoritma pemisahan filenya sendiri untuk menyediakan fitur de-duplikasi. Semua file dipecah menjadi blok 10 MB.

Penginstalan pada sistem berbasis Red Hat sangat mudah:instal dependensi RPM yang diperlukan melalui 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

Kemudian instal dependensi Python menggunakan pip3:

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

Karakteristik penting dari alat ini adalah sistem file S3QL yang dibuat di atas bucket S3.

Bodoh

goofys adalah opsi ketika kinerja mengalahkan kepatuhan POSIX. Tujuannya adalah kebalikan dari s3fs-fuse. Fokus pada kecepatan juga tercermin dalam model distribusi. Untuk Linux ada binari yang sudah dibuat sebelumnya. Setelah diunduh, jalankan:

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

Dan cadangan:

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

Perhatikan bahwa waktu pembuatan objek pada S3 hanya berjarak 3 detik dari stempel waktu file.

ObjectFS

ObjectFS tampaknya telah dipertahankan hingga sekitar 6 bulan yang lalu. Pemeriksaan unggahan multi-bagian mengungkapkan bahwa itu tidak diterapkan, Dari makalah penelitian penulis, kami mengetahui bahwa sistem masih dalam pengembangan, dan sejak makalah itu dirilis pada tahun 2019, saya pikir itu layak untuk disebutkan.

Klien S3

Seperti yang disebutkan sebelumnya, untuk menggunakan AWS S3 CLI, kita perlu mempertimbangkan beberapa aspek khusus untuk penyimpanan objek secara umum, dan Amazon S3 secara khusus. Jika satu-satunya persyaratan adalah kemampuan untuk mentransfer data masuk dan keluar dari penyimpanan S3, maka alat yang mengikuti rekomendasi Amazon S3 dapat melakukan pekerjaan itu.

s3cmd adalah salah satu alat yang bertahan dalam ujian waktu. Blog Open BI 2010 ini membicarakannya, pada saat S3 adalah anak baru di blok tersebut.

Fitur penting:

• enkripsi sisi server
• upload beberapa bagian otomatis
• pelambatan bandwidth

Buka S3cmd:FAQ dan Basis Pengetahuan untuk informasi lebih lanjut.

Kesimpulan

Opsi yang tersedia untuk mencadangkan klaster PostgreSQL ke Amazon S3 berbeda dalam metode transfer data dan cara mereka menyelaraskannya dengan strategi Amazon S3.

AWS Storage Gateway melengkapi penyimpanan objek S3 Amazon, dengan biaya kompleksitas yang meningkat bersama dengan pengetahuan tambahan yang diperlukan untuk mendapatkan hasil maksimal dari layanan ini. Misalnya, memilih jumlah disk yang benar memerlukan perencanaan yang cermat, dan pemahaman yang baik tentang biaya terkait S3 Amazon adalah suatu keharusan untuk meminimalkan biaya operasional.

Meskipun berlaku untuk penyimpanan cloud apa pun tidak hanya Amazon S3, keputusan untuk menyimpan data di cloud publik memiliki implikasi keamanan. Amazon S3 menyediakan enkripsi untuk data saat istirahat dan data dalam perjalanan, tanpa jaminan tanpa pengetahuan, atau tanpa bukti pengetahuan. Organisasi yang ingin memiliki kontrol penuh atas data mereka harus menerapkan enkripsi sisi klien dan menyimpan kunci enkripsi di luar infrastruktur AWS mereka.

Untuk alternatif komersial untuk memetakan S3 ke sistem file lokal, ada baiknya memeriksa produk dari ObjectiveFS atau NetApp.

Terakhir, organisasi yang ingin mengembangkan alat pencadangan mereka sendiri, baik dengan membangun di atas fondasi yang disediakan oleh banyak aplikasi sumber terbuka, atau mulai dari nol, harus mempertimbangkan untuk menggunakan uji kompatibilitas S3, yang disediakan oleh proyek Ceph.