Cum să rulezi WordPress pe 2 VM-uri pentru disponibilitate ridicată

13 iul. 2015, 22:35:17
Vizualizări: 14.2K
Voturi: 14

Microsoft Azure necesită ca aplicațiile să utilizeze două instanțe în mai multe centre de date pentru a obține SLA-ul lor de "disponibilitate ridicată" și pentru a asigura că site-urile nu vor fi indisponibile din cauza întreținerii de rutină. Ei chiar specifică care perechi de centre de date nu vor fi niciodată în întreținere în același timp.

Totul sună bine, dar cum ai putea face acest lucru în practică pentru o aplicație precum WordPress cu o bază de date MySQL pe aceeași VM? Sunt familiarizat cu echilibrarea încărcării între două VM-uri, dar configurarea replicării bazei de date mă depășește. Nu am vrea două versiuni ale datelor care ar putea pierde sincronizarea. Replicarea MySQL pare să necesite o configurare master-slave care ar eșua în sincronizarea modificărilor la baza de date master dacă un utilizator ar ajunge pe instanța slave.

Am înțeles greșit acest concept? Orice ajutor este binevenit!

5
Comentarii

De ce ai gazdui WordPress pe Azure? Există gazduiri mai bune și mai ieftine pentru WordPress. Digital Ocean, de exemplu.

Alexus Alexus
13 iul. 2015 23:20:45

Alexus, asta nu este chiar relevant aici, dar avem un stack destul de mare răspândit pe infrastructura Azure, din care WordPress este doar o componentă. Azure este o platformă fantastică și suntem foarte mulțumiți de ea.

Yaron Yaron
15 iul. 2015 01:16:07

am înțeles. Trebuie să faci ce trebuie să faci :) Îmi place și mie Azure pentru majoritatea lucrurilor mele .NET, dar întotdeauna am gazduit site-uri WP separat.

Alexus Alexus
15 iul. 2015 01:51:34

Yaron, ai găsit răspunsul de mai jos util? A primit până acum 3 voturi pozitive, voiam doar să verific dacă ai observat vreun concept important lipsă, ca să-l pot actualiza pentru a aborda cazul tău particular.

Bryan 'BJ' Hoffpauir Jr. Bryan 'BJ' Hoffpauir Jr.
16 aug. 2015 14:42:09

Mulțumesc mult pentru răspunsul detaliat @Bryan'BJ'Hoffpauir și îmi cer scuze că nu am avut timp să încerc să urmez instrucțiunile tale pentru a verifica dacă funcționează în implementarea noastră. Marchez răspunsul ca corect și voi reveni dacă întâmpin probleme. Mulțumesc din nou!!

Yaron Yaron
17 aug. 2015 22:33:33
Toate răspunsurile la întrebare 1
0
13

Vestea proastă: Baza open source a WordPress face câteva presupuneri despre faptul că rulează pe un singur server (wp-content, încărcările utilizatorilor și biblioteca media, pentru a numi câteva).

Vestea bună: Aproape toți furnizorii de servicii cloud (inclusiv Azure) au abstracții care vă permit să ocoliți aceste limitări de design.

În esență, veți aborda următoarele preocupări:

  • Echilibrarea sarcinii între doi (sau mai mulți) servere web/aplicații WordPress "front-end". Nu este prea dificil, deoarece WordPress este MAI MULT fără stare, cu excepția cazului în care permiteți utilizatorilor să se autentifice pe site-uri. Acest lucru se face printr-o combinație de DNS și echilibrare de sarcină. Veți avea nevoie de suport pentru 2 IP-uri pentru serverele dvs. de aplicații - 1 set se va conecta la subrețeaua care este rutabilă prin internet (deși sperăm că protejată de un firewall care nu este descris mai jos), iar celelalte două vor fi pe o ALTĂ subrețea care este izolată de cealaltă rețea și conține instanțele serverului de baze de date, dar schema de bază este următoarea:
                     /-- (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)
  • Gestionarea sesiunilor DACĂ permiteți utilizatorilor să se autentifice pe site-uri. Dacă da, va trebui să vă asigurați că atunci când se autentifică pe serverul 1, fie toate solicitările lor viitoare sunt direcționate către acel server (sesiuni persistente), fie că nu contează pe care server accesează, deoarece sesiunile sunt gestionate prin alt mecanism (de exemplu, prin Zend Server Session Clustering).

  • Gestionarea autentificărilor de administrare DACĂ permiteți unor utilizatori să se autentifice în backend pentru a gestiona conținutul (similar cu cele de mai sus).

  • Alegerea unui sistem de baze de date care este DE ASEMENEA foarte disponibil. Nu are rost să aveți două servere front-end dacă defectarea bazei de date vă dă în cap întregul sistem. Va trebui să utilizați replicarea MySQL Master / Slave prin ClearDB sau să modificați WordPress prin plugin pentru a utiliza SQL Server, astfel încât să puteți folosi sistemele sale native de clustering. Acest lucru înseamnă că veți avea nevoie de cel puțin 4 VM-uri dacă doriți să gestionați singur stratul de baze de date (2 x App & 2 x DB). Iată cum ar putea arăta:

               /-- 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)/

  • NOTĂ - pentru a asigura o tranziție la rezervă fiabilă și pentru a proteja securitatea sistemului, se utilizează de obicei o A TREIA subrețea pentru a conecta cele două noduri de baze de date între ele printr-un canal privat care este separat de celelalte rețele de comunicare pe care serverele de aplicații le folosesc pentru a comunica cu baza de date și pe care serverele de aplicații le folosesc pentru a comunica cu lumea exterioară.
  • Activarea Connection Pooling pentru a maximiza performanța și fiabilitatea conexiunilor serverului dvs. de aplicații la baza de date.

  • Utilizarea unui plugin de caching precum W3 Total Cache sau Super Cache pentru a minimiza încărcarea pe serverele front-end.

Următoarele ghiduri oferă detalii despre cum puteți aborda fiecare dintre aceste provocări. Există mai multe moduri de a gestiona fiecare în Azure, așa că vă revine sarcina de a decide cum doriți să abordați fiecare provocare și apoi să vă ocupați de constrângerile pe care le impun fiecare dintre aceste alegeri pe măsură ce lucrați în sus și în jos pe stivă.

20 iul. 2015 21:23:50