En el blog anterior de la serie, discutimos los pros y los contras de usar Galera Cluster para crear un clúster distribuido geográficamente. En esta publicación, diseñaremos un clúster distribuido geográficamente basado en Galera y le mostraremos cómo puede implementar todas las piezas necesarias mediante ClusterControl.
Diseño de un clúster de Galera distribuido geográficamente
Comenzaremos explicando el entorno que queremos construir. Utilizaremos tres centros de datos remotos, conectados a través de una red de área amplia (WAN). Cada centro de datos recibirá escrituras de los servidores de aplicaciones locales. Las lecturas también serán solo locales. Esto tiene por objeto evitar el tráfico innecesario que cruza la WAN.
Para esta configuración, la conectividad está en su lugar y asegurada, pero no describiremos exactamente cómo se puede lograr. Existen numerosos métodos para asegurar la conectividad a partir de soluciones de software y hardware patentadas a través de OpenVPN y terminando en túneles SSH.
Usaremos ProxySQL como equilibrador de carga. ProxySQL se implementará localmente en cada centro de datos. También enrutará el tráfico solo a los nodos locales. Los nodos remotos siempre se pueden agregar manualmente y explicaremos los casos en los que esta podría ser una buena solución. La aplicación se puede configurar para conectarse a uno de los nodos ProxySQL locales mediante el algoritmo de turno rotativo. También podemos usar Keepalived y Virtual IP para enrutar el tráfico hacia el único nodo ProxySQL, siempre que un solo nodo ProxySQL pueda manejar todo el tráfico.
Otra solución posible es colocar ProxySQL con nodos de aplicación y configurar la aplicación para conectarse al proxy en el host local. Este enfoque funciona bastante bien bajo la suposición de que es poco probable que ProxySQL no esté disponible pero la aplicación funcione bien en el mismo nodo. Por lo general, lo que vemos es una falla de nodo o una falla de red, lo que afectaría tanto a ProxySQL como a la aplicación al mismo tiempo.
El diagrama anterior muestra la versión del entorno en el que se ubica ProxySQL. el mismo nodo que la aplicación. ProxySQL está configurado para distribuir la carga de trabajo entre todos los nodos de Galera en el centro de datos local. Uno de esos nodos se elegiría como un nodo para enviar las escrituras, mientras que los SELECT se distribuirían en todos los nodos. Tener un nodo de escritor dedicado en un centro de datos ayuda a reducir la cantidad de posibles conflictos de certificación, lo que generalmente conduce a un mejor rendimiento. Para reducir esto aún más, tendríamos que comenzar a enviar el tráfico a través de la conexión WAN, lo cual no es ideal ya que la utilización del ancho de banda aumentaría significativamente. En este momento, con los segmentos en su lugar, solo se envían dos copias del conjunto de escritura a través de los centros de datos, una por DC.
La principal preocupación con las implementaciones distribuidas geográficamente de Galera Cluster es la latencia. Esto es algo que siempre debe probar antes de iniciar el entorno. ¿Estoy bien con el tiempo de compromiso? En cada compromiso, la certificación debe ocurrir, por lo que los conjuntos de escritura deben enviarse y certificarse en todos los nodos del clúster, incluidos los remotos. Es posible que la alta latencia considere que la configuración no es adecuada para su aplicación. En ese caso, puede encontrar varios clústeres de Galera conectados a través de la replicación asíncrona más adecuados. Sin embargo, este sería un tema para otra publicación de blog.
Implementación de un clúster de Galera distribuido geográficamente mediante ClusterControl
Para aclarar las cosas, mostraremos aquí cómo puede verse una implementación. No usaremos la configuración real de varios centros de datos, todo se implementará en un laboratorio local. Suponemos que la latencia es aceptable y que toda la configuración es viable. Lo bueno de ClusterControl es que es independiente de la infraestructura. No importa si los nodos están cerca uno del otro, ubicados en el mismo centro de datos o si los nodos están distribuidos entre múltiples proveedores de nube. Siempre que haya conectividad SSH desde la instancia de ClusterControl a todos los nodos, el proceso de implementación se ve exactamente igual. Es por eso que podemos mostrárselo paso a paso utilizando solo el laboratorio local.
Instalando ClusterControl
Primero, debe instalar ClusterControl. Puedes descargarlo gratis. Después de registrarse, debe acceder a la página con la guía para descargar e instalar ClusterControl. Es tan simple como ejecutar un script de shell. Una vez que haya instalado ClusterControl, se le presentará un formulario para crear un usuario administrativo:
Una vez que lo llene, se le presentará una pantalla de bienvenida y acceso a los asistentes de implementación:
Iremos con la implementación. Esto abrirá un asistente de implementación:
Elegiremos MySQL Galera. Tenemos que pasar los detalles de conectividad SSH:se admite el usuario root o el usuario sudo. En el siguiente paso debemos definir servidores en el clúster.
Vamos a implementar tres nodos en uno de los centros de datos. Entonces podremos extender el clúster, configurando nuevos nodos en diferentes segmentos. Por ahora, todo lo que tenemos que hacer es hacer clic en "Implementar" y ver cómo ClusterControl implementa el clúster de Galera.
Nuestros primeros tres nodos están en funcionamiento, ahora podemos proceder a agregar nodos adicionales en otros centros de datos.
Puede hacerlo desde el menú de acciones, como se muestra en la captura de pantalla anterior .
Aquí podemos agregar nodos adicionales, uno a la vez. Lo que es importante, debe cambiar el segmento de Galera a distinto de cero (0 se usa para los tres nodos iniciales).
Después de un tiempo, terminamos con los nueve nodos, distribuidos en tres segmentos.
Ahora, tenemos que implementar la capa de proxy. Usaremos ProxySQL para eso. Puede implementarlo en ClusterControl a través de Manage -> Load Balancer:
Esto abre un campo de implementación:
Primero, debemos decidir dónde implementar ProxySQL. Usaremos los nodos de Galera existentes, pero puede escribir cualquier cosa en el campo, por lo que es perfectamente posible implementar ProxySQL sobre los nodos de la aplicación. Además, debe pasar las credenciales de acceso para el usuario administrativo y de supervisión.
Luego tenemos que elegir uno de los usuarios existentes en MySQL o crear uno ahora mismo. También queremos asegurarnos de que ProxySQL esté configurado para usar nodos de Galera ubicados solo en el mismo centro de datos.
Cuando tenga un ProxySQL listo en el centro de datos, puede usarlo como fuente de configuración:
Esto debe repetirse para cada servidor de aplicaciones que tenga en todos los centros de datos . Luego, la aplicación debe configurarse para conectarse a la instancia local de ProxySQL, idealmente a través del socket de Unix. Esto viene con el mejor rendimiento y la latencia más baja.
Después de implementar el último ProxySQL, nuestro entorno está listo. Los nodos de aplicación se conectan a ProxySQL local. Cada ProxySQL está configurado para trabajar con los nodos de Galera en el mismo centro de datos:
Conclusión
Esperamos que esta serie de dos partes lo haya ayudado a comprender las fortalezas y debilidades de los clústeres de Galera distribuidos geográficamente y cómo ClusterControl hace que sea muy fácil implementar y administrar dicho clúster.
