Réalisation type E6 SISR : un intranet hautement disponible

Ce chapitre déroule une réalisation professionnelle complète de l'épreuve E6 SISR, du besoin à la recette : rendre l'intranet de Ravelle Conseil hautement disponible, avec un cluster Proxmox VE de trois nœuds, deux répartiteurs HAProxy et keepalived, deux serveurs web, une base de données répliquée et une supervision qui alerte sur chaque perte de redondance. Il montre aussi comment la présenter : ce qu'elle couvre de l'environnement exigé et du bloc 2, la fiche descriptive, les évolutions que la commission peut demander pendant l'heure de réalisation, et les questions de la recette.

Ce que l'E6 SISR attend sur la haute disponibilité

L'épreuve E6 SISR, « Administration des systèmes et des réseaux » (coefficient 4), évalue le bloc 2 à partir de tes deux réalisations professionnelles : la commission en choisit une, te demande de la faire évoluer pendant une heure, puis t'interroge (le règlement de l'E6 SISR). L'environnement dans lequel tu construis tes réalisations doit offrir, d'après l'annexe II.E du référentiel (l'environnement exigé), plusieurs éléments qui relèvent directement de ce cours :

Une seule réalisation bien construite couvre ainsi quatre ou cinq lignes de l'annexe. Côté compétences, elle donne des preuves solides pour « choisir les éléments nécessaires pour assurer la qualité et la disponibilité d'un service », « installer et configurer des éléments nécessaires pour assurer la continuité des services » et « la qualité de service », et pour l'indicateur sur le mode dégradé vérifié périodiquement (les compétences du bloc 2).

Le besoin

Le contexte est celui du chapitre 1 : trois pannes de l'intranet en un trimestre, découvertes par les utilisateurs, et une directrice qui demande « un intranet qui ne tombe plus ». L'entretien avec la responsable administrative précise le besoin :

• le contrat de service : 99,5 % de disponibilité par mois sur les heures ouvrées (8 h à 19 h, du lundi au vendredi), mesurés par une sonde chaque minute ; rétablissement en moins de 4 heures ; perte de données d'une journée au plus ;
• les contraintes : l'adresse de l'intranet ne change pas pour les utilisateurs (https://intranet.ravelle.lan) ; les mises à jour se font sans coupure pendant les heures ouvrées ; un budget de 4 000 € pour le matériel, logiciels libres privilégiés ; mise en service en trois semaines ;
• l'existant : un hyperviseur unique, un répartiteur unique, deux serveurs web, une base de données unique, un onduleur absent.

L'analyse : les SPOF et le dossier de choix

L'analyse du chemin d'une requête (chapitre 2) relève six SPOF : le commutateur de cœur, le pare-feu, l'hyperviseur, le répartiteur, la base de données et l'alimentation électrique. Le dossier de choix compare trois solutions :

La solution C est retenue : pour le même matériel que B, elle supprime aussi les SPOF logiciels (une mise à jour ratée du répartiteur ne coupe plus rien) et permet la maintenance pendant les heures ouvrées. Le pare-feu et le commutateur de cœur restent uniques : ils font l'objet d'une seconde phase, chiffrée, avec un cluster pfSense et une pile de deux commutateurs. La réalisation l'écrit dans ses limites.

L'estimation de disponibilité, avec les hypothèses du chapitre 2 (pare-feu 99,8 %, commutateur 99,9 %, chaque hôte 99,5 %, chaque répartiteur et chaque serveur web 99,7 %, pannes indépendantes) : environ 99,70 % avec le pare-feu et le commutateur encore uniques, contre 98,90 % avant le projet. Le pare-feu (17,5 heures par an) et le commutateur (8,8 heures) représentent désormais presque toute l'indisponibilité estimée : c'est l'argument chiffré de la seconde phase.

L'architecture cible

Le cluster n'a pas de stockage partagé : chaque nœud a ses disques en ZFS miroir (RAID 1), et les VM sont répliquées toutes les 15 minutes vers un autre nœud. C'est un choix assumé : la redondance rapide est assurée au niveau du service (deux répartiteurs, deux serveurs web, un réplica de la base), et la réplication ZFS sert de filet pour redémarrer une VM sur un autre nœud. La base fait exception : elle n'est pas redémarrée par la HA, sa continuité repose sur le réplica. On évite ainsi une baie de stockage, qui aurait été un nouveau SPOF et aurait dépassé le budget.

La mise en œuvre, étape par étape

1. Le cluster Proxmox VE (chapitre 8) : installation des trois nœuds en ZFS miroir, création du cluster, réseau d'administration et réseau du cluster séparés, onduleur avec arrêt automatique par NUT.
2. Les VM et leurs règles : LB1, LB2, WEB1, WEB2 et ZABBIX sont déclarées comme ressources HA, avec réplication ZFS et des règles d'anti-affinité entre LB1 et LB2 et entre WEB1 et WEB2. SRV-DB et SRV-DB2 restent volontairement hors de la HA de Proxmox : sinon, après la panne de pve1, le cluster redémarrerait SRV-DB sur sa dernière copie ZFS, vieille de 15 minutes au plus, avec l'adresse .34, et l'application écrirait sur des données plus anciennes que celles du réplica. Leur bascule passe par la promotion du réplica (chapitre 9). On les place à la main sur pve1 et pve2.
3. Les serveurs web : Nginx et PHP-FPM sur deux Debian 13 identiques, installées par le même script ; page /sante profonde ; lecture de l'adresse client dans X-Forwarded-For (chapitre 6).
4. La base de données (chapitre 9) : copie initiale, réplication avec GTID, read_only sur le réplica, compte de réplication limité, adresse 10.10.20.34 sur la principale, procédure de promotion écrite.
5. Les répartiteurs : HAProxy identique sur LB1 et LB2, avec le certificat de l'autorité interne ; keepalived avec le contrôle de HAProxy (chapitre 5).
6. Les flux autorisés, sur le pare-feu et sur les pare-feu locaux :

7. La supervision (chapitre 11) : sonde de bout en bout sur la VIP, contrôle de chaque membre, bascules keepalived, état de la réplication, quorum du cluster, onduleur, expiration des certificats.
8. La documentation : schémas avant et après, plan d'adressage, configurations commentées, procédure d'ajout d'un serveur web, procédure de promotion du réplica, fiches de mode dégradé, contrat de service.
9. La recette : le plan de test du chapitre 11, joué en maquette puis en production un samedi matin, et rejoué après la correction de l'alerte manquante.

La fiche descriptive

Les rubriques suivent le modèle de la circulaire, présenté dans le chapitre sur le dossier E6.

Verso (extrait).

Contexte. L'intranet documentaire de Ravelle Conseil tournait sur un hyperviseur unique, derrière un répartiteur unique. Trois pannes en un trimestre, découvertes par les utilisateurs.

Démarche. J'ai d'abord écrit avec la responsable administrative le contrat de service (/01), puis analysé les points uniques de défaillance du chemin d'une requête et estimé la disponibilité de l'existant (98,9 %) et de trois solutions (/02). La solution retenue double chaque rôle du chemin web et le répartit sur deux hyperviseurs d'un cluster de trois nœuds.

Tests. Huit tests de bascule mesurés (/06), dont l'arrêt brutal du répartiteur actif (coupure mesurée de 3,8 s) et l'arrêt d'un hyperviseur (aucune coupure du service). Le test des alertes a révélé que les bascules keepalived n'étaient pas signalées : j'ai ajouté un script de notification et un déclencheur Zabbix, puis rejoué le test.

Limites. Le pare-feu et le commutateur de cœur restent uniques ; ils représentent la quasi-totalité de l'indisponibilité estimée restante. La bascule de la base de données est manuelle (moins de 30 minutes, procédure testée). Les deux évolutions sont chiffrées dans les perspectives.

Les évolutions que la commission peut demander

Pendant l'heure de réalisation, la commission te demande de faire évoluer ta réalisation. Sur celle-ci, les demandes probables, avec l'essentiel de la méthode (les tâches types de la phase 2) :

Les questions de la recette et de l'entretien

Exercice 1 sur 4 Huit questions de commission Réussi À revoir

Prépare une réponse d'une minute à chacune, sur cette réalisation.

1. « Pourquoi deux répartiteurs ? HAProxy ne tombe jamais. »
2. « Que se passe-t-il exactement quand LB1 tombe ? Combien de temps ? »
3. « Et si les deux répartiteurs se croient maîtres ? »
4. « Votre base de données est-elle encore un point unique de défaillance ? »
5. « Pourquoi trois hyperviseurs, et pas deux ? »
6. « Comment savez-vous que vous respectez le contrat de service ? »
7. « Un administrateur supprime une table par erreur. Votre haute disponibilité le protège-t-il ? »
8. « Que reste-t-il à faire ? »

Voir la réponseMasquer la réponse de l'exercice 1

1. « Le logiciel est fiable, mais la VM, son système, son hôte ou une mise à jour peuvent tomber. Avec un seul répartiteur, l'intranet tombait avec lui alors que les deux serveurs web fonctionnaient : c'est d'ailleurs ce qui est arrivé lors d'une des trois pannes. Le second répartiteur ne coûte qu'une petite VM. »
2. « LB2 ne reçoit plus les annonces VRRP de LB1. Au bout d'environ 3,5 secondes, il se déclare maître, prend l'adresse 10.10.20.30 et l'annonce par un ARP gratuit. Les postes ne changent rien. J'ai mesuré 3,8 secondes de coupure en arrêtant brutalement LB1. Si c'est seulement HAProxy qui s'arrête sur LB1, le contrôle de keepalived baisse sa priorité de 150 à 120, sous les 130 de LB2, qui prend la main de la même façon. »
3. « C'est un double maître : il arrive si les annonces VRRP ne passent plus, par exemple à cause d'un pare-feu local. Je l'ai prévenu en autorisant le protocole 112 entre les deux nœuds, et je le détecte : Zabbix vérifie qu'un seul des deux porte l'adresse virtuelle. »
4. « Oui, partiellement, et je l'ai écrit dans les limites. Le réplica a les données à quelques secondes près, mais la bascule est manuelle : moins de 30 minutes en suivant la procédure testée, ce que permet le contrat (rétablissement en 4 heures). Pour aller plus loin, il faudrait un cluster Galera de trois nœuds, que le contrat actuel ne justifie pas. »
5. « Pour le quorum. Avec deux nœuds, la panne de l'un laisse l'autre avec un vote sur deux : il n'a pas la majorité, et le gestionnaire HA refuse de redémarrer les VM, de peur qu'elles tournent deux fois. Avec trois nœuds, les deux survivants ont deux votes sur trois. Le troisième nœud sert aussi de réserve de capacité. »
6. « Une sonde Zabbix interroge l'intranet chaque minute depuis le VLAN utilisateurs, et calcule la disponibilité mensuelle sur les heures ouvrées. Le mois dernier : 100 % sur les heures ouvrées, avec une bascule de répartiteur pendant une mise à jour, invisible pour les utilisateurs. Et je teste les bascules chaque trimestre. »
7. « Non. La réplication recopie la suppression en moins d'une seconde. C'est le rôle de la sauvegarde quotidienne, avec un test de restauration mensuel, et du journal binaire pour revenir juste avant l'erreur. Haute disponibilité et sauvegarde répondent à deux risques différents. »
8. « Doubler le pare-feu avec CARP et pfsync, et le commutateur de cœur avec une pile : ce sont les deux derniers points uniques de défaillance, et ils représentent presque toute l'indisponibilité estimée restante. Automatiser le déploiement des serveurs web avec Ansible. Et, si le contrat se durcit, automatiser la bascule de la base. »

Tu avais trouvé ?

Oui, j'avais bonPas encore

Les pièges qui coûtent des points

• Tout sur un seul hyperviseur, sans le dire : la commission le voit en une question. Si ta maquette tourne sur un seul hôte, dis-le et explique ce qui changerait en production.
• Une redondance jamais démontrée : prépare la démonstration de bascule, avec la mesure, et entraîne-toi à la faire en deux minutes.
• Confondre haute disponibilité et sauvegarde, ou migration à chaud et haute disponibilité.
• Des configurations différentes sur les deux répartiteurs : la commission te demandera une modification, et tu dois l'appliquer aux deux.
• Pas de contrat de service : sans engagement chiffré, tu ne peux pas justifier ton architecture ni prouver qu'elle suffit.
• Cacher les limites : une limite assumée et chiffrée vaut bien mieux qu'une faiblesse découverte par la commission.

Exercices

Exercice 2 sur 4 Chiffrer la seconde phase Réussi À revoir

Avec les hypothèses du chapitre (pare-feu 99,8 %, commutateur 99,9 %, hôte 99,5 %, répartiteur et serveur web 99,7 %, chaque élément du chemin doublé sauf le pare-feu et le commutateur), la disponibilité estimée est d'environ 99,70 %.

1. Retrouve ce résultat.
2. Calcule la disponibilité estimée si l'on double seulement le pare-feu, puis si l'on double aussi le commutateur. Convertis chaque résultat en arrêt par an.
3. Pourquoi présenter ces chiffres comme des estimations ?

Voir la réponseMasquer la réponse de l'exercice 2

1. Blocs doublés : hôtes 1 − 0,005² = 0,999975 ; répartiteurs et serveurs web 1 − 0,003² = 0,999991 chacun. Chaîne : 0,998 × 0,999 × 0,999975 × 0,999991 × 0,999991 ≈ 0,99696, soit 99,70 %, environ 26,6 heures d'arrêt par an.
2. Pare-feu doublé (1 − 0,002² = 0,999996) : 0,999996 × 0,999 × 0,999975 × 0,999991 × 0,999991 ≈ 99,895 %, environ 9,2 heures par an. Commutateur doublé aussi (1 − 0,001² = 0,999999) : environ 99,995 %, soit 25 minutes par an.
3. Les disponibilités de chaque élément sont des hypothèses, et le calcul suppose des pannes indépendantes et des bascules parfaites. Une panne de mode commun (électricité, mise à jour, erreur humaine) n'y figure pas. Ces chiffres servent à comparer des architectures et à prioriser ; la disponibilité réelle se mesure avec la supervision.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Analyser une demande de la commission Réussi À revoir

La commission te remet cette demande : « La direction souhaite que l'extranet, aujourd'hui sur un serveur unique en DMZ (172.16.50.10), bénéficie de la même haute disponibilité que l'intranet. » En 10 minutes de préparation :

1. Liste les éléments à créer ou à modifier.
2. Cite les tests que tu présenteras.
3. Identifie un point de vigilance de sécurité.

Voir la réponseMasquer la réponse de l'exercice 3

1. Un second serveur extranet dans la DMZ (172.16.50.11), installé à l'identique ; deux répartiteurs en DMZ (ou une seconde instance VRRP sur une paire de répartiteurs dédiée à la DMZ) avec une VIP, par exemple 172.16.50.20 ; la règle de redirection du pare-feu (NAT) vers la VIP et non plus vers 172.16.50.10 ; les règles de filtrage (VRRP entre les répartiteurs, contrôles de santé vers les deux serveurs) ; une règle d'anti-affinité dans le cluster ; la supervision des nouveaux éléments ; la mise à jour du schéma, du plan d'adressage et de la documentation.
2. Accès depuis Internet (ou depuis un poste simulant l'extérieur) en HTTPS ; répartition entre les deux serveurs ; arrêt brutal du répartiteur actif avec mesure de la coupure ; arrêt d'un serveur extranet ; alerte reçue pour chaque panne.
3. Ne pas mélanger la DMZ et le VLAN serveurs : réutiliser LB1 et LB2, qui sont dans le VLAN 20, pour publier l'extranet ferait entrer des flux venant d'Internet dans le réseau interne. Les répartiteurs de l'extranet doivent être dans la DMZ, et les fichiers déposés par les clients doivent être stockés et analysés sans ouvrir de flux de la DMZ vers l'interne au-delà du strict nécessaire (DMZ et segmentation).

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Organiser l'heure de réalisation Réussi À revoir

La commission demande d'ajouter un serveur WEB3 et de prouver que le service survit à la panne de deux serveurs web sur trois. Propose un découpage de l'heure en étapes chronométrées.

Voir la réponseMasquer la réponse de l'exercice 4

Un découpage possible :

• 5 min : relire la demande, vérifier l'état de départ (page de statistiques, ip -br address sur les deux répartiteurs, boucle de mesure prête).
• 15 min : créer WEB3 par clonage de WEB2 dans Proxmox VE (ou par le script d'installation), lui donner l'adresse 10.10.20.33 et un nom, vérifier Nginx et /sante directement.
• 10 min : ajouter server web3 10.10.20.33:80 check cookie w3 sur LB1, haproxy -c, rechargement ; même chose sur LB2 ; autoriser le contrôle de santé dans le pare-feu local de WEB3.
• 5 min : ajouter WEB3 à la règle d'anti-affinité des serveurs web (sur trois nœuds, chacun sur un nœud différent) et le déclarer comme ressource HA.
• 10 min : tests : répartition sur trois serveurs (boucle curl), arrêt de WEB1 puis de WEB2 avec la boucle de mesure, constat que l'intranet répond sur WEB3 seul, redémarrage et réintégration.
• 10 min : supervision de WEB3 (hôte et /sante), mise à jour du plan d'adressage, de la procédure et du rapport de tests.
• 5 min : marge, et préparation de ce que tu vas montrer à la recette.

Tu avais trouvé ?

Oui, j'avais bonPas encore