Configuración y gestión de clusters de alta disponibilidad

El complemento de alta disponibilidad consta de los siguientes componentes principales:

Puede complementar el complemento de alta disponibilidad con los siguientes componentes:

Pacemaker es un gestor de recursos de clúster. Consigue la máxima disponibilidad para los servicios y recursos de su clúster haciendo uso de las capacidades de mensajería y afiliación de la infraestructura del clúster para disuadir y recuperarse de los fallos a nivel de nodos y recursos.

Si la comunicación con un solo nodo del clúster falla, los demás nodos del clúster deben ser capaces de restringir o liberar el acceso a los recursos a los que el nodo del clúster que ha fallado pueda tener acceso. Esto no puede lograrse contactando con el propio nodo del clúster, ya que éste puede no responder. En su lugar, debe proporcionar un método externo, que se denomina cercado con un agente de cercado. Un agente de valla es un dispositivo externo que puede ser utilizado por el clúster para restringir el acceso a los recursos compartidos por un nodo errante, o para emitir un reinicio duro en el nodo del clúster.

Sin un dispositivo de valla configurado, no tiene forma de saber que los recursos utilizados previamente por el nodo de clúster desconectado han sido liberados, y esto podría impedir que los servicios se ejecuten en cualquiera de los otros nodos de clúster. A la inversa, el sistema puede suponer erróneamente que el nodo del clúster ha liberado sus recursos y esto puede llevar a la corrupción y pérdida de datos. Sin un dispositivo de valla configurado no se puede garantizar la integridad de los datos y la configuración del clúster no será compatible.

Cuando el cercado está en curso, no se permite la ejecución de ninguna otra operación del clúster. El funcionamiento normal del clúster no se puede reanudar hasta que se haya completado el cercado o hasta que el nodo del clúster se reincorpore al clúster después de reiniciar el nodo del clúster.

Para más información sobre el cercado, consulte Cerrado en un cluster de alta disponibilidad de Red Hat.

Para mantener la integridad y la disponibilidad del clúster, los sistemas de clúster utilizan un concepto conocido como quorum para evitar la corrupción y la pérdida de datos. Un clúster tiene quórum cuando más de la mitad de los nodos del clúster están en línea. Para mitigar la posibilidad de corrupción de datos debido a un fallo, Pacemaker detiene por defecto todos los recursos si el clúster no tiene quórum.

El quórum se establece mediante un sistema de votación. Cuando un nodo del clúster no funciona como debería o pierde la comunicación con el resto del clúster, la mayoría de los nodos que funcionan pueden votar para aislar y, si es necesario, cercar el nodo para su mantenimiento.

Por ejemplo, en un cluster de 6 nodos, el quórum se establece cuando al menos 4 nodos del cluster están funcionando. Si la mayoría de los nodos se desconectan o dejan de estar disponibles, el clúster deja de tener quórum y Pacemaker detiene los servicios en clúster.

Las características de quórum en Pacemaker previenen lo que también se conoce como split-brain, un fenómeno en el que el cluster se separa de la comunicación pero cada parte continúa trabajando como clusters separados, potencialmente escribiendo en los mismos datos y posiblemente causando corrupción o pérdida. Para más información sobre lo que significa estar en un estado de cerebro dividido, y sobre los conceptos de quórum en general, vea Explorando los conceptos de los clusters de alta disponibilidad de RHEL - Quórum.

Un cluster de Red Hat Enterprise Linux High Availability Add-On utiliza el servicio votequorum, en conjunto con fencing, para evitar situaciones de split brain. Se asigna un número de votos a cada sistema en el cluster, y las operaciones del cluster se permiten sólo cuando hay una mayoría de votos.

Un cluster resource es una instancia de programa, datos o aplicación que debe ser gestionada por el servicio de cluster. Estos recursos se abstraen mediante agents que proporciona una interfaz estándar para gestionar el recurso en un entorno de clúster.

Para asegurarse de que los recursos se mantienen en buen estado, puede añadir una operación de supervisión a la definición de un recurso. Si no se especifica una operación de supervisión para un recurso, se añade una por defecto.

Puede determinar el comportamiento de un recurso en un cluster configurando constraints. Puede configurar las siguientes categorías de restricciones:

Uno de los elementos más comunes de un clúster es un conjunto de recursos que deben ubicarse juntos, iniciarse secuencialmente y detenerse en el orden inverso. Para simplificar esta configuración, Pacemaker admite el concepto de groups.

El complemento de alta disponibilidad de Red Hat proporciona soporte para volúmenes LVM en dos configuraciones de cluster distintas:

Este ejemplo requiere un único nodo que ejecute RHEL 8 y requiere una dirección IP flotante que resida en la misma red que una de las direcciones IP asignadas estáticamente al nodo.

Mediante este procedimiento, aprenderá a utilizar Pacemaker para configurar un clúster, a mostrar el estado del clúster y a configurar un servicio de clúster. Este ejemplo crea un servidor Apache HTTP como recurso de clúster y muestra cómo responde el clúster cuando el recurso falla.

Este procedimiento proporciona una introducción a la creación de un cluster Pacemaker que ejecuta un servicio que fallará de un nodo a otro cuando el nodo en el que se ejecuta el servicio deje de estar disponible. Mediante este procedimiento, podrá aprender a crear un servicio en un clúster de dos nodos y podrá observar lo que ocurre con ese servicio cuando falla en el nodo en el que se está ejecutando.

Este procedimiento de ejemplo configura un cluster Pacemaker de dos nodos que ejecuta un servidor HTTP Apache. A continuación, puede detener el servicio Apache en un nodo para ver cómo el servicio sigue estando disponible.

Este procedimiento requiere como prerrequisito que tenga dos nodos ejecutando Red Hat Enterprise Linux 8 que puedan comunicarse entre sí, y requiere una dirección IP flotante que resida en la misma red que una de las direcciones IP asignadas estáticamente del nodo.

Puede utilizar la opción -h de pcs para mostrar los parámetros de un comando pcs y una descripción de dichos parámetros. Por ejemplo, el siguiente comando muestra los parámetros del comando pcs resource. Sólo se muestra una parte de la salida.

# pcs resource -h

Aunque no debe editar el archivo de configuración del clúster directamente, puede ver la configuración del clúster en bruto con el comando pcs cluster cib.

Puede guardar la configuración bruta del clúster en un archivo específico con el comando pcs cluster cib filename comando. Si ha configurado previamente un clúster y ya hay un CIB activo, utilice el siguiente comando para guardar el archivo xml sin procesar.

pcs cluster cib filename

Por ejemplo, el siguiente comando guarda el xml crudo del CIB en un archivo llamado testfile.

pcs cluster cib testfile

Al configurar un clúster, puede guardar los cambios de configuración en un archivo específico sin que ello afecte al CIB activo. Esto le permite especificar las actualizaciones de configuración sin actualizar inmediatamente la configuración del clúster que se está ejecutando actualmente con cada actualización individual.

Para obtener información sobre cómo guardar el CIB en un archivo, consulte Visualización de la configuración bruta del clúster. Una vez que haya creado ese archivo, puede guardar los cambios de configuración en ese archivo en lugar de en el CIB activo utilizando la opción -f del comando pcs. Cuando haya completado los cambios y esté listo para actualizar el archivo CIB activo, puede empujar esas actualizaciones del archivo con el comando pcs cluster cib-push.

El siguiente es el procedimiento recomendado para introducir cambios en el archivo CIB. Este procedimiento crea una copia del archivo CIB original guardado y realiza cambios en esa copia. Al transferir esos cambios al CIB activo, este procedimiento especifica la opción diff-against del comando pcs cluster cib-push para que sólo se transfieran al CIB los cambios entre el archivo original y el archivo actualizado. Esto permite a los usuarios realizar cambios en paralelo que no se sobrescriben entre sí, y reduce la carga de Pacemaker, que no necesita analizar todo el archivo de configuración.

Alternativamente, puede empujar todo el contenido actual de un archivo CIB con el siguiente comando.

pcs cluster cib-push filename

Al empujar el archivo CIB completo, Pacemaker comprueba la versión y no permite empujar un archivo CIB que sea más antiguo que el que ya está en un cluster. Si necesita actualizar todo el archivo CIB con una versión más antigua que la que se encuentra actualmente en el clúster, puede utilizar la opción --config del comando pcs cluster cib-push.

pcs cluster cib-push --config filename

Puede mostrar el estado del clúster y de los recursos del clúster con el siguiente comando.

estado de los pcs

Puede mostrar el estado de un componente concreto del clúster con el parámetro commands del comando pcs status, especificando resources, cluster, nodes o pcsd.

estado de los pcs commands

Por ejemplo, el siguiente comando muestra el estado de los recursos del cluster.

recursos del estado de los pcs

El siguiente comando muestra el estado del clúster, pero no los recursos del mismo.

estado del cluster pcs

Utilice el siguiente comando para mostrar la configuración completa del clúster actual.

pcs config

El siguiente procedimiento instala el software del clúster y configura su sistema para la creación del clúster.

Cuando configure su cluster, se recomienda que instale el paquete pcp-zeroconf para la herramienta Performance Co-Pilot (PCP). PCP es la herramienta de monitorización de recursos recomendada por Red Hat para los sistemas RHEL. La instalación del paquete pcp-zeroconf le permite tener a PCP ejecutándose y recopilando datos de monitorización del rendimiento en beneficio de las investigaciones sobre cerramientos, fallos de recursos y otros eventos que perturban el cluster.

Para instalar el paquete pcp-zeroconf, ejecute el siguiente comando.

# yum install pcp-zeroconf

Este paquete permite pmcd y establece la captura de datos a un intervalo de 10 segundos.

Para obtener información sobre la revisión de los datos del PCP, consulte ¿Por qué se ha reiniciado un nodo del cluster de alta disponibilidad de RHEL y cómo puedo evitar que vuelva a ocurrir? en el Portal del cliente de Red Hat.

Este procedimiento crea un cluster de Red Hat High Availability Add-On que consiste en los nodos z1.example.com y z2.example.com.

Puede mostrar el estado actual del clúster con el comando pcs cluster status. Debido a que puede haber un ligero retraso antes de que el clúster esté en funcionamiento cuando inicie los servicios del clúster con la opción --start del comando pcs cluster setup, debe asegurarse de que el clúster esté en funcionamiento antes de realizar cualquier acción posterior en el clúster y su configuración.

[root@z1 ~]# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: z2.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
 Last updated: Thu Oct 11 16:11:18 2018
 Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z2.example.com
 2 Nodes configured
 0 Resources configured

...

Puede utilizar el comando pcs cluster setup para crear un cluster de Alta Disponibilidad de Red Hat con múltiples enlaces especificando todos los enlaces para cada nodo.

El formato del comando para crear un cluster de dos nodos con dos enlaces es el siguiente.

pcs cluster setup cluster_name node1_name addr=node1_link0_address addr=node1_link1_address node2_name addr=node2_link0_address addr=node2_link1_address

Al crear un clúster con múltiples enlaces, debe tener en cuenta lo siguiente.

El siguiente ejemplo crea un cluster de dos nodos llamado my_twolink_cluster con dos nodos, rh80-node1 y rh80-node2. rh80-node1 tiene dos interfaces, la dirección IP 192.168.122.201 como link0 y 192.168.123.201 como link1. rh80-node2 tiene dos interfaces, la dirección IP 192.168.122.202 como link0 y 192.168.123.202 como link1.

# pcs cluster setup my_twolink_cluster rh80-node1 addr=192.168.122.201 addr=192.168.123.201 rh80-node2 addr=192.168.122.202 addr=192.168.123.202

Para obtener información sobre cómo añadir nodos a un clúster existente con múltiples enlaces, consulte Añadir un nodo a un clúster con múltiples enlaces.

Para obtener información sobre la modificación de los enlaces en un clúster existente con múltiples enlaces, consulte Añadir y modificar enlaces en un clúster existente.

