Chers clients,

Cette nuit, nous avons entrepris une maintenance du serveur Avocado.easyhoster.com, en heures creuses, afin de ne pas perturber le trafic de la journée. Les interventions ont débuté vers 3h45 du matin.

Il s'agissait d'une mise à jour du noyau Linux (Kernel) destinée à améliorer les performances et la stabilité du serveur, car nous soupçonnions la version antérieure (5.14.0-503.35.1.e19_5) d'inclure certains bugs impactant négativement la stabilité et les performances, notamment celles de MySQL.

Une mise à jour de noyau nécessite obligatoirement un redémarrage physique du serveur. Ce type d'intervention prend généralement 25 minutes en moyenne. Cependant, le redémarrage d'un serveur est toujours une opération sensible, car celle-ci peut révéler des problèmes matériels.

Malheureusement, ce redémarrage semble avoir révélé un défaut matériel au niveau du système de redémarrage (Défaut de reboot hardware).

Nous avons demandé à un technicien du datacenter de vérifier pourquoi le serveur ne redémarrait pas et nous avons d'ores et déjà été informés qu'un technicien allait intervenir d'ici une quinzaine de minutes.

Nous vous tiendrons informés via cette annonce dès que nous aurons reçu plus d'informations de leur part concernant l'état physique de la machine.

Nous nous excusons sincèrement pour les désagréments occasionnés. 

Merci pour votre patience et votre compréhension.

Mise à jour à 05:45 (heure de Paris)

L'intervention d'un technicien du centre de données a confirmé nos craintes : le serveur fait face à un problème matériel, spécifiquement au niveau de sa connectique électrique et de son système de redémarrage à distance (IPMI).

Il est important de souligner que lorsqu'un incident est de cette nature, notre champ d'action direct est limité. Nous dépendons des équipes techniques du datacenter pour le diagnostic, les tests et le remplacement des pièces potentiellement défectueuses. Bien que nous suivions l'évolution en temps réel et fassions pression pour une résolution rapide, nous n'avons malheureusement pas un contrôle total sur les délais de leur intervention, qui sont parfois incompressibles. C'est le cas, par exemple, pour les tests de mémoire RAM memtest, des disques NVMe, du CPU, de la carte mère, etc., sans compter les éventuels remplacements de matériel.

Nous tenons néanmoins à vous rassurer sur la sécurité de vos données. Comme toujours, celles-ci sont sécurisées grâce à nos sauvegardes régulières, effectuées sur des infrastructures externes et décentralisées.

Nous sommes pleinement conscients que cet incident survient moins d'un mois après la panne majeure du 26 septembre, également liée à une défaillance au niveau du datacenter. Heureusement, cette fois, l'incident a déjà été pris en charge, et ce, dans un délai bien inférieur au précédent. Nous espérons donc une interruption d'une durée moindre.

Nous comprenons que cette malheureuse coïncidence puisse être une source de frustration et tenons à réitérer notre engagement absolu à vous fournir le service le plus fiable possible dans notre périmètre d'action et à faire toute la lumière sur ces pannes récurrentes avec notre fournisseur. En effet, il ne serait pas étonnant que ces deux incidents soient liés d'un point de vue matériel (cf. "connecteur électrique") et que ce second événement pousse le datacenter à remplacer un composant défectueux qui aurait pu être manqué précédemment.

Nous restons en contact permanent avec le support du datacenter et nous vous fournirons une nouvelle mise à jour dès que nous aurons des informations concrètes sur la résolution.

Nous vous remercions une nouvelle fois pour votre patience et votre compréhension.

Mise à jour à 08:47 (heure de Paris)

Nous venons de recevoir une communication du support du datacenter qui nous apporte des précisions techniques sur la nature de l'intervention, qui est plus complexe que prévu.

Un premier technicien est intervenu vers 6h50. Son diagnostic a confirmé que l'intervention nécessitait un remplacement de matériel, renforçant notre idée que cet incident matériel est lié à celui du 26 septembre.

Cette opération a entraîné deux conséquences importantes :

- Un changement d'adresse MAC : C'est la "carte d'identité" physique de la connexion réseau du serveur. Ce changement est normal après un remplacement de pièce (comme la carte mère), mais il rend le serveur injoignable jusqu'à ce qu'une reconfiguration logicielle soit effectuée.

- Une reconfiguration du système IPMI : Le module de gestion à distance, qui était défaillant, a dû être reconfiguré.

Le serveur est actuellement dans une phase de validation post-intervention de la part du datacenter. Nous attendons qu'ils nous "rendent la main" pour pouvoir procéder à la reconfiguration réseau nécessaire.

Nous sommes conscients que cette attente est longue et nous partageons votre impatience !

Soyez assurés que nous sommes prêts à intervenir à la seconde où l'accès nous sera rétabli et nous espérons un rétablissement rapide.

La prochaine communication interviendra dès que le serveur sera de nouveau accessible de notre côté, ou dès que nous recevrons de nouvelles informations du technicien.

