Il teorema CAP è la pietra angolare della teoria dei sistemi distribuiti. Naturalmente, la controversia che lo circonda non si placa: le definizioni in esso contenute non sono canoniche e non esiste una prova rigorosa... Tuttavia, rimanendo fermamente sulle posizioni del buon senso quotidiano™, comprendiamo intuitivamente che il teorema è vero.
L'unica cosa che non è ovvia è il significato della lettera "P". Quando il cluster viene diviso, decide se non rispondere fino al raggiungimento del quorum o restituire 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 dipendendo nemmeno dalle impostazioni del cluster, ma dai parametri di ogni specifica richiesta. Ma se il sistema non è “P” e si divide, allora?
La risposta a questa domanda è alquanto inaspettata: un cluster CA non può dividersi.
Che tipo di cluster è questo che non può dividersi?
Un attributo indispensabile di un tale cluster è un sistema di archiviazione dati condiviso. Nella stragrande maggioranza dei casi, ciò significa connettersi tramite una SAN, il che limita l'uso delle soluzioni CA alle grandi imprese in grado di mantenere un'infrastruttura SAN. Affinché più server possano lavorare con gli stessi dati, è necessario un file system in cluster. Tali file system sono disponibili nei portafogli HPE (CFS), Veritas (VxCFS) e IBM (GPFS).
OracleRAC
L'opzione Real Application Cluster è apparsa per la prima volta nel 2001 con il rilascio di Oracle 9i. In un cluster di questo tipo, diverse istanze del server funzionano con lo stesso database.
Oracle può funzionare sia con un file system in cluster che con la propria soluzione: ASM, Automatic Storage Management.
Ogni copia conserva il proprio diario. La transazione viene eseguita e confermata da un'istanza. Se un'istanza fallisce, uno dei nodi del cluster sopravvissuti (istanze) legge il suo registro e ripristina i dati persi, garantendo così la disponibilità.
Tutte le istanze mantengono la propria cache e le stesse pagine (blocchi) possono trovarsi nella cache di più istanze contemporaneamente. Inoltre, se un'istanza necessita di una pagina ed è nella cache di un'altra istanza, può ottenerla dalla vicina utilizzando il meccanismo di fusione della cache invece di leggerla dal disco.
Ma cosa succede se una delle istanze deve modificare i dati?
La particolarità di Oracle è che non dispone di un servizio di lock dedicato: se il server vuole lockare una riga, allora il record di lock viene posizionato 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 blocco non diventa mai un collo di bottiglia. Ma in una configurazione cluster, un'architettura di questo tipo può portare a un intenso traffico di rete e a blocchi.
Una volta bloccato un record, un'istanza notifica a tutte le altre istanze che la pagina che archivia quel record ha una conservazione esclusiva. Se un'altra istanza deve modificare un record sulla stessa pagina, deve attendere finché le modifiche alla pagina non vengono confermate, ovvero le informazioni sulla modifica vengono scritte su un journal su disco (e la transazione può continuare). Può anche succedere che una pagina venga modificata in sequenza da più copie, e quindi durante la scrittura della pagina su disco dovrai scoprire chi memorizza la versione corrente di questa pagina.
L'aggiornamento casuale delle stesse pagine su diversi nodi RAC provoca un drastico calo delle prestazioni del database, al punto che le prestazioni del cluster possono essere inferiori a quelle di una singola istanza.
L'uso corretto di Oracle RAC consiste nel partizionare fisicamente i dati (ad esempio, utilizzando un meccanismo di tabella partizionata) e accedere a ciascun set di partizioni tramite un nodo dedicato. Lo scopo principale del RAC non era il ridimensionamento orizzontale, ma garantire la tolleranza agli errori.
Se un nodo smette di rispondere a un heartbeat, il nodo che lo ha rilevato avvia per primo una procedura di votazione sul disco. Se il nodo mancante non viene annotato qui, uno dei nodi si assume la responsabilità del recupero dei dati:
- “congela” tutte le pagine che erano nella cache del nodo mancante;
- legge i log (redo) del nodo mancante e riapplica le modifiche registrate in questi log, controllando contemporaneamente se altri nodi hanno versioni più recenti delle pagine che si stanno modificando;
- ripristina le transazioni in sospeso.
Per semplificare il passaggio tra i nodi, Oracle ha il concetto di servizio: un'istanza virtuale. Un'istanza può servire più servizi e un servizio può spostarsi tra i nodi. Un'istanza dell'applicazione che serve una determinata parte del database (ad esempio, un gruppo di client) funziona con un servizio e il servizio responsabile di questa parte del database si sposta su un altro nodo quando un nodo fallisce.
IBM Pure Data Systems per le transazioni
Una soluzione cluster per DBMS è apparsa nel portafoglio Blue Giant nel 2009. Ideologicamente, è il successore del cluster Parallel Sysplex, costruito su apparecchiature “normali”. Nel 2009 è stata rilasciata DB2 pureScale, una suite software, e nel 2012 IBM ha offerto un'appliance chiamata Pure Data Systems for Transactions. Non deve essere confuso con Pure Data Systems for Analytics, che non è altro che un Netezza rinominato.
A prima vista, l'architettura pureScale è simile a Oracle RAC: allo stesso modo, diversi nodi sono collegati a un sistema di archiviazione dati comune e ogni nodo esegue la propria istanza DBMS con le proprie aree di memoria e registri delle transazioni. Ma, a differenza di Oracle, DB2 dispone di un servizio di blocco dedicato rappresentato da una serie di processi db2LLM*. In una configurazione cluster, questo servizio viene posizionato su un nodo separato, denominato CF (coupling facility) in Parallel Sysplex e PowerHA in Pure Data.
PowerHA fornisce i seguenti servizi:
- gestore delle serrature;
- cache del buffer globale;
- area delle comunicazioni tra processi.
Per trasferire i dati da PowerHA ai nodi del database e viceversa, viene utilizzato l'accesso alla memoria remota, quindi l'interconnessione del cluster deve supportare il protocollo RDMA. PureScale può utilizzare sia Infiniband che RDMA su Ethernet.
Se un nodo necessita di una pagina e questa pagina non è nella cache, allora il nodo richiede la pagina nella cache globale e, solo se non è presente, la legge dal disco. A differenza di Oracle, la richiesta arriva solo a PowerHA e non ai nodi vicini.
Se un'istanza sta per modificare una riga, la blocca in modalità esclusiva e la pagina in cui si trova la riga in modalità condivisa. Tutte le serrature sono registrate nel gestore serrature globale. Una volta completata la transazione, il nodo invia un messaggio al gestore dei lock, che copia la pagina modificata nella cache globale, rilascia i lock e invalida la pagina modificata nelle cache degli altri nodi.
Se la pagina in cui si trova la riga modificata è già bloccata, il gestore dei lock leggerà la pagina modificata dalla memoria del nodo che ha apportato la modifica, rilascerà il lock, invaliderà la pagina modificata nelle cache degli altri nodi e dare il blocco della pagina al nodo che lo ha richiesto.
Le pagine "sporche", cioè modificate, possono essere scritte su disco sia da un nodo normale che da PowerHA (castout).
Se uno dei nodi pureScale fallisce, il ripristino è limitato alle sole transazioni che non erano ancora state completate al momento del fallimento: le pagine modificate da quel nodo nelle transazioni completate si trovano nella cache globale su PowerHA. Il nodo si riavvia in una configurazione ridotta su uno dei server del cluster, ripristina le transazioni in sospeso e rilascia i blocchi.
PowerHA viene eseguito su due server e il nodo master replica il proprio stato in modo sincrono. Se il nodo PowerHA primario fallisce, il cluster continua a funzionare con il nodo di backup.
Naturalmente, se si accede al set di dati tramite un singolo nodo, le prestazioni complessive del cluster saranno più elevate. PureScale può anche notare che una determinata area di dati viene elaborata da un nodo, quindi tutti i blocchi relativi a quell'area verranno elaborati localmente dal nodo senza comunicare con PowerHA. Ma non appena l'applicazione tenta di accedere a questi dati tramite un altro nodo, l'elaborazione centralizzata del blocco riprenderà.
I test interni di IBM su un carico di lavoro del 90% in lettura e del 10% in scrittura, che è molto simile ai carichi di lavoro di produzione del mondo reale, mostrano un ridimensionamento quasi lineare fino a 128 nodi. Le condizioni del test, sfortunatamente, non vengono divulgate.
SQL continuo HPE
Il portafoglio Hewlett-Packard Enterprise dispone inoltre di una propria piattaforma ad alta disponibilità. Questa è la piattaforma NonStop, lanciata sul mercato nel 1976 da Tandem Computers. Nel 1997 l'azienda è stata acquisita da Compaq, che a sua volta si è fusa con Hewlett-Packard nel 2002.
NonStop viene utilizzato per creare applicazioni critiche, ad esempio HLR o elaborazione di carte bancarie. La piattaforma viene fornita sotto forma di un complesso software e hardware (apparecchio), che comprende nodi di elaborazione, un sistema di archiviazione dati e apparecchiature di comunicazione. La rete ServerNet (nei sistemi moderni - Infiniband) serve sia per lo scambio tra nodi che per l'accesso al sistema di archiviazione dei dati.
Le prime versioni del sistema utilizzavano processori proprietari sincronizzati tra loro: tutte le operazioni venivano eseguite in modo sincrono da più processori e non appena uno dei processori commetteva un errore, veniva spento e il secondo continuava a funzionare. Successivamente il sistema passò ai processori convenzionali (prima MIPS, poi Itanium e infine x86) e iniziarono ad essere utilizzati altri meccanismi per la sincronizzazione:
- messaggi: ogni processo di sistema ha un gemello “ombra”, al quale il processo attivo invia periodicamente messaggi sul suo stato; se il processo principale fallisce, il processo ombra inizia a funzionare dal momento determinato dall'ultimo messaggio;
- votazione: il sistema di storage dispone di un'apposita componente hardware che accetta più accessi identici e li esegue solo se gli accessi coincidono; Invece della sincronizzazione fisica, i processori operano in modo asincrono e i risultati del loro lavoro vengono confrontati solo nei momenti di I/O.
Dal 1987, un DBMS relazionale è in esecuzione sulla piattaforma NonStop: prima SQL/MP e successivamente SQL/MX.
L'intero database è diviso in parti e ciascuna parte è responsabile del proprio processo DAM (Data Access Manager). Fornisce meccanismi di registrazione, memorizzazione nella cache e blocco dei dati. L'elaborazione dei dati viene eseguita dai processi server esecutori in esecuzione sugli stessi nodi dei corrispondenti gestori dati. Lo scheduler SQL/MX divide le attività tra gli esecutori e aggrega i risultati. Quando è necessario apportare modifiche concordate viene utilizzato il protocollo di commit a due fasi fornito dalla libreria TMF (Transaction Management Facility).
NonStop SQL può dare priorità ai processi in modo che le lunghe query analitiche non interferiscano con l'esecuzione delle transazioni. Tuttavia, il suo scopo è proprio l’elaborazione di transazioni brevi e non l’analisi. Lo sviluppatore garantisce la disponibilità del cluster NonStop al livello di cinque "nove", ovvero il tempo di inattività è di soli 5 minuti all'anno.
SAP-HANA
Nel novembre 1.0 è avvenuta la prima release stabile del DBMS HANA (2010), nel maggio 2013 il pacchetto SAP ERP è passato ad HANA. La piattaforma si basa su tecnologie acquistate: TREX Search Engine (ricerca in storage colonnare), P*TIME DBMS e MAX DB.
La parola stessa “HANA” è un acronimo, High performance ANalytical Appliance. Questo DBMS viene fornito sotto forma di codice eseguibile su qualsiasi server x86, tuttavia le installazioni industriali sono consentite solo su apparecchiature certificate. Soluzioni disponibili da HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Alcune configurazioni Lenovo consentono anche il funzionamento senza SAN: il ruolo di un sistema di archiviazione comune è svolto da un cluster GPFS sui dischi locali.
A differenza delle piattaforme sopra elencate, HANA è un DBMS in-memory, ovvero l'immagine primaria dei dati viene archiviata nella RAM e solo i log e gli snapshot periodici vengono scritti su disco per il ripristino in caso di disastro.
Ogni nodo del cluster HANA è responsabile della propria parte di dati e la mappa dei dati è archiviata in un componente speciale – Name Server, situato sul nodo coordinatore. I dati non vengono duplicati tra i nodi. Anche le informazioni sul blocco vengono archiviate su ciascun nodo, ma il sistema dispone di un rilevatore globale di deadlock.
Quando un client HANA si connette a un cluster, ne scarica la topologia e può quindi accedere direttamente a qualsiasi nodo, a seconda dei dati di cui ha bisogno. Se una transazione interessa i dati di un singolo nodo, allora può essere eseguita localmente da quel nodo, ma se cambiano i dati di più nodi, il nodo iniziante contatta il nodo coordinatore, che apre e coordina la transazione distribuita, impegnandola utilizzando un protocollo di commit a due fasi ottimizzato.
Il nodo coordinatore è duplicato, quindi se il coordinatore fallisce, subentra immediatamente il nodo di backup. Ma se un nodo con dati fallisce, l'unico modo per accedere ai suoi dati è riavviare il nodo. Di norma i cluster HANA mantengono un server di riserva per riavviare su di esso un nodo perduto il più rapidamente possibile.
Fonte: habr.com