Es muy común ver bases de datos distribuidas en múltiples ubicaciones geográficas. Un escenario para realizar este tipo de configuración es para la recuperación ante desastres, donde su centro de datos en espera está ubicado en una ubicación separada de su centro de datos principal. También podría ser necesario para que las bases de datos estén ubicadas más cerca de los usuarios.
El principal desafío para lograr esta configuración es diseñar la base de datos de una manera que reduzca la posibilidad de problemas relacionados con la partición de la red.
MariaDB Cluster puede ser una buena opción para construir un entorno de este tipo por varias razones. Nos gustaría discutirlos aquí y también hablar un poco sobre cómo se vería ese entorno.
¿Por qué usar MariaDB Cluster para entornos distribuidos geográficamente?
La primera razón es que MariaDB Cluster puede admitir múltiples escritores. Esto hace que el enrutamiento de escritura sea mucho más fácil de diseñar:simplemente escribe en los nodos MariaDB locales. Por supuesto, dada la replicación síncrona, la latencia afecta el rendimiento de escritura y es posible que vea que sus escrituras se vuelven más lentas si distribuye su clúster demasiado lejos geográficamente. Después de todo, no puedes ignorar las leyes de la física y dicen, al menos por ahora, que incluso la velocidad de la luz en las conexiones de fibra es limitada. Cualquier enrutador agregado además de eso también aumentará la latencia, aunque solo sea por un par de milisegundos.
Segundo, manejo de retrasos en MariaDB Cluster. La replicación asíncrona es un tema de retraso en la replicación:es posible que los esclavos no estén actualizados con los datos si tienen dificultades para aplicar todos los cambios a tiempo. En MariaDB Cluster esto es diferente:el control de flujo es un mecanismo destinado a mantener el clúster sincronizado. Bueno, casi, en algunos casos extremos aún se puede observar un retraso. Estamos hablando aquí de, por lo general, milisegundos, un par de segundos como máximo, mientras que en el cielo de replicación asincrónica es el límite.
Tercero, segmentos. De forma predeterminada, MariaDB CLuster utiliza la comunicación de todos a todos y el nodo envía cada conjunto de escritura a todos los demás nodos del clúster. Este comportamiento se puede cambiar usando segmentos. Los segmentos permiten a los usuarios dividir los clústeres de MariaDB en varias partes. Cada segmento puede contener varios nodos y elige uno de ellos como nodo de retransmisión. Dichos nodos reciben conjuntos de escritura de otros segmentos y los redistribuyen entre los nodos MariaDB locales del segmento. Como resultado, como puede ver en el diagrama anterior, es posible reducir tres veces el tráfico de replicación que pasa por la WAN:solo se envían dos "réplicas" del flujo de replicación a través de la WAN:una por centro de datos en comparación con una por esclavo en replicación asíncrona.
Finalmente, donde MariaDB Cluster realmente brilla es en el manejo de la partición de la red. MariaDB Cluster monitorea constantemente el estado de los nodos en el clúster. Cada nodo intenta conectarse con sus pares e intercambiar el estado del clúster. Si no se puede acceder a un subconjunto de nodos, MariaDB intenta retransmitir la comunicación, por lo que si hay una forma de llegar a esos nodos, se llegará a ellos.
Se puede ver un ejemplo en el diagrama anterior:DC 1 perdió la conectividad con DC2 pero DC2 y DC3 pueden conectarse. En este caso, uno de los nodos en DC3 se utilizará para transmitir datos de DC1 a DC2, lo que garantiza que se pueda mantener la comunicación dentro del clúster.
MariaDB puede realizar acciones en función del estado del clúster. Implementa el quórum:la mayoría de los nodos deben estar disponibles para que el clúster pueda operar. Si el nodo se desconecta del clúster y no puede llegar a ningún otro nodo, dejará de funcionar.
Como se puede ver en el diagrama anterior, hay una pérdida parcial de la comunicación de red en DC1 y el nodo afectado se elimina del clúster, lo que garantiza que la aplicación no accederá a datos obsoletos.
Esto también es cierto a mayor escala. El DC1 cortó todas sus comunicaciones. Como resultado, todo el centro de datos se eliminó del clúster y ninguno de sus nodos atenderá el tráfico. El resto del clúster mantuvo la mayoría (6 de 9 nodos están disponibles) y se reconfiguró para mantener la conexión entre DC 2 y DC3. En el diagrama anterior, asumimos que el escritor llega al nodo en DC2, pero tenga en cuenta que MariaDB es capaz de ejecutarse con varios escritores.
Diseño de un clúster MariaDB distribuido geográficamente
Examinamos algunas de las características que hacen que MariaDB Cluster se adapte bien a los entornos distribuidos geográficamente. Centrémonos ahora un poco en el diseño. Al principio, vamos a explicar cuál es el entorno con el que estamos trabajando. 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 que este blog sea menos complicado, no entraremos en detalles sobre cómo debería verse la conectividad. Asumimos algún tipo de conexión segura y correctamente configurada en todos los centros de datos. Se pueden usar VPN u otras herramientas para implementar eso.
Usaremos MaxScale como equilibrador de carga. MaxScale 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. Las aplicaciones se pueden configurar para conectarse a uno de los nodos locales de MaxScale mediante un algoritmo de turno rotativo. También podemos usar Keepalived y Virtual IP para enrutar el tráfico hacia el único nodo MaxScale, siempre que un solo nodo MaxScale pueda manejar todo el tráfico.
Otra solución posible es colocar MaxScale con los nodos de la aplicación y configurar la aplicación para conectarse al proxy en el host local. Este enfoque funciona bastante bien bajo el supuesto de que es poco probable que MaxScale no esté disponible, pero la aplicación funcionaría correctamente 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 MaxScale como a la aplicación al mismo tiempo.
El diagrama anterior muestra la versión del entorno, donde MaxScale forma granjas proxy - todos los nodos proxy con la misma configuración, equilibrio de carga usando Keepalived, o simplemente turnos rotativos desde la aplicación en todos los nodos de MaxScale. MaxScale está configurado para distribuir la carga de trabajo entre todos los nodos de MariaDB 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.
Conclusión
Como puede ver, MariaDB Cluster se puede usar fácilmente para crear clústeres distribuidos geográficamente que pueden funcionar incluso en todo el mundo. El factor limitante será la latencia de la red. Si es demasiado alto, es posible que deba considerar el uso de clústeres de MariaDB separados conectados mediante replicación asíncrona.
