7 85 Stratégie de routage par basculement
La stratégie de routage par basculement (failover) repose sur deux cibles : une primaire et une secondaire (souvent placée dans une région différente pour le disaster recovery). Tant que le health check sur la cible primaire reste sain, Route 53 renvoie l'IP de la primaire. Si la primaire tombe (trois échecs consécutifs), Route 53 bascule automatiquement vers la cible secondaire.
Configuration
Dans Route 53, créez un enregistrement avec la politique Basculement, type A, TTL 60 secondes. Première étape : définir la cible primaire — par exemple l'instance Irlande. Sélectionnez « Primaire », saisissez l'IP, associez le health check correspondant (hc-irlande), donnez un identifiant unique. Sans health check, le basculement ne peut pas fonctionner.
Deuxième étape : créer un second enregistrement portant le même nom, cette fois marqué « Secondaire ». L'IP est celle de l'instance Asie (par exemple Tokyo), associée à son health check. Si la primaire tombe ET que la secondaire est saine, c'est cette dernière qui sera renvoyée. Si les deux tombent, Route 53 renvoie quand même la primaire (mieux que rien) et déclenche les alarmes CloudWatch éventuellement configurées.
Test du basculement
Pour valider le basculement, accédez à l'URL : la primaire (Irlande) répond. Ouvrez en parallèle la console des health checks pour suivre les changements d'état. Arrêtez l'instance EC2 Irlande depuis la console. Au bout de quelques cycles de vérification (trois échecs de 30 s), le health check passe en unhealthy. Route 53 commence à renvoyer l'IP de la secondaire, et le rafraîchissement du navigateur (après expiration du TTL) affiche désormais la page servie par l'instance Tokyo.
- Une seule paire primaire/secondaire par nom d'enregistrement
- Health check obligatoire sur les deux cibles
- TTL faible recommandé (60 s) pour minimiser le délai de bascule client
- Combinable avec CloudWatch pour alerter sur la bascule
- Idéal pour les architectures actif/passif disaster recovery
En résumé
Cette leçon explique la stratégie de routage par basculement dans Route 53 pour assurer la disponibilité et la reprise d'activité des applications. Elle détaille comment configurer une architecture avec une instance primaire et une instance secondaire, où Route 53 utilise les vérifications d'état pour basculer automatiquement le trafic en cas de panne détectée. Une démonstration pratique montre en direct comment le basculement s'effectue lorsque l'instance primaire est arrêtée.
Points clés
- Route 53 utilise les vérifications d'état (health checks) pour déterminer l'état de l'instance primaire et déclencher le basculement en cas de panne
- La stratégie de basculement associe chaque instance à un health check spécifique pour sa zone géographique (Europe, Ireland, Tokyo)
- Le trafic bascule automatiquement vers l'instance secondaire dès que l'instance primaire ne répond pas aux vérifications d'état
- Un TTL de 60 secondes permet une détection et un basculement rapides lors d'une panne
- CloudWatch permet de monitorer en temps réel les changements d'état des vérifications d'état et le basculement entre instances
Questions fréquentes
Qu'est-ce qu'un health check dans la stratégie de basculement Route 53 ?
C'est une vérification automatique de l'état de santé d'une instance. Route 53 teste régulièrement chaque instance associée au health check. Si l'instance ne répond pas, la vérification échoue et déclenche le basculement vers l'instance secondaire.
Comment configurer un basculement multi-zones avec Route 53 ?
Il faut créer un enregistrement avec la stratégie de routage par basculement, définir une instance primaire (par exemple en Ireland) et une instance secondaire (par exemple au Japon), puis associer chaque instance au health check approprié pour sa zone géographique.
Quel impact le TTL a-t-il sur le basculement ?
Un TTL de 60 secondes permet une détection et un basculement rapides en cas de panne. C'est le délai après lequel Route 53 réévalue l'état de l'instance et bascule vers le secondaire si nécessaire.