U teorema CAP hè a basa di a teoria di i sistemi distribuiti. Di sicuru, a cuntruversia chì l'intorna ùn si cala micca: e definizioni in questu ùn sò micca canoniche, è ùn ci hè micca una prova stretta ... Tuttavia, fermu nantu à e pusizioni di u sensu cumunu di ogni ghjornu ™, capiscenu intuitivamente chì u teorema hè veru.
L'unicu ciò chì ùn hè micca evidenti hè u significatu di a lettera "P". Quandu u cluster hè divisu, decide s'ellu ùn risponde micca finu à chì un quorum hè righjuntu, o per rinvià e dati chì sò dispunibili. Sicondu i risultati di sta scelta, u sistema hè classificatu cum'è CP o AP. Cassandra, per esempiu, pò cumportà in ogni modu, secondu micca ancu i paràmetri di u cluster, ma i paràmetri di ogni dumanda specifica. Ma se u sistema ùn hè micca "P" è si divide, allora chì?
A risposta à sta quistione hè un pocu inaspettata: un cluster CA ùn pò micca split.
Chì tipu di cluster hè questu chì ùn pò micca split?
Un attributu essenziale di un tale cluster hè un sistema di almacenamentu di dati spartutu. In a grande maggioranza di i casi, questu significa cunnessione via una SAN, ciò chì limita l'usu di e soluzioni CA à e grande imprese capaci di mantene una infrastruttura SAN. Per chì parechji servitori Per travaglià cù i stessi dati, hè necessariu un sistema di fugliali in cluster. Tali sistemi di fugliali sò dispunibili in i portafogli di HPE (CFS), Veritas (VxCFS) è IBM (GPFS).
Oracle RAC
L'opzione Real Application Cluster hè apparsa per a prima volta in u 2001 cù a liberazione di Oracle 9i. In un tale cluster, parechje istanze servitore travaglià cù a listessa basa di dati.
Oracle pò travaglià cù un sistema di file clustered è a so propria suluzione - ASM, Gestione Automatica di Storage.
Ogni copia mantene u so propiu ghjurnale. A transazzione hè eseguita è impegnata da una sola istanza. Se una istanza falla, unu di i nodi di cluster sopravviventi (istanze) leghje u so logu è restaurà i dati persi - assicurendu cusì a dispunibilità.
Tutte e istanze mantenenu u so propiu cache, è e stesse pagine (blocchi) ponu esse in i cache di parechje istanze à u stessu tempu. Inoltre, se una istanza hà bisognu di una pagina è si trova in a cache di un'altra istanza, pò uttene da u so vicinu utilizendu u mecanismu di fusione di cache invece di leghje da u discu.
Ma chì succede se unu di i casi deve cambià dati?
A peculiarità di l'Oracle hè chì ùn hà micca un serviziu di chjusu dedicatu: se u servitore vole chjude una fila, allora u registru di chjusu hè situatu direttamente nantu à a pagina di memoria induve si trova a fila chjusa. Grazie à questu approcciu, Oracle hè u campione di rendiment trà e basa di dati monolitiche: u serviziu di chjusi ùn diventa mai un collu di bottiglia. Ma in una cunfigurazione di cluster, una tale architettura pò purtà à un intensu trafficu di rete è blocchi.
Una volta chì un registru hè chjusu, un'istanza notifica à tutti l'altri casi chì a pagina chì guarda quellu registru hà una riserva esclusiva. Se un altru casu hà bisognu di cambià un registru in a stessa pagina, deve aspittà finu à chì i cambiamenti à a pagina sò impegnati, vale à dì, l'infurmazione di cambiamentu hè scritta à un ghjurnale nantu à u discu (è a transazzione pò cuntinuà). Puderà ancu accade chì una pagina serà cambiata in sequenza da parechje copie, è dopu, quandu scrive a pagina à u discu, avete da sapè quale guarda a versione attuale di sta pagina.
L'aghjurnà aleatoriu di e stesse pagine in diversi nodi RAC face chì a prestazione di a basa di dati cade drasticamente, finu à u puntu chì u rendiment di cluster pò esse più bassu di quellu di una sola istanza.
L'usu currettu di Oracle RAC hè di particionà fisicamente e dati (per esempiu, utilizendu un mecanismu di tavula partizionata) è accede à ogni settore di partizioni per un node dedicatu. U scopu principale di RAC ùn era micca scala horizontale, ma assicurendu a tolleranza di difetti.
Se un node smette di risponde à un battitu di cori, allora u node chì l'hà rilevatu principia prima una prucedura di votu nantu à u discu. Se u node mancante ùn hè micca nutatu quì, allora unu di i nodi assume a rispunsabilità per a ricuperazione di dati:
- "congela" tutte e pagine chì eranu in a cache di u node mancante;
- leghje i logs (redo) di u node mancante è riapplicà i cambiamenti arregistrati in questi logs, verificate simultaneamente se altri nodi anu versioni più recenti di e pagine chì sò cambiate;
- ripiglià e transazzioni pendenti.
Per simplificà u cambiamentu trà i nodi, Oracle hà u cuncettu di un serviziu - una istanza virtuale. Un esempiu pò serve parechji servizii, è un serviziu pò spustà trà i nodi. Un esempiu di l'applicazione chì serve una certa parte di a basa di dati (per esempiu, un gruppu di clienti) travaglia cù un serviziu, è u serviziu rispunsevule per questa parte di a basa di dati si move in un altru node quandu un node falla.
IBM Pure Data Systems for Transactions
Una soluzione di cluster per DBMS hè apparsu in a cartera Blue Giant in 2009. Ideologicamente, hè u successore di u cluster Parallel Sysplex, custruitu nantu à l'equipaggiu "regular". In u 2009, DB2 pureScale, una suite di software, hè stata liberata, è in u 2012, IBM offre un appliance chjamatu Pure Data Systems for Transactions. Ùn deve esse cunfunditu cù Pure Data Systems for Analytics, chì ùn hè nunda più cà una Netezza rinominata.
À u primu sguardu, l'architettura pureScale hè simile à l'Oracle RAC: in a listessa manera, parechji nodi sò cunnessi à un sistema di almacenamentu di dati cumuni, è ogni nodu gestisce a so propria istanza DBMS cù e so zoni di memoria è logs di transazzione. Ma, à u cuntrariu di Oracle, DB2 hà un serviziu di bloccu dedicatu rapprisintatu da un inseme di prucessi db2LLM *. In una cunfigurazione di cluster, stu serviziu hè situatu nantu à un node separatu, chì hè chjamatu facility d'accoppiamentu (CF) in Parallel Sysplex, è PowerHA in Pure Data.
PowerHA furnisce i seguenti servizii:
- gestore di serratura;
- cache di buffer globale;
- zona di cumunicazioni interprocessu.
Per trasfiriri dati da PowerHA à i nodi di basa di dati è torna, l'accessu di memoria remota hè utilizatu, cusì l'interconnessione di cluster deve sustene u protocolu RDMA. PureScale pò aduprà sia Infiniband sia RDMA per Ethernet.
Se un node hà bisognu di una pagina, è sta pagina ùn hè micca in u cache, allura u node dumanda a pagina in u cache globale, è solu s'ellu ùn hè micca quì, leghje da u discu. A cuntrariu di Oracle, a dumanda va solu à PowerHA, è micca à i nodi vicini.
Se una istanza hà da cambià una fila, a chjude in modu exclusivu, è a pagina induve a fila si trova in modu spartutu. Tutte e serrature sò registrate in u gestore di serratura globale. Quandu a transazzione cumpleta, u node manda un missaghju à u gestore di serratura, chì copia a pagina mudificata à a cache globale, libera i chjusi, è invalida a pagina mudificata in i cache di altri nodi.
Se a pagina in quale si trova a fila mudificata hè digià chjusa, allora u gestore di serratura leghje a pagina mudificata da a memoria di u node chì hà fattu u cambiamentu, liberate a serratura, invalida a pagina mudificata in i cache di altri nodi, è dà u bloccu di pagina à u node chì l'hà dumandatu.
"Dirty", vale à dì, cambiatu, e pagine ponu esse scritte à u discu da un node regulare è da PowerHA (castout).
Se unu di i nodi di pureScale falla, a ricuperazione hè limitata à solu quelli transazzione chì ùn anu micca finitu à u mumentu di u fallimentu: e pagine mudificate da quellu node in transazzione cumpleta sò in u cache globale nantu à PowerHA. U node riavvia in una cunfigurazione ridutta nantu à unu di i servitori in u cluster, rinvià e transacciones pendenti è libera i chjusi.
PowerHA funziona nantu à dui servitori è u nodu maestru replica u so statu in modu sincronu. Se u node PowerHA primariu falla, u cluster cuntinueghja à operare cù u node di salvezza.
Di sicuru, se accede à u settore di dati attraversu un unicu node, u rendiment generale di u cluster serà più altu. PureScale pò ancu nutà chì una certa zona di dati hè trattata da un node, è dopu tutti i chjusi ligati à quella zona seranu processati in u locu da u node senza cumunicà cù PowerHA. Ma appena l 'applicazzioni prova à accede à sta dati à traversu un altru node, u prucessu di serratura centralizata ripiglià.
I testi interni di IBM nantu à una carica di travagliu di 90% di lettura è 10% di scrittura, chì hè assai simili à i carichi di travagliu di produzzione in u mondu reale, mostranu una scala quasi lineare finu à 128 nodi. E cundizioni di prova, sfurtunatamenti, ùn sò micca divulgate.
HPE NonStop SQL
A cartera Hewlett-Packard Enterprise hà ancu a so propria piattaforma altamente dispunibile. Questa hè a piattaforma NonStop, liberata à u mercatu in u 1976 da Tandem Computers. In u 1997, a cumpagnia hè stata acquistata da Compaq, chì in u 2002 si fusiona cù Hewlett-Packard.
NonStop hè adupratu per custruisce applicazioni critiche - per esempiu, HLR o trasfurmazioni di carte bancarie. A piattaforma hè furnita in forma di un cumplessu di software è hardware (apparechju), chì include nodi di computing, un sistema di almacenamentu di dati è un equipamentu di cumunicazione. A rete ServerNet (in i sistemi muderni - Infiniband) serve sia per u scambiu trà i nodi sia per l'accessu à u sistema di almacenamiento di dati.
I primi versioni di u sistema utilizanu prucessori proprietarii chì sò stati sincronizati cù l'altri: tutte l'operazioni sò state realizate in modu sincronu da parechji prucessori, è appena unu di i prucessori hà fattu un errore, hè stata disattivata, è a seconda cuntinuava à travaglià. In seguitu, u sistema hà cambiatu à i prucessori cunvinziunali (prima MIPS, dopu Itanium è infine x86), è altri miccanismi cuminciaru à esse usatu per a sincronizazione:
- missaghji: ogni prucessu di u sistema hà un gemello "ombra", à quale u prucessu attivu manda periodicamente missaghji nantu à u so statutu; se u prucessu principale falla, u prucessu d'ombra principia à travaglià da u mumentu determinatu da l'ultimu missaghju;
- votu: u sistema di almacenamentu hà un cumpunente hardware speciale chì accetta parechje accessi identici è eseguisce solu se l'accessi currispondenu; Invece di a sincronizazione fisica, i prucessori operanu in modu asincronu, è i risultati di u so travagliu sò paragunati solu in i mumenti I / O.
Dapoi u 1987, un DBMS relazionale hè in esecuzione nantu à a piattaforma NonStop - prima SQL / MP, è dopu SQL / MX.
A basa di dati sana hè divisa in parti, è ogni parte hè rispunsevule per u so propiu prucessu di Data Access Manager (DAM). Fornisce meccanismi di registrazione di dati, caching è bloccaggio. U prucessu di dati hè realizatu da i Processi di l'Executor Server in esecuzione nantu à i stessi nodi cum'è i gestori di dati currispundenti. U pianificatore SQL / MX divide i travaglii trà esecutori è aggrega i risultati. Quandu hè necessariu di fà cambiamenti accunsentutu, u protocolu di cummissione in dui fasi furnitu da a biblioteca TMF (Transaction Management Facility) hè utilizatu.
NonStop SQL pò dà priorità à i prucessi in modu chì e dumande analitiche longu ùn interferiscenu micca cù l'esekzione di transazzione. Tuttavia, u so scopu hè precisamente u prucessu di transazzione curta, è micca analitiche. U sviluppatore guarantisci a dispunibilità di u cluster NonStop à u livellu di cinque "novi", vale à dì, u downtime hè solu 5 minuti annu.
SAP-HANA
A prima versione stabile di u DBMS HANA (1.0) hè stata fatta in nuvembre 2010, è u pacchettu SAP ERP hà cambiatu à HANA in maghju 2013. A piattaforma hè basatu annantu à e tecnulugia acquistate: TREX Search Engine (ricerca in l'almacenamiento columnar), P * TIME DBMS è MAX DB.
A parolla "HANA" stessu hè un acronimu, High performance ANalytical Appliance. Stu DBMS hè furnitu in forma di codice chì pò esse esecutatu nantu à qualsiasi servitori x86, ma l'installazione industriale sò permesse solu nantu à l'equipaggiu certificatu. Soluzioni dispunibili da HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Certi cunfigurazioni Lenovo permettenu ancu l'operazione senza SAN - u rolu di un sistema di almacenamentu cumuni hè ghjucatu da un cluster GPFS nantu à i dischi lucali.
A cuntrariu di e piattaforme elencate sopra, HANA hè un DBMS in memoria, vale à dì chì l'imaghjini di dati primari sò almacenati in RAM, è solu logs è snapshots periodici sò scritti à u discu per a ricuperazione in casu di un disastru.
Ogni node di cluster HANA hè rispunsevuli di a so propria parte di e dati, è a mappa di dati hè almacenata in un cumpunente speciale - Name Server, situatu nantu à u node coordinatore. I dati ùn sò micca duplicati trà i nodi. L'infurmazione di bloccu hè ancu almacenata in ogni nodu, ma u sistema hà un detector di bloccu globale.
Quandu un cliente HANA si cunnetta à un cluster, scarica a so topulugia è pò accede à qualsiasi nodu direttamente, secondu a dati chì hà bisognu. Se una transazzione affetta i dati di un unicu node, allora pò esse eseguitu in u locu da quellu node, ma se i dati di parechji nodi cambianu, u nodu iniziali cuntattate u node coordinatore, chì apre è coordina a transazzione distribuita, cummittendu cù una transazzione. protokollu di cummissione in duie fasi ottimizzati.
U node di u coordinatore hè duplicatu, perchè se u coordinatore falla, u node di copia di salvezza piglia subitu. Ma se un node cù dati falla, l'unicu modu per accede à i so dati hè di riavvia u node. In regula, i clusters HANA mantenenu un servitore spare per riavvià un node persu nantu à ellu u più prestu pussibule.
Source: www.habr.com
