Toma de control y failback en clusters

Los nodos principales 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. Como ya se explicó, la toma de control se intenta cuando se detecta un fallo en el par. También se puede iniciar manualmente desde la CLI o la BUI de configuración del cluster. Esto resulta útil para hacer pruebas y realizar actualizaciones de software graduales (actualizaciones en las que se actualiza uno de los nodos principales mientras el otro proporciona los servicios con el software anterior, y a continuación se actualiza el segundo nodo principal una vez que se haya validado el nuevo software). Finalmente, la toma de control se realiza cuando uno de los nodos principales se inicia y detecta que su par está ausente. Esto permite que se reanude el servicio con normalidad cuando uno de los nodos principales falla de manera permanente o cuando ambos nodos principales pierden temporalmente la fuente de alimentación.

El failback nunca se realiza de manera automática. Cuando se repara e inicia un nodo principal 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 nodo principal 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 nodo principal 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 nodo principal A falla y que el nodo principal B toma el control. Cuando el nodo principal A se vuelve a unir al cluster, puede tomar el control si detecta que el nodo principal 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 nodo principal que haya fallado, sí es posible que se realice una toma de control en cualquier momento.

Cuando 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.