Basculement d'un déploiement bleu/vert

Une commutation fait du cluster de base de données, y compris de ses instances de base de données, dans l'environnement vert, le cluster de base de données de production. Avant le basculement, le trafic de production est routé vers le cluster dans l'environnement bleu. Après le basculement, le trafic de production est routé vers le cluster de base de données dans l'environnement vert.

Le passage d'un déploiement bleu/vert n'est pas la même chose que la promotion du cluster de base de données d' de base de données vert dans le déploiement bleu/vert. Si vous promouvez manuellement le cluster de de base de données vert en choisissant Promouvoir dans le menu Actions, la réplication entre les environnements bleu et vert est interrompue et le déploiement bleu/vert passe à l'état de configuration non valide.

Délai de commutation

Vous pouvez spécifier un délai de commutation compris entre 30 secondes et 3 600 secondes (une heure). Si la commutation prend plus de temps que la durée spécifiée, toutes les modifications sont annulées et aucune modification n'est apportée à l'un ou l'autre des environnements. Le délai d'attente par défaut est de 300 secondes (cinq minutes).

Barrières de protection de commutation

Lorsque vous lancez un passage au numérique, Amazon RDS effectue des vérifications de base pour vérifier si les environnements bleu et vert sont prêts à passer au numérique. Ces contrôles sont connus sous le nom de barrières de protection de commutation. Ces barrières de protection empêchent une commutation si les environnements ne sont pas prêts pour cela. Ils évitent donc un temps d'arrêt plus long que prévu et empêchent la perte de données entre les environnements bleu et vert qui pourrait survenir si la commutation était lancée.

Amazon RDS effectue les contrôles de sécurité suivants sur l'environnement vert :

• État de la réplication : vérifiez si l'état de réplication du cluster de base de données vert est sain. Le cluster de base de données vert est un réplica du cluster de base de données bleu.

• Décalage de réplication : vérifiez si le retard de réplica du cluster de base de données vert se situe dans les limites autorisées pour la commutation. Les limites autorisées sont basées sur le délai d'attente spécifié. Le retard de réplica indique dans quelle mesure le cluster de base de données vert est en retard sur son cluster de base de données bleu. Pour plus d'informations, consultez Diagnostic et résolution du retard entre réplicas en lecture et for Aurora SQL Postgre.

• Écritures actives : assurez-vous qu'aucune écriture n'est active sur le cluster de base de données vert.

Amazon RDS effectue les contrôles de sécurité suivants sur l'environnement bleu :

• Réplication externe : pour Aurora Postgre SQL RDS , assurez-vous que l'environnement bleu n'est pas une source logique autogérée (éditeur) ou une réplique (abonné). Si tel est le cas, nous vous recommandons de supprimer les emplacements de réplication autogérés et les abonnements dans toutes les bases de données de l'environnement bleu, de procéder au basculement, puis de les recréer pour reprendre la réplication. Pour Aurora My SQL RDS for My SQL , vérifie si la base de données bleue n'est pas une réplique externe du journal binaire. Si tel est le cas, assurez-vous qu'il ne se réplique pas activement.

• Écritures actives de longue durée : assurez-vous qu'il n'y a pas d'écritures actives de longue durée sur le cluster de base de données bleu, car elles peuvent augmenter le retard de réplica.

• Instructions de longue durée : DDL vérifie qu'il n'y a pas d'DDLinstructions de longue durée sur le cluster de base de données bleu de l'instance , car elles peuvent augmenter le délai de réplication.

• SQLModifications Postgre non prises en charge — Pour les clusters de SQL base de données Aurora Postgre RDS de données Postgre, assurez-vous qu'aucune DDL modification ni aucun ajout ou modification d'objets volumineux n'ont été effectués dans l'environnement bleu. Pour de plus amples informations, veuillez consulter Limites de réplication SQL logique Postgre pour les déploiements bleu/vert.

  Si Amazon RDS détecte des SQL modifications Postgre non prises en charge, il change l'état de réplication Replication degraded et vous informe que le basculement n'est pas disponible pour le déploiement bleu/vert. Pour continuer la commutation, nous vous recommandons de supprimer et de recréer le déploiement bleu/vert ainsi que toutes les bases de données vertes. Pour ce faire, choisissez Actions, Supprimer avec les bases de données vertes.

Actions de commutation

Lorsque vous passez d'un déploiement bleu/vert, effectuez les RDS actions suivantes :

1. Exécute des contrôles de barrière de protection pour vérifier si les environnements bleu et vert sont prêts pour la commutation.

2. Arrête les nouvelles opérations d'écriture sur le cluster de base de données dans les deux environnements.

3. Supprime les connexions aux instances de base de données dans les deux environnements et ne permet pas de nouvelles connexions.

4. Attend que la réplication rattrape son retard dans l'environnement vert afin que celui-ci soit synchronisé avec l'environnement bleu.

