Basculement de réplication

Le basculement permet de changer de rôle de réplication. La réplique devient la source en lecture-écriture et la source d'origine passe en lecture seule, ce qui permet de garantir la disponibilité des données en cas de panne.

Concepts de basculement de réplication

Lorsque vous créez un partage de fichiers répliqué, la réplique extrait les données du partage de fichiers source selon un calendrier de réplication. Les données du partage de fichiers de réplique sont définies en lecture seule. Le basculement change la relation de réplication. Le partage de fichiers de réplique en lecture seule devient le partage de fichiers source en lecture/écriture et le partage d'origine passe en lecture seule. Vous pouvez maintenant monter le partage de fichiers actif et le gérer en tant que partage de fichiers standard.

Lorsque vous lancez une reprise en ligne, vous pouvez choisir ce qui se passe si l'opération de reprise en ligne échoue ou expire. Le délai d'expiration par défaut est de 5 minutes.

Si vous décidez de conserver la relation de réplication, le système "revient" au partage source. Même si l'opération a échoué, le système tente de répliquer à nouveau les données à la prochaine heure prévue. Cette option peut être utilisée lorsque le site principal est planifié pour la maintenance de routine. Vous pouvez revenir au partage d'origine lorsque la maintenance est terminée et que le site est à nouveau stable. La réplication peut reprendre.
Si vous décidez de supprimer la relation de réplication, le système sépare les deux partages de fichiers et ils deviennent des partages de fichiers en lecture / écriture indépendants. Cette option peut être utilisée pour la reprise en ligne dans une situation de reprise après incident lorsqu'il est plus important de démarrer votre application aussi rapidement que possible. Vous pouvez donc poursuivre les opérations normales sur le site de réplique, alors que l'avenir du site d'origine est incertain.

Une opération de basculement ou une séparation de réplique ne peut pas avoir lieu lorsqu'une autre opération est en cours sur le partage de fichiers source ou sur le partage de fichiers répliqué (par exemple, lorsque la taille du partage de fichiers est en cours d'augmentation). L'opération de fractionnement ou de basculement reste en suspens jusqu'à ce que l'autre opération se termine.

Le statut de reprise en ligne indique failover_pending lorsque l'opération est en cours ou lorsque le service attend la fin d'une autre opération.

Reprise en ligne pour la maintenance de routine

Utilisez un basculement lors des opérations de maintenance courantes sur le site principal ou lorsque celui-ci rencontre des problèmes. Le processus fonctionne comme suit.

Le partage de fichiers source dans la zone A refuse toutes les opérations de lecture et d'écriture. Ensuite, le système tente d'extraire une copie finale des données du partage vers le partage de réplique dans la zone B.
Les données sont copiées dans le partage de fichiers de réplique, qui devient accessible en lecture / écriture et qui est considéré comme le nouveau site source. (La relation de réplication est inversée.)
Le service tente de répliquer les données de la source active de la zone B vers le partage d'origine de la zone A comme prévu. Si le transfert de données échoue, le système tente à nouveau à la prochaine heure de réplication planifiée.
Vous pouvez revenir au partage d'origine lorsque la maintenance est terminée et que le site est à nouveau stable. Vous pouvez également conserver le partage de réplique comme partage de source.

Reprise en ligne dans une situation de reprise après incident

La reprise en ligne est également une option pour la reprise après incident. Si l'indisponibilité du site d'origine est confirmée et que vous avez besoin de démarrer votre application dès que possible sur l'emplacement de réplication, optez pour la suppression de la relation de réplication. La suppression de la relation de réplication est une option de la stratégie de repli lorsque vous initiez le basculement. La reprise en ligne pour la reprise après incident fonctionne de la manière suivante:

Le partage de fichiers sur le site source refuse toutes les opérations de lecture et d'écriture et le système tente d'extraire une copie finale des données du partage sur le partage de fichiers réplique.
Lorsque l'extraction de données arrive à expiration et échoue, le service de fichiers interrompt la relation de réplication. Le partage de fichiers réplique devient accessible en lecture / écriture et fonctionne comme un partage de fichiers indépendant. Il peut être monté et géré en tant que partage de fichiers normal.
La relation de réplication ne peut pas être rétablie. Toutefois, vous pouvez configurer une nouvelle réplique sur le site d'origine si et quand le site redevient opérationnel.

En raison de la nature du basculement de reprise après sinistre, il se peut que le dernier ensemble de données n'ait pas été copié. Dans ce cas, vous devrez probablement réconcilier manuellement l'état de votre application lorsque le partage de fichiers source sera à nouveau disponible. Si la zone de partage du fichier source redevient accessible, les données sont disponibles à partir du partage de la réplique afin de procéder au rapprochement entre le moment de l'incident et le point de reprise.

Restrictions

Ces restrictions s'appliquent lorsque vous effectuez une reprise en ligne.

Le délai d'attente par défaut pour une opération de basculement réussie est de 5 minutes. Vous pouvez modifier cette valeur lorsque vous lancez la reprise en ligne.
Un basculement reste en attente lorsque d'autres opérations sont en cours sur le partage de fichiers source, comme l'augmentation de la taille du partage. Une fois l'opération terminée, le basculement reprend.

Initier un basculement dans la console

