Alta disponibilidad en servidores virtualizados: guía completa

Informatec Digital » Recursos » Alta disponibilidad en servidores virtualizados: guía completa

La alta disponibilidad en servidores virtualizados se ha convertido en un requisito básico para cualquier organización que no puede permitirse caídas de servicio, ni siquiera de unos pocos minutos. Hablamos de asegurar que tus máquinas virtuales, aplicaciones y datos sigan accesibles aunque falle un servidor físico, un disco, la red o incluso un CPD completo. No es solo cuestión de tener copias de seguridad, sino de mantener el servicio en marcha pase lo que pase.

Cuando mezclamos virtualización, clústeres, almacenamiento y recuperación ante desastres, aparecen muchas tecnologías (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, réplicas, etc.) y no siempre está claro qué elegir ni cómo encajarlo todo. En este artículo se hace un repaso a fondo de las principales opciones y enfoques: desde los clústeres tradicionales con almacenamiento compartido hasta soluciones modernas basadas en replicación en tiempo real entre nodos, pasando por casos concretos con Red Hat, Microsoft Hyper-V, QNAP y arquitecturas HA-DAS.

Conceptos básicos de alta disponibilidad en entornos virtualizados

En un entorno virtualizado, la alta disponibilidad (HA) implica que las VMs sigan accesibles aunque fallen uno o varios componentes del sistema (servidores, discos, controladoras, red, alimentación, etc.). No es lo mismo que la recuperación ante desastres (DR): la HA busca tiempo de inactividad mínimo o casi nulo, mientras que la DR suele aceptar cierto downtime para restaurar servicios desde una copia.

Para conseguir ese comportamiento, se combinan varias piezas: redundancia de hardware, software de clúster, almacenamiento tolerante a fallos y mecanismos de monitorización y conmutación por error. El objetivo es evitar puntos únicos de fallo: si se rompe algo, otra pieza entra en acción sin intervención manual (o con la mínima posible).

En el mundo de la virtualización esto se traduce normalmente en disponer de múltiples hosts físicos que comparten o replican el almacenamiento, y un sistema que vigila el estado de los nodos y de las VMs. Cuando un host cae, las máquinas virtuales se arrancan en otro host, idealmente sin que el usuario lo note o con una interrupción muy breve.

Es importante diferenciar también entre soluciones pensadas para entornos “tipo nube” elásticos y plataformas de HA clásicas. Ciertos productos de clúster tienen una configuración relativamente estática y un número máximo de nodos relativamente bajo, por lo que no son adecuados para montarte un cloud masivo, aunque sí son excelentes para proteger un conjunto de servicios críticos bien definidos.

En un entorno cloud o híbrido conviene revisar estrategias específicas para migración y continuidad: por ejemplo, migración a la nube puede ser parte de la estrategia de recuperación ante desastres, pero no sustituye a la HA local.

Alta disponibilidad en Red Hat Enterprise Linux y plataformas KVM/Xen

El ecosistema de Red Hat ofrece varias opciones para proteger máquinas virtuales mediante clústeres y complementos de alta disponibilidad. En versiones como Red Hat Enterprise Linux 5 y 6 se soportan distintas combinaciones de hipervisores y add-ons de clúster.

En RHEL 5 se soportan dos plataformas de virtualización: Xen (desde RHEL 5.0) y KVM (desde RHEL 5.4). El add-on RHEL 5 Advanced Platform (AP) Cluster permite gestionar tanto VMs Xen como KVM como recursos de clúster, de forma que la infraestructura de alta disponibilidad del host es la que controla el arranque, parada y failover de las máquinas virtuales entre nodos.

Con RHEL 6 el soporte de virtualización se simplifica: solo KVM está soportado como hipervisor. Sin embargo, el complemento de Alta Disponibilidad de RHEL 6 sigue permitiendo tratar las máquinas virtuales KVM como recursos de clúster gestionados por la infraestructura de HA del host. El gestor de recursos de clúster (rgmanager, en las versiones clásicas) se encarga de monitorizar los nodos y mover los huéspedes entre servidores físicos cuando se detecta un fallo.

Este enfoque suele denominarse “RHEL Cluster/HA ejecutándose en hosts físicos que actúan como plataforma de virtualización”. El propio clúster de RHEL es el que dirige dónde se ejecuta cada VM y actúa en caso de caída de un nodo, garantizando que las máquinas virtuales configuradas como críticas se reinicien en un host sano.

