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:
- Balanceo de tráfico entre dos (o más) servidores web / de aplicaciones "front-end" de Wordpress. No es demasiado difícil ya que Wordpress ESTÁ MAYORITAMENTE sin estado a menos que permita que los usuarios inicien sesión en los sitios. Esto se realiza mediante 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 es de esperar 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 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)
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.