Debe configurar un dispositivo de cercado para cada nodo en el cluster. Para obtener información sobre los comandos y opciones de configuración de fencing, consulte Configuración de fencing en un cluster de Red Hat High Availability.

Para obtener información general sobre el cercado y su importancia en un cluster de alta disponibilidad de Red Hat, consulte Cerrado en un cluster de alta disponibilidad de Red Hat.

Este ejemplo utiliza el conmutador de potencia APC con un nombre de host de zapc.example.com para cercar los nodos, y utiliza el agente de cercado fence_apc_snmp. Dado que ambos nodos serán cercados por el mismo agente de cercado, puede configurar ambos dispositivos de cercado como un único recurso, utilizando la opción pcmk_host_map.

Se crea un dispositivo de esgrima configurando el dispositivo como un recurso stonith con el comando pcs stonith create. El siguiente comando configura un recurso stonith llamado myapc que utiliza el agente de esgrima fence_apc_snmp para los nodos z1.example.com y z2.example.com. La opción pcmk_host_map asigna z1.example.com al puerto 1, y z2.example.com al puerto 2. El valor de inicio de sesión y la contraseña para el dispositivo APC son ambos apc. Por defecto, este dispositivo utilizará un intervalo de monitorización de sesenta segundos para cada nodo.

Tenga en cuenta que puede utilizar una dirección IP cuando especifique el nombre de host para los nodos.

[root@z1 ~]# pcs stonith create myapc fence_apc_snmp \
ipaddr="zapc.example.com" \
pcmk_host_map="z1.example.com:1;z2.example.com:2" \
login="apc" passwd="apc"

El siguiente comando muestra los parámetros de un dispositivo STONITH existente.

[root@rh7-1 ~]# pcs stonith config myapc
 Resource: myapc (class=stonith type=fence_apc_snmp)
  Attributes: ipaddr=zapc.example.com pcmk_host_map=z1.example.com:1;z2.example.com:2 login=apc passwd=apc
  Operations: monitor interval=60s (myapc-monitor-interval-60s)

Después de configurar su dispositivo de valla, debe probar el dispositivo. Para obtener información sobre cómo probar un dispositivo de valla, consulte Probar un dispositivo de valla.

Puede hacer una copia de seguridad de la configuración del clúster en un archivo tar con el siguiente comando. Si no especifica un nombre de archivo, se utilizará la salida estándar.

pcs config backup filename

Utilice el siguiente comando para restaurar los archivos de configuración del clúster en todos los nodos desde la copia de seguridad. Si no se especifica un nombre de archivo, se utilizará la entrada estándar. Si se especifica la opción --local, sólo se restaurarán los archivos del nodo actual.

pcs config restore [--local] [filename]

La configuración ideal del cortafuegos para los componentes del clúster depende del entorno local, donde puede ser necesario tener en cuenta consideraciones tales como si los nodos tienen múltiples interfaces de red o si existe un cortafuegos fuera del host.

Si está ejecutando el demonio firewalld, ejecute los siguientes comandos para habilitar los puertos requeridos por el complemento de alta disponibilidad de Red Hat.

# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --add-service=high-availability

Es posible que tenga que modificar qué puertos están abiertos para adaptarse a las condiciones locales.

Tabla 4.1, “Puertos a habilitar para el complemento de alta disponibilidad” muestra los puertos a habilitar para el Complemento de Alta Disponibilidad de Red Hat y proporciona una explicación de para qué se utiliza el puerto.

Este caso de uso requiere que se cree un volumen lógico LVM en el almacenamiento que se comparte entre los nodos del clúster.

El siguiente procedimiento crea un volumen lógico LVM y luego crea un sistema de archivos ext4 en ese volumen para utilizarlo en un cluster de Pacemaker. En este ejemplo, la partición compartida /dev/sdb1 se utiliza para almacenar el volumen físico LVM a partir del cual se creará el volumen lógico LVM.

El siguiente procedimiento configura un servidor HTTP Apache.

Este caso de uso requiere que se creen cuatro recursos de cluster. Para garantizar que todos estos recursos se ejecutan en el mismo nodo, se configuran como parte del grupo de recursos apachegroup. Los recursos a crear son los siguientes, listados en el orden en que se iniciarán.

El siguiente procedimiento crea el grupo de recursos apachegroup y los recursos que contiene el grupo. Los recursos se iniciarán en el orden en que los añada al grupo y se detendrán en el orden inverso en que se añadan al grupo. Ejecute este procedimiento desde un solo nodo del clúster.

En la pantalla de estado del clúster que se muestra en Creación de los recursos y grupos de recursos, todos los recursos se están ejecutando en el nodo z1.example.com. Puede probar si el grupo de recursos falla en el nodo z2.example.com utilizando el siguiente procedimiento para poner el primer nodo en modo standby, tras lo cual el nodo ya no podrá alojar recursos.

Este caso de uso requiere que su sistema incluya los siguientes componentes:

La configuración de un servidor NFS activo/pasivo de alta disponibilidad en un cluster de alta disponibilidad de dos nodos de Red Hat Enterprise Linux requiere que realice los siguientes pasos:

Este caso de uso requiere que se cree un volumen lógico LVM en el almacenamiento que se comparte entre los nodos del clúster.

El siguiente procedimiento crea un volumen lógico LVM y luego crea un sistema de archivos ext4 en ese volumen para utilizarlo en un cluster de Pacemaker. En este ejemplo, la partición compartida /dev/sdb1 se utiliza para almacenar el volumen físico LVM a partir del cual se creará el volumen lógico LVM.

El siguiente procedimiento configura el recurso compartido NFS para la conmutación por error del servicio NFS.

Esta sección proporciona el procedimiento para configurar los recursos del clúster para este caso de uso.

El siguiente procedimiento configura los recursos del sistema. Para garantizar que todos estos recursos se ejecutan en el mismo nodo, se configuran como parte del grupo de recursos nfsgroup. Los recursos se iniciarán en el orden en el que los añada al grupo, y se detendrán en el orden inverso en el que se añaden al grupo. Ejecute este procedimiento desde un solo nodo del clúster.

Puede validar la configuración de su sistema con los siguientes procedimientos. Debería poder montar el sistema de archivos exportado con NFSv3 o NFSv4.

Este procedimiento es un resumen de los pasos necesarios para configurar un cluster Pacemaker que incluya sistemas de archivos GFS2. Este ejemplo crea tres sistemas de archivos GFS2 en tres volúmenes lógicos.

Como requisito previo a este procedimiento, debe instalar e iniciar el software de clúster en todos los nodos y crear un clúster básico de dos nodos. También debe configurar el cercado para el cluster. Para obtener información sobre la creación de un cluster Pacemaker y la configuración del cercado para el cluster, consulte Creación de un cluster de alta disponibilidad de Red Hat con Pacemaker.

En Red Hat Enterprise Linux 8, LVM utiliza el demonio de bloqueo de LVM lvmlockd en lugar de clvmd para gestionar los dispositivos de almacenamiento compartido en un cluster activo/activo. Esto requiere que configure los volúmenes lógicos que su cluster activo/activo requerirá como volúmenes lógicos compartidos. Además, esto requiere que utilice el recurso LVM-activate para gestionar un volumen LVM y que utilice el agente de recursos lvmlockd para gestionar el demonio lvmlockd. Consulte Configuración de un sistema de archivos GFS2 en un clúster para conocer el procedimiento completo para configurar un clúster Pacemaker que incluya sistemas de archivos GFS2 mediante volúmenes lógicos compartidos.

Para utilizar sus volúmenes lógicos existentes de Red Hat Enterprise Linux 7 cuando configure un cluster RHEL8 que incluya sistemas de archivos GFS2, realice el siguiente procedimiento desde el cluster RHEL8. En este ejemplo, el volumen lógico RHEL 7 en cluster es parte del grupo de volúmenes upgrade_gfs_vg.

Después de realizar este procedimiento, puede crear un recurso LVM-activate para cada volumen lógico.

El siguiente procedimiento instala el software del clúster y configura su sistema para la creación del clúster.

Una vez que haya instalado las herramientas de configuración de Pacemaker y haya configurado su sistema para la configuración de clústeres, utilice el siguiente procedimiento para configurar su sistema y utilizar la interfaz web pcsd para configurar un clúster.

Desde la página de Gestión de Clusters, puede crear un nuevo cluster, añadir un cluster existente a la Web UI, o eliminar un cluster de la Web UI.

Una vez que haya creado o añadido un clúster, el nombre del clúster se muestra en la página Gestionar clúster. Al seleccionar el clúster se muestra información sobre el mismo.

Para configurar los componentes y atributos de un clúster, haga clic en el nombre del clúster que aparece en la pantalla Manage Clusters. Esto hace que aparezca la página Nodes, como se describe en Sección 8.4.1, “Configuración de los nodos del clúster con la interfaz web de pcsd”. Esta página muestra un menú en la parte superior de la página con las siguientes entradas:

Cuando se utiliza la interfaz web pcsd, se conecta a uno de los nodos del clúster para mostrar las páginas de gestión del mismo. Si el nodo al que se conecta se cae o deja de estar disponible, puede volver a conectarse al clúster abriendo el navegador a una URL que especifique un nodo diferente del clúster.

Sin embargo, es posible configurar la propia interfaz web pcsd para la alta disponibilidad, en cuyo caso se puede seguir gestionando el clúster sin necesidad de introducir una nueva URL.

Para configurar la interfaz web pcsd para una alta disponibilidad, realice los siguientes pasos.

Utilice el siguiente comando para ver la lista de todos los agentes STONITH disponibles. Cuando se especifica un filtro, este comando muestra sólo los agentes STONITH que coinciden con el filtro.

lista de pcs stonith [filter]

Utilice el siguiente comando para ver las opciones del agente STONITH especificado.

pcs stonith describir stonith_agent

Por ejemplo, el siguiente comando muestra las opciones del agente de la valla para APC sobre telnet/SSH.

# pcs stonith describe fence_apc
Stonith options for: fence_apc
  ipaddr (required): IP Address or Hostname
  login (required): Login Name
  passwd: Login password or passphrase
  passwd_script: Script to retrieve password
  cmd_prompt: Force command prompt
  secure: SSH connection
  port (required): Physical plug number or name of virtual machine
  identity_file: Identity file for ssh
  switch: Physical switch number on device
  inet4_only: Forces agent to use IPv4 addresses only
  inet6_only: Forces agent to use IPv6 addresses only
  ipport: TCP port to use for connection with device
  action (required): Fencing Action
  verbose: Verbose mode
  debug: Write debug information to given file
  version: Display version information and exit
  help: Display help and exit
  separator: Separator for CSV created by operation list
  power_timeout: Test X seconds for status change after ON/OFF
  shell_timeout: Wait X seconds for cmd prompt after issuing command
  login_timeout: Wait X seconds for cmd prompt after login
  power_wait: Wait X seconds after issuing ON/OFF
  delay: Wait X seconds before fencing is started
  retry_on: Count of attempts to retry power on

El formato del comando para crear un dispositivo stonith es el siguiente. Para ver un listado de las opciones de creación de stoniths disponibles, consulte la pantalla pcs stonith -h.

pcs stonith create stonith_id stonith_device_type [stonith_device_options] [op  operation_action operation_options]

El siguiente comando crea un único dispositivo de esgrima para un solo nodo.

# pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s

Algunos dispositivos de cercado sólo pueden cercar un único nodo, mientras que otros dispositivos pueden cercar varios nodos. Los parámetros que se especifican al crear un dispositivo de vallado dependen de lo que el dispositivo de vallado admita y requiera.

Para obtener información sobre los parámetros pcmk_host_list y pcmk_host_map, consulte Propiedades generales de los dispositivos de cercado.

