Microsoft Azure requiere que las aplicaciones utilicen dos instancias en múltiples centros de datos para lograr su SLA de "alta disponibilidad" y garantizar que sus sitios no se caigan por mantenimiento de rutina. Incluso le dicen qué pares de centros de datos nunca realizarán tareas de mantenimiento al mismo tiempo.
Eso está muy bien, pero ¿cómo haría esto fácilmente en la práctica para una aplicación como WordPress con una base de datos MySQL en la misma VM? No soy ajeno al equilibrio de carga entre dos máquinas virtuales, pero la configuración de replicación de la base de datos me elude. No querríamos dos versiones de los datos que pudieran estar fuera de sincronización. La replicación de MySQL parece requerir una configuración maestro-esclavo que no sincronizaría los cambios en la base de datos maestra si un usuario aterrizaba en la instancia esclava.
¿Estoy malinterpretando este concepto? ¡Cualquier ayuda es muy apreciada!
Respuestas:
Las malas noticias: la base central de código abierto de Wordpress hace algunas suposiciones sobre la ejecución en un solo servidor (contenido de wp, cargas de usuarios y biblioteca de medios, por nombrar algunos)
La buena noticia: casi todos los proveedores de la nube (incluido Azure) tienen abstracciones que le permiten evitar estas limitaciones de diseño.
Básicamente, abordará las siguientes preocupaciones:
/ - (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2) (IP pública) wp.domain.com \ - (10.0.0.2 - eth1) wp2.domain.com (10.0.1.2 - eth3)Gestionar sesiones SI está permitiendo que los usuarios inicien sesión en los sitios. Si es así, deberá asegurarse cuando inicien sesión en el servidor 1, ya sea que todas sus solicitudes futuras se enruten a ese servidor (sesiones fijas) o que no importa a qué servidor acceden porque las sesiones se administran a través de algún otro mecanismo (a través de Zend Server Session Clustering , por ejemplo).
Administración de inicios de sesión de administrador SI está permitiendo que algunos usuarios inicien sesión en el back-end para administrar contenido (similar al anterior).
Elección del sistema de base de datos que también está altamente disponible No tiene sentido tener dos servidores front-end si el bloqueo de su base de datos hace caer todo el sistema. Tendrá que aprovechar la replicación maestra / esclava de MySQL a través de ClearDB o modificar WordPress a través de un complemento para aprovechar SQL Server para que pueda usar sus sistemas de clústeres nativos . Esto significará que necesita al menos 4 máquinas virtuales si desea administrar la capa de base de datos usted mismo (2 x aplicación y 2 x base de datos). Así es como podría verse:
/ - 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 : para garantizar una conmutación por error confiable y proteger la seguridad del sistema, generalmente se utiliza una TERCERA subred de red para conectar los dos nodos de la base de datos entre sí a través de un canal privado que está separado de las otras redes de comunicación que usan los servidores de aplicaciones para comunicarse la base de datos y los servidores de aplicaciones utilizan para comunicarse con el mundo exterior.
Habilitar la agrupación de conexiones para maximizar el rendimiento y la confiabilidad de las conexiones de la base de datos del servidor de aplicaciones.
Aprovechando un complemento de almacenamiento en caché como W3 Total Cache o Super Cache para minimizar la carga en los servidores front-end.
Las siguientes guías ofrecen detalles sobre cómo puede abordar cada uno de los desafíos anteriores. Hay varias formas de manejar cada una en Azure, por lo que depende de usted decidir cómo quiere atacar cada desafío y luego lidiar con las limitaciones que impone cada una de esas opciones a medida que sube y baja de la pila.
fuente