Visión general de adición de alta disponibilidad

Un clúster está compuesto por dos o más computadores (llamados nodos o miembros) que trabajan juntos para ejecutar una tarea. Hay cuatro clases de clúster:

Los clústeres de almacenamiento proporcionan una imagen de sistema de archivos consistente, a través de los servidores en el clúster, lo cual permite que los servidores lean y escriban simultáneamente un sistema de archivos compartido. Un clúster de almacenamiento simplifica la administración de almacenamiento al limitar la instalación de aplicaciones a un sistema de archivos. Asimismo, con un sistema de archivos a lo largo del clúster, un clúster de almacenamiento elimina la necesidad de copias de más de los datos de la aplicación y simplifica la creación de copias de seguridad y recuperación contra desastres. La adición de alta disponibilidad proporciona agrupamiento de almacenamiento junto con Red Hat GFS2 (parte de la adición de almacenamiento resistente).

Los clústeres de alta disponibilidad proporcionan alta disponibilidad de servicios mediante la eliminación de los puntos individuales de falla y la conmutación de servicios de un nodo de clúster a otro en caso de que un nodo sea inoperante. Generalmente, los servicios en un clúster de alta disponibilidad leen y escriben datos (a través de los sistemas de archivos de lectura y escritura montados). Así, un clúster de alta disponibilidad debe mantener la integridad de los datos cuando un nodo reciba el control del servicio desde otro nodo de clúster. Las fallas de nodos en un clúster de alta disponibilidad no están visibles para los clientes externos al clúster. (Los clústeres de alta disponibilidad también se conocen como clústeres de conmutación.) La adición de alta disponibilidad proporciona agrupamiento a través de su componente de administración de servicios de alta disponibilidad, rgmanager..

Los clústeres de balance de carga responden a peticiones de servicios de red desde diferentes nodos para balancear las peticiones a los largo de los nodos del clúster. El balance de carga proporciona escalabilidad económica porque se puede configurar el número de nodos de acuerdo con los requerimientos de balance de carga. Si un nodo en un clúster de balance de carga falla, el software de balance de carga detecta la falla y asigna las peticiones a otros nodos en el clúster. Los nodos erróneos en un clúster de balance de carga no son visibles desde los clientes fuera del clúster.

Los clústeres de alto rendimiento utilizan los nodos para ejecutar cálculos simultáneos. Un clúster de alto rendimiento permite que las aplicaciones trabajen de forma paralela, mejorando así el rendimiento de éstas. El clúster de alto rendimiento se conoce como clúster computacional o computación en red.

La adición de alta disponibilidad es un conjunto integrado de componentes de software que puede ser implementado en una amplia variedad de configuraciones para cubrir la necesidad de rendimiento, alta disponibilidad, balance de carga, escalabilidad, compartición de archivos y economía de recursos.

La adición de alta disponibilidad consta de los siguientes componentes principales:

Puede complementar la adición de alta disponibilidad con los siguientes componentes:

La infraestructura de clúster de alta disponibilidad proporciona las funciones básicas para que un grupo de computadores (llamados nodos o miembros) trabajen juntos en un clúster. Una vez el clúster ha sido formado con la infraestructura de clúster, puede utilizar otros componentes para cubrir las necesidades de agrupamiento (por ejemplo, puede establecer un clúster para compartir archivos en un sistema de archivo GFS2 o establecer un servicio de conmutación). La infraestructura de clúster lleva a cabo las siguientes funciones:

Cuórum es un algoritmo de votación utilizado por CMAN.

Un clúster solo puede funcionar correctamente si hay un acuerdo general entre los miembros en relación con sus estatus. Decimos que un clúster tiene cuórum si la mayoría de nodos está viva, comunicándose y en acuerdo con los miembros de clúster activos. Por ejemplo, en un clúster de trece nodos, el cuórum solo se alcanza si siete o más nodos se están comunicando. Si el séptimo nodo muere, el clúster pierde cuórum y no puede funcionar más.

Un clúster debe mantener el cuórum para evitar problemas split-brain . Si el cuórum no era obligatorio, el cuórum, un error de comunicación en ese mismo clúster de trece nodos puede causar una situación en la que seis nodos operen en el almacenamiento compartido , mientras que otros seis nodos también operen en él independientemente. Debido al error de comunicación, los dos clústeres parciales sobrescribirían las áreas del disco y dañarían el sistema de archivos. Con las reglas de cuórum obligatorias, solamente uno de los clústeres parciales puede usar el almacenamiento compartido, lo cual protege la integridad de los datos.

El cuórum no evita situaciones de cerebro dividido, porque no decide quién el dominante y puede funcionar en el clúster. En caso de presentarse la situación de cerebro dividido, el cuórum impide al grupo de clústeres hacer otra cosa.

El Cuórum es determinado por la comunicación de mensajes entre los nodos de clúster vía Ethernet. También, se puede determinar por una combinación de mensajes de comunicación a través de Ethernet y de un disco de cuórum. Para el cuórum vía Ethernet, el cuórum consta de una mayoría simple (50 % de los nodos + 1 adicional). Cuando se configura un disco de cuórum, el cuórum consta de condiciones de usuario especificadas.

Un dominio de conmutación es un subconjunto de miembros ordenados a los cuales se puede vincular un servicio. Aunque . Los dominios de conmutación son útiles para personalizar el clúster, no se requieren para funcionar.

La lista a continuación presenta la semántica que gobierna las opciones de la forma como las diferentes opciones de configuración afectan la conducta de un dominio de conmutación.

El ordenamiento, la restricción y la no recuperación son indicadores que pueden combinarse en casi cualquier forma (por ejemplo, ordenado + restringido, desordenado + irrestringido, etc). Estas combinaciones afectan ambos servicios donde los servicios inician después de la formación del cuórum inicial y en los que los miembros de clúster se encargarán de los servicios en el evento que el servicio falle.