Después de configurar un dispositivo de valla, es imprescindible que pruebe el dispositivo para asegurarse de que funciona correctamente. Para obtener información sobre cómo probar un dispositivo de valla, consulte Probar un dispositivo de valla.

Cualquier nodo del clúster puede cercar cualquier otro nodo del clúster con cualquier dispositivo de cercado, independientemente de si el recurso de cercado está iniciado o detenido. El hecho de que el recurso esté iniciado sólo controla el monitor recurrente para el dispositivo, no si se puede utilizar, con las siguientes excepciones:

enTabla 9.1, “Propiedades generales de los dispositivos de esgrima” se describen las propiedades generales que se pueden establecer para los dispositivos de cercado.

Tabla 9.2, “Propiedades avanzadas de los dispositivos de esgrima” resume las propiedades adicionales que puede configurar para los dispositivos de cercado. Tenga en cuenta que estas propiedades son sólo para uso avanzado.

Además de las propiedades que puede establecer para los dispositivos de vallado individuales, también hay propiedades de cluster que puede establecer que determinan el comportamiento del vallado, como se describe en Tabla 9.3, “Propiedades de los racimos que determinan el comportamiento del cercado”.

Para obtener información sobre la configuración de las propiedades del clúster, consulte Configuración y eliminación de las propiedades del clúster.

El cercado es una parte fundamental de la infraestructura de Red Hat Cluster y por lo tanto es importante validar o probar que el cercado funciona correctamente.

Utilice el siguiente procedimiento para probar un dispositivo de valla.

Pacemaker admite nodos de esgrima con múltiples dispositivos a través de una función denominada topologías de esgrima. Para implementar topologías, cree los dispositivos individuales como lo haría normalmente y luego defina uno o más niveles de esgrima en la sección de topología de esgrima en la configuración.

Utilice el siguiente comando para añadir un nivel de cercado a un nodo. Los dispositivos se dan como una lista separada por comas de ids de stoniths, que se intentan para el nodo en ese nivel.

pcs stonith level add level node devices

El siguiente comando muestra todos los niveles de esgrima que están configurados actualmente.

pcs stonith level

En el siguiente ejemplo, hay dos dispositivos de valla configurados para el nodo rh7-2: un dispositivo de valla ilo llamado my_ilo y un dispositivo de valla apc llamado my_apc. Estos comandos configuran los niveles de vallado para que, si el dispositivo my_ilo falla y no puede vallar el nodo, Pacemaker intente utilizar el dispositivo my_apc. Este ejemplo también muestra la salida del comando pcs stonith level después de configurar los niveles.

# pcs stonith level add 1 rh7-2 my_ilo
# pcs stonith level add 2 rh7-2 my_apc
# pcs stonith level
 Node: rh7-2
  Level 1 - my_ilo
  Level 2 - my_apc

El siguiente comando elimina el nivel de valla para el nodo y los dispositivos especificados. Si no se especifica ningún nodo o dispositivo, el nivel de valla que se especifique se eliminará de todos los nodos.

pcs stonith level remove level [node_id] [stonith_id] ... [stonith_id]

El siguiente comando borra los niveles de valla en el nodo o id de piedra especificado. Si no se especifica un nodo o un id de stonith, se borran todos los niveles de valla.

pcs stonith level clear [node|stonith_id(s)]

Si especifica más de un id de stonith, deben estar separados por una coma y sin espacios, como en el siguiente ejemplo.

# pcs stonith level clear dev_a,dev_b

El siguiente comando verifica que todos los dispositivos y nodos especificados en los niveles de la valla existen.

pcs stonith level verify

