Come eseguire WordPress su 2 VM per l'alta disponibilità

Microsoft Azure richiede che le applicazioni utilizzino due istanze su più data center al fine di raggiungere il loro SLA di "alta disponibilità" e garantire che i siti non vengano interrotti per la manutenzione ordinaria. Ti dicono anche quali coppie di data center non andranno mai per manutenzione contemporaneamente.

Va tutto bene ma come lo faresti facilmente in pratica per un'app come WordPress con un database MySQL sulla stessa VM? Non sono estraneo al bilanciamento del carico tra due VM, ma la configurazione della replica del database mi sfugge. Non vorremmo due versioni dei dati che potrebbero non essere sincronizzate. La replica di MySQL sembra richiedere un'impostazione master-slave che non riuscirebbe a sincronizzare le modifiche al DB master se un utente arrivasse sull'istanza slave.

Sto solo fraintendendo questo concetto? Ogni aiuto è molto apprezzato!

— Yaron
fonte

Perché dovresti ospitare WordPress su Azure? Esistono hosting migliori e più economici per WordPress. Digital Ocean ad esempio.

— Alessio,

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

— Yaron,

Gotcha. Devi fare quello che devi fare :) Mi piace anche Azure per la maggior parte delle mie cose .NET, ma ho sempre ospitato i siti WP separatamente.

— Alessio,

Yaron, hai trovato utile la risposta qui sotto? Finora ha ricevuto 3 voti positivi, volevo solo verificare se hai trovato qualche concetto importante mancante in modo che io possa aggiornare per risolverlo per il tuo caso d'uso specifico.

— Bryan 'BJ' Hoffpauir Jr.

Grazie mille per la risposta esauriente @ Bryan'BJ'Hoffpauir e scusate non ho avuto il tempo di provare a seguire le vostre istruzioni per vedere se funzionano con la nostra implementazione. Contrassegno la risposta come corretta e la raggiungerò di nuovo in caso di problemi. Grazie ancora!!

— Yaron,

Le cattive notizie: la principale base open source di Wordpress fa alcune ipotesi sull'esecuzione su un singolo server (contenuto wp, caricamenti utente e libreria multimediale per citarne alcuni)

Le buone notizie: praticamente tutti i fornitori di cloud (incluso Azure) hanno astrazioni che ti consentono di aggirare queste limitazioni di progettazione.

Fondamentalmente, affronterai le seguenti preoccupazioni:

Bilanciamento del carico tra due (o più) server Web / app "front-end" Wordpress. Non troppo difficile dal momento che Wordpress è per lo più apolide a meno che non si consenta 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 di app: 1 set si connetterà alla sottorete che è instradabile via Internet (anche se si spera sia protetto da un firewall non indicato di seguito) e gli altri due saranno su una sottorete DIVERSA che è isolata da l'altra rete e contiene le istanze del server database ma la struttura di base è simile a questa:

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

Gestione delle sessioni SE si consente agli utenti di accedere ai siti. In questo caso, dovrai assicurarti quando effettuano l'accesso al server 1 che tutte le loro richieste future vengano indirizzate a quel server (sessioni permanenti) o che non importa a quale server accedano perché le sessioni sono gestite tramite altri meccanismi (ad esempio tramite il cluster di sessione del server Zend ).
Gestione degli accessi amministratore Se si consente ad alcuni utenti di accedere al back-end per gestire il contenuto (simile a quello sopra).
La scelta del sistema DB che è anche altamente disponibile. Non ha senso avere due server front-end se l'arresto anomalo del DB fa crollare l'intero sistema. Dovrai sfruttare la replica MySQL Master / Slave tramite ClearDB o modificare WordPress tramite plug-in per sfruttare SQL Server in modo da poter utilizzare i suoi sistemi di clustering nativo . Questo significherà che hai bisogno di almeno 4 VM se vuoi gestire tu stesso il livello DB (2 x App e 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 sottorete di TERZA rete per connettere i due nodi del database tra loro tramite un canale privato separato dalle altre reti di comunicazione con cui i server delle app usano per parlare il database e i server delle app utilizzano per comunicare con il mondo esterno.
Abilitazione del pool di connessioni per massimizzare le prestazioni e l'affidabilità delle connessioni al database del server delle app.
Sfruttando un plug-in di cache come W3 Total Cache o Super Cache per ridurre al minimo il carico sui server front-end.

Le seguenti guide offrono dettagli su come affrontare ciascuna delle sfide sopra menzionate. Esistono diversi modi per gestirli ciascuno in Azure, quindi spetta a te decidere come vuoi attaccare ogni sfida, quindi affrontare i vincoli che ciascuna di queste scelte impone mentre lavori su e giù per lo stack.

— Bryan 'BJ' Hoffpauir Jr.
fonte