MySQL Cluster Carrier Grade Edition

MySQL Cluster è la versione ad alta disponibilità del database MySQL e garantisce una disponibilità pari a “5-nines”. MySQL Cluster è stato progettato in collaborazione con uno dei maggiori fornitori mondiali di servizi per le telecomunicazioni, per poter soddisfare le esigenze delle società di telecomunicazioni e degli operatori di rete a livello di elevata disponibilità, throughput e tempi di risposta. Questa tipologia di database implementa un’architettura distribuita con elevata tolleranza d’errore, senza alcun single point of failure. In altre parole, MySQL Cluster offre affidabilità di livello mainframe su hardware di largo consumo, rappresentando così una soluzione economicamente molto vantaggiosa. In questo contesto, le organizzazioni possono

offrire la scalabilità, l’affidabilità e le prestazioni necessarie per eseguire applicazioni molto complesse.

4.3.1 Vantaggi

L’architettura fault-tolerant parallela di MySQL Cluster offre i seguenti benefici:

• Disponibilità 99.999%: garantita da un’architettura fault tolerant.

• Vantaggio economico: richiede meno hardware, costi di manutenzione inferiori e licenze più economiche rispetto ai database proprietari.

• Prestazioni elevate: offerte soltanto da un in-memory database.

• Scalabilità lineare: per scalare il sistema in modo incrementale, senza un costoso investimento hardware iniziale.

• Facilità di manutenzione: riduce la necessità di assumere ulteriori amministratori di database.

• Nessun Single Point of Failure: usa un’architettura distribuita e basata su nodi, con rapido failover.

• Backup a caldo: per eseguire il backup del sistema senza interruzioni.

• Rapido failover automatico: consente ai sistemi di effettuare automaticamente il failover in meno di un secondo.

4.3.2 Architettura

Per ottenere la tolleranza d’errore, sono necessari diversi componenti per eseguire l’applicazione, accedere al database e gestire l’ambiente distribuito. Questi componenti sono tipicamente distribuiti tra le macchine e condividono continuamente gli uni con gli altri le ultime modifiche apportate al database. Se vengono a mancare un nodo o una

un’applicazione possa continuare ad essere eseguita senza interruzioni. Il sistema deve anche assicurare che le transazioni vengano eseguite con successo e che le informazioni del database rimangano corrette attraverso l’intero processo di recupero.

Questo sistema distribuito e flessibile per la gestione del database consiste in tre tipi di nodi che replicano i dati, accedono al DB e gestiscono il sistema.

• Database Node sono i principali nodi del sistema. Tutti i dati vengono replicati e conservati sul Database Node, il quale gestisce tutte le transazioni di database. Se viene a mancare un Database Node, è sempre presente un altro nodo contenente le stesse informazioni.

• Application Node sono le applicazioni che si collegano al database. Se viene a mancare un Database Node, c’è sempre un altro nodo contenente le stesse informazioni per consentire all’Application Node di continuare la propria esecuzione.

• Management Server Node gestiscono la configurazione del sistema. I Management Server Node vengono usati soltanto all’avvio e per la riconfigurazione del sistema; inoltre, possono essere interrotti e riavviati senza influire in alcun modo sull’esecuzione del database in corso e sugli Application Node.

Questo tipo di architettura garantisce che non vi sia alcun single point of failure: le applicazioni continuano ad essere eseguite e i dati mantengono la propria integrità, persino se dovesse venire a mancare uno dei Database Node, Application Node o Management Server Node. Inoltre, i nodi e i computer possono essere distribuiti su più locazioni geografiche: ciò è importante per recuperare un database o un intero cluster in caso di disastro fisico in una particolare locazione.

Oltre a ciò, MySQL Cluster offre un’architettura flessibile distribuita, con un alto grado di configurabilità. Per esempio, le organizzazioni possono scegliere quanti Database Node utilizzare e come distribuirli tra i computer e tra le locazioni geografiche. Ciò offre loro il controllo necessario ad implementare il livello di prestazioni, affidabilità, scalabilità e tolleranza d’errore adeguato per le loro particolari esigenze.

