Cómo desplegar un clúster tolerante a fallos con disponibilidad continua o alta

Algunas empresas no pueden permitirse tener sus servicios inactivos. En caso de una caída del servidor, un operador celular podría experimentar inactividad en su sistema de facturación, causando la pérdida de conexión para todos sus clientes. La aceptación del impacto potencial de tales situaciones lleva a la idea de siempre tener un plan B.

En este artículo, iluminamos diferentes formas de protección contra fallos del servidor, así como arquitecturas utilizadas para el despliegue de VMmanager Cloud, un panel de control para construir un clúster de Alta Disponibilidad.

Prefacio

La terminología en el área de tolerancia a clústeres varía de un sitio web a otro. Para evitar mezclar diferentes términos y definiciones, delineemos los que se utilizarán en el presente artículo:

• Tolerancia a Fallos (FT) es la capacidad de un sistema para continuar su operación después de la falla de uno de sus componentes.
• Clúster es un grupo de servidores (nodos del clúster) conectados a través de canales de comunicación.
• Clúster Tolerante a Fallos (FTC) es un clúster donde la falla de un servidor no resulta en la completa indisponibilidad de todo el clúster. Las funciones del nodo fallido se reasignan automáticamente entre los nodos restantes.
• Disponibilidad Continua (CA) significa que un usuario puede utilizar el servicio sin experimentar ningún tiempo de espera. No importa cuánto tiempo ha pasado desde que el nodo falló.
• Alta Disponibilidad (HA) significa que un usuario podría experimentar tiempos de espera del servicio en caso de que uno de los nodos se caiga; sin embargo, el sistema se recuperará automáticamente con un tiempo de inactividad mínimo.
• Clúster CA es un clúster de Disponibilidad Continua.
• Clúster HA es un clúster de Alta Disponibilidad.

Supongamos que se requiere desplegar un clúster compuesto por 10 nodos con máquinas virtuales ejecutándose en cada nodo. El objetivo es proteger las máquinas virtuales después de la falla del servidor. Se utilizan servidores de doble CPU para maximizar la densidad de cálculo de los racks.

A primera vista, la opción más atractiva para una empresa es desplegar un clúster de Disponibilidad Continua cuando un servicio aún se proporciona después de que el equipo ha fallado. De hecho, la Disponibilidad Continua es un requisito si necesita mantener la operación de un sistema de facturación o automatizar un proceso de producción continuo. Sin embargo, este enfoque también tiene sus trampas y escollos que se cubren a continuación.

Disponibilidad Continua

La continuidad de un servicio solo es factible si se construye una copia exacta de una máquina física o virtual con este servicio, que esté disponible en cualquier momento. Tal modelo de redundancia se llama 2N. Crear una copia del servidor después de que el equipo haya fallado tomaría tiempo, causando un tiempo de espera del servicio. Además, en este caso, no sería posible recuperar el volcado de RAM del servidor fallido, lo que significa que toda la información contenida allí se habría perdido.

Existen dos métodos utilizados para proporcionar CA: en una capa de hardware y en una capa de software. Centrémonos en cada uno de ellos con mayor detalle.

El método de hardware representa un servidor doble donde todos los componentes están duplicados y los cálculos se ejecutan simultáneamente e independientemente. La sincronización se logra utilizando un nodo dedicado que verifica los resultados provenientes de ambas partes. Si el nodo detecta alguna discrepancia, intenta definir el problema y corregir los errores. Si el error no puede ser corregido, el sistema apaga el módulo fallido.

Stratus, un fabricante de servidores CA, garantiza que el tiempo de inactividad total del sistema no exceda los 32 segundos por año. Tales resultados se pueden lograr utilizando el equipo especial. Según los representantes de Stratus, el costo de un servidor CA con CPUs duales para cada módulo sincronizado es de alrededor de $160,000, dependiendo de las especificaciones. El precio extendido para todo el clúster CA en este caso sería de $1,600,000.

