Akeh wong sing kenal karo PostgreSQL DBMS, lan wis mbuktekake dhewe ing instalasi cilik. Nanging, tren menyang Open Source saya tambah jelas, sanajan babagan perusahaan gedhe lan syarat perusahaan. Ing artikel iki kita bakal pitutur marang kowe carane nggabungake Postgres menyang lingkungan perusahaan lan nuduhake pengalaman kita nggawe sistem serep (BSS) kanggo database iki nggunakake sistem serep Commvault minangka conto.
PostgreSQL wis mbuktekake regane - DBMS bisa digunakake kanthi apik, digunakake dening bisnis digital modern kaya Alibaba lan TripAdvisor, lan kekurangan biaya lisensi ndadekake alternatif sing nggodho kanggo monsters kaya MS SQL utawa Oracle DB. Nanging sanalika kita wiwit mikir babagan PostgreSQL ing lanskap Enterprise, kita langsung nemoni syarat sing ketat: "Apa babagan toleransi kesalahan konfigurasi? tahan bencana? ngendi pemantauan lengkap? Apa babagan serep otomatis? Kepiye nggunakake perpustakaan tape kanthi langsung lan ing panyimpenan sekunder?
Ing sisih siji, PostgreSQL ora duwe alat serep sing dibangun, kaya DBMS "diwasa" kayata RMAN ing Oracle DB utawa SAP Database Backup. Ing tangan liyane, supplier saka sistem serep perusahaan (Veeam, Veritas, Commvault) sanajan padha ndhukung PostgreSQL, nyatane mung bisa karo tartamtu (biasane dewekan) konfigurasi lan karo pesawat saka macem-macem watesan.
Sistem serep sing dirancang khusus kanggo PostgreSQL, kayata Barman, Wal-g, pg_probackup, populer banget ing panginstalan cilik PostgreSQL DBMS utawa ing ngendi serep unsur liyane ing lanskap IT ora dibutuhake. Contone, saliyane PostgreSQL, infrastruktur bisa uga kalebu server fisik lan virtual, OpenShift, Oracle, MariaDB, Cassandra, lsp. Disaranake gawe serep kabeh iki nganggo alat umum. Nginstal solusi sing kapisah khusus kanggo PostgreSQL minangka ide sing ala: data bakal disalin nang endi wae menyang disk, banjur kudu dicopot menyang tape. Serep pindho iki nambah wektu serep, lan uga, luwih kritis, wektu pemulihan.
Ing solusi perusahaan, serep instalasi ditindakake kanthi nomer simpul tartamtu ing kluster khusus. Ing wektu sing padha, contone, Commvault mung bisa digunakake karo kluster loro-simpul, kang Primary lan Secondary strictly diutus kanggo kelenjar tartamtu. Lan mung nggawe serep saka Primary, amarga cadangan saka Secondary duwe watesan. Amarga kekhasan DBMS, dump ora digawe ing Secondary, lan mulane mung ana kemungkinan cadangan file.
Kanggo nyuda resiko downtime, nalika nggawe sistem fault-tolerant, digawe konfigurasi cluster "urip", lan Primary mboko sithik migrasi antarane server beda. Contone, piranti lunak Patroni dhewe ngluncurake Primary ing simpul kluster sing dipilih kanthi acak. IBS ora duwe cara kanggo nglacak iki metu saka kothak, lan yen konfigurasi diganti, proses break. Tegese, introduksi kontrol eksternal nyegah ISR bisa digunakake kanthi efektif, amarga server kontrol mung ora ngerti ngendi lan data apa sing kudu disalin.
Masalah liyane yaiku implementasine serep ing Postgres. Bisa liwat mbucal, lan kerjane ing database cilik. Nanging ing basis data gedhe, mbucal butuh wektu suwe, mbutuhake sumber daya sing akeh lan bisa nyebabake kegagalan conto database.
File serep mbenerake kahanan, nanging ing database gedhe iku alon amarga bisa ing mode single-threaded. Kajaba iku, vendor duwe sawetara watesan tambahan. Sampeyan ora bisa nggunakake file lan mbucal serep bebarengan, utawa deduplication ora didhukung. Ana akeh masalah, lan paling asring luwih gampang milih DBMS sing larang nanging wis kabukten tinimbang Postgres.
Ora ana papan kanggo mundur! pangembang Moscow konco!
Nanging, bubar tim kita ngadhepi tantangan sing angel: ing proyek nggawe AIS OSAGO 2.0, ing ngendi kita nggawe infrastruktur IT, para pangembang milih PostgreSQL kanggo sistem anyar.
Luwih gampang kanggo pangembang piranti lunak gedhe nggunakake solusi open-source "trendi". Facebook duwe spesialis sing cukup kanggo ndhukung operasi DBMS iki. Lan ing kasus RSA, kabeh tugas "dina kapindho" tiba ing pundhak kita. Kita dibutuhake kanggo njamin toleransi kesalahan, ngumpulake kluster lan, mesthi, nyiyapake serep. Logika tumindak kaya ing ngisor iki:
- Ajar SRK nggawe serep saka simpul utami kluster. Kanggo nindakake iki, SRK kudu nemokake - tegese integrasi karo siji utawa solusi manajemen kluster PostgreSQL dibutuhake. Ing kasus RSA, piranti lunak Patroni digunakake kanggo iki.
- Temtokake jinis serep adhedhasar volume data lan syarat pemulihan. Contone, yen sampeyan kudu mulihake kaca kanthi granular, gunakake dump, lan yen database gedhe lan pemugaran granular ora dibutuhake, kerja ing tingkat file.
- Lampirake kamungkinan pamblokiran serep menyang solusi kanggo nggawe salinan serep ing mode multi-Utas.
Ing wektu sing padha, kita miwiti nggawe sistem sing efektif lan prasaja tanpa sabuk komponen tambahan. Kurang crutches, kurang beban kerja ing staf lan luwih murah risiko gagal IBS. Kita langsung ngilangi pendekatan sing nggunakake Veeam lan RMAN, amarga rong solusi wis menehi tandha manawa sistem kasebut ora bisa dipercaya.
A sihir sethitik kanggo perusahaan
Dadi, kita kudu njamin serep sing dipercaya kanggo 10 kluster 3 simpul saben, kanthi infrastruktur sing padha dicerminake ing pusat data serep. Pusat data babagan PostgreSQL makarya ing prinsip aktif-pasif. Ukuran database total 50 TB. Sembarang sistem kontrol tingkat perusahaan bisa gampang ngatasi iki. Nanging caveat yaiku wiwitane Postgres ora duwe pitunjuk babagan kompatibilitas lengkap lan jero karo sistem serep. Mulane, kita kudu nggoleki solusi sing wiwitane nduweni fungsi maksimal bebarengan karo PostgreSQL, lan nyaring sistem kasebut.
Kita nganakake 3 "hackathon" internal - kita ndeleng luwih saka sèket pangembangan, nguji, nggawe owah-owahan sing ana gandhengane karo hipotesis kita, lan nyoba maneh. Sawise mriksa pilihan sing kasedhiya, kita milih Commvault. Out of the box, prodhuk iki bisa digunakake karo instalasi kluster PostgreSQL sing paling gampang, lan arsitektur sing mbukak ndadékaké pangarep-arep (sing dibenerake) kanggo pangembangan lan integrasi sing sukses. Commvault uga bisa nggawe cadangan log PostgreSQL. Contone, Veritas NetBackup babagan PostgreSQL mung bisa nggawe serep lengkap.
Liyane babagan arsitektur. Server manajemen Commvault diinstal ing saben loro pusat data ing konfigurasi CommServ HA. Sistem kasebut dicerminake, dikelola liwat siji konsol lan, saka sudut pandang HA, nyukupi kabeh syarat perusahaan.
Kita uga ngluncurake loro server media fisik ing saben pusat data, sing disambungake susunan disk lan perpustakaan tape khusus kanggo serep liwat SAN liwat Fiber Channel. Basis data deduplikasi sing diperluas njamin toleransi kesalahan server media, lan nyambungake saben server menyang saben CSV ngaktifake operasi terus yen ana komponen sing gagal. Arsitèktur sistem ngidini serep terus sanajan salah sawijining pusat data tiba.
Patroni nemtokake simpul Primer kanggo saben kluster. Bisa wae simpul gratis ing pusat data - nanging mung umume. Ing serep, kabeh simpul Sekunder.
Supaya Commvault mangertos simpul kluster sing Primary, kita nggabungake sistem kasebut (berkat arsitektur mbukak solusi) karo Postgres. Kanggo maksud iki, skrip digawe sing nglaporake lokasi saiki simpul Utama menyang server manajemen Commvault.
UmumΓ©, proses katon kaya iki:
Patroni milih Utama β Keepalived ngangkat kluster IP lan mbukak skrip β agen Commvault ing simpul kluster sing dipilih nampa kabar yen iki Primer β Commvault kanthi otomatis ngonfigurasi ulang serep ing klien pseudo.
Kauntungan saka pendekatan iki yaiku solusi kasebut ora mengaruhi konsistensi, akurasi log, utawa pulih saka conto Postgres. Iku uga gampang keukur, amarga iku ora perlu kanggo ndandani Commvault Primer lan Secondary kelenjar. Iku cukup sing sistem mangertΓ©ni ngendi Primary punika, lan nomer kelenjar bisa tambah kanggo meh wae Nilai.
Solusi kasebut ora nyamar dadi ideal lan duwe nuansa dhewe. Commvault mung bisa nggawe serep kabeh conto, lan dudu database individu. Mulane, conto sing kapisah digawe kanggo saben database. Klien nyata digabungake dadi klien pseudo virtual. Saben pseudo-klien Commvault minangka kluster UNIX. Node kluster sing diinstal agen Commvault kanggo Postgres ditambahake. AkibatΓ©, kabeh simpul virtual saka pseudo-klien digawe serep minangka siji conto.
Ing saben pseudo-klien, simpul aktif kluster dituduhake. Iki minangka solusi integrasi kita kanggo Commvault. Prinsip operasi kasebut cukup prasaja: yen IP kluster diunggahake ing simpul, skrip nyetel parameter "simpul aktif" ing binar agen Commvault - nyatane, skrip nyetel "1" ing bagean memori sing dibutuhake. . Agen ngirim data iki menyang CommServe, lan Commvault nggawe serep saka simpul sing dikarepake. Kajaba iku, kabeneran konfigurasi dicenthang ing tingkat skrip, mbantu supaya ora ana kesalahan nalika miwiti serep.
Ing wektu sing padha, database gedhe digawe serep ing pamblokiran liwat macem-macem Utas, ketemu RPO lan serep syarat jendhela. Beban ing sistem ora pati penting: Salinan lengkap ora kedadeyan asring, ing dina liyane mung log sing diklumpukake, lan sajrone wektu beban sing sithik.
Miturut cara, kita wis ngetrapake kabijakan sing kapisah kanggo nggawe serep log arsip PostgreSQL - disimpen miturut aturan sing beda-beda, disalin miturut jadwal sing beda, lan deduplikasi ora diaktifake, amarga log kasebut ngemot data unik.
Kanggo njamin konsistensi ing kabeh infrastruktur IT, klien file Commvault sing kapisah diinstal ing saben simpul kluster. Dheweke ora kalebu file Postgres saka serep lan mung kanggo serep OS lan aplikasi. Bagean data iki uga nduweni kabijakan lan periode panyimpenan dhewe.
Saiki, IBS ora mengaruhi layanan produktivitas, nanging yen kahanan diganti, Commvault bisa ngaktifake watesan beban.
Apa iku apik? apik!
Dadi, kita wis nampa ora mung bisa, nanging uga serep kanthi otomatis kanggo instalasi kluster PostgreSQL, lan meets kabeh syarat kanggo telpon perusahaan.
Parameter RPO lan RTO 1 jam lan 2 jam ditutupi wates, tegese sistem kasebut bakal tundhuk sanajan ana paningkatan volume data sing disimpen. Beda karo akeh keraguan, PostgreSQL lan lingkungan perusahaan dadi cukup kompatibel. Lan saiki kita ngerti saka pengalaman kita dhewe yen serep kanggo DBMS kuwi bisa ing macem-macem konfigurasi.
Mesthi, ing dalan iki kita kudu nyandhang pitung pasang boots wesi, ngatasi sawetara kangelan, langkah ing sawetara rake lan mbenerake sawetara kesalahane. Nanging saiki pendekatan kasebut wis diuji lan bisa digunakake kanggo ngetrapake Open Source tinimbang DBMS kepemilikan ing kahanan perusahaan sing angel.
Apa sampeyan wis nyoba nggarap PostgreSQL ing lingkungan perusahaan?
Penulis:
Oleg Lavrenov, insinyur desain sistem panyimpenan data, Jet Infosystems
Dmitry Erykin, insinyur desain sistem komputer ing Jet Infosystems
Source: www.habr.com