ApplicationSet-based conmutación por error de aplicaciones entre clústeres gestionados

La conmutación por error es un proceso que realiza la transición de una aplicación de un clúster primario a un clúster secundario en caso de fallo del clúster primario. Si bien la conmutación por error permite que la aplicación se ejecute en el clúster secundario con una interrupción mínima, tomar una decisión de conmutación por error no informada puede tener consecuencias adversas, como la pérdida total de datos en caso de que se produzca un fallo de replicación inadvertido del clúster primario al secundario. Si ha pasado mucho tiempo desde la última replicación correcta, es mejor esperar hasta que se recupere el primario que ha fallado. LastGroupSyncTime es una métrica crítica que refleja el tiempo transcurrido desde que se produjo la última replicación correcta para todos los PVC asociados a una aplicación. En esencia, mide la salud de la sincronización entre los clústeres primario y secundario. Por lo tanto, antes de iniciar una conmutación por error de un clúster a otro, compruebe esta métrica y sólo inicie la conmutación por error si la LastGroupSyncTime se encuentra dentro de un tiempo razonable en el pasado. Durante la migración tras error, el despliegue de duplicación de Ceph-RBD en el clúster de migración tras error se reduce para garantizar una migración tras error limpia para los volúmenes respaldados por Ceph-RBD como suministrador de almacenamiento.

Antes de empezar

  • Cuando el clúster primario esté en un estado que no sea Preparado, compruebe el estado real del clúster, ya que puede tardar algún tiempo en actualizarse.
    1. Vaya a la pestaña Consola RHACM > Infraestructura > Agrupaciones > Lista de grupos .
    2. Compruebe el estado de ambos clústeres gestionados individualmente antes de realizar una operación de migración tras error.

    Sin embargo, la operación de migración tras error todavía se puede ejecutar cuando el clúster al que está migrando tras error está en un estado Preparado .

  • Ejecute el siguiente comando en el Hub Cluster para comprobar si lastGroupSyncTime está dentro de una ventana aceptable de pérdida de datos, cuando se compara con la hora actual.
    oc get drpc -o yaml -A | grep lastGroupSyncTime

    Ejemplo de salida:

    [...]
lastGroupSyncTime: "2023-07-10T12:40:10Z"

Procedimiento

  1. En el clúster de hub, vaya a Aplicaciones.
  2. Pulse el menú Acciones al final de la fila de la aplicación para ver la lista de acciones disponibles.
  3. Pulse Aplicación de migración tras error.
  4. Cuando se muestre el modal de la aplicación Failover, verifique que los detalles que se presentan sean correctos y verifique el estado de preparación de Failover. Si el estado es Listo con una marca verde, indica que el clúster de destino está listo para que se inicie la conmutación por error.
    Importante:

    Si se producen incoherencias en los datos debido a retrasos en la sincronización, aparece un mensaje de advertencia que indica Datos incoherentes en el clúster de destino. Esto alerta de la posibilidad de pérdida de datos si se inicia la conmutación por error. El mensaje ya no aparece cuando finaliza la sincronización de datos.

  5. Pulse Iniciar.
    Todas las cargas de trabajo del sistema y sus recursos disponibles se transfieren ahora al clúster de destino.
  6. Cierre la ventana modal y realice el seguimiento del estado utilizando la columna Política de datos de la página Aplicaciones .
  7. Verifique que el estado de la actividad se muestre como FailedOver para la aplicación.
    1. Vaya a la pestaña Aplicaciones > Descripción general.
    2. En la columna Política de datos , pulse el enlace política para la aplicación a la que ha aplicado la política.
    3. En la página emergente Política de datos , verifique que puede ver uno o más nombres de política y las actividades en curso asociadas con la política en uso con la aplicación.

Si la sincronización de volúmenes no se produce tras una conmutación por error y las aplicaciones de ApplicationSet-based siguen ejecutándose en ambos clústeres, aplique la siguiente solución:

En el clúster central, elimine el recurso manifestwork que sigue ejecutando las aplicaciones ApplicationSet-based en el clúster desde el que se traspasaron las aplicaciones.

Por ejemplo:
oc delete manifestwork -n rackm14 app-busybox-cephfs-1-rackm14-48b8c