Amazon RDS sous le capot : déploiement « Multi AZ »

Nos clients s’appuie sur les services AWS pour opérer leurs bases de données critiques au bon fonctionnement de leur processus métier. La possibilité d’un accès fiable & permanent est un facteur clef de succès et la mise en œuvre d’une configuration « Multi-AZ » offre une solution simple de haute disponibilité (HA).

En effet, quand vous déployez Amazon Relational Database Service (Amazon RDS) sur plusieurs zones de disponibilités, le service maintient une copie secondaire redondante et consistante de vos données. S’il se produit un incident sur la copie primaire, Amazon RDS basculera automatiquement sur la copie secondaire de sorte à maintenir l’accessibilité de vos données.

Les deux copies sont maintenues dans deux zones de disponibilité différentes d’où le nom « Multi-AZ ». Disposer de plusieurs zones de disponibilité séparées, réduit sensiblement, pour la plupart des incidents, le risque de les impacter simultanément. La gestion efficace des données, la gestion simple des reconfigurations et l’accès robuste aux copies sont clés pour répondre aux exigences de haute disponibilité que requièrent les environnements de nos clients.

Cet article décrit les configurations « Multi-AZ » pour Amazon RDS pour des instances de base de données MySQL, MariaDB, PostgreSQL, et Oracle. Amazon RDS pour SQL Server et Amazon RDS pour Amazon Aurora utilisent des composantes technologiques différentes pour offrir la fonctionnalité Multi-AZ.

Principe de conception

La fonctionnalité Multi-AZ est implémentée en utilisant une couche de réplication installée entre le moteur de base de donnée et les volumes de stockage Amazon EBS (Amzon Elastic Block Storage). Cette couche de réplication gère les requêtes en lecture et en écriture et les applique sur un environnement comportant deux volumes Amazon EBS complètement séparés, l’un accédé localement, l’autre à distance.

En fonctionnement nominal, il y a deux instances Amazon EC2 (Amazon Elastic Compute Cloud) actives sur lesquelles est installé la couche de réplication. Chaque instance gère un volume Amazon EBS avec une copie complète des données. Cette configuration associe les deux instances Amazon EC2 et leurs volumes qui constituent une instance de base de données Multi AZ. Les couches de réplication communiquent entre elles directement en utilisant des connections TCP.

A chaque instant, chaque instance se voit attribuer un rôle spécifique. Une instance est primaire et est active pour exposer un point de terminaison externe qui permet aux utilisateurs d’accéder à leurs données. L’ autre instance est en attente et agit comme une instance secondaire qui écrit de manière synchrone toute donnée reçue de l’instance primaire.

Toute requête en écriture nécessite d’avoir pu écrire sur les deux volumes, avant de confirmer le succès de l’opération à l’application cliente. En revanche, les opérations en lecture sont toujours exécutées sur le volume EBS primaire. En effet, il n’y a pas de processus de base de données serveur qui s’exécute sur l’instance secondaire et donc pas de point de terminaison exposé sur l’extérieur. En conséquence, ces copies de données ne sont pas accessible aux utilisateurs.

Pour garantir la disponibilité, le Multi AZ s’efforce de garantir en permanence que l’une des instances a le rôle primaire, fournissant ainsi l’accès aux données qu’elle possède. Si un problème d’accessibilité survient sur le nœud primaire, l’instance secondaire est automatiquement transformée pour devenir la nouvelle instance primaire de sorte que l’accessibilité est restaurée par redirection.

On désigne cet évènement comme étant une bascule. L’instance qui était primaire avant l’incident, si elle est encore allumée et en cours d’exécution, a changé de rôle et est devenue une instance secondaire. La redirection vers la nouvelle instance primaire est obtenue au moyen du service DNS. Les enregistrements retournés aux requêtes des clients DNS ont une durée de vie (TTL) très courte. Cela permet d’empêcher la mise en cache prolongée des informations de correspondance entre les noms et les adresses IP. Cela impose au client de rafraîchir plus souvent ces informations, de sorte qu’en cas de bascule, la prise en compte de la redirection DNS soit plus rapide.

Le schéma ci-dessous montre une instance Multi-AZ qui s’exécute dans son état nominal.

L’application cliente de la base de donnée (DB APP, mentionnée en jaune) utilise le serveur DNS (mentionnée en orange) pour obtenir l’adresse du point de terminaison externe courant de la base de données Amazon RDS.

Il y a deux instances de base de données Amazon RDS dans le déploiement Multi-AZ : l’instance primaire (mentionnée en vert du côté gauche) et l’instance secondaire (mentionnée en bleu du côté droit). Dans cet exemple, l’enregistrement DNS pointe sur l’application vers l’instance Amazon EC2 #1, servant de copie principale du volume de données Amazon EBS #1 qui est disponible dans la zone de disponibilité Availability Zone #1.
Les couches de réplications entre les deux instances EC2 sont connectées. Les opérations en écriture qu’a demandé l’application sont automatiquement répliquées sur la seconde instance (voir le chemin en gris sur le schéma).

En général, les évènements de bascule sont rares, mais peuvent se produire. Pour ces situations ou Amazon RDS détecte ces problèmes, la bascule est déclenchée automatiquement. Vous pouvez aussi déclencher manuellement une bascule au moyen de l’API Amazon RDS.

La couche de réplication n’a qu’une visibilité limitée à elle-même et de ce fait est incapable de prendre les décisions stratégiques comme le moment opportun pour la bascule. C’est pour cette raison que les deux instances sont surveillées et gérées par un observateur externe qui a accès aux informations les plus critiques et interroge périodiquement les instances pour connaître leur statut. Quand cela s’impose, l’observateur agit pour s’assurer que le niveau de disponibilité et de performance est maintenu.

Les améliorations en terme de disponibilité et de durabilité qu’apporte le Multi-AZ n’impacte que de manière minime les performances. En mode nominal, les couches de réplications sont connectées et les opérations d’écriture sont répliqués de manière synchrone sur le volume Amazon EBS secondaire. L’instance et le volume secondaire sont localisés dans une zone de disponibilité distincte et géographiquement éloigné. Des mesures montrent que les commits de transaction des bases de données présente une latence entre 2ms à 5ms. supérieure. L’impact perceptible sur des uses cases réel dépend donc grandement du contexte de ces opérations.

La plupart de nos clients qui utilisent des instances de base de données en Multi-AZ, ne perçoivent qu’un impact mineur voire pas d’impact sur les performances. Ce design permet à AWS d’offrir à ses clients un niveau de service (SLA) qui dépasse 99.95% en termes de disponibilité pour les données des clients. Pour en savoir plus, vous pouvez consulter le niveau de service (SLA) du service RDS.

Quelques subtilités d’implémentation

Vous pourriez pensez que le design des mécanismes de réplication de volume est plutôt simple et facile à implémenter. Cependant, il n’en est rien, l’implémentation est plutôt complexe. En effet, ces mécanismes doivent tenir compte de toutes les situations dans lesquelles peuvent se trouver deux instances et volumes différents interconnectés et soumis à un environnement où des perturbations peuvent constamment subvenir.

Pour que les réplications en cours se déroulent normalement, cela suppose que toutes les composantes fonctionnent normalement : les instances Amazon EC2 sont opérationnelles, le statut des instances remonté par le monitoring est fonctionnel, les volumes Amazon EBS sont disponibles et le réseau se comporte comme prévu. Mais que se passe-t-il quand une ou plusieurs composantes sont en mode dégradé ? Regardons quelques uns des types d’incidents qui peuvent se produire et comment ils sont gérés.

Incident de connectivité et de synchronisation

Parfois, les instances primaires et secondaires ne sont pas connectées entre elles, soit en raison d’un problème ou d’une action de maintenance délibérée. Les réplications qui étaient en cours ne sont plus possibles mais attendre trop longtemps que la connectivité soit rétablie n’est pas acceptable.

Le plus souvent, les problèmes de connectivité sont rapidement investigués et corrigés. Si l’incident persiste au-delà d’une courte durée, cela attire l’attention des opérateurs pour agir et intervenir. C’est pourquoi on peut s’attendre à ce que la majorité des incidents de connectivité soient plutôt de courte durée et que les deux instances restaurent rapidement leur connectivité. Une fois leur connectivité rétablie, les volumes doivent être resynchronisés avant de retourner à l’état normal de réplication en cours. Le processus de resynchronisation s’assurent que les deux copies de données sont restaurées dans un état cohérent.

Afin de réduire le temps de resynchronisation, le nœud primaire garde trace des blocks qui ont été modifiés durant la période ou les deux instances étaient déconnectées. Quand la resynchronisation redémarre, seules les modifications devant être propagées de l’instance primaire vers l’instance secondaire sont appliquées ce qui accélère le processus.

Tolérance aux pannes dans un environnement dynamique

AWS est un environnement dynamique à grande échelle et Amazon RDS Multi-AZ est conçu pour intervenir et prendre les actions correctives quand des perturbations logicielles ou hardware surviennent. Lorsque des incidents se produisent, les problèmes de disponibilité d’instance ou de volume sont les plus courants et ils sont majoritairement résolu par les procédures de bascule. Cela permet d’assurer la disponibilité du service au moyen de l’instance et du volume Amazon EBS secondaire.

Dans le cas peu fréquent ou un volume rencontre une panne matérielle, il est remplacé par un nouveau volume. Le processus de remplacement débute, par sécurité, par la prise d’un snapshot du volume restant. Cette opération est effectuée pour assurer la durabilité des données, mais cela permet également d’améliorer la performance des prochaines resynchronisation des volumes Amazon EBS. L’instance est connectée au nouveau volume Amazon EBS et celui-ci est reconstitué à partir du snapshot. Une fois reconstruit, les volumes sont re-synchronisés et la réplication est rétablie.

Le remplacement d’une instance Amazon EC2 ou d’un volume Amazon EBS peut aussi être une option dans les situations où un élément de l’architecture commence à montrer un comportement inhabituel par rapport à la norme établie. Par exemple, un accroissement sensible ou prolongé de la latence ou une réduction de la bande passante peut indiquer une perturbation localisée sur le chemin d’accès à la ressource. Dans ces situations, le remplacement définitif du volume Amazon EBS est la solution la plus probable.

Il peut y avoir des situations pour lesquelles une région AWS entière ou zone de disponibilité soient affectées, par exemple durant des évènements météorologiques extrêmes ou une coupure d’électricité de grande ampleur. Durant ces situations exceptionnelles, une attention toute particulière est prise pour s’assurer que les instances Multi-AZ restent disponibles. Durant ces périodes, il faut prendre garde à ne pas amplifier l’incident en cours pour éviter de dégrader encore plus la situation. Le système d’observation utilisent les informations de disponibilité des Régions pour retarder les actions automatisées de restauration qui sont non-nécessaires, le temps que les perturbations en cours soient résolues.

Conclusion

Les configurations Amazon RDS en Multi-AZ améliore sensiblement la disponibilité et la durabilité des données de nos clients. Avec des mécanismes de surveillance, de détection d’incident et d’actions correctives pour rétablir la disponibilité lors d’évènements disruptifs, le Multi-AZ permet de préserver l’intégrité des données. Pour plus d’information, vous pouvez consulter Haute disponibilité (Multi-AZ) pour Amazon RDS dans le guide de l’utilisateur Amazon RDS.

Article original écrit par John Gemignani développeur dans l’équipe Amazon RDS et adapté en français par Olivier Rossant, Solutions Architect dans l’équipe AWS France.