Puede especificar nodos en la topología de vallado mediante una expresión regular aplicada a un nombre de nodo y mediante un atributo de nodo y su valor. Por ejemplo, los siguientes comandos configuran los nodos node1, node2, y `node3 para utilizar los dispositivos de vallado apc1 y `apc2, y los nodos `node4, node5, y `node6 para utilizar los dispositivos de vallado apc3 y `apc4.

pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2
pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4

Los siguientes comandos producen los mismos resultados utilizando la coincidencia de atributos de nodos.

pcs node attribute node1 rack=1
pcs node attribute node2 rack=1
pcs node attribute node3 rack=1
pcs node attribute node4 rack=2
pcs node attribute node5 rack=2
pcs node attribute node6 rack=2
pcs stonith level add 1 attrib%rack=1 apc1,apc2
pcs stonith level add 1 attrib%rack=2 apc3,apc4

Cuando se configura el cercado para las fuentes de alimentación redundantes, el clúster debe asegurarse de que cuando se intenta reiniciar un host, ambas fuentes de alimentación se apagan antes de que se vuelva a encender cualquiera de ellas.

Si el nodo nunca pierde completamente la energía, es posible que no libere sus recursos. Esto abre la posibilidad de que los nodos accedan a estos recursos simultáneamente y los corrompan.

Es necesario definir cada dispositivo sólo una vez y especificar que ambos son necesarios para cercar el nodo, como en el siguiente ejemplo.

# pcs stonith create apc1 fence_apc_snmp ipaddr=apc1.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"

# pcs stonith create apc2 fence_apc_snmp ipaddr=apc2.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"

# pcs stonith level add 1 node1.example.com apc1,apc2
# pcs stonith level add 1 node2.example.com apc1,apc2

El siguiente comando muestra todos los dispositivos de valla actualmente configurados. Si se especifica un stonith_id, el comando muestra las opciones de ese dispositivo stonith configurado solamente. Si se especifica la opción --full, se muestran todas las opciones de stonith configuradas.

pcs stonith config [stonith_id] [--full]

Utilice el siguiente comando para modificar o añadir opciones a un dispositivo de cercado actualmente configurado.

pcs stonith update stonith_id [stonith_device_options]

Utilice el siguiente comando para eliminar un dispositivo de cercado de la configuración actual.

pcs stonith delete stonith_id

Puedes cercar un nodo manualmente con el siguiente comando. Si se especifica --off se utilizará la llamada de la API off a stonith que apagará el nodo en lugar de reiniciarlo.

pcs stonith fence node [--off]

En una situación en la que ningún dispositivo stonith es capaz de cercar un nodo aunque ya no esté activo, es posible que el clúster no pueda recuperar los recursos del nodo. Si esto ocurre, después de asegurarse manualmente de que el nodo está apagado, puede introducir el siguiente comando para confirmar al clúster que el nodo está apagado y liberar sus recursos para su recuperación.

pcs stonith confirmar node

Para desactivar un dispositivo/recurso de esgrima, se ejecuta el comando pcs stonith disable.

El siguiente comando desactiva el dispositivo de la valla myapc.

# pcs stonith disable myapc

Para evitar que un nodo específico utilice un dispositivo de esgrima, puede configurar restricciones de ubicación para el recurso de esgrima.

El siguiente ejemplo evita que el dispositivo de valla node1-ipmi se ejecute en node1.

# pcs constraint location node1-ipmi avoids node1

Si su clúster utiliza dispositivos de cercado integrados, debe configurar ACPI (Advanced Configuration and Power Interface) para garantizar un cercado inmediato y completo.

Si un nodo del clúster está configurado para ser cercado por un dispositivo de cercado integrado, desactive el ACPI Soft-Off para ese nodo. La desactivación de ACPI Soft-Off permite que un dispositivo de valla integrado apague un nodo de forma inmediata y completa en lugar de intentar un apagado limpio (por ejemplo, shutdown -h now). De lo contrario, si el ACPI Soft-Off está habilitado, un dispositivo de barrera integrado puede tardar cuatro o más segundos en apagar un nodo (vea la nota que sigue). Además, si el ACPI Soft-Off está habilitado y un nodo entra en pánico o se congela durante el apagado, un dispositivo de cercado integrado puede no ser capaz de apagar el nodo. En esas circunstancias, el cercado se retrasa o no tiene éxito. En consecuencia, cuando un nodo está cercado con un dispositivo de cercado integrado y el ACPI Soft-Off está habilitado, un clúster se recupera lentamente o requiere la intervención administrativa para recuperarse.

La desactivación de ACPI Soft-Off con la BIOS puede no ser posible en algunos sistemas. Si la desactivación de ACPI con la BIOS no es satisfactoria para su clúster, puede desactivar ACPI Soft-Off con uno de los siguientes métodos alternativos:

`Soft-Off by PWR-BTTN` set to
`Instant-Off`

+---------------------------------------------|-------------------+
|    ACPI Function             [Enabled]      |    Item Help      |
|    ACPI Suspend Type         [S1(POS)]      |-------------------|
|  x Run VGABIOS if S3 Resume   Auto          |   Menu Level   *  |
|    Suspend Mode              [Disabled]     |                   |
|    HDD Power Down            [Disabled]     |                   |
|    Soft-Off by PWR-BTTN      [Instant-Off   |                   |
|    CPU THRM-Throttling       [50.0%]        |                   |
|    Wake-Up by PCI card       [Enabled]      |                   |
|    Power On by Ring          [Enabled]      |                   |
|    Wake Up On LAN            [Enabled]      |                   |
|  x USB KB Wake-Up From S3     Disabled      |                   |
|    Resume by Alarm           [Disabled]     |                   |
|  x  Date(of Month) Alarm       0            |                   |
|  x  Time(hh:mm:ss) Alarm       0 :  0 :     |                   |
|    POWER ON Function         [BUTTON ONLY   |                   |
|  x KB Power ON Password       Enter         |                   |
|  x Hot Key Power ON           Ctrl-F1       |                   |
|                                             |                   |
|                                             |                   |
+---------------------------------------------|-------------------+

Los identificadores que se definen para un recurso indican al clúster qué agente debe utilizar para el recurso, dónde encontrar ese agente y a qué estándares se ajusta. Tabla 10.1, “Identificadores de agentes de recursos”, describe estas propiedades.

Tabla 10.2, “Comandos para mostrar las propiedades de los recursos” resume los comandos que muestran las propiedades de los recursos disponibles.

Para cualquier recurso individual, puede utilizar el siguiente comando para mostrar una descripción del recurso, los parámetros que puede establecer para ese recurso y los valores por defecto que se establecen para el recurso.

pcs resource describe [standard:[provider:]]type

Por ejemplo, el siguiente comando muestra información de un recurso de tipo apache.

# pcs resource describe ocf:heartbeat:apache
This is the resource agent for the Apache Web server.
This resource agent operates both version 1.x and version 2.x Apache
servers.

...

Además de los parámetros específicos del recurso, puede configurar opciones adicionales para cualquier recurso. Estas opciones son utilizadas por el clúster para decidir cómo debe comportarse su recurso.

Tabla 10.3, “Meta opciones de recursos” describe las opciones meta de los recursos.

# pcs resource defaults update resource-stickiness=100

# pcs resource defaults set create id=pgsql-stickiness meta resource-stickiness=100 rule resource ::pgsql

# pcs resource defaults
Meta Attrs: rsc_defaults-meta_attributes
  resource-stickiness=100

# pcs resource defaults
Meta Attrs: pgsql-stickiness
  resource-stickiness=100
  Rule: boolean-op=and score=INFINITY
    Expression: resource ::pgsql

pcs resource create resource_id [standard:[provider:]]type [resource options] [meta meta_options...]

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 meta resource-stickiness=50

pcs resource meta resource_id | group_id | clone_id meta_options

# pcs resource meta dummy_resource failure-timeout=20s

# pcs resource config dummy_resource
 Resource: dummy_resource (class=ocf provider=heartbeat type=Dummy)
  Meta Attrs: failure-timeout=20s
  ...

Uno de los elementos más comunes de un clúster es un conjunto de recursos que deben ubicarse juntos, iniciarse secuencialmente y detenerse en el orden inverso. Para simplificar esta configuración, Pacemaker admite el concepto de grupos de recursos.

pcs resource group add group_name resource_id [resource_id] ... [resource_id] [--before resource_id | --after resource_id]

pcs resource create resource_id [standard:[provider:]]type [resource_options] [op operation_action operation_options ] --group group_name

# pcs resource group add shortcut IPaddr Email

pcs resource group remove group_name resource_id ...

lista de grupos de recursos pcs

Puede determinar el comportamiento de un recurso en un cluster configurando restricciones para ese recurso. Puede configurar las siguientes categorías de restricciones:

Pacemaker admite el concepto de grupos de recursos como una forma de abreviar la configuración de un conjunto de restricciones que ubicarán un conjunto de recursos juntos y garantizarán que los recursos se inicien de forma secuencial y se detengan en orden inverso. Una vez que haya creado un grupo de recursos, puede configurar las restricciones del propio grupo del mismo modo que configura las restricciones de los recursos individuales. Para obtener información sobre los grupos de recursos, consulte Configuración de grupos de recursos.

Puede configurar una restricción de ubicación básica para especificar si un recurso prefiere o evita un nodo, con un valor opcional score para indicar el grado relativo de preferencia de la restricción.

El siguiente comando crea una restricción de ubicación para que un recurso prefiera el nodo o nodos especificados. Tenga en cuenta que es posible crear restricciones en un recurso concreto para más de un nodo con un solo comando.

pcs restricción ubicación rsc prefiere node[=score] [node[=score]] ...

El siguiente comando crea una restricción de ubicación para que un recurso evite el nodo o nodos especificados.

pcs restricción ubicación rsc evita node[=score] [node[=score]] ...

Tabla 11.1, “Opciones de restricción de ubicación” resume el significado de las opciones básicas para configurar las restricciones de ubicación.

El siguiente comando crea una restricción de ubicación para especificar que el recurso Webserver prefiere el nodo node1.

pcs ubicación de la restricción El servidor web prefiere el nodo1

pcs admite expresiones regulares en las restricciones de ubicación en la línea de comandos. Estas restricciones se aplican a múltiples recursos basados en la expresión regular que coincide con el nombre del recurso. Esto le permite configurar múltiples restricciones de ubicación con una sola línea de comandos.

El siguiente comando crea una restricción de ubicación para especificar que los recursos dummy0 a dummy9 prefieren node1.

pcs ubicación de la restricción 'regexp mmy[0-9]' prefiere el nodo1

Dado que Pacemaker utiliza expresiones regulares extendidas de POSIX, como se documenta en http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04puede especificar la misma restricción con el siguiente comando.

pcs constraint location 'regexp mmy[[:digit:]]' prefiere el nodo1

Antes de que Pacemaker inicie un recurso en cualquier lugar, primero ejecuta una operación de monitorización única (a menudo denominada "sondeo") en cada nodo, para saber si el recurso ya se está ejecutando. Este proceso de descubrimiento de recursos puede dar lugar a errores en los nodos que no pueden ejecutar el monitor.

Al configurar una restricción de ubicación en un nodo, puede utilizar la opción resource-discovery del comando pcs constraint location para indicar una preferencia sobre si Pacemaker debe realizar el descubrimiento de recursos en este nodo para el recurso especificado. Limitar el descubrimiento de recursos a un subconjunto de nodos en los que el recurso puede ejecutarse físicamente puede aumentar significativamente el rendimiento cuando hay un gran conjunto de nodos. Cuando pacemaker_remote está en uso para ampliar el número de nodos en el rango de cientos de nodos, esta opción debe ser considerada.

El siguiente comando muestra el formato para especificar la opción resource-discovery del comando pcs constraint location. En este comando, un valor positivo para score corresponde a una restricción de ubicación básica que configura un recurso para preferir un nodo, mientras que un valor negativo para score corresponde a una restricción de ubicación básica que configura un recurso para evitar un nodo. Al igual que con las restricciones de ubicación básicas, también puedes utilizar expresiones regulares para los recursos con estas restricciones.

pcs constraint location add id rsc node score [resource-discovery=option]

Tabla 11.2, “Parámetros de restricción de descubrimiento de recursos” resume los significados de los parámetros básicos para configurar las restricciones para el descubrimiento de recursos.

Cuando se utilizan restricciones de ubicación, se puede configurar una estrategia general para especificar en qué nodos puede ejecutarse un recurso:

La elección de configurar su clúster como un clúster opt-in o opt-out depende tanto de sus preferencias personales como de la composición de su clúster. Si la mayoría de sus recursos pueden ejecutarse en la mayoría de los nodos, es probable que una disposición opt-out resulte en una configuración más sencilla. Por otro lado, si la mayoría de los recursos sólo pueden ejecutarse en un pequeño subconjunto de nodos, una configuración opt-in podría ser más sencilla.

# pcs property set symmetric-cluster=false

# pcs constraint location Webserver prefers example-1=200
# pcs constraint location Webserver prefers example-3=0
# pcs constraint location Database prefers example-2=200
# pcs constraint location Database prefers example-3=0

# pcs property set symmetric-cluster=true

# pcs constraint location Webserver prefers example-1=200
# pcs constraint location Webserver avoids example-2=INFINITY
# pcs constraint location Database avoids example-1=INFINITY
# pcs constraint location Database prefers example-2=200

Los recursos tienen un valor resource-stickiness que puedes establecer como un meta atributo cuando creas el recurso, como se describe en Configuración de las opciones meta de los recursos. El valor resource-stickiness determina cuánto quiere permanecer un recurso en el nodo donde se está ejecutando actualmente. Pacemaker tiene en cuenta el valor de resource-stickiness junto con otros ajustes (por ejemplo, los valores de puntuación de las restricciones de ubicación) para determinar si se debe mover un recurso a otro nodo o dejarlo en su lugar.

Por defecto, un recurso se crea con un valor resource-stickiness de 0. El comportamiento predeterminado de Pacemaker cuando resource-stickiness se establece en 0 y no hay restricciones de ubicación es mover los recursos para que se distribuyan uniformemente entre los nodos del clúster. Esto puede dar lugar a que los recursos sanos se muevan con más frecuencia de la deseada. Para evitar este comportamiento, puede establecer el valor predeterminado de resource-stickiness en 1. Este valor predeterminado se aplicará a todos los recursos del clúster. Este pequeño valor puede ser fácilmente anulado por otras restricciones que usted cree, pero es suficiente para evitar que Pacemaker mueva innecesariamente los recursos sanos por el cluster.

El siguiente comando establece el valor por defecto de resource-stickiness en 1.

# pcs resource defaults resource-stickiness=1

Si se establece el valor resource-stickiness, no se moverá ningún recurso a un nodo recién añadido. Si se desea equilibrar los recursos en ese momento, se puede volver a establecer temporalmente el valor resource-stickiness a 0.

Tenga en cuenta que si la puntuación de una restricción de ubicación es mayor que el valor de resource-stickiness, el clúster puede seguir moviendo un recurso sano al nodo donde apunta la restricción de ubicación.

Para obtener más información sobre cómo Pacemaker determina dónde colocar un recurso, consulte Configuración de una estrategia de colocación de nodos.

Una restricción de orden obligatoria indica que la segunda acción no debe iniciarse para el segundo recurso a menos que y hasta que la primera acción se complete con éxito para el primer recurso. Las acciones que pueden ordenarse son stop, start, y adicionalmente para los clones promocionables, demote y promote. Por ejemplo, \ "A entonces B" (que equivale a "iniciar A y luego iniciar B") significa que B no se iniciará a menos que A se inicie con éxito. Una restricción de ordenación es obligatoria si la opción kind de la restricción se establece en Mandatory o se deja por defecto.

Si la opción symmetrical se establece en true o se deja por defecto, las acciones opuestas se ordenarán de forma inversa. Las acciones start y stop son opuestas, y demote y promote son opuestas. Por ejemplo, una ordenación simétrica \ "promocionar A y luego iniciar B" implica \ "detener B y luego degradar A", lo que significa que A no puede ser degradado hasta que y a menos que B se detenga con éxito. Un ordenamiento simétrico significa que los cambios en el estado de A pueden causar acciones que se programen para B. Por ejemplo, dado "A entonces B", si A se reinicia debido a una falla, B se detendrá primero, luego A se detendrá, luego A se iniciará, luego B se iniciará.

Tenga en cuenta que el clúster reacciona a cada cambio de estado. Si el primer recurso se reinicia y vuelve a estar en estado de inicio antes de que el segundo recurso inicie una operación de parada, no será necesario reiniciar el segundo recurso.

Cuando se especifica la opción kind=Optional para una restricción de ordenación, la restricción se considera opcional y sólo se aplica si ambos recursos están ejecutando las acciones especificadas. Cualquier cambio de estado del primer recurso especificado no tendrá efecto en el segundo recurso especificado.

El siguiente comando configura una restricción de ordenación de asesoramiento para los recursos denominados VirtualIP y dummy_resource.

# pcs constraint order VirtualIP then dummy_resource kind=Optional

Una situación común es que un administrador cree una cadena de recursos ordenados, donde, por ejemplo, el recurso A se inicia antes que el recurso B, que se inicia antes que el recurso C. Si su configuración requiere que cree un conjunto de recursos que se coloquen y se inicien en orden, puede configurar un grupo de recursos que contenga esos recursos, como se describe en Configuración de grupos de recursos.

Sin embargo, hay algunas situaciones en las que no es adecuado configurar los recursos que deben iniciarse en un orden determinado como un grupo de recursos:

En estas situaciones, puede crear una restricción de ordenación en un conjunto o conjuntos de recursos con el comando pcs constraint order set.

Puede establecer las siguientes opciones para un conjunto de recursos con el comando pcs constraint order set.

Puede establecer las siguientes opciones de restricción para un conjunto de recursos siguiendo el parámetro setoptions del comando pcs constraint order set.

pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]

Si tiene tres recursos llamados D1, D2, y D3, el siguiente comando los configura como un conjunto de recursos ordenados.

# pcs constraint order set D1 D2 D3

Si tiene seis recursos denominados A, B, C, D, E, y F, este ejemplo configura una restricción de ordenación para el conjunto de recursos que comenzará de la siguiente manera:

La detención de los recursos no se ve influida por esta restricción, ya que se establece symmetrical=false.

# pcs constraint order set A B sequential=false require-all=false set C D set E F sequential=false setoptions symmetrical=false

Es posible que un clúster incluya recursos con dependencias que no son gestionadas por el clúster. En este caso, debe asegurarse de que esas dependencias se inicien antes de iniciar Pacemaker y se detengan después de detenerlo.

Puede configurar su orden de inicio para tener en cuenta esta situación mediante el objetivo systemd resource-agents-deps . Puede crear una unidad de arranque systemd para este objetivo y Pacemaker se ordenará adecuadamente en relación con este objetivo.

Por ejemplo, si un clúster incluye un recurso que depende del servicio externo foo que no está gestionado por el clúster, realice el siguiente procedimiento.

Una dependencia del clúster especificada de esta manera puede ser algo distinto a un servicio. Por ejemplo, puede tener una dependencia para montar un sistema de archivos en /srv, en cuyo caso realizaría el siguiente procedimiento:

La colocación obligatoria se produce cada vez que la puntuación de la restricción es INFINITY o -INFINITY. En estos casos, si la restricción no puede satisfacerse, no se permite la ejecución de source_resource. En el caso de score=INFINITY, esto incluye los casos en los que el target_resource no está activo.

Si necesita que myresource1 se ejecute siempre en la misma máquina que myresource2, deberá añadir la siguiente restricción:

# pcs constraint colocation add myresource1 with myresource2 score=INFINITY

Como se ha utilizado INFINITY, si myresource2 no puede ejecutarse en ninguno de los nodos del clúster (por la razón que sea), entonces myresource1 no podrá ejecutarse.

Alternativamente, puede querer configurar lo contrario, un cluster en el que myresource1 no pueda ejecutarse en la misma máquina que myresource2. En este caso, utilice score=-INFINITY

# pcs constraint colocation add myresource1 with myresource2 score=-INFINITY

De nuevo, al especificar -INFINITY, la restricción es vinculante. Así que si el único lugar que queda por ejecutar es donde ya está myresource2, entonces myresource1 no puede ejecutarse en ningún sitio.

Si la colocación obligatoria se trata de \N "debe" y \N "no debe", entonces la colocación consultiva es la alternativa \N "preferiría si". Para las restricciones con puntuaciones superiores a -INFINITY e inferiores a INFINITY, el clúster intentará acomodar sus deseos pero puede ignorarlos si la alternativa es detener algunos de los recursos del clúster.

Si su configuración requiere que cree un conjunto de recursos que se coloquen y se inicien en orden, puede configurar un grupo de recursos que contenga esos recursos, como se describe en Configuración de grupos de recursos. Sin embargo, hay algunas situaciones en las que no es apropiado configurar los recursos que deben colocarse como un grupo de recursos:

En estas situaciones, puede crear una restricción de colocación en un conjunto o conjuntos de recursos con el comando pcs constraint colocation set.

Puede establecer las siguientes opciones para un conjunto de recursos con el comando pcs constraint colocation set.

Puede establecer la siguiente opción de restricción para un conjunto de recursos siguiendo el parámetro setoptions del comando pcs constraint colocation set.

Cuando se enumeran los miembros de un conjunto, cada miembro se coloca con el anterior. Por ejemplo, "conjunto A B" significa que "B está colocado con A". Sin embargo, cuando se enumeran varios conjuntos, cada conjunto se coloca con el que le sigue. Por ejemplo, "conjunto C D secuencial=falso conjunto A B" significa que "el conjunto C D (donde C y D no tienen relación entre sí) está colocado con el conjunto A B (donde B está colocado con A)".

El siguiente comando crea una restricción de colocación en un conjunto o conjuntos de recursos.

pcs constraint colocation set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]

Utilice el siguiente comando para eliminar las restricciones de colocación con source_resource.

pcs constraint colocation remove source_resource target_resource

El siguiente comando muestra todas las restricciones de ubicación, orden y colocación actuales. Si se especifica la opción --full, muestra los ID de las restricciones internas.

pcs constraint [list|show] [--full]

A partir de RHEL 8.2, el listado de restricciones de recursos ya no muestra por defecto las restricciones caducadas. Para incluir las restricciones caducadas, utilice la opción --all del comando pcs constraint. Esto listará las restricciones expiradas, anotando las restricciones y sus reglas asociadas como (expired) en la pantalla.

El siguiente comando muestra todas las restricciones de ubicación actuales.

pcs constraint location [show [resources [resource...]] | [nodos [node...]]] [--full]

La siguiente orden enumera todas las restricciones de ordenación actuales.

pcs orden de restricción [mostrar]

El siguiente comando muestra todas las restricciones de colocación actuales.

pcs constraint colocation [show]

El siguiente comando enumera las restricciones que hacen referencia a recursos específicos.

pcs constraint ref resource...

El siguiente comando muestra las relaciones entre los recursos del cluster en una estructura de árbol.

pcs resource relations resource [--full]

Si se utiliza la opción --full, el comando muestra información adicional, incluyendo los ID de las restricciones y los tipos de recursos.

En el siguiente ejemplo, hay 3 recursos configurados: C, D y E.

# pcs constraint order start C then start D
Adding C D (kind: Mandatory) (Options: first-action=start then-action=start)
# pcs constraint order start D then start E
Adding D E (kind: Mandatory) (Options: first-action=start then-action=start)

# pcs resource relations C
C
`- order
   |  start C then start D
   `- D
      `- order
         |  start D then start E
         `- E
# pcs resource relations D
D
|- order
|  |  start C then start D
|  `- C
`- order
   |  start D then start E
   `- E
