La toma de control permite que el servicio continúe o vuelva a la normalidad cuando un controlador del cluster falla o pierde energía.
Uno de los controladores intenta automáticamente tomar el control del cluster cuando el controlador detecta que su par está ausente (por ejemplo, se apaga o se reinicia). Después de la toma de control, el controlador que la ejecutó se vuelve el propietario de todos los recursos del cluster y brinda todos los servicios.
Si ambos controladores experimentan un fallo o se apagan, luego de un inicio simultáneo, el software del dispositivo realiza un procedimiento de arbitraje para determinar qué controlador debe continuar con la toma de control.
También es posible realizar la toma de control manualmente, lo que puede ser útil para fines de prueba.
La operación Failback cambia la configuración del cluster de PROPIETARIO-SEGMENTADO (activo-pasivo) a EN CLUSTER-EN CLUSTER (activo-activo). El failback nunca se realiza de manera automática.
Normalmente, el failback se realiza:
Cuando un controlador vuelve a estar en línea después de una toma de control.
Como el último paso de configuración de un cluster. Consulte Actualización de un dispositivo independiente a una configuración en clusters (BUI).
Si el controlador B de un cluster experimenta un fallo o pierde energía, el controlador A de ese cluster toma el control de los recursos asignados al controlador B y brinda todos los servicios del cluster. Una vez reparado y reiniciado el controlador B, un administrador ejecuta la operación de failback para devolver el controlador B al servicio de producción.
Cuando se repara y se inicia, el controlador B:
Se vuelve a unir al cluster y resincroniza su vista de todos los recursos, sus propiedades y su propietario.
Espera que un administrador ejecute una operación de failback.
Mientras el controlador B espera, el controlador A continúa brindando todos los servicios. El controlador A se encuentra en estado Activo (se completó la toma de control) o AKCS_OWNER, y el controlador B se encuentra en estado Listo (a la espera del failback) o AKCS_STRIPPED.
La operación de failback devuelve el controlador B al servicio de producción. El controlador A ha estado brindando todos los servicios desde el fallo en el controlador B. La operación de failback restaura al controlador B los recursos de los que el controlador B era propietario antes del fallo. La operación de failback exporta del controlador A todos los recursos asignados al controlador B, el controlador B importa estos recursos. Después de un failback correcto, tanto el controlador A como el controlador B quedan en estado Activo o EN CLUSTER.
Durante el failback, si el controlador B no puede importar una agrupación debido a un fallo en esta, el controlador B se reinicia. Se produce un fallo en la operación de failback, y el controlador A continúa brindando todos los servicios.
Al programar una operación de failback, tenga en cuenta lo siguiente:
El failback interrumpe la actividad de los clientes del cluster.
Demorar el failback genera interrupciones iguales o mayores si se produce un fallo en el único controlador activo antes de que se ejecute el failback.
Para minimizar el tiempo de inactividad del servicio, no se recopilan datos, y las estadísticas y los juegos de datos no están disponibles durante las operaciones de failback y toma de control. Se demoran las solicitudes para suspender o reanudar las estadísticas hasta que se completan las operaciones de failback y toma de control. La recopilación de datos se reanuda automáticamente una vez completadas las operaciones de failback y toma de control.
Temas relacionados