Watu wengi wanaifahamu PostgreSQL DBMS, na imejidhihirisha katika usakinishaji mdogo. Walakini, mwelekeo kuelekea Open Source umezidi kuwa wazi, hata linapokuja suala la kampuni kubwa na mahitaji ya biashara. Katika makala haya tutakuambia jinsi ya kuunganisha Postgres katika mazingira ya shirika na kushiriki uzoefu wetu wa kuunda mfumo wa chelezo (BSS) wa hifadhidata hii kwa kutumia mfumo wa chelezo wa Commvault kama mfano.
PostgreSQL tayari imethibitisha thamani yake - DBMS inafanya kazi vizuri, inatumiwa na biashara za kisasa za kidijitali kama Alibaba na TripAdvisor, na ukosefu wa ada za leseni huifanya kuwa njia mbadala ya kushawishi kwa viumbe kama vile MS SQL au Oracle DB. Lakini mara tu tunapoanza kufikiria juu ya PostgreSQL katika mazingira ya Biashara, mara moja tunaingia katika mahitaji madhubuti: "Vipi kuhusu uvumilivu wa makosa ya usanidi? upinzani wa maafa? ufuatiliaji wa kina uko wapi? Vipi kuhusu chelezo otomatiki? Vipi kuhusu kutumia maktaba za kanda moja kwa moja na kwenye hifadhi ya pili?β
Kwa upande mmoja, PostgreSQL haina zana za kuhifadhi nakala zilizojengewa ndani, kama vile DBMS za "watu wazima" kama vile RMAN katika Oracle DB au Hifadhidata ya SAP. Kwa upande mwingine, wasambazaji wa mifumo ya chelezo ya ushirika (Veeam, Veritas, Commvault) ingawa wanaunga mkono PostgreSQL, kwa kweli wanafanya kazi tu na usanidi fulani (kawaida wa kusimama pekee) na seti ya vizuizi mbalimbali.
Mifumo ya chelezo iliyoundwa mahususi kwa ajili ya PostgreSQL, kama vile Barman, Wal-g, pg_probackup, ni maarufu sana katika usakinishaji mdogo wa PostgreSQL DBMS au ambapo chelezo nzito za vipengele vingine vya mazingira ya IT hazihitajiki. Kwa mfano, pamoja na PostgreSQL, miundombinu inaweza kujumuisha seva za kimwili na za kawaida, OpenShift, Oracle, MariaDB, Cassandra, nk. Inashauriwa kuunga mkono haya yote kwa chombo cha kawaida. Kufunga suluhisho tofauti kwa PostgreSQL pekee ni wazo mbaya: data itanakiliwa mahali fulani kwenye diski, na kisha inahitaji kuondolewa kwa mkanda. Hifadhi hii mara mbili huongeza muda wa kuhifadhi, na pia, muhimu zaidi, wakati wa kurejesha.
Katika suluhisho la biashara, nakala rudufu ya usanikishaji hufanyika na idadi fulani ya nodi kwenye nguzo iliyojitolea. Wakati huo huo, kwa mfano, Commvault inaweza tu kufanya kazi na nguzo ya nodi mbili, ambayo Msingi na Sekondari hupewa nodes fulani. Na inaeleweka tu kuhifadhi nakala kutoka kwa Msingi, kwa sababu chelezo kutoka Sekondari ina vikwazo vyake. Kwa sababu ya upekee wa DBMS, utupaji haujaundwa kwenye Sekondari, na kwa hivyo uwezekano wa kuhifadhi faili unabaki.
Ili kupunguza hatari ya muda wa kupungua, wakati wa kuunda mfumo unaostahimili hitilafu, usanidi wa nguzo "moja kwa moja" huundwa, na Msingi unaweza kuhama hatua kwa hatua kati ya seva tofauti. Kwa mfano, programu ya Patroni yenyewe inazindua Msingi kwenye nodi ya nguzo iliyochaguliwa kwa nasibu. IBS haina njia ya kufuatilia hii nje ya kisanduku, na ikiwa usanidi utabadilika, michakato huvunjika. Hiyo ni, kuanzishwa kwa udhibiti wa nje huzuia ISR kufanya kazi kwa ufanisi, kwa sababu seva ya udhibiti haielewi wapi na data gani inahitaji kunakiliwa kutoka.
Shida nyingine ni utekelezaji wa chelezo katika Postgres. Inawezekana kupitia dampo, na inafanya kazi kwenye hifadhidata ndogo. Lakini katika hifadhidata kubwa, utupaji huchukua muda mrefu, unahitaji rasilimali nyingi na inaweza kusababisha kutofaulu kwa mfano wa hifadhidata.
Hifadhi nakala ya faili husahihisha hali hiyo, lakini kwenye hifadhidata kubwa ni polepole kwa sababu inafanya kazi katika hali ya uzi mmoja. Kwa kuongeza, wachuuzi wana idadi ya vikwazo vya ziada. Huwezi kutumia faili na kutupa nakala rudufu kwa wakati mmoja, au urejeshaji hautumiki. Kuna matatizo mengi, na mara nyingi ni rahisi kuchagua DBMS ya gharama kubwa lakini iliyothibitishwa badala ya Postgres.
Hakuna mahali pa kurudi! Watengenezaji wa Moscow wako nyuma!
Hata hivyo, hivi majuzi timu yetu ilikabiliwa na changamoto ngumu: katika mradi wa kuunda AIS OSAGO 2.0, ambapo tuliunda miundombinu ya IT, wasanidi walichagua PostgreSQL kwa mfumo mpya.
Ni rahisi zaidi kwa watengenezaji wa programu kubwa kutumia ufumbuzi wa chanzo huria "wenye mtindo". Facebook ina wataalamu wa kutosha kusaidia utendakazi wa DBMS hii. Na kwa upande wa RSA, kazi zote za "siku ya pili" zilianguka kwenye mabega yetu. Tulihitajika kuhakikisha uvumilivu wa makosa, kukusanya nguzo na, bila shaka, kuweka nakala rudufu. Mantiki ya hatua ilikuwa kama ifuatavyo:
- Ifundishe SRK kutengeneza nakala kutoka kwa nodi ya Msingi ya nguzo. Ili kufanya hivyo, SRK lazima ipate - ambayo inamaanisha kuunganishwa na suluhisho la usimamizi wa nguzo moja au lingine la PostgreSQL inahitajika. Katika kesi ya RSA, programu ya Patroni ilitumiwa kwa hili.
- Amua aina ya chelezo kulingana na wingi wa data na mahitaji ya urejeshaji. Kwa mfano, wakati unahitaji kurejesha kurasa kwa punjepunje, tumia dampo, na ikiwa hifadhidata ni kubwa na urejesho wa punjepunje hauhitajiki, fanya kazi kwenye kiwango cha faili.
- Ambatanisha uwezekano wa kuzuia chelezo kwenye suluhisho ili kuunda nakala rudufu katika hali ya nyuzi nyingi.
Wakati huo huo, hapo awali tulipanga kuunda mfumo mzuri na rahisi bila uunganisho wa kutisha wa vifaa vya ziada. Magongo machache, mzigo mdogo wa kazi kwa wafanyakazi na kupunguza hatari ya kushindwa kwa IBS. Mara moja tuliondoa njia ambazo zilitumia Veeam na RMAN, kwa sababu seti ya suluhisho mbili tayari inaonyesha kutotegemewa kwa mfumo.
Uchawi kidogo kwa biashara
Kwa hivyo, tulihitaji kuhakikisha hifadhi rudufu inayotegemewa kwa makundi 10 ya nodi 3 kila moja, na miundombinu sawa inayoakisiwa katika kituo cha hifadhi data. Vituo vya data kwa mujibu wa PostgreSQL hufanya kazi kwa kanuni amilifu-isiyobadilika. Jumla ya ukubwa wa hifadhidata ilikuwa 50 TB. Mfumo wowote wa udhibiti wa kiwango cha ushirika unaweza kukabiliana na hii kwa urahisi. Lakini tahadhari ni kwamba awali Postgres haina kidokezo cha utangamano kamili na wa kina na mifumo ya chelezo. Kwa hivyo, tulilazimika kutafuta suluhisho ambalo hapo awali lilikuwa na utendakazi wa hali ya juu kwa kushirikiana na PostgreSQL, na kuboresha mfumo.
Tulishikilia "hackathons" 3 za ndani - tuliangalia zaidi ya maendeleo hamsini, tukajaribu, tukafanya mabadiliko kuhusiana na nadharia zetu, na tukajaribu tena. Baada ya kukagua chaguzi zinazopatikana, tulichagua Commvault. Nje ya kisanduku, bidhaa hii inaweza kufanya kazi na usakinishaji rahisi zaidi wa nguzo ya PostgreSQL, na usanifu wake wazi uliibua matumaini (ambayo yalihesabiwa haki) kwa maendeleo na ujumuishaji mafanikio. Commvault pia inaweza kuhifadhi kumbukumbu za PostgreSQL. Kwa mfano, Veritas NetBackup kulingana na PostgreSQL inaweza tu kufanya nakala kamili.
Zaidi kuhusu usanifu. Seva za usimamizi wa Commvault zilisakinishwa katika kila moja ya vituo viwili vya data katika usanidi wa CommServ HA. Mfumo huo umeakisiwa, unasimamiwa kupitia koni moja na, kutoka kwa mtazamo wa HA, hukutana na mahitaji yote ya biashara.
Pia tulizindua seva mbili za midia halisi katika kila kituo cha data, ambapo tuliunganisha safu za diski na maktaba za tepu zilizowekwa maalum kwa ajili ya kuhifadhi nakala kupitia SAN kupitia Fiber Channel. Hifadhidata zilizopanuliwa za urudishaji zilihakikisha ustahimilivu wa hitilafu wa seva za midia, na kuunganisha kila seva kwa kila CSV kumewasha utendakazi unaoendelea ikiwa kijenzi chochote kilishindwa. Usanifu wa mfumo huruhusu kuhifadhi nakala kuendelea hata kama moja ya vituo vya data vitaanguka.
Patroni anafafanua nodi ya Msingi kwa kila nguzo. Inaweza kuwa nodi yoyote ya bure katika kituo cha data - lakini zaidi tu. Katika chelezo, nodi zote ni za Sekondari.
Ili Commvault ielewe ni nodi gani ya nguzo ni Msingi, tuliunganisha mfumo (shukrani kwa usanifu wazi wa suluhisho) na Postgres. Kwa kusudi hili, hati iliundwa ambayo inaripoti eneo la sasa la nodi ya Msingi kwa seva ya usimamizi ya Commvault.
Kwa ujumla, mchakato unaonekana kama hii:
Patroni anachagua Msingi β Keepalived huchukua nguzo ya IP na kuendesha hati β wakala wa Commvault kwenye nodi ya nguzo iliyochaguliwa hupokea arifa kwamba hii ndiyo Msingi β Commvault huweka upya kiotomatiki hifadhi rudufu ndani ya mteja bandia.
Faida ya mbinu hii ni kwamba suluhisho haliathiri uthabiti, usahihi wa kumbukumbu, au urejeshaji wa mfano wa Postgres. Pia inaweza kuongezwa kwa urahisi, kwa sababu si lazima tena kurekebisha nodi za Msingi za Commvault na Sekondari. Inatosha kwamba mfumo unaelewa wapi Msingi ulipo, na idadi ya nodes inaweza kuongezeka hadi karibu thamani yoyote.
Suluhisho halijifanya kuwa bora na ina nuances yake mwenyewe. Commvault inaweza kuhifadhi nakala ya mfano mzima tu, na sio hifadhidata za mtu binafsi. Kwa hivyo, mfano tofauti uliundwa kwa kila hifadhidata. Wateja wa kweli wameunganishwa kuwa wateja bandia. Kila mteja bandia wa Commvault ni nguzo ya UNIX. Sehemu hizo za nguzo ambazo wakala wa Commvault wa Postgres amesakinishwa huongezwa kwake. Kama matokeo, nodi zote pepe za mteja wa uwongo zinachelezwa kama mfano mmoja.
Ndani ya kila mteja wa uwongo, nodi hai ya nguzo imeonyeshwa. Hivi ndivyo suluhisho letu la ujumuishaji la Commvault linafafanua. Kanuni ya uendeshaji wake ni rahisi sana: ikiwa IP ya nguzo imeinuliwa kwenye nodi, hati huweka parameta ya "nodi inayotumika" kwenye binary ya wakala wa Commvault - kwa kweli, hati huweka "1" katika sehemu inayohitajika ya kumbukumbu. . Wakala hutuma data hii kwa CommServe, na Commvault hufanya nakala rudufu kutoka kwa nodi inayotaka. Kwa kuongeza, usahihi wa usanidi unaangaliwa kwa kiwango cha script, na kusaidia kuepuka makosa wakati wa kuanzisha salama.
Wakati huo huo, hifadhidata kubwa huchelezwa katika vizuizi kwenye nyuzi nyingi, kukidhi RPO na mahitaji ya dirisha la chelezo. Mzigo kwenye mfumo hauna maana: Nakala kamili hazifanyiki mara nyingi, kwa siku nyingine magogo tu hukusanywa, na wakati wa mzigo mdogo.
Kwa njia, tumetumia sera tofauti za kuhifadhi kumbukumbu za kumbukumbu za PostgreSQL - huhifadhiwa kulingana na sheria tofauti, kunakiliwa kulingana na ratiba tofauti, na urejeshaji haujawezeshwa kwao, kwa kuwa kumbukumbu hizi zina data ya kipekee.
Ili kuhakikisha uthabiti katika miundombinu yote ya IT, wateja tofauti wa faili za Commvault husakinishwa kwenye kila nodi za nguzo. Hazijumuishi faili za Postgres kutoka kwa chelezo na zimekusudiwa tu kwa nakala za OS na programu. Sehemu hii ya data pia ina sera na muda wake wa kuhifadhi.
Kwa sasa, IBS haiathiri huduma za tija, lakini hali ikibadilika, Commvault inaweza kuwezesha kizuizi cha upakiaji.
Je, ni nzuri? Nzuri!
Kwa hivyo, tumepokea sio tu nakala inayoweza kutekelezeka, lakini pia nakala rudufu otomatiki kwa usakinishaji wa nguzo ya PostgreSQL, na inakidhi mahitaji yote ya simu za biashara.
Vigezo vya RPO na RTO vya saa 1 na saa 2 vinafunikwa na ukingo, ambayo ina maana kwamba mfumo utazingatia hata kwa ongezeko kubwa la kiasi cha data iliyohifadhiwa. Kinyume na mashaka mengi, PostgreSQL na mazingira ya biashara yaliendana kabisa. Na sasa tunajua kutokana na uzoefu wetu kwamba chelezo kwa DBMS kama hizo inawezekana katika usanidi mbalimbali.
Kwa kweli, kando ya njia hii tulilazimika kuvaa jozi saba za buti za chuma, kushinda shida kadhaa, kupiga hatua kwenye reki kadhaa na kusahihisha makosa kadhaa. Lakini sasa mbinu hiyo tayari imejaribiwa na inaweza kutumika kutekeleza Open Source badala ya DBMS wamiliki katika hali mbaya ya biashara.
Umejaribu kufanya kazi na PostgreSQL katika mazingira ya ushirika?
Waandishi:
Oleg Lavrenov, mhandisi wa kubuni wa mifumo ya kuhifadhi data, Jet Infosystems
Dmitry Erykin, mhandisi wa kubuni wa mifumo ya kompyuta katika Jet Infosystems
Chanzo: mapenzi.com