Alta disponibilidad se refiere a una metodología de diseño destinada a mantener la disponibilidad de un sistema para su utilización en la máxima medida posible. La intención es reducir al mínimo las causas de tiempo de inactividad, como por ejemplo fallos del sistema y mantenimiento y minimizar el tiempo que se tarda en detectar y recuperarse de los eventos que producen tiempo de inactividad cada vez que ocurran. En la práctica, se hace necesario contar con un medio automatizado para detectar y recuperarse rápidamente los eventos que causan tiempo de inactividad a medida que se deben obtener niveles más altos de disponibilidad.
Sentinel es una aplicación compleja multinivel que depende de y proporciona una amplia variedad de servicios. Por otro lado, se integra con varios sistemas de terceros externos para la recopilación de datos, uso compartido de datos y resolución de incidencias. La mayoría de soluciones de alta disponibilidad permiten a los encargados de implementarlas declarar dependencias entre los servicios que deben estar altamente disponibles y servicios dependientes, pero esto solo se aplica a los servicios que se ejecutan en el propio clúster. Los sistemas externos a Sentinel como los orígenes de eventos deben configurarse por separado para tener la disponibilidad que requiere la organización, y también deben configurarse para manejar correctamente situaciones en las que Sentinel no está disponible durante un cierto período de tiempo, como por ejemplo cuando se produce un evento de failover. Si los derechos de acceso están muy restringidos, por ejemplo si se utilizan sesiones autenticadas para enviar/recibir datos entre un sistema tercero y Sentinel, entonces el sistema tercero debe configurarse para aceptar las sesiones procedentes de cualquier nodo del clúster o para iniciar sesión en cualquier nodo del clúster (para este fin, Sentinel debe configurarse con una IP virtual). NetIQ no puede garantizar ningún nivel de alta disponibilidad en particular entre nuestro producto y sistemas terceros que no están bajo nuestro control.
Todos los clústeres de alta disponibilidad requieren alguna forma de almacenamiento compartido que permita mover rápidamente los datos de aplicaciones de un nodo de clúster a otro en caso de fallo del nodo de origen. El almacenamiento en sí debería tener una alta disponibilidad; eso se consigue por lo general mediante la tecnología de Red de área de almacenamiento (SAN) conectada a los nodos del clúster mediante una red de Canal de fibra. Otros sistemas utilizan Almacenamiento con interconexión a la red (NAS), iSCSI u otras tecnologías que permiten el montaje remoto de almacenamiento compartido. El requisito fundamental del almacenamiento compartido es que el clúster pueda mover de forma transparente el almacenamiento desde un nodo de clúster que ha fallado a un nuevo nodo de clúster.
NOTA:Para iSCSI, debe usar la unidad de transferencia de mensajes (MTU) más grande que sea compatible con su hardware. Las MTU de mayor tamaño optimizan el rendimiento del almacenamiento. Sentinel podría tener problemas si la latencia o el ancho de banda para almacenamiento son inferiores al valor recomendado.
Existen dos planteamientos básicos que puede usar Sentinel para el almacenamiento compartido. El primero localiza todos los componentes: binarios de aplicaciones, configuración y datos de eventos, en el almacenamiento compartido. Al producirse el failover, el almacenamiento se desmonta del nodo principal y se mueve al nodo de reserva, el cual carga toda la aplicación y la configuración desde el almacenamiento compartido. El segundo planteamiento almacena los datos de eventos en el almacenamiento compartido, pero los binarios de la aplicación y la configuración residen en cada nodo del clúster. Al producirse el failover, solo los datos de eventos se mueven al nodo de reserva.
Cada uno de estos planteamientos tiene ventajas y desventajas, pero el segundo permite a la instalación de Sentinel utilizar vías de instalación estándar compatibles con FHS, permite la verificación de paquetes RPM y también la aplicación de parches en caliente y la reconfiguración con el fin de reducir al mínimo el tiempo de inactividad.
Esta solución le guiará en un ejemplo del proceso de instalación en un clúster que utiliza almacenamiento compartido iSCSI y localiza los binarios de la aplicación/la configuración en cada nodo del clúster.
Un componente clave de cualquier entorno de alta disponibilidad es una forma sistemática y fiable de supervisar los recursos que deben tener una alta disponibilidad, junto con cualquier recurso del que dependen. EL SLE HAE utiliza un componente denominado Resource Agent para llevar a cabo esta supervisión: el trabajo de Resource Agent consiste en proporcionar el estado de cada recurso, y además (cuando se le pida) iniciar o detener dicho recurso.
Los Resource Agents deben proporcionar un estado fiable de los recursos supervisados para prevenir cualquier tiempo de inactividad innecesario. Los falsos positivos (cuando se considera que un recurso ha fallado, pero de hecho se recupera por sí solo) pueden provocar una migración del servicio (y el tiempo de inactividad asociado) cuando en realidad no es necesario y los falsos negativos (cuando el Resource Agent informa que un recurso está funcionando correctamente cuando de hecho no lo está) pueden impedir el uso adecuado del servicio. Por otro lado, la supervisión externa de un servicio puede ser bastante difícil; un puerto de servicio Web podría responder a un ping sencillo, por ejemplo, pero podría no ofrecer datos correctos cuando se envía una consulta real. En muchos casos, la funcionalidad de autocomprobación debe integrarse en el propio servicio para proporcionar una medida verdaderamente exacta.
Esta solución proporciona un OCF Resource Agent básico para Sentinel capaz de supervisar y detectar un fallo importante de hardware, del sistema operativo o del sistema Sentinel. En este momento las capacidades de supervisión externas de Sentinel se basan en la investigación de puertos IP y existe cierta posibilidad de que se produzcan lecturas de falsos positivos y negativos. Tenemos previsto mejorar en el futuro tanto Sentinel como Resource Agent con el fin de mejorar la exactitud de este componente.
Dentro de un clúster de alta disponibilidad (HA), se supervisan de forma constante los servicios cruciales y se reinician automáticamente en otros nodos en caso de fallo. Esta automatización puede presentar problemas, no obstante, si ocurre algún problema de comunicación con el nodo principal; aunque el servicio que se ejecuta en dicho nodo parece estar inactivo, de hecho sigue ejecutándose y escribiendo datos en el almacenamiento compartido. En ese caso, comenzar un nuevo conjunto de servicios en un nodo de reserva podría dañar fácilmente los datos.
Los clústeres utilizan una variedad de técnicas denominadas de forma colectiva "fencing" que impiden que esto suceda, incluidas SBD (Split Brain Detection) y STONITH (Shoot The Other Node In The Head). El objetivo principal es prevenir que se dañen los datos en el almacenamiento compartido.