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

Question

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

13 jul 2015, 22:35:17

Vistas: 14.2K

Votos: 14

Microsoft Azure requiere que las aplicaciones utilicen dos instancias en múltiples centros de datos para cumplir con su SLA de "alta disponibilidad" y garantizar que tus sitios no caigan por mantenimiento rutinario. Incluso te indican qué pares de centros de datos nunca entrarán en mantenimiento al mismo tiempo.

Todo esto está muy bien, pero ¿cómo se implementaría fácilmente en la práctica para una aplicación como WordPress con una base de datos MySQL en la misma VM? No soy nuevo en el balanceo de carga entre dos VMs, pero la configuración de replicación de la base de datos se me escapa. No queremos tener dos versiones de los datos que puedan desincronizarse. La replicación de MySQL parece requerir una configuración maestro-esclavo que no sincronizaría los cambios a la base de datos maestra si un usuario aterriza en la instancia esclava.

¿Estoy malinterpretando este concepto? ¡Cualquier ayuda será muy apreciada!

Yaron

360

mysql alojamiento amazon cloud escalabilidad

Comentarios

¿Por qué alojarías WordPress en Azure? Hay alojamientos mejores y más económicos para WordPress. Digital Ocean, por ejemplo.

Alexus

13 jul 2015 23:20:45

Alexus, eso no es realmente relevante aquí, pero tenemos una infraestructura bastante grande distribuida en la plataforma de Azure, de la cual WordPress es solo un componente. Azure es una plataforma fantástica y estamos muy contentos con ella.

Yaron

15 jul 2015 01:16:07

Entiendo. Hay que hacer lo que hay que hacer :) También me gusta Azure para la mayoría de mis proyectos .NET, pero siempre he alojado sitios WP por separado.

Alexus

15 jul 2015 01:51:34

Yaron, ¿encontraste útil la respuesta a continuación? Ha recibido 3 votos positivos hasta ahora, solo quería verificar si encontraste algún concepto importante faltante para poder actualizarlo y abordarlo para tu caso de uso particular.

Bryan 'BJ' Hoffpauir Jr.

16 ago 2015 14:42:09

Muchas gracias por la respuesta tan detallada @Bryan'BJ'Hoffpauir y lamento no haber tenido tiempo para probar seguir tus instrucciones y ver si funcionan con nuestra implementación. Estoy marcando la respuesta como correcta y me comunicaré nuevamente si encuentro algún problema. ¡¡Muchas gracias de nuevo!!

Yaron

17 ago 2015 22:33:33

Todas las respuestas a la pregunta

Bryan 'BJ' Hoffpauir Jr. 322 · Accepted Answer · 2015-07-20T21:23:50Z

La mala noticia: La base de código abierto principal de WordPress hace varias suposiciones sobre su ejecución en un solo servidor (wp-content, subidas de usuarios y biblioteca multimedia, por nombrar algunas).

La buena noticia: La mayoría de los proveedores de cloud (incluyendo Azure) tienen abstracciones que permiten solucionar estas limitaciones de diseño.

Fundamentalmente, tendrás que abordar las siguientes preocupaciones:

Balanceo de carga entre dos (o más) servidores web/aplicación "front-end" de WordPress. No es demasiado difícil ya que WordPress es en su mayor parte sin estado, a menos que permitas que los usuarios inicien sesión en los sitios. Esto se hace mediante una combinación de DNS y balanceadores de carga. Necesitarás soporte para 2 IPs para tus servidores de aplicaciones: un conjunto se conectará a la subred que es enrutable a través de Internet (aunque idealmente protegida por un firewall no descrito aquí) y los otros dos estarán en una subred DIFERENTE que está aislada de la otra red y contiene las instancias del servidor de bases de datos, pero el esquema básico es el siguiente:

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

Gestión de sesiones SI permites que los usuarios inicien sesión en los sitios. Si es así, deberás asegurarte de que cuando inicien sesión en el servidor 1, todas sus futuras solicitudes sean enrutadas a ese servidor (sesiones persistentes) o que no importe a qué servidor accedan porque las sesiones se gestionan mediante algún otro mecanismo (por ejemplo, mediante Zend Server Session Clustering).
Gestión de inicios de sesión de administradores SI permites que algunos usuarios inicien sesión en el backend para gestionar contenido (similar al punto anterior).
Elección de un sistema de bases de datos que TAMBIÉN sea altamente disponible. No tiene sentido tener dos servidores front-end si un fallo en tu base de datos derriba todo el sistema. Deberás aprovechar la replicación Maestro/Esclavo de MySQL mediante ClearDB o modificar WordPress mediante un plugin para aprovechar SQL Server y así usar sus sistemas de clustering nativos. Esto significa que necesitarás al menos 4 máquinas virtuales si quieres gestionar la capa de bases de datos tú mismo (2 x App & 2 x DB). Aquí tienes un esquema de cómo 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 un failover confiable y proteger la seguridad del sistema, normalmente se usa una TERCERA subred de red para conectar los dos nodos de base de datos entre sí mediante un canal privado que está separado de las otras redes de comunicación que los servidores de aplicaciones usan para hablar con la base de datos y las que los servidores de aplicaciones usan para comunicarse con el exterior.

Habilitar Connection Pooling para maximizar el rendimiento y la confiabilidad de las conexiones a la base de datos de tus servidores de aplicaciones.
Aprovechar un plugin de 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 puedes abordar cada uno de los desafíos anteriores. Hay varias formas de manejar cada uno en Azure, por lo que depende de ti decidir cómo quieres abordar cada desafío y luego lidiar con las restricciones que cada una de esas elecciones impone mientras trabajas en la arquitectura.