Ramai orang biasa dengan PostgreSQL DBMS, dan ia telah membuktikan dirinya dalam pemasangan kecil. Walau bagaimanapun, arah aliran ke arah Sumber Terbuka telah menjadi semakin jelas, walaupun ia berkaitan dengan keperluan syarikat dan perusahaan besar. Dalam artikel ini kami akan memberitahu anda cara mengintegrasikan Postgres ke dalam persekitaran korporat dan berkongsi pengalaman kami mencipta sistem sandaran (BSS) untuk pangkalan data ini menggunakan sistem sandaran Commvault sebagai contoh.
PostgreSQL telah pun membuktikan nilainya - DBMS berfungsi hebat, ia digunakan oleh perniagaan digital yang bergaya seperti Alibaba dan TripAdvisor, dan kekurangan yuran pelesenan menjadikannya alternatif yang menarik kepada raksasa seperti MS SQL atau Oracle DB. Tetapi sebaik sahaja kami mula memikirkan PostgreSQL dalam landskap Perusahaan, kami serta-merta menghadapi keperluan yang ketat: βBagaimana pula dengan toleransi kesalahan konfigurasi? rintangan bencana? di manakah pemantauan menyeluruh? Bagaimana pula dengan sandaran automatik? Bagaimana pula dengan menggunakan perpustakaan pita secara langsung dan pada storan sekunder?β
Di satu pihak, PostgreSQL tidak mempunyai alat sandaran terbina dalam, seperti DBMS "dewasa" seperti RMAN dalam Oracle DB atau Sandaran Pangkalan Data SAP. Sebaliknya, pembekal sistem sandaran korporat (Veeam, Veritas, Commvault) walaupun mereka menyokong PostgreSQL, sebenarnya mereka hanya berfungsi dengan konfigurasi tertentu (biasanya kendiri) dan dengan set pelbagai sekatan.
Sistem sandaran yang direka khas untuk PostgreSQL, seperti Barman, Wal-g, pg_probackup, sangat popular dalam pemasangan kecil PostgreSQL DBMS atau di mana sandaran berat elemen lain landskap IT tidak diperlukan. Sebagai contoh, sebagai tambahan kepada PostgreSQL, infrastruktur mungkin termasuk pelayan fizikal dan maya, OpenShift, Oracle, MariaDB, Cassandra, dsb. Adalah dinasihatkan untuk membuat sandaran semua ini dengan alat biasa. Memasang penyelesaian berasingan secara eksklusif untuk PostgreSQL adalah idea yang tidak baik: data akan disalin ke suatu tempat ke cakera, dan kemudian ia perlu dialih keluar ke pita. Sandaran berganda ini meningkatkan masa sandaran, dan juga, lebih kritikal, masa pemulihan.
Dalam penyelesaian perusahaan, sandaran pemasangan berlaku dengan bilangan nod tertentu dalam kelompok khusus. Pada masa yang sama, sebagai contoh, Commvault hanya boleh berfungsi dengan kluster dua nod, di mana Primer dan Secondary diperuntukkan secara ketat kepada nod tertentu. Dan ia hanya masuk akal untuk membuat sandaran daripada Utama, kerana sandaran daripada Menengah mempunyai hadnya. Disebabkan oleh keanehan DBMS, dump tidak dibuat pada Secondary, dan oleh itu hanya kemungkinan sandaran fail kekal.
Untuk mengurangkan risiko masa henti, apabila mencipta sistem toleransi kesalahan, konfigurasi kelompok "langsung" dibuat dan Primary boleh berhijrah secara beransur-ansur antara pelayan yang berbeza. Sebagai contoh, perisian Patroni sendiri melancarkan Primary pada nod kluster yang dipilih secara rawak. IBS tidak mempunyai cara untuk menjejaki perkara ini di luar kotak, dan jika konfigurasi berubah, proses akan pecah. Iaitu, pengenalan kawalan luaran menghalang ISR daripada berfungsi dengan berkesan, kerana pelayan kawalan hanya tidak memahami dari mana dan dari mana data yang perlu disalin.
Masalah lain ialah pelaksanaan sandaran dalam Postgres. Ia boleh dilakukan melalui dump, dan ia berfungsi pada pangkalan data kecil. Tetapi dalam pangkalan data yang besar, pembuangan mengambil masa yang lama, memerlukan banyak sumber dan boleh menyebabkan kegagalan contoh pangkalan data.
Sandaran fail membetulkan keadaan, tetapi pada pangkalan data yang besar ia perlahan kerana ia berfungsi dalam mod satu benang. Di samping itu, vendor mempunyai beberapa sekatan tambahan. Sama ada anda tidak boleh menggunakan fail dan membuang sandaran pada masa yang sama, atau penyahduplikasian tidak disokong. Terdapat banyak masalah, dan selalunya lebih mudah untuk memilih DBMS yang mahal tetapi terbukti berbanding Postgres.
Tiada tempat untuk berundur! Pemaju Moscow berada di belakang!
Walau bagaimanapun, baru-baru ini pasukan kami menghadapi cabaran yang sukar: dalam projek untuk mencipta AIS OSAGO 2.0, di mana kami mencipta infrastruktur IT, pembangun memilih PostgreSQL untuk sistem baharu.
Adalah lebih mudah bagi pembangun perisian besar untuk menggunakan penyelesaian sumber terbuka "bergaya". Facebook mempunyai pakar yang mencukupi untuk menyokong operasi DBMS ini. Dan dalam kes RSA, semua tugas "hari kedua" jatuh ke bahu kami. Kami dikehendaki memastikan toleransi kesalahan, memasang kluster dan, sudah tentu, menyediakan sandaran. Logik tindakan adalah seperti berikut:
- Ajar SRK untuk membuat sandaran daripada nod Utama kluster. Untuk melakukan ini, SRK mesti mencarinya - yang bermaksud penyepaduan dengan satu atau penyelesaian pengurusan kluster PostgreSQL yang lain diperlukan. Dalam kes RSA, perisian Patroni digunakan untuk ini.
- Tentukan jenis sandaran berdasarkan jumlah data dan keperluan pemulihan. Contohnya, apabila anda perlu memulihkan halaman secara berbutir, gunakan dump dan jika pangkalan data adalah besar dan pemulihan berbutir tidak diperlukan, lakukan pada peringkat fail.
- Lampirkan kemungkinan sandaran blok pada penyelesaian untuk membuat salinan sandaran dalam mod berbilang benang.
Pada masa yang sama, kami pada mulanya berhasrat untuk mencipta sistem yang berkesan dan mudah tanpa komponen tambahan yang besar. Semakin sedikit tongkat, semakin sedikit beban kerja pada kakitangan dan semakin rendah risiko kegagalan IBS. Kami segera mengecualikan pendekatan yang menggunakan Veeam dan RMAN, kerana satu set dua penyelesaian sudah menunjukkan ketidakbolehpercayaan sistem.
Sedikit sihir untuk perusahaan
Jadi, kami perlu menjamin sandaran yang boleh dipercayai untuk 10 gugusan 3 nod setiap satu, dengan infrastruktur yang sama dicerminkan dalam pusat data sandaran. Pusat data dari segi PostgreSQL berfungsi pada prinsip aktif-pasif. Jumlah saiz pangkalan data ialah 50 TB. Mana-mana sistem kawalan peringkat korporat boleh mengatasinya dengan mudah. Tetapi kaveatnya ialah pada mulanya Postgres tidak mempunyai petunjuk untuk keserasian penuh dan mendalam dengan sistem sandaran. Oleh itu, kami terpaksa mencari penyelesaian yang pada mulanya mempunyai fungsi maksimum bersama-sama dengan PostgreSQL, dan memperhalusi sistem.
Kami mengadakan 3 "hackathon" dalaman - kami melihat lebih daripada lima puluh perkembangan, mengujinya, membuat perubahan berkaitan dengan hipotesis kami, dan mengujinya semula. Selepas menyemak pilihan yang tersedia, kami memilih Commvault. Di luar kotak, produk ini boleh berfungsi dengan pemasangan kluster PostgreSQL yang paling mudah, dan seni bina terbukanya menimbulkan harapan (yang wajar) untuk pembangunan dan penyepaduan yang berjaya. Commvault juga boleh membuat sandaran log PostgreSQL. Sebagai contoh, Veritas NetBackup dari segi PostgreSQL hanya boleh membuat sandaran penuh.
Lebih lanjut mengenai seni bina. Pelayan pengurusan Commvault telah dipasang di setiap dua pusat data dalam konfigurasi CommServ HA. Sistem ini dicerminkan, diuruskan melalui satu konsol dan, dari sudut pandangan HA, memenuhi semua keperluan perusahaan.
Kami juga melancarkan dua pelayan media fizikal di setiap pusat data, yang kami sambungkan tatasusunan cakera dan perpustakaan pita yang didedikasikan khusus untuk sandaran melalui SAN melalui Saluran Fiber. Pangkalan data deduplikasi lanjutan memastikan toleransi kesalahan pelayan media, dan menyambungkan setiap pelayan ke setiap CSV membolehkan operasi berterusan jika mana-mana komponen gagal. Seni bina sistem membolehkan sandaran diteruskan walaupun salah satu pusat data jatuh.
Patroni mentakrifkan nod Utama untuk setiap kelompok. Ia boleh menjadi sebarang nod percuma dalam pusat data - tetapi kebanyakannya sahaja. Dalam sandaran, semua nod adalah Sekunder.
Untuk membolehkan Commvault memahami nod kelompok mana yang Utama, kami menyepadukan sistem (terima kasih kepada seni bina terbuka penyelesaian) dengan Postgres. Untuk tujuan ini, skrip telah dibuat yang melaporkan lokasi semasa nod Utama kepada pelayan pengurusan Commvault.
Secara umum, prosesnya kelihatan seperti ini:
Patroni memilih Utama β Keepalived mengambil kluster IP dan menjalankan skrip β ejen Commvault pada nod kluster yang dipilih menerima pemberitahuan bahawa ini ialah Primary β Commvault secara automatik mengkonfigurasi semula sandaran dalam klien pseudo.
Kelebihan pendekatan ini ialah penyelesaian tidak menjejaskan ketekalan, ketepatan log, atau pemulihan contoh Postgres. Ia juga mudah berskala, kerana ia tidak lagi perlu untuk membetulkan nod Commvault Primary dan Secondary. Cukuplah bahawa sistem memahami di mana Primary berada, dan bilangan nod boleh ditingkatkan kepada hampir sebarang nilai.
Penyelesaiannya tidak berpura-pura menjadi ideal dan mempunyai nuansa tersendiri. Commvault hanya boleh membuat sandaran keseluruhan contoh, dan bukan pangkalan data individu. Oleh itu, contoh berasingan telah dicipta untuk setiap pangkalan data. Pelanggan sebenar digabungkan menjadi pseudo-klien maya. Setiap pseudo-client Commvault ialah gugusan UNIX. Nod kluster di mana ejen Commvault untuk Postgres dipasang ditambahkan padanya. Akibatnya, semua nod maya pseudo-klien disandarkan sebagai satu contoh.
Dalam setiap pseudo-klien, nod aktif kluster ditunjukkan. Inilah yang ditakrifkan oleh penyelesaian penyepaduan kami untuk Commvault. Prinsip operasinya agak mudah: jika IP kluster dinaikkan pada nod, skrip menetapkan parameter "nod aktif" dalam binari ejen Commvault - sebenarnya, skrip menetapkan "1" dalam bahagian memori yang diperlukan . Ejen menghantar data ini ke CommServe, dan Commvault membuat sandaran daripada nod yang dikehendaki. Selain itu, ketepatan konfigurasi disemak pada peringkat skrip, membantu mengelakkan ralat semasa memulakan sandaran.
Pada masa yang sama, pangkalan data yang besar disandarkan dalam blok merentas berbilang benang, memenuhi keperluan RPO dan tetingkap sandaran. Beban pada sistem adalah tidak penting: Salinan penuh tidak berlaku begitu kerap, pada hari lain hanya log dikumpulkan, dan semasa tempoh beban rendah.
Sebenarnya, kami telah menggunakan dasar berasingan untuk menyandarkan log arkib PostgreSQL - ia disimpan mengikut peraturan yang berbeza, disalin mengikut jadual yang berbeza dan penyahduplikasian tidak didayakan untuk log ini, kerana log ini mengandungi data unik.
Untuk memastikan konsistensi merentas keseluruhan infrastruktur IT, pelanggan fail Commvault yang berasingan dipasang pada setiap nod kluster. Mereka mengecualikan fail Postgres daripada sandaran dan hanya bertujuan untuk sandaran OS dan aplikasi. Bahagian data ini juga mempunyai dasar dan tempoh penyimpanannya sendiri.
Pada masa ini, IBS tidak menjejaskan perkhidmatan produktiviti, tetapi jika keadaan berubah, Commvault boleh mendayakan pengehadan beban.
Ia adalah baik? Baik!
Jadi, kami telah menerima bukan sahaja sandaran yang boleh dilaksanakan, tetapi juga sandaran automatik sepenuhnya untuk pemasangan kluster PostgreSQL, dan ia memenuhi semua keperluan untuk panggilan perusahaan.
Parameter RPO dan RTO selama 1 jam dan 2 jam diliputi dengan margin, yang bermaksud bahawa sistem akan mematuhinya walaupun dengan peningkatan ketara dalam jumlah data yang disimpan. Bertentangan dengan banyak keraguan, PostgreSQL dan persekitaran perusahaan ternyata agak serasi. Dan sekarang kami tahu daripada pengalaman kami sendiri bahawa sandaran untuk DBMS sedemikian boleh dilakukan dalam pelbagai jenis konfigurasi.
Sudah tentu, sepanjang jalan ini kami terpaksa memakai tujuh pasang but besi, mengatasi beberapa kesukaran, memijak beberapa garu dan membetulkan beberapa kesilapan. Tetapi kini pendekatan itu telah pun diuji dan boleh digunakan untuk melaksanakan Sumber Terbuka dan bukannya DBMS proprietari dalam keadaan perusahaan yang teruk.
Pernahkah anda cuba bekerja dengan PostgreSQL dalam persekitaran korporat?
Pengarang:
Oleg Lavrenov, jurutera reka bentuk sistem penyimpanan data, Jet Infosystems
Dmitry Erykin, jurutera reka bentuk sistem komputer di Jet Infosystems
Sumber: www.habr.com