CAP setningin er hornsteinn dreifðkerfakenningarinnar. Auðvitað minnkar deilan í kringum hana ekki: skilgreiningarnar í henni eru ekki kanónískar og það eru engar strangar sannanir... Engu að síður, staðfastlega á afstöðu hversdagslegrar skynsemi™, skiljum við innsæi að setningin er sönn.
Það eina sem er ekki augljóst er merking bókstafsins "P". Þegar klasanum er skipt ákveður hann hvort eigi að bregðast við fyrr en ályktun er náð, eða skila til baka þau gögn sem liggja fyrir. Það fer eftir niðurstöðum þessa vals, kerfið er flokkað sem annað hvort CP eða AP. Cassandra, til dæmis, getur hegðað sér á hvorn veginn sem er, fer ekki einu sinni eftir klasastillingunum, heldur breytum hverrar tiltekinnar beiðni. En ef kerfið er ekki "P" og það klofnar, hvað þá?
Svarið við þessari spurningu er nokkuð óvænt: CA þyrping getur ekki skipt sér.
Hvers konar þyrping er þetta sem getur ekki klofnað?
Nauðsynlegur eiginleiki slíks klasa er sameiginlegt gagnageymslukerfi. Í langflestum tilfellum þýðir þetta tengingu í gegnum SAN, sem takmarkar notkun CA-lausna við stór fyrirtæki sem geta viðhaldið SAN-innviðum. Til þess að nokkrir... netþjónum Til að vinna með sömu gögnin þarf klasaskráarkerfi. Slík skráarkerfi eru fáanleg í vöruúrvali HPE (CFS), Veritas (VxCFS) og IBM (GPFS).
Oracle RAC
Valkosturinn Real Application Cluster birtist fyrst árið 2001 með útgáfu Oracle 9i. Í slíkum klasa eru mörg tilvik miðlara vinna með sama gagnagrunninn.
Oracle getur unnið bæði með klasaskráakerfi og sína eigin lausn - ASM, Automatic Storage Management.
Hvert eintak heldur sína dagbók. Viðskiptin eru framkvæmd og framin af einu tilviki. Ef tilvik mistekst, les einn af eftirlifandi klasahnútum (tilvikum) skráningu þess og endurheimtir týnd gögn - og tryggir þar með aðgengi.
Öll tilvik halda sínu eigin skyndiminni og sömu síður (kubbar) geta verið í skyndiminni margra tilvika á sama tíma. Þar að auki, ef eitt tilvik þarf síðu og það er í skyndiminni annars tilviks, getur það fengið það frá nágranna sínum með því að nota skyndiminnissamrunabúnaðinn í stað þess að lesa af diski.
En hvað gerist ef eitt tilvikanna þarf að breyta gögnum?
Sérkenni Oracle er að það er ekki með sérstaka læsingarþjónustu: ef þjónninn vill læsa röð, þá er læsaskráin sett beint á minnissíðuna þar sem læsta röðin er staðsett. Þökk sé þessari nálgun er Oracle frammistöðumeistari meðal einhæfra gagnagrunna: læsingarþjónustan verður aldrei flöskuháls. En í klasauppsetningu getur slíkur arkitektúr leitt til mikillar netumferðar og stöðvunar.
Þegar skrá hefur verið læst, lætur tilvik öll önnur tilvik tilkynna að síðan sem geymir þá skrá hafi einkarétt. Ef annað tilvik þarf að breyta færslu á sömu síðu verður það að bíða þar til breytingarnar á síðunni eru framkvæmdar, það er að breytingaupplýsingarnar eru skrifaðar í dagbók á diski (og viðskiptin geta haldið áfram). Það getur líka gerst að síðu verði breytt í röð í nokkrum eintökum, og þegar þú skrifar síðuna á disk verður þú að finna út hver geymir núverandi útgáfu af þessari síðu.
Að uppfæra sömu síður af handahófi yfir mismunandi RAC hnúta veldur því að árangur gagnagrunns lækkar verulega, að þeim stað þar sem frammistaða klasa getur verið lægri en einstaks tilviks.
Rétt notkun Oracle RAC er að skipta gögnunum líkamlega í sundur (til dæmis með skiptingu töflukerfi) og fá aðgang að hverju setti skiptinga í gegnum sérstakan hnút. Megintilgangur RAC var ekki lárétt mælikvarði, heldur að tryggja bilanaþol.
Ef hnútur hættir að svara hjartslætti, þá byrjar hnúturinn sem fann hann fyrst atkvæðagreiðslu á disknum. Ef hnúturinn sem vantar er ekki skráður hér, þá tekur einn af hnútunum á sig ábyrgðina á endurheimt gagna:
- „frystir“ allar síður sem voru í skyndiminni hnútsins sem vantar;
- les annála (endurgera) hnútsins sem vantar og endurnýjar breytingarnar sem skráðar eru í þessum annálum og athugar samtímis hvort aðrir hnútar hafi nýlegri útgáfur af síðunum sem verið er að breyta;
- afturkallar færslur sem bíða.
Til að einfalda skiptingu á milli hnúta hefur Oracle hugmyndina um þjónustu - sýndartilvik. Tilvik getur þjónað mörgum þjónustum og þjónusta getur flutt á milli hnúta. Forritstilvik sem þjónar ákveðnum hluta gagnagrunnsins (til dæmis hóp viðskiptavina) vinnur með einni þjónustu og þjónustan sem ber ábyrgð á þessum hluta gagnagrunnsins færist yfir á annan hnút þegar hnút bilar.
IBM Pure Data Systems for Transactions
Klasalausn fyrir DBMS birtist í Blue Giant eignasafninu árið 2009. Hugmyndafræðilega er það arftaki Parallel Sysplex klasans, byggður á „venjulegum“ búnaði. Árið 2009 kom DB2 pureScale út sem hugbúnaðarsvíta og árið 2012 bauð IBM upp á tæki sem kallast Pure Data Systems for Transactions. Það ætti ekki að rugla saman við Pure Data Systems for Analytics, sem er ekkert annað en endurnefnt Netezza.
Við fyrstu sýn er pureScale arkitektúrinn svipaður og Oracle RAC: á sama hátt eru nokkrir hnútar tengdir sameiginlegu gagnageymslukerfi og hver hnút rekur sitt eigið DBMS tilvik með eigin minnissvæðum og færsluskrám. En ólíkt Oracle er DB2 með sérstaka læsingarþjónustu sem er táknuð með safni db2LLM* ferla. Í klasastillingu er þessi þjónusta sett á sérstakan hnút, sem kallast coupling facility (CF) í Parallel Sysplex, og PowerHA í Pure Data.
PowerHA veitir eftirfarandi þjónustu:
- lásstjóri;
- alþjóðlegt biðminni skyndiminni;
- svæði milli vinnslusamskipta.
Til að flytja gögn frá PowerHA til gagnagrunnshnúta og til baka er fjarlægur minnisaðgangur notaður, þannig að klasasamtengingin verður að styðja RDMA samskiptareglur. PureScale getur notað bæði Infiniband og RDMA yfir Ethernet.
Ef hnútur þarf síðu, og þessi síða er ekki í skyndiminni, þá biður hnúturinn um síðuna í alheims skyndiminni, og aðeins ef hún er ekki til staðar, les hana af disknum. Ólíkt Oracle fer beiðnin aðeins til PowerHA en ekki til nálægra hnúta.
Ef tilvik ætlar að breyta röð, læsir það henni í einkastillingu og síðunni þar sem röðin er staðsett í samnýttum ham. Allir læsingar eru skráðir í alheimslásastjóranum. Þegar viðskiptunum er lokið sendir hnúturinn skilaboð til lásstjórans, sem afritar breyttu síðuna í alheims skyndiminni, losar lásana og ógildir breyttu síðuna í skyndiminni annarra hnúta.
Ef síðan sem breytta röðin er á er þegar læst, þá mun læsastjórinn lesa breyttu síðuna úr minni hnútsins sem gerði breytinguna, losa lásinn, ógilda breyttu síðuna í skyndiminni annarra hnúta og gefðu síðulásinn á hnútinn sem bað um það.
"Dirty", það er breytt, síður er hægt að skrifa á diskinn bæði frá venjulegum hnút og frá PowerHA (castout).
Ef einn af pureScale hnútunum mistakast takmarkast endurheimt við aðeins þær færslur sem ekki var enn lokið þegar bilunin varð: síðurnar sem þeim hnút breytt í lokuðum viðskiptum eru í alheims skyndiminni á PowerHA. Hnúturinn endurræsir sig í minni stillingu á einum af netþjónunum í þyrpingunni, rúllar til baka færslur sem bíða og losar læsingar.
PowerHA keyrir á tveimur netþjónum og aðalhnúturinn endurtekur ástand sitt samstillt. Ef aðal PowerHA hnúturinn bilar heldur þyrpingin áfram að starfa með varahnútnum.
Auðvitað, ef þú nálgast gagnasettið í gegnum einn hnút, verður heildarframmistaða þyrpingarinnar hærri. PureScale getur jafnvel tekið eftir því að ákveðið svæði gagna er unnið af einum hnút og þá verða allir læsingar sem tengjast því svæði unnar á staðnum af hnútnum án þess að hafa samskipti við PowerHA. En um leið og forritið reynir að fá aðgang að þessum gögnum í gegnum annan hnút, mun miðlæg læsing vinna aftur.
Innri prófanir IBM á vinnuálagi upp á 90% lestur og 10% skrif, sem er mjög svipað og raunverulegt framleiðsluálag, sýna nánast línulega skala upp í 128 hnúta. Prófskilyrði eru því miður ekki gefin upp.
HPE NonStop SQL
Hewlett-Packard Enterprise eignasafnið hefur einnig sinn eigin mjög fáanlega vettvang. Þetta er NonStop vettvangurinn sem kom út á markað árið 1976 af Tandem Computers. Árið 1997 var fyrirtækið keypt af Compaq, sem síðan sameinaðist Hewlett-Packard árið 2002.
NonStop er notað til að byggja upp mikilvæg forrit - til dæmis HLR eða bankakortavinnslu. Vettvangurinn er afhentur í formi hugbúnaðar- og vélbúnaðarsamstæðu (appliance), sem inniheldur tölvuhnúta, gagnageymslukerfi og samskiptabúnað. ServerNet netið (í nútíma kerfum - Infiniband) þjónar bæði fyrir skipti á milli hnúta og fyrir aðgang að gagnageymslukerfinu.
Fyrstu útgáfur kerfisins notuðu sér örgjörva sem voru samstilltir hver við annan: allar aðgerðir voru gerðar samstillt af nokkrum örgjörvum og um leið og einn af örgjörvunum gerði villu var slökkt á honum og sá seinni hélt áfram að virka. Síðar skipti kerfið yfir í hefðbundna örgjörva (fyrst MIPS, síðan Itanium og loks x86), og önnur tæki fóru í notkun til samstillingar:
- skilaboð: hvert kerfisferli hefur „skugga“ tvíbura, sem virka ferlið sendir reglulega skilaboð um stöðu sína; ef aðalferlið mistekst, byrjar skuggaferlið að virka frá því augnabliki sem ákvarðast af síðustu skilaboðum;
- atkvæðagreiðsla: geymslukerfið hefur sérstakan vélbúnaðarhluta sem tekur við mörgum eins aðgangi og framkvæmir þá aðeins ef aðgangarnir passa saman; Í stað líkamlegrar samstillingar starfa örgjörvar ósamstillt og niðurstöður vinnu þeirra eru aðeins bornar saman á I/O augnablikum.
Síðan 1987 hefur venslabundið DBMS verið keyrt á NonStop pallinum - fyrst SQL/MP og síðar SQL/MX.
Allur gagnagrunnurinn er skipt í hluta og hver hluti ber ábyrgð á sínu eigin Data Access Manager (DAM) ferli. Það býður upp á gagnaupptöku, skyndiminni og læsingarkerfi. Gagnavinnsla fer fram af Executor Server Processes sem keyra á sömu hnútum og samsvarandi gagnastjórar. SQL/MX tímaáætlunarmaðurinn skiptir verkum á milli framkvæmdastjóra og safnar saman niðurstöðunum. Þegar nauðsynlegt er að gera samþykktar breytingar er tveggja fasa skuldbindingarsamskiptareglur sem TMF (Transaction Management Facility) bókasafnið veitir notuð.
NonStop SQL getur forgangsraðað ferlum þannig að langar greiningarfyrirspurnir trufli ekki framkvæmd viðskipta. Hins vegar er tilgangur þess einmitt vinnsla stuttra viðskipta, en ekki greiningar. Framkvæmdaraðilinn ábyrgist framboð á NonStop þyrpingunni á stigi fimm „níur“, það er að niður í miðbæ er aðeins 5 mínútur á ári.
SAP-HANA
Fyrsta stöðuga útgáfan af HANA DBMS (1.0) fór fram í nóvember 2010 og SAP ERP pakkinn skipti yfir í HANA í maí 2013. Vettvangurinn er byggður á keyptri tækni: TREX leitarvél (leit í dálkageymslu), P*TIME DBMS og MAX DB.
Orðið „HANA“ sjálft er skammstöfun, High Performance Analytical Appliance. Þetta DBMS er til staðar í formi kóða sem getur keyrt á hvaða x86 netþjónum sem er, en iðnaðaruppsetningar eru aðeins leyfðar á vottuðum búnaði. Lausnir fáanlegar frá HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Sumar Lenovo stillingar leyfa jafnvel notkun án SAN - hlutverk sameiginlegs geymslukerfis er gegnt af GPFS þyrping á staðbundnum diskum.
Ólíkt pöllunum sem taldir eru upp hér að ofan er HANA DBMS í minni, þ.e.a.s. aðalgagnamyndin er geymd í vinnsluminni og aðeins annálar og reglubundnar skyndimyndir eru skrifaðar á diskinn til endurheimtar ef hamfarir verða.
Hver HANA klasahnútur ber ábyrgð á sínum hluta gagnanna og gagnakortið er geymt í sérstökum hluta – nafnaþjóni, sem staðsettur er á samræmingarhnútnum. Gögn eru ekki afrituð á milli hnúta. Læsingarupplýsingar eru einnig geymdar á hverjum hnút, en kerfið er með alþjóðlegum stöðvunarskynjara.
Þegar HANA viðskiptavinur tengist klasa, hleður hann niður staðfræði hans og getur síðan nálgast hvaða hnút sem er beint, allt eftir því hvaða gögn hann þarfnast. Ef viðskipti hafa áhrif á gögn eins hnúts, þá er hægt að framkvæma þau á staðnum af þeim hnút, en ef gögn nokkurra hnúta breytast, hefur upphafshnúturinn samband við samræmingarhnútinn, sem opnar og samhæfir dreifðu færsluna og framkvæmir þau með því að nota bjartsýni tveggja fasa skuldbindingarferils.
Samhæfingarhnúturinn er tvítekinn, þannig að ef samræmingarstjórinn mistekst tekur varahnúturinn strax við. En ef hnútur með gögnum mistekst, þá er eina leiðin til að fá aðgang að gögnum hans að endurræsa hnútinn. Að jafnaði halda HANA þyrpingar varaþjóni til að endurræsa glataðan hnút á honum eins fljótt og auðið er.
Heimild: www.habr.com
