Migración tras error de réplica

La conmutación por error cambia las funciones de replicación. La réplica pasa a ser la fuente de lectura y escritura, mientras que la fuente original pasa a ser de solo lectura, lo que garantiza la disponibilidad de los datos durante las interrupciones del servicio.

Conceptos de migración tras error de réplica

Al crear un recurso compartido de archivos de réplica, la réplica extrae los datos del recurso compartido de archivos de origen según una programación de replicación. Los datos de la compartición de archivos de réplica se establecen en solo lectura. La migración tras error conmuta la relación de réplica. La compartición de archivos de réplica de solo lectura se convierte en la compartición de archivos de origen de lectura/escritura y la compartición original pasa a ser de solo lectura. Ahora puede montar la compartición de archivos activa y gestionarla como compartición de archivos normal.

Cuando inicia una migración tras error, puede elegir qué sucede si la operación de migración tras error falla o excede el tiempo de espera. El tiempo de espera predeterminado es de 5 minutos.

Si decide mantener la relación de réplica, el sistema "vuelve" a la unidad compartida de origen. Aunque la operación haya fallado, el sistema intenta replicar los datos de nuevo a la siguiente hora programada. Esta opción se puede utilizar cuando el sitio primario está planificado para mantenimiento rutinario. Puede volver a la unidad compartida original cuando se haya completado el mantenimiento y el sitio vuelva a ser estable. La réplica se puede reanudar.
Si decide eliminar la relación de réplica, el sistema divide las dos comparticiones de archivo y se convierten en comparticiones de archivo de lectura/grabación independientes. Esta opción se puede utilizar para la migración tras error en una situación de recuperación tras desastre cuando es más importante iniciar la aplicación lo antes posible. Por lo tanto, puede continuar las operaciones normales en el sitio de réplica, mientras que el futuro del sitio original es incierto.

No se puede llevar a cabo una operación de conmutación por error ni una división de réplica cuando se está realizando otra operación en el recurso compartido de archivos de origen o de réplica (por ejemplo, cuando se está ampliando el tamaño del recurso compartido de archivos). La operación de división o conmutación por error sigue pendiente hasta que finaliza la otra operación.

El estado de migración tras error muestra failover_pending mientras la operación está en curso o mientras el servicio está esperando a que se complete otra operación.

Migración tras error para mantenimiento rutinario

Utiliza una conmutación por error para realizar el mantenimiento rutinario en el sitio principal o cuando este presente problemas. El proceso funciona de la siguiente manera.

La compartición de archivo de origen en la zona A rechaza todas las operaciones de lectura y grabación. A continuación, el sistema intenta extraer una copia final de los datos de la compartición en la compartición de réplica en la zona B.
Los datos se copian en la compartición de archivos de réplica, que pasa a ser de lectura/escritura y se considera el nuevo sitio de origen. (La relación de réplica se invierte).
El servicio intenta replicar datos del origen activo en la zona B a la compartición original en la zona A según lo planificado. Si la transferencia de datos falla, el sistema vuelve a intentarlo en la siguiente hora de réplica planificada.
Puede volver a la unidad compartida original cuando se realice el mantenimiento y el sitio vuelva a ser estable. O bien, puede mantener la compartición de réplica como compartición de origen.

Migración tras error en una situación de recuperación tras desastre

La migración tras error también es una opción para la recuperación tras desastre. Si se confirma que el sitio original no está disponible y necesita que su aplicación se inicie lo antes posible en la ubicación de réplica, opte por eliminar la relación de replicación. La eliminación de la relación de replicación es una opción para la política de reserva cuando se inicia la conmutación por error. La migración tras error para la recuperación tras desastre funciona de la siguiente manera:

La compartición de archivos en el sitio de origen rechaza todas las operaciones de lectura y grabación y el sistema intenta extraer una copia final de los datos de la compartición en la compartición de archivos de réplica.
Cuando la extracción de datos excede el tiempo de espera y falla, el servicio de archivos rompe la relación de réplica. La compartición de archivos de réplica pasa a ser de lectura/grabación y funciona como una compartición de archivos independiente. Se puede montar y gestionar como una compartición de archivos normal.
No se puede restablecer la relación de réplica. Sin embargo, puede configurar una nueva réplica en el sitio original si y cuando el sitio vuelva a estar operativo.