Merci encore pour votre patience et encore navré pour tout désagrément.

Mise à jour 10:46 - 11:22 (heure de Paris) :

Le serveur est enfin à nouveau UP et fonctionne sur la tout dernier noyau Linux (5.14.0-570.51.1.el9_6), comme cela était prévu.

Par souci de transparence, voici les dernières informations à notre disposition, incluant celles reçues de la part du datacenter.

Un peu avant 9h, nous recevons une réponse de notre contact au datacenter expliquant qu’un remplacement de matériel important impliquant notamment une nouvelle carte réseau (donc, remplacement du serveur complet ou au moins de la carte mère) était en cours.

8:47 : 

« Je vous remercie de m'avoir décrit la situation et je vous présente nos excuses pour les désagréments occasionnés. Il y a eu un changement de technicien datacentre pour l'intervention et celle-ci est en cours depuis 6h50. Il y a notamment eu un changement d'adresse MAC effectué par le technicien suivi d'une reconfiguration de l'IPMI. Pour la suite, vous allez recevoir le compte rendu d'intervention via le ticket CS12327978. Cela ne devrait plus tarder. »

Une heure plus tard, nous recevons une confirmation de la fin de l’intervention au datacenter, confirmant notre pronostique du remplacement complet du serveur par une nouvelle machine récemment testée. Néanmoins, l’opération réalisée (notamment, changement de carte réseau et donc de MAC Address) va nécessiter à ce stade des opérations de sysadmin avancées. 

9:54 : 

« L’intervention sur ns3099684.ip-91-134-18.eu est terminée.

Cette opération a été achevée le 2025-10-14 09:53:20 CEST (UTC +02:00)

Voici les détails de cette opération :

Remplacement par un spare

Date 2025-10-14 04:32:16 CEST (UTC +02:00), Remplacement par un spare:

Détails de l'opération:

Nous avons remplacé votre serveur par un serveur de rechange qui a été récemment testé.

Tout le matériel a été remplacé à l'exception des disques que nous avons récupérés de votre serveur d'origine.

Les firmwares ont été mis à jour ainsi que les adresses MAC dans notre système.

Cependant après remplacement de la carte mère, le serveur ne répond pas aux requêtes de ping une fois sur disque. Nous avons donc redémarré le serveur sur le mode rescue pour client.

Résultat :

Le serveur est démarré sur le mode rescue et est sur l'écran du rescue. Ping OK, SSH démarré, les codes d’accès ont été envoyés.

Recommandations :

Nous vous recommandons de mettre à jour l'adresse MAC de votre serveur dans les fichiers de configuration du système d'exploitation.

Nouvelle adresse MAC de votre serveur :

ETH0 : D0:50:99:FF:5E:94

ETH1 : D0:50:99:FF:5E:95

Si vous souhaitez plus de détails sur le rapport d'intervention, veuillez contacter notre support technique. »

Quelques minutes plus tard, nous retrouvons l’accès à la machine (IPMI), mais toujours sans accès au système d’exploitation Linux, ni accès réseau. 

Nous redémarrons la machine en mode rescue pour mettre à jour la MAC Address dans « /mnt/etc/sysconfig/network-scripts/ifcfg-enp66s0f0 », puis reboot sur le système stocké sur disque NVMe.

Malheureusement, suite au reboot, les services ne redémarrent pas : SSH KO, réseau KO, ce qui nous laisse penser que, d’expérience, un FSCK est nécessaire sur le disque pour réparer la séquence de boot qui doit probablement démarrer brièvement en read-only, empêchant les services (dont SSH et réseau) de redémarrer proprement. 

Nous rebootons donc encore une fois en mode rescue et déclenchons l’opération sensible du FSCK qui se complète en quelques minutes, démontrant le peu de corruptions sur le disque. 

Nouveau reboot sur le système et notre disque NVMe : Réseau UP, SSH UP, cPanel et tous les services UP à 10:46.

Pour la résolution de l’incident, l’intervention d’EasyHoster (côté software, administration système) aura duré 52 minutes. Le reste du downtime se situe du côté du datacenter, mais rappelons que cet incident a nécessité le remplacement d’une machine au complet.

En parallèle, nous signalons la résolution et le redémarrage du serveur à notre contact au datacenter qui nous confirme plus ou moins directement que le premier incident du 26 septembre était lié à celui-ci :

11:00 : 

« Merci de confirmer le rétablissement du serveur =)
Cela devrait éviter une reproduction du problème de connecteur électrique que vous aviez déjà eu avec le serveur. 
Je vous remercie de je vous souhaite également une bonne journée. »

Moralité, le serveur Avocado était manifestement arrivé en fin de vie et a nécessité un remplacement complet.

Nous espérons que, à la fois nos travaux de maintenance système (Update Kernel, FSCK) et les travaux de maintenance du datacenter (remplacement complet de la machine) permettront au serveur Avocado et à ses utilisateurs de retrouver les meilleures performances et l’excellent taux de disponibilité dont ils ont bénéficié depuis la création de ce serveur en mi-2024.