He estado investigando soluciones de alta disponibilidad (HA) para MySQL entre centros de datos.
Para los servidores ubicados en el mismo entorno físico, he preferido un maestro dual con latido (VIP flotante) usando un enfoque pasivo activo. El latido es a través de una conexión en serie, así como una conexión a Ethernet.
En última instancia, mi objetivo es mantener este mismo nivel de disponibilidad pero entre centros de datos. Quiero realizar una conmutación por error dinámica entre ambos centros de datos sin intervención manual y aún así mantener la integridad de los datos.
Habría BGP en la parte superior. Clústeres web en ambas ubicaciones, lo que podría enrutar a las bases de datos entre ambos lados. Si la conexión a Internet se cortara en el sitio 1, los clientes se enrutarían a través del sitio 2, al clúster web y luego a la base de datos en el sitio 1 si el enlace entre ambos sitios todavía está activo.
Con este escenario, debido a la falta de enlace físico (en serie), existe una mayor probabilidad de fractura cerebral. Si la WAN cayera entre ambos sitios, el VIP terminaría en ambos sitios, donde una variedad de escenarios desagradables podría introducir la desincronización.
Otro problema potencial que veo es la dificultad de escalar esta infraestructura a un tercer centro de datos en el futuro.
La capa de red no es un foco. La arquitectura es flexible en esta etapa. Nuevamente, mi enfoque es una solución para mantener la integridad de los datos, así como la conmutación por error automática con las bases de datos MySQL. Probablemente diseñaría el resto en torno a esto.
¿Puede recomendar una solución probada para MySQL HA entre dos sitios físicamente diversos?
Gracias por tomarse el tiempo de leer esto. Espero leer sus recomendaciones.
Respuestas:
Te enfrentarás al problema del teorema "CAP". No puede tener consistencia, disponibilidad y tolerancia de partición al mismo tiempo.
DRBD / MySQL HA se basa en la replicación síncrona a nivel de dispositivo de bloque. Esto está bien mientras ambos nodos están disponibles, o si uno sufre una falla temporal, se reinicia, etc., luego vuelve. Los problemas comienzan cuando obtiene una partición de red.
Las particiones de red son extremadamente probables cuando se ejecuta en dos centros de datos. Esencialmente, ninguna de las partes puede distinguir una partición del otro nodo que falla. El nodo secundario no sabe si debe hacerse cargo (el primario ha fallado) o no (el enlace se ha ido).
Mientras sus máquinas están en la misma ubicación, puede agregar un canal secundario de comunicación (generalmente un cable serie o un crossover ethernet) para solucionar este problema, de modo que el secundario sepa cuándo el primario está GENUINAMENTE inactivo, y no es una partición de red .
El siguiente problema es el rendimiento. Si bien DRBD puede brindar un rendimiento decente ** cuando sus máquinas tienen una conexión de baja latencia (por ejemplo, gigabit ethernet, pero algunas personas usan redes dedicadas de alta velocidad), cuanto más latencia tenga la red, más tiempo llevará realizar una transacción *** . Esto se debe a que necesita esperar al servidor secundario (cuando está en línea) para reconocer todas las escrituras antes de decir "OK" a la aplicación para garantizar la durabilidad de las escrituras.
Si hace esto en diferentes centros de datos, normalmente tiene varios más de milisegundos de latencia, incluso si están cerca.
** Todavía mucho más lento que un controlador de E / S local decente
*** No puede usar MyISAM para un sistema DRBD de alta disponibilidad porque no se recupera de manera adecuada / automática de un apagado no limpio, que se requiere durante una conmutación por error.
fuente
¿Qué pasa con el uso de una VLAN para unir todos los servidores en los dos (o más) centros de datos? Luego puede usar CARP para la conmutación por error automática. Use la replicación de la base de datos para mantener todo sincronizado.
Si posee los centros de datos, puede asegurarse de que cada centro de datos tenga múltiples enlaces ascendentes WAN.
fuente
Su primera etapa debe ser actualizar su solución HA actual a una que use OpenAIS como la capa de membresía del Clúster: esto le dará mucha flexibilidad, y dado que los enlaces de baja latencia entre los sitios, podrían llegar a través. PaceMaker y RHEL Clustering lo respaldan.
Para la conmutación por error automática del centro de datos, realmente necesita un tercer sitio que actúe como un factor decisivo, de lo contrario, sus sitios no podrán distinguir entre problemas de enrutamiento entre sitios y fallas de sitios remotos. Microsoft tiene algunos webcasts sorprendentemente buenos que cubren el área:
Agrupación multisitio de Windows Server 2008
Obviamente, la tecnología exacta no se asigna al dominio de Linux, pero los conceptos son los mismos.
fuente
Lo siento, esta es otra red aparte, pero un pensamiento para el futuro ...
Para el escenario de cerebro dividido que mencionó, también podría tener enlaces redundantes entre dos sitios para disminuir la posibilidad de que esto suceda.
fuente
Tenga en cuenta que probablemente no pueda usar BGP, ya que el bloque enrutable más pequeño es 4k, a / 22, buena suerte obteniendo uno. Probablemente se necesita una solución basada en DNS.
fuente
Dar una respuesta correcta puede ser difícil dependiendo de la cantidad de datos que tenga, la cantidad de servidores en los que desea incluir esto, etc. Dicho esto, mi respuesta podría no ser una, o al menos la que está buscando.
No hay una solución comprobada para sitios múltiples con MySQL. Pero hay una solución que funciona. Como algunos señalaron, sí DRDB funciona bien pero tiene su límite o posible problema dependiendo de su configuración.
¿Alguna vez necesitará un tercer sitio (otro centro de datos)? Si es así, ¿cuánto tiempo y dinero tendrá para hacer esto?
Considerando cada vez que agrega un servidor maestro / esclavo / dns, copias de seguridad, ... agrega un servidor para administrar, ¿cuál es su capacidad de administración en términos de número de servidores? Si puede definir este número, es posible que tenga que descartar algunas posibles soluciones y trabajar hacia aquellas que se ajusten a sus números para que la administración no se convierta en un cuello de botella.
Teniendo en cuenta que los centros de datos no caen con frecuencia, múltiples sitios significan equilibrio de carga y algo de piratería de DNS, ¿va a estar en el mismo centro de datos? Si es así, si un centro de datos deja de funcionar por cualquier razón, se encontrará con problemas porque una buena parte de su DNS y equilibrio de carga estarán en este centro de datos.
Por lo tanto, es posible que tenga que planificar esa situación de cerebro dividido. Para cada configuración posible, la forma de resolver una situación de escupir cerebro es diferente. Además, cada solución toma X cantidad de tiempo.
También puede ser mucho más fácil planificar el uso de 3 centros de datos desde el principio. No soy un experto en MySQL, pero he oído que en producción era más fácil tener 3 Masters que 2 si alguna vez te encuentras con problemas.
Una cosa que puede ayudarlo es el servicio de equilibrio de carga ofrecido por algunos proveedores de redes como Zeus, eche un vistazo aquí. Probablemente haya muchos más ofreciendo este tipo de servicio. Estoy seguro de que tiene un precio, pero a veces te permite reducir otras cosas.
¡Buena suerte!
fuente
DRBD no es una solución recomendada para centros de datos remotos, ya que requiere un ancho de banda que puede afectar la velocidad de su base de datos y la replicación. La solución recomendada es Master - Master Replication. El único problema con esto es que los campos de incremento automático deben escalonarse.
Si necesita una verdadera solución de alta disponibilidad para MySQL, debería utilizar MySQL Cluster porque DRBD no puede brindarle integridad de datos en caso de fallas.
fuente
He encontrado publicaciones de blog sobre las opciones disponibles en MySQL y sus ventajas y desventajas. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html
fuente
Superar la falta de un cable serie es realmente fácil, usa una cosa de la edad oscura llamada módem: tiene uno en cada extremo y luego ejecuta Heartbeat sobre el enlace PPP. También puede usar frame relay. Ambos métodos solucionarán cualquier preocupación que tenga con las rutas redundantes de capa 1/2.
Sin embargo, dicho esto: DRBD que se ejecuta sobre cualquier enlace con una latencia de más de 300 µs (tenga en cuenta que es de 0.3 ms) se vuelve ridículo muy rápidamente.
Sería más útil usar la replicación estándar de MySQL y LinuxHA sobre PPP y eth para hacer las fallas.
Al menos eso es lo que he hecho por los clientes en el pasado.
fuente