# pcs resource relations E
E
`- order
   |  start D then start E
   `- D
      `- order
         |  start C then start D
         `- C

En el siguiente ejemplo, hay 2 recursos configurados: A y B. Los recursos A y B forman parte del grupo de recursos G.

# pcs resource relations A
A
`- outer resource
   `- G
      `- inner resource(s)
         |  members: A B
         `- B
# pcs resource relations B
B
`- outer resource
   `- G
      `- inner resource(s)
         |  members: A B
         `- A
# pcs resource relations G
G
`- inner resource(s)
   |  members: A B
   |- A
   `- B

Las reglas pueden ser utilizadas para hacer su configuración más dinámica. Un uso de las reglas podría ser asignar máquinas a diferentes grupos de procesamiento (utilizando un atributo de nodo) en función del tiempo y luego utilizar ese atributo al crear restricciones de ubicación.

Cada regla puede contener varias expresiones, expresiones de fecha e incluso otras reglas. Los resultados de las expresiones se combinan basándose en el campo boolean-op de la regla para determinar si la regla se evalúa finalmente como true o false. Lo que ocurre a continuación depende del contexto en el que se utiliza la regla.

Utilice el siguiente comando para configurar una restricción de Pacemaker que utilice reglas. Si se omite score, el valor por defecto es INFINITO. Si se omite resource-discovery, el valor predeterminado es always.

Para obtener información sobre la opción resource-discovery, consulte Limitar el descubrimiento de recursos a un subconjunto de nodos.

Al igual que con las restricciones de ubicación básicas, también puede utilizar expresiones regulares para los recursos con estas restricciones.

Cuando se utilizan reglas para configurar las restricciones de ubicación, el valor de score puede ser positivo o negativo, con un valor positivo que indica "prefiere" y un valor negativo que indica "evita".

pcs constraint location rsc rule [resource-discovery=option] [role=master|slave] [score=score | score-attribute=attribute] expression

La opción expression puede ser una de las siguientes, donde duration_options y date_spec_options son: horas, días del mes, días de la semana, días del año, meses, semanas, años, años de la semana, luna, como se describe en Propiedades de una especificación de fecha.

Tenga en cuenta que las duraciones son una forma alternativa de especificar un final para las operaciones de in_range mediante cálculos. Por ejemplo, puede especificar una duración de 19 meses.

La siguiente restricción de ubicación configura una expresión que es verdadera si ahora es cualquier momento del año 2018.

# pcs constraint location Webserver rule score=INFINITY date-spec years=2018

El siguiente comando configura una expresión que es verdadera de 9 am a 5 pm, de lunes a viernes. Tenga en cuenta que el valor de horas de 16 coincide hasta las 16:59:59, ya que el valor numérico (hora) sigue coincidiendo.

# pcs constraint location Webserver rule score=INFINITY date-spec hours="9-16" weekdays="1-5"

El siguiente comando configura una expresión que es verdadera cuando hay luna llena el viernes trece.

# pcs constraint location Webserver rule date-spec weekdays=5 monthdays=13 moon=4

Para eliminar una regla, utilice el siguiente comando. Si la regla que está eliminando es la última regla de su restricción, la restricción será eliminada.

regla de restricción pcs eliminar rule_id

Para mostrar una lista de todos los recursos configurados, utilice el siguiente comando.

estado de los recursos pcs

Por ejemplo, si su sistema está configurado con un recurso llamado VirtualIP y un recurso llamado WebSite, el comando pcs resource show produce la siguiente salida.

# pcs resource status
 VirtualIP	(ocf::heartbeat:IPaddr2):	Started
 WebSite	(ocf::heartbeat:apache):	Started

Para mostrar una lista de todos los recursos configurados y los parámetros configurados para esos recursos, utilice la opción --full del comando pcs resource config, como en el siguiente ejemplo.

# pcs resource config
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s
 Resource: WebSite (type=apache class=ocf provider=heartbeat)
  Attributes: statusurl=http://localhost/server-status configfile=/etc/httpd/conf/httpd.conf
  Operations: monitor interval=1min

Para mostrar los parámetros configurados para un recurso, utilice el siguiente comando.

pcs resource config resource_id

Por ejemplo, el siguiente comando muestra los parámetros actualmente configurados para el recurso VirtualIP.

# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s

Para modificar los parámetros de un recurso configurado, utilice el siguiente comando.

pcs resource update resource_id [resource_options]

La siguiente secuencia de comandos muestra los valores iniciales de los parámetros configurados para el recurso VirtualIP, el comando para cambiar el valor del parámetro ip y los valores posteriores al comando de actualización.

# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s
# pcs resource update VirtualIP ip=192.169.0.120
# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.169.0.120 cidr_netmask=24
  Operations: monitor interval=30s

Si un recurso ha fallado, aparece un mensaje de fallo cuando se muestra el estado del cluster. Si resuelve ese recurso, puede borrar ese estado de fallo con el comando pcs resource cleanup. Este comando restablece el estado del recurso y failcount, indicando al clúster que olvide el historial de operaciones de un recurso y vuelva a detectar su estado actual.

El siguiente comando limpia el recurso especificado por resource_id.

limpieza de recursos pcs resource_id

Si no se especifica un resource_id, este comando restablece el estado del recurso y failcountpara todos los recursos.

El comando pcs resource cleanup sondea sólo los recursos que se muestran como una acción fallida. Para sondear todos los recursos en todos los nodos puede introducir el siguiente comando:

actualización de recursos pcs

Por defecto, el comando pcs resource refresh sondea sólo los nodos en los que se conoce el estado de un recurso. Para sondear todos los recursos aunque no se conozca su estado, introduzca el siguiente comando:

pcs resource refresh --full

Pacemaker proporciona una variedad de mecanismos para configurar un recurso para que se mueva de un nodo a otro y para mover manualmente un recurso cuando sea necesario.

Puede mover manualmente los recursos de un clúster con los comandos pcs resource move y pcs resource relocate, como se describe en Mover manualmente los recursos del clúster.

Además de estos comandos, también puede controlar el comportamiento de los recursos del clúster habilitando, deshabilitando y prohibiendo recursos, como se describe en Habilitación, deshabilitación y prohibición de recursos del clúster.

Puedes configurar un recurso para que se mueva a un nuevo nodo después de un número definido de fallos, y puedes configurar un clúster para que mueva los recursos cuando se pierda la conectividad externa.

# pcs resource meta dummy_resource migration-threshold=10

# pcs resource defaults migration-threshold=10

# pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=gateway.example.com clone

# pcs constraint location Webserver rule score=-INFINITY pingd lt 1 or not_defined pingd

 Module included in the following assemblies:
//
// <List assemblies here, each on a new line>
// rhel-8-docs/enterprise/assemblies/assembly_managing-cluster-resources.adoc

La forma más fácil de detener un monitor recurrente es eliminarlo. Sin embargo, puede haber ocasiones en las que sólo quiera desactivarlo temporalmente. En estos casos, añada enabled="false" a la definición de la operación. Cuando quiera restablecer la operación de monitorización, ponga enabled="true" en la definición de la operación.

Cuando se actualiza la operación de un recurso con el comando pcs resource update, cualquier opción que no se indique específicamente se restablece a sus valores por defecto. Por ejemplo, si ha configurado una operación de monitorización con un valor de tiempo de espera personalizado de 600, la ejecución de los siguientes comandos restablecerá el valor de tiempo de espera al valor predeterminado de 20 (o al que haya establecido el valor predeterminado con el comando pcs resource ops default ).

# pcs resource update resourceXZY op monitor enabled=false
# pcs resource update resourceXZY op monitor enabled=true

Para mantener el valor original de 600 para esta opción, al restablecer la operación de supervisión debe especificar ese valor, como en el siguiente ejemplo.

# pcs resource update resourceXZY op monitor timeout=600 enabled=true

A partir de Red Hat Enterprise Linux 8.3, puede utilizar el comando pcs para etiquetar los recursos del cluster. Esto le permite habilitar, deshabilitar, gestionar o desgestionar un conjunto específico de recursos con un solo comando.

Puedes crear un recurso y un clon de ese recurso al mismo tiempo con el siguiente comando.

pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta options] clone [clone options]

El nombre del clon será resource_id-clone.

No se puede crear un grupo de recursos y un clon de ese grupo de recursos en un solo comando.

Alternativamente, puede crear un clon de un recurso o grupo de recursos previamente creado con el siguiente comando.

pcs resource clone resource_id | group_name [clone options]...

El nombre del clon será resource_id-clone o group_name-clone.

Cuando se crea un clon de un recurso, el clon toma el nombre del recurso con -clone añadido al nombre. Los siguientes comandos crean un recurso de tipo apache llamado webfarm y un clon de ese recurso llamado webfarm-clone.

# pcs resource create webfarm apache clone

Utilice el siguiente comando para eliminar un clon de un recurso o grupo de recursos. Esto no elimina el recurso o el grupo de recursos en sí.

pcs resource unclone resource_id | group_name

Tabla 17.1, “Opciones de clonación de recursos” describe las opciones que puede especificar para un recurso clonado.

Para lograr un patrón de asignación estable, los clones son ligeramente pegajosos por defecto, lo que indica que tienen una ligera preferencia por permanecer en el nodo donde se están ejecutando. Si no se proporciona ningún valor para resource-stickiness, el clon utilizará un valor de 1. Al ser un valor pequeño, causa una perturbación mínima en los cálculos de puntuación de otros recursos, pero es suficiente para evitar que Pacemaker mueva innecesariamente las copias por el clúster. Para obtener información sobre la configuración de la meta-opción de recursos resource-stickiness, consulte Configuración de meta-opciones de recursos.

En la mayoría de los casos, un clon tendrá una sola copia en cada nodo activo del clúster. Sin embargo, puede establecer clone-max para el clon de recursos a un valor que sea menor que el número total de nodos en el clúster. Si este es el caso, puedes indicar a qué nodos debe asignar preferentemente las copias el clúster con restricciones de ubicación de recursos. Estas restricciones no se escriben de forma diferente a las de los recursos normales, salvo que se debe utilizar el id del clon.

El siguiente comando crea una restricción de ubicación para que el clúster asigne preferentemente el clon de recursos webfarm-clone a node1.

# pcs constraint location webfarm-clone prefers node1

Las restricciones de orden se comportan de forma ligeramente diferente para los clones. En el ejemplo siguiente, como la opción de clon de interleave se deja por defecto como false, ninguna instancia de webfarm-stats se iniciará hasta que todas las instancias de webfarm-clone que necesiten iniciarse lo hayan hecho. Sólo si no se puede iniciar ninguna copia de webfarm-clone, se impedirá que webfarm-stats se active. Además, webfarm-clone esperará a que webfarm-stats se detenga antes de detenerse.

# pcs constraint order start webfarm-clone then webfarm-stats

La colocación de un recurso regular (o de grupo) con un clon significa que el recurso puede ejecutarse en cualquier máquina con una copia activa del clon. El clúster elegirá una copia en función de dónde se ejecute el clon y de las preferencias de ubicación del propio recurso.

También es posible la colocación entre clones. En estos casos, el conjunto de ubicaciones permitidas para el clon se limita a los nodos en los que el clon está (o estará) activo. La asignación se realiza entonces de forma normal.

El siguiente comando crea una restricción de colocación para garantizar que el recurso webfarm-stats se ejecute en el mismo nodo que una copia activa de webfarm-clone.

# pcs constraint colocation add webfarm-stats with webfarm-clone

Los recursos clónicos promocionables son recursos clónicos con el meta atributo promotable establecido en true. Permiten que las instancias estén en uno de los dos modos de funcionamiento; éstos se denominan Master y Slave. Los nombres de los modos no tienen significados específicos, excepto por la limitación de que cuando una instancia se inicia, debe aparecer en el estado Slave.

pcs resource create resource_id [standard:[provider:]]type [resource options] promocionable [clone options]

recurso pcs promocionable resource_id [clone options]

pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]

pcs constraint order [action] resource_id then [action] resource_id [options]

Puede configurar un recurso promocionable para que cuando una acción de promote o monitor falle para ese recurso, o la partición en la que el recurso se está ejecutando pierda el quórum, el recurso se degradará pero no se detendrá completamente. Esto puede evitar la necesidad de una intervención manual en situaciones en las que sería necesario detener completamente el recurso.

La especificación de un metaatributo demote para una operación no afecta al modo en que se determina la promoción de un recurso. Si el nodo afectado sigue teniendo la mayor puntuación de promoción, será seleccionado para ser promovido de nuevo.

El siguiente comando detiene los servicios de cluster en el nodo o nodos especificados. Al igual que con pcs cluster start, la opción --all detiene los servicios de clúster en todos los nodos y, si no se especifica ningún nodo, los servicios de clúster se detienen únicamente en el nodo local.

pcs cluster stop [--all | node] [...]

Puede forzar una parada de los servicios del clúster en el nodo local con el siguiente comando, que realiza un comando kill -9.

pcs cluster kill

Utilice el siguiente comando para habilitar los servicios del clúster, que configura los servicios del clúster para que se ejecuten al inicio en el nodo o nodos especificados. La habilitación permite que los nodos se reincorporen automáticamente al clúster después de que se hayan cercado, lo que minimiza el tiempo que el clúster está a menos de su capacidad. Si los servicios de clúster no están habilitados, un administrador puede investigar manualmente qué ha fallado antes de iniciar los servicios de clúster manualmente, de modo que, por ejemplo, no se permita que un nodo con problemas de hardware vuelva a entrar en el clúster cuando es probable que vuelva a fallar.

pcs cluster enable [--all | node] [...]

Utilice el siguiente comando para configurar los servicios del clúster para que no se ejecuten al inicio en el nodo o nodos especificados.

pcs cluster disable [--all | node] [...]

Utilice el siguiente procedimiento para añadir un nuevo nodo a un cluster existente. Este procedimiento añade nodos de clústeres estándar que ejecutan corosync. Para obtener información sobre la integración de nodos no corosync en un clúster, consulte Integración de nodos no corosync en un clúster: el servicio pacemaker_remote.

En este ejemplo, los nodos de cluster existentes son clusternode-01.example.com, clusternode-02.example.com, y clusternode-03.example.com. El nuevo nodo es newnode.example.com.

En el nuevo nodo a añadir al clúster, realice las siguientes tareas.

En un nodo del clúster existente, realice las siguientes tareas.

En el nuevo nodo a añadir al clúster, realice las siguientes tareas.

El siguiente comando apaga el nodo especificado y lo elimina del archivo de configuración del clúster, corosync.conf, en todos los demás nodos del clúster.

pcs cluster node remove node

Al añadir un nodo a un cluster con múltiples enlaces, debe especificar las direcciones para todos los enlaces. El siguiente ejemplo añade el nodo rh80-node3 a un cluster, especificando la dirección IP 192.168.122.203 para el primer enlace y 192.168.123.203 como segundo enlace.

# pcs cluster node add rh80-node3 addr=192.168.122.203 addr=192.168.123.203

En la mayoría de los casos, puede añadir o modificar los enlaces de un clúster existente sin reiniciar el clúster.

[root@node1 ~] # pcs cluster link add node1=10.0.5.11 node2=10.0.5.12 node3=10.0.5.31 options linknumber=5

[root@node1 ~] # pcs cluster link delete 5

[root@node1 ~] # pcs cluster link remove 5

Si el clúster que va a desplegar está formado por un gran número de nodos y muchos recursos, es posible que tenga que modificar los valores por defecto de los siguientes parámetros para su clúster.

Para conceder permiso a determinados usuarios para gestionar el clúster a través de la interfaz web y para ejecutar comandos de pcs que se conectan a los nodos a través de una red, añada esos usuarios al grupo haclient. Esto debe hacerse en cada nodo del clúster.

Puede utilizar el comando pcs acl para establecer los permisos de los usuarios locales para permitir el acceso de sólo lectura o de lectura-escritura a la configuración del clúster mediante el uso de listas de control de acceso (ACL).

Por defecto, las ACLs no están habilitadas. Cuando las ACLs no están habilitadas, el usuario root y cualquier usuario que sea miembro del grupo haclient en todos los nodos tiene acceso local completo de lectura/escritura a la configuración del cluster mientras que los usuarios que no son miembros de haclient no tienen acceso. Sin embargo, cuando las ACLs están activadas, incluso los usuarios que son miembros del grupo haclient tienen acceso sólo a lo que se le ha concedido a ese usuario por las ACLs.

El establecimiento de permisos para los usuarios locales es un proceso de dos pasos:

El siguiente procedimiento de ejemplo proporciona acceso de sólo lectura para una configuración de clúster a un usuario local llamado rouser. Tenga en cuenta que también es posible restringir el acceso sólo a determinadas partes de la configuración.

Puede configurar las operaciones de supervisión cuando cree un recurso, utilizando el siguiente comando.

pcs resource create resource_id standard:provider:type|type [resource_options] [op operation_action operation_options [operation_type operation_options ]...]

Por ejemplo, el siguiente comando crea un recurso IPaddr2 con una operación de monitorización. El nuevo recurso se llama VirtualIP con una dirección IP de 192.168.0.99 y una máscara de red de 24 en eth2. Se realizará una operación de monitorización cada 30 segundos.

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2 op monitor interval=30s

Alternativamente, puede añadir una operación de supervisión a un recurso existente con el siguiente comando.

pcs resource op add resource_id operation_action [operation_properties]

Utilice el siguiente comando para eliminar una operación de recurso configurada.

pcs resource op remove resource_id operation_name operation_properties

Para cambiar los valores de una opción de monitorización, puede actualizar el recurso. Por ejemplo, puede crear un VirtualIP con el siguiente comando.

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2

Por defecto, este comando crea estas operaciones.

Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
            stop interval=0s timeout=20s (VirtualIP-stop-timeout-20s)
            monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)

Para cambiar la operación de parada del tiempo de espera, ejecute el siguiente comando.

# pcs resource update VirtualIP op stop interval=0s timeout=40s

# pcs resource show VirtualIP
 Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
  Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
              monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)
              stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)

A partir de Red Hat Enterprise Linux 8.3, puede cambiar el valor por defecto de una operación de recursos para todos los recursos con el comando pcs resource op defaults update. El siguiente comando establece un valor global por defecto de timeout de 240 segundos para todas las operaciones de monitoreo.

# pcs resource op defaults update timeout=240s

El comando original pcs resource op defaults name=value que establecía los valores predeterminados de funcionamiento de los recursos en las versiones anteriores de RHEL 8, sigue siendo compatible a menos que haya más de un conjunto de valores predeterminados configurados. Sin embargo, pcs resource op defaults update es ahora la versión preferida del comando.

# pcs resource update VirtualIP op monitor interval=10s

# pcs resource show VirtualIP
 Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
   Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
   Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
               monitor interval=10s (VirtualIP-monitor-interval-10s)
               stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)

# pcs resource op defaults set create id=podman-timeout meta timeout=90s rule resource ::podman

# pcs resource op defaults set create id=stop-timeout meta timeout=120s rule op stop

# pcs resource op defaults set create id=podman-stop-timeout meta timeout=120s rule resource ::podman and op stop

# pcs resource op defaults
Meta Attrs: podman-timeout
  timeout=90s
  Rule: boolean-op=and score=INFINITY
    Expression: resource ::podman

# pcs resource op defaults
Meta Attrs: podman-stop-timeout
  timeout=120s
  Rule: boolean-op=and score=INFINITY
    Expression: resource ::podman
    Expression: op stop

Puede configurar un único recurso con tantas operaciones de monitorización como soporte tenga el agente de recursos. De este modo, puede hacer una comprobación de salud superficial cada minuto y otras progresivamente más intensas a intervalos mayores.

Para configurar operaciones de supervisión adicionales para un recurso que admita comprobaciones más exhaustivas a diferentes niveles, se añade una opción OCF_CHECK_LEVEL=n opción.