Un aspecto interesante es que, desde el punto de vista del clúster, no importa tanto el sistema operativo huésped de la VM. Cualquier invitado compatible con Xen o KVM en RHEL puede tratarse como máquina virtual altamente disponible: distintas versiones de RHEL (3, 4, 5, etc.) y varias ediciones de Microsoft Windows, siempre que estén soportadas por el hipervisor. Eso da bastante flexibilidad a la hora de proteger entornos mixtos.

Ahora bien, la propia Red Hat recomienda tener cuidado al elegir entre usar RHEL High Availability Add-on o plataformas de virtualización más completas como Red Hat Enterprise Virtualization (RHEV) para proporcionar HA de VMs. Ambas ofrecen funcionalidad de alta disponibilidad, pero los casos de uso son distintos y hay que valorar el tamaño del entorno y el modelo de operación.

Cuándo usar RHEL HA frente a RHEV para alta disponibilidad

A la hora de decidir si conviene RHEL HA Add-on o una plataforma como RHEV para proteger máquinas virtuales, uno de los criterios clave es el número de hosts físicos y el tipo de uso que se va a dar al entorno virtualizado.

El add-on de alta disponibilidad de RHEL está pensado para clústeres relativamente pequeños y con configuración estática. Tradicionalmente, estos clústeres tienen un límite máximo de unos 16 nodos físicos, lo que es suficiente para muchos entornos corporativos pero no encaja bien con arquitecturas tipo cloud con decenas o cientos de hosts cambiando constantemente.

Por ello, la propia documentación de Red Hat señala que no se recomienda usar exclusivamente RHEL HA para construir infraestructuras similares a nube, precisamente por esa naturaleza estática y por el límite de recuento de nodos. Para escenarios cloud, tiene más sentido recurrir a plataformas específicamente pensadas para ese modelo, con gestores de recursos más elásticos y escalables.

En cambio, si el objetivo es proteger un número moderado de VMs críticas en un conjunto de hosts bien definido, el add-on de HA de RHEL es una solución sólida: se integra bien con el sistema operativo, se apoya en tecnologías de clúster maduras y proporciona la lógica necesaria para vigilar y mover VMs en caso de fallo.

En cualquier caso, es recomendable revisar la documentación más reciente de RHEL sobre sistemas operativos invitados soportados y combinaciones de hipervisor y clúster, porque el soporte evoluciona con cada lanzamiento y es importante ceñirse a las matrices oficiales.

Alta disponibilidad en Hyper-V: clústeres, réplicas y migración en vivo

En entornos Microsoft, la alta disponibilidad se basa fundamentalmente en las prestaciones de Hyper-V combinadas con Failover Clustering de Windows Server. El objetivo es tener acceso consistente a las máquinas virtuales incluso si hay fallos de hardware, problemas en la red o errores de software.

La pieza central son los clústeres de conmutación por error de Hyper-V. Un clúster de este tipo es un conjunto de servidores (nodos) que comparten almacenamiento y trabajan de forma coordinada: si un nodo se cae, las VMs que tenía se arrancan automáticamente en otro nodo del clúster. Todo ello se apoya en tecnologías de disco compartido y comunicaciones internas específicas.

Para que esto funcione, es usual que los nodos compartan almacenamiento mediante una SAN (Storage Area Network) o un servidor de archivos de escalabilidad horizontal (SOFS). Sobre esa capa se crean los Cluster Shared Volumes (CSV), que permiten a todos los nodos acceder simultáneamente a los mismos discos donde residen los ficheros de las máquinas virtuales.

Los nodos, además, se comunican por una red dedicada conocida como latido del clúster (cluster heartbeat). Esta red está separada de la red de datos de producción y sirve para que cada servidor notifique que está vivo. Si el clúster deja de recibir heartbeats de un nodo, se considera que ha fallado y se inician las acciones de conmutación por error.

Otro elemento fundamental es la configuración de quórum. El quórum define cuántos votos (nodos o testigos externos) deben estar activos para que el clúster siga funcionando. Esto evita escenarios de “split brain” o “cerebro dividido”, donde grupos de nodos aislados crean que son el clúster principal y provoquen corrupción de datos. Elegir bien el modelo de quórum (nodos, disco testigo, file share witness, etc.) es clave para la estabilidad.

Sobre esta base, Hyper-V aprovecha las capacidades del clúster para habilitar migraciones en vivo de máquinas virtuales entre nodos con tiempo de inactividad mínimo. Durante una operación de mantenimiento o para rebalancear carga, una VM puede pasar de un host a otro sin cortar el servicio, moviendo memoria, estado y conexiones activas de forma transparente.

