Quel est l'impact de la modification de mon instance Amazon RDS mono-AZ en instance multi-AZ et vice versa ?

Lecture de 7 minute(s)
0

Je veux connaître l'impact du changement de mon instance de base de données Amazon Relational Database Service (Amazon RDS) mono-AZ en instance multi-AZ. -ou- Je veux connaître l'impact du changement de mon instance de base de données Amazon RDS multi-AZ en instance mono-AZ.

Brève description

Dans une configuration mono-AZ, une instance de base de données Amazon RDS et un ou plusieurs volumes de stockage Amazon Elastic Block Store (Amazon EBS) sont déployés dans une zone de disponibilité. Dans une configuration multi-AZ, les instances de base de données et les volumes de stockage EBS sont déployés dans deux zones de disponibilité.

Lorsque vous activez l'option multi-AZ sur votre instance, Amazon RDS conserve une copie de secours redondante et cohérente de vos données à l'aide de la réplication de stockage synchrone. Amazon RDS détecte puis récupère automatiquement les scénarios de défaillance d'infrastructure les plus courants pour les déploiements multi-AZ. Cette détection et cette récupération ont lieu afin que vous puissiez reprendre les opérations de base de données le plus rapidement possible. Pour plus d'informations, consultez la section Haute disponibilité (multi-AZ) pour Amazon RDS.

Pour faire passer une instance de base de données d'un déploiement mono-AZ à un déploiement multi-AZ et vice versa, consultez la section Modification d'une instance Amazon RDS.

Solution

Impact du changement d'une instance mono-AZ en une instance multi-AZ

Lorsque vous changez votre instance mono-AZ en multi-AZ, vous ne subissez aucune interruption sur l'instance. Pendant la modification, Amazon RDS crée un instantané des volumes de l'instance. Cet instantané est ensuite utilisé pour créer de nouveaux volumes dans une autre zone de disponibilité. Bien que ces nouveaux volumes soient immédiatement disponibles pour être utilisés, vous pouvez subir un impact sur les performances. Cet impact se produit parce que les données du nouveau volume sont toujours en cours de chargement depuis Amazon Simple Storage Service (Amazon S3). Pendant ce temps, l'instance de base de données continue de charger des données en arrière-plan. Ce processus, appelé chargement différé, peut entraîner une latence d'écriture élevée et un impact sur les performances pendant et après le processus de modification.

L'ampleur de l'impact sur les performances dépend du type de volume, de la charge de travail, de l'instance et de la taille du volume. L'impact peut être important pour les instances de base de données volumineuses nécessitant beaucoup d'écriture pendant les heures de pointe des opérations. Par conséquent, la bonne pratique consiste à tester l'impact sur une instance de test avant d'exécuter cette modification en production. C'est également une bonne pratique d'effectuer cette modification dans une fenêtre de maintenance ou pendant une période de faible débit.

Réduire la durée du chargement

Pour réduire de manière proactive la durée et l'impact du chargement, procédez comme suit :

  1. Changez le type de stockage de l'instance de base de données en IOPS allouées. Assurez-vous de mettre en service une quantité d'IOPS nettement supérieure à ce que requiert votre charge de travail.
    Remarque : cette étape peut entraîner une brève période d'arrêt si l'instance utilise un groupe de paramètres personnalisé.
  2. Changez l'instance en multi-AZ.
  3. Lancez un basculement sur votre instance pour vous assurer que la nouvelle AZ est la principale.
  4. Exécutez un vidage complet des données de votre instance. Vous pouvez également exécuter des requêtes d'analyse de table complète sur les tables les plus actives afin d'accélérer le chargement des données dans les volumes.
  5. Confirmez que la latence d'écriture est revenue à des niveaux normaux en examinant la métrique WriteLatency dans Amazon CloudWatch.
  6. Modifiez le type de stockage ou les IOPS de l'instance pour revenir à votre configuration précédente.
    Remarque : cette étape ne nécessite pas de temps d'arrêt.

Réduire la latence si votre instance est déjà multi-AZ

