Grupo de computadoras que funcionan con un tiempo de inactividad mínimo
Los clústeres de alta disponibilidad (también conocidos como clústeres HA , clústeres de conmutación por error ) son grupos de computadoras que admiten aplicaciones de servidor que se pueden utilizar de manera confiable con una cantidad mínima de tiempo de inactividad . Funcionan mediante el uso de software de alta disponibilidad para aprovechar las computadoras redundantes en grupos o clústeres que brindan un servicio continuo cuando fallan los componentes del sistema. Sin la agrupación en clústeres, si un servidor que ejecuta una aplicación en particular falla, la aplicación no estará disponible hasta que se repare el servidor dañado. La agrupación en clústeres de alta disponibilidad soluciona esta situación detectando fallas de hardware/software y reiniciando inmediatamente la aplicación en otro sistema sin requerir 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, es posible que sea necesario importar y montar los sistemas de archivos adecuados, configurar el hardware de red y también ejecutar algunas aplicaciones de soporte. [1]
Los clústeres HA se utilizan a menudo para bases de datos críticas , intercambio de archivos en una red, aplicaciones comerciales y servicios al cliente, como sitios web de comercio electrónico . Las implementaciones de clústeres HA intentan incorporar redundancia en un clúster para eliminar puntos únicos de falla, incluidas múltiples conexiones de red y almacenamiento de datos que se conecta de manera redundante a través de redes de área de almacenamiento .
Los clústeres de alta disponibilidad suelen utilizar una conexión de red privada de latidos que se utiliza para supervisar la salud y el estado de cada nodo del clúster. Una condición sutil pero grave que todo software de agrupación en clústeres debe poder controlar es la división del cerebro , que se produce cuando todos los enlaces privados se caen simultáneamente, pero los nodos del clúster siguen en funcionamiento. Si eso sucede, cada nodo del clúster puede decidir por error que todos los demás nodos se han caído e intentar iniciar servicios que otros nodos siguen en funcionamiento. Tener instancias duplicadas de servicios puede provocar la corrupción de datos en el almacenamiento compartido.
Los clústeres de alta disponibilidad también suelen utilizar almacenamiento de testigo de quórum (local o en la nube) para evitar esta situación. Un dispositivo testigo no se puede compartir entre 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, falla de latido), si un miembro no puede acceder al testigo, este no puede activarse.
Requisitos de diseño de aplicaciones
No todas las aplicaciones pueden ejecutarse en un entorno de clúster de alta disponibilidad, y las decisiones de diseño necesarias deben tomarse en las primeras fases de diseño del software. Para poder ejecutarse en un entorno de clúster de alta disponibilidad, una aplicación debe satisfacer al menos los siguientes requisitos técnicos, los dos últimos de los cuales son fundamentales para su funcionamiento confiable 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 verificar el estado de la aplicación. En términos prácticos, esto significa que la aplicación debe tener una interfaz de línea de comandos o secuencias de comandos para controlarla, incluido el soporte para múltiples instancias de la aplicación.
La aplicación debe poder utilizar almacenamiento compartido ( NAS / SAN ).
Lo más importante es que la aplicación debe almacenar la mayor cantidad posible de su estado 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.
Muchas de estas restricciones se pueden minimizar mediante el uso de entornos de servidores virtuales, en los que el propio hipervisor es consciente de los clústeres y proporciona una migración sin inconvenientes 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 que reconocen clústeres es que este último puede lidiar con fallas de aplicaciones de servidor y admitir actualizaciones de software "continuas" en vivo mientras mantiene el acceso del cliente al servicio (por ejemplo, la base de datos), al hacer que una instancia brinde servicio mientras otra se actualiza o repara. Esto requiere que las instancias del clúster se comuniquen, vacíen cachés y coordinen el acceso a archivos durante la transferencia. La agrupación en clústeres de conmutación por error se incluye en la planificación, creación y configuración, así como en la resolución de problemas.
Configuraciones de nodos
Diagrama de red de clúster de alta disponibilidad de 2 nodos
El tamaño más común para un clúster HA es un clúster de dos nodos, ya que es el mínimo necesario para proporcionar redundancia, pero muchos clústeres constan de muchos más nodos, a veces docenas de nodos.
El diagrama adjunto es una buena descripción general de un clúster HA clásico, con la salvedad de que no menciona ninguna funcionalidad de quórum/testigo (ver arriba).
Estas configuraciones a veces se pueden clasificar en uno de los siguientes modelos:
Activo/activo: el tráfico destinado al nodo fallido se transfiere a un nodo existente o se equilibra la carga entre los nodos restantes. Por lo general, esto solo es posible cuando los nodos utilizan una configuración de software homogénea.
Activo/pasivo: proporciona una instancia completamente redundante de cada nodo, que solo se pone en línea cuando falla su nodo principal asociado. [2] Esta configuración generalmente requiere la mayor cantidad de hardware adicional.
N+1: proporciona un único nodo adicional que se pone en línea para asumir la función del nodo que ha fallado. En el caso de una configuración de software heterogénea 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 normalmente se refiere a clústeres que tienen varios servicios ejecutándose simultáneamente; en el caso de un solo servicio, esto se degenera en activo/pasivo.
N+M: en los casos en los que un solo clúster administra muchos servicios, es posible que tener un solo nodo de conmutación por error dedicado no ofrezca suficiente redundancia. En tales casos, se incluyen y están disponibles más de un (M) servidor en espera. La cantidad de servidores en espera es una compensación entre los requisitos de costo y confiabilidad.
N-to-1: permite que el nodo en espera de conmutación por error se convierta en el nodo activo temporalmente, hasta que el nodo original pueda restaurarse o ponerse nuevamente en línea, momento en el cual los servicios o instancias deben volver a conectarse a él para restaurar la alta disponibilidad.
N-to-N: una combinación de clústeres activo/activo y N+M; los clústeres N a N redistribuyen los servicios, instancias o conexiones del nodo fallido entre los nodos activos restantes, eliminando así (como con activo/activo) la necesidad de un nodo "en espera", 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 utiliza para acceder a los servicios proporcionados por el clúster. Esta identidad de host lógico no está vinculada a un solo nodo del clúster. En realidad, es una dirección de red o un nombre de host que está vinculado con los servicios proporcionados por el clúster. Si un nodo del clúster con una base de datos en ejecución deja de funcionar, la base de datos se reiniciará en otro nodo del clúster.
Fiabilidad del nodo
Los clústeres de alta disponibilidad suelen utilizar todas las técnicas disponibles para que los sistemas individuales y la infraestructura compartida sean lo más confiables posible. Entre ellas se incluyen las siguientes:
Estas características ayudan a minimizar las posibilidades de que se requiera una conmutación por error de agrupación entre sistemas. En este tipo de conmutación por error, el servicio proporcionado no está disponible durante al menos un breve período de tiempo, por lo que es preferible tomar medidas para evitar la conmutación por error.
Estrategias de conmutación por error
Los sistemas que gestionan fallos en la informática distribuida tienen distintas estrategias para solucionarlos. Por ejemplo, la API Hector de Apache Cassandra define tres formas de configurar una conmutación por error:
Fail Fast , cuyo script es "FAIL_FAST", significa que el intento de solucionar la falla falla si no se puede alcanzar el primer nodo.
En caso de error, pruebe uno (el siguiente disponible) , cuyo script es "ON_FAIL_TRY_ONE_NEXT_AVAILABLE", significa que el sistema prueba un host, el más accesible o disponible, antes de darse por vencido.
En caso de error, probar todo , cuyo script es "ON_FAIL_TRY_ALL_AVAILABLE", significa que el sistema prueba todos los nodos existentes disponibles antes de darse por vencido.
^ van Vugt, Sander (2014), Clústeres de alta disponibilidad Pro Linux , p.3, Apress, ISBN 978-1484200803
^ Bornschlegl, Susanne (2012). Railway Computer 3.0: An Innovative Board Design Could Revolutionize The Market (pdf) . MEN Mikro Elektronik . Consultado el 21 de septiembre de 2015 .
Evan Marcus, Hal Stern: Planos para la 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 [1]
