

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Présentation de DR Orchestrator Framework
<a name="dr-orchestrator-framework-overview"></a>

DR Orchestrator Framework fournit une solution en un clic pour orchestrer et automatiser la reprise après sinistre entre régions pour les bases de données. AWS Il utilise [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)et exécute [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)les étapes requises lors du basculement et du retour en arrière. Les machines d'état Step Functions constituent la base de la prise de décision dans le cadre de la conception de l'orchestrateur. Les opérations d'API permettant d'effectuer des actions de basculement ou de retour sont codées dans des fonctions Lambda appelées depuis la machine à états. Les fonctions Lambda sont exécutées [AWS SDK pour Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) APIs pour interagir avec AWS les bases de données.

DR Orchestrator Framework contient deux machines d'état principales qui correspondent aux phases de basculement et de retour en arrière.

Pour Amazon RDS, la phase de basculement favorise la création d'une réplique de lecture RDS interrégionale dans une instance de base de données autonome. Pour Amazon Aurora, lorsque la région principale est en panne lors d'une panne rare et inattendue, son nœud d'écriture n'est pas disponible. La réplication entre le nœud d'écriture et les clusters secondaires s'arrête. Vous devez détacher le cluster secondaire de la base de données globale et le promouvoir en tant que cluster autonome. Les applications peuvent se connecter et envoyer du trafic d'écriture au cluster autonome. Vous pouvez utiliser ce même processus pour transférer [le cluster de](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html) base de données principal de la base de données globale vers les régions secondaires.  Utilisez cette approche pour des scénarios contrôlés tels que les suivants :
+ Maintenance opérationnelle
+ Procédures opérationnelles planifiées
+ Promotion d'un cluster secondaire Amazon ElastiCache (Redis OSS) en tant que nouveau cluster principal

La phase de repli établit la réplication en direct des données entre une région principale active et une nouvelle région secondaire.

Il est essentiel de comprendre que DR Orchestrator s'applique uniquement aux bases de données. Toutes les applications qui font référence à ces bases de données et qui se trouvent dans la même région peuvent avoir besoin d'une solution de basculement en tandem distincte. Après le basculement des bases de données vers la région secondaire, les applications doivent être mises à jour pour se connecter aux nouvelles instances de base de données, qui serviront de source de données.

## Le processus de basculement
<a name="failover-process"></a>

Pour effectuer un basculement, exécutez la machine `DR Orchestrator FAILOVER` d'état. À ce stade, une base de données secondaire est déjà présente dans la région secondaire, soit en tant que réplique en lecture (Amazon RDS), soit en tant que cluster secondaire (Amazon Aurora). Lorsque vous exécutez la machine `DR Orchestrator FAILOVER` d'état, la base de données secondaire devient la base de données principale.

### Architecture d’`DR Orchestrator FAILOVER`
<a name="failover-architecture"></a>

Le schéma suivant montre les concepts du processus de basculement pour Amazon Aurora lors de l'utilisation de DR Orchestrator. Amazon Aurora et Amazon ElastiCache utilisent le même flux de travail, mais avec des machines à états et des fonctions Lambda différentes.