Debido a la naturaleza de la conmutación por error de recuperación ante desastres, es posible que el conjunto de datos más reciente no se haya copiado. En ese caso, es probable que tenga que conciliar el estado de la aplicación manualmente cuando la compartición de archivos de origen esté disponible de nuevo. Si la zona compartida del archivo de origen vuelve a estar disponible, se podrá acceder a los datos de la réplica compartida para realizar la conciliación desde el momento del incidente hasta el punto de recuperación.

Restricciones

Estas restricciones se aplican cuando se realiza una migración tras error.

El tiempo de espera predeterminado para una migración tras error satisfactoria es de 5 minutos. Puede modificar este valor cuando inicie las opciones de migración tras error.
Una conmutación por error queda pendiente cuando se están realizando otras operaciones en el recurso compartido de origen, como ampliar el tamaño del recurso compartido. Cuando finalice la operación, la migración tras error se reanudará.

Iniciar una conmutación por error en la consola

Vaya a la lista de todas las comparticiones de archivos. En la consola IBM Cloud, haga clic en el del menú de navegación > de infraestructura > Almacenamiento > Recursos compartidos de almacenamiento de archivos.
Haz clic en el nombre de un recurso compartido de archivos replicado para abrir su página de detalles.
En el menú Acciones , seleccione Realizar migración tras error. Antes de la conmutación por error, se lleva a cabo una sincronización final de los archivos para garantizar que el recurso compartido de conmutación por error contenga el contenido más reciente. Cuando se completa la migración tras error, la compartición de archivos de réplica se convierte en la nueva compartición de archivos de origen. La compartición de origen anterior se convierte en la nueva compartición de réplica de solo lectura.
Para establecer un valor de tiempo de espera, marque el recuadro en Tiempo de espera (opcional) y especifique un valor de tiempo. Este valor especifica un límite de tiempo absoluto para que finalice la migración tras error. Establezca un tiempo de espera basado en el tiempo que puede tener la compartición de archivos fuera de línea.
En Política de migración tras error, si la operación de migración tras error no tiene éxito o excede el tiempo de espera, elija mantener la relación de réplica o cambiarla:
- Mantener la relación de réplica: no se realizan cambios en la compartición de archivos de réplica ni en la compartición de archivos de origen.
- Eliminar relación de replicación: esta acción crea dos recursos compartidos de archivos independientes para lectura y escritura. Como la relación se ha interrumpido, los cambios en una compartición de archivos no afectan a la otra.
Una vez que se rompe la relación, no se puede restablecer.
Pulse Realizar la migración tras error. Se muestran mensajes que indican que se ha solicitado la migración tras error y que se está realizando.

Se ha actualizado la página de detalles del recurso compartido de archivos, y la relación de replicación muestra el recurso compartido de archivos réplica como el nuevo recurso compartido de archivos de origen.

Inicio de una migración tras error desde la CLI

Para poder utilizar la CLI, debe instalar la CLI de IBM Cloud y el plugin de la CLI de VPC. Para obtener más información, consulte los Requisitos previos de la CLI.

Localice la compartición de archivos de réplica en la que desea realizar la migración tras error listando todos los compartimientos de archivos de la región con el mandato ibmcloud is shares

ibmcloud is shares

Listing shares in all resource groups and region us-south under account Test Account as user test.user@ibm.com...
ID                                          Name                    Lifecycle state   Zone         Profile   Size(GB)   Resource group   Replication role   Accessor binding role   Snapshot count   Snapshot size
r006-a8d6af48-0c97-4c6b-bab1-fbefdc1e1e03   my-file-share           stable            us-south-2   dp2       10         defaults         none               none                    0                0
r006-aaf4bfe9-358c-4faa-a4ec-0b955090b940   my-file-share-2         stable            us-south-2   dp2       10         defaults         none               none                    0                0
r006-a60bfa90-a893-40ad-be34-28ab51a963f9   replica-dal-2           stable            us-south-2   dp2       10         defaults         replica            none                    0                0
r006-3f21e3c3-e12d-425f-ab77-810cabfde8df   source-dal-1            stable            us-south-1   dp2       10         defaults         source             none                    0                0
r006-455b601c-8fc1-4476-8771-4708c49c8ef7   my-replica-share-dal-1  stable            us-south-1   dp2       10         defaults         replica            none                    0                0
r006-4dadac27-cd17-42df-a5fe-1388705d33e0   my-source-share-dal-2   stable            us-south-2   dp2       10         defaults         source             none                    0                0

