Il teorema CAP è la pietra angolare della teoria dei sistemi distribuiti. Certamente, i dibattiti al riguardo non si placano: le definizioni non sono canoniche, e non esiste una prova rigorosa... Tuttavia, rimanendo saldi sulle posizioni del buon senso comune™, comprendiamo intuitivamente che il teorema è corretto.
L'unica cosa che non è ovvia è il significato della lettera «P». Quando un cluster si separa, decide se non rispondere finché non si raggiunge un 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, non in base alle impostazioni del cluster, ma ai parametri di ciascuna richiesta specifica. Ma se il sistema non è „P“ e si separa, allora – che succede?
La risposta a questa domanda è piuttosto inaspettata: un cluster CA non può separarsi.
Qual è quindi questo cluster che non può separarsi?
Un attributo imprescindibile di tale cluster è un sistema di archiviazione dati condiviso. Nella stragrande maggioranza dei casi, questo significa una connessione tramite SAN, il che limita l'applicazione delle soluzioni CA alle grandi aziende in grado di mantenere un'infrastruttura SAN. Affinché più server possono lavorare con gli stessi dati, è necessaria un file system cluster. Tali file system sono disponibili nei portafogli di HPE (CFS), Veritas (VxCFS) e IBM (GPFS).
Oracle RAC
L'opzione Real Application Cluster è apparsa per la prima volta nel 2001 con il rilascio di Oracle 9i. In un tale cluster, più istanze server lavorano con lo stesso database.
Oracle può lavorare sia con un file system cluster, sia con la propria soluzione – ASM, Automatic Storage Management.
Ogni istanza tiene il proprio registro. La transazione viene eseguita e registrata da un'istanza. In caso di guasto di un'istanza, uno dei nodi sopravvissuti del cluster (istanze) legge il suo registro e recupera i dati persi: in questo modo si garantisce la disponibilità.
Tutte le istanze supportano la propria cache, e le stesse pagine (blocchi) possono trovarsi contemporaneamente nelle cache di più istanze. Inoltre, se una pagina è necessaria a un'istanza, e 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 degli istanze ha bisogno di modificare i dati?
La caratteristica di Oracle è che non ha un servizio di locking dedicato: se il server desidera bloccare una riga, il record di locking viene impresso direttamente nella pagina di memoria dove si trova la riga bloccata. Grazie a questo approccio, Oracle è il campione di prestazioni tra i database monolitici: il servizio di locking non diventa mai un collo di bottiglia. Tuttavia, in una configurazione cluster, questa architettura può portare a un intenso scambio di rete e a deadlock reciproci.
Non appena un record viene bloccato, l'istanza informa tutte le altre istanze che la pagina contenente questo record è stata acquisita in modalità monopolio. Se un'altra istanza ha bisogno di modificare un record sulla stessa pagina, deve attendere che le modifiche sulla pagina siano confermate, ovvero che l'informazione sulla modifica sia scritta nel journal sul disco (in questo mentre la transazione può continuare). Può anche accadere che la pagina venga modificata consecutivamente da più istanze, e in tal caso, quando la pagina viene scritta sul disco, sarà necessario determinare chi detiene la versione più recente di questa pagina.
L’aggiornamento casuale delle stesse pagine attraverso nodi diversi del RAC porta a un drastico calo delle prestazioni del database, tanto da essere possibile che le prestazioni del cluster siano inferiori a quelle di un'istanza singola.
Un uso corretto di Oracle RAC implica la divisione fisica dei dati (ad esempio, utilizzando meccanismi di tabelle partizionate) e l'accesso a ciascun set di sezioni tramite un nodo dedicato. L'obiettivo principale del RAC è diventato non lo scaling orizzontale, ma garantire la tolleranza ai guasti.
Se un nodo smette di rispondere al heartbeat, il nodo che lo rileva per primo avvia una procedura di voto su disco. Se anche in questo caso il nodo mancante non si segnala, uno dei nodi si fa carico del recupero dei dati:
- «congela» tutte le pagine presenti nella cache del nodo mancante;
- legge i log (redo) del nodo mancante e riapplica le modifiche registrate in questi log, verificando nel contempo se ci sono versioni più recenti delle pagine modificate presso altri nodi;
- riavvia le transazioni non completate.
Per semplificare la transizione tra i nodi, Oracle ha il concetto di servizio – un'istanza virtuale. Un'istanza può gestire più servizi, e un servizio può trasferirsi tra i nodi. Un'istanza di applicazione, che si occupa di una specifica porzione del database (ad esempio, un gruppo di clienti), lavora con un servizio, e il servizio, responsabile di questa porzione di database, si trasferisce su un altro nodo in caso di guasto di quest'ultimo.
IBM Pure Data Systems for Transactions
La soluzione cluster per il DBMS è apparsa nel portafoglio del Grande Blu nel 2009. Ideologicamente, è l'erede del cluster Parallel Sysplex, costruito su hardware 'normale'. Nel 2009 è stato lanciato il prodotto DB2 pureScale, che è un pacchetto software, mentre nel 2012 IBM ha offerto un pacchetto hardware-software (appliance) chiamato Pure Data Systems for Transactions. Non deve essere confuso con Pure Data Systems for Analytics, che non è altro che un Netezza rinominato.
L'architettura pureScale a prima vista assomiglia a Oracle RAC: analogamente, più nodi sono connessi a un sistema di storage dati comune, e ciascun nodo esegue una propria istanza di DBMS con le proprie aree di memoria e registri delle transazioni. Tuttavia, a differenza di Oracle, in DB2 esiste un servizio di locking dedicato, rappresentato da un insieme di processi db2LLM*. Nella configurazione cluster, questo servizio viene spostato su un nodo separato, che nel Parallel Sysplex è chiamato coupling facility (CF), mentre in Pure Data – PowerHA.
PowerHA offre i seguenti servizi:
- gestore dei locking;
- cache globale dei buffer;
- area per la comunicazione interprocesso.
Per il trasferimento dei dati da PowerHA ai nodi del DB e viceversa, viene utilizzato 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 questa non è nella cache, il nodo richiede la pagina nella cache globale, e solo se nemmeno lì è presente, la legge dal disco. A differenza di Oracle, la richiesta va solo a PowerHA, e non ai nodi vicini.
Se un'istanza sta per modificare una riga, blocca essa in modalità esclusiva e la pagina in cui si trova la riga in modalità condivisa. Tutti i blocchi vengono registrati nel gestore globale dei blocchi. Quando la transazione viene completata, il nodo invia un messaggio al gestore dei blocchi, che copia la pagina modificata nella cache globale, rimuove i blocchi e invalida la pagina modificata nelle cache degli altri nodi.
Se la pagina in cui si trova 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 passerà il blocco della pagina al nodo che lo ha richiesto.
Le pagine "sporche", ovvero quelle modificate, possono essere scritte su disco sia da un nodo normale che da PowerHA (castout).
In caso di guasto di uno dei nodi pureScale, il ripristino è limitato solo alle transazioni che durante il guasto non erano state ancora completate: le pagine modificate da questo nodo in transazioni completate si trovano nella cache globale di PowerHA. Il nodo viene riavviato in una configurazione ridotta su uno dei server del cluster, riporta le transazioni non completate e libera i blocchi.
PowerHA opera su due server, e il nodo principale replica sincronamente il proprio stato. In caso di guasto del nodo principale, il cluster PowerHA continua a funzionare con il nodo secondario.
Naturalmente, se si accede a un insieme di dati tramite un nodo, le prestazioni complessive del cluster saranno migliori. PureScale può anche notare che un certo insieme di dati viene elaborato da un nodo, e in tal caso tutti i blocchi relativi a quell'area verranno gestiti localmente dal nodo senza comunicazioni con PowerHA. Ma non appena l'applicazione proverà ad accedere a questi dati tramite un altro nodo, il processo centralizzato di gestione dei blocchi verrà ripreso.
I test interni di IBM su un carico composto dal 90% di lettura e 10% di scrittura, molto simile a 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 ha una 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 è stata assorbita da Hewlett-Packard nel 2002.
NonStop è utilizzato per costruire applicazioni critiche, come HLR o il processamento delle carte bancarie. La piattaforma è fornita come un insieme di hardware e software (appliance), che include nodi di calcolo, un sistema di archiviazione e attrezzature di comunicazione. La rete ServerNet (nelle moderne configurazioni – Infiniband) serve sia per lo scambio di dati tra i nodi, sia per l'accesso al sistema di archiviazione.
Nelle versioni precedenti del sistema venivano utilizzati processori proprietari, che erano sincronizzati tra loro: tutte le operazioni venivano eseguite in modo sincrono da più processori e, se uno di essi si bloccava, veniva disattivato mentre l'altro continuava a lavorare. In seguito, il sistema ha adottato processori standard (iniziando con MIPS, poi Itanium e, infine, x86), e sono stati utilizzati altri meccanismi per la sincronizzazione:
- messaggi: ogni processo di sistema ha un duplicato-«ombra», al quale il processo attivo invia periodicamente messaggi sul proprio stato; in caso di errore del processo principale, il processo ombra inizia la propria esecuzione dal punto definito dall'ultimo messaggio;
- voto: il sistema di archiviazione dei dati presenta un componente hardware speciale che accetta più richieste identiche e le esegue solo se le richieste coincidono; invece della sincronizzazione fisica, i processori operano in modo asincrono, e i risultati del loro lavoro vengono confrontati solo nei momenti di input/output.
A partire dal 1987, sulla piattaforma NonStop funziona un DBMS relazionale – inizialmente SQL/MP, e successivamente SQL/MX.
L'intera base di dati è suddivisa in parti, e ciascuna parte è gestita da un processo chiamato Data Access Manager (DAM). Questo assicura la registrazione dei dati, la memorizzazione nella cache e il meccanismo di blocco. L'elaborazione dei dati è effettuata dai processi esecutori (Executor Server Process), che operano sugli stessi nodi dei rispettivi manager dei dati. Il pianificatore SQL/MX suddivide i compiti tra gli esecutori e unisce i risultati. Se è necessario apportare modifiche concordate, viene utilizzato il protocollo di conferma a 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 interferiscano con l'esecuzione delle transazioni. Tuttavia, il suo scopo è specificamente l'elaborazione di transazioni brevi, non l'analisi. Lo sviluppatore garantisce la disponibilità del cluster NonStop a un livello di cinque «nove», il che significa che il downtime è di soli 5 minuti all'anno.
SAP HANA
Il primo rilascio stabile del database HANA (1.0) è avvenuto nel novembre 2010, mentre il pacchetto SAP ERP è passato a HANA nel maggio 2013. La piattaforma si basa su tecnologie acquisite: il motore di ricerca TREX (per la ricerca nel magazzino a colonne), il database P*TIME e MAX DB.
La parola stessa «HANA» è un acronimo, High performance ANalytical Appliance. Questo database viene 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 consentono persino l'operazione senza SAN: il cluster GPFS su dischi locali svolge il ruolo di storage condiviso.
A differenza delle piattaforme sopra menzionate, HANA è un database in memoria, cioè l'immagine primaria dei dati è memorizzata nella RAM, mentre solo i registri e le istantanee periodiche vengono scritti su disco – per il recupero in caso di guasto.
Ogni nodo del cluster HANA è responsabile della propria parte di dati, e la mappa dei dati è memorizzata in un componente speciale, il Name Server, situato nel nodo coordinatore. Le informazioni non vengono duplicate tra i nodi. Le informazioni sui blocchi sono anch'esse memorizzate su ogni nodo, ma il sistema dispone di un rilevatore globale di deadlock.
Il client HANA, collegandosi al cluster, carica la sua topologia e può successivamente accedere direttamente a qualsiasi nodo, a seconda dei dati di cui ha bisogno. Se una transazione coinvolge i dati di un singolo nodo, può essere eseguita localmente da quel nodo; ma se vengono modificati i dati di più nodi, il nodo che inizia la transazione si rivolge al nodo coordinatore, il quale apre e coordina la transazione distribuita, completandola tramite un protocollo di commit a due fasi ottimizzato.
Il nodo coordinatore è duplicato, quindi, in caso di malfunzionamento del coordinatore, un nodo di riserva entra immediatamente in funzione. Tuttavia, se si guasta un nodo contenente dati, l'unico modo per accedere ai suoi dati è riavviare il nodo. Di solito, nei cluster HANA si mantiene un server di riserva (spare), per poter riavviare il nodo perduto il più rapidamente possibile.
Fonte: habr.com
