Drupal è un Content Management System (CMS) progettato per creare qualsiasi cosa, dai piccoli ai grandi siti web aziendali. Oltre 1.000.000 di siti Web vengono eseguiti su Drupal e viene utilizzato per creare molti dei siti Web e delle applicazioni che usi ogni giorno (incluso questo). Drupal ha un ottimo set di funzionalità standard come la creazione di contenuti semplice, prestazioni affidabili e sicurezza eccellente. Ciò che distingue Drupal è la sua flessibilità poiché la modularità è uno dei suoi principi fondamentali.
Drupal è anche un'ottima scelta per la creazione di framework digitali integrati. Puoi estenderlo con le migliaia di componenti aggiuntivi disponibili. Questi moduli espandono le funzionalità di Drupal. I temi ti consentono di personalizzare la presentazione e le distribuzioni dei tuoi contenuti (i bundle Drupal) sono bundle che puoi utilizzare come kit di base. Puoi utilizzare tutte queste funzionalità per combinare e abbinare per migliorare le abilità principali di Drupal o per integrare Drupal con servizi esterni. È un software di gestione dei contenuti potente e scalabile.
Drupal utilizza i database per archiviare i propri contenuti web. Quando il tuo sito Web o applicazione basato su Drupal sta subendo una grande quantità di traffico, può avere un impatto sul tuo server di database. Quando ti trovi in questa situazione, avrai bisogno di bilanciamento del carico, disponibilità elevata e un'architettura ridondante per mantenere il tuo database online.
Quando ho iniziato a fare ricerche su questo blog, mi sono reso conto che ci sono molte risposte a questo problema online, ma le soluzioni consigliate erano molto datate. Ciò potrebbe essere il risultato dell'aumento della quota di mercato di WordPress che si traduce in una comunità open source più piccola. Quello che ho trovato sono alcuni esempi sull'implementazione dell'alta disponibilità utilizzando Master/Master (alta disponibilità) o Master/Master/Slave (alta disponibilità/Alte prestazioni).
Drupal offre supporto per un'ampia gamma di database, ma inizialmente è stato progettato utilizzando varianti MySQL. Sebbene l'utilizzo di MySQL sia completamente supportato, ci sono approcci migliori che puoi implementare. L'implementazione di questi altri approcci, tuttavia, se non eseguita correttamente, può causare notevoli tempi di inattività del sito Web, problemi di prestazioni dell'applicazione e problemi di scrittura per gli slave. Anche l'esecuzione della manutenzione sarebbe difficile poiché è necessario il failover per applicare gli aggiornamenti o le patch del server (hardware o software) senza tempi di inattività. Ciò è particolarmente vero se si dispone di una grande quantità di dati, che causa un potenziale impatto importante sulla propria attività.
Queste sono situazioni che non vuoi che si verifichino, motivo per cui in questo blog discuteremo di come implementare il failover del database per i tuoi database MySQL o PostgreSQL.
Perché il tuo sito web Drupal ha bisogno del failover del database?
Da Wikipedia "il failover sta passando a un server, sistema, componente hardware o rete ridondante o in standby in caso di guasto o chiusura anomala dell'applicazione, del server, del sistema, del componente hardware o della rete precedentemente attivi. Il failover e il passaggio sono essenzialmente la stessa operazione, tranne per il fatto che il failover è automatico e di solito funziona senza preavviso, mentre il passaggio richiede l'intervento umano".
Nelle operazioni di database, switchover è anche un termine utilizzato per il failover manuale, il che significa che richiede una persona per operare il failover. Il failover è utile per qualsiasi amministratore in quanto isola problemi indesiderati come eliminazioni/eliminazioni accidentali di tabelle, lunghe ore di inattività che causano un impatto sul business, danneggiamento del database o danneggiamento a livello di sistema.
Il failover del database consiste in più di un singolo nodo del database, fisicamente o virtualmente. Idealmente, poiché il failover richiede il passaggio a un nodo diverso, potresti anche passare a un server di database diverso, se un host esegue più istanze di database su un singolo host. Può ancora essere un passaggio o un failover, ma in genere si tratta più di ridondanza e disponibilità elevata nel caso in cui si verifichi una catastrofe sull'host corrente.
Failover MySQL per Drupal
L'esecuzione di un failover per l'applicazione basata su Drupal richiede che i dati gestiti dal database non si distinguano né si separino. Ci sono diverse soluzioni disponibili e ne abbiamo già discusse alcune nei precedenti blog di Diversinines. Probabilmente vorrai leggere la nostra Introduzione al Failover per la replica di MySQL:il blog 101.
Il passaggio tra padrone e schiavo
L'approccio più comune per il failover di MySQL è l'utilizzo dello switch over master-slave o del failover manuale. Ci sono due approcci che puoi fare qui:
- Puoi implementare il tuo database con una tipica replica asincrona master-slave.
- oppure può essere implementato con la replica asincrona master-slave utilizzando la replica basata su GTID.
Il passaggio a un altro master potrebbe essere più rapido e semplice. Questo può essere fatto con la seguente sintassi MySQL:
mysql> SET GLOBAL read_only = 1; /* enable read-only */
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
mysql> START SLAVE; /* start replication */
mysql> SHOW SLAVE STATUS\G /* check replication status */o con GTID, puoi semplicemente farlo,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitL'utilizzo dell'approccio non GTID richiede di determinare prima il file di registro del master e la pos del registro del master. È possibile determinarlo osservando lo stato del master nel nodo master prima della commutazione.
mysql> MASTER STATUS;Potresti anche considerare di rafforzare il tuo server aggiungendo sync_binlog =1 e innodb_flush_log_at_trx_commit =1 poiché, nel caso in cui il tuo master si arresti in modo anomalo, avrai maggiori possibilità che le transazioni dal master non siano sincronizzate con il tuo slave( S). In tal caso, il master promosso ha maggiori possibilità di essere un nodo di origine dati coerente.
Questo, tuttavia, potrebbe non essere l'approccio migliore per il tuo database Drupal in quanto potrebbe imporre lunghi tempi di inattività se non eseguito correttamente, ad esempio essere interrotto bruscamente. Se il tuo nodo del database master riscontra un bug che provoca l'arresto anomalo di un database, avrai bisogno che la tua applicazione punti a un altro database in attesa in standby come nuovo master o che il tuo slave venga promosso a master. Dovrai specificare esattamente quale nodo dovrebbe prendere il controllo e quindi determinare il ritardo e la coerenza di quel nodo. Raggiungere questo non è facile come semplicemente fare SET GLOBAL read_only=1; CAMBIA MASTER IN... (ecc.), ci sono alcune situazioni che richiedono un'analisi più approfondita, esaminando le transazioni valide necessarie per essere presenti in quel server standby o master promosso, per portarlo a termine.
Failover Drupal con MHA
Uno degli strumenti più comuni per il failover automatico e manuale è MHA. È in circolazione da molto tempo ed è ancora utilizzato da molte organizzazioni. Puoi dare un'occhiata a questi blog precedenti che abbiamo sull'argomento, Principali problemi comuni con MHA e come risolverli o Strumenti MySQL ad alta disponibilità:confronto tra MHA, MRM e ClusterControl.
Failover di Drupal utilizzando Orchestrator
Orchestrator è stato ampiamente adottato ora ed è utilizzato da grandi organizzazioni come Github e Booking.com. Non solo consente di gestire un failover, ma anche la gestione della topologia, l'individuazione degli host, il refactoring e il ripristino. C'è un bel blog esterno qui che ho trovato molto utile per conoscere il suo meccanismo di failover con Orchestrator. È una serie di blog in due parti; parte prima e parte seconda.
Failover Drupal utilizzando MaxScale
MaxScale non è solo un sistema di bilanciamento del carico progettato per il server MariaDB, ma estende anche l'elevata disponibilità, scalabilità e sicurezza per MariaDB semplificando allo stesso tempo lo sviluppo delle applicazioni disaccoppiandole dall'infrastruttura del database sottostante. Se stai usando MariaDB, MaxScale potrebbe essere una tecnologia rilevante per te. Dai un'occhiata ai nostri blog precedenti su come utilizzare il meccanismo di failover MaxScale.
Failover Drupal utilizzando ClusterControl
ClusterControl di Severalnines offre un'ampia gamma di soluzioni per la gestione e il monitoraggio dei database. Parte delle soluzioni che offriamo sono il failover automatico, il failover manuale e il ripristino di cluster/nodi. Questo è molto utile come se fungesse da amministratore del database virtuale, avvisandoti in tempo reale nel caso in cui il tuo cluster sia in "modalità panico", il tutto mentre il ripristino viene gestito dal sistema. Puoi consultare questo blog Come automatizzare il failover del database con ClusterControl per saperne di più sul failover di ClusterControl.
Altre soluzioni MySQL
Alcuni dei vecchi approcci sono ancora applicabili quando si desidera eseguire il failover. C'è MMM, MRM, oppure puoi controllare Group Replication o Galera (nota:Galera non usa la replica asincrona, piuttosto sincrona). Il failover in un cluster Galera non funziona allo stesso modo della replica asincrona. Con Galera puoi semplicemente scrivere su qualsiasi nodo oppure, se implementi un approccio master-slave, puoi indirizzare la tua applicazione su un altro nodo che sarà lo scrittore attivo per il cluster.
Failover di Drupal PostgreSQL
Dato che Drupal supporta PostgreSQL, verificheremo anche gli strumenti per implementare un processo di failover o switchover per PostgreSQL. PostgreSQL utilizza la replica di flusso incorporata, tuttavia puoi anche impostarla per utilizzare una replica logica (aggiunto come elemento principale di PostgreSQL nella versione 10).
Failover Drupal con pg_ctlcluster
Se il tuo ambiente è Ubuntu, usare pg_ctlcluster è un modo semplice e facile per ottenere il failover. Ad esempio, puoi semplicemente eseguire il seguente comando:
$ pg_ctlcluster 9.6 pg_7653 promoteo con RHEL/Centos, puoi usare il comando pg_ctl proprio come,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingPuoi anche attivare il failover di un server standby di log shipping creando un file trigger con il nome file e il percorso specificati da trigger_file in recovery.conf.
Devi fare attenzione con la promozione standby o la promozione slave qui, poiché potresti dover assicurarti che solo un master accetti la richiesta di lettura-scrittura. Ciò significa che, durante il passaggio, potrebbe essere necessario assicurarsi che il master precedente sia stato rilassato o arrestato.
La gestione del passaggio o del failover manuale dal server primario a quello di standby può essere veloce, ma richiede del tempo per preparare nuovamente il cluster di failover. Passare regolarmente da primario a standby è una pratica utile in quanto consente tempi di fermo regolari su ciascun sistema per la manutenzione. Questo serve anche come test del meccanismo di failover, per garantire che funzioni davvero quando ne hai bisogno. Sono sempre consigliate procedure di amministrazione scritte.
Failover automatico di Drupal PostgreSQL
Invece di un approccio manuale, potresti richiedere il failover automatico. Ciò è particolarmente necessario quando un server si arresta a causa di un guasto hardware o del danneggiamento della macchina virtuale. Potresti anche richiedere che un'applicazione esegua automaticamente il failover per ridurre i tempi di inattività dell'applicazione Drupal. Esamineremo ora alcuni di questi strumenti che possono essere utilizzati per il failover automatico.
Failover Drupal con Patroni
Patroni è un modello per creare la tua soluzione personalizzata ad alta disponibilità utilizzando Python e, per la massima accessibilità, un archivio di configurazione distribuito come ZooKeeper, etcd, Consul o Kubernetes. Si spera che gli ingegneri di database, i DBA, gli ingegneri DevOps e gli SRE che stanno cercando di implementare HA PostgreSQL nel data center, o in qualsiasi altro luogo, lo trovino utile
Failover Drupal utilizzando Pgpool
Pgpool-II è un software proxy che si trova tra i server PostgreSQL e un client di database PostgreSQL. Oltre ad avere un failover automatico, ha molteplici funzionalità che includono pool di connessioni, bilanciamento del carico, replica e limitazione delle connessioni in eccesso. Puoi leggere di più su questo strumento è il nostro blog in tre parti; parte prima, parte seconda, parte terza.
Failover Drupal utilizzando pglookout
pglookout è un daemon di monitoraggio e failover della replica PostgreSQL. pglookout monitora i nodi del database, il loro stato di replica e agisce in base a tale stato. Ad esempio, chiamando un comando di failover predefinito per promuovere un nuovo master nel caso in cui il precedente vada perso.
pglookout supporta due diversi tipi di nodi, quelli installati sui nodi db stessi e i nodi osservatore che possono essere installati ovunque. Lo scopo di avere pglookout sui nodi del database PostgreSQL è monitorare lo stato di replica del cluster e agire di conseguenza, gli osservatori hanno un mandato più limitato:osservano semplicemente lo stato del cluster per dare un altro punto di vista allo stato del cluster.
Failover Drupal utilizzando repmgr
repmgr è una suite di strumenti open source per la gestione della replica e del failover in un cluster di server PostgreSQL. Migliora le funzionalità di hot-standby integrate di PostgreSQL con strumenti per configurare server in standby, monitorare la replica ed eseguire attività amministrative come operazioni di failover o passaggio manuale.
repmgr ha fornito un supporto avanzato per i meccanismi di replica incorporati di PostgreSQL sin dalla loro introduzione nella versione 9.0. L'attuale serie repmgr, repmgr 4, supporta gli ultimi sviluppi nelle funzionalità di replica introdotti da PostgreSQL 9.3 come la replica a cascata, il cambio di sequenza temporale e i backup di base tramite il protocollo di replica.
Failover Drupal utilizzando ClusterControl
ClusterControl supporta il failover automatico per PostgreSQL. In caso di incidente, il tuo slave può essere promosso automaticamente allo stato di master. Con ClusterControl puoi anche distribuire database PostgreSQL standalone, replicato o in cluster. Puoi anche aggiungere o rimuovere facilmente un nodo con una singola azione.
Altre soluzioni di failover Drupal PostgreSQL
Ci sono sicuramente soluzioni di failover automatico che potrei essermi perso su questo blog. In tal caso, aggiungi i tuoi commenti di seguito in modo che possiamo conoscere i tuoi pensieri e le tue esperienze con la tua implementazione e configurazione per il failover, in particolare per i siti Web o le applicazioni Drupal.
Soluzioni aggiuntive per il failover di Drupal
Mentre gli strumenti che ho menzionato in precedenza gestiscono sicuramente la soluzione per i tuoi problemi con il failover, l'aggiunta di alcuni strumenti che rendano il failover abbastanza più semplice, più sicuro e abbiano un isolamento totale tra il livello del database può essere soddisfacente.
Failover Drupal utilizzando ProxySQL
Con ProxySQL, puoi semplicemente indirizzare i tuoi siti Web o applicazioni Drupal all'host del server ProxySQL e designerà quale nodo riceverà le scritture e quali nodi riceveranno le letture. La magia avviene in modo trasparente all'interno del livello TCP e non sono necessarie modifiche per la configurazione dell'applicazione/sito web. Oltre a ciò, ProxySQL funge anche da bilanciamento del carico per le richieste di scrittura e lettura per il traffico del database. Questo è applicabile solo se stai utilizzando varianti di database MySQL.
Failover Drupal utilizzando HAProxy con Keepalived
L'utilizzo di HAProxy e Keepalived aggiunge maggiore disponibilità e ridondanza all'interno del database di Drupal. Se si desidera eseguire il failover, è possibile farlo senza che l'applicazione sappia cosa sta accadendo all'interno del livello del database. Basta puntare la tua applicazione all'IP vrrp che hai impostato nel tuo Keepalived e tutto sarà gestito con isolamento totale dalla tua applicazione. La presenza di un failover automatico verrà gestita in modo trasparente e inconsapevole dall'applicazione, quindi non è necessario apportare modifiche una volta, ad esempio, che si è verificata un'emergenza ed è stato applicato un ripristino o un failover. La cosa buona di questa configurazione è che è applicabile sia ai database MySQL che PostgreSQL. Ti suggerisco di consultare il nostro blog PostgreSQL Load Balancing Using HAProxy &Keepalived per saperne di più su come farlo.
Tutte le opzioni precedenti sono supportate da ClusterControl. È possibile distribuire o importare il database e quindi distribuire ProxySQL, MaxScale o HAProxy &Keepalived. Tutto sarà gestito, monitorato e impostato automaticamente senza bisogno di ulteriori configurazioni da parte tua. Succede tutto in background e crea automaticamente un pronto per la produzione.
Conclusione
Avere un sito Web o un'applicazione Drupal sempre attivo, soprattutto se ti aspetti una grande quantità di traffico, può essere complicato da creare. Tuttavia, se disponi degli strumenti giusti, della configurazione corretta e del giusto stack tecnologico, è possibile ottenere un'elevata disponibilità e ridondanza.
E se non lo fai? Bene, allora ClusterControl lo configurerà e lo manterrà per te. In alternativa, puoi creare una configurazione utilizzando le tecnologie menzionate in questo blog, la maggior parte delle quali sono strumenti gratuiti open source in grado di soddisfare le tue esigenze.
