Cómo ejecutar WordPress en 2 máquinas virtuales para una alta disponibilidad

10

Microsoft Azure requiere que las aplicaciones utilicen dos instancias en varios centros de datos para lograr su SLA de "alta disponibilidad" y garantizar que sus sitios no se caigan para el mantenimiento de rutina. Incluso le dicen qué pares de centros de datos nunca irán al mantenimiento al mismo tiempo.

Todo está muy bien, pero ¿cómo lo haría fácilmente en la práctica para una aplicación como WordPress con una base de datos MySQL en la misma máquina virtual? No soy ajeno al equilibrio de carga entre dos máquinas virtuales, pero la configuración de la replicación de la base de datos me elude. No queremos dos versiones de los datos que podrían desincronizarse. La replicación de MySQL parece requerir una configuración maestro-esclavo que no sincronizaría los cambios con la base de datos maestra si un usuario aterrizara en la instancia esclava.

¿Estoy malinterpretando este concepto? Cualquier ayuda es muy apreciada!

    
pregunta Yaron 13.07.2015 - 21:35

1 respuesta

9

Las malas noticias: la base de código abierto de Wordpress hace algunas suposiciones sobre la ejecución en un único servidor (contenido wp, subidas de usuarios y biblioteca de medios, por nombrar algunas)

La buena noticia: prácticamente todos los proveedores de la nube (incluido Azure) tienen abstracciones que le permiten solucionar estas limitaciones de diseño.

Fundamentalmente, abordarás las siguientes inquietudes:

  • El tráfico de equilibrio de carga entre dos (o más) servidores de aplicaciones / web de WordPress "front-end". No es demasiado difícil ya que Wordpress es mayormente sin estado a menos que esté permitiendo que los usuarios inicien sesión en los sitios. Esto se hace a través de una combinación de DNS y equilibradores de carga. Necesitará soporte para 2 IP para sus servidores de aplicaciones: 1 conjunto se conectará a la subred que se puede enrutar a través de Internet (aunque se espera que esté protegido por un firewall que no se describe a continuación) y los otros dos estarán en una subred DIFERENTE que esté aislada de la otra red y contiene las instancias del servidor de base de datos, pero el esquema básico es el siguiente:
                     /-- (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)
  • Administrar sesiones SI está permitiendo a los usuarios iniciar sesión en los sitios. Si es así, deberá asegurarse cuando inicien sesión en el servidor 1 que todas sus futuras solicitudes se enruten a ese servidor (sesiones persistentes) o que no importa a qué servidor acceden, ya que las sesiones se administran a través de algún otro mecanismo. (a través de Agrupación de sesiones del servidor de Zend , por ejemplo).

  • Administrar los inicios de sesión del administrador SI está permitiendo que algunos usuarios inicien sesión en el back-end para administrar el contenido (similar a lo anterior).

  • Elegir un sistema de base de datos que TAMBIÉN es altamente disponible. No tiene sentido tener dos servidores front-end si la falla de su base de datos desbarata todo el sistema. Tendrá que aprovechar la replicación de MySQL Master / Slave a través de ClearDB o modifique WordPress a través del complemento para aprovechar SQL Server para que pueda usar su sistemas de agrupamiento nativo . Esto significará que necesita al menos 4 máquinas virtuales si desea administrar la capa de DB por sí mismo (2 x App y 2 x DB). 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 & Para proteger la seguridad del sistema, una TERCERA red de subred se usa generalmente 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 los servidores de aplicaciones utilizan para comunicarse con la base de datos & Los servidores de aplicaciones utilizan para comunicarse con el mundo exterior.

  • Habilitando la agrupación de conexiones para maximizar el rendimiento y la confiabilidad de las conexiones de la base de datos del servidor de su aplicación.

  • Aprovechar 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 información específica sobre cómo 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 desea atacar cada desafío y luego lidiar con las restricciones que impone cada una de esas opciones a medida que sube y baja de la pila.

respondido por el Bryan 'BJ' Hoffpauir Jr. 20.07.2015 - 20:23

Lea otras preguntas en las etiquetas