Banyak orang yang familiar dengan DBMS PostgreSQL, dan telah membuktikan dirinya dalam instalasi kecil. Namun, tren menuju Open Source menjadi semakin jelas, bahkan ketika menyangkut kebutuhan perusahaan dan perusahaan besar. Pada artikel ini kami akan memberi tahu Anda cara mengintegrasikan Postgres ke dalam lingkungan perusahaan dan berbagi pengalaman kami dalam membuat sistem cadangan (BSS) untuk database ini menggunakan sistem cadangan Commvault sebagai contoh.
PostgreSQL telah membuktikan manfaatnya - DBMS berfungsi dengan baik, digunakan oleh bisnis digital modis seperti Alibaba dan TripAdvisor, dan kurangnya biaya lisensi menjadikannya alternatif yang menggiurkan dibandingkan monster seperti MS SQL atau Oracle DB. Namun begitu kami mulai memikirkan PostgreSQL di lanskap Perusahaan, kami langsung dihadapkan pada persyaratan yang ketat: “Bagaimana dengan toleransi kesalahan konfigurasi? ketahanan terhadap bencana? dimana pemantauan komprehensifnya? Bagaimana dengan pencadangan otomatis? Bagaimana dengan menggunakan perpustakaan tape baik secara langsung maupun pada penyimpanan sekunder?”
Di satu sisi, PostgreSQL tidak memiliki alat pencadangan bawaan, seperti DBMS “dewasa” seperti RMAN di Oracle DB atau SAP Database Backup. Di sisi lain, pemasok sistem cadangan perusahaan (Veeam, Veritas, Commvault) meskipun mendukung PostgreSQL, pada kenyataannya mereka hanya bekerja dengan konfigurasi tertentu (biasanya mandiri) dan dengan serangkaian batasan yang berbeda.
Sistem cadangan yang dirancang khusus untuk PostgreSQL, seperti Barman, Wal-g, pg_probackup, sangat populer dalam instalasi kecil DBMS PostgreSQL atau ketika cadangan besar elemen lanskap TI lainnya tidak diperlukan. Misalnya, selain PostgreSQL, infrastrukturnya mungkin mencakup server fisik dan virtual, OpenShift, Oracle, MariaDB, Cassandra, dll. Dianjurkan untuk membuat cadangan semua ini dengan alat yang umum. Menginstal solusi terpisah khusus untuk PostgreSQL adalah ide yang buruk: data akan disalin ke suatu tempat ke disk, dan kemudian harus dihapus ke tape. Pencadangan ganda ini meningkatkan waktu pencadangan, dan yang lebih penting, waktu pemulihan.
Dalam solusi perusahaan, pencadangan instalasi terjadi dengan sejumlah node tertentu dalam cluster khusus. Pada saat yang sama, misalnya, Commvault hanya dapat bekerja dengan cluster dua node, di mana Primer dan Sekunder ditetapkan secara ketat ke node tertentu. Dan masuk akal untuk melakukan pencadangan dari Primer, karena pencadangan dari Sekunder memiliki keterbatasan. Karena kekhasan DBMS, dump tidak dibuat di Sekunder, dan oleh karena itu hanya kemungkinan pencadangan file yang tersisa.
Untuk mengurangi risiko waktu henti, saat membuat sistem yang toleran terhadap kesalahan, konfigurasi cluster "langsung" dibuat, dan Primer dapat bermigrasi secara bertahap antar server yang berbeda. Misalnya, perangkat lunak Patroni sendiri meluncurkan Primer pada node cluster yang dipilih secara acak. IBS tidak memiliki cara untuk melacak hal ini, dan jika konfigurasi berubah, prosesnya akan terhenti. Artinya, pengenalan kontrol eksternal mencegah ISR bekerja secara efektif, karena server kontrol tidak memahami dari mana dan data apa yang perlu disalin.
Masalah lainnya adalah implementasi backup di Postgres. Hal ini dimungkinkan melalui dump, dan berfungsi pada database kecil. Namun dalam database yang besar, dump memerlukan waktu yang lama, memerlukan banyak sumber daya, dan dapat mengakibatkan kegagalan instance database.
Pencadangan file memperbaiki situasi ini, tetapi pada database besar, pencadangannya lambat karena bekerja dalam mode single-threaded. Selain itu, vendor memiliki sejumlah batasan tambahan. Mungkin Anda tidak dapat menggunakan cadangan file dan dump secara bersamaan, atau deduplikasi tidak didukung. Ada banyak masalah, dan seringkali lebih mudah untuk memilih DBMS yang mahal namun terbukti daripada Postgres.
Tidak ada tempat untuk mundur! Pengembang Moskow tertinggal!
Namun, baru-baru ini tim kami menghadapi tantangan yang sulit: dalam proyek pembuatan AIS OSAGO 2.0, tempat kami membuat infrastruktur TI, para pengembang memilih PostgreSQL untuk sistem baru.
Jauh lebih mudah bagi pengembang perangkat lunak besar untuk menggunakan solusi sumber terbuka yang “trendi”. Facebook memiliki cukup banyak spesialis untuk mendukung pengoperasian DBMS ini. Dan dalam kasus RSA, semua tugas “hari kedua” berada di pundak kami. Kami diminta untuk memastikan toleransi kesalahan, merakit cluster dan, tentu saja, menyiapkan cadangan. Logika tindakannya adalah sebagai berikut:
- Ajari SRK untuk membuat cadangan dari node Utama cluster. Untuk melakukan ini, SRK harus menemukannya - yang berarti diperlukan integrasi dengan satu atau beberapa solusi manajemen cluster PostgreSQL. Dalam kasus RSA, perangkat lunak Patroni digunakan untuk ini.
- Tentukan jenis cadangan berdasarkan volume data dan persyaratan pemulihan. Misalnya, ketika Anda perlu memulihkan halaman secara terperinci, gunakan dump, dan jika database berukuran besar dan pemulihan terperinci tidak diperlukan, bekerjalah di tingkat file.
- Lampirkan kemungkinan blok cadangan ke solusi untuk membuat salinan cadangan dalam mode multi-utas.
Pada saat yang sama, kami pada awalnya bertujuan untuk menciptakan sistem yang efektif dan sederhana tanpa menggunakan komponen tambahan yang berlebihan. Semakin sedikit kruk, semakin sedikit beban kerja staf dan semakin rendah risiko kegagalan IBS. Kami segera mengecualikan pendekatan yang menggunakan Veeam dan RMAN, karena serangkaian dua solusi sudah mengisyaratkan tidak dapat diandalkannya sistem.
Sedikit keajaiban untuk perusahaan
Jadi, kami perlu menjamin pencadangan yang andal untuk 10 cluster yang masing-masing terdiri dari 3 node, dengan infrastruktur yang sama dicerminkan di pusat data cadangan. Pusat data dalam hal PostgreSQL bekerja berdasarkan prinsip aktif-pasif. Total ukuran basis data adalah 50 TB. Sistem kendali tingkat perusahaan mana pun dapat dengan mudah mengatasi hal ini. Namun peringatannya adalah pada awalnya Postgres tidak memiliki petunjuk tentang kompatibilitas penuh dan mendalam dengan sistem cadangan. Oleh karena itu, kami harus mencari solusi yang awalnya memiliki fungsionalitas maksimal bersama dengan PostgreSQL, dan menyempurnakan sistemnya.
Kami mengadakan 3 “hackathon” internal - kami melihat lebih dari lima puluh perkembangan, mengujinya, membuat perubahan sehubungan dengan hipotesis kami, dan mengujinya lagi. Setelah meninjau opsi yang tersedia, kami memilih Commvault. Secara langsung, produk ini dapat bekerja dengan instalasi cluster PostgreSQL yang paling sederhana, dan arsitektur terbukanya meningkatkan harapan (yang memang beralasan) untuk keberhasilan pengembangan dan integrasi. Commvault juga dapat mencadangkan log PostgreSQL. Misalnya Veritas NetBackup dalam hal PostgreSQL hanya dapat membuat cadangan penuh.
Lebih lanjut tentang arsitektur. Server manajemen Commvault dipasang di masing-masing dua pusat data dalam konfigurasi CommServ HA. Sistem ini dicerminkan, dikelola melalui satu konsol dan, dari sudut pandang HA, memenuhi semua persyaratan perusahaan.
Kami juga meluncurkan dua server media fisik di setiap pusat data, tempat kami menghubungkan array disk dan perpustakaan tape yang didedikasikan khusus untuk pencadangan melalui SAN melalui Fibre Channel. Basis data deduplikasi yang diperluas memastikan toleransi kesalahan server media, dan menghubungkan setiap server ke setiap CSV memungkinkan operasi berkelanjutan jika ada komponen yang gagal. Arsitektur sistem memungkinkan pencadangan terus berlanjut meskipun salah satu pusat data rusak.
Patroni mendefinisikan node Utama untuk setiap cluster. Ini bisa berupa node gratis mana pun di pusat data - tetapi hanya sebagian besar. Di cadangan, semua node adalah Sekunder.
Agar Commvault memahami node cluster mana yang merupakan Primer, kami mengintegrasikan sistem (berkat arsitektur solusi terbuka) dengan Postgres. Untuk tujuan ini, skrip dibuat yang melaporkan lokasi node Utama saat ini ke server manajemen Commvault.
Secara umum, prosesnya terlihat seperti ini:
Patroni memilih Primer → Keepalived mengambil cluster IP dan menjalankan skrip → agen Commvault pada node cluster yang dipilih menerima pemberitahuan bahwa ini adalah Primer → Commvault secara otomatis mengkonfigurasi ulang cadangan dalam klien semu.
Keuntungan dari pendekatan ini adalah solusinya tidak mempengaruhi konsistensi, kebenaran log, atau pemulihan instance Postgres. Ini juga mudah diskalakan, karena tidak perlu lagi memperbaiki node Commvault Primer dan Sekunder. Sistem cukup memahami di mana Primer berada, dan jumlah node dapat ditingkatkan ke hampir nilai apa pun.
Solusinya tidak berpura-pura ideal dan memiliki nuansa tersendiri. Commvault hanya dapat mencadangkan seluruh instans, dan bukan database individual. Oleh karena itu, contoh terpisah dibuat untuk setiap database. Klien nyata digabungkan menjadi klien semu virtual. Setiap klien semu Commvault adalah kluster UNIX. Node cluster tempat agen Commvault untuk Postgres diinstal ditambahkan ke dalamnya. Hasilnya, semua node virtual klien semu dicadangkan sebagai satu instance.
Dalam setiap klien semu, node aktif cluster ditunjukkan. Inilah yang didefinisikan oleh solusi integrasi kami untuk Commvault. Prinsip operasinya cukup sederhana: jika IP cluster dimunculkan pada sebuah node, skrip menetapkan parameter "node aktif" dalam biner agen Commvault - sebenarnya, skrip menetapkan "1" di bagian memori yang diperlukan . Agen mengirimkan data ini ke CommServe, dan Commvault membuat cadangan dari node yang diinginkan. Selain itu, kebenaran konfigurasi diperiksa pada tingkat skrip, membantu menghindari kesalahan saat memulai pencadangan.
Pada saat yang sama, database besar dicadangkan dalam blok di beberapa thread, memenuhi persyaratan RPO dan jendela pencadangan. Beban pada sistem tidak signifikan: Salinan lengkap tidak sering terjadi, pada hari-hari lain hanya log yang dikumpulkan, dan selama periode beban rendah.
Omong-omong, kami telah menerapkan kebijakan terpisah untuk mencadangkan log arsip PostgreSQL - log tersebut disimpan menurut aturan yang berbeda, disalin menurut jadwal yang berbeda, dan deduplikasi tidak diaktifkan untuk log tersebut, karena log ini berisi data unik.
Untuk memastikan konsistensi di seluruh infrastruktur TI, klien file Commvault terpisah diinstal pada setiap node cluster. Mereka mengecualikan file Postgres dari cadangan dan hanya ditujukan untuk cadangan OS dan aplikasi. Bagian data ini juga memiliki kebijakan dan jangka waktu penyimpanannya sendiri.
Saat ini, IBS tidak memengaruhi layanan produktivitas, namun jika situasinya berubah, Commvault dapat mengaktifkan pembatasan beban.
Apakah itu bagus? Bagus!
Jadi, kami tidak hanya menerima cadangan yang bisa diterapkan, tetapi juga cadangan yang sepenuhnya otomatis untuk instalasi cluster PostgreSQL, dan memenuhi semua persyaratan untuk panggilan perusahaan.
Parameter RPO dan RTO 1 jam dan 2 jam ditutupi dengan margin, yang berarti sistem akan mematuhinya bahkan dengan peningkatan volume data yang disimpan secara signifikan. Bertentangan dengan banyak keraguan, PostgreSQL dan lingkungan perusahaan ternyata cukup kompatibel. Dan sekarang kita tahu dari pengalaman kita sendiri bahwa pencadangan untuk DBMS semacam itu dapat dilakukan dalam berbagai konfigurasi.
Tentu saja, dalam perjalanan ini kami harus memakai tujuh pasang sepatu bot besi, mengatasi sejumlah kesulitan, menginjak beberapa garu dan memperbaiki sejumlah kesalahan. Namun sekarang pendekatan tersebut telah diuji dan dapat digunakan untuk mengimplementasikan Open Source dibandingkan DBMS berpemilik dalam kondisi perusahaan yang sulit.
Sudahkah Anda mencoba bekerja dengan PostgreSQL di lingkungan perusahaan?
Penulis:
Oleg Lavrenov, insinyur desain sistem penyimpanan data, Jet Infosystems
Dmitry Erykin, insinyur desain sistem komputer di Jet Infosystems
Sumber: www.habr.com