 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
1.1. Clústeres, nodos y servicios de clúster
Al distribuir servicios críticos y de misión crítica, como bases de datos o sitios web de comercio electrónico, es poco probable que confíes en que el host que ejecuta esos servicios vaya a tener una vida útil larga, estable y sin contratiempos. Más bien, tendrás en cuenta el posible fallo de un host y te asegurarás de que otros hosts estén en espera para hacerse cargo de los servicios inmediatamente en caso de fallo (o Failover), de modo que el fallo ni siquiera sea perceptible para el mundo exterior.
Un grupo de hosts conectados en red que trabajan juntos para realizar la misma tarea se denomina red informática o clúster informático, o más sencillamente, un clúster. Un clúster actúa y se presenta externamente como un único sistema y organiza internamente a sus hosts para que trabajen juntos en la tarea común.
Un clúster puede realizar diversas tareas; por ejemplo, un clúster HPC puede realizar computación de alto rendimiento, que se utiliza, entre otros escenarios, cuando los cálculos requieren mucha más memoria de la que hay disponible en un solo ordenador. Si el clúster tiene la tarea de proporcionar alta disponibilidad (HA), también se denomina clúster HA. Este artículo trata sobre los clústeres HA; es decir, cuando nos referimos a un «clúster» en el texto siguiente, siempre nos referimos a un clúster HA.
Un clúster ofrece uno o más servicios al mundo exterior: los servicios del clúster, a veces denominados «servicios en clúster». En un clúster, los hosts que lo componen se llaman nodos. En un momento dado, cada servicio lo proporciona solo uno de los nodos. Si falla cualquier nodo del clúster, todos los servicios esenciales para la misión del clúster se trasladan a uno de los otros nodos.
Para que cualquier Failover sea transparente, algunos clústeres proporcionan su propia dirección IP de clúster, a la que a veces también se hace referencia como dirección IP virtual. La dirección IP del clúster siempre hace referencia al nodo activo y representa a todo el clúster. En caso de Failover, la dirección IP se transfiere a otro nodo, anteriormente pasivo, que pasa a ser el nodo activo. El cliente que se comunica con el clúster puede ignorar un Failover interno: utiliza la misma dirección IP, sin cambios, y no necesita realizar ningún cambio por su parte.
Otros clústeres no tienen una dirección IP de clúster. Los clústeres de bases de datos Oracle, en muchas de sus variantes, son un ejemplo destacado. Sin una dirección IP de clúster, el cliente debe mantener una lista de direcciones IP de todos los nodos que podrían proporcionar el servicio. Si el nodo activo falla, el cliente debe detectarlo y switchear al nodo que ahora está proporcionando el servicio.
1.2. Monitorización de un clúster
Checkmk es uno de los clientes que se comunica con el clúster. En Checkmk, se pueden configurar y realizar la monitorización de todos los nodos de un clúster, independientemente de cómo el software del clúster compruebe internamente el estado de los nodos individuales y, si es necesario, realice un Failover.
La mayoría de las comprobaciones que Checkmk realiza en los nodos individuales de un clúster se refieren a las propiedades físicas de los nodos, que son independientes de si el host pertenece a un clúster o no. Algunos ejemplos son la carga de la CPU y la memoria, los discos locales, las interfaces de red físicas, etc. Sin embargo, para el mapeo de la función de clúster de los nodos en Checkmk, es necesario identificar aquellos servicios que definen la tarea del clúster y para los que podría ser necesaria una transferencia a otro nodo: los servicios del clúster.
Checkmk te ayuda a realizar la monitorización de los servicios del clúster. Lo que tienes que hacer es:
Crear el clúster.
Seleccionar los servicios del clúster.
Realizar un descubrimiento de servicios para todos los hosts asociados.
En el siguiente capítulo se describe cómo proceder utilizando la siguiente configuración de ejemplo:
En Checkmk, se va a configurar un clúster de Failover de Windows como un clúster HA compuesto por dos nodos con servidores Microsoft SQL (MS SQL) instalados. Se trata de un clúster denominado «activo/pasivo», lo que significa que solo uno, el nodo activo, ejecuta una instancia de base de datos. El otro nodo es pasivo y solo se activa en caso de Failover, momento en el que iniciará la instancia de la base de datos y sustituirá al nodo que ha fallado. Los datos de la instancia de la base de datos no se almacenan en los propios nodos, sino en un medio de almacenamiento compartido, por ejemplo, una red de área de almacenamiento (SAN), a la que están conectados ambos nodos. La configuración de ejemplo consta de los siguientes componentes:
mssql-node01es el nodo activo que ejecuta una instancia de base de datos activa.mssql-node02es el nodo pasivo.mssql-cluster01es el clúster al que pertenecen ambos nodos.
A diferencia de este ejemplo, también es posible que un mismo nodo pueda estar incluido en más de un clúster. En el último capítulo aprenderás a configurar estos clústeres superpuestos utilizando una configuración de ejemplo modificada.
2. Configuración de clústeres y servicios de clúster
2.1. Creación de un clúster
En Checkmk, los nodos y el propio clúster se crean como hosts (hosts de nodo y hosts de clúster), con un tipo de host especial definido para un host de clúster.
Aquí tienes algunos puntos a tener en cuenta antes de configurar un host de clúster:
El host de clúster es un host virtual que debe configurarse con una dirección IP de clúster, si hay una disponible. En nuestro ejemplo, suponemos que el nombre del host de clúster se puede resolver a través de DNS.
Los hosts de clúster se pueden configurar de la misma manera que los hosts «normales», por ejemplo, con tags del host o grupos del host.
Para todos los hosts participantes (esto siempre significa el host del clúster y todos sus hosts de nodo asociados), las fuentes de datos deben configurarse de forma idéntica, es decir, en particular, no se puede configurar unos a través de un agente Checkmk y otros a través de SNMP. Checkmk se asegura de que solo se pueda crear un host del clúster si se cumple este requisito.
En una monitorización distribuida, todos los hosts participantes deben estar asignados al mismo site de Checkmk.
No todas las comprobaciones funcionan en una configuración de clúster. Para aquellas comprobaciones que tienen implementada la compatibilidad con clústeres, puedes leer más al respecto en la página del manual del Plugin. Puedes acceder a las páginas del manual desde el menú «Setup > Services > Catalog of check plug-ins».
En nuestro ejemplo, los dos hosts de nodo mssql-node01 y mssql-node02 ya se han creado y configurado como hosts.
Para saber cómo llegar hasta aquí, consulta el artículo sobre la monitorización de servidores Windows, y allí, en el capítulo sobre la ampliación del agente estándar de Windows con plugins, en nuestro ejemplo los plugins de MS SQL Server.
Inicia la creación del clúster desde el menú Setup > Hosts > Hosts y, a continuación, desde el menú Hosts > Add cluster:
Introduce «mssql-cluster01» como «Host name» e introduce los dos hosts de los nodos en «Nodes».
 |