4.3.3 Costi di fermo

Un recente studio condotto da IDC ha rivelato come i tempi di fermo siano il principale fattore del costo totale di gestione dei database. Per eliminare questi tempi di inattività, i sistemi di gestione dei database devono offrire un’architettura fault-tolerant distribuita, che replichi i dati su altre macchine o tra le regioni, affinché possano continuare la propria esecuzione senza interruzioni in caso di problemi a livello di hardware, rete o applicazioni.

Un’architettura server parallela consente a MySQL Cluster di raggiungere una disponibilità del 99.999%. Ciò si traduce in tempi di fermo inferiori a 5 minuti l’anno, incluse le regolari operazioni di manutenzione. Nell’ambito di questa architettura, ogni nodo possiede la propria memoria e i propri supporti di disco, e il database è distribuito tra più macchine all’interno del cluster. I dati sono replicati in modo sincronizzato tra i nodi, senza dover ricorrere ad un disco condiviso esterno. Se vengono a mancare uno o più Database Node, l’applicazione può eseguire il failover su un altro nodo, al fine di completare la transazione con successo. Se dovessero venire a mancare tutti i nodi, per esempio per difetti a livello di hardware, MySQL Cluster garantisce il sicuro recupero

inserimenti, cancellazioni, aggiornamenti. Per creare un’istantanea sul disco delle transazioni di tutti i dati dei nodi, viene utilizzato un protocollo basato sul local checkpoint.

Inoltre, in caso di disastro (incendio, terremoto, alluvione), MySQL Cluster consente di replicare interi cluster su più zone geografiche e su altri siti, per garantire la disponibilità del sistema. Per riprendersi dai guasti di sistema, MySQL Cluster utilizza un protocollo di checkpoint che conferma tutte le transazioni su disco, garantendone il successo.

4.3.4 Alte prestazioni

Oltre all’alta disponibilità, anche le alte prestazioni sono un requisito di importanza critica per poter gestire volumi elevati di richieste e transazioni del database, particolarmente nei settori dei servizi finanziari e delle telecomunicazioni. Le esigenze delle società, in termini di prestazioni devono tipicamente essere raggiunte, mantenendo allo stesso tempo l’alta disponibilità.

MySQL Cluster è un database in memoria centrale, progettato per soddisfare questi requisiti di prestazioni e implementato utilizzando un’architettura di tipo Shared Nothing, ovvero dove le risorse non sono condivise tra i nodi. Tale soluzione è utile affinché ogni Database Node utilizzi i propri dischi e la propria memoria, anziché necessitare di dischi condivisi, che aumentano i costi e che possono limitare le prestazioni. Questo DBMS mantiene tutti i dati in memoria centrale per le transazioni e il failover rapido, e limita i rallentamenti di Input/Output scrivendo i log delle transazioni su disco in modo asincrono. I tipici tempi di risposta di MySQL Cluster si aggirano, quindi, su pochi millisecondi. Inoltre, questa architettura consente di gestire per ogni secondo decine di migliaia di transazioni distribuite, che vengono anche replicate sui Database Node.

4.3.5 Failover automatico

MySQL Cluster rileva gli errori e garantisce tempi di failover estremamente rapidi, con risposte inferiori al secondo per garantire che le applicazioni rimangano altamente disponibili in caso di guasto. Ciò riveste un’importanza critica nei sistemi bancari e di prenotazioni aeree, che dipendono fortemente dal fattore tempo. MySQL Cluster utilizza la replicazione sincrona per propagare le informazioni di una transazione a tutti i Database Node interessati, affinché le applicazioni possano eseguire il failover automatico su di un altro nodo, in modo estremamente rapido. Quando vengono rilevate delle interruzioni nell’accesso ai nodi, questi vengono automaticamente riavviati, utilizzando un protocollo di recupero, che fornisce ai nodi oggetto del riavvio tutti i dati necessari provenienti dai nodi al momento attivi.