![\[Schéma d'architecture du processus de basculement entre régions.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failover.png)


1. La machine `DR Orchestrator FAILOVER` d'état lit les paramètres JSON d'entrée.

1. Sur la base du `resourceType`**** paramètre, la machine à états appelle les autres machines à états :`Promote RDS Read Replica`,`Failover Aurora Cluster`, ou`Failover ElastiCache`. Si plusieurs ressources sont transmises en entrée, ces machines d'état s'exécutent en parallèle.

1. La machine à `Failover Aurora Cluster`**** états appelle les fonctions Lambda dans chacune des trois étapes suivantes. 

1. La fonction `Resolve imports`**** Lambda est résolue `"! import <export-variable-name>"` avec les valeurs réelles du `App-Stack` AWS CloudFormation modèle.

1. La fonction **`Failover Aurora Cluster`******Lambda**** promeut la réplique en lecture en tant qu'instance de base de données autonome.

1. La fonction **`Check Failover Status`**Lambda vérifie l'état de l'instance de base de données promue. Une fois que le statut est **DISPONIBLE**, la fonction Lambda renvoie un jeton de réussite à la machine d'état appelante et termine.

1. Vous pouvez rediriger vos applications vers la base de données autonome de la région DR (`us-west-2`), qui est désormais la base de données principale.

## Le processus de failback
<a name="failback-process"></a>

Une fois que votre ancienne région principale (`us-east-1`) sera de nouveau active, vous pouvez y revenir, de sorte que la base de données `us-east-1` redevienne la région principale. Pour démarrer le failback, exécutez la machine `DR Orchestrator FAILBACK` d'état. Comme son nom l'indique, cette machine à états commence à répliquer les modifications de votre nouvelle région principale (`us-west-2`) vers l'ancienne région principale (`us-east-1`), qui agit en tant que région secondaire actuelle.

Une fois la réplication établie entre les deux régions, vous pouvez lancer le retour en arrière. Pour revenir en arrière et revenir à votre région principale d'origine (`us-east-1`), exécutez la machine d'`DR Orchestrator FAILOVER`état de la région secondaire actuelle (`us-east-1`) pour la promouvoir en région principale.

### Architecture d’`DR Orchestrator FAILBACK`
<a name="failback-architecture"></a>

Le schéma suivant montre les concepts du processus de repli pour Amazon Aurora lors de l'utilisation de DR Orchestrator.



![\[Schéma d'architecture du processus de repli interrégional.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failback.png)


1. Avant de commencer le retour en arrière, prenez un instantané manuel de base de données à utiliser lors de l'analyse des causes premières (RCA).

   Désactivez également le `DeletionProtection` pour le cluster Aurora dans la région principale précédente (`us-east-1`).

1. La machine `DR Orchestrator FAILBACK` d'état lit les paramètres JSON d'entrée.

1. Sur la base de`resourceType`, la machine `DR Orchestrator FAILBACK` d'état appelle la machine `Create Aurora Secondary DB Cluster`**** d'état.

1. La machine à `Create Aurora Secondary DB Cluster`**** états appelle les fonctions Lambda dans chacune des cinq étapes suivantes.

1. La fonction `Resolve import`**** Lambda est résolue `"! import <export-variable-name>"` avec les valeurs réelles du `App-Stack` CloudFormation modèle.

1. La fonction `Delete DB Instance`**** Lambda supprime l'ancienne instance principale.

1. La fonction `Check DB instance status`**** Lambda vérifie `Delete DB Instance status` jusqu'à ce que la base de données soit supprimée.

1. La**** fonction `Create Read Replica` Lambda crée une réplique de lecture dans la région secondaire à partir de l'instance de base de données située dans la nouvelle région principale.

1. La fonction `Check DB instance status`**** Lambda vérifie l'état de l'instance de base de données de réplique lue. Lorsque le statut est **DISPONIBLE**, la fonction Lambda renvoie un jeton de réussite à la machine d'état appelante, ce qui est terminé.

## DR Orchestrator FAILOVER
<a name="dr-orchestrator-failover"></a>

Utilisez la machine `DR Orchestrator FAILOVER` d'état en cas de reprise après sinistre lorsque la région principale (`us-east-1`) est en panne ou lors d'événements planifiés tels que la maintenance opérationnelle.

La fonction peut être appelée pour basculer sur une ou plusieurs bases de données en parallèle.



![\[Schéma de la machine d'état montrant le basculement pour différents types de ressources.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failover-state-machine.jpg)


La machine d'état accepte les paramètres au format JSON, comme indiqué dans le code suivant :

```
{
  "StatePayload": [
    {
      "layer": 1,
      "resources": [
        {
          "resourceType": "PromoteRDSReadReplica",
          "resourceName": "Promote RDS MySQL Read Replica",
          "parameters": {
            "RDSInstanceIdentifier": "!Import rds-mysql-instance-identifier",
            "TargetClusterIdentifier": "!Import rds-mysql-instance-global-arn"
          }
        },
        {
          "resourceType": "FailoverElastiCacheCluster",
          "resourceName": "Failover ElastiCache Cluster",
          "parameters": {
            "GlobalReplicationGroupId": "!Import demo-redis-cluster-global-replication-group-id",
            "TargetRegion": "!Import demo-redis-cluster-target-region",
            "TargetReplicationGroupId": "!Import demo-redis-cluster-target-replication-group-id"
          }
        }
      ]
    }
  ]
}
```

### Détails des paramètres
<a name="parameters"></a>

Le tableau suivant indique les paramètres utilisés par la machine `DR Orchestrator FAILOVER` d'état.


| Nom du paramètre | Description | Valeurs attendues | 
| --- | --- | --- | 
| layer(obligatoire : numéro) | La séquence de traitement. Toutes les ressources définies dans la couche 1 doivent être exécutées avant que les ressources de couche 2 ne soient exécutées. | 1 ou 2, et ainsi de suite | 
| ressources (obligatoire : tableau de dictionnaires) | Toutes les ressources d'une même couche s'exécutent en parallèle. | <pre>{<br />"resourceType":"String",<br />"resourceName":"String",<br />"parameters":{<br />"<param1>":"<!Import cft-output-1">,<br />....<br />}</pre> | 
| resourceType(obligatoire : chaîne) | Type de ressource pour identifier la ressource | PromoteRDSReadReplica ou FailoverElastiCacheCluster | 
| resourceName(facultatif : chaîne) | Pour identifier à quel portefeuille d'applications appartiennent ces ressources | Promote RDS for MySQL Read Replica | 
| paramètres (obligatoire : tableau de dictionnaire) | Liste des paramètres requis pour basculer ou revenir en arrière dans la AWS base de données | <pre>{<br />          "<param1>":"<!Import<br />                cft-output-1>",<br />                "<param2>":"<!Import<br />                cft-output-2>",<br />                }</pre> | 

## DR Orchestrator FAILBACK
<a name="dr-orchestrator-failback"></a>

Utilisez la machine à `DR Orchestrator FAILBACK` états après l'événement DR, lorsque l'ancienne région principale (`us-east-1`) est active. Vous pouvez créer la [réplique en lecture](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) pour Amazon RDS dans l'ancienne région principale à partir de la nouvelle région principale (`us-west-2`) afin de vous conformer à votre stratégie de reprise après sinistre. Comme il s'agit d'un événement planifié, vous pouvez planifier cette activité pendant le week-end ou en dehors des heures de bureau avec une estimation des temps d'arrêt.



![\[Schéma de la machine d'état montrant les types de ressources pour le retour en cas de défaillance.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failback-state-machine.jpg)


La machine d'état accepte les paramètres au format JSON, comme indiqué dans le code suivant :

```
{
  "StatePayload": [
    {
      "layer": 1,
      "resources": [
        {
          "resourceType": "CreateRDSReadReplica",
          "resourceName": "Create RDS for MySQL Read Replica",
          "parameters": {
            "RDSInstanceIdentifier": "!Import rds-mysql-instance-identifier",
            "TargetClusterIdentifier": "!Import rds-mysql-instance-global-arn",
            "SourceRDSInstanceIdentifier": "!Import rds-mysql-instance-source-identifier",
            "SourceRegion": "!Import rds-mysql-instance-SourceRegion",
            "MultiAZ": "!Import rds-mysql-instance-MultiAZ",
            "DBInstanceClass": "!Import rds-mysql-instance-DBInstanceClass",
            "DBSubnetGroup": "!Import rds-mysql-instance-DBSubnetGroup",
            "DBSecurityGroup": "!Import rds-mysql-instance-DBSecurityGroup",
            "KmsKeyId": "!Import rds-mysql-instance-KmsKeyId",
            "BackupRetentionPeriod": "7",
            "MonitoringInterval": "60",
            "StorageEncrypted": "True",
            "EnableIAMDatabaseAuthentication": "True",
            "DeletionProtection": "True",
            "CopyTagsToSnapshot": "True",
            "AutoMinorVersionUpgrade": "True",
            "Port": "!Import rds-mysql-instance-DBPortNumber",
            "MonitoringRoleArn": "!Import rds-mysql-instance-RDSMonitoringRole"
          }
        }
      ]
    }
  ]
}
```