Si, en lugar de mantenimiento planificado, se produce un fallo real de hardware o software en un nodo, el clúster ejecuta una conmutación por error automática. Las máquinas virtuales que se ejecutaban allí se levantan en otro host con acceso al mismo almacenamiento compartido. La interrupción es mayor que en una migración en vivo (hay que apagar/encender la VM), pero se mantiene la continuidad del servicio con la mínima intervención humana.

Réplica de Hyper-V y migración en vivo “Shared Nothing”

Además del clúster clásico con SAN, Hyper-V incorpora otras tecnologías enfocadas tanto a la alta disponibilidad como a la recuperación ante desastres, destacando Hyper-V Replica y la migración en vivo sin almacenamiento compartido.

La Réplica de Hyper-V es una función de replicación asincrónica de máquinas virtuales entre un host principal y uno o varios hosts de réplica, normalmente ubicados en otro sitio o CPD. Cada cierto intervalo, se envían cambios a la VM de destino, creando puntos de recuperación que permiten recuperar la VM en un estado reciente si el sitio principal sufre un desastre.

Este mecanismo cuenta con un agente de réplicas de Hyper-V que coordina el tráfico de replicación, gestiona los puntos de recuperación y centraliza las operaciones de conmutación por error. Permite realizar tanto conmutaciones planificadas (por ejemplo, para mover la producción a otro centro) como no planificadas (cuando se cae el sitio principal inesperadamente).

Por su naturaleza asincrónica, la réplica está más orientada a DR que a HA “casi cero downtime”. Después de un incidente, hay que iniciar el failover sobre la VM de réplica y, aunque el proceso es bastante ágil, implica cierto tiempo de inactividad y posible pérdida de los últimos segundos o minutos de datos, dependiendo del intervalo de replicación configurado.

En paralelo, Hyper-V ofrece la migración en vivo de Shared Nothing, que permite mover una VM entre hosts que no comparten almacenamiento. En este modelo, cada host tiene su propio almacenamiento local, pero la migración en vivo copia de forma transparente los discos de la máquina virtual al destino mientras la VM sigue online, para después conmutar la ejecución al nuevo servidor.

Esta funcionalidad resulta especialmente útil en entornos sin SAN o sin infraestructura de almacenamiento compartido, reduciendo el coste de entrada para pymes o escenarios donde no se quiere mantener una red de almacenamiento dedicada. Permite, por ejemplo, reorganizar hosts o migrar a hardware nuevo con impacto mínimo, sin necesidad de parar máquinas.

La combinación de estas tecnologías (clústeres de conmutación por error, CSV, migración en vivo con o sin almacenamiento compartido y réplica de Hyper-V) proporciona un abanico amplio de opciones para diseñar estrategias de continuidad de negocio y tolerancia a fallos adaptadas a distintos presupuestos y niveles de exigencia.

Soluciones de alta disponibilidad con HA-DAS y Windows Server

Más allá de los entornos con grandes SAN, existen arquitecturas pensadas para alta disponibilidad en sistemas de almacenamiento directamente conectados a servidores (HA-DAS). Estas soluciones sacan partido de Windows Server (por ejemplo, 2012) y de controladoras RAID/HBA avanzadas para ofrecer clústeres en alta disponibilidad sin necesidad de montar una SAN iSCSI o FC tradicional.

En este enfoque, se utilizan dos nodos en clúster HA con almacenamiento compartido tipo JBOD (chasis de discos “just a bunch of disks” sin inteligencia propia). El JBOD se conecta a ambos servidores mediante controladoras Host RAID HBA redundantes, de forma que cada nodo ve el mismo conjunto de discos y puede acceder al mismo RAID de manera simultánea.

Estas soluciones pueden alcanzar capacidades de hasta 180 TB en el chasis compartido, trabajando con discos magnéticos o SSD hot-swap en diferentes niveles RAID. Las controladoras RAID suelen incorporar 1 GB de caché cada una, con la caché replicada en espejo entre controladoras para mantener coherencia y mejorar rendimiento, y protección de caché basada en supercondensadores en lugar de baterías tradicionales.

La comunicación entre controladoras se realiza típicamente a través de enlaces SAS, lo que permite prescindir de enlaces Ethernet de latido para la sincronización de estado de los discos. Esto aporta una ruta de comunicación directa y altamente fiable entre los dos nodos a nivel de almacenamiento.

Otra característica importante es que estas arquitecturas suelen trabajar en modo activo/activo sobre el mismo RAID. Es decir, ambos nodos dan servicio simultáneamente y aprovechan la potencia de cómputo de los dos servidores, en lugar de dejar uno “en espera” hasta que falle el otro. De esta forma se evita malgastar el 50 % de la inversión en hardware que suele ocurrir en clústeres activo/pasivo.

