Haute disponibilité

Objectifs du chapitre

Comprendre la haute disponibilité dans Swarm
Configurer la tolérance aux pannes des managers
Assurer la résilience des services
Planifier la reprise après sinistre

1 - Concepts de haute disponibilité

Définitions

Terme	Description
HA	High Availability - Disponibilité élevée
Failover	Basculement automatique vers un backup
Quorum	Nombre minimum de nœuds pour fonctionner
Split-brain	Situation où le cluster se divise

Architecture HA

┌─────────────────────────────────────────────────────────────┐
│                  Cluster Haute Disponibilité                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   Zone A              Zone B              Zone C            │
│   ┌──────────┐       ┌──────────┐       ┌──────────┐       │
│   │ Manager  │       │ Manager  │       │ Manager  │       │
│   │ (Leader) │◄─────▶│(Reachable)◄─────▶│(Reachable)│       │
│   └────┬─────┘       └────┬─────┘       └────┬─────┘       │
│        │                  │                  │              │
│   ┌────▼─────┐       ┌────▼─────┐       ┌────▼─────┐       │
│   │ Worker 1 │       │ Worker 3 │       │ Worker 5 │       │
│   │ Worker 2 │       │ Worker 4 │       │ Worker 6 │       │
│   └──────────┘       └──────────┘       └──────────┘       │
│                                                             │
│   Si Zone A tombe → Zone B ou C prend le lead              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

2 - Haute disponibilité des managers

Nombre de managers recommandé

Managers	Quorum	Tolérance aux pannes	Recommandation
1	1	0	Dev/Test uniquement
2	2	0	Pas recommandé
3	2	1	Production minimale
5	3	2	Production standard
7	4	3	Grande production

Important

Toujours un nombre impair de managers pour éviter le split-brain.

Configurer 3 managers

# Sur le premier manager
docker swarm init --advertise-addr 192.168.1.10

# Obtenir le token manager
docker swarm join-token manager

# Sur les autres managers
docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# Vérifier
docker node ls

Distribution géographique

# Ajouter des labels de zone
docker node update --label-add zone=eu-west-1a manager1
docker node update --label-add zone=eu-west-1b manager2
docker node update --label-add zone=eu-west-1c manager3

# Répartir les services par zone
docker service create --name critical-app \
  --replicas 6 \
  --placement-pref 'spread=node.labels.zone' \
  myapp

3 - Tolérance aux pannes des services

Réplicas et disponibilité

# Plus de réplicas = plus de résilience
docker service create --name web \
  --replicas 5 \
  nginx

# Si un nœud tombe, les tâches sont redéployées

Politique de redémarrage

services:
  api:
    deploy:
      restart_policy:
        condition: on-failure    # none, on-failure, any
        delay: 5s               # Délai avant redémarrage
        max_attempts: 3         # Nombre max de tentatives
        window: 120s           # Fenêtre de comptage des échecs

Healthchecks

services:
  api:
    image: myapi
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      replicas: 3

Comportement :

Swarm surveille la santé des conteneurs
Si unhealthy, le conteneur est arrêté
Une nouvelle tâche est créée
L'ancienne tâche est supprimée

4 - Gestion des pannes de nœuds

Comportement automatique

Panne d'un worker :

Avant:              Node 1    Node 2    Node 3
                    [web.1]   [web.2]   [web.3]
                    [web.4]   [web.5]

                        ↓ Node 2 tombe ↓

Après (auto):       Node 1    Node 2    Node 3
                    [web.1]     ❌      [web.3]
                    [web.4]             [web.5]
                    [web.2*]            [NEW]
                    
* web.2 redéployé sur Node 1 ou 3

Comportement lors de la panne d'un manager

3 Managers :
┌──────────┐  ┌──────────┐  ┌──────────┐
│ Manager1 │  │ Manager2 │  │ Manager3 │
│ (Leader) │  │(Reachable)│  │(Reachable)│
└──────────┘  └──────────┘  └──────────┘
    │              │              │
    ▼ Tombe        ▼              ▼
    ❌         ┌──────────┐  ┌──────────┐
               │ Manager2 │  │ Manager3 │
               │ (Leader) │  │(Reachable)│
               └──────────┘  └──────────┘