Por ejemplo, si se configura el siguiente recurso IPaddr2, por defecto se crea una operación de supervisión con un intervalo de 10 segundos y un valor de tiempo de espera de 20 segundos.

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2

Si la IP virtual admite una comprobación diferente con una profundidad de 10, el siguiente comando hace que Pacemaker realice la comprobación de supervisión más avanzada cada 60 segundos, además de la comprobación normal de la IP virtual cada 10 segundos. (Como se indica, no debe configurar la operación de supervisión adicional con un intervalo de 10 segundos también)

# pcs resource op add VirtualIP monitor interval=60s OCF_CHECK_LEVEL=10

Tabla 21.1, “Propiedades del clúster” resume las propiedades del cluster Pacemaker, mostrando los valores por defecto de las propiedades y los posibles valores que puede establecer para esas propiedades.

Hay propiedades adicionales del clúster que determinan el comportamiento del cercado. Para obtener información sobre estas propiedades, consulte Opciones avanzadas de configuración de cercado.

Para establecer el valor de una propiedad del clúster, utilice el siguiente pcs comando.

pcs property set property=value

Por ejemplo, para establecer el valor de symmetric-cluster en false, utilice el siguiente comando.

# pcs property set symmetric-cluster=false

Puede eliminar una propiedad del clúster de la configuración con el siguiente comando.

propiedad pcs unset property

Alternativamente, puede eliminar una propiedad del clúster de una configuración dejando en blanco el campo de valor del comando pcs property set. Esto restablece esa propiedad a su valor por defecto. Por ejemplo, si ha establecido previamente la propiedad symmetric-cluster a false, el siguiente comando elimina el valor que ha establecido de la configuración y restaura el valor de symmetric-cluster a true, que es su valor por defecto.

# pcs property set symmetic-cluster=

En la mayoría de los casos, cuando se utiliza el comando pcs para mostrar los valores de los distintos componentes del cluster, se puede utilizar pcs list o pcs show indistintamente. En los siguientes ejemplos, pcs list es el formato utilizado para mostrar una lista completa de todos los ajustes de más de una propiedad, mientras que pcs show es el formato utilizado para mostrar los valores de una propiedad específica.

Para mostrar los valores de la configuración de las propiedades que se han establecido para el clúster, utilice el siguiente pcs comando.

lista de propiedades de pcs

Para mostrar todos los valores de las configuraciones de las propiedades del cluster, incluyendo los valores por defecto de las configuraciones de las propiedades que no se han establecido explícitamente, utilice el siguiente comando.

pcs property list --all

Para mostrar el valor actual de una propiedad específica del clúster, utilice el siguiente comando.

pcs property show property

Por ejemplo, para mostrar el valor actual de la propiedad cluster-infrastructure, ejecute el siguiente comando:

# pcs property show cluster-infrastructure
Cluster Properties:
 cluster-infrastructure: cman

Con fines informativos, puede mostrar una lista de todos los valores por defecto de las propiedades, tanto si se han establecido como si no, utilizando el siguiente comando.

propiedad pcs [list|show] --defaults

La capacidad de evitar que los recursos fallen en un cierre de nodo limpio se implementa por medio de las siguientes propiedades del clúster.

El siguiente ejemplo establece la propiedad de clúster shutdown-lock a true en un clúster de ejemplo y muestra el efecto que esto tiene cuando el nodo se apaga y se inicia de nuevo. Este clúster de ejemplo consta de tres nodos: z1.example.com, z2.example.com, y z3.example.com.

Para configurar la capacidad que proporciona un nodo o que requiere un recurso, puedes utilizar utilization attributes para nodos y recursos. Esto se hace estableciendo una variable de utilización para un recurso y asignando un valor a esa variable para indicar lo que el recurso requiere, y luego estableciendo esa misma variable de utilización para un nodo y asignando un valor a esa variable para indicar lo que ese nodo proporciona.

Puede nombrar los atributos de utilización según sus preferencias y definir tantos pares de nombre y valor como necesite su configuración. Los valores de los atributos de utilización deben ser enteros.

# pcs node utilization node1 cpu=2 memory=2048
# pcs node utilization node2 cpu=4 memory=2048

# pcs resource utilization dummy-small cpu=1 memory=1024
# pcs resource utilization dummy-medium cpu=2 memory=2048
# pcs resource utilization dummy-large cpu=3 memory=3072

# pcs property set placement-strategy=balanced

Las siguientes subsecciones resumen cómo Pacemaker asigna los recursos.

Para garantizar que la estrategia de colocación de recursos de Pacemaker funcione de la manera más eficaz, debe tener en cuenta las siguientes consideraciones al configurar su sistema.

El agente NodeUtilization puede detectar los parámetros del sistema de la CPU disponible, la disponibilidad de la memoria del host y la disponibilidad de la memoria del hipervisor y añadir estos parámetros en el CIB. Puede ejecutar el agente como un recurso clonado para que rellene automáticamente estos parámetros en cada nodo.

Para obtener información sobre el agente de recursos NodeUtilization y las opciones de recursos para este agente, ejecute el comando pcs resource describe NodeUtilization.

Tabla 24.1, “Opciones de recursos para los recursos del dominio virtual” describe las opciones de recursos que puede configurar para un recurso VirtualDomain.

Además de las opciones del recurso VirtualDomain, puede configurar la opción de metadatos allow-migrate para permitir la migración en vivo del recurso a otro nodo. Cuando esta opción se establece en true, el recurso puede ser migrado sin pérdida de estado. Cuando esta opción se establece en false, que es el estado por defecto, el dominio virtual se apagará en el primer nodo y luego se reiniciará en el segundo nodo cuando se mueva de un nodo a otro.

Utilice el siguiente procedimiento para crear un recurso VirtualDomain en un clúster para una máquina virtual que haya creado previamente:

Hay algunas características especiales de la configuración del quórum que puede establecer cuando crea un clúster con el comando pcs cluster setup. Tabla 25.1, “Opciones de quórum” resume estas opciones.

Para más información sobre la configuración y el uso de estas opciones, consulte la página de manual votequorum(5).

Puede modificar las opciones generales de quórum de su clúster con el comando pcs quorum update. La ejecución de este comando requiere que el clúster esté detenido. Para obtener información sobre las opciones de quórum, consulte la página de manual votequorum(5).

El formato del comando pcs quorum update es el siguiente.

