¡Hola, Habr!
Después de las vacaciones de Año Nuevo, relanzamos una nube a prueba de desastres basada en dos sitios. Hoy le diremos cómo funciona y le mostraremos qué sucede con las máquinas virtuales del cliente cuando los elementos individuales del clúster fallan y todo el sitio falla (spoiler: todo está bien para ellos).
Sistema de almacenamiento en la nube resistente a desastres en el sitio OST.
Que hay dentro
Debajo del capó, el clúster cuenta con servidores Cisco UCS con un hipervisor VMware ESXi, dos sistemas de almacenamiento INFINIDAT InfiniBox F2240, equipos de red Cisco Nexus y conmutadores Brocade SAN. El clúster está dividido en dos sitios: OST y NORD, es decir, cada centro de datos tiene un conjunto de equipos idéntico. En realidad, esto es lo que lo hace resistente a los desastres.
Dentro de un sitio, los elementos principales también están duplicados (hosts, conmutadores SAN, redes).
Los dos sitios están conectados por rutas dedicadas de fibra óptica, también reservadas.
Algunas palabras sobre los sistemas de almacenamiento. Creamos la primera versión de una nube a prueba de desastres en NetApp. Aquí elegimos INFINIDAT y este es el motivo:
- Opción de replicación Activo-Activo. Permite que la máquina virtual permanezca operativa incluso si uno de los sistemas de almacenamiento falla por completo. Te contaré más sobre la replicación más adelante.
- Tres controladores de disco para aumentar la tolerancia a fallas del sistema. Generalmente son dos.
- Solución lista. Recibimos un rack premontado que solo hay que conectarlo a la red y configurarlo.
- Soporte técnico atento. Los ingenieros de INFINIDAT analizan constantemente los registros y eventos del sistema de almacenamiento, instalan nuevas versiones de firmware y ayudan con la configuración.
Aquí hay algunas fotos del desembalaje:
Cómo funciona
La nube ya es tolerante a fallos en sí misma. Protege al cliente de fallos únicos de hardware y software. La resistencia a desastres ayudará a proteger contra fallas masivas dentro de un sitio: por ejemplo, falla de un sistema de almacenamiento (o un clúster SDS, lo cual ocurre con bastante frecuencia 🙂), errores masivos en una red de almacenamiento, etc. Bueno, y lo más importante: una nube de este tipo salva cuando un sitio completo se vuelve inaccesible debido a un incendio, un apagón, una toma de control de un asaltante o un aterrizaje alienígena.
En todos estos casos, las máquinas virtuales del cliente continúan funcionando y he aquí por qué.
El diseño del clúster está pensado para que cualquier host ESXi con máquinas virtuales cliente pueda acceder a cualquiera de los dos sistemas de almacenamiento. Si el sistema de almacenamiento en el sitio OST falla, las máquinas virtuales seguirán funcionando: los hosts en los que se ejecutan accederán al sistema de almacenamiento en NORD para obtener datos.
Así es como se ve el diagrama de conexión en un clúster.
Esto es posible debido al hecho de que se configura un enlace entre conmutadores entre las estructuras SAN de los dos sitios: el conmutador SAN OST de la estructura A está conectado al conmutador SAN NORD de la estructura A y de manera similar para los conmutadores SAN de la estructura B.
Bueno, para que todas estas complejidades de las fábricas SAN tengan sentido, la replicación Activo-Activo se configura entre los dos sistemas de almacenamiento: la información se escribe casi simultáneamente en los sistemas de almacenamiento local y remoto, RPO = 0. Resulta que los datos originales se almacenan en un sistema de almacenamiento y su réplica se almacena en el otro. Los datos se replican a nivel de volúmenes de almacenamiento y los datos de la VM (sus discos, archivo de configuración, archivo de intercambio, etc.) se almacenan en ellos.
El host ESXi ve el volumen principal y su réplica como un dispositivo de disco (dispositivo de almacenamiento). Hay 24 rutas desde el host ESXi a cada dispositivo de disco:
12 rutas lo conectan al sistema de almacenamiento local (rutas óptimas) y las 12 restantes al sistema de almacenamiento remoto (rutas no óptimas). En una situación normal, ESXi accede a los datos del sistema de almacenamiento local utilizando rutas "óptimas". Cuando este sistema de almacenamiento falla, ESXi pierde las rutas óptimas y cambia a rutas "no óptimas". Así es como se ve en el diagrama.
Esquema de un cluster a prueba de desastres.
Todas las redes de clientes están conectadas a ambos sitios a través de una estructura de red común. Cada sitio ejecuta un Provider Edge (PE), en el que terminan las redes del cliente. Los PE están unidos en un grupo común. Si un PE falla en un sitio, todo el tráfico se redirige al segundo sitio. Gracias a esto, las máquinas virtuales del sitio que se quedaron sin PE permanecen accesibles a través de la red para el cliente.
Veamos ahora qué sucederá con las máquinas virtuales del cliente durante varios fallos. Comencemos con las opciones más fáciles y terminemos con las más graves: el fallo de todo el sitio. En los ejemplos, la plataforma principal será OST y la plataforma de respaldo, con réplicas de datos, será NORD.
¿Qué sucede con la máquina virtual del cliente si...?
El enlace de replicación falla. Se detiene la replicación entre los sistemas de almacenamiento de los dos sitios.
ESXi solo funcionará con dispositivos de disco locales (a través de rutas óptimas).
Las máquinas virtuales siguen funcionando.
El ISL (enlace entre conmutadores) se rompe. El caso es poco probable. A menos que algún excavador loco excave varias rutas ópticas a la vez, que discurren por rutas independientes y llegan a los sitios a través de diferentes entradas. Pero de todos modos. En este caso, los hosts ESXi pierden la mitad de las rutas y solo pueden acceder a sus sistemas de almacenamiento locales. Se recopilan réplicas, pero los hosts no podrán acceder a ellas.
Las máquinas virtuales funcionan con normalidad.
El conmutador SAN falla en uno de los sitios. Los hosts ESXi pierden algunas de las rutas al sistema de almacenamiento. En este caso, los hosts en el sitio donde falló el conmutador funcionarán solo a través de uno de sus HBA.
Las máquinas virtuales siguen funcionando con normalidad.
Todos los conmutadores SAN en uno de los sitios fallan. Digamos que ocurrió tal desastre en el sitio OST. En este caso, los hosts ESXi de este sitio perderán todas las rutas a sus dispositivos de disco. Entra en juego el mecanismo estándar de VMware vSphere HA: reiniciará todas las máquinas virtuales del sitio OST en NORD en un máximo de 140 segundos.
Las máquinas virtuales que se ejecutan en los hosts del sitio NORD funcionan con normalidad.
El host ESXi falla en un sitio. Aquí el mecanismo de vSphere HA vuelve a funcionar: las máquinas virtuales del host fallido se reinician en otros hosts, en el mismo sitio o en un sitio remoto. El tiempo de reinicio de la máquina virtual es de hasta 1 minuto.
Si todos los hosts ESXi en el sitio OST fallan, no hay opciones: las VM se reinician en otro. El tiempo de reinicio es el mismo.
El sistema de almacenamiento falla en un sitio. Digamos que el sistema de almacenamiento falla en el sitio OST. Luego, los hosts ESXi del sitio OST cambian para trabajar con réplicas de almacenamiento en NORD. Después de que el sistema de almacenamiento fallido vuelva al servicio, se producirá una replicación forzada y los hosts ESXi OST comenzarán nuevamente a acceder al sistema de almacenamiento local.
Las máquinas virtuales han estado funcionando con normalidad todo este tiempo.
Uno de los sitios falla. En este caso, todas las máquinas virtuales se reiniciarán en el sitio de respaldo mediante el mecanismo de vSphere HA. El tiempo de reinicio de la máquina virtual es de 140 segundos. En este caso, todas las configuraciones de red de la máquina virtual se guardarán y el cliente permanecerá accesible a través de la red.
Para garantizar que el reinicio de las máquinas en el sitio de respaldo se realice sin problemas, cada sitio está lleno solo hasta la mitad. La segunda mitad es una reserva en caso de que todas las máquinas virtuales se muevan desde el segundo sitio dañado.
Una nube resistente a desastres basada en dos centros de datos protege contra tales fallas.
Este placer no es barato, ya que, además de los recursos principales, se necesita una reserva en el segundo sitio. Por lo tanto, los servicios críticos para el negocio se colocan en dicha nube, cuyo tiempo de inactividad a largo plazo causa grandes pérdidas financieras y de reputación, o si el sistema de información está sujeto a requisitos de resiliencia ante desastres por parte de los reguladores o regulaciones internas de la empresa.
Fuentes:
Fuente: habr.com