Ogni impresa redditizia richiede un'elevata disponibilità. I siti Web e i blog non sono diversi poiché anche le aziende e gli individui più piccoli richiedono che i loro siti rimangano attivi per mantenere la loro reputazione.
WordPress è, di gran lunga, il CMS più popolare al mondo che alimenta milioni di siti Web di piccole e grandi dimensioni. Ma come puoi assicurarti che il tuo sito web rimanga attivo. In particolare, come posso garantire che l'indisponibilità del mio database non influisca sul mio sito web?
In questo post del blog mostreremo come ottenere il failover per il tuo sito Web WordPress utilizzando ClusterControl.
La configurazione che utilizzeremo per questo blog utilizzerà Percona Server 5.7. Avremo un altro host che contiene l'applicazione Apache e Wordpress. Non toccheremo la parte di alta disponibilità dell'applicazione, ma anche questo qualcosa che vuoi assicurarti di avere. Utilizzeremo ClusterControl per gestire i database per garantire la disponibilità e utilizzeremo un terzo host per installare e configurare ClusterControl stesso.
Supponendo che ClusterControl sia attivo e funzionante, dovremo importarvi il nostro database esistente.
Importazione di un cluster di database con ClusterControl
Vai all'opzione Importa server/database esistente nella procedura guidata di distribuzione.
Dobbiamo configurare la connettività SSH poiché questo è un requisito per ClusterControl per essere in grado di gestire i nodi.
Ora dobbiamo definire alcuni dettagli su fornitore, versione, utente root accedere, il nodo stesso e se vogliamo che ClusterControl gestisca il ripristino automatico per noi o meno. Questo è tutto, una volta che il lavoro ha esito positivo, ti verrà presentato un cluster nell'elenco.
Per configurare l'ambiente ad alta disponibilità, dobbiamo eseguire un paio di azioni. Il nostro ambiente sarà composto da...
- Coppia Master - Slave
- Due istanze ProxySQL per il rilevamento della suddivisione in lettura/scrittura e della topologia
- Due istanze Keepalived per la gestione dell'IP virtuale
L'idea è semplice:distribuiremo lo slave sul nostro master in modo da avere una seconda istanza su cui eseguire il failover in caso di errore del master. ClusterControl sarà responsabile del rilevamento degli errori e promuoverà lo slave nel caso in cui il master non sia disponibile. ProxySQL terrà traccia della topologia di replica e reindirizzerà il traffico al nodo corretto - le scritture verranno inviate al master, indipendentemente dal nodo in cui si trova, le letture possono essere inviate solo al master o distribuite tra master e slave . Infine, Keepalived sarà collocato con ProxySQL e fornirà VIP per la connessione dell'applicazione. Quel VIP sarà sempre assegnato a una delle istanze ProxySQL e Keepalived lo sposterà sulla seconda, in caso di errore del nodo ProxySQL "principale".
Detto tutto questo, configuriamolo usando ClusterControl. Tutto può essere fatto in un paio di clic. Inizieremo con l'aggiunta dello schiavo.
Aggiunta di uno slave al database con ClusterControl
Iniziamo selezionando il lavoro "Aggiungi slave di replica". Quindi ci viene chiesto di compilare un modulo:
Dobbiamo scegliere il master (nel nostro caso non lo sappiamo davvero hanno molte opzioni), dobbiamo passare l'IP o il nome host per il nuovo slave. Se avessimo dei backup creati in precedenza, potremmo usarne uno per eseguire il provisioning dello slave. Nel nostro caso questo non è disponibile e ClusterControl provvederà al provisioning dello slave direttamente dal master. Questo è tutto, il lavoro si avvia e ClusterControl esegue le azioni richieste. Puoi monitorare i progressi nella scheda Attività.
Infine, una volta completato con successo il lavoro, lo slave dovrebbe essere visibile sulla elenco dei cluster.
Ora procederemo con la configurazione delle istanze ProxySQL. Nel nostro caso l'ambiente è minimo, quindi, per semplificare le cose, individueremo ProxySQL su uno dei nodi del database. Questa non è, tuttavia, l'opzione migliore in un ambiente di produzione reale. Idealmente, ProxySQL dovrebbe essere posizionato su un nodo separato o collocato con gli altri host dell'applicazione.
Il punto in cui iniziare il lavoro è Gestisci -> Bilanciatori di carico.
Qui devi scegliere dove installare ProxySQL, passare le credenziali amministrative e aggiungi un utente del database. Nel nostro caso, utilizzeremo il nostro utente esistente poiché la nostra applicazione WordPress lo utilizza già per la connessione al database. Dobbiamo quindi scegliere quali nodi utilizzare in ProxySQL (qui vogliamo sia master che slave) e far sapere a ClusterControl se utilizziamo transazioni esplicite o meno. Questo non è realmente rilevante nel nostro caso, poiché riconfigurare ProxySQL una volta distribuito. Quando l'opzione è abilitata, la divisione in lettura/scrittura non sarà abilitata. Altrimenti ClusterControl configurerà ProxySQL per la divisione in lettura/scrittura. Nella nostra configurazione minima dovremmo pensare seriamente se vogliamo che la divisione lettura/scrittura avvenga. Analizziamolo.
I vantaggi e gli svantaggi di lettura/scrittura Spit in ProxySQL
Il vantaggio principale dell'utilizzo della divisione lettura/scrittura è che tutto il traffico SELECT sarà distribuito tra il master e lo slave. Ciò significa che il carico sui nodi sarà inferiore e anche il tempo di risposta dovrebbe essere inferiore. Suona bene, ma tieni presente che se un nodo si guasta, l'altro nodo dovrà essere in grado di ospitare tutto il traffico. Non ha senso disporre di un failover automatizzato se la perdita di un nodo significa che il secondo nodo sarà sovraccarico e, di fatto, anche non disponibile.
Potrebbe avere senso distribuire il carico se si hanno più slave:perdere un nodo su cinque ha un impatto minore rispetto a perderne uno su due. Indipendentemente da ciò che decidi, puoi facilmente modificare il comportamento andando al nodo ProxySQL e facendo clic sulla scheda Regole.
Assicurati di guardare la regola 200 (quella che cattura tutte le istruzioni SELECT ). Nella schermata seguente puoi vedere che il gruppo host di destinazione è 20, il che significa che tutti i nodi nel cluster:la divisione in lettura/scrittura e la scalabilità orizzontale sono abilitate. Possiamo facilmente disabilitarlo modificando questa regola e cambiando il gruppo host di destinazione su 10 (quello che contiene master).
Se desideri abilitare la divisione lettura/scrittura, puoi facilmente farlo modificando nuovamente questa regola di query e riportando il gruppo host di destinazione su 20.
Ora, distribuiamo il secondo ProxySQL.
Per evitare di passare nuovamente tutte le opzioni di configurazione possiamo utilizzare la voce “Importa configurazione ” e scegli il nostro ProxySQL esistente come sorgente.
Quando questo lavoro sarà completato, dobbiamo ancora eseguire l'ultimo passaggio nell'impostazione del nostro ambiente. Dobbiamo distribuire Keepalived sopra le istanze ProxySQL.
Distribuzione di Keepalived su istanze ProxySQL
Qui abbiamo scelto ProxySQL come tipo di bilanciamento del carico, passato entrambe le istanze ProxySQL per Keepalive per essere installato e abbiamo digitato la nostra interfaccia VIP e di rete.
Come puoi vedere, ora abbiamo l'intera configurazione pronta e pronta. Abbiamo un VIP di 10.0.0.111 che è assegnato a una delle istanze ProxySQL. Le istanze ProxySQL reindirizzeranno il nostro traffico ai nodi MySQL di back-end corretti e ClusterControl terrà d'occhio l'ambiente che esegue il failover, se necessario. L'ultima azione che dobbiamo compiere è riconfigurare Wordpress per utilizzare l'IP virtuale per la connessione al database.
Per farlo, dobbiamo modificare wp-config.php e cambiare la variabile DB_HOST nel nostro IP virtuale:
/** MySQL hostname */
define( 'DB_HOST', '10.0.0.111' );Conclusione
D'ora in poi Wordpress si collegherà al database usando VIP e ProxySQL. In caso di guasto del nodo master, ClusterControl eseguirà il failover.
Come puoi vedere, è stato eletto un nuovo master e anche ProxySQL punta a nuovo master nel gruppo host 10.
Ci auguriamo che questo post del blog ti dia un'idea su come progettare un ambiente di database ad alta disponibilità per un sito Web Wordpress e su come è possibile utilizzare ClusterControl per distribuire tutti i suoi elementi.
