Los entornos híbridos, en los que una parte de la infraestructura de la base de datos se encuentra en las instalaciones y otra parte se encuentra en una nube pública, no son infrecuentes. Puede haber diferentes razones para usar dicha configuración:escalabilidad, flexibilidad, alta disponibilidad, recuperación ante desastres. ¿Cómo implementar esta configuración de manera adecuada? Esto puede ser un desafío, ya que debe considerar varias piezas de un rompecabezas que deben encajar. Este blog tiene como objetivo brindarle algunas ideas sobre cómo se vería una configuración de este tipo.
Conectividad
No entraremos en detalles aquí porque hay muchas formas de configurar la conectividad entre su configuración local y la nube pública. Dependerá de la infraestructura que tenga instalada, la nube pública que desee utilizar y muchos otros factores. La gama de opciones puede comenzar con enrutadores habilitados para BGP, a través de VPN de hardware, VPN de software que termina en túneles SSH como una forma de conectar temporalmente su red a las instancias en una nube pública. Lo que es importante, haga lo que haga, el resultado final debe ser una conectividad total y transparente desde su red local a las instancias ubicadas en la nube pública.
Consideraciones de alta disponibilidad
La replicación de MySQL es una excelente forma de crear sistemas de alta disponibilidad, pero tiene importantes limitaciones. Lo principal a considerar es el escritor:solo puede tener un lugar para enviar sus escritos:el maestro. No importa cómo desee diseñar todo el entorno, debe considerar cuidadosamente la ubicación del maestro. Lo más probable es que desee que forme parte del entorno, que contiene los hosts de la aplicación. Consideremos la siguiente configuración:
Tenemos una configuración local con tres nodos MySQL y dos esclavos adicionales ubicado en la nube pública, actuando como un medio de recuperación ante desastres para la empresa, está bastante claro que el nodo grabable debe ubicarse junto con los hosts de aplicaciones en la parte privada de la nube. Queremos mantener la latencia lo más baja posible para las conexiones más importantes.
Este tipo de diseño se centra en la disponibilidad de las bases de datos:si los nodos ubicados en las instalaciones no estarán disponibles, los hosts de aplicaciones pueden conectarse a la parte remota de la configuración:los nodos de la base de datos ubicados en la nube pública. Idealmente, usaría algún tipo de proxy para esto:ProxySQL es una de las soluciones que puede rastrear la topología y reconfigurar según sea necesario en función de la cadena de replicación existente.
Si desea considerar más una configuración activo-activo en la que tiene nodos de aplicación tanto privados como públicos, debe hacer algunos compromisos ya que las escrituras deberán transferirse a través de la WAN, de la nube pública a la privada (o viceversa, si su ubicación principal donde opera en la nube pública).
Nuevamente, ProxySQL es el proxy elegido. Lo que es genial, ProxySQL se puede configurar como un clúster de ProxySQL, lo que garantiza que los cambios de configuración introducidos en un nodo se replicarán en los demás nodos de ProxySQL.
Manejo de fallas
Consideremos un par de escenarios de falla. Antes que nada, debemos tener en cuenta que la replicación asíncrona de MySQL no es compatible con clústeres, por lo tanto, la división de la red es algo que debe manejarse manualmente; será el usuario quien tome la decisión y presione el interruptor para promover uno de los esclavos en el entorno que está disponible. También depende del usuario asegurarse de que el entorno, que ha perdido la conectividad de la red, se comportará como debería y no seguirá funcionando.
Si la parte privada de la nube no está disponible, como mencionamos anteriormente, se requerirá una acción manual para promover a uno de los esclavos a convertirse en un nuevo maestro. Luego, todos los servidores de aplicaciones web restantes ubicados en la nube pública, utilizando ProxySQL local, tendrán su tráfico redirigido al nuevo maestro y todos los esclavos restantes. Por otro lado, dado que perdimos tres de cada cinco nodos de MySQL, queremos ampliar la configuración de la nube pública:ClusterControl puede ayudarlo a agregar nodos adicionales a su clúster de manera eficiente.
Otro escenario podría ser que el escritor se haya bloqueado mientras la conectividad entre nuestra configuración local y la nube pública funciona bien.
En tal escenario, queremos promover a uno de los esclavos para que se convierta en un nuevo maestro. Dependiendo de los requisitos, también podemos querer que el nuevo maestro se promocione entre los nodos en una parte determinada del entorno. ClusterControl tiene la capacidad de incluir en la lista blanca o negra los nodos para la conmutación por error, lo que garantiza que tenga control total sobre el proceso de conmutación por error y que pueda elegir qué nodos se deben considerar como candidatos para un nuevo maestro y en qué orden.
Esperamos que este blog le haya dado una idea de cómo funciona la configuración de la nube híbrida para la replicación de MySQL y cómo puede protegerlo en caso de fallas en la base de datos o en la red.