Quorum maintenu (2/3) → Cluster fonctionnel
Nouveau leader élu automatiquement

Perte du quorum

# Si vous perdez le quorum (ex: 2 managers sur 3 tombent)
# Le cluster devient non fonctionnel

# Récupération forcée (sur le manager restant)
docker swarm init --force-new-cluster --advertise-addr <IP>

# Reconstruire ensuite en ajoutant de nouveaux managers

5 - Mode drain et maintenance

Mettre un nœud en maintenance

# Drainer le nœud (les tâches sont déplacées)
docker node update --availability drain worker1

# État du nœud
docker node ls
# AVAILABILITY: Drain

# Les tâches sont reschedulées sur les autres nœuds
docker service ps web

# Réactiver après maintenance
docker node update --availability active worker1

Maintenance planifiée

#!/bin/bash
# maintenance.sh

NODE=$1

echo "Draining node $NODE..."
docker node update --availability drain $NODE

echo "Waiting for tasks to migrate..."
sleep 30

echo "Performing maintenance..."
# Vos commandes de maintenance ici
ssh $NODE "apt update && apt upgrade -y && reboot"

echo "Waiting for node to come back..."
sleep 120

echo "Reactivating node..."
docker node update --availability active $NODE

echo "Done!"

6 - Backup et restauration

Sauvegarder l'état du Swarm

# Sur un manager (de préférence le leader)
# Arrêter Docker
sudo systemctl stop docker

# Sauvegarder le répertoire swarm
sudo tar -cvzf swarm-backup-$(date +%Y%m%d).tar.gz \
  /var/lib/docker/swarm

# Redémarrer Docker
sudo systemctl start docker

Données à sauvegarder

Donnée	Emplacement	Critique
État Swarm	`/var/lib/docker/swarm`	Oui
Secrets	Inclus dans swarm	Oui
Configs	Inclus dans swarm	Oui
Volumes	`/var/lib/docker/volumes`	Oui
Images	Registre externe	Non

Script de backup complet

#!/bin/bash
# backup-swarm.sh

BACKUP_DIR="/backups/swarm"
DATE=$(date +%Y%m%d_%H%M%S)

# Créer le répertoire
mkdir -p $BACKUP_DIR

# Sauvegarder l'état Swarm (manager uniquement)
if docker node ls > /dev/null 2>&1; then
  echo "Backing up Swarm state..."
  sudo systemctl stop docker
  sudo tar -czf $BACKUP_DIR/swarm-state-$DATE.tar.gz /var/lib/docker/swarm
  sudo systemctl start docker
fi

# Sauvegarder les volumes
echo "Backing up volumes..."
for vol in $(docker volume ls -q); do
  docker run --rm \
    -v $vol:/source:ro \
    -v $BACKUP_DIR:/backup \
    alpine tar -czf /backup/volume-$vol-$DATE.tar.gz -C /source .
done

# Exporter les secrets (métadonnées seulement)
echo "Exporting secrets list..."
docker secret ls > $BACKUP_DIR/secrets-list-$DATE.txt

# Exporter les configs
echo "Exporting configs..."
docker config ls > $BACKUP_DIR/configs-list-$DATE.txt

# Nettoyer les vieux backups
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

echo "Backup completed: $BACKUP_DIR"

Restauration

# Restaurer l'état Swarm
sudo systemctl stop docker
sudo rm -rf /var/lib/docker/swarm
sudo tar -xzf swarm-backup.tar.gz -C /
sudo systemctl start docker

# Récupérer le cluster
docker swarm init --force-new-cluster

7 - Monitoring de la disponibilité

Métriques clés

# État des nœuds
docker node ls

# Services unhealthy
docker service ls --filter "replicas=0/N"

# Tâches en échec
docker service ps --filter "desired-state=running" --filter "actual-state=failed" myservice

Alerting avec Prometheus

