ProHoster > Blogs > Administrācija > Kā iekļaut ā€œbezmaksasā€ PostgreSQL skarbā uzņēmuma vidē

Kā iekļaut ā€œbezmaksasā€ PostgreSQL skarbā uzņēmuma vidē

Daudzi cilvēki ir pazÄ«stami ar PostgreSQL DBVS, un tā ir sevi pierādÄ«jusi mazās instalācijās. Tomēr tendence uz atvērto avotu ir kļuvusi arvien skaidrāka, pat ja runa ir par lieliem uzņēmumiem un uzņēmumu prasÄ«bām. Å ajā rakstā mēs jums pastāstÄ«sim, kā integrēt Postgres korporatÄ«vajā vidē, un dalÄ«simies pieredzē par rezerves sistēmas (BSS) izveidi Å”ai datubāzei, kā piemēru izmantojot Commvault dublÄ“Å”anas sistēmu.

Kā iekļaut ā€œbezmaksasā€ PostgreSQL skarbā uzņēmuma vidē
PostgreSQL jau ir pierādÄ«jis savu vērtÄ«bu ā€“ DBVS darbojas lieliski, to izmanto moderni digitālie uzņēmumi, piemēram, Alibaba un TripAdvisor, un licencÄ“Å”anas maksas trÅ«kums padara to par vilinoÅ”u alternatÄ«vu tādiem monstriem kā MS SQL vai Oracle DB. Bet, tiklÄ«dz mēs sākam domāt par PostgreSQL uzņēmuma vidē, mēs nekavējoties saskaramies ar stingrām prasÄ«bām: ā€œKā ir ar konfigurācijas kļūdu toleranci? izturÄ«ba pret katastrofām? kur ir visaptveroŔā uzraudzÄ«ba? Kā ar automatizētajām dublējumkopijām? Kā ar lentu bibliotēku izmantoÅ”anu gan tieÅ”i, gan sekundārajā atmiņā?

Kā iekļaut ā€œbezmaksasā€ PostgreSQL skarbā uzņēmuma vidē
No vienas puses, PostgreSQL nav iebÅ«vētu dublÄ“Å”anas rÄ«ku, piemēram, ā€œpieauguÅ”oā€ DBVS, piemēram, RMAN Oracle DB vai SAP datu bāzes dublÄ“Å”ana. No otras puses, korporatÄ«vo dublÄ“Å”anas sistēmu piegādātāji (Veeam, Veritas, Commvault), lai gan atbalsta PostgreSQL, patiesÄ«bā viņi strādā tikai ar noteiktu (parasti savrupu) konfigurāciju un ar dažādu ierobežojumu kopumu.

DublÄ“Å”anas sistēmas, kas Ä«paÅ”i izstrādātas PostgreSQL, piemēram, Barman, Wal-g, pg_probackup, ir ļoti populāras nelielās PostgreSQL DBVS instalācijās vai gadÄ«jumos, kad nav nepiecieÅ”amas smagas citu IT ainavas elementu dublējumkopijas. Piemēram, papildus PostgreSQL infrastruktÅ«ra var ietvert fiziskos un virtuālos serverus, OpenShift, Oracle, MariaDB, Cassandra utt. Ieteicams to visu dublēt ar kopÄ«gu rÄ«ku. AtseviŔķa risinājuma instalÄ“Å”ana tikai PostgreSQL ir slikta ideja: dati tiks pārkopēti kaut kur diskā, un pēc tam tie ir jānoņem lentē. Å Ä« dubultā dublÄ“Å”ana palielina dublÄ“Å”anas laiku un, vēl svarÄ«gāk, atkopÅ”anas laiku.

Uzņēmuma risinājumā instalācijas dublÄ“Å”ana notiek ar noteiktu skaitu mezglu Ä«paŔā klasterÄ«. Tajā paŔā laikā, piemēram, Commvault var strādāt tikai ar divu mezglu klasteri, kurā primārais un sekundārais ir stingri pieŔķirti noteiktiem mezgliem. Un ir jēga dublēt tikai no primārās, jo dublÄ“Å”anai no sekundārās ir savi ierobežojumi. DBVS Ä«patnÄ«bu dēļ uz Secondary netiek izveidota izgāztuve, un tāpēc paliek tikai faila dublÄ“Å”anas iespēja.