pcs actualización del quórum [auto_tie_breaker=[0|1]] [last_man_standing=[0|1]] [last_man_standing_window=[time-in-ms] [wait_for_all=[0|1]]

La siguiente serie de comandos modifica la opción de quórum wait_for_all y muestra el estado actualizado de la opción. Tenga en cuenta que el sistema no permite ejecutar este comando mientras el clúster está en funcionamiento.

[root@node1:~]# pcs quorum update wait_for_all=1
Checking corosync is not running on nodes...
Error: node1: corosync is running
Error: node2: corosync is running

[root@node1:~]# pcs cluster stop --all
node2: Stopping Cluster (pacemaker)...
node1: Stopping Cluster (pacemaker)...
node1: Stopping Cluster (corosync)...
node2: Stopping Cluster (corosync)...

[root@node1:~]# pcs quorum update wait_for_all=1
Checking corosync is not running on nodes...
node2: corosync is not running
node1: corosync is not running
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded

[root@node1:~]# pcs quorum config
Options:
  wait_for_all: 1

Una vez que el clúster está funcionando, puede introducir los siguientes comandos de quórum del clúster.

El siguiente comando muestra la configuración del quórum.

pcs quorum [config]

El siguiente comando muestra el estado de ejecución del quórum.

estado del quórum del pcs

Si retira nodos de un clúster durante un largo período de tiempo y la pérdida de esos nodos provocaría la pérdida de quórum, puede cambiar el valor del parámetro expected_votes para el clúster en vivo con el comando pcs quorum expected-votes. Esto permite que el clúster siga funcionando cuando no tiene quórum.

El siguiente comando establece los votos esperados en el cluster en vivo al valor especificado. Esto afecta sólo al clúster en vivo y no cambia el archivo de configuración; el valor de expected_votes se restablece al valor del archivo de configuración en caso de recarga.

pcs quórum esperado-votos votes

En una situación en la que usted sabe que el clúster está inerme pero quiere que el clúster proceda a la gestión de recursos, puede utilizar el comando pcs quorum unblock para evitar que el clúster espere a todos los nodos al establecer el quórum.

# pcs quorum unblock

Puede permitir que un clúster soporte más fallos de nodo de los que permiten las reglas de quórum estándar configurando un dispositivo de quórum independiente que actúe como dispositivo de arbitraje de terceros para el clúster. Se recomienda un dispositivo de quórum para clusters con un número par de nodos. Con clusters de dos nodos, el uso de un dispositivo de quórum puede determinar mejor qué nodo sobrevive en una situación de cerebro dividido.

Al configurar un dispositivo de quórum hay que tener en cuenta lo siguiente.

[root@qdevice:~]# pcs qdevice start net
[root@qdevice:~]# pcs qdevice stop net
[root@qdevice:~]# pcs qdevice enable net
[root@qdevice:~]# pcs qdevice disable net
[root@qdevice:~]# pcs qdevice kill net

[root@node1:~]# pcs quorum device update model algorithm=lms
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Reloading qdevice configuration on nodes...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
node1: corosync-qdevice started
node2: corosync-qdevice started

[root@node1:~]# pcs quorum device remove
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Disabling corosync-qdevice...
node1: corosync-qdevice disabled
node2: corosync-qdevice disabled
Stopping corosync-qdevice...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
Removing qdevice certificates from nodes...
node1: Succeeded
node2: Succeeded

[root@node1:~]# pcs quorum device status
Error: Unable to get quorum status: corosync-qdevice-tool: Can't connect to QDevice socket (is QDevice running?): No such file or directory

[root@qdevice:~]# pcs qdevice destroy net
Stopping quorum device...
quorum device stopped
quorum device disabled
Quorum device 'net' configuration files removed

Cuando utilice uno de los agentes de alerta de muestra, deberá revisar el script para asegurarse de que se adapta a sus necesidades. Estos agentes de muestra se proporcionan como punto de partida para scripts personalizados para entornos de cluster específicos. Tenga en cuenta que mientras Red Hat soporta las interfaces que los scripts de agentes de alerta utilizan para comunicarse con Pacemaker, Red Hat no proporciona soporte para los agentes personalizados en sí mismos.

Para utilizar uno de los agentes de alerta de ejemplo, debe instalar el agente en cada nodo del clúster. Por ejemplo, el siguiente comando instala el script alert_file.sh.sample como alert_file.sh.

# install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample /var/lib/pacemaker/alert_file.sh

Una vez instalado el script, puede crear una alerta que utilice el script.

El siguiente ejemplo configura una alerta que utiliza el agente de alerta instalado alert_file.sh para registrar eventos en un archivo. Los agentes de alerta se ejecutan como el usuario hacluster, que tiene un conjunto mínimo de permisos.

Este ejemplo crea el archivo de registro pcmk_alert_file.log que se utilizará para registrar los eventos. A continuación, crea el agente de alerta y añade la ruta del archivo de registro como su destinatario.

# touch /var/log/pcmk_alert_file.log
# chown hacluster:haclient /var/log/pcmk_alert_file.log
# chmod 600 /var/log/pcmk_alert_file.log
# pcs alert create id=alert_file description="Log events to a file." path=/var/lib/pacemaker/alert_file.sh
# pcs alert recipient add alert_file id=my-alert_logfile value=/var/log/pcmk_alert_file.log

El siguiente ejemplo instala el script alert_snmp.sh.sample como alert_snmp.sh y configura una alerta que utiliza el agente de alerta instalado alert_snmp.sh para enviar los eventos del cluster como traps SNMP. Por defecto, el script enviará todos los eventos excepto las llamadas de monitorización exitosas al servidor SNMP. Este ejemplo configura el formato de marca de tiempo como una opción meta. Después de configurar la alerta, este ejemplo configura un destinatario para la alerta y muestra la configuración de la alerta.

# install --mode=0755 /usr/share/pacemaker/alerts/alert_snmp.sh.sample /var/lib/pacemaker/alert_snmp.sh
# pcs alert create id=snmp_alert path=/var/lib/pacemaker/alert_snmp.sh meta timestamp-format="%Y-%m-%d,%H:%M:%S.%01N"
# pcs alert recipient add snmp_alert value=192.168.1.2
# pcs alert
Alerts:
 Alert: snmp_alert (path=/var/lib/pacemaker/alert_snmp.sh)
  Meta options: timestamp-format=%Y-%m-%d,%H:%M:%S.%01N.
  Recipients:
   Recipient: snmp_alert-recipient (value=192.168.1.2)

El siguiente ejemplo instala el agente alert_smtp.sh y luego configura una alerta que utiliza el agente de alertas instalado para enviar los eventos del clúster como mensajes de correo electrónico. Después de configurar la alerta, este ejemplo configura un destinatario y muestra la configuración de la alerta.

# install --mode=0755 /usr/share/pacemaker/alerts/alert_smtp.sh.sample /var/lib/pacemaker/alert_smtp.sh
# pcs alert create id=smtp_alert path=/var/lib/pacemaker/alert_smtp.sh options email_sender=donotreply@example.com
# pcs alert recipient add smtp_alert value=admin@example.com
# pcs alert
Alerts:
 Alert: smtp_alert (path=/var/lib/pacemaker/alert_smtp.sh)
  Options: email_sender=donotreply@example.com
  Recipients:
   Recipient: smtp_alert-recipient (value=admin@example.com)

El siguiente comando crea una alerta de cluster. Las opciones que se configuran son valores de configuración específicos del agente que se pasan al script del agente de alertas en la ruta que se especifica como variables de entorno adicionales. Si no especifica un valor para id, se generará uno.

pcs alert create path=path [id=alert-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]

Se pueden configurar varios agentes de alerta; el clúster los llamará a todos para cada evento. Los agentes de alerta serán llamados sólo en los nodos del cluster. Serán llamados para eventos que involucren nodos Pacemaker Remote, pero nunca serán llamados en esos nodos.

El siguiente ejemplo crea una simple alerta que llamará a myscript.sh para cada evento.

# pcs alert create id=my_alert path=/path/to/myscript.sh

El siguiente comando muestra todas las alertas configuradas junto con los valores de las opciones configuradas.

pcs alert [config|show]

El siguiente comando actualiza una alerta existente con el valor especificado en alert-id.

pcs alert update alert-id [path=path] [description=description] [options [option=value]...] [meta [meta-option=value]...]

El siguiente comando elimina una alerta con el valor especificado alert-id.

pcs alerta eliminar alert-id

Alternativamente, puede ejecutar el comando pcs alert delete, que es idéntico al comando pcs alert remove. Tanto el comando pcs alert delete como el pcs alert remove permiten especificar más de una alerta para ser eliminada.

Normalmente las alertas se dirigen a un destinatario. Así, cada alerta puede configurarse adicionalmente con uno o varios destinatarios. El clúster llamará al agente por separado para cada destinatario.

El destinatario puede ser cualquier cosa que el agente de alertas pueda reconocer: una dirección IP, una dirección de correo electrónico, un nombre de archivo o cualquier cosa que el agente en particular admita.

El siguiente comando añade un nuevo destinatario a la alerta especificada.

pcs alert recipient add alert-id value=recipient-value [id=recipient-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]

El siguiente comando actualiza un destinatario de alerta existente.

pcs alert recipient update recipient-id [value=recipient-value] [description=description] [options [option=value]...] [meta [meta-option=value]...]

El siguiente comando elimina el destinatario de la alerta especificado.

pcs alerta receptor eliminar recipient-id

Alternativamente, puede ejecutar el comando pcs alert recipient delete, que es idéntico al comando pcs alert recipient remove. Tanto el comando pcs alert recipient remove como el pcs alert recipient delete le permiten eliminar más de un destinatario de alerta.

El siguiente comando de ejemplo añade el destinatario de la alerta my-alert-recipient con un ID de destinatario de my-recipient-id a la alerta my-alert. Esto configurará el cluster para llamar al script de alerta que ha sido configurado para my-alert para cada evento, pasando el destinatario some-address como una variable de entorno.

#  pcs alert recipient add my-alert value=my-alert-recipient id=my-recipient-id options value=some-address

Al igual que en el caso de los agentes de recursos, las opciones meta pueden configurarse para los agentes de alerta para afectar a la forma en que Pacemaker los llama. Tabla 26.1, “Meta Opciones de Alerta” describe las opciones meta de las alertas. Las opciones meta pueden configurarse por agente de alerta así como por destinatario.

El siguiente ejemplo configura una alerta que llama al script myscript.sh y luego añade dos destinatarios a la alerta. El primer destinatario tiene un ID de my-alert-recipient1 y el segundo tiene un ID de my-alert-recipient2. El script será llamado dos veces para cada evento, con cada llamada usando un tiempo de espera de 15 segundos. Una llamada se pasará al destinatario someuser@example.com con una marca de tiempo en el formato %H:%M, mientras que la otra llamada se pasará al destinatario otheruser@example.com con una marca de tiempo en el formato

# pcs alert create id=my-alert path=/path/to/myscript.sh meta timeout=15s
# pcs alert recipient add my-alert value=someuser@example.com id=my-alert-recipient1 meta timestamp-format="%D %H:%M"
# pcs alert recipient add my-alert value=otheruser@example.com id=my-alert-recipient2 meta timestamp-format="%c"

Los siguientes ejemplos secuenciales muestran algunos comandos básicos de configuración de alertas para mostrar el formato a utilizar para crear alertas, añadir destinatarios y mostrar las alertas configuradas.

Tenga en cuenta que, si bien debe instalar los agentes de alerta en sí en cada nodo de un clúster, sólo debe ejecutar los comandos de pcs una vez.

Los siguientes comandos crean una alerta simple, añaden dos destinatarios a la alerta y muestran los valores configurados.

# pcs alert create path=/my/path
# pcs alert recipient add alert value=rec_value
# pcs alert recipient add alert value=rec_value2 id=my-recipient
# pcs alert config
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)

Los siguientes comandos añaden una segunda alerta y un destinatario para esa alerta. El ID de la segunda alerta es my-alert y el valor del destinatario es my-other-recipient. Como no se especifica ningún ID de destinatario, el sistema proporciona un ID de destinatario de my-alert-recipient.

# pcs alert create id=my-alert path=/path/to/script description=alert_description options option1=value1 opt=val meta timeout=50s timestamp-format="%H%B%S"
# pcs alert recipient add my-alert value=my-other-recipient
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=value1
  Meta options: timestamp-format=%H%B%S timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)

Los siguientes comandos modifican los valores de la alerta my-alert y del destinatario my-alert-recipient.

# pcs alert update my-alert options option1=newvalue1 meta timestamp-format="%H%M%S"
# pcs alert recipient update my-alert-recipient options option1=new meta timeout=60s
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=newvalue1
  Meta options: timestamp-format=%H%M%S timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)
    Options: option1=new
    Meta options: timeout=60s

El siguiente comando elimina el destinatario my-alert-recipient de alert.

# pcs alert recipient remove my-recipient
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=newvalue1
  Meta options: timestamp-format="%M%B%S" timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)
    Options: option1=new
    Meta options: timeout=60s

El siguiente comando elimina myalert de la configuración.

# pcs alert remove myalert
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)

Hay tres tipos de alertas de Pacemaker: alertas de nodo, alertas de cercado y alertas de recursos. Las variables de entorno que se pasan a los agentes de alerta pueden variar, dependiendo del tipo de alerta. Tabla 26.2, “Variables de entorno transmitidas a los agentes de alerta” describe las variables de entorno que se pasan a los agentes de alerta y especifica cuándo la variable de entorno está asociada a un tipo de alerta específico.

A la hora de redactar un agente de alerta, hay que tener en cuenta los siguientes aspectos.

El Booth ticket manager es un servicio distribuido que está pensado para ejecutarse en una red física diferente a las redes que conectan los nodos del clúster en sitios concretos. Produce otro clúster suelto, un Booth formation, que se sitúa encima de los clústeres regulares de los sitios. Esta capa de comunicación agregada facilita los procesos de decisión basados en el consenso para las entradas individuales de Booth.

Una cabina ticket es un singleton en la formación de la cabina y representa una unidad de autorización temporal y móvil. Los recursos pueden configurarse para que requieran un determinado ticket para ejecutarse. Esto puede garantizar que los recursos se ejecuten sólo en un sitio a la vez, para el que se ha concedido un ticket o tickets.

Se puede pensar en una formación Booth como un clúster superpuesto que consiste en clústeres que se ejecutan en diferentes sitios, donde todos los clústeres originales son independientes entre sí. Es el servicio Booth el que comunica a los clusters si se les ha concedido un ticket, y es Pacemaker el que determina si se ejecutan recursos en un cluster basándose en una restricción de ticket de Pacemaker. Esto significa que cuando se utiliza el gestor de tickets, cada uno de los clusters puede ejecutar sus propios recursos, así como los recursos compartidos. Por ejemplo, puede haber recursos A, B y C que se ejecuten sólo en un clúster, recursos D, E y F que se ejecuten sólo en el otro clúster, y recursos G y H que se ejecuten en cualquiera de los dos clústeres según lo determine un ticket. También es posible tener un recurso adicional J que podría ejecutarse en cualquiera de los dos clústeres según lo determinado por un ticket separado.

El siguiente procedimiento proporciona un resumen de los pasos que se siguen para configurar una configuración multisitio que utiliza el gestor de tickets de Booth.

Estos comandos de ejemplo utilizan la siguiente disposición:

Estos comandos de ejemplo asumen que los recursos de cluster para un servicio Apache han sido configurados como parte del grupo de recursos apachegroup para cada cluster. No es necesario que los recursos y los grupos de recursos sean los mismos en cada clúster para configurar una restricción de tickets para esos recursos, ya que la instancia de Pacemaker para cada clúster es independiente, pero ese es un escenario común de conmutación por error.

Tenga en cuenta que en cualquier momento del procedimiento de configuración puede introducir el comando pcs booth config para mostrar la configuración de booth para el nodo o clúster actual o el comando pcs booth status para mostrar el estado actual de booth en el nodo local.

Es posible añadir o eliminar tickets en cualquier momento, incluso después de completar este procedimiento. Sin embargo, después de añadir o eliminar un ticket, debe sincronizar los archivos de configuración con los otros nodos y clústeres, así como con el árbitro, y conceder el ticket como se muestra en este procedimiento.

Para obtener información sobre otros comandos de administración de Booth que puede utilizar para limpiar y eliminar archivos de configuración, tickets y recursos de Booth, consulte la pantalla de ayuda de PCS para el comando pcs booth.

La conexión entre los nodos del clúster y pacemaker_remote está asegurada mediante Transport Layer Security (TLS) con cifrado de clave precompartida (PSK) y autenticación a través de TCP (utilizando el puerto 3121 por defecto). Esto significa que tanto el nodo del clúster como el nodo que ejecuta pacemaker_remote deben compartir la misma clave privada. Por defecto, esta clave debe colocarse en /etc/pacemaker/authkey tanto en los nodos del clúster como en los nodos remotos.

El comando pcs cluster node add-guest configura el authkey para los nodos invitados y el comando pcs cluster node add-remote configura el authkey para los nodos remotos.

Un nodo invitado de Pacemaker es un nodo invitado virtual que ejecuta el servicio pacemaker_remote. El nodo invitado virtual es gestionado por el clúster.