Prima di sviluppare l'applicazione, è buona norma elaborare un piano. Iniziate definendo gli obiettivi aziendali principali, raccogliendo i requisiti, valutando un potenziale stack tecnologico e comprendendo le integrazioni. Alla fine del processo, dovreste avere una bozza dell'architettura di riferimento della vostra applicazione, che funge da schema per l'implementazione dei componenti dell'infrastruttura e definisce il flusso dei dati tra questi componenti.
In questo esempio, esaminiamo la progettazione di un database utilizzando Galera per MySQL e MariaDB. I database sono componenti mission critical di molte applicazioni. Questa preziosa risorsa si basa sulla ridondanza per mantenere in vita il carico di lavoro. Un singolo punto di guasto può avere un impatto negativo sulle operazioni aziendali, sugli accordi di uptime e sull'esperienza complessiva degli utenti.
Utilizzando le architetture di riferimento come guida, è possibile creare implementazioni di database e applicazioni resilienti che scalano orizzontalmente (senza tempi di inattività) in base alla crescita dell'azienda.
Che cos'è l'architettura di riferimento?
Le architetture di riferimento sono diagrammi tecnici riutilizzabili che incorporano principi di progettazione comuni e best practice del settore per l'implementazione di soluzioni. Un'architettura di riferimento del cloud altamente astratta descrive le connessioni tra le varie istanze di calcolo, i bilanciatori di carico, lo storage, le reti definite dal software e così via - il valore dei vostri database ne fa un'area chiave di attenzione.
Basi di dati e architetture di riferimento
L'obiettivo principale è aggiungere ridondanza e impedire che il database sia un singolo punto di guasto. Esistono diversi modi per raggiungere questo obiettivo, a seconda dei vincoli dell'applicazione e del carico di lavoro. Ad esempio, un'applicazione potrebbe ottenere prestazioni migliori dividendo le letture e le scritture in un modello di replica primario-secondario. Una necessità di scalare le operazioni di scrittura richiederebbe una strategia con più primari.
Altre considerazioni riguardano il volume dei dati, la conformità ACID, il processo di failover/elezione (manuale o automatico), il numero previsto di connessioni client e la tecnologia di database scelta. Queste considerazioni daranno forma alla soluzione di database e formeranno il quadro generale di come questi pezzi lavorano insieme nella vostra architettura di riferimento.
Quando utilizzare Galera
Galera è una soluzione di database ad alta disponibilità gratuita e open source, semplice da gestire e che non dipende da un singolo provider cloud. Se la vostra tecnologia di database è MySQL, o uno dei suoi fork come MariaDB o Percona, vi consigliamo vivamente Galera come soluzione durevole e portatile.
Vantaggi del cluster Galera
- Guasti dei nodi - Previene le condizioni di split-brain invocando un quorum ponderato per eleggere un componente primario in caso di guasti dei nodi.
- Cluster Multi-Primario, Attivo-Attivo - Lettura e scrittura su qualsiasi nodo del cluster.
- Consistenza dei dati - Utilizza una replica sincrona basata sulla certificazione per garantire la conformità ACID.
- Provisioning automatico dei nodi - Quando i nodi guasti si ripristinano o quando nuovi nodi si uniscono al cluster, vengono automaticamente sincronizzati con lo stato del componente primario utilizzando trasferimenti di istantanee di stato (SST) o trasferimenti incrementali di stato (IST).
Limitazioni del cluster Galera
- Nessun supporto per MyISAM: supporta solo il motore InnoDB. Le scritture su altri tipi di tabelle, comprese quelle di sistema, non vengono replicate.
- Formattazione delle tabelle: le tabelle senza chiavi primarie non possono essere eliminate o replicate correttamente.
- Considerazioni sulla logica: potrebbe essere necessario riscrivere la logica dell'applicazione per evitare l'uso del blocco esplicito delle tabelle.
- Scalabilità della scrittura: tutti i nodi devono certificare di essere in grado di scrivere prima di impegnarsi, pertanto le prestazioni di scrittura diminuiscono con la crescita del cluster. Si consiglia di mantenere le dimensioni del cluster a tre nodi, sufficienti per avere un quorum e prestazioni di scrittura ottimali.
Eliminare i singoli punti di guasto
Utilizziamo l'esempio di uno stack LEMP tradizionale, in cui il software applicativo e il database sono stati separati in diverse istanze di calcolo in vista di una futura scalabilità. La configurazione potrebbe essere la seguente:
La separazione delle preoccupazioni è una buona pratica e certamente aiuta a supportare la scalabilità; ma la mancanza di ridondanza rende sia il database che i server applicativi un singolo punto di fallimento. Possiamo migliorare questa struttura per eliminare i singoli punti di guasto e costruire l'architettura di riferimento complessiva.
Semplice configurazione del cluster Galera con VLAN e firewall cloud
Un cluster Galera aumenta il livello di database a tre nodi con replica sincrona tra di essi. Possiamo usare un Linode VLAN per isolare il traffico di replica dalle reti pubbliche e private condivise, e un Cloud Firewall per limitare l'accesso dall'esterno di VLAN. I nodi Galera condividono un indirizzo IP fluttuante, in modo che se uno si guasta, un altro è in grado di subentrare nel servire le richieste al server applicativo sconosciuto.
Il livello di database è ora altamente disponibile. La prossima cosa su cui concentrarsi è la gestione del server delle applicazioni. Questo processo è semplice per applicazioni stateless ma è necessario tenere conto di ulteriori considerazioni per le applicazioni che sono statiche. A seconda di come viene mantenuto lo stato, potrebbe essere necessario rifattorizzare il codice e/o implementare la replica dei file con strumenti come Unison o Gluster. Per questo esempio, si supponga che, ad eccezione dei file temporanei di sessione, lo stato dell'applicazione sia mantenuto dal database.
Bilanciamento del carico e replica delle applicazioni
Il bilanciamento del carico offre all'applicazione un'elevata disponibilità e scalabilità orizzontale, ma una singola istanza del bilanciatore di carico crea anche un singolo punto di guasto. La ridondanza rimane un componente critico di questa implementazione. Linode NodeBalancers fornisce una soluzione ad alta disponibilità, pronta all'uso, per facilitare l'aderenza delle sessioni, il monitoraggio dello stato di salute e la distribuzione delle richieste dei clienti a una serie di nodi applicativi di backend.
Se un server applicativo si guasta, il NodeBalancer inizierà a dirigere il traffico solo verso il nodo sano. Non appena il nodo non sano si riprende, riprende il bilanciamento delle connessioni come prima. In questo modo è facile aggiungere, rimuovere o aggiornare i server applicativi senza tempi di inattività e, grazie alla soluzione attiva-attiva fornita da Galera, qualsiasi nodo applicativo può leggere/scrivere su qualsiasi nodo di database.
Il team Solutions Engineering di Linode condivide framework, guide e strumenti come questo per sviluppare applicazioni tenendo conto delle migliori pratiche. Per saperne di più sui vantaggi dell'alta disponibilità forniti dai cluster Galera. Se siete pronti a iniziare a costruire su Linode, date un'occhiata alla nostra guida alla creazione di cluster MariaDB con Galeria, Debian e Ubuntu.
Commenti