

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Überblick über das DR Orchestrator Framework
<a name="dr-orchestrator-framework-overview"></a>

DR Orchestrator Framework bietet eine Ein-Klick-Lösung zur Orchestrierung und Automatisierung regionsübergreifender DR für Datenbanken. AWS Es verwendet [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)und [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)führt die erforderlichen Schritte während des Failovers und des Failbacks aus. Die Step Functions Functions-Zustandsmaschinen bilden die Grundlage für die Entscheidungsfindung innerhalb des Orchestrator-Designs. Die API-Operationen zur Durchführung von Failover- oder Failback-Aktionen sind in Lambda-Funktionen codiert, die von der Zustandsmaschine aus aufgerufen werden. Die Lambda-Funktionen werden ausgeführt [AWS SDK für Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) APIs , um mit AWS Datenbanken zu interagieren.

Das DR Orchestrator Framework enthält zwei Hauptzustandsmaschinen, die den Failover- und Failback-Phasen entsprechen.

Bei Amazon RDS wird in der Failover-Phase eine regionsübergreifende RDS-Read Replica in eine eigenständige DB-Instance umgewandelt. Bei Amazon Aurora ist der Writer-Knoten nicht verfügbar, wenn die primäre Region während eines seltenen, unerwarteten Ausfalls ausgefallen ist. Die Replikation zwischen dem Writer-Knoten und den sekundären Clustern wird gestoppt. Sie müssen den sekundären Cluster von der globalen Datenbank trennen und ihn zu einem eigenständigen Cluster heraufstufen. Anwendungen können eine Verbindung herstellen und Schreibdatenverkehr an den eigenständigen Cluster senden. Sie können denselben Prozess verwenden, um vom primären DB-Cluster der globalen Datenbank zu den sekundären Regionen zu [wechseln](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html).  Verwenden Sie diesen Ansatz für kontrollierte Szenarien wie die folgenden:
+ Betriebliche Wartung
+ Geplante Betriebsabläufe
+ Förderung eines sekundären Clusters von Amazon ElastiCache (Redis OSS) als Ihrem neuen primären Cluster

In der Failback-Phase wird die Live-Replikation von Daten zwischen einer primären Live-Region und einer neuen sekundären Region eingerichtet.

Es ist wichtig zu verstehen, dass DR Orchestrator nur für Datenbanken gilt. Alle Anwendungen, die auf diese Datenbanken verweisen und sich in derselben Region befinden, benötigen möglicherweise eine separate Tandem-Failover-Lösung. Nach dem Failover der Datenbanken in die sekundäre Region müssen die Anwendungen aktualisiert werden, um eine Verbindung zu den neuen Datenbankinstanzen herzustellen, die als Datenquelle dienen.

## Der Failover-Prozess
<a name="failover-process"></a>

Führen Sie die `DR Orchestrator FAILOVER` Zustandsmaschine aus, um einen Failover durchzuführen. Zu diesem Zeitpunkt ist in der sekundären Region bereits eine sekundäre Datenbank vorhanden, entweder als Read Replica (Amazon RDS) oder als sekundärer Cluster (Amazon Aurora). Wenn Sie die `DR Orchestrator FAILOVER` Zustandsmaschine ausführen, wird die sekundäre Datenbank zur primären Datenbank heraufgestuft.

### `DR Orchestrator FAILOVER`-Architektur
<a name="failover-architecture"></a>

Das folgende Diagramm zeigt die Konzepte des Failover-Prozesses für Amazon Aurora bei Verwendung von DR Orchestrator. Amazon Aurora und Amazon ElastiCache verwenden denselben Workflow, jedoch mit unterschiedlichen Zustandsmaschinen und Lambda-Funktionen.



![Architekturdiagramm des regionsübergreifenden Failover-Prozesses.](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failover.png)


1. Die `DR Orchestrator FAILOVER` Zustandsmaschine liest die JSON-Eingabeparameter.

1. Basierend auf dem `resourceType`**** Parameter ruft die Zustandsmaschine andere Zustandsmaschinen auf: `Promote RDS Read Replica``Failover Aurora Cluster`, oder`Failover ElastiCache`. Wenn in der Eingabe mehr als eine Ressource übergeben wird, laufen diese Zustandsmaschinen parallel.

1. Die `Failover Aurora Cluster`**** Zustandsmaschine ruft Lambda-Funktionen in jedem der folgenden drei Schritte auf. 

1. Die `Resolve imports`**** Lambda-Funktion wird `"! import <export-variable-name>"` mit den tatsächlichen Werten aus der `App-Stack` AWS CloudFormation Vorlage aufgelöst.

1. Die **`Failover Aurora Cluster`******Lambda-Funktion**** bewirbt die Read Replica als eigenständige DB-Instance.

1. Die **`Check Failover Status`**Lambda-Funktion überprüft den Status der beworbenen DB-Instance. Sobald der Status **VERFÜGBAR** ist, sendet die Lambda-Funktion ein Erfolgstoken zurück an die aufrufende Zustandsmaschine und schließt den Vorgang ab.

1. Sie können Ihre Anwendungen zur eigenständigen Datenbank in der DR-Region (`us-west-2`) umleiten, die jetzt die primäre Datenbank ist.

## Der Failback-Prozess
<a name="failback-process"></a>

Nachdem Ihre frühere primäre Region (`us-east-1`) wieder aktiv ist, können Sie zu ihr zurückkehren, sodass die Datenbank in wieder zur primären Region `us-east-1` wird. Um das Failback zu starten, führen Sie die `DR Orchestrator FAILBACK` Zustandsmaschine aus. Wie der Name schon sagt, beginnt dieser Zustandsmaschine damit, Änderungen in Ihrer neuen primären Region (`us-west-2`) zurück in die frühere primäre Region (`us-east-1`) zu replizieren, die als aktuelle sekundäre Region fungiert.

