Mae llawer o bobl yn gyfarwydd â DBMS PostgreSQL, ac mae wedi profi ei hun mewn gosodiadau bach. Fodd bynnag, mae'r duedd tuag at Ffynhonnell Agored wedi dod yn fwyfwy amlwg, hyd yn oed pan ddaw i gwmnïau mawr a gofynion menter. Yn yr erthygl hon byddwn yn dweud wrthych sut i integreiddio Postgres i amgylchedd corfforaethol a rhannu ein profiad o greu system wrth gefn (BSS) ar gyfer y gronfa ddata hon gan ddefnyddio system wrth gefn Commvault fel enghraifft.
Mae PostgreSQL eisoes wedi profi ei werth - mae'r DBMS yn gweithio'n wych, fe'i defnyddir gan fusnesau digidol ffasiynol fel Alibaba a TripAdvisor, ac mae diffyg ffioedd trwyddedu yn ei gwneud yn ddewis arall demtasiwn i angenfilod fel MS SQL neu Oracle DB. Ond cyn gynted ag y byddwn yn dechrau meddwl am PostgreSQL yn y dirwedd Menter, rydym yn rhedeg i mewn i ofynion llym ar unwaith: “Beth am oddefgarwch bai cyfluniad? gwrthsefyll trychineb? ble mae'r monitro cynhwysfawr? Beth am gopïau wrth gefn awtomataidd? Beth am ddefnyddio llyfrgelloedd tâp yn uniongyrchol ac ar storfa eilaidd?”
Ar y naill law, nid oes gan PostgreSQL offer wrth gefn adeiledig, fel DBMSs “oedolyn” fel RMAN yn Oracle DB neu SAP Database Backup. Ar y llaw arall, mae cyflenwyr systemau wrth gefn corfforaethol (Veeam, Veritas, Commvault) er eu bod yn cefnogi PostgreSQL, mewn gwirionedd dim ond gyda chyfluniad penodol (annibynnol fel arfer) y maent yn gweithio a chyda set o gyfyngiadau amrywiol.
Mae systemau wrth gefn a ddyluniwyd yn arbennig ar gyfer PostgreSQL, megis Barman, Wal-g, pg_probackup, yn hynod boblogaidd mewn gosodiadau bach o'r DBMS PostgreSQL neu lle nad oes angen copïau wrth gefn trwm o elfennau eraill o'r dirwedd TG. Er enghraifft, yn ogystal â PostgreSQL, gall y seilwaith gynnwys gweinyddwyr ffisegol a rhithwir, OpenShift, Oracle, MariaDB, Cassandra, ac ati. Fe'ch cynghorir i ategu hyn i gyd gydag offeryn cyffredin. Mae gosod datrysiad ar wahân ar gyfer PostgreSQL yn unig yn syniad gwael: bydd y data'n cael ei gopïo yn rhywle i ddisg, ac yna mae angen ei dynnu i dâp. Mae'r copi wrth gefn dwbl hwn yn cynyddu'r amser wrth gefn, a hefyd, yn bwysicach, yr amser adfer.
Mewn datrysiad menter, mae copi wrth gefn o'r gosodiad yn digwydd gyda nifer benodol o nodau mewn clwstwr pwrpasol. Ar yr un pryd, er enghraifft, dim ond gyda chlwstwr dau nod y gall Commvault weithio, lle mae Cynradd ac Uwchradd yn cael eu neilltuo'n llym i nodau penodol. Ac nid yw ond yn gwneud synnwyr gwneud copi wrth gefn o'r Cynradd, oherwydd mae cyfyngiadau wrth gefn o'r Uwchradd. Oherwydd hynodion y DBMS, nid yw dymp yn cael ei greu ar Uwchradd, ac felly dim ond y posibilrwydd o ffeil wrth gefn sydd ar ôl.
Er mwyn lleihau'r risg o amser segur, wrth greu system sy'n goddef namau, crëir cyfluniad clwstwr “byw”, a gall Cynradd fudo'n raddol rhwng gwahanol weinyddion. Er enghraifft, mae meddalwedd Patroni ei hun yn lansio Cynradd ar nod clwstwr a ddewiswyd ar hap. Nid oes gan yr IBS unrhyw ffordd i olrhain hyn allan o'r blwch, ac os bydd y cyfluniad yn newid, mae'r prosesau'n torri. Hynny yw, mae cyflwyno rheolaeth allanol yn atal yr ISR rhag gweithio'n effeithiol, oherwydd nid yw'r gweinydd rheoli yn deall o ble ac o ba ddata y mae angen copïo.
Problem arall yw gweithredu copi wrth gefn yn Postgres. Mae'n bosibl trwy dympio, ac mae'n gweithio ar gronfeydd data bach. Ond mewn cronfeydd data mawr, mae'r domen yn cymryd amser hir, mae angen llawer o adnoddau a gall arwain at fethiant yr enghraifft gronfa ddata.
Mae copi wrth gefn o ffeiliau yn cywiro'r sefyllfa, ond ar gronfeydd data mawr mae'n araf oherwydd ei fod yn gweithio mewn modd un edau. Yn ogystal, mae gan werthwyr nifer o gyfyngiadau ychwanegol. Naill ai ni allwch ddefnyddio copïau wrth gefn o ffeiliau a dympio ar yr un pryd, neu ni chefnogir dad-ddyblygu. Mae yna lawer o broblemau, ac yn fwyaf aml mae'n haws dewis DBMS drud ond profedig yn lle Postgres.
Nid oes unman i encilio! Mae datblygwyr Moscow ar ei hôl hi!
Fodd bynnag, yn ddiweddar roedd ein tîm yn wynebu her anodd: yn y prosiect i greu AIS OSAGO 2.0, lle gwnaethom greu'r seilwaith TG, dewisodd y datblygwyr PostgreSQL ar gyfer y system newydd.
Mae'n llawer haws i ddatblygwyr meddalwedd mawr ddefnyddio datrysiadau ffynhonnell agored “trendi”. Mae gan Facebook ddigon o arbenigwyr i gefnogi gweithrediad y DBMS hwn. Ac yn achos RSA, disgynnodd holl dasgau'r “ail ddiwrnod” ar ein hysgwyddau. Roedd yn ofynnol i ni sicrhau goddefgarwch namau, cydosod clwstwr ac, wrth gwrs, sefydlu copi wrth gefn. Roedd y rhesymeg gweithredu fel a ganlyn:
- Dysgwch y SRK i wneud copïau wrth gefn o nod Cynradd y clwstwr. I wneud hyn, mae'n rhaid i'r SRK ddod o hyd iddo - sy'n golygu bod angen integreiddio ag un neu ateb rheoli clwstwr PostgreSQL arall. Yn achos RSA, defnyddiwyd meddalwedd Patroni ar gyfer hyn.
- Penderfynwch ar y math o gopi wrth gefn yn seiliedig ar faint o ddata a gofynion adfer. Er enghraifft, pan fydd angen i chi adfer tudalennau'n gronynnog, defnyddiwch domen, ac os yw'r cronfeydd data yn fawr ac nad oes angen adfer gronynnog, gweithio ar lefel y ffeil.
- Atodwch y posibilrwydd o wrth gefn bloc i'r ateb i greu copi wrth gefn yn y modd aml-edau.
Ar yr un pryd, aethom ati i ddechrau i greu system effeithiol a syml heb harnais gwrthun o gydrannau ychwanegol. Po leiaf o faglau, y lleiaf o lwyth gwaith ar staff a lleiaf yw'r risg o fethiant IBS. Fe wnaethom eithrio ar unwaith ddulliau a oedd yn defnyddio Veeam a RMAN, oherwydd bod set o ddau ateb eisoes yn awgrymu annibynadwyedd y system.
Ychydig o hud ar gyfer menter
Felly, roedd angen i ni warantu copi wrth gefn dibynadwy ar gyfer 10 clwstwr o 3 nod yr un, gyda'r un seilwaith yn cael ei adlewyrchu yn y ganolfan ddata wrth gefn. Mae canolfannau data o ran PostgreSQL yn gweithio ar yr egwyddor gweithredol-goddefol. Cyfanswm maint y gronfa ddata oedd 50 TB. Gall unrhyw system reoli lefel gorfforaethol ymdopi â hyn yn hawdd. Ond y cafeat yw nad oes gan Postgres syniad i ddechrau am gydnawsedd llawn a dwfn â systemau wrth gefn. Felly, bu'n rhaid inni chwilio am ateb a oedd â'r ymarferoldeb mwyaf posibl i ddechrau ar y cyd â PostgreSQL, a mireinio'r system.
Fe wnaethom gynnal 3 “hacathon” mewnol - edrychom ar fwy na hanner cant o ddatblygiadau, eu profi, gwneud newidiadau mewn cysylltiad â'n damcaniaethau, a'u profi eto. Ar ôl adolygu'r opsiynau sydd ar gael, fe wnaethom ddewis Commvault. Allan o'r bocs, gallai'r cynnyrch hwn weithio gyda'r gosodiad clwstwr PostgreSQL symlaf, a chododd ei bensaernïaeth agored obeithion (a gyfiawnhawyd) ar gyfer datblygu ac integreiddio llwyddiannus. Gall Commvault hefyd wneud copi wrth gefn o logiau PostgreSQL. Er enghraifft, dim ond copïau wrth gefn llawn y gall Veritas NetBackup o ran PostgreSQL eu gwneud.
Mwy am bensaernïaeth. Gosodwyd gweinyddwyr rheoli Commvault ym mhob un o'r ddwy ganolfan ddata mewn cyfluniad HA CommServ. Mae'r system yn cael ei hadlewyrchu, ei rheoli trwy un consol ac, o safbwynt HA, mae'n bodloni holl ofynion menter.
Fe wnaethom hefyd lansio dau weinydd cyfryngau ffisegol ym mhob canolfan ddata, y gwnaethom gysylltu araeau disg a llyfrgelloedd tâp â nhw yn benodol ar gyfer copïau wrth gefn trwy SAN trwy Fiber Channel. Sicrhaodd cronfeydd data dad-ddyblygu estynedig goddefgarwch gweinyddwyr cyfryngau i ddiffygion, ac roedd cysylltu pob gweinydd â phob CSV yn galluogi gweithrediad parhaus pe bai unrhyw gydran yn methu. Mae pensaernïaeth y system yn caniatáu i'r copi wrth gefn barhau hyd yn oed os bydd un o'r canolfannau data yn disgyn.
Mae Patroni yn diffinio nod Cynradd ar gyfer pob clwstwr. Gall fod yn unrhyw nod am ddim yn y ganolfan ddata - ond dim ond yn bennaf. Yn y copi wrth gefn, mae pob nod yn Uwchradd.
Er mwyn i Commvault ddeall pa nod clwstwr yw Cynradd, fe wnaethom integreiddio'r system (diolch i bensaernïaeth agored yr ateb) â Postgres. At y diben hwn, crëwyd sgript sy'n adrodd am leoliad presennol y nod Cynradd i'r gweinydd rheoli Commvault.
Yn gyffredinol, mae'r broses yn edrych fel hyn:
Mae Patroni yn dewis Primary → Keepalived yn codi'r clwstwr IP ac yn rhedeg y sgript → mae'r asiant Commvault ar y nod clwstwr a ddewiswyd yn derbyn hysbysiad mai dyma'r Cynradd → Mae Commvault yn ad-drefnu'r copi wrth gefn yn awtomatig o fewn y ffug-gleient.
Mantais y dull hwn yw nad yw'r datrysiad yn effeithio ar gysondeb, cywirdeb boncyffion, nac adferiad achos Postgres. Mae hefyd yn hawdd ei raddio, oherwydd nid oes angen trwsio nodau Cynradd ac Uwchradd Commvault mwyach. Mae'n ddigon bod y system yn deall ble mae Cynradd, a gellir cynyddu nifer y nodau i bron unrhyw werth.
Nid yw'r ateb yn esgus ei fod yn ddelfrydol ac mae ganddo ei naws ei hun. Dim ond yr enghraifft gyfan y gall Commvault wneud copi wrth gefn, ac nid cronfeydd data unigol. Felly, crëwyd enghraifft ar wahân ar gyfer pob cronfa ddata. Mae cleientiaid go iawn yn cael eu cyfuno'n ffug-gleientiaid rhithwir. Mae pob ffug-gleient Commvault yn glwstwr UNIX. Mae'r nodau clwstwr hynny y mae'r asiant Commvault ar gyfer Postgres wedi'i osod arnynt yn cael eu hychwanegu ato. O ganlyniad, mae holl nodau rhithwir y ffug-gleient yn cael eu hategu fel un enghraifft.
O fewn pob cleient ffug, nodir nod gweithredol y clwstwr. Dyma beth mae ein datrysiad integreiddio ar gyfer Commvault yn ei ddiffinio. Mae egwyddor ei weithrediad yn eithaf syml: os codir IP clwstwr ar nod, mae'r sgript yn gosod y paramedr “nod gweithredol” yn y deuaidd asiant Commvault - mewn gwirionedd, mae'r sgript yn gosod “1” yn y rhan ofynnol o'r cof . Mae'r asiant yn trosglwyddo'r data hwn i CommServe, ac mae Commvault yn gwneud copi wrth gefn o'r nod a ddymunir. Yn ogystal, mae cywirdeb y ffurfweddiad yn cael ei wirio ar lefel y sgript, gan helpu i osgoi gwallau wrth ddechrau copi wrth gefn.
Ar yr un pryd, mae cronfeydd data mawr yn cael eu hategu mewn blociau ar draws edafedd lluosog, gan fodloni gofynion RPO a ffenestri wrth gefn. Nid yw'r llwyth ar y system yn sylweddol: Nid yw copïau llawn yn digwydd mor aml, ar ddiwrnodau eraill dim ond logiau a gesglir, ac yn ystod cyfnodau o lwyth isel.
Gyda llaw, rydym wedi cymhwyso polisïau ar wahân ar gyfer gwneud copïau wrth gefn o logiau archif PostgreSQL - maent yn cael eu storio yn unol â rheolau gwahanol, eu copïo yn unol ag amserlen wahanol, ac nid yw dad-ddyblygu wedi'i alluogi ar eu cyfer, gan fod y logiau hyn yn cynnwys data unigryw.
Er mwyn sicrhau cysondeb ar draws yr holl seilwaith TG, gosodir cleientiaid ffeiliau Commvault ar wahân ar bob un o nodau'r clwstwr. Maent yn eithrio ffeiliau Postgres o gopïau wrth gefn ac fe'u bwriedir ar gyfer copïau wrth gefn OS a rhaglenni yn unig. Mae gan y rhan hon o'r data hefyd ei pholisi a'i chyfnod storio ei hun.
Ar hyn o bryd, nid yw IBS yn effeithio ar wasanaethau cynhyrchiant, ond os bydd y sefyllfa'n newid, gall Commvault alluogi cyfyngu llwyth.
Ydy e'n dda? Da!
Felly, rydym wedi derbyn nid yn unig copi wrth gefn ymarferol, ond hefyd copi wrth gefn cwbl awtomataidd ar gyfer gosodiad clwstwr PostgreSQL, ac mae'n bodloni'r holl ofynion ar gyfer galwadau menter.
Mae paramedrau RPO a RTO o 1 awr a 2 awr wedi'u gorchuddio ag ymyl, sy'n golygu y bydd y system yn cydymffurfio â nhw hyd yn oed gyda chynnydd sylweddol yn nifer y data sydd wedi'i storio. Yn groes i lawer o amheuon, trodd PostgreSQL a'r amgylchedd menter yn eithaf cydnaws. Ac yn awr rydym yn gwybod o'n profiad ein hunain bod copi wrth gefn ar gyfer DBMSs o'r fath yn bosibl mewn amrywiaeth eang o ffurfweddiadau.
Wrth gwrs, ar hyd y llwybr hwn roedd yn rhaid i ni wisgo saith pâr o esgidiau haearn, goresgyn nifer o anawsterau, camu ar sawl cribin a chywiro nifer o gamgymeriadau. Ond nawr mae'r dull gweithredu eisoes wedi'i brofi a gellir ei ddefnyddio i weithredu Ffynhonnell Agored yn lle DBMS perchnogol mewn amodau menter llym.
Ydych chi wedi ceisio gweithio gyda PostgreSQL mewn amgylchedd corfforaethol?
Awduron:
Oleg Lavrenov, peiriannydd dylunio systemau storio data, Jet Infosystems
Dmitry Erykin, peiriannydd dylunio systemau cyfrifiadurol yn Jet Infosystems
Ffynhonnell: hab.com