clúster de alta disponibilidad

En informática , los clústeres de alta disponibilidad ( clústeres HA ) o clústeres de conmutación por error son grupos de ordenadores que dan soporte a aplicaciones de servidor y que pueden utilizarse de forma fiable con un tiempo de inactividad mínimo . Funcionan mediante software de alta disponibilidad que aprovecha ordenadores redundantes en grupos o clústeres para proporcionar un servicio continuo cuando fallan los componentes del sistema. Sin la agrupación en clústeres, si un servidor que ejecuta una aplicación específica falla, la aplicación no estará disponible hasta que se repare el servidor averiado. La agrupación en clústeres HA soluciona esta situación detectando fallos de hardware/software y reiniciando inmediatamente la aplicación en otro sistema sin necesidad de intervención administrativa, un proceso conocido como conmutación por error . Como parte de este proceso, el software de agrupación en clústeres puede configurar el nodo antes de iniciar la aplicación en él. Por ejemplo, puede ser necesario importar y montar los sistemas de archivos adecuados, configurar el hardware de red y ejecutar también algunas aplicaciones de soporte. ^{[ 1 ]}

Los clústeres de alta disponibilidad (HA) se utilizan a menudo para bases de datos críticas , el intercambio de archivos en red, aplicaciones empresariales y servicios al cliente, como sitios web de comercio electrónico . Las implementaciones de clústeres HA buscan incorporar redundancia para eliminar puntos únicos de fallo, incluyendo múltiples conexiones de red y almacenamiento de datos conectados de forma redundante mediante redes de área de almacenamiento (SAN).

Los clústeres de alta disponibilidad (HA) suelen utilizar una conexión de red privada de latido para monitorizar el estado de cada nodo. Una condición sutil pero grave que todo software de clúster debe ser capaz de gestionar es el problema de la división de clúster ( split-brain) , que se produce cuando todos los enlaces privados fallan simultáneamente, pero los nodos del clúster siguen funcionando. En ese caso, cada nodo podría interpretar erróneamente que los demás nodos han fallado e intentar iniciar servicios que otros nodos aún están en funcionamiento. La existencia de instancias duplicadas de servicios puede provocar la corrupción de datos en el almacenamiento compartido.

Los clústeres de alta disponibilidad (HA) suelen utilizar almacenamiento de testigo de quórum (local o en la nube) para evitar este problema. Un dispositivo testigo no se puede compartir entre las dos mitades de un clúster dividido, por lo que, en caso de que todos los miembros del clúster no puedan comunicarse entre sí (por ejemplo, debido a un fallo en la señal de latido), si un miembro no puede acceder al testigo, no podrá activarse.

No todas las aplicaciones pueden ejecutarse en un entorno de clúster de alta disponibilidad, y las decisiones de diseño necesarias deben tomarse al inicio de la fase de diseño del software. Para ejecutarse en un entorno de clúster de alta disponibilidad, una aplicación debe cumplir al menos los siguientes requisitos técnicos, los dos últimos de los cuales son fundamentales para su funcionamiento fiable en un clúster y son los más difíciles de satisfacer por completo:

• Debe existir una forma relativamente sencilla de iniciar, detener, forzar la detención y comprobar el estado de la aplicación. En la práctica, esto significa que la aplicación debe contar con una interfaz de línea de comandos o scripts para su control, incluyendo la compatibilidad con múltiples instancias.
• La aplicación debe poder utilizar almacenamiento compartido ( NAS / SAN ).
• Lo más importante es que la aplicación debe almacenar la mayor parte de su estado posible en un almacenamiento compartido no volátil. Igualmente importante es la capacidad de reiniciarse en otro nodo en el último estado anterior al fallo, utilizando el estado guardado en el almacenamiento compartido.
• La aplicación no debe dañar los datos si falla o se reinicia desde el estado guardado.
• Varias de estas limitaciones pueden minimizarse mediante el uso de entornos de servidor virtual, en los que el hipervisor en sí mismo es compatible con clústeres y proporciona una migración fluida de máquinas virtuales (incluido el estado de la memoria en ejecución) entre hosts físicos; consulte Clústeres de conmutación por error de Microsoft Server 2012 y 2016 .
  • Una diferencia clave entre este enfoque y la ejecución de aplicaciones compatibles con clústeres es que estas últimas pueden gestionar fallos en las aplicaciones del servidor y admitir actualizaciones de software continuas, manteniendo el acceso del cliente al servicio (por ejemplo, la base de datos). Esto se logra mediante la prestación del servicio por parte de una instancia mientras otra se actualiza o repara. Para ello, las instancias del clúster deben comunicarse, vaciar las cachés y coordinar el acceso a los archivos durante la transferencia. La agrupación en clústeres con conmutación por error se incluye en la planificación, creación, configuración y resolución de problemas.

El tamaño más común para un clúster de alta disponibilidad es de dos nodos, ya que es el mínimo necesario para proporcionar redundancia, pero muchos clústeres constan de muchos más, a veces docenas de nodos.

El diagrama adjunto ofrece una buena visión general de un clúster HA clásico, con la salvedad de que no menciona la funcionalidad de quórum/testigo (véase más arriba).

Dichas configuraciones a veces se pueden clasificar en uno de los siguientes modelos:

