Il teorema CAP è una pietra angolare della teoria dei sistemi distribuiti. Certo, le controversie su di esso non si placano: le definizioni non sono canoniche e non esiste una dimostrazione rigorosa... Tuttavia, fermamente ancorati al buon senso comune™, comprendiamo intuitivamente che il teorema è valido.
L'unica cosa che non è ovvia è il significato della lettera 'P'. Quando un cluster si divide, deve decidere se non rispondere finché non si raggiunge il quorum, oppure se fornire i dati disponibili. A seconda dei risultati di questa scelta, il sistema viene classificato come CP o AP. Cassandra, ad esempio, può comportarsi in entrambi i modi, a seconda non solo delle impostazioni del cluster, ma anche dei parametri di ogni singola richiesta. Ma se il sistema non è 'P' e si è diviso, allora – cosa succede?
La risposta a questa domanda è piuttosto inaspettata: un cluster CA non può dividersi.
Che tipo di cluster è dunque quello che non può dividersi?
Un attributo indispensabile di un cluster di questo tipo è il sistema di archiviazione dati condiviso. Nella maggior parte dei casi, questo implica una connessione tramite SAN, il che limita l'uso delle soluzioni CA alle grandi imprese in grado di mantenere un'infrastruttura SAN. Per permettere a più server di lavorare con gli stessi dati, è necessaria un file system cluster. Tali file system sono presenti nei portafogli HPE (CFS), Veritas (VxCFS) e IBM (GPFS).
Oracle RAC
L'opzione Real Application Cluster è stata introdotta per la prima volta nel 2001 con il rilascio di Oracle 9i. In un tale cluster, più istanze server lavorano sulla stessa base di dati.
Oracle può operare sia con un file system cluster, sia con la propria soluzione – ASM, Automatic Storage Management.
Ogni istanza tiene un proprio registro. La transazione viene eseguita e registrata da un'istanza. In caso di guasto di un'istanza, uno dei nodi cluster sopravvissuti (istanze) legge il suo registro e ripristina i dati persi – grazie a questo si garantisce la disponibilità.
Tutte le istanze supportano una cache propria e le stesse pagine (blocchi) possono trovarsi contemporaneamente nelle cache di più istanze. Inoltre, se un'istanza ha bisogno di una certa pagina e questa si trova nella cache di un'altra istanza, può ottenerla dal "vicino" tramite il meccanismo di cache fusion anziché leggerla dal disco.
Ma cosa succede se uno delle istanze deve modificare i dati?
La peculiarità di Oracle è che non ha un servizio di blocco dedicato: se un server desidera bloccare una riga, l’informazione sul blocco viene scritta direttamente nella pagina di memoria dove si trova la riga bloccata. Grazie a questo approccio, Oracle è il campione delle prestazioni tra i database monolitici: il servizio di blocco non diventa mai un collo di bottiglia. Tuttavia, in una configurazione cluster, questa architettura può portare a un intenso scambio di rete e a blocchi reciproci.
Una volta bloccata la registrazione, l'istanza avvisa tutte le altre istanze che la pagina in cui è memorizzata questa registrazione è stata presa in modalità monopolio. Se un'altra istanza deve modificare la registrazione sulla stessa pagina, deve attendere che le modifiche sulla pagina siano state confermate, cioè che le informazioni sulla modifica siano state scritte nel registro su disco (nel frattempo, la transazione può continuare). Può anche succedere che la pagina venga modificata consecutivamente da più istanze, e in tal caso, al momento della scrittura della pagina su disco, sarà necessario determinare chi detiene la versione attuale di quella pagina.
L'aggiornamento casuale delle stesse pagine tramite diversi nodi RAC determina un forte calo delle prestazioni del database, fino al punto in cui le prestazioni del cluster possono essere inferiori a quelle di un'unica istanza.
L'uso corretto di Oracle RAC implica la suddivisione fisica dei dati (ad esempio, utilizzando meccanismi di tabelle partizionate) e l'accesso a ciascun set di partizioni tramite un nodo dedicato. L'obiettivo principale di RAC non è stato quello di ottenere scalabilità orizzontale, ma di garantire la continuità operativa.
Quando un nodo smette di rispondere al segnale di heartbeat, il nodo che lo rileva per primo avvia una procedura di voto su disco. Se il nodo mancante non si registra nemmeno in questo caso, uno dei nodi assume le responsabilità per il ripristino dei dati:
- «congela» tutte le pagine che si trovavano nella cache del nodo mancante;
- legge i registri (redo) del nodo mancante e riapplica le modifiche registrate in tali registri, nel frattempo controllando se ci sono versioni più recenti delle pagine modificate presso altri nodi;
- annulla le transazioni incomplete.
Per semplificare il passaggio tra i nodi, Oracle ha il concetto di servizio – un'istanza virtuale. Un'istanza può gestire diversi servizi, e un servizio può spostarsi tra i nodi. Un'istanza applicativa che gestisce una specifica parte del database (ad esempio, un gruppo di clienti) lavora con un servizio, e il servizio responsabile di quella parte del database si sposta su un altro nodo in caso di guasto del nodo.
IBM Pure Data Systems for Transactions
La soluzione cluster per database è stata introdotta nel portafoglio del Gigante Blu nel 2009. Ideologicamente, essa rappresenta l'eredità del cluster Parallel Sysplex, costruito su hardware "normale". Nel 2009 è stato lanciato il prodotto DB2 pureScale, che rappresenta un pacchetto software, e nel 2012 IBM ha offerto un pacchetto software e hardware (appliance) chiamato Pure Data Systems for Transactions. Non va confuso con Pure Data Systems for Analytics, che non è altro che un rebranding di Netezza.
L'architettura pureScale assomiglia a prima vista a Oracle RAC: allo stesso modo, più nodi sono collegati a un sistema di archiviazione dati condiviso, e su ogni nodo è in esecuzione la propria istanza del DBMS con le proprie aree di memoria e registri delle transazioni. Tuttavia, a differenza di Oracle, in DB2 è presente un servizio di lock dedicato, rappresentato da un insieme di processi db2LLM*. In una configurazione a cluster, questo servizio è spostato su un nodo separato, che in Parallel Sysplex è chiamato coupling facility (CF), e in Pure Data – PowerHA.
PowerHA fornisce i seguenti servizi:
- gestore dei lock;
- cache globale dei buffer;
- area delle comunicazioni interprocesso.
Per il trasferimento dei dati da PowerHA ai nodi del database e viceversa si utilizza l'accesso remoto alla memoria, quindi l'interconnessione del cluster deve supportare il protocollo RDMA. PureScale può utilizzare sia Infiniband che RDMA over Ethernet.
Se un nodo ha bisogno di una pagina e quella pagina non è nella cache, il nodo richiede la pagina nella cache globale, e solo se non è presente nemmeno lì, la legge dal disco. A differenza di Oracle, la richiesta avviene solo in PowerHA, e non nei nodi adiacenti.
Se un'istanza sta per modificare una riga, la blocca in modo esclusivo e la pagina in cui si trova la riga in modo condiviso. Tutti i blocchi vengono registrati nel gestore globale dei blocchi. Quando la transazione è completata, il nodo invia un messaggio al gestore dei blocchi, il quale copia la pagina modificata nella cache globale, rimuove i blocchi e invalida la pagina modificata nelle cache degli altri nodi.
Se la pagina contenente la riga modificabile è già bloccata, il gestore dei blocchi leggerà la pagina modificata dalla memoria del nodo che ha effettuato le modifiche, rimuoverà il blocco, invaliderà la pagina modificata nelle cache degli altri nodi e restituirà il blocco della pagina al nodo che l'ha richiesta.
Le pagine "sporche", cioè modificate, possono essere scritte su disco sia da un nodo normale sia da PowerHA (castout).
In caso di guasto di uno dei nodi, il ripristino in pureScale è limitato solo alle transazioni che non erano state ancora completate al momento dell'interruzione: le pagine modificate da questo nodo nelle transazioni concluse sono presenti nella cache globale su PowerHA. Il nodo viene riavviato in una configurazione ridotta su uno dei server del cluster, annulla le transazioni non completate e libera i lock.
PowerHA opera su due server, e il nodo principale replica in modo sincrono il proprio stato. In caso di guasto del nodo principale, il cluster PowerHA continua a funzionare con il nodo di riserva.
Naturalmente, se si accede a un set di dati tramite un nodo, le prestazioni complessive del cluster saranno superiori. PureScale può anche notare che una certa area di dati è elaborata da un nodo, e in tal caso tutti i lock relativi a quest'area saranno gestiti localmente dal nodo senza comunicazioni con PowerHA. Ma non appena l'applicazione tenterà di accedere a questi dati tramite un altro nodo, il trattamento centralizzato dei lock riprenderà.
I test interni di IBM su un carico composto per il 90% da operazioni di lettura e per il 10% da operazioni di scrittura, che riflette molto da vicino un carico industriale reale, mostrano quasi una scalabilità lineare fino a 128 nodi. Purtroppo, le condizioni di test non vengono divulgate.
HPE NonStop SQL
Anche Hewlett-Packard Enterprise dispone della propria piattaforma ad alta disponibilità. Si tratta della piattaforma NonStop, lanciata sul mercato nel 1976 da Tandem Computers. Nel 1997, l'azienda è stata acquisita da Compaq, che a sua volta è entrata a far parte di Hewlett-Packard nel 2002.
NonStop viene utilizzato per costruire applicazioni critiche, come ad esempio HLR o il processamento delle carte bancarie. La piattaforma viene fornita come un sistema hardware e software (appliance), che include nodi di calcolo, un sistema di archiviazione dati e apparecchiature di comunicazione. La rete ServerNet (nelle moderne versioni – Infiniband) serve sia per lo scambio tra i nodi sia per l'accesso al sistema di archiviazione dati.
Nelle versioni precedenti del sistema venivano utilizzati processori proprietari che erano sincronizzati tra loro: tutte le operazioni venivano eseguite simultaneamente da più processori, e quando uno di essi commetteva un errore, veniva disattivato mentre gli altri continuavano a funzionare. Successivamente, il sistema è passato a processori standard (inizialmente MIPS, poi Itanium e infine x86), e sono stati utilizzati altri meccanismi per la sincronizzazione:
- messaggi: ogni processo di sistema ha un doppione 'ombra', a cui il processo attivo invia periodicamente messaggi sul proprio stato; in caso di guasto del processo principale, il processo ombra inizia a funzionare dal punto definito dall'ultimo messaggio;
- votazione: il sistema di archiviazione dei dati ha un componente hardware speciale che riceve più richieste identiche e le esegue solo se le richieste coincidono; invece di una sincronizzazione fisica, i processori operano in modo asincrono e i risultati del loro lavoro vengono confrontati solo nei momenti di input/uscita.
Dal 1987, sulla piattaforma NonStop opera un DBMS relazionale, inizialmente SQL/MP e successivamente SQL/MX.
L'intera base di dati è suddivisa in parti, ciascuna delle quali è gestita da un processo Data Access Manager (DAM). Questo processo garantisce la scrittura dei dati, la memorizzazione nella cache e il meccanismo di bloccaggio. L'elaborazione dei dati è affidata ai processi esecutori (Executor Server Process), che operano sugli stessi nodi dei rispettivi manager dei dati. Il pianificatore SQL/MX distribuisce i compiti tra gli esecutori e combina i risultati. Per apportare modifiche concordate viene utilizzato un protocollo di commit in due fasi, garantito dalla libreria TMF (Transaction Management Facility).
NonStop SQL è in grado di dare priorità ai processi in modo che le lunghe query analitiche non disturbino l'esecuzione delle transazioni. Tuttavia, il suo scopo è specificamente l'elaborazione di transazioni brevi e non l'analisi. Lo sviluppatore garantisce la disponibilità del cluster NonStop a un livello di cinque 'nove', ossia un'interruzione di soli 5 minuti all'anno.
SAP HANA
La prima versione stabile del DBMS HANA (1.0) è stata rilasciata nel novembre 2010, e il pacchetto SAP ERP è passato a HANA a partire da maggio 2013. La piattaforma si basa su tecnologie acquistate: il motore di ricerca TREX (per la ricerca nel data warehouse colonnare), il DBMS P*TIME e MAX DB.
La parola «HANA» è un acronimo che sta per High performance ANalytical Appliance. Questo DBMS è fornito sotto forma di codice, che può funzionare su qualsiasi server x86, tuttavia, le installazioni industriali sono consentite solo su hardware certificato. Sono disponibili soluzioni da HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Alcune configurazioni Lenovo possono persino funzionare senza SAN, poiché il cluster GPFS su dischi locali svolge il ruolo di storage condiviso.
A differenza delle piattaforme sopra menzionate, HANA è un DBMS in-memory, cioè l'immagine primaria dei dati è conservata nella memoria RAM, e solo i log e gli snapshot periodici vengono registrati su disco, per il recupero in caso di guasto.
Ogni nodo del cluster HANA gestisce la propria parte di dati, mentre la mappa dei dati è memorizzata in un componente speciale — il Name Server, situato nel nodo coordinatore. I dati non vengono duplicati tra i nodi. Le informazioni sui lock sono anch'esse memorizzate su ciascun nodo, ma il sistema dispone di un rilevatore globale di deadlock.
Il client HANA, durante la connessione al cluster, carica la sua topologia e può successivamente interagire direttamente con qualsiasi nodo a seconda dei dati di cui ha bisogno. Se la transazione coinvolge i dati di un singolo nodo, può essere eseguita localmente su quel nodo, ma se i dati di più nodi vengono modificati, il nodo iniziale contatta il nodo coordinatore, il quale apre e coordina la transazione distribuita, registrandola tramite un protocollo di commit a due fasi ottimizzato.
Il nodo coordinatore è duplicato, quindi in caso di guasto del coordinatore, un nodo di riserva entra immediatamente in funzione. Se invece si guasta un nodo contenente dati, l'unico modo per accedere a quei dati è riavviare il nodo. Di solito, nei cluster HANA è disponibile un server di riserva (spare) per poter riavviare rapidamente il nodo perduto.
Fonte: habr.com