5. Renomme le cluster de base de données et les instances de base de données dans les deux environnements.

   RDSrenomme le cluster d' de base de données et les instances de base de données dans l'environnement vert pour qu'ils correspondent au cluster d' de base de données correspondant et aux instances de base de données dans l'environnement bleu. Par exemple, supposons que le nom d'une instance de base de données dans l'environnement bleu est mydb. Supposons également que le nom de l'instance de base de données correspondante dans l'environnement vert est mydb-green-abc123. Pendant la commutation, le nom de l'instance de base de données dans l'environnement vert devient mydb.

   RDSrenomme le cluster d' de base de données et les instances de base de données dans l'environnement bleu en ajoutant un chiffre -oldn au nom actuel. n Par exemple, supposons que le nom d'une instance de base de données dans l'environnement bleu est mydb. Après la commutation, le nom de l'instance de base de données pourrait être mydb-old1.

   RDSrenomme également les points de terminaison dans l'environnement vert pour qu'ils correspondent aux points de terminaison correspondants dans l'environnement bleu afin qu'aucune modification de l'application ne soit requise.

6. Permet les connexions aux bases de données dans les deux environnements.

7. Autorise les opérations d'écriture sur l'instance de base de données principale dans le nouvel environnement de production.

   Après le basculement, le cluster de base de données d'instance de production précédent autorise uniquement les opérations de lecture de base de données. Même si vous désactivez le read_only paramètre sur le cluster de base de données, il reste en lecture seule jusqu'à ce que vous supprimiez le déploiement bleu/vert.

Vous pouvez surveiller l'état d'un passage au numérique à l'aide d'Amazon. EventBridge Pour de plus amples informations, veuillez consulter Événements de déploiement bleu/vert.

Si vous avez configuré des balises dans l'environnement bleu, elles sont copiées dans le nouvel environnement de production lors du passage au numérique. Pour en savoir plus sur les identifications, consultez Marquage d'Amazon Aurora et des ressources Amazon RDS.

Si la commutation commence et s'arrête avant la fin pour une raison quelconque, les modifications sont annulées et aucune modification n'est apportée à l'environnement.

Bonnes pratiques de commutation

Avant de basculer, nous vous recommandons vivement de respecter les bonnes pratiques en accomplissant les tâches suivantes :

• Testez minutieusement les ressources dans l'environnement vert. Assurez-vous qu'elles fonctionnent correctement et efficacement.

• Surveillez les CloudWatch statistiques Amazon pertinentes. Pour de plus amples informations, veuillez consulter Vérification des CloudWatch métriques avant le passage au numérique.

• Déterminez le meilleur moment pour la commutation.

  Pendant la commutation, les écritures sont interrompues dans les bases de données des deux environnements. Identifiez un moment où le trafic est le plus faible dans votre environnement de production. Les transactions de longue durée, telles que les transactions activesDDLs, peuvent augmenter le temps de transition, ce qui se traduit par des temps d'arrêt plus longs pour vos charges de travail de production.

  S'il existe un grand nombre de connexions sur votre cluster de base de données et vos instances de base de données, pensez à les réduire manuellement au minimum nécessaire pour votre application avant de basculer vers le déploiement bleu/vert. Une manière de procéder consiste à créer un script qui surveille le statut du déploiement bleu/vert et qui commence à nettoyer les connexions lorsqu'il détecte que le statut est passé à SWITCHOVER_IN_PROGRESS.

• Assurez-vous que le cluster de base de données et les instances de base de données dans les deux environnements sont dans l'état Available.

• Assurez-vous que le cluster de base de données dans l'environnement vert est dans un état sain et qu'il se réplique.

• Assurez-vous que les configurations de votre réseau et de votre client n'augmentent pas le temps de vie du DNS cache au-delà de cinq secondes, ce qui est la valeur par défaut pour les zones Aurora DNS. TTL
 Sinon, les applications continueront à envoyer du trafic d'écriture vers l'environnement bleu après le basculement.

• Pour les clusters de SQL base de données Aurora Postgre RDS , procédez comme suit :

  • Passez en revue les limites de la réplication logique et prenez les mesures nécessaires avant le passage au numérique. Pour de plus amples informations, veuillez consulter Limites de réplication SQL logique Postgre pour les déploiements bleu/vert.

  • Exécutez l'opération ANALYZE pour actualiser la table pg_statistics. Cela réduit le risque de problèmes de performances après le passage au numérique.

Note

Lors d'une commutation, vous ne pouvez modifier aucun cluster de base de données inclus dans la commutation.

Vérification des CloudWatch métriques avant le passage au numérique

Avant de passer à un déploiement bleu/vert, nous vous recommandons de vérifier les valeurs des métriques suivantes sur Amazon. CloudWatch

• DatabaseConnections : utilisez cette métrique pour estimer le niveau d'activité du déploiement bleu/vert et assurez-vous que la valeur est à un niveau acceptable pour votre déploiement avant d'effectuer le basculement. Si l'analyse des performances est activée, DBLoad est une métrique plus précise.

• ActiveTransactions : si innodb_monitor_enable a pour valeur all dans le groupe de paramètres de base de données de l'une de vos instances de base de données, utilisez cette métrique pour déterminer si un nombre élevé de transactions actives sont susceptibles de bloquer la commutation.