Lai samazinātu dÄ«kstāves risku, veidojot kļūdu izturÄ«gu sistēmu, tiek izveidota klastera ā€œdzÄ«vāā€ konfigurācija, un primārais var pakāpeniski migrēt starp dažādiem serveriem. Piemēram, Patroni programmatÅ«ra pati palaiž primāro nejauÅ”i izvēlētā klastera mezglā. IBS nevar to izsekot, un, ja konfigurācija mainās, procesi pārtrÅ«kst. Tas ir, ārējās kontroles ievieÅ”ana neļauj ISR darboties efektÄ«vi, jo vadÄ«bas serveris vienkārÅ”i nesaprot, no kurienes un kādi dati ir jākopē.

Vēl viena problēma ir dublÄ“Å”anas ievieÅ”ana programmā Postgres. Tas ir iespējams, izmantojot dump, un tas darbojas nelielās datu bāzēs. Bet lielās datu bāzēs izgāztuve aizņem ilgu laiku, prasa daudz resursu un var izraisÄ«t datu bāzes instances kļūmi.

Failu dublÄ“Å”ana izlabo situāciju, bet lielās datu bāzēs tas ir lēns, jo darbojas viena pavediena režīmā. Turklāt pārdevējiem ir vairāki papildu ierobežojumi. Vai nu jÅ«s nevarat vienlaikus izmantot failu un dublējumus, vai arÄ« netiek atbalstÄ«ta dublÄ“Å”ana. Problēmu ir daudz, un visbiežāk Postgres vietā ir vieglāk izvēlēties dārgu, bet pārbaudÄ«tu DBVS.

Nav kur atkāpties! Maskavas izstrādātāji ir aiz muguras!

Tomēr nesen mūsu komanda saskārās ar sarežģītu izaicinājumu: AIS OSAGO 2.0 izveides projektā, kurā izveidojām IT infrastruktūru, izstrādātāji jaunajai sistēmai izvēlējās PostgreSQL.

Lieliem programmatÅ«ras izstrādātājiem ir daudz vieglāk izmantot ā€œmodernusā€ atvērtā pirmkoda risinājumus. Facebook ir pietiekami daudz speciālistu, lai atbalstÄ«tu Ŕīs DBVS darbÄ«bu. Un RSA gadÄ«jumā visi ā€œotrās dienasā€ uzdevumi gulēja uz mÅ«su pleciem. Mums bija jānodroÅ”ina kļūdu tolerance, jāsamontē klasteris un, protams, jāizveido dublējums. DarbÄ«bas loÄ£ika bija Ŕāda:

  • Māciet SRK izveidot dublējumus no klastera primārā mezgla. Lai to izdarÄ«tu, SRK tas ir jāatrod ā€“ tas nozÄ«mē, ka ir nepiecieÅ”ama integrācija ar vienu vai otru PostgreSQL klasteru pārvaldÄ«bas risinājumu. RSA gadÄ«jumā Å”im nolÅ«kam tika izmantota programmatÅ«ra Patroni.
  • Izlemiet par dublējuma veidu, pamatojoties uz datu apjomu un atkopÅ”anas prasÄ«bām. Piemēram, ja nepiecieÅ”ams detalizēti atjaunot lapas, izmantojiet izgāztuvi un, ja datu bāzes ir lielas un granulēta atjaunoÅ”ana nav nepiecieÅ”ama, strādājiet faila lÄ«menÄ«.
  • Pievienojiet risinājumam bloÄ·Ä“Å”anas dublÄ“Å”anas iespēju, lai izveidotu rezerves kopiju vairāku pavedienu režīmā.

Tajā paŔā laikā mēs sākotnēji nolēmām izveidot efektÄ«vu un vienkārÅ”u sistēmu bez milzÄ«giem papildu komponentiem. Jo mazāk kruÄ·u, jo mazāka ir personāla darba slodze un mazāks IBS atteices risks. Mēs nekavējoties izslēdzām pieejas, kas izmantoja Veeam un RMAN, jo divu risinājumu kopums jau norāda uz sistēmas neuzticamÄ«bu.

Maza burvība uzņēmējdarbībai

