Haute Disponibilité &
Produit Minimum Viable
De la scalabilité horizontale à un produit minimum viable d'une application en haute disponibilité.
420-5A4-MT · Module 3 · Projet Haute-DisponibilitéSommaire du Diaporama
- Partie 1 (Slides 3-6) : Qu'est-ce que la HA ? Pourquoi ? Les 9 de disponibilité & les 5 principes fondateurs.
- Partie 2 (Slides 7-12) : Diagnostic des failles d'architecture & matrice des solutions (Failles vs Solutions).
- Partie 3 (Slides 13-16) : Réplication des données (GlusterFS/NFS & Galera/MGR) & Définition du PMV.
- Partie 4 (Slides 17-22) : Surveillance continue (Prometheus, Grafana, Healthchecks & Métriques).
Qu'est-ce que la Haute Disponibilité ?
La haute disponibilité (HA - High Availability) est une approche qui vise à garantir qu'un système informatique reste accessible et fonctionnel le plus longtemps possible, même en cas de panne.
- L'objectif est de minimiser les interruptions de service pour offrir une expérience continue aux utilisateurs.
Pourquoi la Haute Disponibilité est-elle vitale ?
Imaginez une boutique en ligne qui tombe en panne pendant le Black Friday, ou un système bancaire inaccessible pendant plusieurs heures. Les conséquences sont dévastatrices : perte de revenus directe, clients mécontents, atteinte irrémédiable à la réputation.
- La panne n'est pas une éventualité : en production, tout ce qui peut tomber tombera.
- L'objectif de l'architecte est de concevoir un système qui survit à la défaillance d'un composant sans que l'usager s'en aperçoive.
Les Concepts de Base · Les "9" de Disponibilité
Le taux de disponibilité se mesure en pourcentage. Voici le temps d'arrêt maximal autorisé par an :
| Niveau de disponibilité | Pourcentage | Indisponibilité max. / an |
|---|---|---|
| Un "9" | 90 % | 36,5 jours / an |
| Deux "9" | 99 % | 3,65 jours / an |
| Trois "9" | 99,9 % | 8,76 heures / an |
| Quatre "9" | 99,99 % | 52,6 minutes / an |
| Cinq "9" (Standard Or) | 99,999 % | 5,26 minutes / an |
Comment atteindre la Haute Disponibilité ?
Éliminer les points de défaillance uniques en dupliquant les composants critiques.
Répartir le trafic entre plusieurs serveurs pour absorber les pics et les pannes.
Copier en temps réel les données sur plusieurs disques et sous-systèmes de stockage.
Basculer instantanément sans intervention humaine vers un composant de secours.
Détecter les défaillances en continu et déclencher les alertes et mécanismes de récupération.
De la Scalabilité Horizontale au PMV HA
Dans les laboratoires précédents, nous avons vu la séparation BDD/Web et le cache Varnish. Il faut maintenant assembler ces briques dans un Produit Minimum Viable (PMV) en Haute Disponibilité complète.
Mettre en Évidence la HA Progressivement
- À partir de votre expérimentation des laboratoires applicatifs virtualisés, nous validons étape par étape :
- 1. La Redondance (Passerelles & Web doublés).
- 2. L'Équilibrage de Charge (HAProxy & Varnish).
- 3. La Sauvegarde & Réplication des données (GlusterFS & Cluster MySQL).
- 4. Le Basculement Automatique (Failover) (Keepalived IP Virtuelle).
- 5. La Surveillance Continue (Netdata / Prometheus).
Identifions les Points de Failles
Analyse de la topologie initiale et de l'adressage IP :
192.168.56.10 (HTTP) et 192.168.56.20 (MYSQL) sont uniques ! Si l'une tombe, l'application entière s'arrête. SPOF
Aucun mécanisme automatique ne permet de promouvoir un serveur de secours MySQL. SPOF
Les images téléversées sur HTTP et les tables MySQL vivent sur un seul disque local non répliqué. PERTE
Identifions les Solutions aux Points de Failles
Évaluation des corrections apportées à la topologie :
| Composant & IP | Redondance | Failover Auto | Équilibrage | Réplication Données |
|---|---|---|---|---|
| Passerelle (HAProxy + IPV) 192.168.56.49 / .40 / .41 |
☑ OUI | ☑ OUI | ☑ OUI | N/A (Sans état) |
| Cache (Varnish 1 & 2) 192.168.56.30 / .31 |
☑ OUI | ☑ OUI | ☑ OUI | N/A (RAM Cache) |
| Serveurs Web (HTTP) 192.168.56.10 |
✘ UNIQUE | ✘ NON | ✘ NON | ✘ DISQUE LOCAL |
| Base de Données (MySQL) 192.168.56.20 |
✘ UNIQUE | ✘ NON | ✘ NON | ✘ NON RÉPLIQUÉ |
Diagnostic : La passerelle et le cache sont sécurisés, mais la couche Web et la couche BDD restent les deux maillons faibles à répliquer !
Identifions les Points de Failles
420-5A4-MT · Projet Haute DisponibilitéIdentifions les Solutions aux Points de Failles
420-5A4-MT · Projet Haute DisponibilitéQuoi faire pour assurer la Sauvegarde & Réplication ?
Il faut d'abord classifier les données applicatives en deux familles distinctes :
Les images, documents et médias téléversés sur HTTP via WordPress (dossier wp-content/uploads).
Les bases de données relationnelles MySQL/MariaDB contenant les articles, comptes utilisateurs et transactions.
Solution pour les Fichiers HTTP : Stockage Partagé
Le serveur HTTP va être dupliqué (HTTP-1 et HTTP-2) derrière une IP Virtuelle. Les serveurs HTTP deviennent sans état (stateless).
- Les serveurs HTTP-1 et HTTP-2 ne conservent aucune donnée locale propre.
- Solution recommandée : Ajouter un système de serveur de fichiers partagé en Haute Disponibilité (disque virtuel global partagé).
- Technologies préconisées : GlusterFS (répliqué synchrone) ou NFS avec stockage redondé.
Solution pour MySQL : SGBD Haute Disponibilité
Le serveur MySQL doit devenir un cluster distribué en haute disponibilité :
MariaDB / Percona XtraDB. Cluster multi-maître synchrone ultra-robuste sans perte de transactions.
MySQL MGR / InnoDB Cluster. Réplication native avec consensus et tolérance aux pannes.
Failover automatique de topologie Master-Slave et routage intelligent des requêtes SQL.
Produit Minimum Viable (PMV) d'une App HA
Un Produit Minimum Viable (PMV), c'est ce qui est strictement nécessaire pour accomplir une tâche en respectant une cible préétablie. Dans notre cas, la cible préétablie est une application en haute disponibilité qui élimine les points de faille majeurs.
- Limites du PMV : Une seconde panne matérielle simultanée dans un sous-système à simple redondance causera une panne.
- Une surcharge massive sur un composant non balancé entraînera une défaillance.
- Le PMV est une première expression solide de la HA, mais le durcissement continu reste nécessaire.
Surveillance Continue en Haute Disponibilité
La surveillance repose sur 5 piliers complémentaires :
- 1. Architecture de surveillance dédiée et distribuée.
- 2. Métriques critiques à surveiller en temps réel.
- 3. Alertes intelligentes (anti-bruit).
- 4. Healthchecks actifs et tests synthétiques.
- 5. Outils populaires de l'industrie.
Architecture de Surveillance Dédiée
Déployer les instances de monitoring sur une zone isolée pour éviter de perdre la visibilité si l'application tombe.
Agents (node_exporter, telegraf) sur chaque serveur rapportant processeur, mémoire, disque et santé des services.
Métriques Critiques à Surveiller
- Santé des nœuds : Utilisation CPU, RAM, saturation disque I/O, bande passante réseau.
- État du cluster : Quorum des serveurs, synchronisation, latence inter-nœuds.
- Mécanismes HA : État du load balancer, heartbeats Keepalived, nombre de failovers.
- Bases de données : Lag de réplication MySQL, transactions/sec, connexions actives.
Alertes Intelligentes & Escalade
Évitez le bruit : trop d'alertes tuent l'alerte !
- Privilégiez les alertes sur les symptômes (service inaccessible) plutôt que sur les métriques brutes isolées.
- Chîne d'escalade : Warning (notification Slack) ➔ Critical (courriel) ➔ PagerDuty / Appel si la gravité dure.
Healthchecks & Tests Synthétiques
Ne pas se fier au simple ping : exécuter une requête HTTP complète qui valide l'accès à la BDD.
Simuler un parcours usager en continu (connexion, panier) pour détecter les pannes avant les vrais clients.
Outils Populaires de l'Industrie
Stack recommandés :
- Métriques & Visualisation : Prometheus + Grafana.
- Logs Centralisés : Loki / ELK Stack (Elasticsearch, Logstash, Kibana).
- Healthchecks Externes : Uptime Kuma / Pingdom.