Multaj homoj konas la PostgreSQL-DBMS, kaj ĝi pruvis sin en malgrandaj instalaĵoj. Tamen, la tendenco al Malferma Fonto fariĝis ĉiam pli klara, eĉ se temas pri grandaj kompanioj kaj entreprenaj postuloj. En ĉi tiu artikolo ni diros al vi kiel integri Postgres en kompanian medion kaj dividi nian sperton pri kreado de rezerva sistemo (BSS) por ĉi tiu datumbazo uzante la Commvault rezervan sistemon kiel ekzemplon.
PostgreSQL jam pruvis sian valoron - la DBMS funkcias bonege, ĝi estas uzata de modaj ciferecaj entreprenoj kiel Alibaba kaj TripAdvisor, kaj la manko de licencaj kotizoj faras ĝin tenta alternativo al tiaj monstroj kiel MS SQL aŭ Oracle DB. Sed tuj kiam ni ekpensas pri PostgreSQL en la Enterprise-pejzaĝo, ni tuj renkontas striktajn postulojn: "Kion pri agorda misfunkciadotoleremo? katastroforezisto? kie estas la ampleksa monitorado? Kio pri aŭtomataj sekurkopioj? Kio pri uzado de bendbibliotekoj kaj rekte kaj sur sekundara stokado?"
Unuflanke, PostgreSQL ne havas enkonstruitajn rezervajn ilojn, kiel "plenkreskaj" DBMS kiel ekzemple RMAN en Oracle DB aŭ SAP Database Backup. Aliflanke, provizantoj de kompaniaj rezervaj sistemoj (Veeam, Veritas, Commvault) kvankam ili subtenas PostgreSQL, fakte ili funkcias nur kun certa (kutime memstara) agordo kaj kun aro de diversaj limigoj.
Rezervsistemoj speciale dizajnitaj por PostgreSQL, kiel ekzemple Barman, Wal-g, pg_probackup, estas ekstreme popularaj en malgrandaj instalaĵoj de la PostgreSQL DBMS aŭ kie pezaj sekurkopioj de aliaj elementoj de la IT-pejzaĝo ne estas bezonataj. Ekzemple, krom PostgreSQL, la infrastrukturo povas inkluzivi fizikajn kaj virtualajn servilojn, OpenShift, Oracle, MariaDB, Cassandra, ktp. Estas konsilinde konservi ĉion ĉi per komuna ilo. Instali apartan solvon ekskluzive por PostgreSQL estas malbona ideo: la datumoj estos kopiitaj ie al disko, kaj tiam ĝi devas esti forigita al sonbendo. Ĉi tiu duobla sekurkopio pliigas la sekurkopion, kaj ankaŭ, pli kritike, la reakirotempon.
En entreprena solvo, sekurkopio de la instalado okazas kun certa nombro da nodoj en dediĉita areto. Samtempe, ekzemple, Commvault povas funkcii nur kun du-noda areto, en kiu Primaraj kaj Sekundaraj estas strikte asignitaj al certaj nodoj. Kaj estas nur senco al sekurkopio de Primara, ĉar sekurkopio de Sekundara havas siajn limigojn. Pro la proprecoj de la DBMS, rubejo ne estas kreita sur Sekundara, kaj tial nur la ebleco de dosierrezervo restas.
Por redukti la riskon de malfunkcio, dum kreado de mistolerema sistemo, "viva" cluster-agordo estas kreita, kaj Primary povas iom post iom migri inter malsamaj serviloj. Ekzemple, Patroni-programaro mem lanĉas Primary sur hazarde elektita aretnodo. La IBS ne havas manieron spuri ĉi tion el la skatolo, kaj se la agordo ŝanĝiĝas, la procezoj rompas. Tio estas, la enkonduko de ekstera kontrolo malhelpas la ISR funkcii efike, ĉar la kontrolservilo simple ne komprenas de kie kaj kiaj datumoj devas esti kopiitaj.
Alia problemo estas la efektivigo de sekurkopio en Postgres. Ĝi eblas per dump, kaj ĝi funkcias sur malgrandaj datumbazoj. Sed en grandaj datumbazoj, la rubejo daŭras longan tempon, postulas multajn rimedojn kaj povas kaŭzi malsukceson de la datumbaza petskribo.
Dosiera sekurkopio korektas la situacion, sed ĉe grandaj datumbazoj ĝi estas malrapida ĉar ĝi funkcias en unufadena reĝimo. Krome, vendistoj havas kelkajn kromajn restriktojn. Aŭ vi ne povas uzi dosierajn kaj forĵetajn sekurkopiojn samtempe, aŭ deduplikado ne estas subtenata. Estas multaj problemoj, kaj plej ofte estas pli facile elekti multekostan sed provitan DBMS anstataŭ Postgres.
Estas nenie por retiriĝi! Moskvaj programistoj estas malantaŭe!
Tamen lastatempe nia teamo alfrontis malfacilan defion: en la projekto krei AIS OSAGO 2.0, kie ni kreis la IT-infrastrukturon, la programistoj elektis PostgreSQL por la nova sistemo.
Estas multe pli facile por grandaj programistoj uzi "modajn" malfermfontajn solvojn. Facebook havas sufiĉe da specialistoj por subteni la funkciadon de ĉi tiu DBMS. Kaj en la kazo de RSA, ĉiuj taskoj de la "dua tago" falis sur niajn ŝultrojn. Ni estis postulataj certigi misfunkciadon, kunmeti areton kaj, kompreneble, starigi sekurkopion. La logiko de ago estis jena:
- Instruu la SRK fari sekurkopiojn de la Ĉefa nodo de la areto. Por fari tion, la SRK devas trovi ĝin - kio signifas ke integriĝo kun unu aŭ alia PostgreSQL-clusteradministradsolvo necesas. En la kazo de RSA, Patroni-programaro estis uzita por tio.
- Decidi pri la tipo de sekurkopio bazita sur la volumo de datumoj kaj reakiro postuloj. Ekzemple, kiam vi bezonas restarigi paĝojn grajne, uzu rubejon, kaj se la datumbazoj estas grandaj kaj granula restarigo ne necesas, laboru ĉe la dosiernivelo.
- Aligu la eblecon de bloka sekurkopio al la solvo por krei rezervan kopion en multfadena reĝimo.
Samtempe, ni komence komencis krei efikan kaj simplan sistemon sen monstra jungilaro de pliaj komponantoj. Ju malpli da lambastonoj, des malpli da laborŝarĝo de dungitaro kaj des pli malalta risko de IBS-malsukceso. Ni tuj ekskludis alirojn, kiuj uzis Veeam kaj RMAN, ĉar aro de du solvoj jam sugestas la nefidindecon de la sistemo.
Iom da magio por entrepreno
Do, ni bezonis garantii fidindan sekurkopion por 10 aretoj de 3 nodoj ĉiu, kun la sama infrastrukturo spegulita en la rezerva datumcentro. Datumcentroj laŭ PostgreSQL funkcias laŭ la aktiva-pasiva principo. La totala datumbazo estis 50 TB. Ajna kompania-nivela kontrolsistemo povas facile trakti ĉi tion. Sed la averto estas, ke komence Postgres ne havas indicon pri plena kaj profunda kongruo kun rezervaj sistemoj. Tial ni devis serĉi solvon, kiu komence havis maksimuman funkciecon kune kun PostgreSQL, kaj rafini la sistemon.
Ni okazigis 3 internajn "hakatonojn" - ni rigardis pli ol kvindek evoluojn, testis ilin, faris ŝanĝojn lige kun niaj hipotezoj, kaj testis ilin denove. Post revizii la disponeblajn elektojn, ni elektis Commvault. Ekstere de la skatolo, ĉi tiu produkto povis funkcii kun la plej simpla PostgreSQL-clusterinstalado, kaj ĝia malferma arkitekturo levis esperojn (kiuj estis pravigitaj) por sukcesa disvolviĝo kaj integriĝo. Commvault ankaŭ povas sekurkopii PostgreSQL-protokolojn. Ekzemple, Veritas NetBackup laŭ PostgreSQL povas nur fari plenajn sekurkopiojn.
Pli pri arkitekturo. Commvault-administradserviloj estis instalitaj en ĉiu el la du datencentroj en CommServ HA-konfiguracio. La sistemo estas spegulita, administrita per unu konzolo kaj, de la vidpunkto de HA, plenumas ĉiujn entreprenajn postulojn.
Ni ankaŭ lanĉis du fizikajn amaskomunikilajn servilojn en ĉiu datumcentro, al kiuj ni konektis disko-tabelojn kaj bendbibliotekojn dediĉitajn specife por sekurkopioj per SAN per Fibra Kanalo. Plilongigitaj deduplikadaj datumbazoj certigis faŭltoleremon de amaskomunikilaj serviloj, kaj konekti ĉiun servilon al ĉiu CSV ebligis kontinuan operacion se iu komponento malsukcesis. La sistema arkitekturo permesas sekurkopion daŭri eĉ se unu el la datumcentroj falas.
Patroni difinas Primaran nodon por ĉiu areto. Ĝi povas esti ajna libera nodo en la datumcentro - sed nur plejparte. En la sekurkopio, ĉiuj nodoj estas Malĉefaj.
Por ke Commvault komprenu, kiu clusternodo estas Ĉefa, ni integris la sistemon (danke al la malferma arkitekturo de la solvo) kun Postgres. Por ĉi tiu celo, skripto estis kreita, kiu raportas la nunan lokon de la Ĉefa nodo al la administradservilo de Commvault.
Ĝenerale, la procezo aspektas jene:
Patroni elektas Primaran → Keepalived prenas la IP-areton kaj rulas la skripton → la Commvault-agento sur la elektita grapolnodo ricevas sciigon, ke ĉi tio estas la Ĉefa → Commvault aŭtomate reagordas la sekurkopion ene de la pseŭdo-kliento.
La avantaĝo de ĉi tiu aliro estas, ke la solvo ne influas la konsistencon, ĝustecon de protokoloj aŭ reakiron de la petskribo de Postgres. Ĝi ankaŭ estas facile skalebla, ĉar ne plu necesas ripari la Commvault Primarajn kaj Malĉefajn nodojn. Sufiĉas, ke la sistemo komprenu, kie Ĉefa estas, kaj la nombro da nodoj povas esti pliigita al preskaŭ ajna valoro.
La solvo ne ŝajnigas esti ideala kaj havas siajn proprajn nuancojn. Commvault povas nur sekurkopii la tutan petskribon, kaj ne individuajn datumbazojn. Tial, aparta kazo estis kreita por ĉiu datumbazo. Realaj klientoj estas kombinitaj en virtualajn pseŭdo-klientojn. Ĉiu pseŭdokliento de Commvault estas UNIX-areto. Tiuj clusternodoj sur kiuj la Commvault-agento por Postgres estas instalita estas aldonitaj al ĝi. Kiel rezulto, ĉiuj virtualaj nodoj de la pseŭdo-kliento estas sekurkopiitaj kiel unu kazo.
Ene de ĉiu pseŭdo-kliento, la aktiva nodo de la areto estas indikita. Jen kion difinas nia integriga solvo por Commvault. La principo de ĝia funkciado estas sufiĉe simpla: se areto IP estas levita sur nodo, la skripto metas la "aktivan nodon" parametron en la Commvault-agenta binaro - fakte, la skripto metas "1" en la bezonata parto de la memoro. . La agento transdonas ĉi tiujn datumojn al CommServe, kaj Commvault faras sekurkopion de la dezirata nodo. Krome, la ĝusteco de la agordo estas kontrolita ĉe la skriptonivelo, helpante eviti erarojn dum komencado de sekurkopio.
Samtempe, grandaj datumbazoj estas konservitaj en blokoj tra pluraj fadenoj, plenumante RPO kaj rezervajn fenestropostulojn. La ŝarĝo sur la sistemo estas sensignifa: Plenaj kopioj ne okazas tiel ofte, en aliaj tagoj nur ŝtipoj estas kolektitaj, kaj dum periodoj de malalta ŝarĝo.
Cetere, ni aplikis apartajn politikojn por sekurigi PostgreSQL-arkivajn protokolojn - ili estas konservitaj laŭ malsamaj reguloj, kopiitaj laŭ malsama horaro, kaj deduplikado ne estas ebligita por ili, ĉar ĉi tiuj protokoloj enhavas unikajn datumojn.
Por certigi konsistencon tra la tuta IT-infrastrukturo, apartaj dosierklientoj de Commvault estas instalitaj sur ĉiu el la grapolnodoj. Ili ekskludas Postgres-dosierojn de sekurkopioj kaj estas destinitaj nur por sekurkopioj de OS kaj aplikaĵo. Ĉi tiu parto de la datumoj ankaŭ havas sian propran politikon kaj konservan periodon.
Nuntempe, IBS ne influas produktemajn servojn, sed se la situacio ŝanĝiĝas, Commvault povas ebligi ŝarĝlimigon.
Ĉu estas bone? Bone!
Do, ni ricevis ne nur funkcieblan, sed ankaŭ plene aŭtomatigitan sekurkopion por instalaĵo de PostgreSQL-grupo, kaj ĝi plenumas ĉiujn postulojn por entreprenaj vokoj.
La parametroj RPO kaj RTO de 1 horo kaj 2 horoj estas kovritaj per rando, kio signifas, ke la sistemo plenumos ilin eĉ kun signifa kresko de la volumo de stokitaj datumoj. Kontraŭe al multaj duboj, PostgreSQL kaj la entreprena medio montriĝis sufiĉe kongruaj. Kaj nun ni scias el nia propra sperto, ke sekurkopio por tiaj DBMS-oj eblas en diversaj agordoj.
Kompreneble, laŭ tiu ĉi vojo ni devis eluzi sep parojn da ferbotoj, venki kelkajn malfacilaĵojn, paŝi sur plurajn rastilojn kaj korekti kelkajn erarojn. Sed nun la aliro jam estis provita kaj povas esti uzata por efektivigi Malferman Fonton anstataŭ proprieta DBMS en severaj entreprenaj kondiĉoj.
Ĉu vi provis labori kun PostgreSQL en kompania medio?
Aŭtoroj:
Oleg Lavrenov, dezajninĝeniero de datumstokaj sistemoj, Jet Infosystems
Dmitry Erykin, dezajninĝeniero de komputilsistemoj ĉe Jet Infosystems
fonto: www.habr.com