ProHoster > Blogs > Administrācija > Izplatīta DBVS uzņēmumam

Izplatīta DBVS uzņēmumam

KLP teorēma ir sadalÄ«to sistēmu teorijas stÅ«rakmens. Protams, strÄ«ds ap to nerimst: definÄ«cijas tajā nav kanoniskas, un nav arÄ« stingru pierādÄ«jumu... Tomēr, stingri nostājoties uz ikdienas veselā saprātaā„¢ pozÄ«cijām, mēs intuitÄ«vi saprotam, ka teorēma ir patiesa.

Izplatīta DBVS uzņēmumam

VienÄ«gais, kas nav acÄ«mredzams, ir burta "P" nozÄ«me. Kad klasteris ir sadalÄ«ts, tas izlemj, vai neatbildēt, kamēr nav sasniegts kvorums, vai atdot atpakaļ pieejamos datus. AtkarÄ«bā no Ŕīs izvēles rezultātiem sistēma tiek klasificēta kā CP vai AP. Piemēram, Cassandra var uzvesties jebkurā veidā, pat ne atkarÄ«bā no klastera iestatÄ«jumiem, bet gan no katra konkrētā pieprasÄ«juma parametriem. Bet, ja sistēma nav "P" un tā sadalās, ko tad?

Atbilde uz Ŕo jautājumu ir nedaudz negaidīta: CA klasteris nevar sadalīties.
Kas tas par kopu, kas nevar sadalīties?

Šāda klastera neaizstājams atribÅ«ts ir koplietoÅ”anas datu uzglabāŔanas sistēma. Lielākajā daļā gadÄ«jumu tas nozÄ«mē savienojuma izveidi, izmantojot SAN, kas ierobežo CA risinājumu izmantoÅ”anu lieliem uzņēmumiem, kas spēj uzturēt SAN infrastruktÅ«ru. Lai vairāki serveri varētu strādāt ar vieniem un tiem paÅ”iem datiem, ir nepiecieÅ”ama klasteru failu sistēma. Šādas failu sistēmas ir pieejamas HPE (CFS), Veritas (VxCFS) un IBM (GPFS) portfeļos.

Oracle RAC

Real Application Cluster opcija pirmo reizi parādījās 2001. gadā, izlaižot Oracle 9i. Šādā klasterī vairāki servera gadījumi strādā ar vienu un to paŔu datu bāzi.
Oracle var strādāt gan ar klasteru failu sistēmu, gan ar savu risinājumu ā€“ ASM, Automatic Storage Management.

Katram eksemplāram ir savs žurnāls. DarÄ«jumu izpilda un apņemas viena instance. Ja gadÄ«jums neizdodas, viens no izdzÄ«vojuÅ”ajiem klastera mezgliem (gadÄ«jumiem) nolasa tā žurnālu un atjauno zaudētos datus, tādējādi nodroÅ”inot pieejamÄ«bu.

Visas instances uztur savu keÅ”atmiņu, un tās paÅ”as lapas (bloki) var atrasties vairāku gadÄ«jumu keÅ”atmiņā vienlaikus. Turklāt, ja vienai instancei ir nepiecieÅ”ama lapa un tā atrodas citas instances keÅ”atmiņā, tā var to iegÅ«t no kaimiņa, izmantojot keÅ”atmiņas sapludināŔanas mehānismu, nevis nolasot no diska.

Izplatīta DBVS uzņēmumam

Bet kas notiek, ja kādam no gadījumiem ir jāmaina dati?

Oracle Ä«patnÄ«ba ir tāda, ka tai nav speciāla bloÄ·Ä“Å”anas pakalpojuma: ja serveris vēlas bloķēt rindu, tad bloÄ·Ä“Å”anas ieraksts tiek ievietots tieÅ”i atmiņas lapā, kurā atrodas bloķētā rinda. Pateicoties Å”ai pieejai, Oracle ir veiktspējas čempions monolÄ«tu datu bāzu vidÅ«: bloÄ·Ä“Å”anas pakalpojums nekad nekļūst par vājo vietu. Taču klastera konfigurācijā Ŕāda arhitektÅ«ra var izraisÄ«t intensÄ«vu tÄ«kla trafiku un strupceļus.

Kad ieraksts ir bloķēts, gadÄ«jums paziņo visiem pārējiem gadÄ«jumiem, ka lapai, kurā ieraksts tiek glabāts, ir ekskluzÄ«va aizturÄ“Å”ana. Ja citai instancei ir jāmaina ieraksts tajā paŔā lapā, tai ir jāgaida, lÄ«dz tiek veiktas lapas izmaiņas, tas ir, izmaiņu informācija tiek ierakstÄ«ta žurnālā diskā (un darÄ«jumu var turpināt). Var gadÄ«ties arÄ« tā, ka lapa tiks mainÄ«ta secÄ«gi par vairākiem eksemplāriem, un tad, rakstot lapu diskā, bÅ«s jānoskaidro, kas glabā Ŕīs lapas aktuālo versiju.

