Aller au contenu

TP – Répartir la charge et basculer sur panne

BTS SIO SISR 2e année – Bloc 2 – S12 – binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. Tu calcules une disponibilité, tu répartis le trafic entre deux serveurs web avec HAProxy, tu doubles le répartiteur avec une adresse IP flottante (keepalived), puis tu provoques des pannes et mesures l'interruption.

Durée : 2 h 35 (parties A à E), plus le bilan. Prérequis : cours S12 lu ; S05 ; S06 et S08 (web1 et web2 déployés, avec leur page qui indique leur nom).

Note

Comment ce TP fonctionne. Avant de manipuler, tu écris ce que tu anticipes, puis tu testes et tu notes ce que tu constates. Un bilan de compétences clôt la séance.

Binôme : ____________ / ____________

Le laboratoire (cinq machines)

Machine Rôle Adresse
web1 Serveur web 192.168.10.11/24
web2 Serveur web 192.168.10.12/24
LB1 Répartiteur maître 192.168.10.21/24
LB2 Répartiteur de secours 192.168.10.22/24
CLI Poste client 192.168.10.30/24
(VIP) Adresse flottante 192.168.10.100

Toutes sont sur le même réseau interne. Sur les ressources du laboratoire : si l'hôte manque de mémoire, donne 512 Mo à chaque machine (sans interface graphique, c'est suffisant).

Partie A – Calculer la disponibilité (≈ 25 min)

Le Cabinet Delorme exige 99,9 % pour son site de prise de rendez-vous. Données : un répartiteur à 99,9 %, deux serveurs web à 99 %, un commutateur à 99,95 % commun à tout.

  1. Combien de minutes d'indisponibilité par mois (30 jours) autorise 99,9 % ?
  2. Disponibilité d'ensemble de l'architecture : répartiteur unique, deux serveurs en parallèle, commutateur ?
  3. Même calcul avec deux répartiteurs à 99,9 % en parallèle ?
  4. Atteint-on 99,9 % dans chaque cas ? Quel est le maillon faible ?
Éléments de réponse
  1. 0,001 × 30 × 24 × 60 = 43,2 minutes par mois.
  2. Serveurs en parallèle : 1 − 0,01² = 0,9999. Série : 0,999 × 0,9999 × 0,9995 ≈ 0,9984, soit 99,84 % : l'objectif n'est pas atteint.
  3. Répartiteurs en parallèle : 1 − 0,001² = 0,999999. Série : 0,999999 × 0,9999 × 0,9995 ≈ 0,99940, soit 99,94 % : objectif atteint.
  4. Dans le cas 2, le répartiteur unique est le maillon faible ; dans le cas 3, c'est le commutateur (99,95 %), unique et commun. Doubler aussi le commutateur monterait encore la disponibilité. La redondance n'a de valeur que si elle élimine les SPOF.

Partie B – Répartition de charge avec HAProxy (≈ 40 min)

Sur LB1 et LB2 (carte NAT temporaire pour installer) :

sudo apt update && sudo apt -y install haproxy keepalived

Remplace le contenu de /etc/haproxy/haproxy.cfg sur LB1 et LB2 :

global
    log /dev/log local0
    maxconn 2000

defaults
    mode http
    log global
    option httplog
    timeout connect 3s
    timeout client  30s
    timeout server  30s

frontend entree
    bind *:80
    default_backend web

backend web
    balance roundrobin
    option httpchk GET /
    http-check expect status 200
    server web1 192.168.10.11:80 check inter 2s fall 2 rise 2
    server web2 192.168.10.12:80 check inter 2s fall 2 rise 2

listen statistiques
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 5s

Vérifie puis démarre :

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl restart haproxy

Depuis CLI, interroge LB1 (pas encore la VIP) :

for i in 1 2 3 4 5 6; do curl -s http://192.168.10.21/ | grep -om1 'web[12]'; done

Ouvre aussi la page de statistiques : http://192.168.10.21:8404/stats.

J'anticipe. Quelle suite de noms vas-tu voir ? Que montrera la page de statistiques si tu arrêtes Apache sur web1 ? ______________________

Éléments de réponse

