- Ubicloud a adopté les nouveaux serveurs AX162 de Hetzner, qui semblaient meilleurs que les AX161 en performances comme en prix, mais a rencontré en production un problème de fiabilité avec des pannes 16 fois plus fréquentes
- L’investigation a commencé avec des journaux système contenant des octets NULL, puis a consisté à écarter successivement la charge, la température, les informations sur les composants et la consommation électrique ;
sensors,dmidecodeetpowerstatont été les outils clés - Dans les premières données, l’AX161 comptait 11 pannes sur 3 784 jours de service, soit un AFR de 1,06, tandis que l’AX162 enregistrait 34 pannes sur 737 jours, avec un AFR de 16,84
- 80 % des serveurs ayant subi une panne en ont connu une deuxième dans les 24 heures, et Hetzner a signalé un défaut de lot de cartes mères sans confirmer l’existence ou non d’une limitation de puissance
- L’AX162 -v3, migré vers la carte mère la plus récente, a vu son AFR descendre à 0,39 après plusieurs mois de monitoring ; le nouveau matériel doit être validé progressivement, en commençant par des workloads non critiques
Crashs répétés après l’introduction de l’AX162
- Ubicloud développe un logiciel qui transforme des fournisseurs bare metal en plateforme cloud, et utilisait Hetzner comme fournisseur de serveurs bon marché et fiable
- La gamme de serveurs AX162 de Hetzner offrait de meilleures performances et un prix plus bas que le modèle précédent AX161, ce qui a conduit à son adoption rapide
- Trois semaines après l’achat du premier serveur AX162, un serveur a crashé, et les journaux système contenaient des octets NULL
- Cela a été interprété comme le signe d’une panne soudaine empêchant l’écriture de se terminer correctement, comme lors d’une perte d’alimentation
- Les contrôles matériels de Hetzner n’ont d’abord révélé aucune anomalie, mais un autre crash est survenu une semaine plus tard, puis les incidents se sont répétés en quelques jours
Comment les pannes se manifestaient
- Tous les crashs se produisaient uniquement sur des serveurs AX162
- Les pannes prenaient deux formes
- Le serveur revenait en ligne après un redémarrage manuel
- Le serveur ne répondait ni aux demandes de redémarrage ni au code de diagnostic des ingénieurs Hetzner, et devait être remplacé
- Les serveurs fonctionnaient généralement normalement pendant longtemps, puis la probabilité de crashs supplémentaires augmentait après le premier crash
- Un schéma a été observé : plusieurs répétitions du premier type de crash finissaient par mener au second type, nécessitant le remplacement du serveur
Écarter d’abord la charge et la température
- L’AX162 proposait 96 vCPU, et Ubicloud avait des workloads utilisant tous les vCPU simultanément
- L’hypothèse selon laquelle une forte charge pouvait entraîner une hausse de température ou des problèmes inattendus a été examinée, mais les pannes survenaient aussi au moment du crash avec une charge faible, voire sans charge
- Pour étudier la corrélation entre température et pannes, la température des composants système a été collectée avec la commande
sensors - Un simple cron job a recueilli les données de température, et les valeurs observées lors d’un nouveau crash n’étaient pas nettement supérieures à la moyenne
Enquête sur les composants et la consommation électrique
lshwetdmidecodeont été utilisés pour vérifier les modèles et numéros de série des composants matériels- La comparaison des composants entre les serveurs AX162 ayant crashé et ceux qui n’avaient pas crashé n’a révélé aucune différence significative
- Comme des composants plus anciens pouvaient tomber en panne plus souvent, l’évolution des numéros de série a aussi été vérifiée, mais des serveurs avec les numéros de série les plus récents ont également crashé
- Dans l’extension de datacenters, la contrainte vient souvent de la puissance électrique plutôt que de l’espace, et un opérateur peut limiter la consommation par machine
- Ubicloud ne savait pas si Hetzner limitait la consommation électrique, mais estimait que le symptôme — un fonctionnement stable prolongé suivi de crashs répétés — correspondait à une usure matérielle
- Après avoir écarté les autres hypothèses une à une, la limitation de puissance est restée une hypothèse forte
powerstat -Ra servi à mesurer la consommation électrique maximale sur une longue période et à la comparer aux valeurs annoncées- AX161 : puissance maximale annoncée 147 W, puissance maximale mesurée 168 W
- AX162 : puissance maximale annoncée 408 W, puissance maximale mesurée 266 W
- Cet écart a conduit à soupçonner Hetzner de limiter effectivement la consommation électrique
Taux de panne vu à travers l’AFR
- Pour comparer la fiabilité matérielle, l’Annualized Failure Rate (AFR) a été utilisé
- L’AFR a ses limites, mais c’était un indicateur suffisamment simple comme point de départ pour comparer les taux de panne
- Les premières mesures montraient que le taux de panne de l’AX162 était bien plus élevé que celui de l’AX161
- AX161 : 11 pannes, 3 784 jours de service au total, AFR 1,06
- AX162 : 34 pannes, 737 jours de service au total, AFR 16,84
- Ces données étayaient l’observation selon laquelle l’AX162 avait 16 fois plus de risques de connaître une panne que les autres modèles
- Un serveur ayant déjà crashé avait une probabilité très élevée de crasher à nouveau, et 80 % des serveurs ayant subi un premier crash en ont connu un deuxième dans les 24 heures
Remplacement de la carte mère et limites de la v2
- Ubicloud a soumis à Hetzner un ticket de support détaillé incluant le soupçon de limitation de puissance et les données d’AFR
- Hetzner n’a ni confirmé ni infirmé la possibilité d’une limitation de puissance, mais a indiqué avoir identifié un défaut de lot de cartes mères
- Hetzner avait reçu un nouveau lot de cartes mères et a recommandé de remplacer celles des serveurs affectés
- Un remplacement de serveurs à grande échelle pouvait affecter les workloads clients, mais comme la plupart des tâches importantes avaient déjà été déplacées hors des AX162 en raison des crashs répétés, le remplacement était possible
- Même après le remplacement par de nouvelles cartes mères, les workloads critiques n’ont pas été remis sur AX162, et le monitoring s’est poursuivi sur une longue période
- Au début, aucun crash ne s’est produit, mais deux semaines plus tard, un serveur équipé de la nouvelle carte mère a lui aussi crashé
- AX162 -v2 : 11 pannes, 758 jours de service au total, AFR 5,30
- La v2 crashait moins souvent que l’AX162 initial, mais le taux de panne restait élevé
Stabilisation avec la v3
- Après avoir recontacté Hetzner, Ubicloud a appris qu’il existait une version plus récente de carte mère offrant une fiabilité améliorée
- Les serveurs ont été migrés vers la dernière version et leur fiabilité a été surveillée
- Après plusieurs mois d’observation des nouveaux serveurs, le problème de crash de l’AX162 a été considéré comme résolu
- La comparaison finale des AFR est la suivante
- AX161 : 11 pannes, 3 784 jours de service au total, AFR 1,06
- AX162 : 34 pannes, 737 jours de service au total, AFR 16,84
- AX162 -v2 : 11 pannes, 758 jours de service au total, AFR 5,30
- AX162 -v3 : 4 pannes, 3 738 jours de service au total, AFR 0,39
- L’AFR de l’AX162 -v3 était même inférieur à celui de l’AX161
Amélioration des processus d’exploitation
- Adopter très tôt une nouvelle gamme de serveurs peut entraîner des problèmes inattendus
- L’AX162 avait des spécifications attractives, et l’arrêt de l’AX161 par Hetzner semblait indiquer que la nouvelle gamme était prête pour la production
- Ubicloud estime que beaucoup de problèmes auraient pu être évités en attendant six mois
- Les changements prévus sont les suivants
- Effectuer une validation plus approfondie des nouveaux modèles de serveurs
- Introduire le nouveau matériel progressivement, en commençant par des workloads non critiques
- Ajouter davantage de fournisseurs bare metal afin de répartir les risques
- Ubicloud prend déjà en charge deux fournisseurs bare metal supplémentaires, Leaseweb et Latitude, et l’ajout d’un quatrième fournisseur est également en cours
1 commentaires
Avis sur Hacker News
D’autres modèles AX (AX42, AX52, AX102) souffrent aussi de graves problèmes de fiabilité, avec des pannes au bout de quelques mois
Comme ils reposent sur des cartes mères défectueuses, Hetzner devra remplacer, au cours des 12 prochains mois, la plupart, voire la totalité, des cartes mères des serveurs fabriqués avant une certaine date [0]
[0] https://docs.hetzner.com/robot/dedicated-server/general-info...
Le dernier remplacement semble tenir, donc sur ce petit échantillon, on dirait un taux de panne de 50 %. Les vrais chiffres ne sont sans doute connus que de Hetzner et ASRock
Dans une ancienne boîte, les DevOps détectaient souvent des pannes de ventilateur CPU sur du matériel Hetzner
C’était distinct des pannes HDD/SSD auxquelles on s’attend généralement, et il fallait les surveiller soi-même. C’est l’une des raisons pour lesquelles les serveurs non managés coûtent moins cher que les instances cloud
Le premier jour où j’ai rejoint Dropbox, j’ai dit à l’équipe qu’on pouvait trouver, dans la fleet, des machines tournant à 400 MHz, et c’était bien le cas. Un contrôleur d’alimentation redondante défectueux déclenchait PROCHOT. Quand on a beaucoup de machines, ce genre de choses arrive
Posséder, maintenir et réparer correctement l’équipement physique reste la responsabilité de l’hébergeur, surveillance comprise. Autrefois, il fallait installer des scripts ou des paquets pour le connecter au monitoring, mais maintenant qu’IPMI et autres sont des standards, cela peut se faire sans l’aide du client
Sauf si l’offre se limite à fournir de l’espace en baie, de l’alimentation et du réseau, ce qui est pris en charge relève du contrat. Si Hetzner n’arrive même pas à détecter les pannes de ventilateur CPU sur son propre matériel et déploie de nouveaux systèmes sans les tester suffisamment, cela ressemble à un signe qu’ils continuent de déraper
Quand on évalue un achat, si l’on ne se met pas ne serait-ce qu’un instant à la place de l’autre partie et qu’on cherche seulement à réduire les coûts et augmenter le chiffre d’affaires, cela ne tient pas longtemps, sauf dans des métiers de vente douteux
Le matériel serveur est vraiment bon marché, et pour un programmeur un minimum compétent, la plupart des programmes peuvent tourner sur un seul serveur ou une seule machine virtuelle. Il faut payer 50 dollars par mois au lieu de 25 pour laisser un peu de marge. Cela ne garantit toujours pas que l’entreprise ne fera pas faillite ou qu’elle vous considérera comme un client précieux ; au final, on dépend d’un modèle où l’ensemble devient rentable grâce aux gros clients
Si votre activité est aux États-Unis, il faut utiliser un hébergeur américain
Le conseil selon lequel « attendre 6 mois aurait permis d’éviter beaucoup de problèmes, et les early adopters découvrent généralement les problèmes en premier, qui sont corrigés ensuite » s’applique à tous les systèmes qui nécessitent de la stabilité
S’il n’y a pas de problème de sécurité, il vaut mieux attendre quelques mois ou rester une ou deux versions en arrière
Par exemple, dans la forêt, un vieux sanglier envoie d’abord les petits dans une clairière peu fiable en émettant un signal de sécurité. Côté tech, c’est un peu comme écrire un billet de blog qui survend une technologie pas encore prête pour la production
Cela dit, c’est déjà une consolation que nos difficultés aient aidé à faire apparaître plus vite la cause racine
Je ne l’ai pas écrit dans l’article, mais nous avons aussi envisagé, à l’avenir, de recevoir les serveurs puis de les laisser tourner à vide pendant environ un mois, sans workload client réel. Cela coûte plus cher, mais peut aider à détecter des problèmes latents sans impact utilisateur. Dans notre cas, les crashs ont commencé 3 semaines après le déploiement du premier serveur AX162 ; il faudrait donc une période tampon d’au moins un mois, peut-être plus longue
Cela dit, c’est la première et la dernière fois qu’Ubicloud utilise un nouveau modèle ou une nouvelle tranche d’achat sans burn-in. J’y travaille aussi, et j’en suis cofondateur
Dell a aussi parfois ce genre de problème. Quand nous avons reçu le premier lot d’anciens serveurs, les serveurs perdaient pendant un moment les périphériques du côté I/O arrière, et il fallait remplacer la section I/O arrière de la carte mère
Par exemple, le contrôleur Ethernet, l’iDRAC, et parfois même le BIOS disparaissaient. Une fois ce problème réglé, ils ont tourné correctement pendant près de 10 ans
Récemment, nous les avons mis à la retraite parce que tout était usé, de la carte RAID aux régulateurs d’alimentation. Redémarrer un serveur qui fonctionnait parfaitement à cause d’un changement de configuration, puis perdre définitivement la carte RAID parce que l’électromigration avait érodé des pistes internes du processeur RAID, ça remet les idées en place
Hetzner n’aurait ni confirmé ni démenti la possibilité d’une limitation de puissance, et je me demande quelles seraient les conséquences de cette limitation de puissance.
L’article dit que le matériel pourrait se dégrader plus vite, mais je ne vois pas pourquoi.
Vu l’absence de réponse de Hetzner et les mesures d’UbiCloud, on dirait bien qu’ils limitent réellement la puissance. Sinon, ils auraient dit que non.
Pour vérifier, il suffit d’exécuter
cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. La valeur devrait êtreperformance.Sinon, on peut la définir avec
echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. C’est utile pour les workloads gourmands en CPU. Le réglage revient en arrière au redémarrage, donc on peut le maintenir via cron/systemd, etc.Bien sûr, si vous payez directement l’électricité ou si c’est votre propre matériel, à vous de juger pour le gouverneur de scaling. Mais sur un serveur bare metal loué,
performanceest le bon choix.L’idée qu’un opérateur de datacenter limite la consommation par serveur pour augmenter le nombre de machines dans une enveloppe électrique donnée, et que cela puisse accélérer la dégradation de la carte mère, va à l’encontre de l’intuition.
D’après mes recherches rapides aussi, une limitation de puissance semblait plutôt prolonger la durée de vie effective de plusieurs composants.
Les résultats de recherche affirmant l’inverse parlaient seulement du fait que des températures de fonctionnement élevées, en cas de thermal throttling, peuvent dégrader plus vite des composants comme les condensateurs. Or l’article dit avoir consulté plusieurs capteurs de température, et ce cas était explicitement exclu.
La réponse ci-dessous a partagé un exemple, et en cherchant j’ai trouvé quelques sources supplémentaires [1], [2].
Cela dit, je ne suis pas électronicien, donc ma compréhension n’est peut-être pas parfaitement exacte. La dégradation venait peut-être non pas de la limitation de puissance elle-même, mais des variations de puissance, ou d’un autre facteur.
[1] https://electronics.stackexchange.com/questions/65837/can-el...
[2] https://superuser.com/questions/1202062/what-happens-when-ha...
La tension est fournie par le réseau électrique, et le courant est surveillé par rack. Dans un datacenter, la réaction habituelle quand on dépasse la limite de courant est qu’un fusible saute ou qu’on vous demande de payer davantage.
La seule façon de réduire la puissance consommée par un serveur est de throttler le CPU. En général, on throttle le CPU via le système d’exploitation, donc il faut sa coopération.
Je suppose que ce serait peut-être possible via un contrôleur baseband lights-out sans intervention de l’OS, mais si c’était le cas, je pense qu’on le verrait probablement dans
/sys.Malgré tout, on impose une limite par rack pour éviter que quelques serveurs très énergivores ne mettent à terre une zone plus large du datacenter.
Je ne sais pas exactement comment la limitation est appliquée, mais un simple disjoncteur comme à la maison pourrait être une solution facile. Dans ce cas, en cas de déclenchement, l’alimentation du rack tombe, ce qui affecte tout le rack et plusieurs clients, donc ce n’est pas idéal.
Une autre option est un limiteur de courant/puissance[0], mais comme P = U * I, cela peut créer davantage de problèmes. La tension (U) chute, tout le système se retrouve en sous-tension, et des glitches étranges apparaissent. C’est aussi une méthode courante pour contourner divers dispositifs de sécurité dans les puces. Raspberry Pi a également organisé un challenge[1] pour trouver ce type de bug et tester la résistance de la puce à des attaques, y compris par manipulation de tension.
[0] - https://en.m.wikipedia.org/wiki/Current_limiting
[1] - https://www.raspberrypi.com/news/security-through-transparen...
La solution habituelle consiste à surveiller aussi la température de ces autres composants et à l’intégrer dans l’algorithme de vitesse des ventilateurs. Je ne sais pas si c’est effectivement ce qui s’est produit ici.
Impossible à savoir, mais cela pourrait aussi être un problème d’alimentation, de signal ou de VRM.
Le fait que le CPU ne soit pas chaud ne signifie pas qu’un autre élément de la carte n’est pas hors spécifications et en train d’entrer dans une panne critique.
Les problèmes de carte mère autour de l’alimentation et du signal sont pénibles à diagnostiquer. De l’extérieur, ils se manifestent par toutes sortes de symptômes qui ressemblent à des problèmes d’autres composants, et d’expérience les échecs d’initialisation de la RAM et les redémarrages aléatoires sont très fréquents. Au final, on finit par tout remplacer avant de remplacer réellement la carte mère.
J’ai eu quelque chose de similaire sur l’AX102 que j’utilise actuellement, et les crashs semblaient liés à un problème de carte réseau.
Heureusement, le support Hetzner a bien géré le matériel de remplacement. C’était assez pénible, mais une bonne occasion d’apprendre à résoudre des problèmes matériels, et personnellement ça en valait la peine.
Hetzner l’a examiné plusieurs fois, mais n’a rien trouvé, ou s’est contenté de remplacer la pâte thermique du CPU et le connecteur du PSU. Je suis passé à un AX162 et, jusqu’ici, tout va bien.
Quelqu’un ayant de l’expérience en datacenter peut-il imaginer quel arrangement commercial Hetzner a pu trouver ici avec le fournisseur de cartes mères ?
Faut-il supposer qu’ils ont obtenu le remplacement gratuit de toutes les cartes mères, avec une compensation en plus ?
Les compensations ne sont possibles que si elles ont été négociées à l’avance, et dans ce cas il faut payer un supplément. Plutôt que d’essayer de faire payer au fournisseur le coût de l’indisponibilité, il vaut probablement mieux souscrire quelque chose comme une assurance pertes d’exploitation. Même si la faute incombe au fournisseur.
Hetzner n’est pas un client ordinaire. Dans le cadre d’une optimisation extrême des coûts, ils sont susceptibles d’acheter les composants les moins chers, et ont peut-être négocié un prix encore plus bas sans garantie. Dans ce cas, ils auraient dû acheter eux-mêmes les cartes mères de remplacement.
C’était à l’époque où la Coupe du monde de football se tenait en Allemagne.
C’est la première fois que j’entends dire qu’un opérateur de datacenter limite la consommation électrique par serveur à cause de contraintes d’alimentation, et que cela peut accélérer la dégradation des cartes mères ; j’ai trouvé ça assez surprenant.