Cum să rulezi WordPress pe 2 VM-uri pentru disponibilitate ridicată
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!
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ă.
- WordPress Scalabil
- Cum să găzduiți un WordPress Scalabil și Optimizat pentru Azure în câteva minute
- Implementarea unei aplicații web MVC cu Disponibilitate Ultra Înaltă pe Microsoft Azure – Partea 1
- Implementarea unei aplicații web MVC cu Disponibilitate Ultra Înaltă pe Microsoft Azure – Partea 2
- Oferta nouă "Scalabilă" WordPress în Azure
- WordPress de clasă enterprise pe Azure App Service
- Cum să rulați site-uri WordPress de clasă enterprise pe Azure Websites