Une alternance web1 web2 web1 web2 … (tourniquet). Si Apache s'arrête sur web1, la sonde échoue deux fois de suite (fall 2, toutes les 2 s) : web1 passe DOWN (rouge) et tous les clients sont servis par web2, sans erreur côté client.

Test de panne côté serveurs.

# sur web1
sudo systemctl stop apache2

Attends environ 5 secondes, puis relance la boucle curl depuis CLI. Remets Apache : sudo systemctl start apache2, attends 5 secondes, relance la boucle.

Moment Noms obtenus
Normal
web1 arrêté
web1 relancé

Je comprends. À quoi servent fall 2 et rise 2 ? Pourquoi ne pas retirer un serveur dès la première sonde ratée ? ______________________

Éléments de réponse

fall 2 : le serveur est déclaré hors service après 2 échecs consécutifs ; rise 2 : il revient après 2 succès consécutifs. Cela évite qu'une sonde isolée ratée (réseau chargé) fasse sortir un serveur sain, et qu'un serveur instable bascule en permanence (même logique que les seuils de supervision, S11).

Partie C – Adresse flottante avec keepalived (≈ 40 min)

Relève d'abord le nom de l'interface réseau de LB1 et LB2 (ip -br a) et remplace enp0s3 si besoin.

LB1 — /etc/keepalived/keepalived.conf :

global_defs {
    router_id LB1
    enable_script_security
    script_user root
}

vrrp_script verif_haproxy {
    script "/usr/bin/systemctl is-active --quiet haproxy"
    interval 2
    fall 2
    rise 2
}

vrrp_instance VIP_WEB {
    state MASTER
    interface enp0s3
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass lab-S12
    }
    virtual_ipaddress {
        192.168.10.100/24
    }
    track_script {
        verif_haproxy
    }
}

LB2 — la même configuration, avec ces trois différences :

Paramètre LB1 LB2
router_id LB1 LB2
state MASTER BACKUP
priority 150 100

Démarre sur les deux machines :

sudo keepalived --config-test
sudo systemctl enable --now keepalived
ip -br a

J'anticipe. Sur quelle machine verras-tu 192.168.10.100 dans ip -br a ? ______________________

Éléments de réponse

Sur LB1 (priorité 150, plus élevée) : l'adresse est ajoutée à son interface. LB2 reste en secours et n'a pas l'adresse.

Depuis CLI, interroge la VIP :

for i in 1 2 3 4; do curl -s http://192.168.10.100/ | grep -om1 'web[12]'; done

Je comprends. Pourquoi virtual_router_id et auth_pass doivent-ils être identiques sur LB1 et LB2 ? ______________________

Éléments de réponse

Ils définissent le groupe VRRP : les deux machines n'échangent leurs annonces que si elles utilisent le même identifiant et le même mot de passe. Sinon, chacune se croit seule et prend la VIP (partition, ou « split brain »).

Partie D – Provoquer des pannes et mesurer (≈ 30 min)

Lance sur CLI, dans un terminal, la mesure continue (toutes les 0,2 s) :

while true; do
  printf '%s ' "$(date +%T.%N | cut -c1-12)"
  curl -s -m 1 http://192.168.10.100/ | grep -om1 'web[12]' || echo ECHEC
  sleep 0.2
done | tee mesure.log

Dans un autre terminal, provoque trois pannes l'une après l'autre, en laissant la mesure tourner et en attendant que tout redevienne normal entre deux pannes :

# Panne Commande
1 Un serveur web sudo systemctl stop apache2 sur web1
2 Le service HAProxy du maître sudo systemctl stop haproxy sur LB1
3 Le maître entier sudo poweroff sur LB1

Pour chaque panne, repère dans mesure.log le nombre de lignes ECHEC et en déduis l'interruption (≈ nombre × 0,2 s + 1 s de délai maximal).

# Panne Lignes ECHEC Interruption estimée Qui a pris le relais ?
1 web1 arrêté
2 HAProxy arrêté sur LB1
3 LB1 éteint

J'anticipe. Quelle panne produira la plus longue interruption ? Laquelle ne devrait presque rien changer pour l'utilisateur ? ______________________

Éléments de réponse