El método de software

La herramienta de software más popular para el despliegue de un clúster de Disponibilidad Continua en el momento del artículo es VMware vSphere. La tecnología de Disponibilidad Continua de este producto se llama Tolerancia a Fallos.

A diferencia del método de hardware, esta tecnología tiene ciertos requisitos, tales como los siguientes:

• CPU en el host físico: - Intel con arquitectura Sandy Bridge (o más reciente). Avoton no es compatible.
• AMD Bulldozer (o más reciente).
• Las máquinas con Tolerancia a Fallos deben estar conectadas a una red de 10 Gb con baja latencia. VMware recomienda encarecidamente utilizar una red dedicada.
• No más de 4 CPUs virtuales por VM.
• No más de 8 CPUs virtuales por host físico.
• No más de 4 máquinas virtuales por host físico.
• Las instantáneas de máquinas virtuales no están disponibles.
• Storage vMotion no está disponible.

La lista completa de limitaciones e incompatibilidades se puede encontrar en la documentación oficial.

La licencia de vSphere se basa en CPUs físicas. El precio comienza en $1750 por licencia + $550 por suscripción anual y soporte. La automatización de la gestión del clúster también requiere VMware vCenter Server, que cuesta más de $8000. Se utiliza el modelo 2N para proporcionar Disponibilidad Continua, por lo que es necesario comprar 10 servidores replicados con licencias para cada uno de ellos para construir un clúster con 10 nodos con máquinas virtuales.

El costo total del software sería 2[ Número de CPUs por servidor ](10[ Número de nodos con máquinas virtuales ]+10[ Número de nodos replicados ])(1750+550)[ Costo de licencia por cada CPU ]+8000[ Costo de VMware vCenter Server ]=$100,000. Todos los precios están redondeados.

Las configuraciones específicas de los nodos no se describen en este artículo, ya que los componentes del servidor siempre difieren dependiendo del propósito del clúster. El equipo de red tampoco se describe, ya que debe ser idéntico en cada caso. Este artículo se centra en aquellos componentes que definitivamente variarían, que es el costo de la licencia.

También es importante mencionar los productos que ya no se desarrollan ni se soportan.

El producto llamado Remus se basa en la virtualización Xen. Es una solución gratuita de código abierto que utiliza la tecnología de micro instantáneas. Desafortunadamente, su documentación no se ha actualizado durante mucho tiempo: La guía de instalación proporciona instrucciones para Ubuntu 12.10, cuyo fin de vida se anunció en 2014. Incluso la búsqueda en Google no encontró ninguna empresa que estuviera utilizando Remus para sus operaciones.

Se hicieron intentos de modificar QEMU para construir clústeres de Disponibilidad Continua sobre esta tecnología. Hay dos proyectos que anunciaron su trabajo en esta dirección.

El primero es Kemari, un producto de código abierto liderado por Yoshiaki Tamura. Este proyecto tenía la intención de utilizar la migración en vivo de QEMU. El último commit se realizó en febrero de 2011, lo que sugiere que el desarrollo llegó a un punto muerto y no se continuará.

El segundo producto es Micro Checkpointing, un proyecto de código abierto fundado por Michael Hines. No se ha encontrado actividad en su registro de cambios durante el último año, lo que se asemeja al proyecto Kemari.

Estos hechos nos permiten concluir que simplemente no hay posibilidad de Disponibilidad Continua en la virtualización KVM hasta la fecha.

A pesar de todas las ventajas de los sistemas de Disponibilidad Continua, existen muchos impedimentos en el camino para desplegar y operar tales soluciones. Sin embargo, en algunos casos, la Tolerancia a Fallos podría ser requerida, pero sin la necesidad de estar continuamente disponible. Tales escenarios permiten utilizar clústeres con Alta Disponibilidad.

Alta Disponibilidad