NejauÅ”i atjauninot vienas un tās paÅ”as lapas dažādos RAC mezglos, datu bāzes veiktspēja krasi samazinās lÄ«dz vietai, kur klastera veiktspēja var bÅ«t zemāka nekā viena gadÄ«juma veiktspēja.

Pareiza Oracle RAC izmantoÅ”ana ir datu fiziska sadalÄ«Å”ana (piemēram, izmantojot sadalÄ«tās tabulas mehānismu) un piekļuve katrai nodalÄ«jumu kopai, izmantojot Ä«paÅ”u mezglu. RAC galvenais mērÄ·is nebija horizontālā mērogoÅ”ana, bet gan kļūdu tolerances nodroÅ”ināŔana.

Ja mezgls pārstāj reaģēt uz sirdspukstiem, mezgls, kas to atklāja pirmais, diskā sāk balsoÅ”anas procedÅ«ru. Ja trÅ«kstoÅ”ais mezgls Å”eit nav atzÄ«mēts, viens no mezgliem uzņemas atbildÄ«bu par datu atkopÅ”anu:

  • ā€œiesaldēā€ visas lapas, kas atradās trÅ«kstoŔā mezgla keÅ”atmiņā;
  • nolasa trÅ«kstoŔā mezgla žurnālus (pārtaisa) un atkārtoti piemēro Å”ajos žurnālos ierakstÄ«tās izmaiņas, vienlaikus pārbaudot, vai citos mezglos nav jaunākas maināmo lapu versijas;
  • atceļ nepabeigtos darÄ«jumus.

Lai vienkārÅ”otu pārslēgÅ”anos starp mezgliem, Oracle ir pakalpojuma jēdziens ā€” virtuāla instance. Eksemplārs var apkalpot vairākus pakalpojumus, un pakalpojums var pārvietoties starp mezgliem. Lietojumprogrammas instance, kas apkalpo noteiktu datu bāzes daļu (piemēram, klientu grupa), strādā ar vienu pakalpojumu, un pakalpojums, kas ir atbildÄ«gs par Å”o datu bāzes daļu, tiek pārvietots uz citu mezglu, ja mezgls neizdodas.

IBM Pure Data Systems darījumiem

2009. gadā Blue Giant portfelÄ« parādÄ«jās klasteru risinājums DBVS. IdeoloÄ£iski tas ir Parallel Sysplex klastera pēctecis, kas veidots uz ā€œparastāmā€ iekārtām. 2009. gadā DB2 pureScale tika izlaists kā programmatÅ«ras komplekts, un 2012. gadā IBM piedāvāja ierÄ«ci ar nosaukumu Pure Data Systems for Transactions. To nevajadzētu sajaukt ar Pure Data Systems for Analytics, kas ir nekas cits kā pārdēvēts Netezza.

No pirmā acu uzmetiena pureScale arhitektÅ«ra ir lÄ«dzÄ«ga Oracle RAC: tādā paŔā veidā vairāki mezgli ir savienoti ar kopēju datu glabāŔanas sistēmu, un katrs mezgls vada savu DBVS gadÄ«jumu ar saviem atmiņas apgabaliem un darÄ«jumu žurnāliem. Taču atŔķirÄ«bā no Oracle DB2 ir Ä«paÅ”s bloÄ·Ä“Å”anas pakalpojums, ko pārstāv db2LLM* procesu kopa. Klastera konfigurācijā Å”is pakalpojums ir novietots atseviŔķā mezglā, ko sauc par savienoÅ”anas iekārtu (CF) Parallel Sysplex un PowerHA Pure Data.

PowerHA sniedz Ŕādus pakalpojumus:

  • slēdzenes pārvaldnieks;
  • globālā bufera keÅ”atmiņa;
  • starpprocesu sakaru joma.

Lai pārsūtītu datus no PowerHA uz datu bāzes mezgliem un atpakaļ, tiek izmantota attālā piekļuve atmiņai, tāpēc klastera starpsavienojumam ir jāatbalsta RDMA protokols. PureScale var izmantot gan Infiniband, gan RDMA, izmantojot Ethernet.

Izplatīta DBVS uzņēmumam

Ja mezglam ir nepiecieÅ”ama lapa un Ŕī lapa nav keÅ”atmiņā, tad mezgls pieprasa lapu globālajā keÅ”atmiņā un tikai tad, ja tās nav, nolasa to no diska. AtŔķirÄ«bā no Oracle, pieprasÄ«jums tiek nosÅ«tÄ«ts tikai uz PowerHA, nevis uz blakus esoÅ”ajiem mezgliem.