Al basarse en Windows Server 2012 (o versiones posteriores), los administradores se benefician de un entorno de gestión familiar: herramientas, asistentes, consola de administración y modelo de permisos ya conocidos. El tiempo de aprendizaje se reduce al mínimo, lo que también disminuye los costes operativos y los riesgos durante la puesta en marcha.

Este tipo de soluciones HA-DAS se orientan a varios usos: virtualización de servidores Hyper-V, VDI Windows, almacenamiento SAN/NAS, bases de datos transaccionales (OLTP), data warehouse y servicios web en alta disponibilidad. Todo ello aprovechando un único chasis de almacenamiento compartido, dos nodos redundantes y la lógica de clúster de Windows.

Alta disponibilidad específica en cabinas NAS QNAP y Virtualization Station 4

En el ámbito de los NAS, fabricantes como QNAP han desarrollado funcionalidades avanzadas para lograr alta disponibilidad tanto del almacenamiento como de las máquinas virtuales alojadas en sus equipos. En particular, combinan el sistema operativo QuTS hero (basado en ZFS) con Virtualization Station 4 para ofrecer replicación en tiempo real y conmutación por error entre dos NAS.

Por un lado, el sistema QuTS hero integra tecnologías de HA para el propio NAS, permitiendo tener dos equipos idénticos (o similares) configurados como pareja de alta disponibilidad. Si uno de los NAS falla, el segundo asume la carga y los servicios continúan operativos. Esto ya protege el almacenamiento y los servicios básicos del NAS.

Sobre esa base, la nueva funcionalidad de alta disponibilidad en Virtualization Station 4 (disponible en fase beta en las versiones recientes) da un paso más: permite que las máquinas virtuales que se ejecutan en el NAS tengan tolerancia a fallos avanzada mediante replicación en tiempo real entre dos dispositivos QNAP.

Esta función está disponible solo en NAS QNAP con procesadores x86 que ejecuten QuTS hero y cuenten con la versión adecuada de Virtualization Station 4. El uso de ZFS y de la tecnología SnapSync es fundamental, ya que se encarga de sincronizar en tiempo real los datos de las VMs entre ambos NAS, garantizando que la VM replicada esté siempre al día.

El esquema de funcionamiento se basa en que dos NAS se respaldan mutuamente: el NAS A y el NAS B actúan como nodos de copia de seguridad entre sí, de forma bidireccional. Cada uno puede tener sus propias máquinas virtuales y, para las que se marcan como protegidas por HA, se crea una réplica en el otro NAS. En caso de fallo de uno de los equipos, el otro toma el control y arranca las VMs afectadas.

Esto permite una conmutación entre servidores NAS fluida. Se puede activar la protección HA solo para ciertas VMs críticas sin que ello afecte a otros servicios del NAS (por ejemplo, tareas de backup, compartición de archivos, etc.). Cada NAS puede seguir cumpliendo su rol original mientras protege, al mismo tiempo, las máquinas virtuales designadas para alta disponibilidad.

La sincronización en tiempo real basada en SnapSync asegura que, cuando se produce un incidente, la conmutación es prácticamente inmediata y sin pérdida de datos. A diferencia de arquitecturas tradicionales que dependen de un almacenamiento compartido central (SAN), esta solución elimina ese punto único de fallo: cada NAS mantiene una copia completa y coherente de las VMs que protege.

Además, QNAP define múltiples condiciones de fallo que pueden disparar la conmutación: sobrecarga prolongada de CPU (por encima de cierto umbral, por ejemplo, 80 % durante un tiempo), temperatura excesiva del sistema, fallo de discos incluso en configuraciones RAID, pérdida de una de las fuentes de alimentación redundantes, entre otras. El sistema evalúa estas condiciones y, si se considera que el NAS ya no es fiable, mueve la carga al otro nodo.

También se ofrece la posibilidad de hacer conmutaciones manuales, muy útiles cuando el equipo técnico quiere migrar de forma controlada las máquinas virtuales a otro NAS para hacer tareas de mantenimiento: sustituir discos, actualizar firmware, cambiar configuraciones avanzadas, etc. La conmutación es muy rápida (del orden de menos de un segundo), lo que hace que el proceso sea prácticamente transparente para los usuarios.

Otro punto interesante es que no hay coste adicional de licencia: la funcionalidad de alta disponibilidad en Virtualization Station 4 forma parte de la propia aplicación y viene incluida en el sistema, sin pagos extra por nodo o por VM. Esto la vuelve especialmente atractiva para pymes y entornos que buscan HA con un coste contenido.

