Teorema CAP është themeli i teorisë së sistemeve të shpërndara. Sigurisht, polemikat rreth saj nuk pushojnë: as përkufizimet e saj nuk janë kanonike, dhe as nuk ka një provë të rreptë... Megjithatë, duke qëndruar fort mbi pozitat e shëndetit të zakonshëm™, ne e kuptojmë instinktivisht se teorema është e saktë.
E vetmja gjë që nuk është kaq e qartë është vlera e shkronjës "P". Kur klasteri ndahet, ai vendos - të mos përgjigjet derisa të arrihet një kuorum, ose të ofrojë të dhënat që ka. Në varësi të rezultateve të këtij zgjedhjeje, sistemi klasifikohet si CP ose AP. Cassandra, për shembull, mund të sillet kështu ose ashtu, jo vetëm në varësi të konfigurimeve të klasterit, por edhe të parametrave të çdo kërkese të veçantë. Por nëse sistemi nuk është "P", dhe ai është ndarë, atëherë – çfarë?
Përgjigjja për këtë pyetje është disi befasuese: një klaster CA nuk mund të ndahet.
Çfarë është ky klaster që nuk mund të ndahet?
Një atribut i domosdoshëm i këtij klasteri është sistemi i përbashkët i ruajtjes së të dhënave. Në shumicën dërrmuese të rasteve, kjo do të thotë lidhje përmes SAN, e cila e kufizon përdorimin e zgjidhjeve CA nga ndërmarrjet e mëdha që janë të afta të mbajnë një infrastrukturë SAN. Për të siguruar që disa serverëve mund të punojnë me të njëjtat të dhëna, nevojitet një sistem skedarësh klasteri. Të tilla sisteme skedarësh janë në portofolin e HPE (CFS), Veritas (VxCFS) dhe IBM (GPFS).
Oracle RAC
Opsioni Real Application Cluster u shfaq për herë të parë në vitin 2001 me publikimin e Oracle 9i. Në një klaster të tillë, disa instanca serverit punojnë me të njëjtën bazë të dhënash.
Oracle mund të punojë si me një sistem skedarësh klasteri, ashtu edhe me zgjidhjen e vet – ASM, Automatic Storage Management.
Çdo instancë mban një regjistër të saj. Transaksioni ekzekutohet dhe regjistrohet nga një instancë. Në rast dështimi të instancës, një nga nyjet e mbijetuara të klasterit (instancave) lexon regjistrin e saj dhe rikthen të dhënat e humbura – përmes kësaj sigurohet disponueshmëria.
Të gjitha instancat mbështesin një cache të vetin, dhe të njëjtat faqe (blloqe) mund të jenë në të njëjtën kohë në cache të disa instancave. Më tej, nëse një instancë ka nevojë për një faqe dhe ajo ndodhet në cache-n e një instancë tjetër, ajo mund ta marrë nga "fqinj" me mekanizmin e bashkëveprimit të caches, në vend që ta lexojë nga disku.
Por çfarë do të ndodhë nëse njëra nga instancat ka nevojë të ndryshojë të dhënat?
Karakteristika e Oracle është se nuk ka një shërbim të dedikuar për bllokimin: nëse serveri dëshiron të bllokojë një rresht, atëherë shënimi për bllokimin vendoset direkt në atë faqe të memories ku ndodhet rreshti i bllokuar. Falë këtij qasje, Oracle është kampion në performancë ndërmjet bazave të dhënash monolitike: shërbimi i bllokimit nuk bëhet kurrë ngushticë. Por në një konfigurim klaster, një arkitekturë e tillë mund të çojë në shkëmbim intensiv rrjeti dhe bllokime të ndërsjella.
Sapo qe regjistrimi bllokohet, instanca njofton të gjitha instancat e tjera se faqa, në të cilën ruhet ky regjistrim, është kapur në modin monopol. Nëse një instancë tjetër ka nevojë të ndryshojë regjistrimin në të njëjtën faqe, duhet të presë deri sa ndryshimet në faqe të regjistrohen, dmth. informacioni mbi ndryshimin nuk është regjistruar në regjistrin në disk (në të njëjtën kohë, transaksioni mund të vazhdojë). Mund të ndodhë që faqja të ndryshohet në mënyrë të renditur nga disa instanca, dhe atëherë gjatë regjistrimit të faqes në disk do të duhet të përcaktohet se kujt i përket versioni aktual i kësaj faqeje.
Rivendosja e rastësishme e të njëjtave faqe përmes nyjeve të ndryshme RAC çon në një rënie të ndjeshme të performancës së bazës së të dhënave - deri në pikën që performanca e klasterit mund të jetë më e ulët se ajo e një instance të vetme.
Përdorimi i duhur i Oracle RAC – ndarja fizike e të dhënave (p.sh., përmes mekanizmit të tabelave të ndara) dhe qasja ndaj çdo grupi seksionesh përmes një nyjeje të dedikuar. Qëllimi kryesor i RAC nuk është shkallëzimi horizontal, por sigurimi i qëndrueshmërisë ndaj dështimeve.
Nëse një nyje pushon së përgjiguri në heartbeat, nyja që e zbulon këtë e para, nis procedurën e votimit në disk. Nëse edhe këtu nyja e humbur nuk shënohet, një nga nyjet merr përsipër detyrat për rikthimin e të dhënave:
- «ngrin» të gjitha faqet që ishin në cache të nyjes së humbur;
- lexon journalat (redo) e nyjes së humbur dhe përsërit ndryshimet e regjistruara në këto journal, duke kontrolluar gjithashtu nëse ndonjë nyje tjetër ka versione më të reja të faqeve të ndryshuara;
- rrokullisi transaksionet e papërfunduara.
Për të lehtësuar kalimin ndërmjet nyjeve, Oracle ka konceptin e shërbimit – një ekzemplar virtual. Ekzemplari mund të shërbejë disa shërbime, ndërsa shërbimi mund të jetë në lëvizje ndërmjet nyjeve. Një ekzemplar aplikacioni që shërben një pjesë të caktuar të bazës (p.sh., një grup klientësh) punon me një shërbim, dhe shërbimi, i cili është përgjegjës për këtë pjesë të bazës, kalon në një nyje tjetër kur një nyje dështon.
IBM Pure Data Systems for Transactions
Zgjidhja klasterike për DBMS erdhi në portofolin e Gigantit Blu në vitin 2009. Ideologjikisht ajo është pasardhëse e klasterit Parallel Sysplex, e ndërtuar mbi pajisje "të zakonshme". Në vitin 2009 doli produkti DB2 pureScale, që përfaqëson një grup software, ndërsa në vitin 2012 IBM ofron një paketë software-hardware (appliance) me emrin Pure Data Systems for Transactions. Mos e ngatërroni atë me Pure Data Systems for Analytics, e cila nuk është gjë tjetër veçse e rinovuar Netezza.
Arkitektura pureScale përshtatet në një shikim të parë me Oracle RAC: ashtu si disa nyje janë lidhur me një sistem të përbashkët të ruajtjes së të dhënave, dhe në çdo nyje funksionon një instancë e vetme e DBMS me hapësira të saj dhe regjistra transaksionesh. Por, për dallim nga Oracle, në DB2 ekziston një shërbim i dedikuar bllokimi, i paraqitur nga një grup procesesh db2LLM*. Në konfigurimin klaster, ky shërbim Transferohet në një nyje të veçantë, e cila në Parallel Sysplex quhet facility një lidhjeje (CF), dhe në Pure Data – PowerHA.
PowerHA ofron shërbimet e mëposhtme:
- menaxheri i bllokimeve;
- kash global;
- zona e komunikimeve ndër-proces.
Për transferimin e të dhënave nga PowerHA në nyjet e DB dhe mbrapsht përdoret qasja e largët në memorje, kështu që ndërkonnekti i klasterit duhet të mbështesë protokollin RDMA. PureScale mund të përdorë si Infiniband ashtu edhe RDMA mbi Ethernet.
Nëse nyja ka nevojë për një faqe, dhe kjo faqe nuk është në kash, nyja kërkon faqen në kashin global, dhe vetëm nëse as aty nuk ndodhet, e lexon nga disku. Ndryshe nga Oracle, kërkesa shkon vetëm në PowerHA, dhe jo në nyjet ngjitur.
Në qoftë se një instancë do të ndërronte një rresht, ajo e bllokon atë në mënyrë ekskluzive dhe faqen ku ndodhet rreshti – në mënyrë të ndarë. Të gjitha bllokimet regjistrohen në menaxherin global të bllokimeve. Kur transaksioni përfundon, nodi dërgon një mesazh menaxherit të bllokimeve, i cili kopjon faqen e ndryshuar në cache-n global, heq bllokimet dhe invalidon faqen e ndryshuar në cache-t e nodëve të tjerë.
Në qoftë se faqja në të cilën ndodhet rreshti i ndryshuar tashmë është e bllokuar, menaxheri i bllokimeve do të lexojë faqen e ndryshuar nga memoria e nodit që ka bërë ndryshimet, do të heqë bllokimin, do të invalidon faqen e ndryshuar në cache-t e nodëve të tjerë dhe do t'i japë bllokimin e faqes nodit që e ka kërkuar atë.
Faqet «të ndotura», domethënë të ndryshuara, mund të shkruhen në disk si nga një nod i zakonshëm, ashtu edhe nga PowerHA (castout).
Në rast të dështimit të një nga nyjeve, riparimi i pureScale është i kufizuar vetëm në ato transaksione që në momentin e dështimit ende nuk ishin përfunduar: faqet e ndryshuara nga kjo nyje në transaksionet e përfunduara ndodhen në кешin global në PowerHA. Nyja rilansohet në një konfigurim të reduktuar në një nga serverët e klasterit, rregullon transaksionet e papërfunduara dhe çliron bllokimet.
PowerHA funksionon në dy servera, dhe nyja kryesore në mënyrë sinkrone riplikon gjendjen e saj. Në rast dështimi të nyjës kryesore, klasteri PowerHA vazhdon të punojë me nyjën rezervë.
Sigurisht, nëse qasemi në setin e të dhënave përmes një nyje, performanca totale e klasterit do të jetë më e lartë. PureScale madje mund të vërejë se një zonë e caktuar e të dhënave po përpuntohet nga një nyje, dhe atëherë të gjitha bllokimet që i përkasin kësaj zone do të përpunohen lokal nga nyja pa komunikim me PowerHA. Por sapo aplikacioni të përpiqet të qaset në këto të dhëna përmes një nyje tjetër, përpunimi qendror i bllokimeve do të rifillojë.
Testet e brendshme të IBM mbi ngarkesën 90% lexim dhe 10% shkruaj, e cila është shumë e ngjashme me ngarkesat reale të industrisë, tregojnë një shkallëzim pothuajse linear deri në 128 node. Kushtet e testimit, fatkeqësisht, nuk zbulohen.
HPE NonStop SQL
Hewlett-Packard Enterprise gjithashtu ofron një platformë të saj të lartë disponueshmërie. Kjo është platforma NonStop, e cila u lançua në treg në vitin 1976 nga kompani Tandem Computers. Në vitin 1997, kompania u ble nga Compaq, e cila, nga ana e saj, u bashkua me Hewlett-Packard në vitin 2002.
NonStop përdoret për ndërtimin e aplikacioneve kritike – për shembull, HLR ose procesimin e kartave bankare. Platforma ofrohet si një kompleks softuerik dhe harduerik (appliance), që përfshin node llogaritëse, një sistem ruajtjeje dhe pajisje komunikimi. Rrjeti ServerNet (në sistemet moderne – Infiniband) shërben si për shkëmbimin midis node-ve ashtu edhe për qasje në sistemin e ruajtjes.
Në versionet e hershme të sistemit, janë përdorur procesorë proprietarë, të cilët ishin të sinkronizuar me njëri-tjetrin: të gjitha operacionet realizoheshin në mënyrë sinkrone nga disa procesorë, dhe sapo një nga procesorët gabonte, ai shkëputej, ndërsa tjetri vazhdonte punën. Më vonë, sistemi kaloi në procesorë standardë (fillimisht MIPS, pastaj Itanium dhe përfundimisht x86), dhe për sinkronizimin filluan të përdoren mekanizma të tjerë:
- mesazhet: çdo proces sistemor ka një dyplikat-«hije», të cilit procesi aktiv i dërgon periodikisht mesazhe për gjendjen e tij; në rast dështimi të procesit kryesor, procesi hije fillon punën nga pika që përcaktohet nga mesazhi i fundit;
- votimi: sistemi i ruajtjes së të dhënave ka një komponent të veçantë harduerik, i cili pranon disa kërkesa identike dhe i ekzekuton vetëm nëse kërkesat përputhen; në vend të sinkronizimit fizik, procesorët punojnë asinkronisht, dhe rezultatet e punës së tyre krahasohen vetëm në momentet e hyrjes/daljes.
Që nga viti 1987, në platformën NonStop punon një sistem i bazave të të dhënave relacional - fillimisht SQL/MP, dhe më vonë - SQL/MX.
E gjithë baza e të dhënave ndahet në pjesë, dhe për secilën pjesë përgjigjet procesi Data Access Manager (DAM). Ai siguron regjistrimin e të dhënave, ruajtjen në memorie dhe mekanizmin e bllokimeve. Përpunimi i të dhënave bëhet nga proceset ekzekutues (Executor Server Process), të cilët punojnë në të njëjtat nyje si menaxherët përkatës të të dhënave. Planifikuesi SQL/MX ndan detyrat midis ekzekutuesve dhe kombinon rezultatet. Kur është e nevojshme të bëhen ndryshime të rëna dakord, përdoret protokolli i bllokimit dytë, i siguruar nga biblioteka TMF (Transaction Management Facility).
NonStop SQL ka aftësinë për të priorizuar proceset në mënyrë që kërkesat e gjata analitike të mos pengojnë ekzekutimin e transaksioneve. Megjithatë, qëllimi i saj është përpunimi i transaksioneve të shkurtra, dhe jo analitika. Zhvilluesi garanton disponueshmërinë e klasterit NonStop në nivelin pesë «nëntë», që do të thotë se koha e papërshkruar përbën vetëm 5 minuta në vit.
SAP HANA
Rirajti i parë stabil i DBMS HANA (1.0) u lançua në nëntor 2010, dhe paketa SAP ERP kaloi në HANA që nga maji 2013. Platforma është e bazuar në teknologjitë e blera: TREX Search Engine (kërkim në magazinën me kolona), DBMS P*TIME dhe MAX DB.
Fjala «HANA» është një akronim për High performance ANalytical Appliance. Ky DBMS ofrohet në formën e kodit, i cili mund të punojë në serverë x86 të çdo lloji, megjithatë instalimet industriale lejojnë vetëm pajisje që kanë kaluar certifikimin. Janë në dispozicion zgjidhje nga HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Disa konfiguracione të Lenovo lejojnë madje operimin pa SAN - roli i ruajtjes së përbashkët luhet nga klasteri GPFS në diskët lokalë.
Në kundërshtim me platformat e përmendura më sipër, HANA është një DBMS në memory, që do të thotë se pamja primare e të dhënave ruhet në kujtesën operative, ndërsa në disk regjistrohen vetëm ditarët dhe përkohësitë - për rikuperim në rast aksidenti.
Çdo nyje e klasterit HANA është përgjegjëse për pjesën e saj të të dhënave, ndërsa harta e të dhënave ruhet në një komponent të veçantë - Serverin e Emrave, i vendosur në nyjen koordinatore. Të dhënat ndërmjet nyjeve nuk dublikohen. Informacioni mbi bllokimet gjithashtu ruhet në çdo nyje, por në sistem ka një detektor global të bllokimeve të ndërsjella.
Klienti HANA, kur lidhet me klasterin, ngarkon topologjinë e tij dhe më pas mund të drejtohet drejtpërdrejt te çdo nyje në varësi të të dhënave që i nevojiten. Nëse transaksioni përfshin të dhënat e një nyjeje të vetme, ai mund të ekzekutohet lokalisht nga kjo nyje, por nëse ndryshohen të dhënat e disa nyjeve, nyja-iniciatore i drejtohet nyjës-koordinatori, e cila hap dhe koordinon transaksionin e shpërndarë, duke e regjistruar atë përmes një protokolli të optimizuar të regjistrimit në dy faza.
Nyja-koordinatore është e dyfishtë, prandaj në rast se koordinatori dështon, menjëherë aktivizohet nyja rezervë. Nëse dështinë një nyje me të dhëna, mënyra e vetme për të aksesuar të dhënat e saj është të rindizni nyjën. Si rregull, në klasteret HANA mbahet një server rezervë (spare), në mënyrë që të rikthehet sa më shpejt nyja e humbur.
Burimi: habr.com
