Come eseguire WordPress su 2 VM per alta disponibilità

Question

Come eseguire WordPress su 2 VM per alta disponibilità

13 lug 2015, 22:35:17

Visualizzazioni: 14.2K

Voti: 14

Microsoft Azure richiede che le applicazioni utilizzino due istanze distribuite su più data center per raggiungere il loro SLA di "alta disponibilità" e garantire che i tuoi siti non vadano offline durante la manutenzione di routine. Indicano anche quali coppie di data center non andranno mai in manutenzione contemporaneamente.

Tutto bene, ma come si può implementare facilmente nella pratica per un'app come WordPress con un database MySQL sulla stessa VM? Ho esperienza nel bilanciamento del carico tra due VM, ma la configurazione della replica del database mi sfugge. Non vorremmo avere due versioni dei dati che potrebbero desincronizzarsi. La replica MySQL sembra richiedere una configurazione master-slave che non sincronizzerebbe le modifiche al DB master se un utente finisse sull'istanza slave.

Sto fraintendendo questo concetto? Qualsiasi aiuto è molto apprezzato!

Yaron

360

mysql hosting amazon cloud scalabilità

Commenti

Perché ospiteresti WordPress su Azure? Ci sono hosting migliori e più economici per WordPress. Digital Ocean, per esempio.

Alexus

13 lug 2015 23:20:45

Alexus, non è davvero rilevante qui ma abbiamo un stack piuttosto ampio distribuito sull'infrastruttura di Azure, di cui WordPress è solo un componente. Azure è una piattaforma fantastica e ne siamo molto soddisfatti.

Yaron

15 lug 2015 01:16:07

capisco. Devi fare quello che devi fare :) Anche a me piace Azure per la maggior parte del mio lavoro con .NET, ma ho sempre ospitato i siti WP separatamente.

Alexus

15 lug 2015 01:51:34

Yaron, hai trovato utile la risposta qui sotto? Ha ricevuto 3 voti positivi finora, volevo solo verificare se hai trovato qualche concetto importante mancante così posso aggiornarla per affrontare il tuo caso d'uso specifico.

Bryan 'BJ' Hoffpauir Jr.

16 ago 2015 14:42:09

Grazie mille per la risposta approfondita @Bryan'BJ'Hoffpauir e scusa se non ho avuto il tempo di seguire le tue istruzioni per vedere se funzionano con la nostra implementazione. Sto segnando la risposta come corretta e ti ricontatterò se dovessi incontrare problemi. Grazie ancora!!

Yaron

17 ago 2015 22:33:33

Tutte le risposte alla domanda

Bryan 'BJ' Hoffpauir Jr. 322 · Accepted Answer · 2015-07-20T21:23:50Z

La cattiva notizia: la base open source di WordPress fa diverse assunzioni sull'essere eseguito su un singolo server (wp-content, upload degli utenti e media library per citarne alcuni).

La buona notizia: praticamente tutti i provider cloud (incluso Azure) hanno astrazioni che permettono di aggirare queste limitazioni progettuali.

Fondamentalmente, dovrai affrontare le seguenti problematiche:

Bilanciamento del traffico tra due (o più) server web/app "front-end" WordPress. Non troppo difficile dato che WordPress è PER LO PIÙ stateless a meno che non permetti agli utenti di accedere ai siti. Questo viene fatto tramite una combinazione di DNS e Load Balancer. Avrai bisogno di supporto per 2 IP per i tuoi server app - 1 set si collegherà alla subnet raggiungibile via Internet (si spera protetta da un firewall non descritto qui) e gli altri due saranno su una subnet DIVERSA isolata dall'altra rete e contenente le istanze del Database Server, ma lo schema di base è questo:

                     /-- (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2)
(Public IP) wp.domain.com          
                     \-- (10.0.0.2 - eth1) wp2.domain.com (10.0.1.2 - eth3)

Gestione delle sessioni SE permetti agli utenti di accedere ai siti. In tal caso, dovrai assicurarti che quando accedono al server 1, tutte le loro richieste future vengano instradate a quel server (sessioni sticky) o che non importi a quale server accedono perché le sessioni sono gestite tramite qualche altro meccanismo (ad esempio via Zend Server Session Clustering).
Gestione degli accessi Admin SE permetti ad alcuni utenti di accedere al back-end per gestire i contenuti (simile al punto sopra).
Scelta di un Sistema DB ANCHE Altamente Disponibile. Non ha senso avere due server front-end se il crash del DB manda giù l'intero sistema. Dovrai sfruttare la replica MySQL Master/Slave via ClearDB o modificare WordPress via plugin per usare SQL Server così da poter usare i suoi sistemi di clustering nativi. Questo significa che ti serviranno almeno 4 VM se vuoi gestire il livello DB da solo (2 x App & 2 x DB). Ecco come potrebbe apparire:


               /-- wp1.domain.com (10.0.1.1)\---/(10.0.1.3) db1.domain.com (10.0.2.3)\
         wp.domain.com                        X                                      |           
               \-- wp2.domain.com (10.0.1.2)/---\(10.0.1.4) db2.domain.com (10.0.2.3)/

NOTA - per garantire un failover affidabile e proteggere la sicurezza del sistema, di solito viene utilizzata una TERZA subnet di rete per collegare i due nodi del database tra loro tramite un canale privato separato dalle altre reti di comunicazione che i server app usano per parlare con il database e che i server app usano per comunicare con il mondo esterno.

Abilitare il Connection Pooling per massimizzare prestazioni e affidabilità delle connessioni al database dei tuoi server app.
Sfruttare un plugin di Caching come W3 Total Cache o Super Cache per minimizzare il carico sui server front-end.

Le seguenti guide offrono dettagli su come puoi affrontare ciascuna delle sfide sopra elencate. Ci sono diversi modi per gestirle in Azure, quindi spetta a te decidere come affrontare ogni sfida e gestire i vincoli che ogni scelta impone mentre lavori su e giù per lo stack.