• Activo/activo: El tráfico destinado al nodo averiado se redirige a un nodo existente o se distribuye entre los nodos restantes mediante balanceo de carga. Esto suele ser posible únicamente cuando los nodos utilizan una configuración de software homogénea.
• Activo/pasivo: proporciona una instancia totalmente redundante de cada nodo, que solo se pone en línea cuando falla su nodo primario asociado. ^{[ 2 ]} Esta configuración suele requerir la mayor cantidad de hardware adicional.
• N+1: Proporciona un nodo adicional que se activa para asumir la función del nodo que ha fallado. En el caso de configuraciones de software heterogéneas en cada nodo principal, el nodo adicional debe ser capaz de asumir cualquiera de las funciones de los nodos principales de los que es responsable. Esto se refiere normalmente a clústeres con múltiples servicios ejecutándose simultáneamente; en el caso de un solo servicio, se reduce a un modelo activo/pasivo.
• N+M: En los casos en que un único clúster gestiona muchos servicios, contar con un solo nodo de conmutación por error dedicado podría no ofrecer suficiente redundancia. En tales casos, se incluyen y disponen de más de un (M) servidor en espera. El número de servidores en espera representa un equilibrio entre el coste y los requisitos de fiabilidad.
• N-to-1: permite que el nodo de reserva de conmutación por error se convierta temporalmente en el nodo activo, hasta que el nodo original pueda restaurarse o volver a ponerse en línea, momento en el que los servicios o instancias deben volver a él para restablecer la alta disponibilidad.
• De N a N: una combinación de clústeres activo/activo y N+M, los clústeres de N a N redistribuyen los servicios, instancias o conexiones del nodo que falló entre los nodos activos restantes, eliminando así (al igual que con activo/activo) la necesidad de un nodo de reserva, pero introduciendo la necesidad de capacidad adicional en todos los nodos activos.

Los términos host lógico o host lógico de clúster se utilizan para describir la dirección de red que se usa para acceder a los servicios que proporciona el clúster. Esta identidad de host lógico no está vinculada a un único nodo del clúster. En realidad, es una dirección de red/nombre de host que está vinculada a los servicios que proporciona el clúster. Si un nodo del clúster con una base de datos en ejecución falla, la base de datos se reiniciará en otro nodo del clúster.

Los clústeres de alta disponibilidad suelen utilizar todas las técnicas disponibles para lograr que los sistemas individuales y la infraestructura compartida sean lo más fiables posible. Estas incluyen:

• La duplicación de discos (o matrices redundantes de discos independientes — RAID ) evita que la falla de los discos internos provoque fallos en el sistema. El dispositivo de bloques replicados distribuidos es un ejemplo de ello.
• Conexiones de red redundantes para que los fallos en un solo cable, conmutador o interfaz de red no provoquen interrupciones en la red.
• Conexiones de red de área de almacenamiento (SAN) redundantes para que las fallas de un solo cable, conmutador o interfaz no provoquen la pérdida de conectividad con el almacenamiento (esto violaría la arquitectura de recursos compartidos nulos ).
• Entradas de energía eléctrica redundantes en diferentes circuitos, generalmente todas o ambas protegidas por unidades de alimentación ininterrumpida (UPS) , y unidades de alimentación redundantes , de modo que las fallas en una sola fuente de alimentación, cable, UPS o fuente de alimentación no provoquen la pérdida de energía en el sistema.

Estas características ayudan a minimizar la probabilidad de que sea necesaria la conmutación por error del clúster entre sistemas. En tal caso, el servicio proporcionado no estará disponible durante un tiempo, por lo que se prefieren las medidas para evitarla.

Los sistemas que gestionan fallos en la computación distribuida tienen diferentes estrategias para solucionar un fallo. Por ejemplo, la API Hector de Apache Cassandra define tres formas de configurar una conmutación por error:

• La opción "Fail Fast" , codificada como "FAIL_FAST", significa que el intento de solucionar el fallo fracasará si no se puede acceder al primer nodo.
• En caso de fallo, pruebe con el siguiente disponible , programado como "ON_FAIL_TRY_ONE_NEXT_AVAILABLE", significa que el sistema intenta conectarse a un host, el más accesible o disponible, antes de desistir.
• La opción "En caso de fallo, intentar con todos los nodos ", programada como "ON_FAIL_TRY_ALL_AVAILABLE", significa que el sistema intenta con todos los nodos existentes y disponibles antes de desistir.

• clúster de computadoras
• conmutación por error
• Foro sobre disponibilidad de servicios
• OpenSAF
• Computación urgente
• Marcapasos (software)
• IBM Parallel Sysplex
• Lista de software de gestión de clústeres

• Greg Pfister: En busca de clústeres , Prentice Hall, ISBN 0-13-899709-8
• Evan Marcus, Hal Stern: Planos para alta disponibilidad: Diseño de sistemas distribuidos resilientes , John Wiley & Sons, ISBN 0-471-35601-8
• Chee-Wei Ang, Chen-Khong Tham: Análisis y optimización de la disponibilidad del servicio en un clúster HA con disponibilidad de máquina dependiente de la carga , IEEE Transactions on Parallel and Distributed Systems, Volumen 18, Número 9 (septiembre de 2007), Páginas 1307-1319, ISSN 1045-9219