Un clúster de Alta Disponibilidad proporciona Tolerancia a Fallos al detectar automáticamente si el hardware está caído y posteriormente lanzar el servicio en el nodo disponible.

La Alta Disponibilidad no soporta la sincronización de CPUs lanzadas en nodos y no siempre permite sincronizar discos locales. Con esto en mente, se recomienda ubicar las unidades utilizadas por los nodos en un almacenamiento independiente separado, como el almacenamiento en red.

La razón es clara: El nodo no se puede alcanzar después de su falla, y la información de su dispositivo de almacenamiento no se puede recuperar. El sistema de almacenamiento de datos también debe ser tolerante a fallos, de lo contrario, no hay posibilidad de Alta Disponibilidad. Como resultado, el clúster de Alta Disponibilidad consta de dos sub-clústeres:

• Clúster de computación compuesto por nodos con máquinas virtuales
• Clúster de almacenamiento con discos que son utilizados por nodos de computación.

En este momento, existen las siguientes soluciones utilizadas para implementar clústeres de Alta Disponibilidad con máquinas virtuales en nodos de clúster:

• Heartbeat, versión 1.? con DRBD;
• Pacemaker;
• VMware vSphere;
• Proxmox VE;
• XenServer;
• OpenStack;
• oVirt;
• Red Hat Enterprise Virtualization;
• Windows Server Failover Clustering con el rol de servidor Hyper-V;
• VMmanager Cloud.

Veamos más de cerca VMmanager Cloud.

VMmanager Cloud

VMmanager Cloud es un producto que permite desplegar clústeres de Alta Disponibilidad y utiliza virtualización QEMU-KVM. Esta tecnología fue seleccionada porque se desarrolla y soporta activamente y permite instalar cualquier sistema operativo en una máquina virtual. El producto utiliza Corosync para detectar la disponibilidad del clúster. Si uno de los servidores está caído, VMmanager distribuye sus máquinas virtuales entre los nodos restantes una por una.

En forma simplificada, este mecanismo funciona de la siguiente manera:

1. El sistema identifica el nodo del clúster con el menor número de máquinas virtuales.
2. Verifica si hay suficiente RAM para ubicar la máquina.
3. Si hay suficiente memoria en un nodo para la máquina pertinente, VMmanager crea una nueva máquina virtual en este nodo.
4. Si no hay suficiente memoria, el sistema verifica los otros nodos con más máquinas virtuales.

Probar algunas configuraciones de hardware y consultar a muchos usuarios actuales de VMmanager Cloud identificó que normalmente toma de 45 a 90 segundos distribuir y restaurar la operación de todas las VMs desde el nodo fallido, dependiendo del rendimiento del equipo.

Se recomienda dedicar uno o varios nodos como salvaguarda contra situaciones de emergencia y no desplegar VMs en estos nodos durante la operación rutinaria. Esto minimiza las posibilidades de falta de recursos en los nodos del clúster en vivo para agregar máquinas virtuales desde el nodo fallido. En caso de que solo se utilice un nodo de respaldo, tal modelo de seguridad se llama N+1.

VMmanager Cloud soporta los siguientes tipos de almacenamiento: sistema de archivos, LVM, LVM de red, iSCSI y Ceph [en particular RBD (Dispositivo de Bloque RADOS), una de las implementaciones de Ceph]. Los últimos tres se utilizan para Alta Disponibilidad.

Una licencia de por vida para diez nodos operativos y un nodo de respaldo cuesta €3520, o $3865 hasta la fecha (una licencia cuesta €320 por nodo independientemente del número de CPU). La licencia incluye un año de actualizaciones gratuitas; a partir del segundo año, las actualizaciones se proporcionan bajo un modelo de suscripción al precio de €880 por año para todo el clúster.

Veamos cómo se ha utilizado VMmanager Cloud para el despliegue de clústeres de Alta Disponibilidad.

FirstByte