Requisitos y limitaciones de la alta disponibilidad en QNAP

Para desplegar correctamente esta solución sobre QNAP es esencial respetar ciertos requisitos de software, hardware y red. No son extremadamente complejos, pero sí conviene tenerlos muy claros antes de diseñar el entorno.

En cuanto al software, es necesario contar con QuTS hero en versión h5.3 o superior y con Virtualization Station 4.1 o posterior. Solo esas versiones incorporan la funcionalidad de HA de VMs basada en SnapSync. En NAS con QTS “clásico” o versiones anteriores de Virtualization Station, esta característica no está disponible.

A nivel de hardware, no es obligatorio que los dos NAS sean exactamente el mismo modelo, pero sí se exige que ambos utilicen procesadores de la misma arquitectura y marca (los dos Intel o los dos AMD). Esto simplifica la compatibilidad y garantiza que las VMs replicadas puedan ejecutarse sin problemas en cualquiera de los dispositivos.

Respecto a la red, es indispensable que los dos NAS estén en el mismo segmento de red y que exista, además, una conexión directa entre ambos mediante un cable de red físico dedicado para la sincronización de datos de las máquinas virtuales. Este enlace dedicado funciona como canal “fuera de banda” para la replicación, evitando interferencias con el tráfico normal de usuarios.

En la práctica, el requisito real de hardware se reduce a esto: misma familia de CPU y enlace directo entre NAS. Todo lo demás (capacidad de disco, RAM, etc.) se dimensiona en función de las VMs que se quieran proteger y del rendimiento esperado. Si se respetan estas condiciones, la configuración de HA de QNAP es relativamente directa y muy robusta.

Diferencia entre alta disponibilidad y simple replicación/DR en VMs

Muchas veces se confunden las soluciones de replicación de máquinas virtuales como mecanismo de recuperación ante desastres con la verdadera alta disponibilidad sin tiempo de inactividad (o con downtime mínimo). Ambas son importantes, pero resuelven problemas distintos.

Por ejemplo, en entornos con VMware vSphere es frecuente configurar replicación de VMs a un sitio de DR, de manera que la imagen de disco del servidor principal se va copiando al nodo de contingencia. Esto protege frente a la pérdida total del sitio principal, pero, cuando éste cae, suele ser necesario hacer una recuperación manual: encender las VMs en el sitio de DR, reconfigurar redes, validar integridad de datos, etc.

Ese proceso, aunque automatizable en parte, implica un periodo de inactividad que puede ir de minutos a horas, dependiendo de la complejidad del entorno y de los procedimientos internos. Es una excelente estrategia de DR, pero no cumple el objetivo de disponibilidad casi continua que se espera de una solución HA estricta.

La alta disponibilidad “de verdad” exige que exista un mecanismo automático o casi automático de conmutación por error, con tiempos de corte muy bajos y sin necesidad de operaciones manuales complejas cuando un componente falla. Además, la sincronización de datos entre el nodo activo y el de respaldo debe ser lo bastante estrecha como para evitar o minimizar la pérdida de información reciente.

Por eso, al diseñar un entorno de VMs altamente disponible, hay que combinar correctamente tecnologías de clúster, replicación en tiempo (casi) real, almacenamiento redundante y monitorización proactiva. Solo así se consigue que los usuarios sigan accediendo al sitio web, la base de datos o la aplicación corporativa sin apenas interrupciones, incluso si un servidor o un NAS completo se apaga de repente.

En la práctica, lo más habitual es complementar la alta disponibilidad local (por ejemplo, un clúster dentro de un mismo CPD) con una estrategia de recuperación ante desastres en otro emplazamiento. De ese modo, se cubren tanto los fallos cotidianos (discos, servidores, fuentes, etc.) como eventos más graves (incendios, cortes de energía prolongados, desastres naturales).

Todo este abanico de soluciones —clústeres de RHEL y Hyper-V, arquitecturas HA-DAS sin SAN, alta disponibilidad específica en NAS QNAP con Virtualization Station y replicación avanzada de VMs— demuestra que, a día de hoy, es posible diseñar entornos virtualizados muy resistentes a fallos ajustados a distintos tamaños de empresa y presupuestos. Entender bien las diferencias entre cada enfoque, sus límites (como el número máximo de nodos o la necesidad de almacenamiento compartido), y sus requisitos técnicos es clave para elegir la combinación adecuada y mantener los servicios críticos en marcha casi sin parpadeos.