Ja gadÄ«jums mainÄ«s rindu, tas bloķē to ekskluzÄ«vajā režīmā un lapu, kurā rinda atrodas, koplietoÅ”anas režīmā. Visas slēdzenes ir reÄ£istrētas globālajā slēdzeņu pārvaldniekā. Kad transakcija ir pabeigta, mezgls nosÅ«ta ziņojumu bloÄ·Ä“Å”anas pārvaldniekam, kas kopē modificēto lapu globālajā keÅ”atmiņā, atbrÄ«vo bloÄ·Ä“Å”anu un padara modificēto lapu nederÄ«gu citu mezglu keÅ”atmiņā.

Ja lapa, kurā atrodas modificētā rinda, jau ir bloķēta, bloÄ·Ä“Å”anas pārvaldnieks nolasÄ«s modificēto lapu no tā mezgla atmiņas, kurÅ” veicis izmaiņas, atbrÄ«vos bloÄ·Ä“Å”anu, padarÄ«s modificēto lapu nederÄ«gu citu mezglu keÅ”atmiņās un pieŔķiriet lapas bloÄ·Ä“Å”anu mezglam, kas to pieprasÄ«ja.

ā€œNetÄ«rasā€, tas ir, mainÄ«tas, lapas var ierakstÄ«t diskā gan no parastā mezgla, gan no PowerHA (castout).

Ja kāds no pureScale mezgliem neizdodas, atkopÅ”ana tiek ierobežota ar tikai tām transakcijām, kuras kļūmes brÄ«dÄ« vēl nebija pabeigtas: lapas, ko Å”is mezgls modificējis pabeigtajos darÄ«jumos, atrodas PowerHA globālajā keÅ”atmiņā. Mezgls tiek restartēts samazinātā konfigurācijā vienā no klastera serveriem, atgriež neapstiprinātās transakcijas un atbrÄ«vo bloÄ·Ä“Å”anas.

PowerHA darbojas divos serveros, un galvenais mezgls sinhroni atkārto tā stāvokli. Ja primārais PowerHA mezgls neizdodas, klasteris turpina darboties ar rezerves mezglu.
Protams, ja piekļūstat datu kopai, izmantojot vienu mezglu, kopas kopējā veiktspēja bÅ«s augstāka. PureScale pat var pamanÄ«t, ka noteiktu datu apgabalu apstrādā viens mezgls, un tad mezgls lokāli apstrādās visas ar Å”o apgabalu saistÄ«tās slēdzenes, nesazinoties ar PowerHA. Taču, tiklÄ«dz lietojumprogramma mēģinās piekļūt Å”iem datiem, izmantojot citu mezglu, tiks atsākta centralizētā bloÄ·Ä“Å”anas apstrāde.

IBM iekŔējie testi ar 90% lasÄ«Å”anas un 10% rakstÄ«Å”anas slodzi, kas ir ļoti lÄ«dzÄ«ga reālās pasaules ražoÅ”anas darba slodzei, parāda gandrÄ«z lineāru mērogoÅ”anu lÄ«dz 128 mezgliem. Diemžēl pārbaudes apstākļi netiek izpausti.

HPE NonStop SQL

Hewlett-Packard Enterprise portfelim ir arÄ« sava augsti pieejama platforma. Å Ä« ir NonStop platforma, ko 1976. gadā tirgÅ« laida Tandem Computers. 1997. gadā uzņēmumu iegādājās Compaq, kas savukārt 2002. gadā apvienojās ar Hewlett-Packard.

NonStop tiek izmantots, lai izveidotu kritiskas lietojumprogrammas, piemēram, HLR vai bankas karÅ”u apstrādi. Platforma tiek piegādāta programmatÅ«ras un aparatÅ«ras kompleksa (ierÄ«ces) veidā, kas ietver skaitļoÅ”anas mezglus, datu uzglabāŔanas sistēmu un sakaru iekārtas. ServerNet tÄ«kls (modernās sistēmās - Infiniband) kalpo gan apmaiņai starp mezgliem, gan piekļuvei datu uzglabāŔanas sistēmai.

Sistēmas sākotnējās versijās tika izmantoti patentēti procesori, kas tika sinhronizēti viens ar otru: visas darbības sinhroni veica vairāki procesori, un, tiklīdz kāds no procesoriem pieļāva kļūdu, tas tika izslēgts, bet otrais turpināja darboties. Vēlāk sistēma pārgāja uz parastajiem procesoriem (vispirms MIPS, tad Itanium un visbeidzot x86), un sinhronizācijai sāka izmantot citus mehānismus:

  • ziņojumi: katram sistēmas procesam ir ā€œÄ“nuā€ dvÄ«nis, kuram aktÄ«vais process periodiski sÅ«ta ziņojumus par tā statusu; ja galvenais process neizdodas, ēnu process sāk darboties no pēdējā ziņojuma noteiktā brīža;
  • balsoÅ”ana: krātuves sistēmai ir Ä«paÅ”s aparatÅ«ras komponents, kas pieņem vairākas identiskas pieejas un izpilda tās tikai tad, ja piekļuves sakrÄ«t; Fiziskās sinhronizācijas vietā procesori darbojas asinhroni, un to darba rezultāti tiek salÄ«dzināti tikai I/O momentos.

