Teorema CAP este piatra de temelie a teoriei sistemelor distribuite. Bineînțeles, controversa în jurul acestuia nu se potolește: definițiile din ea nu sunt canonice și nu există nicio dovadă strictă... Cu toate acestea, stând ferm pe pozițiile bunului simț™ de zi cu zi, înțelegem intuitiv că teorema este adevărată.
Singurul lucru care nu este evident este semnificația literei „P”. Când clusterul este împărțit, acesta decide dacă nu răspunde până când se ajunge la un cvorum sau dacă returnează datele disponibile. În funcție de rezultatele acestei alegeri, sistemul este clasificat fie ca CP, fie ca AP. Cassandra, de exemplu, se poate comporta în orice fel, în funcție nici măcar de setările clusterului, ci de parametrii fiecărei solicitări specifice. Dar dacă sistemul nu este „P” și se împarte, atunci ce?
Răspunsul la această întrebare este oarecum neașteptat: un cluster CA nu se poate diviza.
Ce fel de cluster este acesta care nu se poate diviza?
Un atribut esențial al unui astfel de cluster este un sistem partajat de stocare a datelor. În marea majoritate a cazurilor, aceasta înseamnă conexiune printr-o rețea SAN, ceea ce limitează utilizarea soluțiilor CA la întreprinderile mari capabile să mențină o infrastructură SAN. Pentru ca mai multe... servere Pentru a lucra cu aceleași date, este necesar un sistem de fișiere cluster. Astfel de sisteme de fișiere sunt disponibile în portofoliile HPE (CFS), Veritas (VxCFS) și IBM (GPFS).
Oracle RAC
Opțiunea Real Application Cluster a apărut pentru prima dată în 2001, odată cu lansarea Oracle 9i. Într-un astfel de cluster, mai multe instanțe Server lucrați cu aceeași bază de date.
Oracle poate lucra atât cu un sistem de fișiere în cluster, cât și cu propria soluție - ASM, Automatic Storage Management.
Fiecare exemplar își păstrează propriul jurnal. Tranzacția este executată și comisă de o singură instanță. Dacă o instanță eșuează, unul dintre nodurile de cluster supraviețuitoare (instanțele) își citește jurnalul și restaurează datele pierdute - asigurând astfel disponibilitatea.
Toate instanțele își păstrează propriul cache și aceleași pagini (blocuri) pot fi în cache-urile mai multor instanțe în același timp. Mai mult, dacă o instanță are nevoie de o pagină și se află în memoria cache a altei instanțe, o poate obține de la vecinul său folosind mecanismul de fuziune a cache-ului în loc să citească de pe disc.
Dar ce se întâmplă dacă una dintre instanțe trebuie să schimbe datele?
Particularitatea Oracle este că nu are un serviciu de blocare dedicat: dacă serverul dorește să blocheze un rând, atunci înregistrarea de blocare este plasată direct pe pagina de memorie în care se află rândul blocat. Datorită acestei abordări, Oracle este campionul performanței printre bazele de date monolitice: serviciul de blocare nu devine niciodată un blocaj. Dar într-o configurație de cluster, o astfel de arhitectură poate duce la trafic intens în rețea și blocaje.
Odată ce o înregistrare este blocată, o instanță notifică toate celelalte instanțe că pagina care stochează acea înregistrare are o reținere exclusivă. Dacă o altă instanță trebuie să schimbe o înregistrare pe aceeași pagină, trebuie să aștepte până când modificările paginii sunt comise, adică informațiile de modificare sunt scrise într-un jurnal de pe disc (și tranzacția poate continua). De asemenea, se poate întâmpla ca o pagină să fie schimbată secvenţial cu mai multe copii, iar atunci când scrieţi pagina pe disc va trebui să aflaţi cine stochează versiunea curentă a acestei pagini.
Actualizarea aleatorie a acelorași pagini în diferite noduri RAC face ca performanța bazei de date să scadă dramatic, până la punctul în care performanța clusterului poate fi mai mică decât cea a unei singure instanțe.
Utilizarea corectă a Oracle RAC este să partiționați fizic datele (de exemplu, folosind un mecanism de tabel partiționat) și să accesați fiecare set de partiții printr-un nod dedicat. Scopul principal al RAC nu a fost scalarea orizontală, ci asigurarea toleranței la erori.
Dacă un nod nu mai răspunde la bătăile inimii, atunci nodul care l-a detectat începe mai întâi o procedură de vot pe disc. Dacă nodul lipsă nu este notat aici, atunci unul dintre noduri își asumă responsabilitatea pentru recuperarea datelor:
- „îngheață” toate paginile care se aflau în memoria cache a nodului lipsă;
- citește jurnalele (redo) ale nodului lipsă și reaplică modificările înregistrate în aceste jurnale, verificând simultan dacă alte noduri au versiuni mai recente ale paginilor în curs de modificare;
- derulează înapoi tranzacțiile în așteptare.
Pentru a simplifica comutarea între noduri, Oracle are conceptul unui serviciu - o instanță virtuală. O instanță poate deservi mai multe servicii, iar un serviciu se poate muta între noduri. O instanță de aplicație care deservește o anumită parte a bazei de date (de exemplu, un grup de clienți) funcționează cu un serviciu, iar serviciul responsabil pentru această parte a bazei de date se mută la un alt nod atunci când un nod eșuează.
IBM Pure Data Systems for Transactions
O soluție de cluster pentru DBMS a apărut în portofoliul Blue Giant în 2009. Din punct de vedere ideologic, este succesorul clusterului Parallel Sysplex, construit pe echipamente „obișnuite”. În 2009, a fost lansat DB2 pureScale, o suită de software, iar în 2012, IBM a oferit un dispozitiv numit Pure Data Systems for Transactions. Nu trebuie confundat cu Pure Data Systems for Analytics, care nu este altceva decât o Netezza redenumită.
La prima vedere, arhitectura pureScale este similară cu Oracle RAC: în același mod, mai multe noduri sunt conectate la un sistem comun de stocare a datelor, iar fiecare nod rulează propria instanță DBMS cu propriile zone de memorie și jurnalele de tranzacții. Dar, spre deosebire de Oracle, DB2 are un serviciu de blocare dedicat reprezentat de un set de procese db2LLM*. Într-o configurație de cluster, acest serviciu este plasat pe un nod separat, care se numește facilitate de cuplare (CF) în Parallel Sysplex și PowerHA în Pure Data.
PowerHA oferă următoarele servicii:
- manager de blocare;
- cache-ul tampon global;
- domeniul comunicațiilor între procese.
Pentru a transfera date de la PowerHA la nodurile bazei de date și înapoi, se folosește accesul la memorie de la distanță, astfel încât interconectarea clusterului trebuie să accepte protocolul RDMA. PureScale poate folosi atât Infiniband, cât și RDMA prin Ethernet.
Dacă un nod are nevoie de o pagină, iar această pagină nu este în cache, atunci nodul solicită pagina în memoria cache globală și numai dacă nu este acolo, o citește de pe disc. Spre deosebire de Oracle, cererea merge doar către PowerHA, și nu către nodurile învecinate.
Dacă o instanță urmează să schimbe un rând, îl blochează în modul exclusiv, iar pagina în care se află rândul în modul partajat. Toate blocările sunt înregistrate în managerul global de blocare. Când tranzacția se finalizează, nodul trimite un mesaj managerului de blocare, care copiază pagina modificată în memoria cache globală, eliberează blocările și invalidează pagina modificată în cache-urile altor noduri.
Dacă pagina în care se află rândul modificat este deja blocată, atunci managerul de blocare va citi pagina modificată din memoria nodului care a făcut modificarea, va elibera blocarea, va invalida pagina modificată în cache-urile altor noduri și dați blocarea paginii nodului care a solicitat-o.
„Dirty”, adică modificate, paginile pot fi scrise pe disc atât de la un nod obișnuit, cât și de la PowerHA (castout).
Dacă unul dintre nodurile pureScale eșuează, recuperarea este limitată doar la acele tranzacții care nu au fost încă finalizate în momentul eșecului: paginile modificate de acel nod în tranzacțiile finalizate se află în memoria cache globală pe PowerHA. Nodul repornește într-o configurație redusă pe unul dintre serverele din cluster, derulează înapoi tranzacțiile în așteptare și eliberează blocările.
PowerHA rulează pe două servere, iar nodul principal își reproduce starea în mod sincron. Dacă nodul PowerHA primar eșuează, clusterul continuă să funcționeze cu nodul de rezervă.
Desigur, dacă accesați setul de date printr-un singur nod, performanța globală a clusterului va fi mai mare. PureScale poate observa chiar că o anumită zonă de date este procesată de un nod, iar apoi toate blocările legate de acea zonă vor fi procesate local de către nod fără a comunica cu PowerHA. Dar de îndată ce aplicația încearcă să acceseze aceste date printr-un alt nod, procesarea centralizată a blocării va relua.
Testele interne ale IBM pe o sarcină de lucru de 90% citire și 10% scriere, care este foarte similară cu sarcinile de lucru de producție din lumea reală, arată o scalare aproape liniară până la 128 de noduri. Condițiile de testare, din păcate, nu sunt dezvăluite.
HPE NonStop SQL
Portofoliul Hewlett-Packard Enterprise are, de asemenea, propria sa platformă foarte disponibilă. Aceasta este platforma NonStop, lansată pe piață în 1976 de către Tandem Computers. În 1997, compania a fost achiziționată de Compaq, care la rândul său a fuzionat cu Hewlett-Packard în 2002.
NonStop este folosit pentru a construi aplicații critice - de exemplu, HLR sau procesarea cardurilor bancare. Platforma este livrată sub forma unui complex software și hardware (aparat), care include noduri de calcul, un sistem de stocare a datelor și echipamente de comunicație. Rețeaua ServerNet (în sistemele moderne - Infiniband) servește atât pentru schimbul între noduri, cât și pentru accesul la sistemul de stocare a datelor.
Versiunile timpurii ale sistemului foloseau procesoare proprietare care erau sincronizate între ele: toate operațiunile au fost efectuate sincron de mai multe procesoare și, de îndată ce unul dintre procesoare a făcut o eroare, a fost oprit, iar al doilea a continuat să funcționeze. Ulterior, sistemul a trecut la procesoare convenționale (întâi MIPS, apoi Itanium și în sfârșit x86), iar alte mecanisme au început să fie folosite pentru sincronizare:
- mesaje: fiecare proces de sistem are un geamăn „umbră”, căruia procesul activ îi trimite periodic mesaje despre starea sa; dacă procesul principal eșuează, procesul umbră începe să funcționeze din momentul determinat de ultimul mesaj;
- vot: sistemul de stocare are o componentă hardware specială care acceptă mai multe accesări identice și le execută numai dacă accesele se potrivesc; În loc de sincronizare fizică, procesoarele funcționează asincron, iar rezultatele muncii lor sunt comparate doar în momentele I/O.
Din 1987, pe platforma NonStop rulează un SGBD relațional - mai întâi SQL/MP, iar mai târziu SQL/MX.
Întreaga bază de date este împărțită în părți, iar fiecare parte este responsabilă pentru propriul proces Data Access Manager (DAM). Oferă mecanisme de înregistrare, stocare în cache și blocare a datelor. Prelucrarea datelor este efectuată de Procesele Executor Server care rulează pe aceleași noduri ca și managerii de date corespunzători. Planificatorul SQL/MX împarte sarcinile între executanți și adună rezultatele. Atunci când este necesar să se facă modificări convenite, se utilizează protocolul de comitere în două faze furnizat de biblioteca TMF (Transaction Management Facility).
NonStop SQL poate prioritiza procesele, astfel încât interogările analitice lungi să nu interfereze cu execuția tranzacției. Cu toate acestea, scopul său este tocmai procesarea tranzacțiilor scurte, și nu analiza. Dezvoltatorul garantează disponibilitatea clusterului NonStop la nivelul de cinci „nouă”, adică timpul de nefuncționare este de doar 5 minute pe an.
SAP-HANA
Prima lansare stabilă a DBMS HANA (1.0) a avut loc în noiembrie 2010, iar pachetul SAP ERP a trecut la HANA în mai 2013. Platforma se bazează pe tehnologii achiziționate: TREX Search Engine (căutare în stocare coloană), P*TIME DBMS și MAX DB.
Cuvântul „HANA” însuși este un acronim, Aparat analitic de înaltă performanță. Acest DBMS este furnizat sub formă de cod care poate rula pe orice server x86, cu toate acestea, instalațiile industriale sunt permise numai pe echipamente certificate. Soluții disponibile de la HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Unele configurații Lenovo permit chiar funcționarea fără SAN - rolul unui sistem de stocare comun este jucat de un cluster GPFS pe discuri locale.
Spre deosebire de platformele enumerate mai sus, HANA este un DBMS în memorie, adică imaginea de date primară este stocată în RAM și doar jurnalele și instantaneele periodice sunt scrise pe disc pentru recuperare în caz de dezastru.
Fiecare nod de cluster HANA este responsabil pentru propria sa parte a datelor, iar harta de date este stocată într-o componentă specială – Name Server, situată pe nodul coordonator. Datele nu sunt duplicate între noduri. Informațiile de blocare sunt, de asemenea, stocate pe fiecare nod, dar sistemul are un detector global de blocare.
Când un client HANA se conectează la un cluster, acesta își descarcă topologia și apoi poate accesa direct orice nod, în funcție de datele de care are nevoie. Dacă o tranzacție afectează datele unui singur nod, atunci poate fi executată local de către acel nod, dar dacă datele mai multor noduri se modifică, nodul inițiator contactează nodul coordonator, care deschide și coordonează tranzacția distribuită, comitând-o folosind un protocol optimizat de comitere în două faze.
Nodul coordonator este duplicat, așa că dacă coordonatorul eșuează, nodul de rezervă preia imediat controlul. Dar dacă un nod cu date eșuează, atunci singura modalitate de a-și accesa datele este repornirea nodului. De regulă, clusterele HANA mențin un server de rezervă pentru a reporni cât mai repede posibil un nod pierdut pe acesta.
Sursa: www.habr.com
