Vendredi 21 mars 2025, un après-midi comme un autre chez ScalarX… ou presque.
– Un client avec une infrastructure bi-datacenter PROD / PRA
– Des serveurs solides, double alimentation, double induction réseau, RAID, réplication, backup,
puis tout à coup… plus rien.

1) Un SSD du RAID système de la prod vient de lâcher.
2) L’IP Failover de la production bascule sur le PRA sur un second datacenter
3) Un ticket est ouvert chez OVH pour remplacer le SSD défaillant
4) OVHcloud procède au remplacement
5) Le second SSD rends l’âme
6) Le serveur ne peut plus booter, plus d’OS.

Dans le même temps :
1) Le PRA ne réponds plus
2) Des erreurs remontées par le noyau indiquent un problème hardware
3) Une analyse hardware est effectuée par le support : une barette RAM et le CPU sont HS
4) Un remplacement est effectué
5) Les corruptions liées à l’incident nécessitent de recharger un backup antérieur de la base de données, la réplication n’étant plus disponible.
6) La plateforme était down durant plusieurs heures.

Mais, par un concours extraordinaire de circonstances, ce n’est heureusement pas ce qui s’est passé. Retour sur cette histoire qui s’est achevée ce matin :

John Benett est le CTO depuis plus de 17 ans de l’agence MYAGA (Make Your Application Great Again) qu’il a par ailleurs cofondée. Parmi ses clients, Neotypa est une société B2B spécialisée dans la vente de composants permettant de fabriquer et réparer les drones, les robots et les objets connectés.

John prend soin de ses clients : ils sont tous hébergés sur des plateformes dédiées, cloud et baremetal qui répondent individuellement aux besoins spécifiques de chacun.

Ces plateformes tournent sous StackX sont managées par ScalarX, en 24/7.

Pour ce client, John a pris 2 serveurs chez OVHcloud en mode prod/pra, sur 2 datacenters différents, équipés chacun de processeurs Intel(R) Xeon(R) Gold 6242R, 384 GB de RAM, 2 x SSD dédiés au système en RAID 1 et 2 SSD Nvme de 1.9 TB en RAID1 également dédié au datastore.

Une plage IP dédiée est annoncée dans un vRack, ce qui permet l’utilisation d’une IP failover sans aucune interaction externe telle qu’un call API chez l’hébergeur ou autre.

En cas d’incident, les services peuvent être basculés sur le PRA sans modifications particulières, sans changer d’adresse IP et sans dépendance à un load-balancer.

À cela se rajoute un backup externe sur un 3ᵉ datacenter.

Il y a quelques jours, un incident hardware est remonté par nos sondes sur la production : il s’agit d’un SSD du RAID 1 système qui est HS.

Le client n’est pas coupé, et plusieurs scénarios sont envisagés avec lui.

La procédure suivante est validée par les équipes de MYAGA et le client final :

1) Bascule de la production sur le PRA
2) Remplacement du NVMe défectueux par OVHcloud
3) Retour de la production sur le serveur initial après tests et validation.

L’opération de bascule est programmée durant un week-end.

Sauf que… l’intervention va être reportée, et heureusement !

1) Hier (vendredi), le serveur utilisé pour le PRA ne répond plus.
2) Des messages d’erreurs sont visibles via le KVM sur la console :

kernel: CMCI storm detected: switching to poll mode
kernel: mce: [Hardware Error]: Machine check events logged

3) Un reboot est effectué et le serveur est à nouveau disponible.
4) La réplication SQL est HS
5) La réplication ne peut pas être corrigée et nécessite une reconstruction
6) Alors que la base de données est en cours d’injection, nouveau plantage…
7) Ouverture d’un ticket chez OVHcloud,
8) OVH confirme des soucis avec la RAM remontée via IPMI
9) Par expérience avec ce genre d’erreur, nous demandons un check hardware complet.
10) Le support programme l’intervention.
11) On génère un second autre backup de secours de la production
12) Quelques heures plus tard, OVH remplace une barrette RAM et le CPU
13) La machine est relancée
14) On relance la reconstruction de la réplication, suivie de son rattrapage.
15) Tout se déroule sans incident et tout est à nouveau opérationnel

Le client n’a pas eu d’interruption de services.

Qu’est-ce qui a sauvé la prod ?

1)Ce ne sont pas les specs techniques
2)Ce n’est pas l’expertise de nos équipes
3)Ce n’est pas notre service 24/7 disponible en moins de 12 minutes

Ce qui a sauvé la prod c’est :

1) Un léger contre-temps
2) Une bonne dose de chance

Mon expérience depuis plus de 25 ans dans ce métier : quel que soit le niveau de redondance de vos infrastructures et la qualité de vos process, il existe toujours des situations qui, bien qu’improbables, peuvent se produire. J’en ai vu défiler un paquet. Il faut savoir l’accepter et accepter aussi que parfois, le hasard, la chance ou encore l’intuition ont aussi un rôle à jouer.

La résilience, parfois, c’est aussi de savoir ne pas basculer trop vite.

Note : seuls les noms des protagonistes, client et agence ont été modifiés.

—
Christophe Casalegno
Vous pouvez me suivre sur : Telegram | Facebook | LinkedIn | X | YouTube | Twitch