Nachdem die Replikation zwischen den beiden Regionen eingerichtet wurde, können Sie das Failback einleiten. Um ein Failback durchzuführen und zu Ihrer ursprünglichen primären Region (`us-east-1`) zurückzukehren, führen Sie den `DR Orchestrator FAILOVER` Zustandsmaschine in der aktuellen sekundären Region (`us-east-1`) aus, um sie zur primären Region hochzustufen.

### `DR Orchestrator FAILBACK`-Architektur
<a name="failback-architecture"></a>

Das folgende Diagramm zeigt die Konzepte des Failback-Prozesses für Amazon Aurora bei Verwendung von DR Orchestrator.



![Architekturdiagramm des regionsübergreifenden Failback-Prozesses.](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failback.png)


1. Bevor Sie mit dem Failback beginnen, erstellen Sie einen manuellen DB-Snapshot, den Sie bei der Root Cause Analysis (RCA) verwenden können.

   Deaktivieren Sie außerdem das `DeletionProtection` für den Aurora-Cluster in der vorherigen primären Region (`us-east-1`).

1. Die `DR Orchestrator FAILBACK` Zustandsmaschine liest die JSON-Eingabeparameter.

1. Basierend auf dem `resourceType` ruft die `DR Orchestrator FAILBACK` Zustandsmaschine die `Create Aurora Secondary DB Cluster`**** Zustandsmaschine auf.

1. Die `Create Aurora Secondary DB Cluster`**** Zustandsmaschine ruft Lambda-Funktionen in jedem der folgenden fünf Schritte auf.

1. Die `Resolve import`**** Lambda-Funktion wird `"! import <export-variable-name>"` mit den tatsächlichen Werten aus der `App-Stack` CloudFormation Vorlage aufgelöst.

1. Die `Delete DB Instance`**** Lambda-Funktion löscht die frühere Primärinstanz.

1. Die `Check DB instance status`**** Lambda-Funktion überprüft die, `Delete DB Instance status` bis die Datenbank gelöscht wird.

1. Die `Create Read Replica`**** Lambda-Funktion erstellt eine Read Replica in der sekundären Region aus der DB-Instance, die sich in der neuen primären Region befindet.

1. Die `Check DB instance status`**** Lambda-Funktion überprüft den Status der Read Replica-DB-Instance. Wenn der Status **VERFÜGBAR** ist, sendet die Lambda-Funktion ein Erfolgstoken zurück an die aufrufende Zustandsmaschine, die abgeschlossen ist.

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

Verwenden Sie die `DR Orchestrator FAILOVER` Zustandsmaschine im DR-Ereignis, wenn die primäre Region (`us-east-1`) ausgefallen ist, oder bei geplanten Ereignissen, z. B. bei Wartungsarbeiten.

Die Funktion kann aufgerufen werden, um ein Failover einzelner oder mehrerer Datenbanken parallel durchzuführen.



![Zustandsmaschinendiagramm, das den Failover für verschiedene Ressourcentypen zeigt.](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failover-state-machine.jpg)


Die Zustandsmaschine akzeptiert Parameter im JSON-Format, wie im folgenden Code dargestellt:

```
{
  "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"
          }
        }
      ]
    }
  ]
}
```

### Einzelheiten zu den Parametern
<a name="parameters"></a>

Die folgende Tabelle zeigt die von der `DR Orchestrator FAILOVER` Zustandsmaschine verwendeten Parameter.


| Parametername | Description | Erwartete Werte | 
| --- | --- | --- | 
| layer(erforderlich: Zahl) | Die Reihenfolge der Verarbeitung. Alle in Layer 1 definierten Ressourcen müssen ausgeführt werden, bevor die Layer-2-Ressourcen ausgeführt werden. | 1 oder 2 und so weiter | 
| Ressourcen (erforderlich: Wörterbuch-Array) | Alle Ressourcen innerhalb einer einzigen Schicht laufen parallel. | <pre>{<br />"resourceType":"String",<br />"resourceName":"String",<br />"parameters":{<br />"<param1>":"<!Import cft-output-1">,<br />....<br />}</pre> | 
| resourceType(erforderlich: Zeichenfolge) | Typ der Ressource zur Identifizierung der Ressource | PromoteRDSReadReplica oder FailoverElastiCacheCluster | 
| resourceName(optional: Zeichenfolge) | Um zu ermitteln, zu welchem Anwendungsportfolio diese Ressourcen gehören | Promote RDS for MySQL Read Replica | 
| Parameter (erforderlich: Wörterbuch-Array) | Liste der Parameter, die für ein Failover oder ein Failback der AWS Datenbank erforderlich sind | <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>

Verwenden Sie die `DR Orchestrator FAILBACK` Zustandsmaschine nach dem DR-Ereignis, wenn die frühere primäre Region (`us-east-1`) aktiv ist. Sie können die [Read Replica](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) für Amazon RDS in der früheren primären Region aus der neuen primären Region (`us-west-2`) erstellen, um Ihrer DR-Strategie zu entsprechen. Da es sich um eine geplante Veranstaltung handelt, können Sie diese Aktivität auf das Wochenende oder außerhalb der Hauptverkehrszeiten mit voraussichtlicher Ausfallzeit planen.



![Zustandsdiagramm, das die Ressourcentypen für das Failback zeigt.](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-failback-state-machine.jpg)


Die Zustandsmaschine akzeptiert Parameter im JSON-Format, wie im folgenden Code dargestellt:

```
{
  "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"
          }
        }
      ]
    }
  ]
}
```