19 votos

La arquitectura de alta disponibilidad de MySQL con conmutación automática por error en diversos lugares físicamente

He estado investigando de alta disponibilidad (HA) soluciones para MySQL entre centros de datos.

Para los servidores que se encuentran en el mismo entorno físico, he preferido dual maestro con los latidos del corazón (flotante VIP) usando un enfoque pasivo. El latido del corazón es tanto una conexión en serie, así como una conexión ethernet.

En definitiva, mi objetivo es mantener este mismo nivel de disponibilidad, pero entre los centros de datos. Quiero dinámica de conmutación por error entre ambos centros de datos sin intervención manual y todavía mantener la integridad de los datos.

No sería BGP en la parte superior. Web, grupos en ambas localidades, que tienen el potencial de ruta para las bases de datos entre ambos lados. Si la conexión a Internet en el sitio 1, los clientes de la ruta a través de la página 2, en la Web del clúster y, a continuación, a la base de datos en el sitio 1 si el vínculo entre ambos sitios es todavía.

Con este escenario, debido a la falta de vínculo físico (de serie) es más probable que la posibilidad de dividir el cerebro. Si la WAN que pasó entre ambos sitios, el VIP terminaría en ambos sitios, donde una variedad de desagradable escenarios podrían introducir desync.

Otro posible problema que veo es la dificultad de escala de esta infraestructura a un tercer centro de datos en el futuro.

La capa de red no es un tema. La arquitectura es flexible en esta etapa. De nuevo, mi enfoque es una solución para el mantenimiento de la integridad de los datos así como la conmutación por error automática con la base de datos MySQL. Yo probablemente de diseño que el resto de todo esto.

¿Puede recomendar una solución probada para MySQL HA entre dos físicamente diversos sitios?

Gracias por tomarse el tiempo para leer esto. Estoy deseando leer vuestras recomendaciones.

9voto

MarkR Puntos 2323

Usted se enfrentará a la "TAPA" teorema de problema. Usted no puede tener consistencia, disponibilidad y partición de tolerancia al mismo tiempo.

DRBD / MySQL HA se basa en la replicación sincrónica en el dispositivo de bloque nivel. Esto está bien mientras ambos nodos están disponibles, o si uno sufre una falla temporal, se reinicia etc, luego viene la parte de atrás. Los problemas comienzan cuando usted consigue una partición de red.

Red de particiones es muy probable que cuando se está ejecutando en dos centros de datos. Esencialmente, ninguna de las partes puede distinguir una partición desde el otro nodo falla. El nodo secundario no sabe si debe tomar más de (ha fallado la primaria) o no (el vínculo se ha ido).

Mientras las máquinas están en la misma ubicación, se puede añadir un canal secundario de comunicación (normalmente un cable serie o ethernet cruzado) para conseguir alrededor de este problema - por lo que la secundaria sabe cuando la principal es REALMENTE, y no una partición de red.


El siguiente problema es el rendimiento. Mientras DRBD puede dar decente** rendimiento cuando sus máquinas tienen una conexión de baja latencia (por ejemplo, gigabit ethernet - pero algunas personas usan dedicado redes de alta velocidad), más la latencia de la red, el tiempo que se necesita para la confirmación de una transacción***. Esto es debido a que se necesita esperar a que el servidor secundario (cuando es en línea) para reconocer todas las escrituras antes de decir "OK" para que la aplicación para asegurar la durabilidad de las escrituras.

Si se puede hacer esto en diferentes centros de datos, normalmente se tienen varios milisegundos de latencia, incluso si están cerca.

** Todavía mucho más lento que un decente controlador IO

*** No se pueden usar MyISAM para una alta disponibilidad de DRBD sistema, ya que no se recupera correctamente/ automáticamente a partir de un apagado sucio, que se requiere durante una conmutación por error.

6voto

Kyle Brandt Puntos 50907

Lo siento, este es otro de la red a un lado, pero un pensamiento para abajo en la carretera...

Para el cerebro dividido escenario que usted ha mencionado, usted podría tener enlaces redundantes entre dos sitios así disminuir la probabilidad de que esto ocurra.

3voto

Matt Puntos 6166

¿Qué acerca del uso de una VLAN para atar todos los servidores en los dos (o más) de los centros de datos juntos. Usted podría utilizar la CARPA para la conmutación por error automática. El uso de replicación de base de datos para mantener todo sincronizado.

Si usted es dueño de los centros de datos se puede asegurar que cada centro de datos tiene múltiples WAN uplinks.

3voto

Martin Puntos 311

Su primera etapa se deben actualizar su actual solución de HA a uno que utiliza OpenAIS como la pertenencia al Clúster de la capa: esto le dará una gran flexibilidad, y dado de baja latencia de enlaces entre sitios, podría ser capaz de llegar al otro lado. Marcapasos y RHEL la Agrupación de apoyo a esta.

Automático de centro de datos de conmutación por error, usted realmente necesita un tercero para que actúe como un desempate, de lo contrario sus sitios, no será capaz de distinguir entre los sitios de problemas de enrutamiento de sitio remoto y el fracaso. Microsoft tiene algunos sorprendentemente buena web-moldes que cubre el área:

Windows Server 2008 multi-sitio de la agrupación

Obviamente la tecnología exacta no mapa en el Linux de dominio, pero los conceptos son los mismos.

1voto

automatonic Puntos 2830

Tenga en cuenta que usted probablemente no puede utilizar BGP, como el más pequeño enrutable bloque de 4k, un /22, la buena suerte de conseguir uno. Probablemente una de DNS basado en la solución que se necesita.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: