Toma de control y failback en clusters

Los nodos de controlador en clusters pueden estar en uno de una pequeña cantidad de estados posibles en cualquier momento dado:

Estado Ícono Expresión de la CLI/BUI Descripción Sin configurar La agrupación en clusters no está configurada Sistema que no está agrupado en clusters en este estado. El sistema se está configurando o la tarea de configuración del cluster nunca se completó. Propietario Activo (toma de control completada) La agrupación en clusters está configurada, y este nodo ha tomado el control de todos los recursos compartidos del cluster. El sistema pasa a este estado inmediatamente después de que se completa la configuración del cluster desde la interfaz del usuario y cuando detecta que el par ha fallado (es decir, después de una toma de control). Permanece en este estado hasta que un administrador ejecuta manualmente una operación de failback. Segmentado Listo (esperando failback) La agrupación en clusters está configurada, y este nodo no controla ninguno de los recursos compartidos. El sistema se segmenta inmediatamente después de que se completa la configuración del cluster desde la interfaz del usuario del otro nodo o después de un reinicio, desconexión de la fuente de alimentación o algún otro fallo. El nodo permanece en este estado hasta que un administrador ejecuta manualmente una operación de failback. En cluster Activo La agrupación en clusters está configurada, y ambos nodos son propietarios de recursos compartidos según las asignaciones de recursos. Si cada nodo es propietario de una agrupación ZFS y se encuentra en el estado En cluster, los dos nodos forman lo que comúnmente se denomina un cluster activo-activo. - Volviendo a unirse al cluster... El dispositivo se reinició recientemente, o el software de gestión del dispositivo se está reiniciando después de un fallo interno. El estado de los recursos se está resincronizando. - Desconocido (desconectado o reiniciando) El dispositivo par está apagado o se está reiniciando, todos los enlaces de interconexión del cluster están inactivos o todavía no se configuró la agrupación en clusters.

Las transiciones entre estos estados tienen lugar como parte de dos operaciones: toma de control y failback.

La toma de control puede ocurrir en cualquier momento. Se intenta realizarla cuando se detecta un fallo en el par. También se puede iniciar manualmente desde la CLI o la BUI de configuración de clusters, lo cual es muy útil para realizar pruebas. Finalmente, la toma de control se realiza cuando uno de los controladores se inicia y detecta que su par está ausente. Esto permite que se reanude el servicio con normalidad cuando uno de los controladores falla de manera permanente o cuando ambos controladores pierden temporalmente la fuente de alimentación.

El failback nunca se realiza de manera automática. Cuando se repara y se inicia un controlador que ha fallado, se vuelve a unir al cluster (resincroniza su vista de todos los recursos, sus propiedades y su propietario) y espera a que un administrador realice la operación de failback. Hasta ese momento, el controlador original superviviente continúa proporcionando todos los servicios. Esto permite llevar a cabo una investigación completa del problema que ocasionó la toma de control, validar alguna nueva revisión del software o realizar otras tareas administrativas antes de que el controlador regrese al servicio de producción. Como el failback interrumpe la actividad de los clientes, se debe programar en función de las necesidades y los procesos específicos de la empresa. Hay una excepción: supongamos que el controlador A falla y que el controlador B toma el control. Cuando el controlador A se vuelve a unir al cluster, puede tomar el control si detecta que el controlador B está ausente o ha fallado. El principio es que siempre es mejor proporcionar servicio que no hacerlo, aun cuando todavía no se haya podido investigar el problema original. De manera que si nunca se realizará automáticamente un failback a un controlador que haya fallado, sí es posible que se realice una toma de control en cualquier momento.

Después de que configura un cluster, el estado inicial tiene el nodo que inició la configuración en el estado PROPIETARIO y el otro nodo en el estado SEGMENTADO. Después de realizar una operación inicial de failback para entregar al nodo Segmentado su porción de los recursos compartidos, ambos nodos pasan al estado En cluster. Si se apagan ambos nodos del cluster o se produce un fallo en ellos, cuando vuelvan a iniciar simultáneamente se llevará a cabo un arbitraje y uno de ellos tomará el estado Propietario y el otro el estado Segmentado.

Durante el failback, se exportan todos los recursos externos (los asignados al par) y, a continuación, son importados por el par. Una agrupación no se puede importar porque el estado de fallo haría que el nodo Segmentado se reinicie. Si se intenta realizar failback con una agrupación que tiene un fallo, el nodo Segmentado puede reiniciarse a causa del fallo de importación.

Para minimizar el tiempo de inactividad del servicio, las estadísticas y los juegos de datos no están disponibles durante las operaciones de failback y toma de control. No se recopilan datos y se retrasa todo intento de suspender o reanudar estadísticas hasta que las operaciones de failback y toma de control finalizan y la recopilación de datos se reanuda automáticamente.

Temas relacionados

• Cierre de una configuración en clusters (CLI)