CAP teorema je kamen temeljac teorije distribuiranih sistema. Naravno, kontroverza oko njega ne jenjava: definicije u njemu nisu kanonske, i nema strogog dokaza... Ipak, čvrsto stojeći na pozicijama svakodnevnog zdravog razuma™, mi intuitivno razumijemo da je teorema istinita.
Jedino što nije očigledno je značenje slova "P". Kada se klaster podijeli, odlučuje da li neće odgovoriti dok se ne postigne kvorum ili će vratiti podatke koji su dostupni. U zavisnosti od rezultata ovog izbora, sistem je klasifikovan kao CP ili AP. Cassandra se, na primjer, može ponašati na bilo koji način, čak ni ne ovisno o postavkama klastera, već o parametrima svakog specifičnog zahtjeva. Ali ako sistem nije "P" i ako se podijeli, šta 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?
Bitan atribut takvog klastera je zajednički sistem za pohranu podataka. U velikoj većini slučajeva, to znači povezivanje putem SAN-a, što ograničava upotrebu CA rješenja na velika preduzeća sposobna za održavanje SAN infrastrukturu. Da bi nekoliko serveri Za rad s istim podacima potreban je klasterski datotečni sistem. Takvi datotečni sistemi dostupni su u portfolijima HPE (CFS), Veritas (VxCFS) i IBM (GPFS).
Oracle RAC
Opcija Real Application Cluster prvi put se pojavila 2001. godine s izdavanjem Oracle 9i. U takvom klasteru, više instanci server rade s istom bazom podataka.
Oracle može da radi i sa klasterizovanim sistemom datoteka i sa sopstvenim rešenjem – ASM, Automatic Storage Management.
Svaki primjerak vodi svoj vlastiti dnevnik. Transakciju izvršava i izvršava 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 keš memoriju, a iste stranice (blokovi) mogu biti u keš memoriji više instanci u isto vrijeme. Štaviše, ako je jednoj instanci potrebna stranica i nalazi se u kešu druge instance, može je dobiti od svog susjeda koristeći mehanizam spajanja keša umjesto čitanja s diska.
Ali šta se dešava ako jedna od instanci treba da promeni podatke?
Posebnost Oraclea je u tome što nema namjensku uslugu zaključavanja: ako server želi zaključati red, tada se zapis zaključavanja postavlja direktno na memorijsku stranicu gdje se nalazi zaključani red. Zahvaljujući ovom pristupu, Oracle je šampion u performansama 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.
Jednom kada je zapis zaključan, instanca obavještava sve ostale instance da stranica koja pohranjuje taj zapis ima ekskluzivno zadržavanje. Ako druga instanca treba da promijeni zapis na istoj stranici, mora pričekati dok se promjene na stranici ne potvrde, to jest, informacija o promjeni se upiše u dnevnik na disku (i transakcija se može nastaviti). Može se desiti i da će se stranica uzastopno mijenjati u nekoliko kopija, a onda ćete prilikom pisanja stranice na disk morati saznati ko pohranjuje trenutnu verziju ove stranice.
Nasumično ažuriranje istih stranica na različitim RAC čvorovima uzrokuje drastičan pad performansi baze podataka, do točke u kojoj performanse klastera mogu biti niže od one jedne instance.
Ispravna upotreba Oracle RAC-a je fizičko particioniranje podataka (na primjer, korištenje mehanizma particionirane tablice) i pristup svakom skupu particija preko namjenskog čvora. Glavna svrha RAC-a nije bila horizontalno skaliranje, već osiguravanje tolerancije grešaka.
Ako čvor prestane da reaguje na otkucaje srca, onda čvor koji ga je detektovao prvi pokreće proceduru glasanja na disku. Ako čvor koji nedostaje nije naveden ovdje, tada jedan od čvorova preuzima odgovornost za oporavak podataka:
- „zamrzava“ sve stranice koje su bile u kešu čvora koji nedostaje;
- čita dnevnike (ponovno) čvora koji nedostaje i ponovo primjenjuje promjene zabilježene u tim zapisnicima, istovremeno provjeravajući da li drugi čvorovi imaju novije verzije stranica koje se mijenjaju;
- vraća transakcije na čekanju.
Da bi pojednostavio prebacivanje između čvorova, Oracle ima koncept usluge - virtuelne instance. Instanca može poslužiti 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 prelazi na drugi čvor kada čvor otkaže.
IBM Pure Data Systems za transakcije
Klaster rješenje za DBMS pojavilo se u portfelju Blue Giant 2009. godine. Ideološki, to je nasljednik klastera Parallel Sysplex, izgrađen na „običnoj“ opremi. 2009. godine, DB2 pureScale je objavljen kao softverski paket, a 2012. godine IBM je ponudio uređaj pod nazivom Pure Data Systems for Transactions. Ne treba ga miješati sa Pure Data Systems for Analytics, koji nije ništa drugo do preimenovana Netezza.
Na prvi pogled, pureScale arhitektura je slična Oracle RAC-u: na isti način, nekoliko čvorova je povezano sa zajedničkim sistemom skladištenja podataka, a svaki čvor pokreće sopstvenu DBMS instancu sa sopstvenim memorijskim područjima i evidencijama transakcija. Ali, za razliku od Oraclea, DB2 ima namjensku uslugu zaključavanja koju predstavlja skup db2LLM* procesa. U konfiguraciji klastera, ova usluga je postavljena na odvojeni čvor, koji se u Parallel Sysplexu naziva mogućnost povezivanja (CF), a u Pure Data PowerHA.
PowerHA pruža sljedeće usluge:
- lock manager;
- globalni keš bafera;
- područje međuprocesnih komunikacija.
Za prijenos podataka od PowerHA do čvorova baze podataka i natrag, koristi se udaljeni pristup memoriji, tako da interkonekcija klastera mora podržavati RDMA protokol. PureScale može koristiti i Infiniband i RDMA preko Etherneta.
Ako čvor treba stranicu, a ova stranica nije u kešu, onda čvor traži stranicu u globalnoj keš memoriji i samo ako je nema, čita je s diska. Za razliku od Oraclea, zahtjev ide samo na PowerHA, a ne na susjedne čvorove.
Ako će instanca promijeniti red, zaključava ga u ekskluzivnom načinu, a stranicu na kojoj se red nalazi u dijeljenom načinu. Sve brave su registrovane u globalnom menadžeru zaključavanja. Kada se transakcija završi, čvor šalje poruku upravitelju zaključavanja, koji kopira izmijenjenu stranicu u globalnu keš memoriju, oslobađa 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 izvršio promjenu, otpustiti zaključavanje, poništiti izmijenjenu stranicu u keš memoriji drugih čvorova i dajte zaključavanje stranice čvoru koji je to zatražio.
“Prljave”, odnosno promijenjene, stranice se mogu upisivati na disk i iz običnog čvora i iz PowerHA (izbacivanje).
Ako jedan od pureScale čvorova ne uspije, oporavak je ograničen samo na one transakcije koje još nisu bile dovršene u vrijeme kvara: stranice koje je taj čvor modificirao u dovršenim transakcijama nalaze se u globalnoj keš memoriji na PowerHA-u. Čvor se ponovo pokreće u smanjenoj konfiguraciji na jednom od servera u klasteru, vraća transakcije na čekanju i otpušta zaključavanja.
PowerHA radi na dva servera i glavni čvor sinhrono replicira svoje stanje. Ako primarni PowerHA čvor pokvari, klaster nastavlja raditi s rezervnim čvorom.
Naravno, ako pristupite skupu podataka preko jednog čvora, ukupne performanse klastera će biti veće. PureScale može čak primijetiti da se određeno područje podataka obrađuje od strane jednog čvora, a zatim će sve brave povezane s tim područjem biti obrađene lokalno od strane čvora bez komunikacije s PowerHA. Ali čim aplikacija pokuša pristupiti ovim podacima preko 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. Uslovi testiranja, nažalost, nisu objavljeni.
HPE NonStop SQL
Hewlett-Packard Enterprise portfolio takođe ima svoju veoma dostupnu platformu. Ovo je NonStop platforma, koju je na tržište 1976. godine pustio Tandem Computers. 1997. kompaniju je kupio Compaq, koji se spojio sa Hewlett-Packard-om 2002. godine.
NonStop se koristi za izradu kritičnih aplikacija - na primjer, HLR ili obrada bankovnih kartica. Platforma se isporučuje u obliku softversko-hardverskog kompleksa (aparata), koji uključuje računarske čvorove, sistem za skladištenje podataka i komunikacionu opremu. ServerNet mreža (u savremenim sistemima - Infiniband) služi kako za razmjenu između čvorova tako i za pristup sistemu za pohranu podataka.
Rane verzije sistema koristile su vlasničke procesore koji su bili međusobno sinhronizovani: sve operacije je sinhrono izvodilo nekoliko procesora, a čim je jedan od procesora napravio grešku, bio je isključen, a drugi je nastavio da radi. Kasnije je sistem prešao na konvencionalne procesore (prvo MIPS, zatim Itanium i na kraju x86), a za sinhronizaciju su se počeli koristiti i drugi mehanizmi:
- poruke: svaki sistemski proces ima „sjenoviti“ blizanac, kojem aktivni proces periodično šalje poruke o svom statusu; ako glavni proces ne uspije, sjenčani proces počinje s radom od trenutka određenog posljednjom porukom;
- glasanje: sistem za skladištenje ima posebnu hardversku komponentu koja prihvata više identičnih pristupa i izvršava ih samo ako se pristupi podudaraju; Umjesto fizičke sinhronizacije, procesori rade asinhrono, a rezultati njihovog rada se upoređuju samo u I/O trenucima.
Od 1987. relacijski DBMS radi na NonStop platformi - prvo SQL/MP, a kasnije SQL/MX.
Cijela baza podataka je podijeljena na dijelove, a svaki dio je odgovoran za svoj vlastiti proces Data Access Manager (DAM). Pruža mehanizme za snimanje, keširanje i zaključavanje podataka. Obradu podataka provode procesi Executor Servera koji rade na istim čvorovima kao i odgovarajući menadžeri podataka. SQL/MX planer dijeli zadatke među izvršiocima i agregira rezultate. Kada je potrebno izvršiti dogovorene promjene, koristi se dvofazni protokol urezivanja koji obezbjeđuje TMF (Transaction Management Facility) biblioteka.
NonStop SQL može dati prioritet procesima tako da dugi analitički upiti ne ometaju izvršenje transakcije. Međutim, njegova svrha je upravo obrada kratkih transakcija, a ne analitika. Programer garantuje dostupnost klastera NonStop na nivou od pet „devetki“, odnosno zastoj je samo 5 minuta godišnje.
SAP-HANA
Prvo stabilno izdanje HANA DBMS-a (1.0) održano je u novembru 2010. godine, a SAP ERP paket je prešao na HANA u maju 2013. godine. Platforma je bazirana na kupljenim tehnologijama: TREX Search Engine (pretraga u stubnoj memoriji), P*TIME DBMS i MAX DB.
Sama riječ “HANA” je akronim, ANAlytical Appliance visokih performansi. Ovaj DBMS se isporučuje u obliku koda koji može raditi na bilo kojem x86 serveru, međutim, industrijske instalacije su dozvoljene samo na sertifikovanoj opremi. Dostupna rješenja od HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Neke Lenovo konfiguracije čak dozvoljavaju rad bez SAN-a - ulogu uobičajenog sistema skladištenja igra GPFS klaster na lokalnim diskovima.
Za razliku od gore navedenih platformi, HANA je DBMS u memoriji, tj. primarna slika podataka je pohranjena u RAM-u, a samo se zapisnici i periodični snimci zapisuju na disk radi oporavka u slučaju katastrofe.
Svaki čvor HANA klastera odgovoran je za svoj dio podataka, a mapa podataka je pohranjena u posebnoj komponenti – Name Server, koji se nalazi na čvoru koordinatora. Podaci se ne dupliciraju između čvorova. Informacije o zaključavanju se takođe pohranjuju na svakom čvoru, ali sistem ima globalni detektor zastoja.
Kada se HANA klijent poveže s klasterom, on preuzima njegovu topologiju i tada može direktno pristupiti bilo kojem čvoru, ovisno o tome koji su mu podaci potrebni. Ako transakcija utiče na podatke jednog čvora, tada je taj čvor može izvršiti lokalno, ali ako se podaci više čvorova promijene, inicijacijski čvor kontaktira čvor koordinatora, koji otvara i koordinira distribuiranu transakciju, urezujući je pomoću optimizirani dvofazni protokol urezivanja.
Koordinatorski čvor je dupliran, tako da ako koordinator ne uspije, rezervni čvor odmah preuzima. Ali ako čvor s podacima ne uspije, tada je jedini način da pristupite njegovim podacima ponovno pokretanje čvora. U pravilu, HANA klasteri održavaju rezervni server kako bi što prije ponovo pokrenuli izgubljeni čvor na njemu.
izvor: www.habr.com