FirstByte comenzó a proporcionar alojamiento en la nube en febrero de 2016. Inicialmente, su clúster se construyó sobre OpenStack; sin embargo, la falta de especialistas para este sistema en términos de disponibilidad y costo los impulsó a buscar una solución alternativa. El nuevo sistema para construir un clúster de Alta Disponibilidad debía cumplir con los siguientes requisitos:

1. Capacidad para desplegar máquinas virtuales KVM.
2. Integración con Ceph.
3. Integración con un sistema de facturación para ofrecer los servicios existentes.
4. Costo de licencia asequible.
5. Soporte del desarrollador de software.

VMmanager Cloud cumplió con todos los requisitos.

Características distintivas del clúster de FirstByte:

• La transferencia de datos se basa en tecnología Ethernet y equipos Cisco.
• El enrutamiento se realiza utilizando Cisco ASR9001. El clúster utiliza alrededor de 50000 direcciones IPv6.
• La velocidad de enlace entre nodos de computación y conmutadores es de 10 Gbps.
• La velocidad de transferencia de datos entre conmutadores y nodos de almacenamiento es de 20 Gbps, con dos canales combinados de 10 Gbps cada uno.
• Se utiliza un enlace separado de 20 Gbps entre racks con nodos de almacenamiento para replicación.
• Se instalan discos SAS en combinación con SSDs en todos los nodos de almacenamiento.
• El tipo de almacenamiento es RBD.

El diseño del sistema se presenta a continuación:

Tal configuración funciona para alojar sitios web populares, servidores de juegos y bases de datos con carga superior a la media.

FirstVDS

FirstVDS proporciona los servicios de un clúster tolerante a fallos que se inició en septiembre de 2015.

Se eligió VMmanager Cloud para este clúster debido a los siguientes factores:

1. Sólida experiencia en el uso de paneles de control ISPsystem.
2. Integración con BILLmanager por defecto.
3. Alta calidad del soporte técnico.
4. Integración con Ceph.

Su clúster tiene las siguientes características:

• La transferencia de datos se basa en una red Infiniband con velocidad de conexión de 56 Gbps;
• La red Infiniband se construye sobre equipos Mellanox;
• Los nodos de almacenamiento tienen unidades SSD;
• El tipo de almacenamiento es RBD.

El sistema se puede distribuir de la siguiente manera:

En caso de falla de la red Infiniband, la conexión entre el almacenamiento de discos de VM y los servidores de computación se establece a través de la red Ethernet desplegada en equipos Juniper. La nueva conexión se establece automáticamente.

Debido a la alta velocidad de comunicación con el almacenamiento, este clúster funciona perfectamente para alojar sitios web con tráfico ultralto, transmisión de video y contenido, así como grandes datos.

Conclusión

Resumamos los hallazgos clave del artículo.

El clúster de Disponibilidad Continua es imprescindible cuando cada segundo de inactividad trae pérdidas sustanciales. Si se permite tener una interrupción de 5 minutos mientras se despliegan máquinas virtuales en un nodo de respaldo, el clúster de Alta Disponibilidad puede ser una buena opción que reduce los costos de hardware y software.

También es importante recordar que la única forma de lograr Tolerancia a Fallos es la excesividad. Asegúrese de replicar sus servidores, equipos de comunicación de datos y enlaces, canales de acceso a Internet y energía. Replicar todo lo que pueda. Tales medidas hacen posible eliminar cuellos de botella y puntos de falla potenciales que pueden causar la inactividad de todo el sistema. Al tomar las medidas anteriores, puede estar seguro de que tiene un clúster tolerante a fallos resistente a fallos.

Si cree que el modelo de Alta Disponibilidad se ajusta a sus requisitos y que VMmanager Cloud es una buena herramienta para realizarlo, consulte el manual de instalación y la documentación para aprender más sobre el sistema. Le deseo operaciones continuas y sin fallos!**