Capítulo 2. Administración de clúster con CMAN
La administración de clúster maneja el cuórum y la membresía de clúster. CMAN (abreviación en inglés del Gestor de clústeres) administra los clústeres en la adición de alta disponibilidad para Red Hat Enterprise Linux. CMAN es un gestor de clústeres distribuido que se ejecuta en cada nodo de clúster; la administración de clústeres se distribuye a través de todos los nodos en el clúster.
CMAN guarda el rastro de las membresías al monitorizar los mensajes desde otros nodos de clúster. Cuando las membresías de clúster cambian, el gestor de clúster notifica a los otros componentes de la infraestructura para que lleven a cabo las acciones apropiadas. Si un nodo de clúster no transmite un mensaje durante un tiempo determinado, el gestor de clúster retira el nodo del clúster y comunica a los otros componentes de la infraestructura de clúster que el nodo ya no es miembro del clúster.
CMAN realiza un seguimiento del cuórum del clúster sondeando la cuenta de nodos de clúster. Si más de la mitad de los nodos están activos, el clúster tiene cuórum. Si la mitad o menos de la mitad de los nodos están activos, no hay cuórum en el clúster y toda la actividad de clúster se detiene. El cuórum del clúster evita que se presente la condición de cerebro dividido o "split-brain" — una condición en la cual dos instancias del mismo clúster se ejecutan al mismo tiempo. Esta condición permitiría que cada instancia de clúster accediera a los recursos sin conocimiento de la otra instancia de clúster, lo cual produciría la corrupción de la integridad del clúster.
2.1. Cuórum de clúster
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.
Nota
Por defecto, cada nodo tiene un voto. Sin embargo, se puede modificar la configuración para que cada nodo tenga más de un voto.
2.1.1. Discos de cuórum
Un disco de cuórum o partición es una sección de un disco que está configurado para se usado con los componentes del proyecto de clúster. Tiene varios propósitos. Por ejemplo:
Suponga que tiene los nodos A y B, y el nodo A no puede obtener varios de los paquetes "heartbeat" del gestor de clústeres. El nodo A no sabe por qué no ha recibido los paquetes, pero hay varias posibilidades: el nodo B ha fallado, el interruptor de red o concentrador ha fallado, el adaptador de red de nodo A ha fallado o quizás se debió a que el nodo B estaba demasiado ocupado para enviar el paquete. Esto puede suceder si el clúster es demasiado grande, sus sistemas están muy ocupados o si su red es poco fiable.
El nodo A no sabe cuál es el caso y desconoce si el problema reside en él o en el nodo B. Esto es problemático especialmente en un clúster de dos nodos, porque estos dos nodos no se tocan entre sí y cada uno puede tratar de cercar al otro.
Por lo tanto, antes de cercar un nodo, sería conveniente tener otra forma de verificar si el otro nodo está realmente vivo, a pesar de que no parezcan estar en contacto. Un disco de cuórum le da la destreza para hacer justo esto. Antes de cercar un nodo que esté fuera de contacto, el software de clúster puede verificar si el nodo está aún vivo basándose en si ha escrito datos en la partición de cuórum o no.
En el caso de sistemas de dos nodos, el disco de cuórum también actúa como un disyuntor. Si un nodo ha ingresado al disco de cuórum y la red, eso cuenta como dos votos.
Un nodo que haya perdido contacto con la red o disco de cuórum pierde el voto, y por lo tanto, es conveniente cercarlo por seguridad.
Para obtener más información sobre configuración de los parámetros de disco de cuórum, consulte los capítulos sobre administración de Conga y
ccs en la guía Administración de clústeres.
2.1.2. Tie-breakers (Disyuntores)
Los disyuntores son heurística adicional que permiten a una partición de clúster decidir si hay cuórum (quorate) o no en el evento de una división equitativa anterior al cercado. Un disyuntor típico es un disyuntor IP, conocido también como nodo 'ping'.
Con estos disyuntores, los nodos no solo se controlan entre sí, sino también controlan al enrutador principal que está en la misma ruta de comunicaciones de clúster. Si los dos nodos pierden contacto entre sí, el ganador es el que aún pueda contactar al enrutador principal. Claro está, que en casos tales como en un interruptor de bucle, donde los dos nodos pueden ver al enrutador, pero no verse entre sí, se produce un cerebro dividido, incluso cuando se utilizan disyuntores. Por esta razón, es importante asegurarse de que el cercado esté configurado correctamente.
Otros tipos de disyuntores incluyen dónde la partición compartida, la cual suele llamarse disco de cuórum, proporciona información adicional. clumanager 1.2.x (Red Hat Cluster Suite 3) tenía un disyuntor de discos que permitía operar si la red estaba caída, siempre y cuando ambos nodos aún estuvieran comunicándose en la partición compartida.
Existen esquemas de disyuntores más complejos, tales como QDisk (parte de linux-cluster). QDisk permite especificar la heurística arbitraria. Esta permite que cada nodo determine su propia estabilidad de participación en el clúster. No obstante, suele usarse como un simple disyuntor IP. Para obtener más información, consulte la página de manual qdisk(5).
Cman no presenta disyuntos internos por varias razones. No obstante, los disyuntores pueden implementarse mediante la API. Esta API permite registro y actualización de dispositivos de cuórum. Por ejemplo, observe el código fuente de QDisk.
Será necesario usar un disyuntor si:
- Tiene una configuración de dos nodos con dispositivos de cercado en una ruta de red diferente a la ruta utilizada para comunicación de clúster.
- Tiene una configuración de dos nodos en donde el cercado está en el nivel de fábrica - especialmente para reservaciones SCSI.
No obstante, si la red y la configuración de cercado en su clúster están correctas, un disyuntor solo añade complejidad, salvo en casos excepcionales.
