La CAP-teoremo estas la bazŝtono de distribua sistemteorio. Kompreneble, la diskutado ĉirkaŭ ĝi ne trankviliĝas: la difinoj en ĝi ne estas kanonikaj, kaj ne ekzistas strikta pruvo... Tamen, firme starante sur la pozicioj de ĉiutaga komuna sento™, ni intuicie komprenas, ke la teoremo estas vera.
La sola afero, kiu ne estas evidenta, estas la signifo de la litero "P". Kiam la areto estas dividita, ĝi decidas ĉu ne respondi ĝis kvorumo estas atingita, aŭ redoni la datumojn kiuj estas disponeblaj. Depende de la rezultoj de ĉi tiu elekto, la sistemo estas klasifikita kiel aŭ CP aŭ AP. Kasandra, ekzemple, povas konduti ambaŭmaniere, depende eĉ ne de la agordoj de la grapo, sed de la parametroj de ĉiu specifa peto. Sed se la sistemo ne estas "P" kaj ĝi disiĝas, do kio?
La respondo al ĉi tiu demando estas iom neatendita: CA-areto ne povas disiĝi.
Kia areto estas ĉi tio, kiu ne povas disiĝi?
Nemalhavebla atributo de tia areto estas komuna datumstokado. En la granda plimulto de kazoj, ĉi tio signifas konekti per SAN, kio limigas la uzon de CA-solvoj al grandaj entreprenoj kapablaj konservi SAN-infrastrukturon. Por ke pluraj serviloj funkciu kun la samaj datumoj, necesas amasigita dosiersistemo. Tiaj dosiersistemoj estas haveblaj en la paperaro HPE (CFS), Veritas (VxCFS) kaj IBM (GPFS).
Oracle RAC
La opcio Real Application Cluster unue aperis en 2001 kun la liberigo de Oracle 9i. En tia areto, pluraj servilaj petskriboj funkcias kun la sama datumbazo.
Oracle povas funkcii kun kaj grupigita dosiersistemo kaj sia propra solvo - ASM, Aŭtomata Stokado-Administrado.
Ĉiu kopio tenas sian propran ĵurnalon. La transakcio estas efektivigita kaj farita de unu okazo. Se kazo malsukcesas, unu el la pluvivaj aretnodoj (instancoj) legas sian protokolon kaj restarigas la perditajn datumojn - tiel certigante haveblecon.
Ĉiuj instancoj konservas sian propran kaŝmemoron, kaj la samaj paĝoj (blokoj) povas esti en la kaŝmemoroj de pluraj okazoj samtempe. Plie, se unu kazo bezonas paĝon kaj ĝi estas en la kaŝmemoro de alia petskribo, ĝi povas ricevi ĝin de sia najbaro uzante la kaŝmemoro-fuzian mekanismon anstataŭ legi de disko.
Sed kio okazas se unu el la okazoj bezonas ŝanĝi datumojn?
La propreco de Oracle estas, ke ĝi ne havas dediĉitan ŝlosilservon: se la servilo volas ŝlosi vicon, tiam la ŝlosila rekordo estas metita rekte sur la memorpaĝon, kie troviĝas la ŝlosita vico. Dank' al ĉi tiu aliro, Oracle estas la rendimenta ĉampiono inter monolitaj datumbazoj: la ŝlosa servo neniam fariĝas botelo. Sed en cluster-agordo, tia arkitekturo povas konduki al intensa rettrafiko kaj blokiĝo.
Post kiam rekordo estas ŝlosita, kazo sciigas ĉiujn aliajn okazojn, ke la paĝo, kiu stokas tiun rekordon, havas ekskluzivan tenon. Se alia okazo bezonas ŝanĝi rekordon sur la sama paĝo, ĝi devas atendi ĝis la ŝanĝoj al la paĝo estas faritaj, tio estas, la ŝanĝinformoj estas skribitaj al ĵurnalo sur disko (kaj la transakcio povas daŭri). Povas ankaŭ okazi, ke paĝo estos ŝanĝita sinsekve per pluraj kopioj, kaj tiam skribante la paĝon al disko vi devos ekscii, kiu konservas la nunan version de ĉi tiu paĝo.
Hazarde ĝisdatigi la samajn paĝojn trans malsamaj RAC-nodoj igas datumbazan efikecon draste malpliiĝi, ĝis la punkto kie aretrendimento povas esti pli malalta ol tiu de ununura kazo.
La ĝusta uzo de Oracle RAC estas fizike dispartigi la datumojn (ekzemple, uzante dividitan tabelmekanismon) kaj aliri ĉiun aron de sekcioj per dediĉita nodo. La ĉefcelo de RAC ne estis horizontala skalado, sed certigado de faŭltoleremo.
Se nodo ĉesas respondi al korbato, tiam la nodo kiu detektis ĝin unue komencas voĉdonan proceduron sur la disko. Se la mankanta nodo ne estas notita ĉi tie, tiam unu el la nodoj prenas la respondecon pri reakiro de datumoj:
- "frostas" ĉiujn paĝojn kiuj estis en la kaŝmemoro de la mankanta nodo;
- legas la protokolojn (refari) de la mankanta nodo kaj re aplikas la ŝanĝojn registritajn en ĉi tiuj protokoloj, samtempe kontrolante ĉu aliaj nodoj havas pli lastatempajn versiojn de la paĝoj ŝanĝantaj;
- ruliĝas reen atendatajn transakciojn.
Por simpligi ŝanĝadon inter nodoj, Oracle havas la koncepton de servo - virtuala kazo. Kazo povas servi plurajn servojn, kaj servo povas moviĝi inter nodoj. Aplikkazaĵo servanta certan parton de la datumbazo (ekzemple, grupo de klientoj) funkcias kun unu servo, kaj la servo respondeca por tiu parto de la datumbazo moviĝas al alia nodo kiam nodo malsukcesas.
IBM Pure Data Systems por Transakcioj
Aretsolvo por DBMS aperis en la paperaro de Blue Giant en 2009. Ideologie, ĝi estas la posteulo de la Parallel Sysplex-areto, konstruita sur "regula" ekipaĵo. En 2009, DB2 pureScale estis publikigita kiel programaro, kaj en 2012, IBM ofertis aparaton nomitan Pure Data Systems for Transactions. Ĝi ne devus esti konfuzita kun Pure Data Systems for Analytics, kiu estas nenio pli ol renomita Netezza.
Unuavide, la pureScale-arkitekturo similas al Oracle RAC: en la sama maniero, pluraj nodoj estas konektitaj al ofta datumstokado-sistemo, kaj ĉiu nodo prizorgas sian propran DBMS-instancon kun siaj propraj memorareoj kaj transakciaj protokoloj. Sed, male al Oracle, DB2 havas dediĉitan ŝlosan servon reprezentitan per aro de db2LLM*-procezoj. En aretkonfiguracio, ĉi tiu servo estas metita sur apartan nodon, kiu estas nomita kunliga instalaĵo (CF) en Parallel Sysplex, kaj PowerHA en Pure Data.
PowerHA disponigas la sekvajn servojn:
- seruro peranto;
- tutmonda bufrokaŝmemoro;
- areo de interprocezaj komunikadoj.
Por transdoni datumojn de PowerHA al la datumbazaj nodoj kaj reen, fora memoraliro estas uzata, do la areto-interkonekto devas subteni la RDMA-protokolon. PureScale povas uzi kaj Infiniband kaj RDMA super Ethernet.
Se nodo bezonas paĝon, kaj ĉi tiu paĝo ne estas en la kaŝmemoro, tiam la nodo petas la paĝon en la tutmonda kaŝmemoro, kaj nur se ĝi ne estas tie, legas ĝin el disko. Male al Oracle, la peto iras nur al PowerHA, kaj ne al najbaraj nodoj.
Se okazo ŝanĝos vicon, ĝi ŝlosas ĝin en ekskluziva reĝimo, kaj la paĝon kie la vico situas en komuna reĝimo. Ĉiuj seruroj estas registritaj en la tutmonda seruro-administranto. Kiam la transakcio finiĝas, la nodo sendas mesaĝon al la seruro-administranto, kiu kopias la modifitan paĝon al la tutmonda kaŝmemoro, liberigas la serurojn kaj nuligas la modifitan paĝon en la kaŝmemoroj de aliaj nodoj.
Se la paĝo, en kiu troviĝas la modifita vico, estas jam ŝlosita, tiam la seruro-administranto legos la modifitan paĝon el la memoro de la nodo, kiu faris la ŝanĝon, liberigu la seruron, malvalidigos la modifitan paĝon en la kaŝmemoroj de aliaj nodoj, kaj donu la paĝan seruron al la nodo, kiu petis ĝin.
"Malpuraj", tio estas, ŝanĝitaj, paĝoj povas esti skribitaj al disko kaj de regula nodo kaj de PowerHA (castout).
Se unu el la pureScale-nodoj malsukcesas, reakiro estas limigita al nur tiuj transakcioj kiuj ankoraŭ ne estis kompletigitaj en la momento de fiasko: la paĝoj modifitaj de tiu nodo en finitaj transakcioj estas en la tutmonda kaŝmemoro sur PowerHA. La nodo rekomencas en reduktita agordo sur unu el la serviloj en la areto, restarigas atendatajn transakciojn kaj liberigas serurojn.
PowerHA funkcias per du serviloj kaj la majstra nodo reproduktas sian staton sinkrone. Se la primara PowerHA-nodo malsukcesas, la areto daŭre funkcias kun la rezerva nodo.
Kompreneble, se vi aliras la datuman aron per ununura nodo, la ĝenerala rendimento de la areto estos pli alta. PureScale eĉ povas rimarki, ke certa areo de datumoj estas prilaborata de unu nodo, kaj tiam ĉiuj seruroj rilataj al tiu areo estos prilaboritaj loke de la nodo sen komuniki kun PowerHA. Sed tuj kiam la aplikaĵo provos aliri ĉi tiujn datumojn per alia nodo, la centralizita seruro-pretigo rekomencos.
La internaj testoj de IBM pri laborkvanto de 90% legado kaj 10% skribado, kiu estas tre simila al realmondaj produktadŝarĝoj, montras preskaŭ linearan skalon ĝis 128 nodoj. Testkondiĉoj, bedaŭrinde, ne estas malkaŝitaj.
HPE NonStop SQL
La biletujo de Hewlett-Packard Enterprise ankaŭ havas sian propran tre disponeblan platformon. Ĉi tio estas la NonStop-platformo, liberigita al la merkato en 1976 fare de Tandem Computers. En 1997, la firmao estis akirita fare de Compaq, kiu en victurno kunfalis kun Hewlett-Packard en 2002.
NonStop estas uzata por konstrui kritikajn aplikojn - ekzemple, HLR aŭ bankkartpretigo. La platformo estas liverita en formo de komplekso de programaro kaj aparataro (aparato), kiu inkluzivas komputajn nodojn, datumstokan sistemon kaj komunikajn ekipaĵojn. La reto ServerNet (en modernaj sistemoj - Infiniband) servas kaj por interŝanĝo inter nodoj kaj por aliro al la datumstokada sistemo.
Fruaj versioj de la sistemo uzis proprietajn procesorojn, kiuj estis sinkronigitaj unu kun la alia: ĉiuj operacioj estis faritaj sinkrone de pluraj procesoroj, kaj tuj kiam unu el la procesoroj faris eraron, ĝi estis malŝaltita, kaj la dua daŭre funkciis. Poste, la sistemo ŝanĝis al konvenciaj procesoroj (unue MIPS, tiam Itanium kaj finfine x86), kaj aliaj mekanismoj komencis esti uzitaj por sinkronigado:
- mesaĝoj: ĉiu sistema procezo havas "ombron" ĝemelo, al kiu la aktiva procezo periode sendas mesaĝojn pri sia stato; se la ĉefa procezo malsukcesas, la ombroprocezo ekfunkcias de la momento determinita de la lasta mesaĝo;
- voĉdonado: la stokadsistemo havas specialan aparataron komponanton kiu akceptas plurajn identajn alirojn kaj efektivigas ilin nur se la aliroj kongruas; Anstataŭ fizika sinkronigo, procesoroj funkcias nesinkrone, kaj la rezultoj de sia laboro estas komparitaj nur ĉe I/O-momentoj.
Ekde 1987, interrilata DBMS funkcias sur la platformo NonStop - unue SQL/MP, kaj poste SQL/MX.
La tuta datumbazo estas dividita en partojn, kaj ĉiu parto respondecas pri sia propra Data Access Manager (DAM) procezo. Ĝi disponigas datumregistradon, kaŝmemoron kaj ŝlosajn mekanismojn. Datumtraktado estas efektivigita de Executor Server Processes kurantaj sur la samaj nodoj kiel la respondaj datummanaĝeroj. La SQL/MX-planilo dividas taskojn inter ekzekutistoj kaj agregas la rezultojn. Kiam estas necese fari interkonsentitajn ŝanĝojn, la dufaza kommitprotokolo provizita de la biblioteko TMF (Transaction Management Facility) estas uzata.
NonStop SQL povas prioritatigi procezojn tiel ke longaj analizaj demandoj ne malhelpas transakcian plenumon. Tamen, ĝia celo estas ĝuste la prilaborado de mallongaj transakcioj, kaj ne analitiko. La programisto garantias la haveblecon de la NonStop-grupo je la nivelo de kvin "naŭoj", tio estas, malfunkcio estas nur 5 minutoj jare.
SAP-HANA
La unua stabila eldono de la HANA DBMS (1.0) okazis en novembro 2010, kaj la SAP ERP-pakaĵo ŝanĝis al HANA en majo 2013. La platformo baziĝas sur aĉetitaj teknologioj: TREX Serĉilo (serĉo en kolona stokado), P*TIME DBMS kaj MAX DB.
La vorto "HANA" mem estas akronimo, High performance ANalytical Appliance. Ĉi tiu DBMS estas liverita en formo de kodo, kiu povas funkcii per iuj x86-serviloj, tamen, industriaj instalaĵoj estas permesitaj nur sur atestitaj ekipaĵoj. Solvoj haveblaj de HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Iuj Lenovo-agordoj eĉ permesas funkciadon sen SAN - la rolon de komuna stokada sistemo ludas GPFS-areto sur lokaj diskoj.
Male al la platformoj listigitaj supre, HANA estas en-memora DBMS, t.e. la primara datuma bildo estas stokita en RAM, kaj nur protokoloj kaj periodaj momentfotoj estas skribitaj al disko por reakiro en kazo de katastrofo.
Ĉiu HANA-clusternodo respondecas pri sia propra parto de la datumoj, kaj la datummapo estas konservita en speciala komponento - Nomservilo, situanta sur la kunordiga nodo. Datenoj ne estas duobligitaj inter nodoj. Ŝlosinformoj ankaŭ estas stokitaj sur ĉiu nodo, sed la sistemo havas tutmondan blokan detektilon.
Kiam HANA-kliento konektas al areto, ĝi elŝutas sian topologion kaj tiam povas aliri iun ajn nodon rekte, depende de kiaj datumoj ĝi bezonas. Se transakcio influas la datumojn de ununura nodo, tiam ĝi povas esti efektivigita loke per tiu nodo, sed se la datumoj de pluraj nodoj ŝanĝiĝas, la komenca nodo kontaktas la kunordigan nodon, kiu malfermas kaj kunordigas la distribuitan transakcion, farante ĝin uzante optimumigita dufaza kommit protokolo.
La kunordiganto-nodo estas duobligita, do se la kunordiganto malsukcesas, la rezerva nodo tuj transprenas. Sed se nodo kun datumoj malsukcesas, tiam la nura maniero aliri ĝiajn datumojn estas rekomenci la nodon. Kiel regulo, HANA-aretoj konservas rezervan servilon por rekomenci perditan nodon sur ĝi kiel eble plej rapide.
fonto: www.habr.com