Skip to main content
BeeGFS on NetApp with E-Series Storage
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Examine el estado del clúster

Colaboradores

Utilice pc para ver el estado del clúster.

Descripción general

Ejecutando pcs status Desde cualquiera de los nodos del clúster es la forma más sencilla de ver el estado general del clúster y el estado de cada recurso (como los servicios BeeGFS y sus dependencias). En esta sección se describe lo que encontrará en el resultado del pcs status comando.

Comprender el resultado de pcs status

Ejecución pcs status En cualquier nodo de clúster en el que se hayan iniciado los servicios de clúster (Pacemaker y Corosync). La parte superior del resultado le mostrará un resumen del clúster:

[root@ictad22h01 ~]# pcs status
Cluster name: hacluster
Cluster Summary:
  * Stack: corosync
  * Current DC: ictad22h01 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
  * Last updated: Fri Jul  1 13:37:18 2022
  * Last change:  Fri Jul  1 13:23:34 2022 by root via cibadmin on ictad22h01
  * 6 nodes configured
  * 235 resource instances configured

En la siguiente sección se enumeran los nodos del clúster:

Node List:
  * Node ictad22h06: standby
  * Online: [ ictad22h01 ictad22h02 ictad22h04 ictad22h05 ]
  * OFFLINE: [ ictad22h03 ]

Esto indica notablemente cualquier nodo que esté en espera o sin conexión. Los nodos en espera siguen participando en el clúster, pero se marcan como no aptos para ejecutar los recursos. Los nodos que están sin conexión indican que los servicios de clúster no se están ejecutando en ese nodo, ya sea debido a que se detuvo manualmente o porque el nodo se reinició/apague.

Nota Cuando se inician por primera vez los nodos, se detienen los servicios del clúster y se deben iniciar manualmente para evitar que se reproduzcan accidentalmente los recursos de un nodo que no está en buen estado.

Si los nodos están en espera o sin conexión debido a un motivo no administrativo (por ejemplo, un fallo), se mostrará texto adicional junto al estado del nodo entre paréntesis. Por ejemplo, si está desactivada la delimitación y un recurso encuentra un error que verá Node <HOSTNAME>: standby (on-fail). Otro estado posible es Node <HOSTNAME>: UNCLEAN (offline), que se verá brevemente como un nodo está siendo vallado, pero persistirá si falló la cercado indicando que el clúster no puede confirmar el estado del nodo (esto puede bloquear que los recursos comiencen en otros nodos).

En la siguiente sección se muestra una lista de todos los recursos del clúster y sus estados:

Full List of Resources:
  * mgmt-monitor	(ocf::eseries:beegfs-monitor):	 Started ictad22h01
  * Resource Group: mgmt-group:
    * mgmt-FS1	(ocf::eseries:beegfs-target):	 Started ictad22h01
    * mgmt-IP1	(ocf::eseries:beegfs-ipaddr2):	 Started ictad22h01
    * mgmt-IP2	(ocf::eseries:beegfs-ipaddr2):	 Started ictad22h01
    * mgmt-service	(systemd:beegfs-mgmtd):	 Started ictad22h01
[...]

De forma similar a los nodos, se mostrará texto adicional junto al estado del recurso entre paréntesis si hay problemas con el recurso. Por ejemplo, si Pacemaker solicita una detención de recursos y no puede completarse dentro del tiempo asignado, Pacemaker intentará cercar el nodo. Si se desactiva la delimitación o se produce un error en la operación de delimitación, el estado del recurso será FAILED <HOSTNAME> (blocked) Y Pacemaker no podrá iniciarlo en un nodo diferente.

Vale la pena destacar que los clusters de ha de BeeGFS utilizan una serie de agentes de recursos de OCFP personalizados optimizados de BeeGFS. En particular, el monitor BeeGFS es responsable de activar una conmutación por error cuando los recursos de BeeGFS en un nodo determinado no están disponibles.