Résilience 3-AZ : Mécanismes et architectures de référence

Ce schéma illustre une application en trois couches (frontend web, backend applicatif et base de données) déployée sur trois zones de disponibilité (AZ), et reposant sur des services régionaux du Public Cloud (Load Balancer, Base de données managée, Floating IP et Gateway) pour assurer haute disponibilité et résilience, même en cas d’incident affectant une AZ.

1. La Gateway expose publiquement le Load Balancer via une Floating IP.
2. Le Load Balancer répartit le trafic réseau entre les instances web.
3. Le groupe de sécurité web :
   • Accepte uniquement le trafic entrant provenant des IP privées du Load Balancer sur le port web.
   • Autorise uniquement le trafic sortant vers le groupe de sécurité App sur le port App.
4. Le groupe de sécurité App :
   • Accepte uniquement le trafic entrant provenant du groupe de sécurité web sur le port App.
   • Autorise uniquement le trafic sortant vers l’IP privée et le port de la base de données managée.
5. La base de données managée utilise une ACL qui n’autorise que les connexions provenant des IP privées des instances App.

Fonctionnement normal (côté gauche) :

• L’application est déployée sur trois AZ (a, b et c).
• Toutes les AZ sont connectées au même réseau privé.
• Couche web : 3 instances web sont réparties sur les AZ (Web 1 sur AZ-a, Web 2 sur AZ-b, Web 3 sur AZ-c).
• Couche App : 3 instances applicatives sont réparties sur les AZ (App 1 sur AZ-a, App 2 sur AZ-b, App 3 sur AZ-c).
• Couche données : Une base de données managée régionale est disponible sur toutes les AZ.
• Un Load Balancer régional (avec nœuds actifs/passifs gérés par OVHcloud) répartit le trafic entre les instances web.
• Les groupes de sécurité restreignent le trafic entre les couches :
  • Le groupe de sécurité web n’autorise que les connexions provenant du Load Balancer et vers la couche App.
  • Le groupe de sécurité App n’autorise que les connexions provenant de la couche web et vers la base de données managée.
• La connectivité est assurée par une Floating IP et une Gateway. Les deux services reposent sur un mécanisme actif/passif géré par OVHcloud, aucune configuration supplémentaire n’est nécessaire.

Incident sur AZ‑a (côté droit) :

• L’AZ‑a tombe, rendant Web 1 et App 1 indisponibles.
• La Gateway dans AZ‑a devient inaccessible, mais la Gateway passive dans une autre AZ prend automatiquement le relais (résilience gérée par OVHcloud).
• Le Load Balancer reste disponible grâce à son architecture active/passive gérée par OVHcloud et continue de répartir le trafic entre Web 2 et Web 3.
• La Floating IP reste disponible grâce à son mécanisme actif/passif et continue de router les requêtes vers les instances saines.
• Les instances backend App 2 (AZ-b) et App 3 (AZ-c) continuent de fonctionner et de traiter les requêtes.
• La base de données managée régionale reste pleinement disponible sur toutes les AZ.
• L’application continue de servir les utilisateurs sans interruption, même si la capacité globale est temporairement réduite.

Grâce aux services régionaux (Load Balancer, Gateway, Floating IP et base de données managée), l’application reste résiliente et disponible pendant tout l’incident. Une fois l’AZ‑a rétablie, Web 1 et App 1 se réintègrent automatiquement, et l’application retrouve un fonctionnement en haute disponibilité complète.

Recovery :

• Une fois l’AZ‑a restaurée, ses instances Web 1 et App 1 redémarrent et se synchronisent avec le reste de l’application. Elles redeviennent actives et reprennent le traitement du trafic applicatif.
• Les services réseau régionaux OVHcloud (Gateway, Load Balancer, Floating IP) dans AZ‑a sont réactivés, mais ne retrouvent pas leur état initial actif. Ils restent passifs, car l’AZ où ils étaient déjà actifs conserve ce rôle. OVHcloud gère automatiquement le mécanisme actif/passif pour maintenir la résilience.
• La base de données managée continue d’accepter les connexions depuis AZ‑a et se synchronise normalement.
• Le Load Balancer réintègre progressivement Web 1 dans la distribution du trafic.
• L’application retrouve sa haute disponibilité (HA) complète sur les trois AZ. Toutefois, l’état actif/passif des services réseau peut différer de la configuration initiale : AZ‑a est active pour les instances applicatives mais passive pour les services réseau, tandis que l’AZ initialement active pour les services réseau conserve ce rôle.

Ce schéma illustre une application déployée sur deux Availability Zones (AZ) en s’appuyant sur un service Block Storage régional pour assurer la résilience.

Fonctionnement normal (Côté gauche) :

• L’application est répartie sur deux AZ (a et b).
• Les 2 AZ sont dans le même Private Network.
• L'instance 1 fonctionne sur l’AZ-a et l'instance 2 sur l’AZ-b.
• Un Load Balancer actif répartit le trafic sur l’AZ-a, avec un Load Balancer passif en attente sur l’AZ-b.
• Le service Block Storage est régional, partagé entre les zones de disponibilité, et simultanément attaché à la fois à l’Instance 1 sur AZ-a et à l’Instance 2 sur AZ-b (voir notre guide « Utilisation correcte et limitations du stockage Classic Multi-Attach dans les régions 3AZ »).
• La connectivité est assurée par une Floating IP et une Gateway (dont une seconde disponible en cas de défaillance).

Incident sur l’AZ-a (Côté droit) :

• L’AZ-a tombe en panne, rendant l’Instance 1 et le Load Balancer actif indisponibles.
• La Gateway de l'AZ-a devient inacessible mais une seconde se trouvant dans une autre AZ prend le relais.
• Le Load Balancer passif devient actif pour assurer la continuité du service.
• La Floating IP peut être basculée dynamiquement via le Private Network vers l'AZ-b pour permettre un accès continu à l'application.
• L’Instance 2 (qui se trouve dans l’AZ-b) prend automatiquement le relais.
• L’application reste disponible, mais l’application ne fonctionne plus en mode haute disponibilité (High Availability - HA).

Grâce au transfert dynamique de services entre Availability Zones, l’application est restée active tout au long de l’incident, sans interruption pour les utilisateurs. Une fois AZ-a rétabli, l'application revient à son état initial et redevient hautement disponible.

Ce schéma illustre une architecture de déploiement en 2-AZ avec du service Block Storage local.

Fonctionnement normal (Côté gauche) :

• L’application est répartie sur deux AZ (a et b).
• L'instance 1 fonctionne sur l’AZ-a, et Instance 2 sur l’AZ-b.
• Un Load Balancer actif distribue le trafic sur l'AZ-a, avec un Load Balancer passif en attente sur l'AZ-b.
• Le service Block Storage est local, ce qui signifie que chaque instance dispose de son propre volume attaché à son AZ et non partagé avec l'autre AZ.
• Les 2 AZ sont dans le même Private Network.
• La connectivité est assurée par une Floating IP et une Gateway (dont une seconde disponible en cas de défaillance).

Incident sur l’AZ-a (Côté droit) :

• L'AZ-a tombe en panne, rendant l'Instance 1 et le Load Balancer actif indisponibles.
• La Gateway de l'AZ-a devient inacessible mais une seconde se trouvant dans une autre AZ prend le relais.
• Le Load Balancer passif devient actif pour assurer la continuité du service.
• La Floating IP peut être basculée dynamiquement via le Private Network vers l'AZ-b pour permettre un accès continu à l'application.
• L'instance 2 (située dans l'AZ-b) prend automatiquement le relais.
• L'application reste disponible, mais elle ne fonctionne plus en mode haute disponibilité (HA).
• Comme le service de stockage est local et non régional, les données stockées sur l'instance AZ-a peuvent être perdues temporairement ou définitivement (en cas de panne majeure) jusqu'à ce que la zone soit restaurée.

Grâce au transfert dynamique des services entre les Availability Zones, l'application est restée active pendant toute la durée de l'incident, sans interruption pour les utilisateurs. Une fois AZ-a rétabli, l'application revient à son état initial et redevient hautement disponible. Un backup programmé à l'avance peut être utile pour récupérer les données et restaurer le volume Block Storage en cas de panne majeure.