RGManager tiene tres políticas de servicios que el administrador puede personalizar según las necesidades del servicio.

<service name="myservice" max_restarts="3" restart_expire_time="300" ...>
  ...
</service>

<service name="myservice" max_restarts="3" restart_expire_time="300" ...>
  ...
</service>

Lo siguiente ilustra la estructura de un árbol de recursos con la correspondiente lista que define cada área.

    <service name="foo" ...>
        <fs name="myfs" ...>
            <script name="script_child"/>
        </fs>
        <ip address="10.1.1.2" .../>
    </service>

    <service name="foo" ...>
        <fs name="myfs" ...>
            <script name="script_child"/>
        </fs>
        <ip address="10.1.1.2" .../>
    </service>

Las siguientes operaciones aplican a ambos servicios y a las máquinas virtuales, a excepción de la operación de migración, la cual únicamente funciona en máquinas virtuales.

RGManager maneja máquinas virtuales un poco diferente a los otros servicios.

RGManager espera los siguiente valores de retorno de los agentes de recursos:

El modelo de cerramiento DLM proporciona una serie de modos de cerrojo de ejecución tanto asíncrona como sincrónica. Una aplicación adquiere un cerrojo en un recurso de cerrojos. Existe una relación de uno o muchos entre recursos y cerrojos: un recurso de cerrojo individual puede tener múltiples cerrojos asociados a este.

Un recurso de cerrojos puede corresponder al objeto real, tal como un archivo, una estructura de datos, una base de datos o una rutina ejecutable, pero no necesariamente debe corresponder a alguna de ellas. El objeto que usted asocie con el recurso de cerrojos determina la granularidad del cerrojo. Por ejemplo, encerrar toda una base de datos se considera un cerramiento en granularidad gruesa. Encerrar cada elemento en una base de datos se considera un cerramiento en una granularidad fina.

El modelo de cerramiento DLM soporta:

El DLM provee sus propios mecanismos para soportar sus funcionalidades de cerramiento, tales como la comunicación internodal para manejar el tráfico de cerrojos y los protocolos de recuperación para remasterizar cerrojos tras una falla de nodos o para migrar cerrojos cuando un nodo se une al clúster. No obstante, el DLM no proporciona mecanismos para administrar en realidad el clúster. Por lo tanto, el DLM espera operar en un clúster junto con otro entorno de infraestructura de clúster que proporcione los siguientes requisitos mínimos:

El DLM funciona con cualquier entorno de infraestructura de clúster que proporciona los requerimientos mínimos listados arriba. La selección de un entorno de código abierto o cerrado depende del usuario. Sin embargo, la mayor limitación de DLM es la cantidad de pruebas realizadas con entornos diferentes.

Un estado de cerrojo indica el estatus actual de una solicitud de cerrojo. Un cerrojo siempre está en alguno de los tres estados:

El estado de cerrojo es determinado por el modo solicitado y los modos de los otros cerrojos en el mismo recurso.

El manejo de Red Hat High Availability Add-On consiste en usar herramientas de configuración para especificar la relación entre los componentes de clúster. Las siguientes herramientas de configuración de clúster están disponibles con dicho complemento:

RHEL HA y RHEV ofrecen máquinas virtuales de alta disponibilidad (HA). Debido a la coincidencia en funcionalidad, se debe tener cuidado al escoger el producto para que se ajuste a su caso de uso específico. Los siguientes lineamientos deben tenerse en cuenta al elegir entre RHEL HA y RHEV para proporcionar alta disponibilidad de Máquinas virtuales.

Para máquina virtual y conteo de hosts físicos

Uso de máquina virtual:

RHEL 5 soporta dos plataformas de virtualización. Xen ha tenido soporte desde el lanzamiento de RHEL 5.0. Se introdujo en RHEL 5.4 KVM.

RHEL 6 solamente soporta KVM como plataforma de virtualización.

RHEL 5 AP Cluster ofrece soporte para KVM y Xen para uso en máquinas virtuales que son administradas por la infraestructura de clúster de host.

Alta disponibilidad de RHEL 6 soporta KVM para usar en máquinas virtuales que son administradas por la infraestructura de clúster de host.

La lista a continuación muestra los escenarios de implementación que tienen soporte de Red Hat actualmente:

Los tipos de máquinas virtuales que se ejecutan como recursos administrados no importan. Cualquier huésped que tenga soporte ya sea para Xen o KVM en RHEL puede ser utilizada como huésped altamente disponible. Esto incluye las variantes de RHEL (RHEL3, RHEL4, RHEL5) y varias variantes de Microsoft Windows. Verifique la documentación RHEL para buscar las listas más recientes de sistemas operativos de huésped que reciben soporte en cada hipervisor.

Se refiere a RHEL Cluster/HA que se ejecuta dentro de los huéspedes virtualizados en una variedad de plataformas de virtualización. En este caso RHEL Clustering/HA se utiliza principalmente para hacer que las aplicaciones que se ejecuten dentro de los huéspedes estén altamente disponibles. Este escenario es similar a la forma como RHEL Clustering/HA siempre ha utilizado hosts vacíos tradicionales. La diferencia es que el agrupamiento se ejecuta dentro de los huéspedes en su lugar.

La siguiente es una lista de plataformas de virtualización y el nivel de soporte actualmente disponible para ejecutar clústeres de huéspedes mediante alta disponibilidad (HA) de clústeres de RHEL. En la lista, RHEL 6 Guests abarca tanto la alta disponibilidad (agrupamiento de núcleos) como los complementos de almacenamiento resistente (GFS2, clvmd y cmirror).