Ejecute el mandato ibmcloud is share-replica-failover y especifique la propiedad fallback-policy. Puede especificar fail o split para esta propiedad.
- El ejemplo siguiente especifica fail para la propiedad fallback-policy. Si la operación de conmutación por error falla o se agota el tiempo de espera, la operación de conmutación por error no se habrá realizado correctamente. La compartición de origen permanece activa y la réplica se reanuda según lo planificado.
```
ibmcloud is share-replica-failover r006-a60bfa90-a893-40ad-be34-28ab51a963f9 --fallback-policy fail
```
```
The file share r006-a60bfa90-a893-40ad-be34-28ab51a963f9 failover request was accepted under account Test Account as user test.user@ibm.com...
The file share failover request was accepted.
```
- El ejemplo siguiente especifica split para la propiedad fallback-policy. Si la operación de migración tras error falla, la compartición de réplica se divide de la compartición de archivos de origen. Si la migración tras error falla, el resultado son dos comparticiones de archivos de lectura/grabación independientes.
```
ibmcloud is share-replica-failover my-source-share-dal-2 --fallback-policy split
```
```
The file share r006-4dadac27-cd17-42df-a5fe-1388705d33e0 failover request was accepted under account Test Account as user test.user@ibm.com...
The file share failover request was accepted.
```

Para obtener más información sobre las opciones de mandato, consulte ibmcloud is share-replica-failover.

Inicio de una migración tras error con la API

Realice una solicitud de POST /shares/{share_id}/failover y especifique las propiedades timeout y fallback_policy. El tiempo de espera mínimo es de 300 segundos y el máximo de 3600 segundos. Esta solicitud inicia una migración tras error de una compartición de archivo de origen a la compartición de réplica, que se especifica mediante el ID de compartición de archivo de réplica.

La propiedad fallback_policy puede tener los valores: split o fail. Cuando se especifica « fail », si la operación de conmutación por error falla o se agota el tiempo de espera, la operación de conmutación por error no se lleva a cabo con éxito. La relación de réplica permanece sin cambios.

Si especifica split para la propiedad fallback_policy, la compartición de réplica se separa de la compartición de origen siempre que falla una operación de migración tras error. El resultado son dos recursos compartidos de archivos independientes con derechos de lectura y escritura. En este caso, dado que la sincronización final de los archivos no se completó, es posible que el recurso compartido de réplica no contenga todos los datos del recurso compartido de origen. Utilice esta opción para la recuperación tras desastre, cuando se sepa que no se puede acceder a la compartición de archivos de origen.

Si la propiedad fallback_policy no se especifica en la solicitud, el sistema toma el valor predeterminado split cuando falla la operación de migración tras error.

Este ejemplo especifica fail para la propiedad fallback_policy. La propiedad timeout es opcional. Puedes utilizar el tiempo de espera predeterminado.

curl -X POST \
"$vpc_api_endpoint/v1/shares/$replica_id?/failover?version=2023-08-08"\
-H "Authorization: Bearer $iam_token"\
-d '{
     "fallback_policy": "fail",
      "timeout": 600
    }'

Una respuesta satisfactoria indica que se ha aceptado la solicitud de migración tras error de compartición de archivos.

Puedes utilizar la API para comprobar si la conmutación por error de la replicación se ha realizado correctamente, está pendiente o ha fallado. Haga una llamada a GET /shares/{replica_id}. Consulte la propiedad latest_job. Para obtener más información, consulte Verificar la réplica con la API.

Inicio de una migración tras error con Terraform

Cuando se realiza una migración tras error, la compartición de réplica se convierte en el origen y la compartición de origen se convierte en la réplica. Es necesario modificar la configuración de terraform para que coincida con este cambio. La opción « fallback_policy » define la acción que se debe llevar a cabo si la solicitud de conmutación por error se acepta, pero no se puede ejecutar o se agota el tiempo de espera. Los valores aceptados son split o fail. Si especifica split y la migración tras error no es satisfactoria, el sistema rompe la relación de réplica y las dos comparticiones de archivos pasan a ser independientes entre sí.

resource "ibm_is_share_replica_operations" "test" {
  share_replica = ibm_is_share.replica.id
  fallback_policy = "split"
  timeout = 500
}

Para obtener más información sobre los argumentos y atributos, consulte ibm_is_share_replica_operations.

Próximos pasos

Gestione la réplica.