Accédez à la liste de tous les partages de fichiers. Dans la console IBM Cloud, cliquez sur l'icône de Navigation > Infrastructure > Stockage > Partages de stockage de fichiers.
Cliquez sur le nom d'un partage de fichiers répliqué pour ouvrir sa page de détails.
Dans le menu Actions , sélectionnez Effectuer la reprise en ligne. Avant le basculement, une dernière synchronisation des fichiers est effectuée afin de s'assurer que le partage de basculement contient bien le contenu le plus récent. Une fois l'opération de basculement terminée, le partage de fichiers de réplique devient le nouveau partage de fichiers source. L'ancien partage source devient le nouveau partage de réplique en lecture seule.
Pour définir une valeur de délai d'attente, cochez la case sous Délai d'attente (facultatif) et spécifiez une valeur de temps. Cette valeur indique une limite de temps absolue pour l'exécution du basculement. Définissez un délai d'attente en fonction de la durée pendant laquelle votre partage de fichiers peut rester hors ligne.
Sous Stratégie de reprise en ligne, si l'opération de basculement n'a pas abouti ou a dépassé le délai d'attente, choisissez de conserver la relation de réplication ou de la modifier :
- Conserver la relation de réplication - Aucune modification n'est apportée au partage de fichiers de réplique ou au partage de fichiers source.
- Supprimer la relation de réplication : cette action crée deux partages de fichiers distincts en lecture et en écriture. Etant donné que la relation est rompue, les modifications apportées à un partage de fichiers n'affectent pas l'autre.
Une fois la relation rompue, elle ne peut plus être rétablie.
Cliquez sur Exécuter le basculement. Des messages s'affichent pour indiquer que la reprise en ligne a été demandée et qu'elle est en cours d'exécution.

La page de détails du partage de fichiers est mise à jour, et la relation de réplication indique désormais le partage de fichiers répliqué comme nouveau partage de fichiers source.

Lancement d'un basculement à partir de l'interface de ligne de commande

Avant de pouvoir utiliser l'interface de ligne de commande, vous devez installer l'interface de ligne de commande d'IBM Cloud et le plug-in de l'interface de ligne de commande du VPC. Pour plus d'informations, reportez-vous à la rubrique Configuration requise pour l'interface de ligne de commande.

Localisez le partage de fichiers de réplique sur lequel vous souhaitez basculer en répertoriant tous les partages de fichiers de la région à l'aide de la commande 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

Exécutez la commande ibmcloud is share-replica-failover et indiquez la propriété fallback-policy. Vous pouvez spécifier fail ou split pour cette propriété.
- L'exemple suivant spécifie fail pour la propriété fallback-policy. Si l'opération de basculement échoue ou si le délai d'attente est atteint, l'opération de basculement est considérée comme ayant échoué. Le partage source reste actif et la réplication reprend comme prévu.
```
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.
```
- L'exemple suivant spécifie split pour la propriété fallback-policy. Si l'opération de reprise en ligne échoue, le partage de réplique est fractionné à partir du partage de fichiers source. Si la reprise en ligne échoue, le résultat est deux partages de fichiers en lecture / écriture indépendants.
```
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.
```

Pour plus d'informations sur les options de commande, voir ibmcloud is share-replica-failover.

Lancement d'une reprise en ligne avec l'API

Effectuez une demande POST /shares/{share_id}/failover et indiquez les propriétés timeout et fallback_policy. Le délai minimum est de 300 secondes et le délai maximum est de 3600 secondes. Cette demande lance une reprise en ligne d'un partage de fichiers source vers le partage de répliques, qui est spécifié par l'ID de partage de fichiers de réplique.

La propriété fallback_policy peut avoir les valeurs: split ou fail. Lorsque l'option « fail » est spécifiée, si l'opération de basculement échoue ou si le délai d'attente est atteint, l'opération de basculement échoue. La relation de réplication reste inchangée.

Si vous indiquez split pour la propriété fallback_policy, le partage de réplique est séparé du partage source chaque fois qu'une opération de basculement échoue. On obtient ainsi deux partages de fichiers indépendants en lecture/écriture. Dans ce cas, la synchronisation finale des fichiers n'ayant pas abouti, le partage répliqué pourrait ne pas contenir toutes les données du partage source. Utilisez cette option pour la reprise après incident, lorsqu'il s'avère que le partage de fichiers source est inaccessible.

Si la propriété fallback_policy n'est pas spécifiée dans la demande, le système prend par défaut la valeur split lorsque l'opération de reprise en ligne échoue.

Cet exemple spécifie fail pour la propriété fallback_policy. La propriété timeout est facultative. Vous pouvez utiliser le délai d'expiration par défaut.

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
    }'

Une réponse en cas de réussite indique que la demande de basculement du partage de fichiers a été acceptée.

Vous pouvez utiliser l'API pour vérifier si le basculement de réplication a réussi, est en attente ou a échoué. Effectuez un appel GET /shares/{replica_id}. Examinez la propriété latest_job. Pour plus d'informations, voir Vérification de la réplication avec l'API.

Lancement d'une reprise en ligne avec Terraform

Lorsqu'une reprise en ligne est effectuée, le partage de la réplique devient la source et le partage de la source devient la réplique. La configuration Terraform doit être modifiée pour correspondre à cette modification. L' fallback_policy e définit l'action à entreprendre si la demande de basculement est acceptée mais ne peut être exécutée ou si le délai d'attente est dépassé. Les valeurs admises sont split ou fail. Si vous spécifiez split et que la reprise en ligne échoue, le système interrompt la relation de réplication et les deux partages de fichiers deviennent indépendants l'un de l'autre.

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

Pour plus d'informations sur les arguments et les attributs, voir ibm_is_share_replica_operations.

Etapes suivantes

Gérer la réplication.