Pour réduire la latence si vous avez déjà modifié l'instance en multi-AZ, procédez comme suit :

  1. Lancez un basculement sur votre instance pour vous assurer que la nouvelle AZ est la principale.
  2. Changez le type de stockage de l'instance de base de données en IOPS allouées. Assurez-vous de mettre en service une quantité d'IOPS nettement supérieure à ce que requiert votre charge de travail.
    Remarque : cette étape ne nécessite pas de temps d'arrêt.
  3. Exécutez un vidage complet des données de votre instance. Vous pouvez également exécuter des requêtes d'analyse de table complète sur les tables les plus actives afin d'accélérer le chargement des données dans les volumes.
  4. Confirmez que la latence d'écriture est revenue à des niveaux normaux en examinant la métrique WriteLatency dans Amazon CloudWatch.
  5. Modifiez le type de stockage ou les IOPS de l'instance pour revenir à votre configuration précédente.
    Remarque : cette étape ne nécessite pas de temps d'arrêt.

Si vous changez une instance de base de données de mono-AZ en multi-AZ, une instance de secours est créée avec la même configuration dans une autre zone de disponibilité. Cela génère des coûts supplémentaires. De plus, comme multi-AZ utilise la réplication synchrone, les écritures sont légèrement plus lentes que dans mono-AZ.

Impact du changement d'une instance multi-AZ en une instance mono-AZ

Lorsque vous faites passer votre instance de multi-AZ à mono-AZ, vous ne subissez pas de temps d'arrêt sur l'instance. Pendant la modification, Amazon RDS ne supprime que l'instance et les volumes secondaires, et l'instance principale n'est pas affectée.

Voici quelques éléments à prendre en compte avant de changer votre instance d'un déploiement multi-AZ à un déploiement mono-AZ :

  • Avec le déploiement multi-AZ, Amazon RDS bascule automatiquement vers la copie de secours dans une autre zone de disponibilité pendant une panne planifiée ou non planifiée de votre instance de base de données. Mais, dans le cas d'une instance mono-AZ, vous devrez peut-être lancer une opération de restauration-à-un-point-dans-le-temps. Cette opération peut prendre plusieurs heures. Toutes les mises à jour de données effectuées après la dernière période de restauration ne sont pas disponibles. Vous risquez donc de subir un temps d'arrêt supplémentaire sur une instance mono-AZ en cas de défaillance.
  • Avec une instance multi-AZ, des sauvegardes automatisées sont créées à partir de l'instance secondaire pendant la fenêtre de sauvegarde automatique. Pour Amazon RDS pour MariaDB, Amazon RDS pour MySQL, Amazon RDS pour Oracle et Amazon RDS for PostgreSQL, l'activité I/O n'est pas suspendue sur votre instance principale pendant la sauvegarde des déploiements multi-AZ, car les données sauvegardées proviennent de l'instance secondaire. Pour Amazon RDS pour SQL Server, l'activité I/O est brièvement suspendue pendant la sauvegarde des déploiements multi-AZ. Le processus de sauvegarde sur une instance de base de données single-AZ entraîne une brève suspension de l'activité I/O qui peut durer de quelques secondes à quelques minutes. La durée dépend de la taille et de la classe de votre instance de bases de données.
  • Dans les déploiements multi-AZ, la maintenance du système d'exploitation est appliquée à l'instance secondaire en premier. L'instance secondaire est promue en instance principale, puis la maintenance est effectuée sur l'ancienne instance principale, qui est la nouvelle instance de secours. Ainsi, dans une instance multi-AZ le temps d'arrêt lors de certains correctifs du système d'exploitation est minimale.
  • Si vous mettez à l'échelle votre instance multi-AZ, le temps d'arrêt est minimale. Cela s'explique par le fait que l'instance secondaire est modifiée en premier. L'instance secondaire devient l'instance principale. Ensuite, l'ancienne instance principale, désormais secondaire, est modifiée. Une instance mono-AZ devient indisponible pendant l'opération de mise à l'échelle.

Informations connexes

Déploiements multi-AZ Amazon RDS

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans