Concepts de Haute Disponibilité
Qu'est-ce que la Haute Disponibilité ?
La Haute Disponibilité (HA) est la capacité d'un système à rester opérationnel et accessible même en cas de panne d'un ou plusieurs de ses composants.
┌─────────────────────────────────────────────────────────────┐
│ HAUTE DISPONIBILITÉ │
├─────────────────────────────────────────────────────────────┤
│ │
│ Objectif : Le service reste accessible malgré les pannes │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Panne serveur ? → Autre serveur prend le relai│ │
│ │ Panne zone (AZ) ? → Autre AZ prend le relai │ │
│ │ Panne région ? → Autre région (DR) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Mesure : Pourcentage de disponibilité (uptime) │
│ │
│ 99% = 3.65 jours de downtime/an (pas acceptable) │
│ 99.9% = 8.76 heures de downtime/an (standard) │
│ 99.99% = 52.6 minutes de downtime/an (haute dispo) │
│ 99.999% = 5.26 minutes de downtime/an (très haute) │
│ │
└─────────────────────────────────────────────────────────────┘
SPOF - Single Point of Failure
Un SPOF est un composant dont la panne entraîne l'arrêt complet du système.
┌─────────────────────────────────────────────────────────────┐
│ IDENTIFIER LES SPOF │
├─────────────────────────────────────────────────────────────┤
│ │
│ ARCHITECTURE AVEC SPOF │
│ ────────────────────── │
│ │
│ Utilisateurs │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ Serveur │ ← SPOF ! Si ce serveur tombe, tout s'arrête │
│ │ Web │ │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ BDD │ ← SPOF ! Une seule base de données │
│ │ │ │
│ └─────────┘ │
│ │
│ SPOF identifiés : │
│ ❌ 1 seul serveur web │
│ ❌ 1 seule base de données │
│ ❌ 1 seule zone de disponibilité │
│ │
└─────────────────────────────────────────────────────────────┘
Éliminer les SPOF
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE SANS SPOF │
├─────────────────────────────────────────────────────────────┤
│ │
│ Utilisateurs │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Load Balancer│ ← Géré par AWS (haute dispo native) │
│ └──────┬──────┘ │
│ │ │
│ ┌─────┼─────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──┐ ┌──┐ ┌──┐ │
│ │S1│ │S2│ │S3│ ← 3 serveurs dans 3 AZ différentes │
│ └┬─┘ └┬─┘ └┬─┘ │
│ │ │ │ │
│ └─────┼─────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ RDS Multi-AZ│ ← Base de données avec standby auto │
│ │ Primary │ │
│ │ ↓ │ │
│ │ Standby │ │
│ └─────────────┘ │
│ │
│ SPOF éliminés : │
│ ✅ Multiple serveurs web │
│ ✅ Base de données Multi-AZ │
│ ✅ Répartition sur plusieurs AZ │
│ │
└─────────────────────────────────────────────────────────────┘
Architecture Multi-AZ
Zones de Disponibilité AWS
┌─────────────────────────────────────────────────────────────┐
│ ZONES DE DISPONIBILITÉ (AZ) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Région AWS (ex: us-east-1) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │
│ │ │ AZ-a │ │ AZ-b │ │ AZ-c │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ Datacenter│ │ Datacenter│ │ Datacenter│ │ │
│ │ │ isolé │ │ isolé │ │ isolé │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │
│ │ │ │ │ │ │
│ │ └──────────────┼──────────────┘ │ │
│ │ │ │ │
│ │ Réseau haute vitesse │ │
│ │ (faible latence entre AZ) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Caractéristiques : │
│ • Chaque AZ = 1+ datacenters physiquement séparés │
│ • Alimentation, réseau, refroidissement indépendants │
│ • Distance suffisante pour éviter catastrophe commune │
│ • Latence < 2ms entre AZ de la même région │
│ │
└─────────────────────────────────────────────────────────────┘
Calcul de Disponibilité
┌─────────────────────────────────────────────────────────────┐
│ CALCUL DE DISPONIBILITÉ │
├─────────────────────────────────────────────────────────────┤
│ │
│ Formule : Dispo_totale = 1 - (1 - Dispo_composant)^n │
│ │
│ Exemple : Un serveur a 99% de disponibilité │
│ │
│ 1 serveur : │
│ Dispo = 99% = 0.99 │
│ Downtime = 3.65 jours/an │
│ │
│ 2 serveurs (en parallèle) : │
│ Dispo = 1 - (1-0.99)² = 1 - 0.0001 = 99.99% │
│ Downtime = 52 minutes/an │
│ │
│ 3 serveurs (en parallèle) : │
│ Dispo = 1 - (1-0.99)³ = 1 - 0.000001 = 99.9999% │
│ Downtime = 32 secondes/an │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Nombre de serveurs Disponibilité Downtime │ │
│ │ ────────────────── ──────────── ───────── │ │
│ │ 1 99% 3.65 jours │ │
│ │ 2 99.99% 52 minutes │ │
│ │ 3 99.9999% 32 secondes │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ⚠️ Attention : Cela suppose des pannes indépendantes ! │
│ Si les serveurs sont dans la même AZ, une panne AZ │
│ les affecte tous → utiliser Multi-AZ │
│ │
└─────────────────────────────────────────────────────────────┘
Patterns de Haute Disponibilité
Pattern 1 : Active-Passive
┌─────────────────────────────────────────────────────────────┐
│ ACTIVE-PASSIVE (Standby) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ ACTIVE │ │ PASSIVE │ │ │
│ │ │ (Primary) │───────►│ (Standby) │ │ │
│ │ │ │ sync │ │ │ │
│ │ │ Traite le │ │ Attend │ │ │
│ │ │ trafic │ │ son tour │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │ │
│ │ │ Si panne │ │
│ │ ▼ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ (down) │ │ ACTIVE │ │ │
│ │ │ │ │ (nouveau) │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ Avantages : Inconvénients : │
│ ✅ Simple ❌ Ressources sous-utilisées│
│ ✅ Données synchronisées ❌ Failover pas instantané │
│ ✅ Coût modéré │
│ │
│ Cas d'usage : RDS Multi-AZ, bases de données │
│ │
└─────────────────────────────────────────────────────────────┘
Pattern 2 : Active-Active
┌─────────────────────────────────────────────────────────────┐
│ ACTIVE-ACTIVE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────────────┐ │ │
│ │ │ Load Balancer │ │ │
│ │ └────────┬────────┘ │ │
│ │ │ │ │
│ │ ┌───────────┼───────────┐ │ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │ ACTIVE │ │ ACTIVE │ │ ACTIVE │ │ │
│ │ │ (1) │ │ (2) │ │ (3) │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ Traite │ │ Traite │ │ Traite │ │ │
│ │ │ trafic │ │ trafic │ │ trafic │ │ │
│ │ └────────┘ └────────┘ └────────┘ │ │
│ │ AZ-a AZ-b AZ-c │ │
│ │ │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ Avantages : Inconvénients : │
│ ✅ Toutes ressources utilisées ❌ Plus complexe │
│ ✅ Meilleure performance ❌ Sync données difficile │
│ ✅ Failover transparent │
│ │
│ Cas d'usage : Serveurs web stateless, APIs │
│ │
└─────────────────────────────────────────────────────────────┘
Services AWS Haute Disponibilité
| Service | HA Native | Configuration Requise |
|---|---|---|
| S3 | ✅ 99.999999999% | Aucune |
| DynamoDB | ✅ Multi-AZ auto | Aucune |
| ALB/NLB | ✅ Multi-AZ | Spécifier 2+ subnets |
| RDS | ⚠️ Option | Activer Multi-AZ |
| EC2 | ❌ Non | Concevoir avec ASG |
| Lambda | ✅ Multi-AZ auto | Aucune |
| Aurora | ✅ Multi-AZ | Activer replicas |
Exercice : Identifier les SPOF
Scénario
Analysez cette architecture et identifiez les SPOF :
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE À ANALYSER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Internet │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ ALB │ │
│ └────┬─────┘ │
│ │ │
│ ┌──────────┴──────────┐ │
│ │ │ │
│ ▼ ▼ │
│ ┌────────┐ ┌────────┐ │
│ │ EC2 │ │ EC2 │ │
│ │ AZ-a │ │ AZ-a │ │
│ └────┬───┘ └────┬───┘ │
│ │ │ │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ RDS │ │
│ │ Single │ │
│ │ AZ │ │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
💡 Solution
SPOF identifiés :
-
❌ Toutes les EC2 dans la même AZ (AZ-a)
- Si AZ-a tombe, tous les serveurs sont down
- Solution : Répartir dans AZ-a et AZ-b minimum
-
❌ RDS Single-AZ
- Si l'AZ de la BDD tombe, perte de données possible
- Solution : Activer RDS Multi-AZ
-
✅ ALB est OK (Multi-AZ par défaut si 2+ subnets)
Architecture corrigée :
- EC2 dans AZ-a ET AZ-b
- RDS avec Multi-AZ activé
- ALB avec subnets dans 2+ AZ
Résumé
| Concept | Description |
|---|---|
| HA | Système reste accessible malgré pannes |
| SPOF | Composant unique dont la panne arrête tout |
| Multi-AZ | Répartition sur plusieurs zones |
| 99.9% | ~8h downtime/an (standard) |
| Active-Passive | Un actif, un en attente |
| Active-Active | Tous traitent le trafic |
Prochaine section : Load Balancers