Panne 1 : presque aucune interruption visible (au plus une requête partie vers web1 avant la détection par la sonde). Panne 2 : le script verif_haproxy doit échouer deux fois de suite (toutes les 2 s) avant que LB1 ne perde la VIP : quelques secondes. Panne 3 : le secours attend l'absence d'annonces VRRP : de l'ordre de trois secondes (3 × advert_int plus un petit délai). Les valeurs exactes sont à mesurer : elles dépendent des paramètres interval, fall, advert_int.

Je comprends. Que peut-on régler pour réduire l'interruption ? Quel est le risque à le faire trop agressivement ? ______________________

Éléments de réponse

Réduire advert_int, interval et fall raccourcit la détection. Le risque : des bascules inutiles (faux positifs) sur un réseau chargé, voire une partition. C'est un compromis entre réactivité et stabilité, comme pour les seuils de supervision.

Remets le laboratoire en état : LB1 redémarré, systemctl start haproxy si besoin. Note quelle machine a repris la VIP quand LB1 revient (priorité plus élevée : elle la reprend, sauf configuration de non-préemption).

Partie E – Bilan : ce que la HA ne couvre pas (≈ 20 min)

  1. Cite trois SPOF qui subsistent dans ton laboratoire.
  2. Le disque de web1 est détruit. La haute disponibilité suffit-elle ? Que faut-il d'autre ?
  3. Un utilisateur supprime par erreur un fichier du site. La HA t'aide-t-elle ?
  4. Avec 2 serveurs de 400 requêtes/s et 600 requêtes/s de charge, quelle part n'est plus servie après la panne d'un serveur ? Que règles-tu dans HAProxy pour que le serveur restant tienne ?
Éléments de réponse
  1. L'hôte physique des machines virtuelles, le commutateur (réseau interne), le stockage ou la base de données s'ils sont uniques, mais aussi l'alimentation, et les comptes d'administration partagés.
  2. La HA maintient le service sur web2, mais web1 doit être reconstruit : déploiement automatisé (S07), configuration (S08), sauvegarde (S05).
  3. Non : la suppression est appliquée partout ; seule la sauvegarde permet de récupérer le fichier.
  4. Capacité restante 400 ; (600 − 400) / 600 = 33,3 % non servie. maxconn par serveur pour éviter l'écroulement, page 503 explicite, ou un troisième serveur (N + 1).

Pour aller plus loin

  • Ajoute un cookie de persistance dans le backend et teste.
  • Supervise (S11) l'état des deux serveurs et de la VIP.
  • Calcule la disponibilité réelle de ton laboratoire à partir de tes mesures.

Retour en entreprise (si ta situation le permet)

  • Observer : quels services de l'entreprise sont redondants ? Lesquels ne le sont pas ? Quelle disponibilité est promise aux clients ?
  • Documenter : un schéma de l'architecture avec les SPOF repérés.

Rendu

Compte rendu PDF, nommé RENDU-B2A2-S12-NOM.pdf, contenant : les calculs de la partie A, les captures de la page de statistiques (normal et web1 arrêté), ip -br a avant et après bascule, un extrait de mesure.log pour chaque panne avec le tableau complété, les réponses de la partie E.

Bilan de la séance

Niveau : Non maîtrisé, Maîtrise partielle, Bonne maîtrise ou Excellente maîtrise, ou Non évalué.

Compétence du référentiel Ce que j'ai fait dans cette séance Niveau
B2.2 – Installer, tester et déployer une solution d'infrastructure réseau
B2.3 – Exploiter, dépanner et superviser une solution d'infrastructure réseau
B3.4 – Garantir la disponibilité, l'intégrité et la confidentialité des services informatiques et des données

Note

Les codes sont ceux du référentiel.

Je sais faire, sans aide :

  • Distinguer tolérance de panne, haute disponibilité et répartition de charge ;
  • Calculer une disponibilité en série et en parallèle ;
  • Configurer HAProxy avec sondes de santé ;
  • Configurer une adresse flottante avec keepalived ;
  • Provoquer une panne, mesurer l'interruption, conclure ;
  • Citer ce que la HA ne couvre pas.

Ce que je dois reprendre : ______________________

Ma question à poser à l'enseignant : ______________________