Cuando tu WordPress consigue tener mucho tráfico o tienes instalado un WooCommerce y necesitas que siempre esté funcionando para evitar problemas con tu hosting es muy probable que necesites montar tu WordPress en un sistema de Alta Disponibilidad (o High Availability).
En su día ya expliqué los distintos tipos de Hosting para WordPress que se pueden llegar a conseguir y partiendo de esa ase se pueden construir sistemas de Alta Disponibilidad. Esto significa que tienes tu sitio web en distintos servidores distribuidos en varias partes del planeta (normalmente en 2-3 localizaciones) y que todos ellos son capaces de responder de la misma manera a todas las peticiones.
Para esto necesitamos bastantes elementos previos a montar el propio WordPress en sí, que se centran en la infraestructura y su configuración. Lo que voy a explicar es una de tantas opciones posibles, pero es simplemente una idea de lo que se puede montar y cómo.
Para comenzar necesitamos al menos un sistema centralizado de control. En este caso usaremos algún sistema tipo Rancher con el que poder gestionar la infraestructura y sus contenedores. Desde este sistema podremos crear y escalar la infraestructura, sus contenidos y parte de la gestión en los momentos críticos.
Por otro lado necesitaremos varios VPS distribuidos en varias localizaciones. Por poner un ejemplo podríamos montar un VPS en Barcelona y otro VPS en Madrid, de forma que tendríamos un sistema de Alta Disponibilidad focalizado a España. Se puede montar a nivel internacional, los límites están en donde quieras ponerlos. En principio se puede montar un VPS con cualquier tipo de recursos, aunque teniendo en cuenta lo que se va a montar es muy recomendable que, por ejemplo para una web sencilla tengamos una máquina de 1 CPU, 2 GB de RAM y 20 GB en SSD, o si tenemos un proyecto ya un poco más avanzado al menos 2 CPU, 4 GB de RAM y 40 GB de SDD. De nuevo, los recursos dependen del proyecto (o los proyectos) que se vayan a incluir. Al fin y al cabo la infraestructura hoy en día es bastante barata. Incluso, se puede plantear que una infraestructura principal tenga una serie de recursos y el resto tenga otra.
¿Qué tendrá cada uno de estos VPS? Pues en principio 4 contenedores que se pueden montar, por ejemplo, con Docker. Uno de ellos tendría la base de datos con MariaDB (o MySQL o Percona). Otro de ellos podría tener ProxySQL para la gestión de las consultas. Un tercer elemento sería un Redis para la caché. Para acabar tendríamos lo que sería el servidor web, con un nginx y PHP. Esta es la base, se podrían montar otros sistemas.
Otro elemento a tener presente es dónde se almacenan los datos. En este caso las bases de datos almacenarán la información en local, de forma que MariaDB y Redis alojarán los datos en los discos locales de cada VPS. En cambio para los datos del servidor web (o de las webs en sí) podremos aprovechar en montar un sistema distribuido con GlusterFS, que nos permita, por ejemplo, que cuando se suba una imagen al WordPress automáticamente esté disponible en todas las localizaciones.
Para los datos del MariaDB plantearemos un sistema master-slave. Depende de la infraestructura y su conectividad se puede montar también un sistema master-master, todo dependerá de la potencia de la infraestructura y del proyecto. Para la gestión plantearemos que el ProxySQL permita ejecutar las consultas SELECT (el 90%-95% habitualmente en WordPress) en cualquiera de las máquinas, y los INSERT o UPDATE en sólo la base de datos principal. Esta parte es bastante variable aunque este sistema es simple y funcional.
La caché de objetos en Redis funcionaría en modo local. Se podría montar también en modo cluster, aunque las ventajas de hacerlo tendrían que analizarse, ya que dependería del sistema de distribución del tráfico que se haga.
Para la distribución del tráfico podemos plantear las funcionalidades avanzadas de Route53 a nivel de DNS gracias a las cuales el sistema decidiría a qué infraestructura distribuir el tráfico, e incluso detectar si uno de los nodos está sin funcionar y poder desviar el tráfico automáticamente.
Otro elemento a tener en cuenta es el de las tareas programadas (crones). Para evitar que se ejecuten en todas las máquinas y se puedan duplicar tareas, desde un nivel superior el sistema decidirá en qué infraestructura ejecutarlos. Lo ideal es que se ejecuten en la máquina principal donde se trabaja con los INSERT en la base de datos para reducir la latencia.
Con este sistema conseguiremos que toda la infraestructura sea capaz de responder en todo momento y que en a penas un par de minutos y sólo en caso de que alguno de los nodos falle, el sistema se gestione automáticamente para resolver las incidencias, mantener el servicio y que posteriormente se pueda recuperar por el equipo responsable del mismo, teniendo en cuenta que el sistema está en modo incidencia.
En el tiempo que llevamos haciendo pruebas diversas con este sistema la verdad es que la escalabilidad es muy correcta y en los casos en los que ha habido algún tipo de corte en alguno de los centros de datos se ha distribuido el sistema de forma automática en el resto de sistemas, pudiendo recuperar la localización posteriormente gracias a la distribución de los otros puntos.
Sobre este documento
Este documento está regulado por la licencia EUPL v1.2, publicado en WP SysAdmin y creado por Javier Casares. Por favor, si utilizas este contenido en tu sitio web, tu presentación o cualquier material que distribuyas, recuerda hacer una mención a este sitio o a su autor, y teniendo que poner el material que crees bajo licencia EUPL.