Panoramica di DR Orchestrator Framework

DR Orchestrator Framework offre una soluzione con un solo clic per orchestrare e automatizzare il ripristino di emergenza interregionale per i database. AWS Utilizza AWS Step Functionsed esegue i passaggi richiesti durante AWS Lambdail failover e il failback. Le macchine a stati Step Functions forniscono la base per il processo decisionale all'interno della progettazione dell'orchestratore. Le operazioni API per l'esecuzione di azioni di failover o failback sono codificate in funzioni Lambda richiamate dall'interno della macchina a stati. Le funzioni Lambda vengono eseguite AWS SDK per Python (Boto3) APIs per interagire con AWS i database.

DR Orchestrator Framework contiene due macchine a stati principali che corrispondono alle fasi di failover e failback.

Per Amazon RDS, la fase di failover promuove una replica di lettura RDS interregionale in un'istanza DB autonoma. Per Amazon Aurora, quando la regione principale è inattiva durante un'interruzione rara e inaspettata, il relativo nodo di scrittura non è disponibile. La replica tra il nodo di scrittura e i cluster secondari si interrompe. È necessario scollegare il cluster secondario dal database globale e promuoverlo come cluster autonomo. Le applicazioni possono connettersi e inviare traffico di scrittura al cluster autonomo. È possibile utilizzare lo stesso processo per passare dal cluster DB primario del database globale alle regioni secondarie.  Utilizzate questo approccio per scenari controllati come i seguenti:

La fase di failback stabilisce la replica in tempo reale dei dati tra una regione primaria attiva e una nuova regione secondaria.

È fondamentale comprendere che DR Orchestrator si applica solo ai database. Tutte le applicazioni che fanno riferimento a questi database e si trovano nella stessa regione potrebbero richiedere una soluzione di failover tandem separata. Dopo il failover dei database nella regione secondaria, è necessario aggiornare le applicazioni per connettersi alle nuove istanze del database, che fungeranno da origine dati.

Il processo di failover

Per eseguire un failover, eseguite la macchina a DR Orchestrator FAILOVER stati. In questa fase, un database secondario è già presente nella regione secondaria, come replica di lettura (Amazon RDS) o come cluster secondario (Amazon Aurora). Quando si esegue la macchina a DR Orchestrator FAILOVER stati, il database secondario diventa il principale.

Architettura di DR Orchestrator FAILOVER

Il diagramma seguente mostra i concetti del processo di failover per Amazon Aurora quando si utilizza DR Orchestrator. Amazon Aurora e Amazon ElastiCache utilizzano lo stesso flusso di lavoro ma con macchine a stati e funzioni Lambda diverse.

Il processo di failback

Dopo che la regione principale precedente (us-east-1) è stata nuovamente attivata, è possibile eseguire il failback, in modo che il database in entrata us-east-1 diventi nuovamente la principale. Per avviare il failback, esegui la macchina a DR Orchestrator FAILBACK stati. Come indica il nome, questa macchina a stati inizia a replicare le modifiche nella nuova regione principale (us-west-2) nella precedente regione primaria (us-east-1), che funge da regione secondaria corrente.

Una volta stabilita la replica tra le due regioni, è possibile avviare il failback. Per eseguire il failback e tornare alla regione primaria originale (us-east-1), esegui la macchina a DR Orchestrator FAILOVER stati nella regione secondaria corrente (us-east-1) per promuoverla nella regione primaria.

Architettura di DR Orchestrator FAILBACK

Il diagramma seguente mostra i concetti del processo di failback per Amazon Aurora quando si utilizza DR Orchestrator.

FAILOVER DI DR Orchestrator

Utilizza la macchina a DR Orchestrator FAILOVER stati nell'evento DR quando la regione primaria (us-east-1) è inattiva o durante eventi pianificati come la manutenzione operativa.

La funzione può essere chiamata per eseguire il failover di uno o più database in parallelo.

La macchina a stati accetta parametri in formato JSON, come illustrato nel codice seguente:

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

Dettagli dei parametri

La tabella seguente mostra i parametri utilizzati dalla macchina a DR Orchestrator FAILOVER stati.

{
"resourceType":"String",
"resourceName":"String",
"parameters":{
"<param1>":"<!Import cft-output-1">,
....
}

{
          "<param1>":"<!Import
                cft-output-1>",
                "<param2>":"<!Import
                cft-output-2>",
                }

FAILBACK DI DR Orchestrator

Utilizza la macchina a DR Orchestrator FAILBACK stati dopo l'evento DR, quando la precedente regione primaria () us-east-1 è attiva. Puoi creare la replica di lettura per Amazon RDS nella precedente regione principale dalla nuova regione principale (us-west-2) per renderla conforme alla tua strategia di disaster recovery. Poiché si tratta di un evento pianificato, puoi pianificare questa attività durante il fine settimana o durante le ore lavorative non di punta con un tempo di inattività stimato.

La macchina a stati accetta parametri in formato JSON, come illustrato nel codice seguente:

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