# alert-rules.yml
groups:
  - name: swarm-ha
    rules:
      - alert: SwarmNodeDown
        expr: swarm_node_manager_reachable == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Swarm node {{ $labels.node_id }} is down"

      - alert: SwarmQuorumAtRisk
        expr: count(swarm_node_manager_leader) < 2
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Swarm quorum at risk"

      - alert: ServiceReplicasMismatch
        expr: swarm_service_running_replicas != swarm_service_desired_replicas
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Service {{ $labels.service_name }} has replica mismatch"

8 - Bonnes pratiques HA

Architecture

# ✅ 3 ou 5 managers (jamais pair)
# ✅ Managers dans différentes zones/racks
# ✅ Au moins 3 réplicas pour les services critiques
# ✅ Healthchecks sur tous les services
# ✅ Limites de ressources définies

# ❌ Éviter
# - 2 managers (pas de quorum en cas de panne)
# - Tous les managers dans la même zone
# - Services critiques avec 1 seul réplica

Checklist HA

## Checklist Haute Disponibilité

### Infrastructure
- [ ] 3+ managers (nombre impair)
- [ ] Managers dans différentes zones
- [ ] Workers répartis géographiquement
- [ ] Réseau redondant

### Services
- [ ] Réplicas >= 3 pour services critiques
- [ ] Healthchecks configurés
- [ ] Restart policy définie
- [ ] Rolling update configuré

### Données
- [ ] Volumes sur stockage persistant
- [ ] Backups automatisés
- [ ] Test de restauration régulier

### Monitoring
- [ ] Alertes sur état des nœuds
- [ ] Alertes sur quorum
- [ ] Alertes sur réplicas manquants

Résumé

Concept	Description
Quorum	Majorité de managers nécessaire
Failover	Élection automatique d'un nouveau leader
Drain	Déplacer les tâches avant maintenance
Backup	Sauvegarder `/var/lib/docker/swarm`

Points clés

3 ou 5 managers pour la production
Répartir les managers géographiquement
Healthchecks obligatoires pour la résilience
Tester régulièrement la restauration des backups

Exercices pratiques

Configurez un cluster avec 3 managers
Simulez la panne d'un manager et observez le failover
Mettez un worker en mode drain et observez la migration
Créez un script de backup et testez la restauration

← Scaling et Load Balancing | Bonnes pratiques →

Objectifs du chapitre​

1 - Concepts de haute disponibilité​

Définitions​

Architecture HA​

2 - Haute disponibilité des managers​

Nombre de managers recommandé​

Configurer 3 managers​

Distribution géographique​

3 - Tolérance aux pannes des services​

Réplicas et disponibilité​

Politique de redémarrage​

Healthchecks​

4 - Gestion des pannes de nœuds​

Comportement automatique​

Comportement lors de la panne d'un manager​

Perte du quorum​

5 - Mode drain et maintenance​

Mettre un nœud en maintenance​

Maintenance planifiée​

6 - Backup et restauration​

Sauvegarder l'état du Swarm​

Données à sauvegarder​

Script de backup complet​

Restauration​

7 - Monitoring de la disponibilité​

Métriques clés​

Alerting avec Prometheus​

8 - Bonnes pratiques HA​

Architecture​

Checklist HA​

Résumé​

Exercices pratiques​

Objectifs du chapitre

1 - Concepts de haute disponibilité

Définitions

Architecture HA

2 - Haute disponibilité des managers

Nombre de managers recommandé

Configurer 3 managers

Distribution géographique

3 - Tolérance aux pannes des services

Réplicas et disponibilité

Politique de redémarrage

Healthchecks

4 - Gestion des pannes de nœuds

Comportement automatique

Comportement lors de la panne d'un manager

Perte du quorum

5 - Mode drain et maintenance

Mettre un nœud en maintenance

Maintenance planifiée

6 - Backup et restauration

Sauvegarder l'état du Swarm

Données à sauvegarder

Script de backup complet

Restauration

7 - Monitoring de la disponibilité

Métriques clés

Alerting avec Prometheus

8 - Bonnes pratiques HA

Architecture

Checklist HA

Résumé

Exercices pratiques