KopÅ” 1987. gada NonStop platformā darbojas relāciju DBVS ā€“ vispirms SQL/MP, vēlāk SQL/MX.

Visa datu bāze ir sadalÄ«ta daļās, un katra daļa ir atbildÄ«ga par savu Data Access Manager (DAM) procesu. Tas nodroÅ”ina datu ierakstÄ«Å”anas, keÅ”atmiņas saglabāŔanas un bloÄ·Ä“Å”anas mehānismus. Datu apstrādi veic Executor Server Processes, kas darbojas tajos paÅ”os mezglos kā attiecÄ«gie datu pārvaldnieki. SQL/MX plānotājs sadala uzdevumus starp izpildÄ«tājiem un apkopo rezultātus. Ja nepiecieÅ”ams veikt saskaņotas izmaiņas, tiek izmantots TMF (Transaction Management Facility) bibliotēkas nodroÅ”inātais divu fāzu saistÄ«bu izpildes protokols.

Izplatīta DBVS uzņēmumam

NonStop SQL var noteikt prioritāti procesiem, lai ilgi analÄ«tiskie vaicājumi netraucētu darÄ«jumu izpildi. Tomēr tā mērÄ·is ir tieÅ”i Ä«su darÄ«jumu apstrāde, nevis analÄ«tika. Izstrādātājs garantē NonStop klastera pieejamÄ«bu piecu ā€œdeviņuā€ lÄ«menÄ«, tas ir, dÄ«kstāves laiks ir tikai 5 minÅ«tes gadā.

SAP-HANA

Pirmā stabilā HANA DBMS (1.0) izlaiÅ”ana notika 2010. gada novembrÄ«, un SAP ERP pakotne tika pārslēgta uz HANA 2013. gada maijā. Platformas pamatā ir iegādātās tehnoloÄ£ijas: TREX Search Engine (meklÄ“Å”ana kolonnu krātuvē), P*TIME DBMS un MAX DB.

Pats vārds ā€œHANAā€ ir akronÄ«ms, augstas veiktspējas analÄ«tiskā ierÄ«ce. Å Ä« DBVS tiek piegādāta koda veidā, kas var darboties jebkurā x86 serverÄ«, tomēr rÅ«pnieciskās instalācijas ir atļautas tikai sertificētām iekārtām. Risinājumi pieejami no HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Dažas Lenovo konfigurācijas pat ļauj darboties bez SAN ā€” kopÄ«gas uzglabāŔanas sistēmas lomu pilda GPFS klasteris vietējos diskos.

AtŔķirÄ«bā no iepriekÅ” minētajām platformām, HANA ir atmiņā esoÅ”a DBVS, t.i., primārais datu attēls tiek glabāts RAM, un tikai žurnāli un periodiski momentuzņēmumi tiek ierakstÄ«ti diskā, lai tos atkoptu katastrofas gadÄ«jumā.

Izplatīta DBVS uzņēmumam

Katrs HANA klastera mezgls ir atbildÄ«gs par savu datu daļu, un datu karte tiek glabāta Ä«paŔā komponentā - Name Server, kas atrodas koordinatora mezglā. Dati netiek dublēti starp mezgliem. BloÄ·Ä“Å”anas informācija tiek saglabāta arÄ« katrā mezglā, taču sistēmai ir globāls strupceļa detektors.

Kad HANA klients izveido savienojumu ar klasteru, tas lejupielādē savu topoloÄ£iju un pēc tam var tieÅ”i piekļūt jebkuram mezglam atkarÄ«bā no tā, kādi dati tam ir nepiecieÅ”ami. Ja transakcija ietekmē viena mezgla datus, tad to var izpildÄ«t lokāli Å”is mezgls, bet, ja mainās vairāku mezglu dati, iniciējoÅ”ais mezgls sazinās ar koordinatora mezglu, kas atver un koordinē sadalÄ«to darÄ«jumu, veicot to, izmantojot optimizēts divfāzu apstiprināŔanas protokols.

Koordinatora mezgls tiek dublēts, tāpēc, ja koordinators neizdodas, rezerves mezgls nekavējoties pārņem. Bet, ja mezgls ar datiem neizdodas, vienÄ«gais veids, kā piekļūt tā datiem, ir mezgla restartÄ“Å”ana. Parasti HANA kopas saglabā rezerves serveri, lai pēc iespējas ātrāk restartētu tajā pazaudēto mezglu.

Avots: www.habr.com

Pievieno komentāru