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 . Operan mediante el uso de software de alta disponibilidad para aprovechar computadoras redundantes en grupos o clústeres que brindan un servicio continuo cuando fallan los componentes del sistema. Sin 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 fallado. La agrupación en clústeres HA 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 sistemas de archivos adecuados, que sea necesario configurar el hardware de red y que también sea necesario ejecutar algunas aplicaciones de soporte. [1]
Los clústeres de 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 crear 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 latido 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 clustering debe ser capaz de manejar es el cerebro dividido , que ocurre cuando todos los enlaces privados se caen simultáneamente, pero los nodos del cluster aún están ejecutándose. Si eso sucede, cada nodo del clúster puede decidir erróneamente que todos los demás nodos han caído e intentar iniciar servicios que otros nodos todavía están ejecutando. Tener instancias duplicadas de servicios puede dañar los datos en el almacenamiento compartido.
Los clústeres de alta disponibilidad también suelen utilizar almacenamiento de testigos de quórum (local o en la nube) para evitar este escenario. Un dispositivo testigo no se puede compartir entre dos mitades de un clúster dividido, por lo que en el caso de que todos los miembros del clúster no puedan comunicarse entre sí (por ejemplo, un latido fallido), 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 temprano en la fase de diseño del software. Para 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 críticos para su funcionamiento confiable en un clúster y son los más difíciles de satisfacer por completo:
Debe haber una manera relativamente fácil 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 scripts para controlar la aplicación, 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 reiniciar en otro nodo en el último estado antes del fallo utilizando el estado guardado del almacenamiento compartido.
La aplicación no debe dañar los datos si falla o se reinicia desde el estado guardado.
Varias de estas limitaciones se pueden minimizar mediante el uso de entornos de servidores virtuales, en los que el hipervisor en sí es compatible con los 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 clusters es que estas últimas pueden lidiar con fallos de las aplicaciones del servidor y admitir actualizaciones de software "continuas" en vivo mientras mantienen el acceso del cliente al servicio (por ejemplo, la base de datos), al hacer que una instancia proporcione el servicio mientras que otra está siendo actualizado o reparado. Esto requiere que las instancias del clúster se comuniquen, vacíen las cachés y coordinen el acceso a los archivos durante la transferencia. La agrupación en clústeres de conmutación por error se incluye en la planificación, la creación y la configuración, así como en la resolución de problemas.
Configuraciones de nodos
Diagrama de red del 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 requerido para proporcionar redundancia, pero muchos clústeres constan de muchos más, 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 la funcionalidad de quórum/testigo (ver arriba).
En ocasiones, estas configuraciones se pueden clasificar en uno de los siguientes modelos:
Activo/activo: el tráfico destinado al nodo fallido se pasa a un nodo existente o se equilibra la carga entre los nodos restantes. Normalmente, esto sólo 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 normalmente 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 falló. En el caso de una configuración de software heterogénea en cada nodo primario, el nodo adicional debe ser universalmente capaz de asumir cualquiera de las funciones de los nodos primarios de los que es responsable. Normalmente esto se refiere a clústeres que tienen múltiples servicios ejecutándose simultáneamente; en el caso de un solo servicio, esto degenera a activo/pasivo.
N+M: en los casos en los que un único clúster gestiona muchos servicios, tener un solo nodo de conmutación por error dedicado podría no ofrecer suficiente redundancia. En tales casos, se incluyen y están disponibles más de un (M) servidores 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 volver a estar en línea, momento en el cual los servicios o instancias deben 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í (al igual que con activo/activo) la necesidad. para 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ógica no está vinculada a un único nodo del clúster. En realidad, es una dirección de red/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 HA suelen utilizar todas las técnicas disponibles para hacer que los sistemas individuales y la infraestructura compartida sean lo más confiables posible. Éstas incluyen:
Estas características ayudan a minimizar las posibilidades de que sea necesaria la conmutación por error de agrupación entre sistemas. En dicha conmutación por error, el servicio proporcionado no está disponible al menos durante un tiempo, por lo que se prefieren medidas para evitar la conmutación por error.
Estrategias de conmutación por error
Los sistemas que manejan fallas en la computación distribuida tienen diferentes estrategias para solucionar una falla. Por ejemplo, la API Hector de Apache Cassandra define tres formas de configurar una conmutación por error:
Fail Fast , escrito como "FAIL_FAST", significa que el intento de solucionar el fallo falla si no se puede alcanzar el primer nodo.
En caso de error, pruebe uno: el siguiente disponible , escrito como "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, intentar todo , escrito como "ON_FAIL_TRY_ALL_AVAILABLE", significa que el sistema prueba todos los nodos existentes y 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: un diseño de placa innovador podría revolucionar el mercado (pdf) . HOMBRES 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 la 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]