Tāpēc mums bija jāgarantē uzticama dublÄ“Å”ana 10 klasteriem, kuros katrā ir 3 mezgli, ar to paÅ”u infrastruktÅ«ru, kas atspoguļojas rezerves datu centrā. PostgreSQL datu centri darbojas pēc aktÄ«vā-pasÄ«vā principa. Kopējais datu bāzes lielums bija 50 TB. Jebkura uzņēmuma lÄ«meņa kontroles sistēma var viegli tikt galā ar to. Taču brÄ«dinājums ir tāds, ka sākotnēji Postgres nav ne jausmas par pilnÄ«gu un dziļu saderÄ«bu ar rezerves sistēmām. Tāpēc mums bija jāmeklē risinājums, kam sākotnēji bija maksimāla funkcionalitāte kopā ar PostgreSQL, un jāpilnveido sistēma.

Mēs sarÄ«kojām 3 iekŔējos ā€œhakatonusā€ - apskatÄ«jām vairāk nekā piecdesmit izstrādnes, pārbaudÄ«jām tās, veicām izmaiņas saistÄ«bā ar mÅ«su hipotēzēm un pārbaudÄ«jām vēlreiz. Pēc pieejamo opciju pārskatÄ«Å”anas mēs izvēlējāmies Commvault. Å is produkts varētu darboties ar vienkārŔāko PostgreSQL klastera instalāciju, un tā atvērtā arhitektÅ«ra radÄ«ja cerÄ«bas (kas bija pamatotas) uz veiksmÄ«gu attÄ«stÄ«bu un integrāciju. Commvault var arÄ« dublēt PostgreSQL žurnālus. Piemēram, Veritas NetBackup saistÄ«bā ar PostgreSQL var veikt tikai pilnas dublējumkopijas.

Vairāk par arhitektūru. Commvault pārvaldības serveri tika instalēti katrā no diviem datu centriem CommServ HA konfigurācijā. Sistēma ir atspoguļota, pārvaldīta caur vienu konsoli un no HA viedokļa atbilst visām uzņēmuma prasībām.

Kā iekļaut ā€œbezmaksasā€ PostgreSQL skarbā uzņēmuma vidē
Mēs arÄ« ieviesām divus fiziskus multivides serverus katrā datu centrā, ar kuriem pievienojām disku masÄ«vus un lentes bibliotēkas, kas Ä«paÅ”i paredzētas dublÄ“Å”anai, izmantojot SAN, izmantojot Fibre Channel. PaplaÅ”inātās dublÄ“Å”anas datu bāzes nodroÅ”ināja multivides serveru kļūdu toleranci, un katra servera savienoÅ”ana ar katru CSV nodroÅ”ināja nepārtrauktu darbÄ«bu, ja kāds komponents atteicās. Sistēmas arhitektÅ«ra ļauj turpināt dublÄ“Å”anu pat tad, ja kāds no datu centriem nokrÄ«t.

Patroni katram klasterim definē primāro mezglu. Tas var bÅ«t jebkurÅ” bezmaksas mezgls datu centrā, bet tikai galvenokārt. Dublējumkopijā visi mezgli ir sekundāri.

Lai Commvault saprastu, kurÅ” klastera mezgls ir primārais, mēs integrējām sistēmu (pateicoties risinājuma atvērtajai arhitektÅ«rai) ar Postgres. Å im nolÅ«kam tika izveidots skripts, kas ziņo par primārā mezgla paÅ”reizējo atraÅ”anās vietu Commvault pārvaldÄ«bas serverim.

Kopumā process izskatās Ŕādi:

Patroni atlasa Primary ā†’ Keepalived paņem IP klasteru un palaiž skriptu ā†’ Commvault aÄ£ents atlasÄ«tajā klastera mezglā saņem paziņojumu, ka tas ir primārais ā†’ Commvault automātiski pārkonfigurē dublējumu pseidoklientā.

Kā iekļaut ā€œbezmaksasā€ PostgreSQL skarbā uzņēmuma vidē
Å Ä«s pieejas priekÅ”rocÄ«ba ir tāda, ka risinājums neietekmē žurnālu konsekvenci, pareizÄ«bu vai Postgres instances atkopÅ”anu. Tas ir arÄ« viegli mērogojams, jo vairs nav nepiecieÅ”ams labot Commvault primāro un sekundāro mezglu. Pietiek ar to, ka sistēma saprot, kur atrodas primārais, un mezglu skaitu var palielināt lÄ«dz gandrÄ«z jebkurai vērtÄ«bai.

