CAP teorem je kamen temeljac teorije distribuiranih sustava. Naravno, kontroverze koje ga okružuju ne jenjavaju: definicije u njemu nisu kanonske i nema strogih dokaza... Ipak, čvrsto stojeći na pozicijama svakodnevnog zdravog razuma™, intuitivno shvaćamo da je teorem istinit.
Jedino što nije očito je značenje slova "P". Kada se klaster podijeli, odlučuje hoće li ne odgovoriti dok se ne postigne kvorum ili će vratiti podatke koji su dostupni. Ovisno o rezultatima ovog izbora, sustav se klasificira kao CP ili AP. Cassandra se, na primjer, može ponašati na bilo koji način, ovisno čak i ne o postavkama klastera, već o parametrima svakog specifičnog zahtjeva. Ali ako sustav nije "P" i razdvoji se, što onda?
Odgovor na ovo pitanje je pomalo neočekivan: CA klaster se ne može podijeliti.
Kakav je to klaster koji se ne može razdvojiti?
Neizostavan atribut takvog klastera je zajednički sustav za pohranu podataka. U velikoj većini slučajeva to znači povezivanje preko SAN-a, što ograničava korištenje CA rješenja na velika poduzeća sposobna održavati SAN infrastrukturu. Kako bi više poslužitelja radilo s istim podacima, potreban je klasterirani datotečni sustav. Takvi datotečni sustavi dostupni su u HPE (CFS), Veritas (VxCFS) i IBM (GPFS) portfeljima.
Oracle RAC
Opcija Real Application Cluster prvi put se pojavila 2001. s izdavanjem Oracle 9i. U takvom klasteru nekoliko instanci poslužitelja radi s istom bazom podataka.
Oracle može raditi i s klasteriranim datotečnim sustavom i s vlastitim rješenjem - ASM, Automatic Storage Management.
Svaki primjerak vodi svoj dnevnik. Transakciju izvršava i potvrđuje jedna instanca. Ako instanca ne uspije, jedan od preživjelih čvorova klastera (instanci) čita svoj dnevnik i vraća izgubljene podatke - čime se osigurava dostupnost.
Sve instance održavaju vlastitu predmemoriju, a iste stranice (blokovi) mogu biti u predmemorijama više instanci u isto vrijeme. Štoviše, ako jedna instanca treba stranicu, a nalazi se u predmemoriji druge instance, može je dobiti od susjeda pomoću mehanizma fuzije predmemorije umjesto čitanja s diska.
Ali što se događa ako jedna od instanci treba promijeniti podatke?
Posebnost Oraclea je ta što nema namjensku uslugu zaključavanja: ako poslužitelj želi zaključati red, tada se zapis zaključavanja postavlja izravno na memorijsku stranicu na kojoj se nalazi zaključani red. Zahvaljujući ovom pristupu, Oracle je prvak u izvedbi među monolitnim bazama podataka: usluga zaključavanja nikada ne postaje usko grlo. Ali u konfiguraciji klastera takva arhitektura može dovesti do intenzivnog mrežnog prometa i zastoja.
Nakon što je zapis zaključan, instanca obavještava sve druge instance da stranica koja pohranjuje taj zapis ima ekskluzivno zadržavanje. Ako druga instanca treba promijeniti zapis na istoj stranici, mora pričekati dok se promjene na stranici ne potvrde, to jest dok se informacija o promjeni ne zapiše u dnevnik na disku (i transakcija se može nastaviti). Također se može dogoditi da će se stranica mijenjati uzastopno u nekoliko kopija, a zatim ćete prilikom pisanja stranice na disk morati saznati tko pohranjuje trenutnu verziju ove stranice.
Nasumično ažuriranje istih stranica na različitim RAC čvorovima uzrokuje dramatičan pad performansi baze podataka, do točke u kojoj performanse klastera mogu biti niže od performansi jedne instance.
Ispravna upotreba Oracle RAC-a je fizička particija podataka (na primjer, pomoću mehanizma particionirane tablice) i pristup svakom skupu particija putem namjenskog čvora. Glavna svrha RAC-a nije bila horizontalno skaliranje, već osiguravanje tolerancije na pogreške.
Ako čvor prestane reagirati na otkucaj srca, tada čvor koji ga je otkrio prvi započinje proceduru glasanja na disku. Ako čvor koji nedostaje ovdje nije zabilježen, tada jedan od čvorova preuzima odgovornost za oporavak podataka:
- “zamrzava” sve stranice koje su bile u cacheu nedostajućeg čvora;
- čita zapise (ponovi) nedostajućeg čvora i ponovno primjenjuje promjene zabilježene u tim zapisima, istovremeno provjeravajući imaju li drugi čvorovi novije verzije stranica koje se mijenjaju;
- vraća transakcije na čekanju.
Kako bi pojednostavio prebacivanje između čvorova, Oracle ima koncept usluge - virtualne instance. Instanca može posluživati više usluga, a usluga se može kretati između čvorova. Instanca aplikacije koja opslužuje određeni dio baze podataka (na primjer, grupa klijenata) radi s jednom uslugom, a usluga odgovorna za ovaj dio baze podataka premješta se u drugi čvor kada čvor zakaže.
IBM Pure Data Systems for Transactions
Rješenje klastera za DBMS pojavilo se u portfelju Blue Gianta 2009. godine. Ideološki, to je nasljednik klastera Parallel Sysplex, izgrađenog na "običnoj" opremi. Godine 2009. DB2 pureScale objavljen je kao softverski paket, a 2012. IBM je ponudio uređaj pod nazivom Pure Data Systems for Transactions. Ne treba ga brkati s Pure Data Systems for Analytics, koji nije ništa drugo nego preimenovana Netezza.
Na prvi pogled, pureScale arhitektura je slična Oracle RAC-u: na isti način, nekoliko čvorova je povezano na zajednički sustav za pohranu podataka, a svaki čvor pokreće vlastitu DBMS instancu s vlastitim memorijskim područjima i zapisima transakcija. Ali, za razliku od Oraclea, DB2 ima namjensku uslugu zaključavanja koju predstavlja skup db2LLM* procesa. U konfiguraciji klastera, ova je usluga smještena na zasebnom čvoru, koji se naziva mogućnost spajanja (CF) u Parallel Sysplexu, a PowerHA u Pure Data.
PowerHA pruža sljedeće usluge:
- upravitelj brave;
- globalni međuspremnik;
- područje međuprocesnih komunikacija.
Za prijenos podataka iz PowerHA u čvorove baze podataka i natrag, koristi se udaljeni pristup memoriji, tako da međusobno povezivanje klastera mora podržavati RDMA protokol. PureScale može koristiti i Infiniband i RDMA preko Etherneta.
Ako čvor treba stranicu, a ta stranica nije u predmemorije, tada čvor zahtijeva stranicu u globalnoj predmemorije, i samo ako je nema, čita je s diska. Za razliku od Oraclea, zahtjev ide samo PowerHA, a ne susjednim čvorovima.
Ako će instanca promijeniti redak, ona ga zaključava u ekskluzivnom načinu rada, a stranicu na kojoj se nalazi redak u zajedničkom načinu rada. Sva zaključavanja registrirana su u globalnom upravitelju zaključavanja. Kada se transakcija završi, čvor šalje poruku upravitelju zaključavanja, koji kopira izmijenjenu stranicu u globalnu predmemoriju, otpušta zaključavanja i poništava izmijenjenu stranicu u predmemoriji drugih čvorova.
Ako je stranica u kojoj se nalazi izmijenjeni red već zaključana, tada će upravitelj zaključavanja pročitati izmijenjenu stranicu iz memorije čvora koji je napravio promjenu, otpustiti zaključavanje, poništiti izmijenjenu stranicu u predmemoriji drugih čvorova i dati zaključavanje stranice čvoru koji je to zatražio.
“Prljave”, odnosno promijenjene, stranice mogu se pisati na disk i iz običnog čvora i iz PowerHA (castout).
Ako jedan od pureScale čvorova ne uspije, oporavak je ograničen samo na one transakcije koje još nisu bile dovršene u trenutku kvara: stranice koje je taj čvor izmijenio u dovršenim transakcijama nalaze se u globalnoj predmemorije na PowerHA. Čvor se ponovno pokreće u smanjenoj konfiguraciji na jednom od poslužitelja u klasteru, vraća transakcije na čekanju i oslobađa zaključavanja.
PowerHA radi na dva poslužitelja, a glavni čvor sinkrono replicira svoje stanje. Ako primarni PowerHA čvor zakaže, klaster nastavlja raditi s rezervnim čvorom.
Naravno, ako skupu podataka pristupate putem jednog čvora, ukupna izvedba klastera bit će veća. PureScale čak može primijetiti da se određeno područje podataka obrađuje od strane jednog čvora, a zatim će sva zaključavanja povezana s tim područjem biti obrađena lokalno od strane čvora bez komunikacije s PowerHA. Ali čim aplikacija pokuša pristupiti tim podacima putem drugog čvora, centralizirana obrada zaključavanja će se nastaviti.
IBM-ovi interni testovi na radnom opterećenju od 90% čitanja i 10% pisanja, što je vrlo slično proizvodnim radnim opterećenjima u stvarnom svijetu, pokazuju gotovo linearno skaliranje do 128 čvorova. Uvjeti testiranja, nažalost, nisu objavljeni.
HPE NonStop SQL
Portfelj Hewlett-Packard Enterprise također ima vlastitu vrlo dostupnu platformu. Ovo je NonStop platforma koju je 1976. godine na tržište pustio Tandem Computers. Godine 1997. tvrtku je kupio Compaq, koji se zatim spojio s Hewlett-Packardom 2002. godine.
NonStop se koristi za izradu kritičnih aplikacija - na primjer, HLR ili obrada bankovnih kartica. Platforma se isporučuje u obliku softverskog i hardverskog kompleksa (uređaja), koji uključuje računalne čvorove, sustav za pohranu podataka i komunikacijsku opremu. ServerNet mreža (u modernim sustavima - Infiniband) služi kako za razmjenu između čvorova tako i za pristup sustavu za pohranu podataka.
Rane verzije sustava koristile su vlasničke procesore koji su bili međusobno sinkronizirani: sve operacije sinkrono je izvodilo nekoliko procesora, a čim je jedan od procesora napravio pogrešku, bio je isključen, a drugi je nastavio raditi. Kasnije je sustav prešao na konvencionalne procesore (prvo MIPS, zatim Itanium i na kraju x86), a za sinkronizaciju su se počeli koristiti i drugi mehanizmi:
- poruke: svaki proces sustava ima blizanca u sjeni, kojem aktivni proces povremeno šalje poruke o svom statusu; ako glavni proces ne uspije, proces u sjeni počinje raditi od trenutka određenog zadnjom porukom;
- glasanje: sustav za pohranu ima posebnu hardversku komponentu koja prihvaća više identičnih pristupa i izvršava ih samo ako se pristupi podudaraju; Umjesto fizičke sinkronizacije, procesori rade asinkrono, a rezultati njihova rada uspoređuju se samo u I/O trenucima.
Od 1987. godine relacijski DBMS radi na NonStop platformi - prvo SQL/MP, a kasnije SQL/MX.
Cijela baza podataka podijeljena je na dijelove, a svaki dio je odgovoran za svoj proces Data Access Manager (DAM). Omogućuje mehanizme za snimanje podataka, predmemoriju i zaključavanje. Obradu podataka provode procesi poslužitelja izvršitelja koji se izvode na istim čvorovima kao i odgovarajući upravitelji podataka. SQL/MX planer dijeli zadatke između izvršitelja i agregira rezultate. Kada je potrebno izvršiti dogovorene promjene, koristi se dvofazni protokol predaje koji pruža biblioteka TMF (Transaction Management Facility).
NonStop SQL može odrediti prioritete procesa tako da dugi analitički upiti ne ometaju izvršenje transakcije. No, svrha mu je upravo obrada kratkih transakcija, a ne analitika. Programer jamči dostupnost klastera NonStop na razini pet "devetki", odnosno zastoj je samo 5 minuta godišnje.
SAP-HANA
Prvo stabilno izdanje HANA DBMS-a (1.0) dogodilo se u studenom 2010., a SAP ERP paket prebačen je na HANA u svibnju 2013. Platforma se temelji na kupljenim tehnologijama: TREX Search Engine (pretraživanje u columnar storageu), P*TIME DBMS i MAX DB.
Sama riječ "HANA" je akronim, Analitički uređaj visokih performansi. Ovaj DBMS isporučuje se u obliku koda koji se može izvoditi na bilo kojem x86 poslužitelju, međutim, industrijske instalacije dopuštene su samo na certificiranoj opremi. Dostupna rješenja HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Neke Lenovo konfiguracije čak dopuštaju rad bez SAN-a - ulogu zajedničkog sustava za pohranu igra GPFS klaster na lokalnim diskovima.
Za razliku od gore navedenih platformi, HANA je DBMS u memoriji, tj. primarna slika podataka pohranjuje se u RAM, a samo se zapisnici i periodične snimke zapisuju na disk za oporavak u slučaju katastrofe.
Svaki čvor HANA klastera odgovoran je za svoj dio podataka, a mapa podataka pohranjena je u posebnoj komponenti – Name Server koja se nalazi na čvoru koordinatora. Podaci se ne dupliciraju između čvorova. Podaci o zaključavanju također su pohranjeni na svakom čvoru, ali sustav ima detektor globalnog zastoja.
Kada se HANA klijent poveže s klasterom, preuzima njegovu topologiju i zatim može izravno pristupiti bilo kojem čvoru, ovisno o tome koji su mu podaci potrebni. Ako transakcija utječe na podatke jednog čvora, tada ju taj čvor može izvršiti lokalno, ali ako se podaci nekoliko čvorova promijene, početni čvor kontaktira čvor koordinatora, koji otvara i koordinira distribuiranu transakciju, izvršavajući je pomoću optimizirani dvofazni protokol predaje.
Koordinatorski čvor je dupliciran, pa ako koordinator zakaže, rezervni čvor odmah preuzima. Ali ako čvor s podacima ne uspije, tada je jedini način pristupa njegovim podacima ponovno pokretanje čvora. HANA klasteri u pravilu održavaju rezervni poslužitelj kako bi što brže ponovno pokrenuli izgubljeni čvor na njemu.
Izvor: www.habr.com