Pour plus d’informations sur ces métriques, consultez CloudWatch Métriques Amazon pour Amazon Aurora.

Surveillance du délai de réplication avant le passage au numérique

Avant de passer à un déploiement bleu/vert, assurez-vous que le délai de réplication sur la base de données verte est proche de zéro afin de réduire les temps d'arrêt.

• Pour Aurora MySQL, utilisez la AuroraBinlogReplicaLag CloudWatch métrique pour identifier le délai de réplication actuel dans un environnement écologique.

• Pour Aurora PostgreSQL, utilisez la SQL requête suivante :

  SELECT slot_name,
         confirmed_flush_lsn as flushed,
         pg_current_wal_lsn(),
         (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
  FROM pg_catalog.pg_replication_slots
  WHERE slot_type = 'logical';
  
  slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
  -----------------+---------------+--------------------+------------
  logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192

  Le confirmed_flush_lsn représente le dernier numéro de séquence du journal (LSN) envoyé à la réplique. Le pg_current_wal_lsn représente l'emplacement actuel de la base de données. Une lsn_distance valeur de 0 signifie que la réplique est rattrapée.

Basculement d'un déploiement bleu/vert

Vous pouvez passer d'un déploiement bleu/vert à l'aide du AWS Management Console AWS CLI, du ou du. RDS API

Console

Pour effectuer un basculement de déploiement bleu/vert

1. Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

2. Dans le panneau de navigation, choisissez Bases de données, puis sélectionnez le déploiement bleu/vert que vous souhaitez basculer.

3. Pour Actions, choisissez Basculer.

   La page Basculer apparaît.

   

4. Sur la page Basculer, consultez le résumé de la commutation. Assurez-vous que les ressources des deux environnements correspondent à ce que vous attendez. Si ce n'est pas le cas, choisissez Annuler.

5. Dans le champ Paramètre de délai d'attente, entrez le délai limite pour la commutation.

6. Si votre cluster exécute une SQL instance Aurora Postgre , passez en revue et confirmez les recommandations avant le basculement. Pour de plus amples informations, veuillez consulter Limites de réplication SQL logique Postgre pour les déploiements bleu/vert.

7. Choisissez Basculer.

AWS CLI

Pour passer d'un déploiement bleu/vert à l'aide de AWS CLI, utilisez la switchover-blue-green-deploymentcommande avec les options suivantes :

• --blue-green-deployment-identifier— Spécifiez l'ID de ressource du déploiement bleu/vert.

• --switchover-timeout : spécifiez la limite de temps pour la commutation, en secondes. La valeur par défaut est 300.

Exemple Basculement d'un déploiement bleu/vert

Pour LinuxmacOS, ou Unix :

aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600

Dans Windows :

aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600

RDS API

Pour passer d'un déploiement bleu/vert à l'aide d'Amazon RDSAPI, utilisez l'SwitchoverBlueGreenDeploymentopération avec les paramètres suivants :

• BlueGreenDeploymentIdentifier— Spécifiez l'ID de ressource du déploiement bleu/vert.

• SwitchoverTimeout : spécifiez la limite de temps pour la commutation, en secondes. La valeur par défaut est 300.

Après la commutation

Après une commutation, le cluster de base de données et les instances de base de données de l'environnement bleu précédent sont conservé(e)s. Les coûts standard s'appliquent à ces ressources. La réplication et la journalisation binaire entre les environnements bleu et vert s'arrête.

RDSrenomme le cluster d' de base de données et les instances de base de données dans l'environnement bleu en ajoutant un chiffre -oldn au nom de la ressource en cours. n Le cluster de base de données est forcé de passer en mode lecture seule. Même si vous désactivez le read_only paramètre sur le cluster de base de données, il reste en lecture seule jusqu'à ce que vous supprimiez le déploiement bleu/vert.

Mise à jour du nœud parent pour les consommateurs

Après avoir basculé vers un déploiement bleu/vert Aurora contenait des répliques externes ou des consommateurs de journaux binaires avant le basculement, vous devez mettre à jour son nœud parent après le basculement afin de maintenir la continuité de la réplication.

Après le basculement, l'instance de base de données du rédacteur qui se trouvait auparavant dans l'environnement vert émet un événement contenant le nom du fichier journal principal et la position du journal principal. Par exemple :

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier

{
    "Events": [
...
        {
            "SourceIdentifier": "db-instance-identifier",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000003 and position 804",
            "EventCategories": [],
            "Date": "2023-11-10T01:33:41.911Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier"
        }
    ]
}

Tout d'abord, assurez-vous que le consommateur ou la réplique a appliqué tous les journaux binaires de l'ancien environnement bleu. Ensuite, utilisez les coordonnées binaires du journal fournies pour reprendre l'application auprès des consommateurs. Par exemple, si vous exécutez une SQL réplique My Replica surEC2, vous pouvez utiliser la CHANGE MASTER TO commande suivante :

CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;