B2-25 Haute disponibilité et répartition de charge

1. Mesurer la disponibilité

La disponibilité d'un service est la part du temps pendant laquelle il fonctionne réellement pour ses utilisateurs. Elle s'exprime en pourcentage sur une période, le plus souvent l'année, et figure dans les contrats de service (SLA).

Chaque « 9 » supplémentaire divise l'arrêt autorisé par dix… et multiplie le coût de l'infrastructure. On choisit donc le niveau d'après le coût d'une heure d'arrêt pour l'entreprise.

• MTBF (Mean Time Between Failures, temps moyen entre deux pannes)Plus il est grand, plus l'équipement est fiable. Donné par le constructeur pour un disque, une alimentation, un commutateur.
• MTTR (Mean Time To Repair, temps moyen de remise en service)Temps de détection, de diagnostic, de réparation et de redémarrage. La haute disponibilité cherche surtout à le rendre presque nul grâce à une bascule automatique.
• Disponibilité = MTBF ÷ (MTBF + MTTR)Un serveur qui tombe en moyenne toutes les 2 000 h et qu'on répare en 4 h : 2 000 ÷ 2 004 ≈ 99,8 %.

2. Chasser les points uniques de défaillance

Un point unique de défaillance (SPOF) est un élément dont la seule panne suffit à arrêter le service. La démarche consiste à suivre le chemin d'une requête, de l'utilisateur jusqu'aux données, et à se demander à chaque étape : « si ceci tombe, que se passe-t-il ? ».

3. Le RAID : survivre à la panne d'un disque

Le disque est l'un des composants qui tombent le plus souvent en panne. Le RAID (Redundant Array of Independent Disks) regroupe plusieurs disques pour qu'ils fonctionnent comme un seul, plus rapide et/ou capable de survivre à la perte de l'un d'eux. Il est géré par une carte contrôleur (RAID matériel) ou par le système (RAID logiciel : mdadm sous Linux, ZFS dans Proxmox, espaces de stockage sous Windows).

4. La redondance matérielle et électrique

Après les disques, on double tout ce qui peut tomber dans le local technique. La règle est simple : deux de chaque, branchés à deux endroits différents.

4.1 L'onduleur

L'onduleur (UPS) fournit du courant pendant une coupure grâce à ses batteries, et protège des micro-coupures et des surtensions. Il ne sert pas à tenir des heures : il laisse le temps au groupe électrogène de démarrer, ou aux serveurs de s'arrêter proprement.

5. Le cluster Proxmox et la haute disponibilité des VM

Un cluster Proxmox VE regroupe plusieurs hyperviseurs (les nœuds) administrés comme un seul. Il permet de migrer une VM d'un nœud à l'autre sans l'arrêter, et surtout de la redémarrer automatiquement sur un autre nœud si le sien tombe : c'est le gestionnaire de haute disponibilité (HA manager).

• QuorumChaque nœud dispose d'une voix ; le cluster ne prend de décision que si une majorité stricte de voix est présente (2 sur 3, 3 sur 5). Cela évite que deux moitiés isolées démarrent chacune les mêmes VM (split brain).
• Nombre de nœudsTrois nœuds minimum pour la haute disponibilité. Avec deux, la perte d'un seul fait perdre le quorum : il faut alors un arbitre externe, le QDevice, qui apporte une troisième voix.
• Stockage partagé ou répliquéLe disque de la VM doit être accessible depuis le nœud de secours : stockage partagé (Ceph, NFS, iSCSI) ou réplication ZFS planifiée entre nœuds (on perd alors les dernières minutes).
• Isolement (fencing)Un nœud qui perd le quorum s'éteint de lui-même grâce à un chien de garde (watchdog) avant que la VM ne soit redémarrée ailleurs : jamais deux copies de la même VM en marche.

6. Une adresse virtuelle avec keepalived

Le cluster redémarre une VM en quelques minutes. Pour une bascule en quelques secondes, on fait tourner le service sur deux serveurs en même temps et on leur fait partager une adresse IP virtuelle (VIP), portée par l'un ou l'autre. Sous Linux, c'est le rôle de keepalived, qui utilise le protocole VRRP, celui-là même que tu as vu sur les routeurs (B2-09).

vrrp_instance VI_INTRANET {
    state MASTER
    interface ens18
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass Brocel26
    }
    virtual_ipaddress {
        172.16.50.25/24
    }
}

• state / priorityRôle de départ et priorité (1 à 254) : c'est le serveur de plus haute priorité encore vivant qui porte l'adresse virtuelle.
• virtual_router_idNuméro du groupe VRRP (1 à 255) : identique sur les deux serveurs, différent pour chaque autre groupe du même réseau.
• advert_intIntervalle des annonces « je suis là » du MASTER, en secondes. Sans annonce pendant environ trois intervalles, le BACKUP prend l'adresse.
• virtual_ipaddressL'adresse virtuelle, ici 172.16.50.25 : c'est elle que le DNS associe à intranet.broceliande.lan.
• authenticationMot de passe partagé du groupe, identique des deux côtés (8 caractères au plus). Il évite les erreurs, pas les attaques : VRRP doit rester dans un VLAN de confiance.

