# Panne réseau chez un fournisseur cloud : ce que la redondance nous a évité

> Une coupure réseau a touché une zone de disponibilité entière chez un grand fournisseur cloud. Récit d'une nuit où l'architecture multi-zone en place a transformé une panne majeure en non-événement.

- Auteur : Clément Hadrot
- Publié le : 2024-07-15
- Mis à jour le : 2024-07-15
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/panne-reseau-fournisseur-cloud-redondance-a-evite/

## L’essentiel

- La panne a duré près de deux heures sur une seule zone de disponibilité
- Le trafic a basculé automatiquement sans intervention manuelle
- Aucun client n'a signalé d'indisponibilité pendant l'incident

2 h 14 du matin, une alerte de supervision se déclenche : latence anormale sur les requêtes sortantes vers la base de données répliquée dans la deuxième zone de disponibilité. Rien de dramatique en apparence, le trafic principal continue de répondre normalement. Ce n'est qu'au petit matin, en consultant la page de statut publique du fournisseur cloud, que l'ampleur réelle de l'incident se précise : une coupure réseau a effectivement touché une zone de disponibilité entière pendant près de deux heures, affectant de nombreux clients de ce fournisseur cette nuit-là.

Sur le parc de serveurs concerné, aucun ticket client n'a été ouvert pendant ces deux heures. Ce récit ne cherche pas à dérouler une méthodologie générale de haute disponibilité, déjà couverte par ailleurs, mais à raconter précisément ce que l'architecture multi-zone déployée quelques mois plus tôt a permis d'éviter cette nuit-là.

## L'architecture en place avant l'incident

Les serveurs applicatifs WordPress de ce parc sont répartis sur deux zones de disponibilité distinctes du même fournisseur cloud, chacune dans un centre de données physiquement séparé au sein de la même région. Un répartiteur de charge global distribue le trafic entre les deux zones, avec des contrôles de santé réguliers qui retirent automatiquement une zone du pool si elle ne répond plus dans les délais attendus.

```
# Extrait de la configuration de contrôle de santé côté répartiteur
health_check:
  interval: 5s
  timeout: 3s
  unhealthy_threshold: 2
  path: /healthz
  zones:
    - eu-west-1a
    - eu-west-1b
```

La base de données MariaDB suit le même principe, avec une réplication asynchrone entre la zone principale et la zone secondaire, ce qui garantit qu'une bascule d'écriture reste possible même si la zone principale est totalement injoignable, au prix d'une perte de données limitée aux quelques dernières transactions non encore répliquées au moment de la coupure.

## Ce qui s'est passé côté fournisseur

Selon la page de statut officielle du fournisseur, publiée le lendemain, l'incident provenait d'une défaillance d'un équipement réseau critique dans un des centres de données de la zone eu-west-1a, qui a isolé cette zone du reste du réseau pendant environ deux heures. Les serveurs applicatifs et la base de données répliquée dans cette zone sont devenus injoignables pendant toute la durée de la coupure.

> L'essentiel à retenir : La panne a duré près de deux heures sur une seule zone de disponibilité ; Le trafic a basculé automatiquement sans intervention manuelle ; Aucun client n'a signalé d'indisponibilité pendant l'incident

## Ce que le répartiteur a fait automatiquement

```
[02:14:32] health_check FAIL zone=eu-west-1a (2/2 unhealthy_threshold)
[02:14:37] zone eu-west-1a removed from active pool
[02:14:37] 100% traffic routed to zone eu-west-1b
[04:09:51] health_check PASS zone=eu-west-1a
[04:10:20] zone eu-west-1a re-added to active pool (25% traffic ramp-up)
```

Ce journal simplifié résume l'essentiel : cinq secondes après le deuxième contrôle de santé en échec consécutif, le répartiteur a retiré la zone défaillante du pool actif et redirigé l'intégralité du trafic vers la zone saine, sans qu'aucune intervention humaine n'ait été nécessaire. La base de données a suivi le même mouvement côté écriture, le nœud secondaire répliqué prenant le relais grâce au mécanisme de failover déjà en place.

## Ce que cette nuit a confirmé

| Élément testé en conditions réelles | Résultat observé |
| --- | --- |
| Détection automatique de la panne | 5 secondes après le seuil configuré |
| Bascule du trafic applicatif | Immédiate, sans intervention |
| Retour progressif après rétablissement | Montée en charge progressive sur 25 % puis 100 % |

Le retour progressif au rétablissement de la zone (25 % de trafic avant un retour complet) mérite d'être souligné : rebasculer instantanément 100 % du trafic dès la première réponse positive du contrôle de santé aurait pris le risque de renvoyer du trafic vers une zone tout juste rétablie et potentiellement encore instable. Cette montée en charge progressive, décidée lors de la conception initiale de l'architecture, a évité tout effet de rebond.

> Une architecture multi-zone ne se juge jamais sur le papier ni sur un test planifié en journée : elle se juge la nuit où personne ne l'a déclenchée volontairement, et où pourtant elle a fait exactement ce qui était prévu.

## Ce que cet incident n'a pas testé

Cette panne, bien que réelle et significative pour le fournisseur, restait limitée à une seule zone au sein d'une seule région. Elle n'a donc rien confirmé sur la résilience face à une panne régionale complète, un scénario différent qui demanderait une réplication inter-régions, non déployée sur ce parc à ce jour faute de justification suffisante au regard du coût et de la latence supplémentaire que cela introduirait.

## En résumé

Cette nuit de panne réseau chez le fournisseur cloud n'a produit aucun incident visible côté clients, pas parce que le fournisseur n'a pas eu de problème, mais parce que l'architecture multi-zone déployée en amont a absorbé la coupure automatiquement, sans intervention humaine. C'est précisément la nuit où personne ne s'attendait à ce que l'architecture soit testée qu'elle a démontré sa valeur.