Teorema CAP është themeli i teorisë së sistemeve të shpërndara. Natyrisht, polemika rreth tij nuk zbutet: përkufizimet në të nuk janë kanonike dhe nuk ka asnjë provë të rreptë... Megjithatë, duke qëndruar me vendosmëri në pozicionet e sensit të zakonshëm të përditshëm™, ne kuptojmë intuitivisht se teorema është e vërtetë.
E vetmja gjë që nuk është e dukshme është kuptimi i shkronjës "P". Kur grupi ndahet, ai vendos nëse nuk do të përgjigjet derisa të arrihet një kuorum ose do të kthejë të dhënat që janë në dispozicion. Në varësi të rezultateve të kësaj zgjedhjeje, sistemi klasifikohet si CP ose AP. Cassandra, për shembull, mund të sillet sido që të jetë, në varësi jo edhe nga cilësimet e grupit, por nga parametrat e secilës kërkesë specifike. Por nëse sistemi nuk është "P" dhe ai ndahet, atëherë çfarë?
Përgjigja për këtë pyetje është disi e papritur: një grup CA nuk mund të ndahet.
Çfarë lloj grupi është ky që nuk mund të ndahet?
Një atribut i domosdoshëm i një grupi të tillë është një sistem i përbashkët i ruajtjes së të dhënave. Në shumicën dërrmuese të rasteve, kjo nënkupton lidhjen përmes një SAN, gjë që kufizon përdorimin e zgjidhjeve CA për ndërmarrjet e mëdha të afta për të mbajtur një infrastrukturë SAN. Në mënyrë që shumë serverë të punojnë me të njëjtat të dhëna, kërkohet një sistem skedari i grupuar. Sisteme të tilla skedarësh janë të disponueshëm në portofolet HPE (CFS), Veritas (VxCFS) dhe IBM (GPFS).
Oracle RAC
Opsioni Real Application Cluster u shfaq për herë të parë në 2001 me lëshimin e Oracle 9i. Në një grup të tillë, disa raste të serverëve punojnë me të njëjtën bazë të dhënash.
Oracle mund të punojë si me një sistem skedarësh të grumbulluar ashtu edhe me zgjidhjen e tij - ASM, Menaxhimi automatik i ruajtjes.
Çdo kopje mban ditarin e vet. Transaksioni ekzekutohet dhe kryhet nga një instancë. Nëse një shembull dështon, një nga nyjet (instancat) e grupimit të mbijetuar lexon regjistrin e tij dhe rikthen të dhënat e humbura - duke siguruar kështu disponueshmërinë.
Të gjitha instancat ruajnë cache-në e tyre, dhe të njëjtat faqe (blloqe) mund të jenë në cache të shumë shembujve në të njëjtën kohë. Për më tepër, nëse një shembull ka nevojë për një faqe dhe është në cache-in e një shembulli tjetër, ai mund ta marrë atë nga fqinji i tij duke përdorur mekanizmin e bashkimit të cache në vend që të lexojë nga disku.
Por çfarë ndodh nëse një nga rastet duhet të ndryshojë të dhënat?
E veçanta e Oracle është se ai nuk ka një shërbim të dedikuar mbylljeje: nëse serveri dëshiron të bllokojë një rresht, atëherë regjistrimi i bllokimit vendoset drejtpërdrejt në faqen e kujtesës ku ndodhet rreshti i kyçur. Falë kësaj qasjeje, Oracle është kampioni i performancës midis bazave të të dhënave monolitike: shërbimi i kyçjes nuk bëhet kurrë një pengesë. Por në një konfigurim grupi, një arkitekturë e tillë mund të çojë në trafik intensiv të rrjetit dhe bllokime.
Pasi një regjistrim është i kyçur, një shembull njofton të gjitha rastet e tjera që faqja që ruan atë regjistrim ka një mbajtje ekskluzive. Nëse një shembull tjetër duhet të ndryshojë një rekord në të njëjtën faqe, ai duhet të presë derisa të kryhen ndryshimet në faqe, domethënë, informacioni i ndryshimit të shkruhet në një ditar në disk (dhe transaksioni mund të vazhdojë). Mund të ndodhë gjithashtu që një faqe të ndryshohet në mënyrë sekuenciale nga disa kopje, dhe më pas kur shkruani faqen në disk, do të duhet të zbuloni se kush ruan versionin aktual të kësaj faqeje.
Përditësimi i rastësishëm i të njëjtave faqe nëpër nyje të ndryshme RAC bën që performanca e bazës së të dhënave të bjerë në mënyrë dramatike, deri në pikën ku performanca e grupit mund të jetë më e ulët se ajo e një shembulli të vetëm.
Përdorimi i saktë i Oracle RAC është ndarja fizike e të dhënave (për shembull, duke përdorur një mekanizëm tabele të ndarë) dhe aksesimi i çdo grupi ndarjesh përmes një nyje të dedikuar. Qëllimi kryesor i RAC nuk ishte shkallëzimi horizontal, por sigurimi i tolerancës së gabimeve.
Nëse një nyje ndalon së përgjigjuri ndaj një rrahjeje zemre, atëherë nyja që e ka zbuluar fillimisht fillon një procedurë votimi në disk. Nëse nyja që mungon nuk shënohet këtu, atëherë një nga nyjet merr përgjegjësinë për rikuperimin e të dhënave:
- "ngrin" të gjitha faqet që ishin në cache të nyjës që mungon;
- lexon regjistrat (redo) të nyjës që mungon dhe riaplikon ndryshimet e regjistruara në këto regjistra, duke kontrolluar njëkohësisht nëse nyjet e tjera kanë versione më të fundit të faqeve që po ndryshohen;
- kthen mbrapsht transaksionet në pritje.
Për të thjeshtuar kalimin midis nyjeve, Oracle ka konceptin e një shërbimi - një shembull virtual. Një shembull mund të shërbejë shumë shërbime dhe një shërbim mund të lëvizë midis nyjeve. Një shembull aplikacioni që shërben për një pjesë të caktuar të bazës së të dhënave (për shembull, një grup klientësh) punon me një shërbim, dhe shërbimi përgjegjës për këtë pjesë të bazës së të dhënave lëviz në një nyje tjetër kur një nyje dështon.
IBM Pure Data Systems for Transactions
Një zgjidhje grupi për DBMS u shfaq në portofolin Blue Giant në 2009. Ideologjikisht, është pasardhësi i grupit Parallel Sysplex, i ndërtuar mbi pajisje "të rregullta". Në vitin 2009, DB2 pureScale u lëshua si një paketë softuerësh dhe në vitin 2012, IBM ofroi një pajisje të quajtur Pure Data Systems for Transactions. Nuk duhet të ngatërrohet me Sistemet e të Dhënave të Pasta për Analytics, që nuk është gjë tjetër veçse një Netezza e riemërtuar.
Në pamje të parë, arkitektura PureScale është e ngjashme me Oracle RAC: në të njëjtën mënyrë, disa nyje lidhen me një sistem të përbashkët të ruajtjes së të dhënave dhe secila nyje drejton shembullin e vet DBMS me zonat e veta të memories dhe regjistrat e transaksioneve. Por, ndryshe nga Oracle, DB2 ka një shërbim të dedikuar mbylljeje të përfaqësuar nga një grup procesesh db2LLM*. Në një konfigurim grupi, ky shërbim vendoset në një nyje të veçantë, e cila quhet pajisje bashkuese (CF) në Sysplex paralel dhe PowerHA në të dhëna të pastra.
PowerHA ofron shërbimet e mëposhtme:
- menaxher bllokimi;
- memoria e tamponit global;
- zona e komunikimeve ndërprocesore.
Për të transferuar të dhëna nga PowerHA në nyjet e bazës së të dhënave dhe mbrapa, përdoret aksesi i memories në distancë, kështu që ndërlidhja e grupit duhet të mbështesë protokollin RDMA. PureScale mund të përdorë Infiniband dhe RDMA mbi Ethernet.
Nëse një nyje ka nevojë për një faqe, dhe kjo faqe nuk është në cache, atëherë nyja kërkon faqen në cache globale, dhe vetëm nëse nuk është aty, e lexon atë nga disku. Ndryshe nga Oracle, kërkesa shkon vetëm në PowerHA, dhe jo në nyjet fqinje.
Nëse një shembull do të ndryshojë një rresht, ai e kyç atë në modalitetin ekskluziv dhe faqen ku ndodhet rreshti në modalitetin e përbashkët. Të gjitha bravat regjistrohen në menaxherin global të bllokimit. Kur transaksioni përfundon, nyja i dërgon një mesazh menaxherit të bllokimit, i cili kopjon faqen e modifikuar në cache globale, lëshon bllokimet dhe zhvlerëson faqen e modifikuar në memoriet e nyjeve të tjera.
Nëse faqja në të cilën ndodhet rreshti i modifikuar është tashmë e kyçur, atëherë menaxheri i bllokimit do të lexojë faqen e modifikuar nga memoria e nyjes që ka bërë ndryshimin, do të lëshojë bllokimin, do të zhvlerësojë faqen e modifikuar në cache-të e nyjeve të tjera dhe jepni bllokimin e faqes nyjes që e ka kërkuar atë.
"Në pistë", domethënë të ndryshuara, faqet mund të shkruhen në disk si nga një nyje e rregullt ashtu edhe nga PowerHA (castout).
Nëse një nga nyjet e PureScale dështon, rikuperimi kufizohet vetëm në ato transaksione që nuk ishin përfunduar ende në kohën e dështimit: faqet e modifikuara nga ajo nyje në transaksionet e përfunduara janë në cache globale në PowerHA. Nyja riniset në një konfigurim të reduktuar në një nga serverët në grup, kthen transaksionet në pritje dhe lëshon bllokimet.
PowerHA funksionon në dy serverë dhe nyja kryesore përsërit gjendjen e saj në mënyrë sinkronike. Nëse nyja kryesore PowerHA dështon, grupi vazhdon të funksionojë me nyjen rezervë.
Sigurisht, nëse aksesoni grupin e të dhënave përmes një nyje të vetme, performanca e përgjithshme e grupit do të jetë më e lartë. PureScale madje mund të vërejë se një zonë e caktuar e të dhënave po përpunohet nga një nyje, dhe më pas të gjitha bllokimet që lidhen me atë zonë do të përpunohen lokalisht nga nyja pa komunikuar me PowerHA. Por sapo aplikacioni të përpiqet të aksesojë këto të dhëna përmes një nyje tjetër, përpunimi i centralizuar i bllokimit do të rifillojë.
Testet e brendshme të IBM në një ngarkesë pune prej 90% leximi dhe 10% shkrimi, e cila është shumë e ngjashme me ngarkesat e prodhimit në botën reale, tregojnë shkallëzim pothuajse linear deri në 128 nyje. Kushtet e testimit, për fat të keq, nuk zbulohen.
HPE NonStop SQL
Portofoli i Hewlett-Packard Enterprise ka gjithashtu platformën e vet shumë të disponueshme. Kjo është platforma NonStop, e lëshuar në treg në vitin 1976 nga Tandem Computers. Në 1997, kompania u ble nga Compaq, e cila nga ana e saj u bashkua me Hewlett-Packard në 2002.
NonStop përdoret për të ndërtuar aplikacione kritike - për shembull, HLR ose përpunimi i kartave bankare. Platforma shpërndahet në formën e një kompleksi softueri dhe hardueri (pajisje), i cili përfshin nyjet kompjuterike, një sistem të ruajtjes së të dhënave dhe pajisje komunikimi. Rrjeti ServerNet (në sistemet moderne - Infiniband) shërben si për shkëmbim midis nyjeve ashtu edhe për akses në sistemin e ruajtjes së të dhënave.
Versionet e hershme të sistemit përdorën procesorë të pronarit që ishin të sinkronizuar me njëri-tjetrin: të gjitha operacionet kryheshin në mënyrë sinkronike nga disa procesorë, dhe sapo njëri prej procesorëve bënte një gabim, ai fiket dhe i dyti vazhdoi të funksiononte. Më vonë, sistemi kaloi në procesorë konvencionalë (së pari MIPS, pastaj Itanium dhe në fund x86), dhe mekanizma të tjerë filluan të përdoren për sinkronizim:
- mesazhet: çdo proces sistemi ka një binjak "hije", të cilit procesi aktiv i dërgon periodikisht mesazhe për statusin e tij; nëse procesi kryesor dështon, procesi hije fillon të funksionojë nga momenti i përcaktuar nga mesazhi i fundit;
- votimi: sistemi i ruajtjes ka një komponentë të veçantë harduerike që pranon aksese të shumta identike dhe i ekzekuton ato vetëm nëse akseset përputhen; Në vend të sinkronizimit fizik, procesorët funksionojnë në mënyrë asinkrone dhe rezultatet e punës së tyre krahasohen vetëm në momentet I/O.
Që nga viti 1987, një DBMS relacionale ka funksionuar në platformën NonStop - fillimisht SQL/MP dhe më vonë SQL/MX.
E gjithë baza e të dhënave është e ndarë në pjesë, dhe secila pjesë është përgjegjëse për procesin e vet të Menaxherit të Qasjes së të Dhënave (DAM). Ai siguron mekanizma regjistrimi, memorie dhe mbylljeje të të dhënave. Përpunimi i të dhënave kryhet nga proceset e serverit ekzekutues që funksionojnë në të njëjtat nyje si menaxherët përkatës të të dhënave. Planifikuesi SQL/MX ndan detyrat midis ekzekutuesve dhe grumbullon rezultatet. Kur është e nevojshme të bëhen ndryshimet e dakorduara, përdoret protokolli i kryerjes me dy faza i ofruar nga biblioteka TMF (Transaction Management Facility).
NonStop SQL mund t'i japë përparësi proceseve në mënyrë që pyetjet e gjata analitike të mos ndërhyjnë në ekzekutimin e transaksionit. Megjithatë, qëllimi i tij është pikërisht përpunimi i transaksioneve të shkurtra, dhe jo analitika. Zhvilluesi garanton disponueshmërinë e grupit NonStop në nivelin e pesë "nëntë", domethënë, koha e ndërprerjes është vetëm 5 minuta në vit.
SAP-HANA
Lëshimi i parë i qëndrueshëm i HANA DBMS (1.0) u zhvillua në nëntor 2010 dhe paketa SAP ERP kaloi në HANA në maj 2013. Platforma bazohet në teknologjitë e blera: TREX Search Engine (kërkim në ruajtje kolone), P*TIME DBMS dhe MAX DB.
Vetë fjala "HANA" është një akronim, Pajisje analitike me performancë të lartë. Ky DBMS ofrohet në formën e kodit që mund të funksionojë në çdo server x86, megjithatë, instalimet industriale lejohen vetëm në pajisje të certifikuara. Zgjidhjet e disponueshme nga HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Disa konfigurime të Lenovo madje lejojnë funksionimin pa një SAN - roli i një sistemi të përbashkët ruajtjeje luhet nga një grup GPFS në disqet lokale.
Ndryshe nga platformat e listuara më sipër, HANA është një DBMS në memorie, d.m.th., imazhi kryesor i të dhënave ruhet në RAM dhe vetëm regjistrat dhe fotografitë periodike shkruhen në disk për rikuperim në rast fatkeqësie.
Çdo nyje grupi HANA është përgjegjëse për pjesën e vet të të dhënave, dhe harta e të dhënave ruhet në një komponent të veçantë - Serveri i emrave, i vendosur në nyjen koordinatore. Të dhënat nuk dublikohen ndërmjet nyjeve. Informacioni i kyçjes ruhet gjithashtu në secilën nyje, por sistemi ka një detektor global të bllokimit.
Kur një klient HANA lidhet me një grup, ai shkarkon topologjinë e tij dhe më pas mund të hyjë drejtpërdrejt në çdo nyje, në varësi të të dhënave që i nevojiten. Nëse një transaksion ndikon në të dhënat e një nyje të vetme, atëherë ai mund të ekzekutohet lokalisht nga ajo nyje, por nëse të dhënat e disa nyjeve ndryshojnë, nyja iniciuese kontakton nyjen koordinatore, e cila hap dhe koordinon transaksionin e shpërndarë, duke e kryer atë duke përdorur një protokoll i optimizuar i kryerjes me dy faza.
Nyja e koordinatorit është e dyfishuar, kështu që nëse koordinatori dështon, nyja rezervë merr menjëherë kontrollin. Por nëse një nyje me të dhëna dështon, atëherë mënyra e vetme për të hyrë në të dhënat e saj është rinisja e nyjes. Si rregull, grupet HANA mbajnë një server rezervë në mënyrë që të rifillojnë një nyje të humbur në të sa më shpejt që të jetë e mundur.
Burimi: www.habr.com