7. Répartir la charge avec HAProxy

Avec keepalived, un seul serveur travaille, l'autre attend. Un répartiteur de charge (load balancer) fait travailler tous les serveurs : il reçoit les requêtes des clients et les distribue entre plusieurs serveurs identiques, en écartant automatiquement ceux qui ne répondent plus. HAProxy est le répartiteur libre le plus répandu.

frontend fe_intranet
    bind *:80
    default_backend be_web

backend be_web
    balance roundrobin
    option httpchk GET /
    server web1 172.16.50.21:80 check
    server web2 172.16.50.22:80 check

listen stats
    bind *:8404
    stats enable
    stats uri /stats

• frontendCe que voient les clients : l'adresse et le port d'écoute (bind), et vers quel groupe de serveurs envoyer les requêtes.
• backendLe groupe de serveurs réels, l'algorithme (balance) et la liste des serveurs (server nom adresse:port check).
• check / option httpchkContrôle de santé : HAProxy interroge chaque serveur toutes les 2 secondes ; après 3 échecs, le serveur est marqué DOWN et ne reçoit plus rien, jusqu'à ce qu'il réponde de nouveau.
• listen statsPage de statistiques (port 8404) : état UP/DOWN de chaque serveur, nombre de sessions, erreurs. À protéger par un mot de passe en production.

8. La réplication des données

Deux serveurs web identiques, c'est facile : ils affichent les mêmes pages. Mais si l'application écrit des données (une base, des fichiers déposés), il faut que chaque serveur voie les mêmes données. C'est le rôle de la réplication.

Exemples : réplication MariaDB (primaire et réplique, ou grappe Galera synchrone), réplication ZFS entre nœuds Proxmox (asynchrone, toutes les 15 minutes par exemple), DFS-R entre serveurs de fichiers Windows, stockage distribué Ceph (synchrone). Comme le RAID, la réplication recopie aussi les erreurs : elle ne remplace jamais la sauvegarde.

9. Vérifier et dépanner

Une architecture haute disponibilité se teste en provoquant la panne : on éteint un serveur, on coupe un service, on débranche un lien, et l'on vérifie que la bascule se fait dans le délai prévu. Ces tests font partie du cahier de recette.

9.1 Entraîne-toi : les tickets du support

Tu es de permanence au support de Brocéliande Logistique. Six tickets arrivent les uns après les autres : lis le message, observe le relevé, puis choisis la cause.

Expected votes:   2
Total votes:      1
Quorum:           2 Activity blocked
Flags:            (aucun Quorate)

backend be_web
    option httpchk GET /sante.html
    server web1 172.16.50.21:80 check   → DOWN (L7STS/404)
    server web2 172.16.50.22:80 check   → DOWN (L7STS/404)

web1$ ip -br a show ens18
ens18  UP  172.16.50.21/24 172.16.50.25/24
web2$ ip -br a show ens18
ens18  UP  172.16.50.22/24 172.16.50.25/24
web2$ journalctl -u keepalived | tail -1
VRRP_Instance(VI_INTRANET) Entering MASTER STATE

Grappe : RAID 5 · 4 disques de 12 To · même lot de fabrication
Alerte mail du contrôleur : non configurée
Disque de secours (hot spare) : aucun

backend be_web
    balance roundrobin
    server web1 172.16.50.21:80 check
    server web2 172.16.50.22:80 check
# l'application garde les sessions en mémoire, sur chaque serveur

Liaison avec les serveurs : aucune (USB débranché)
Batteries : installées en 2019
Arrêt automatique : non configuré

10. À l'examen et en entreprise

11. L'essentiel

1. Disponibilité = temps de fonctionnement ÷ temps total ; 99,9 % ≈ 8 h 46 min d'arrêt par an.
2. Disponibilité = MTBF ÷ (MTBF + MTTR) : la haute disponibilité réduit surtout le MTTR.
3. En série, les disponibilités se multiplient ; en parallèle, ce sont les indisponibilités.
4. Un SPOF arrête tout à lui seul : on le double et on ajoute une bascule automatique et une alerte.
5. RAID : 1 miroir, 5 parité (1 panne), 6 double parité (2 pannes), 10 miroirs en bandes ; 0 ne protège rien.
6. Le RAID et la réplication ne sont pas des sauvegardes.
7. Onduleur + arrêt propre (NUT) ; doubles alimentations sur deux circuits.
8. Cluster Proxmox : quorum = majorité stricte, 3 nœuds (ou QDevice), HA manager redémarre la VM ailleurs.
9. keepalived (VRRP) : une adresse virtuelle portée par le serveur vivant de plus haute priorité.
10. HAProxy : frontend, backend, balance (roundrobin, leastconn, source), check retire les serveurs en panne.

Les commandes clés

Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.

12. Quiz noté

13. Exercices : à toi de répondre

Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige. Montre tes calculs.

14. Au labo : un intranet qui survit à la panne