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.