I sistemi di database clusterizzati offrono tipicamente capacità di failover attraverso un’architettura di disco condivisa. Per poter recuperare un nodo guasto, quest’ultimo deve ricreare il database leggendo e riproducendo i file di log. Si tratta di un processo relativamente lento, che tipicamente impiega diversi secondi. Inoltre, le architetture a dischi condivisi hanno un costo proibitivo ed aggiungono un single point of failure all’intero sistema. Il vantaggio della replicazione sincrona è che elimina la complessa operazione di ricreare e riprodurre i file di log, operazione che consente alle applicazioni di eseguire il failover con successo. Inoltre, i Database Node sono in grado di riavviarsi, ripristinarsi e riconfigurarsi dinamicamente in modo automatico e in meno di un secondo, senza dover scrivere la logica di ripristino all’interno dell’applicazione.

4.3.6 Scalabilità incrementale e backup “a caldo”

La capacità di scalare in modalità semi-lineare è necessaria per far crescere il sistema in modo economicamente vantaggioso. Ciò offre alle organizzazioni la flessibilità di partire in piccolo e fare investimenti incrementali, aumentando la capacità via via che aumentano le loro esigenze. Inoltre, questo elimina la necessità di un ingente investimento iniziale per hardware e software, nell’ambito di quella che tende ad essere una configurazione eccessiva.

MySQL Cluster consente di effettuare backup online e, quando è necessario, ripristinarlo senza dover interrompere il sistema, risparmiando così tempo e risorse. Nel caso di applicazioni commerciali, come e-commerce o customer service, ciò significa che è possibile fornire un livello di servizio più elevato ed impedire che il business venga interrotto a causa di guasti catastrofici.

4.3.7 Riduzione complessiva dei costi

MySQL Cluster non solo riduce i costi iniziali per le licenze, grazie ad un economico meccanismo di licenze commerciali, ma riduce anche in modo significativo i tempi di fermo del sistema. Inoltre, un ambiente altamente portabile e basato su standard consente di distribuire le applicazioni in modo economicamente vantaggioso su hardware innovativo a basso costo, e sulle infrastrutture del sistema operativo, inclusi Linux e Windows.

Grazie alla possibilità di utilizzare in modo efficiente hardware di largo consumo a basso costo, MySQL Cluster necessita di investimenti significativamente più ridotti rispetto alle soluzioni di clustering di tipo proprietario. Inoltre, implementando un’architettura server parallela, la potenza di elaborazione viene distribuita e condivisa da tutti i nodi all’interno di un cluster. Non è necessario avere alcun hardware in standby, quindi si può sfruttare a pieno tutta la potenza. Oltre a ciò, l’architettura shared nothing di MySQL Cluster elimina il costo di una SAN (Storage Area Network), un insieme di dispositivi di memorizzazione dati che richiede hardware centralizzato e introduce un single-point-of-failure.

MySQL Cluster è progettato per essere in gran parte autonomo, quindi sono pochi i parametri di sistema che necessitano di messa a punto, il che riduce ulteriormente il rischio di errori costosi. Il risultato è che vi sono tipicamente meno conflitti con gli altri prodotti software e hardware e una minore necessità di interventi manuali. Ciò significa, inoltre, che il DBMS in esame avrà costi di manutenzione molto più bassi, dato che sono necessari meno amministratori di database.

4.3.8 Facile amministrazione

Una semplice interfaccia a linea di comando consente di monitorare e mantenere il database con facilità. È facile configurare il server localmente o remotamente, utilizzando i Management Client che si collegano ai Management Server Node. Inoltre, un’apposita API permette di scrivere programmi che eseguono il monitoraggio e la manutenzione del database in modo automatico.