Si estás trabajando con un clúster sin una dirección IP de clúster, tendrás que dar un rodeo un poco incómodo, seleccionando No IP en la caja Network address para el IP address family. Pero para evitar que el host aparezca como «DOWN» en la monitorización, debes cambiar el comando «Check host» predeterminado para esto a través de la regla del mismo nombre —de «Smart PING» o «PING» a, por ejemplo, el estado de uno de los servicios que se asignará al host del clúster—, tal y como se explicará en la siguiente sección. Para obtener más información sobre los conjuntos de reglas de host, consulta el artículo sobre reglas. |
Finaliza la creación con «Save & view folder» y activa los cambios.
2.2. Selección de servicios de clúster
Checkmk no puede saber cuáles de los servicios que se ejecutan en un nodo son locales y cuáles son servicios de clúster: algunos sistemas de archivos pueden ser locales, mientras que otros pueden estar montados solo en el nodo activo. Lo mismo ocurre con los procesos: mientras que el servicio «Windows Timer» probablemente se esté ejecutando en todos los nodos, una instancia de base de datos concreta solo estará disponible en el nodo activo.
En lugar de dejar que Checkmk adivine, selecciona los servicios del clúster con una regla.
Sin una regla, no se asignará ningún servicio al clúster.
En este ejemplo, supondremos que los nombres de todos los servicios del clúster de MS SQL Server comienzan por MSSQL y que se puede acceder al sistema de archivos del dispositivo de almacenamiento compartido a través de la unidad D:
Empieza por Setup > Hosts > Hosts y haz clic en el nombre del clúster. En la página Properties of host, selecciona en el menú «Host > Clustered services». Llegarás a la página del conjunto de reglas «Clustered services», donde podrás crear una nueva regla. A continuación, aparecerá la página «Add rule: Clustered services»:
Independientemente de si los hosts están organizados en carpetas y de cómo lo estén, asegúrate de crear cualquier regla para los servicios del clúster de modo que se apliquen a los hosts de los nodos en los que se ejecutan los servicios. Una regla de este tipo no es efectiva para un host del clúster.
En la caja «Conditions», bajo «Folder», selecciona la carpeta que contiene los hosts de nodo.
Activa «Explicit hosts» e introduce el host de nodo activo mssql-node01 y el host de nodo pasivo mssql-node02.
A continuación, activa «Services» y realiza dos entradas allí:
«MSSQL» para todos los servicios MS SQL cuyo nombre comience por MSSQL y «Filesystem D:» para la unidad.
Las entradas se interpretan como expresiones regulares.
Checkmk tratará como servicios locales todos los servicios que no estén definidos como servicios de clúster.
Finaliza la creación de la regla con «Save» y activa los cambios.
2.3. Realiza el descubrimiento de servicios
Para todos los hosts participantes (hosts del clúster y de los nodos), hay que realizar un nuevo descubrimiento de servicios al final para que todos los servicios de clúster recién definidos se eliminen primero de los nodos y luego se añadan al clúster.
En «Setup > Hosts > Hosts», selecciona primero todos los hosts implicados y, a continuación, selecciona en el menú «Hosts > On Selected hosts > Run bulk service discovery». En la página «Bulk discovery», la primera opción «Add unmonitored services and new host labels» debería dar el resultado deseado.
Haz clic en «Start» para iniciar el descubrimiento de servicios para varios hosts.
Una vez completado con éxito —lo que se indica con el mensaje «Bulk discovery successful»—, sal y activa los cambios.
Para saber si la selección de servicios del clúster ha dado el resultado deseado, puedes ver todos los servicios que ahora están asignados al clúster:
En «Setup > Hosts > Hosts», en la lista de hosts, en la entrada del host del clúster, haz clic en el icono «
» para realizar la edición de los servicios.
En la página siguiente Services of host, todos los servicios del clúster aparecen en «Monitored services»:
Por otro lado, en los hosts de los nodos, esos mismos servicios que se han trasladado al clúster ahora no aparecerán en la lista de servicios supervisados. En el host del nodo, puedes volver a encontrarlos mirando al final de la lista de servicios en la sección Monitored clustered services (located on cluster host):
|
Si realizas local checks en un clúster donde se ha aplicado la regla «Clustered services», puedes usar el conjunto de reglas «Local checks in Checkmk clusters» para influir en el resultado eligiendo entre «Worst state» y «Best state». |
2.4. Descubrimiento automático de servicios
Si dejas que el descubrimiento de servicios se realice automáticamente a través de la comprobación de descubrimiento, debes tener en cuenta un aspecto especial. La regla «Discovery Check» puede eliminar automáticamente los servicios que desaparecen. Sin embargo, si un servicio en clúster se traslada de un nodo a otro, podría registrarse incorrectamente como desaparecido y, por lo tanto, eliminarse. Por otro lado, si omites esta opción, los servicios que realmente hayan desaparecido nunca se eliminarían.
3. Clústeres superpuestos
Es posible que varios clústeres compartan uno o más nodos. En ese caso, se denominan clústeres superpuestos. Para los clústeres superpuestos, necesitas una regla especial que le indique a Checkmk qué servicios de clúster de un nodo compartido deben asignarse a cada clúster.
A continuación te mostramos el procedimiento básico para configurar un clúster superpuesto modificando el ejemplo del clúster de MS SQL Server de un clúster activo/pasivo a uno activo/activo:
En esta configuración, no solo está instalado MS SQL Server en ambos hosts de nodo, sino que se ejecuta una instancia de base de datos independiente en cada uno de los dos nodos. Ambos nodos acceden al medio de almacenamiento compartido, pero en unidades diferentes. Este ejemplo implementa un clúster 100 % solapado porque los dos nodos pertenecen a ambos clústeres.
La ventaja del clúster activo/activo es que se aprovechan mejor los recursos disponibles de los dos nodos. En caso de Failover, la tarea del nodo que ha fallado la asume el nodo alternativo, que entonces ejecuta ambas instancias de base de datos.
Esta configuración de ejemplo consta, por tanto, de los siguientes componentes:
mssql-node01es el primer nodo activo que ejecuta actualmente la instancia de base de datosMSSQL Instance1.mssql-node02es el segundo nodo activo que ejecuta actualmente la instancia de base de datosMSSQL Instance2.mssql-cluster01ymssql-cluster02son los dos clústeres a los que pertenecen ambos nodos.
Solo tienes que modificar ligeramente el primer paso para configurar el clúster activo/pasivo y convertirlo en un clúster activo/activo:
Crea el primer clúster mssql-cluster01 tal y como se ha descrito anteriormente.
A continuación, crea el segundo clúster mssql-cluster02 con los mismos dos hosts de nodo.
En el segundo paso, en lugar de usar el conjunto de reglas general Clustered services para seleccionar los servicios del clúster, usa el conjunto de reglas creado especialmente para clústeres superpuestos Clustered services for overlapping clusters. Esto te permite definir en una regla los servicios del clúster que se eliminarán de los hosts de los nodos y se añadirán al clúster seleccionado.
Para nuestro ejemplo con un solapamiento del 100 %, necesitamos dos de estas reglas: La primera regla define los servicios de clúster de la primera instancia de base de datos, que se ejecutan en el primer nodo por defecto. Dado que, en caso de Failover, estos servicios de clúster se transfieren al segundo nodo, asignamos los servicios a ambos nodos. La segunda regla hace lo mismo para el segundo clúster y la segunda instancia de base de datos.
Empecemos con la primera regla:
En «Setup > General > Rule search», busca el conjunto de reglas «Clustered services for overlapping clusters» y haz clic en él.
Crea una nueva regla.
En «Assign services to the following cluster», introduce el clúster «mssql-cluster01»:
En la caja «Conditions», en «Folder», vuelve a seleccionar la carpeta que contiene los hosts de los nodos.
Activa «Explicit hosts» e introduce ambos hosts de los nodos.
A continuación, activa «Services» y realiza dos entradas allí:
«MSSQL Instance1» para todos los servicios MS SQL de la primera instancia de la base de datos, y «Filesystem D:» para la unidad:
Finaliza la creación de la primera regla con Save.
A continuación, crea la segunda regla, esta vez para el segundo clúster mssql-cluster02 y de nuevo para ambos hosts de nodo.
En Services, introduce ahora MSSQL Instance2 para todos los servicios MS SQL de la segunda instancia de base de datos.
El segundo host de nodo, en el que se ejecuta por defecto la segunda instancia de base de datos, accede a su medio de almacenamiento a través de una unidad diferente; en el siguiente ejemplo, a través de la unidad E::
Guarda también esta regla y, a continuación, activa los dos cambios.
Por último, realiza el descubrimiento de servicios como tercer y último paso de la misma manera que se ha descrito anteriormente: como Bulk discovery para todos los hosts asociados, es decir, los dos hosts del clúster y los dos hosts de nodo.
|
Si varias reglas definen un servicio de clúster, la regla más específica Clustered services for overlapping clusters con la asignación explícita a un clúster concreto tiene prioridad sobre la regla más general Clustered services. Para los dos ejemplos presentados en este artículo, esto significa que las dos últimas reglas específicas creadas nunca permitirían que se aplicara la regla general creada en el primer ejemplo. |