Risinājums nepretendē uz ideālu un tam ir savas nianses. Commvault var dublēt tikai visu gadÄ«jumu, nevis atseviŔķas datu bāzes. Tāpēc katrai datubāzei tika izveidota atseviŔķa instance. Reālie klienti tiek apvienoti virtuālos pseidoklientos. Katrs Commvault pseidoklients ir UNIX klasteris. Tam tiek pievienoti tie klastera mezgli, kuros ir instalēts Postgres Commvault aÄ£ents. Rezultātā visi pseidoklienta virtuālie mezgli tiek dublēti kā viens gadÄ«jums.

Katrā pseidoklientā ir norādÄ«ts klastera aktÄ«vais mezgls. Tas ir tas, ko definē mÅ«su Commvault integrācijas risinājums. Tās darbÄ«bas princips ir pavisam vienkārÅ”s: ja mezglā tiek paaugstināts klastera IP, skripts Commvault aÄ£enta binārajā failā iestata parametru ā€œactive nodeā€ - patiesÄ«bā skripts iestata ā€œ1ā€ vajadzÄ«gajā atmiņas daļā. . AÄ£ents pārsÅ«ta Å”os datus uz CommServe, un Commvault izveido dublējumu no vēlamā mezgla. Turklāt konfigurācijas pareizÄ«ba tiek pārbaudÄ«ta skripta lÄ«menÄ«, palÄ«dzot izvairÄ«ties no kļūdām, uzsākot dublÄ“Å”anu.

Tajā paŔā laikā lielas datu bāzes tiek dublētas blokos vairākos pavedienos, kas atbilst RPO un rezerves loga prasÄ«bām. Sistēmas slodze ir nenozÄ«mÄ«ga: pilnas kopijas nerodas tik bieži, citās dienās tiek vākti tikai žurnāli un zemas noslodzes periodos.

Starp citu, mēs esam piemērojuÅ”i atseviŔķas politikas PostgreSQL arhÄ«va žurnālu dublÄ“Å”anai - tie tiek glabāti saskaņā ar dažādiem noteikumiem, tiek kopēti pēc cita grafika, un tiem nav iespējota dublÄ“Å”ana, jo Å”ajos žurnālos ir unikāli dati.

Lai nodroÅ”inātu konsekvenci visā IT infrastruktÅ«rā, katrā klastera mezglā ir instalēti atseviŔķi Commvault failu klienti. Tie izslēdz Postgres failus no dublējumkopijām un ir paredzēti tikai OS un lietojumprogrammu dublÄ“Å”anai. Å ai datu daļai ir arÄ« sava politika un uzglabāŔanas periods.

Kā iekļaut ā€œbezmaksasā€ PostgreSQL skarbā uzņēmuma vidē
PaÅ”laik IBS neietekmē produktivitātes pakalpojumus, taču, ja situācija mainās, Commvault var iespējot slodzes ierobežoÅ”anu.

Vai tas ir labs? Labi!

Tātad mēs esam saņēmuÅ”i ne tikai funkcionējoÅ”u, bet arÄ« pilnÄ«bā automatizētu dublējumu PostgreSQL klastera instalÄ“Å”anai, un tas atbilst visām uzņēmuma zvanu prasÄ«bām.

RPO un RTO parametri 1 stunda un 2 stundas ir pārklāti ar rezervi, kas nozÄ«mē, ka sistēma tos ievēros pat ievērojami palielinot uzglabāto datu apjomu. Pretēji daudzām Å”aubām, PostgreSQL un uzņēmuma vide izrādÄ«jās diezgan saderÄ«ga. Un tagad mēs no savas pieredzes zinām, ka Ŕādu DBVS dublÄ“Å”ana ir iespējama dažādās konfigurācijās.

Protams, pa Å”o ceļu bija jānovalkā septiņi dzelzs zābaku pāri, jāpārvar vairākas grÅ«tÄ«bas, jāuzkāpj uz vairākiem grābekļiem un jāizlabo vairākas kļūdas. Bet tagad Ŕī pieeja jau ir pārbaudÄ«ta, un to var izmantot, lai ieviestu atvērtā pirmkoda, nevis patentētu DBVS skarbos uzņēmuma apstākļos.

Vai esat mēģinājis strādāt ar PostgreSQL korporatīvajā vidē?

Autori:

Oļegs Lavrenovs, Jet Infosystems datu uzglabāŔanas sistēmu projektÄ“Å”anas inženieris

Dmitrijs Erikins, Jet Infosystems datorsistēmu projektÄ“Å”anas inženieris

Avots: www.habr.com

Pievieno komentāru