Alimentations bon marché : comment économiser 20 $ devient un feu d’artifice

Pourquoi les alimentations bon marché échouent de façons qui font mal

Une alimentation est un traducteur entre le monde bordélique (le courant mural, la sortie de votre UPS, votre groupe électrogène, la climatisation du voisin)
et le monde exigeant (les VRM du CPU, les rails RAM, les contrôleurs SSD). « Elle transforme l’AC en DC » revient à décrire un hôpital comme « un bâtiment avec des lits ».

Les alimentations bon marché ne sont pas juste « moins efficaces ». Elles manquent souvent de fonctions de protection, sont fabriquées avec des condensateurs de qualité inférieure, des radiateurs sous-dimensionnés,
des étiquettes optimistes et des boucles de contrôle qui deviennent instables lors de transitoires réels. L’unité peut faire fonctionner un poste pendant une après-midi calme.
Puis vous lancez une compilation, un ZFS scrub, un job GPU ou une tempête de VM et elle se transforme en équivalent électrique d’un bambin au volant d’un chariot élévateur.

Le plus dur, c’est que la mauvaise alimentation ne tue pas toujours immédiatement. Elle peut provoquer :

• Corruption silencieuse : des écritures sur le stockage qui « réussissent » mais sont incorrectes.
• Heisenbugs : panics noyau et segfaults aléatoires qui disparaissent quand vous changez quelque chose d’apparemment sans rapport.
• Vieillissement des composants : vous raccourcissez la durée de vie des disques, des VRM de la carte mère et des NIC à cause du ripple et de la chaleur.
• Pannes « seulement en charge » : stable au repos, instable sous charge—exactement quand ça compte.

Les 20 $ que vous « avez économisés » ne se comparent pas à une meilleure alimentation. Ils se comparent à votre temps, à votre budget d’indisponibilité, à la crédibilité de vos SLA, et aux données que
vous ne pouvez pas recréer. Si vous gérez de la production, la plus économique des alimentations est celle dont vous n’avez jamais à parler.

Une petite blague pour digérer : Une alimentation bon marché, c’est comme une affiche de motivation—on dirait qu’elle soutient, mais elle s’effondre sous la vraie pression.

Ce que font les bonnes alimentations que les bon marché ne font souvent pas

Les alimentations de qualité tendent à délivrer un comportement ennuyeux et répétable :

• Régulation de tension précise sur toutes les plages de charge, pas seulement à un point « agréable pour les tests ».
• Faible ripple et bruit, pour que les VRM en aval n’aient pas à filtrer constamment des ordures.
• Réponse transitoire rapide quand la charge du CPU/GPU passe de 20 % à 90 % en millisecondes.
• Circuits de protection réels : OCP, OVP, UVP, OTP, SCP, et de préférence un comportement d’arrêt bien réglé « sans drame ».
• Temps de maintien qui survit à de brèves baisses d’entrée sans redémarrages par brownout.
• Indices conservateurs : un 750W qui peut réellement fournir 750W à température réelle.

Vous ne pouvez pas « RAIDer » une alimentation qui fait chuter des rails ou qui envoie du ripple au moment précis où le contrôleur SSD commit une mise à jour de la table de mapping.
La redondance aide. Elle ne suspend pas les lois de la physique.

Faits et histoire qui comptent plus que le marketing

Voici des faits concrets et des points de contexte qui expliquent pourquoi le marché des alimentations est plein de pièges. Ce ne sont pas des anecdotes ; ce sont les raisons pour lesquelles vous continuez
à voir les mêmes pannes se répéter dans les entreprises et les homelabs.

1. 80 PLUS a commencé comme un programme d’efficacité, pas comme un label de qualité.
   La certification mesure principalement l’efficacité à quelques points de charge ; elle ne garantit pas un faible ripple, de bonnes protections ou un comportement d’arrêt sûr.
2. L’étiquette « puissance de crête » est exploitée depuis des décennies.
   Certaines unités annoncent un chiffre qu’elles peuvent délivrer brièvement, pas en continu, et parfois seulement à des températures internes irréalistes.
3. Les standards ATX ont évolué parce que des rails instables causaient des instabilités réelles.
   Les systèmes modernes s’appuient fortement sur le rail 12V, avec des VRM CPU/GPU qui l’abaisse ; les designs plus anciens se souciaient davantage de la distribution 3.3V/5V.
4. Le temps de maintien est une caractéristique de fiabilité cachée.
   C’est la capacité de l’alimentation à garder le DC stable pendant des millisecondes après une chute d’entrée AC. Un temps de maintien court transforme des baisses d’entrée bénignes en redémarrages et resets de disques.
5. Les condensateurs électrolytiques vieillissent plus vite avec la chaleur et le courant de ripple.
   Des condensateurs moins chers et des designs plus chauds perdent de la capacité, augmentant le ripple au fil du temps, ce qui accélère la défaillance—une boucle de rétroaction désagréable.
6. Les designs à régulation de groupe peuvent peiner avec les schémas de charge modernes.
   Si votre charge est principalement en 12V (très courant aujourd’hui), une alimentation group-regulated peut avoir une mauvaise régulation sur les rails secondaires et une pire réponse transitoire.
7. Les « protections » peuvent figurer sur une fiche technique mais être mal calibrées.
   Une protection contre les surcourants réglée trop haut est essentiellement décorative ; une UVP réglée trop bas signifie que votre système souffre avant que la protection ne déclenche.
8. Les alimentations serveurs ont popularisé la redondance hot-swap pour une raison.
   Les centres de données ont appris à la dure que l’alimentation est une cause majeure d’incidents impactant le service, et les alimentations hot-swap permettent de réparer sans temps d’arrêt.

Une citation pour rester lucide. Voici une idée paraphrasée de W. Edwards Deming : La qualité se conçoit dans le processus ; on ne peut pas l’inspecter après coup.
C’est les alimentations en une phrase. Vous ne pouvez pas « tester » un mauvais design pour le rendre bon.

Ce qui casse réellement : modes de défaillance en français clair

1) Ripple et bruit : le poison lent

Le ripple est du bruit AC superposé à la sortie DC. Les VRM et les régulateurs en aval le filtrent, mais ils ne sont pas des broyeurs infinis.
Un ripple excessif augmente la chaleur dans les VRM, peut déclencher des comportements marginaux dans la RAM et le PCIe, et fait travailler plus dur l’électronique de stockage.
La signature de panne est rageante : vous obtenez des erreurs « aléatoires » sous charge, surtout les jours chauds.

Pensez-y comme si vous donniez à un marathonien un régime à base de boissons énergétiques et de gravier. Il courra encore—pendant un certain temps.

2) Réponse transitoire : quand la charge change plus vite que la capacité de réaction de l’alimentation

Les CPU et GPU modernes varient leur consommation très rapidement. Une bonne alimentation gère l’à-coup sans que la sortie ne descende sous la tolérance ou ne surcompense.
La boucle de contrôle d’une unité bon marché peut être en retard ou osciller. Le résultat : de brefs événements de sous-tension qui provoquent :

• Redémarrages instantanés (sans arrêt propre)
• Resets de lien PCIe (NIC disparaît, NVMe reset)
• Exceptions machine check du noyau
• Flushs de cache d’écriture disque qui expirent

3) Protections qui ne protègent pas

Une alimentation devrait s’arrêter proprement quand quelque chose sort des limites. Des protections manquantes ou mal réglées transforment un défaut gérable en dommages collatéraux.
Les protections typiques :

• OVP (Over Voltage Protection) : empêche un « oups, 12V est devenu 14V » qui tue les cartes.
• UVP (Under Voltage Protection) : évite la limbo du brownout où le système dysfonctionne pendant des secondes.
• OCP (Over Current Protection) : évite qu’un câble/rail ne devienne un élément chauffant.
• OTP (Over Temperature Protection) : empêche l’alimentation de se « cuisiner » et de tomber ensuite de façon imprévisible.
• SCP (Short Circuit Protection) : empêche le type de défaillance spectaculaire.

4) Courant d’appel et composants bon marché : le problème « ça marche jusqu’à ce que ça casse »

Les alimentations ont des limites d’inrush et une électronique PFC pour gérer le démarrage. Les designs bon marché peuvent mettre les composants à rude épreuve à la mise sous tension, surtout derrière certains UPS.
Avec le temps, vous obtenez des échecs au démarrage : le système ne démarre pas à froid, démarre après plusieurs tentatives, ou ne démarre que si vous basculez l’interrupteur PSU off/on.

5) Câblage et connecteurs : le plastique fondu est un outil de diagnostic que vous ne vouliez pas

Même si l’alimentation elle-même est « bonne », des faisceaux bon marché, des fils de faible section et des sertissages mal faits deviennent des points chauds à forts courants.
Le symptôme : resets GPU intermittents, disques SATA qui se déconnectent, ou gel complet quand un périphérique particulier démarre.
Vous ouvrez le boîtier et trouvez des connecteurs brunis. Ce n’est pas « cosmétique ». C’est de la résistance, de la chaleur et une défaillance imminente.

Deuxième petite blague (et la dernière) : L’odeur d’une alimentation en train de lâcher est la façon dont la nature vous annonce que votre fenêtre de maintenance a commencé.

6) Pourquoi les gens du stockage s’en préoccupent tant

Le stockage est l’endroit où les péchés d’alimentation deviennent péchés de données. Une perte soudaine d’alimentation, c’est une chose ; la corruption pendant une alimentation instable est pire parce que c’est silencieux.
Les systèmes de fichiers et les bases de données ont des stratégies pour la perte de courant. Ils ont moins de stratégies pour « le contrôleur a menti pendant 200 millisecondes ».

Les SSD sont particulièrement sensibles aux événements d’alimentation en cours d’écriture. Les SSD d’entreprise ont souvent des condensateurs de protection contre les pertes de puissance ; les disques grand public bon marché n’en ont souvent pas.
Associez cela à une alimentation bon marché et vous avez construit une machine à corruption qui ne fonctionne que les jours de semaine.

Trois mini-récits d’entreprise (anonymisés, plausibles, techniquement exacts)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a étendu un cluster de calcul utilisé pour des jobs en arrière-plan. Ils ont acheté une série de nœuds 1U « rentables » auprès d’un fournisseur secondaire.
La fiche technique avait l’air correcte : puissance adéquate, badge 80 PLUS, et le vendeur promettait une « alimentation de qualité serveur ».

La mauvaise hypothèse était subtile : ils ont supposé que « server-grade » impliquait un comportement stable avec leur topologie UPS. Les nœuds étaient connectés à un UPS line-interactive
qui basculait parfois de mode lors de petites fluctuations d’entrée. La plupart des serveurs s’en fichaient. Cette série-là non.

Pendant une semaine de mauvais temps avec des petites chutes fréquentes, le cluster a commencé à subir des rafales de redémarrages. Les redémarrages n’étaient pas synchronisés, donc ça ressemblait à un problème logiciel :
peut-être un mauvais déploiement, peut-être une régression du noyau, peut-être un problème d’ordonnanceur. Les ingénieurs ont cherché dans les logs et n’ont rien vu de cohérent.

Puis la file d’attente s’est accumulée. Les timeouts ont augmenté. L’autoscaling a ajouté des nœuds—plus du même comportement d’alimentation instable. Cela a transformé le problème de « quelques redémarrages »
en « la plateforme est instable ». L’incident a pris fin quand quelqu’un a déplacé physiquement deux nœuds suspects vers un autre chemin PDU/UPS et que les redémarrages ont cessé.

Le postmortem a préconisé une correction ennuyeuse : remplacer les alimentations par des modèles connus et qualifier le matériel d’alimentation avec un test de transition de mode UPS.
La leçon n’était pas « UPS mauvais ». C’était « ne supposez pas qu’un autocollant signifie compatibilité avec votre environnement. »

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe fintech a essayé de réduire la consommation et la chaleur en rack. Ils ont remplacé un ensemble d’alimentations plus anciennes, légèrement surdimensionnées, par des unités plus petites « taillées »
qui promettaient une meilleure efficacité à la charge typique. Sur le papier, c’était intelligent : moins de capacité gaspillée, meilleure efficacité, factures en baisse.

Le revers est venu des charges réelles. Leurs systèmes avaient des transitoires de puissance nets : rafales CPU, rafales d’activité NVMe, accélérations GPU occasionnelles.
Les alimentations plus petites fonctionnaient plus près de leurs limites et avaient moins de marge transitoire. Quand la charge a picqué, le 12V est tombé juste assez pour déclencher des resets PCIe.

Le symptôme n’était pas « problème d’alimentation ». C’était une instabilité de stockage : les appareils NVMe tombaient puis réapparaissaient, des rebuilds RAID démarraient, et la base de données journalisait
des erreurs IO. Parce que les boîtiers restaient en ligne, les gens ont suspecté le firmware, les disques, le noyau et les backplanes. L’équipe a remplacé des disques. Puis en a remplacé d’autres.

Le tournant a été la corrélation des événements : les logs de reset NVMe s’alignaient avec de brefs avertissements capteurs BMC sur des valeurs minimales de 12V. Rien de catastrophique, juste suffisant.
Revenir à des alimentations de meilleure qualité avec une meilleure réponse transitoire a éliminé les resets. La facture d’électricité a légèrement augmenté ; le taux d’incidents a fortement diminué.

La leçon : « taillé » n’est pas synonyme de « bien conçu ». La marge n’est pas du gaspillage ; c’est une marge de stabilité.

Mini-récit 3 : La pratique ennuyeuse mais juste qui a sauvé la mise

Un groupe IT d’entreprise gérait un cluster de virtualisation privé. Rien de spécial. Ils étaient disciplinés sur deux choses : la redondance PSU et la maintenance trimestrielle.
Chaque hôte avait deux alimentations hot-swap alimentées par des PDUs séparés, et l’équipe testait régulièrement le basculement en retirant une alimentation sous charge pendant des fenêtres planifiées.

Un après-midi, un disjoncteur PDU a commencé à sauter de façon intermittente. Ce n’était pas un incident d’ensemble de datacenter—juste une alimentation qui devenait instable. La moitié des racks sur cette alimentation
a vu de brèves baisses d’entrée. Dans beaucoup d’environnements, cela devient une panne en cascade quand des nœuds redémarrent et que les charges s’emballent.

Ici, c’est devenu un ticket. Les serveurs sont restés en ligne sur l’alimentation alternative. Le système de monitoring a alerté sur « redondance PSU perdue » et « événements de tension d’entrée »
mais les VM n’ont rien remarqué. Pas de corruption de stockage. Pas de split-brain de cluster. Pas de récupération héroïque à minuit.

Parce qu’ils avaient pratiqué la procédure, la réaction a été calme : isoler l’alimentation PDU défaillante, déplacer la charge, appeler les installations et remplacer un module de disjoncteur.
Le postmortem a été court. Les actions recommandées étaient surtout : « continuer ce que nous faisons. »

La leçon : la fiabilité est souvent une collection d’habitudes ennuyeuses exécutées de façon cohérente.

Mode d’emploi pour un diagnostic rapide (premier/deuxième/troisième)

Quand vous suspectez l’alimentation, il vous faut de la vitesse et un plan. Ne tombez pas dans le piège de passer six heures à prouver une hypothèse que vous pourriez tester en vingt minutes.
Ce mode d’emploi est conçu pour la réalité de l’on-call.

Premier : classer la panne et protéger les données

• Le système redémarre-t-il brutalement ? Si oui, traitez-le comme une instabilité d’alimentation. Désactivez les caches d’écriture quand approprié, suspendez les jobs risqués (scrubs, rebuilds), et snapshottez ce que vous pouvez.
• Y a-t-il odeur/chaleur/bruit ? S’il y a odeur électrique, crépitements ou dommages visibles, coupez l’alimentation en sécurité et arrêtez les « tests ».
• Est-ce isolé ou systémique ? Un hôte versus plusieurs hôtes sur le même PDU/UPS pointe vers des corrections différentes.

Second : corréler les logs avec les capteurs et la charge

• Vérifiez les logs du noyau pour les machine checks, resets NVMe, resets de lien SATA et événements ACPI power.
• Consultez l’historique des capteurs BMC/IPMI pour les événements min/max 12V/5V et l’état des PSU.
• Vérifiez si les pannes coïncident avec des pics CPU/GPU, des scrubs de disque ou des montées de ventilateurs (chaleur).

Troisième : réduire les variables avec un swap décisif ou une isolation

• Si vous avez une alimentation connue bonne, échangez-la. N’« observe z » pas pendant des jours.
• Si double-PSU, retirez une alimentation à la fois sous charge et voyez si le comportement change.
• Déplacez l’hôte vers un autre circuit/PDU temporairement pour exclure l’alimentation en amont.

Le goulot d’étranglement du diagnostic d’alimentation est généralement l’hésitation humaine. Échangez, isolez et mesurez. Vous ne faites pas de philosophie ; vous faites des opérations.

Tâches pratiques : commandes, sorties et décisions

Ce sont des vérifications pratiques que vous pouvez exécuter sur des serveurs Linux. Aucune d’elles ne « prouve » seule que l’alimentation est défaillante.
Ensemble, elles vous permettent de bâtir un dossier solide rapidement et d’éviter de remplacer des pièces au hasard par frustration.

Tâche 1 : Vérifier les redémarrages abrupts (pas d’arrêt propre)

cr0x@server:~$ last -x | head -n 12
reboot   system boot  6.8.0-41-generic Mon Jan 22 09:14   still running
shutdown system down  6.8.0-41-generic Mon Jan 22 08:57 - 09:13  (00:16)
reboot   system boot  6.8.0-41-generic Mon Jan 22 08:12 - 08:57  (00:45)
reboot   system boot  6.8.0-41-generic Mon Jan 22 07:38 - 08:12  (00:34)
shutdown system down  6.8.0-41-generic Mon Jan 22 07:35 - 07:38  (00:02)

Ce que ça signifie : Les entrées « reboot » sans un « shutdown » précédent au bon moment indiquent un reset brutal/chute de courant.

Décision : Traitez comme une instabilité potentielle d’alimentation. Priorisez les vérifications PSU/UPS/PDU plutôt que le débogage applicatif.

Tâche 2 : Chercher les événements noyau liés à l’alimentation et les machine checks

cr0x@server:~$ journalctl -k -b -1 | egrep -i "mce|machine check|watchdog|reset|nvme|ata|pcie|EDAC" | tail -n 30
Jan 22 08:11:58 server kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 5: b200000000070005
Jan 22 08:11:58 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1c140 MISC d012000100000000
Jan 22 08:11:59 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x1, PCI_STATUS=0x10
Jan 22 08:12:00 server kernel: nvme nvme0: reset controller
Jan 22 08:12:03 server kernel: ata3: SATA link down (SStatus 0 SControl 300)

Ce que ça signifie : Les MCE couplés à des resets de liens de stockage sont du domaine classique « alimentation ou carte mère », surtout si ça apparaît sous charge.

Décision : Vérifiez les rails PSU via les capteurs BMC ; envisagez un échange immédiat si cela se corrèle avec des redémarrages.

Tâche 3 : Vérifier les capteurs BMC pour les tensions min/max et l’état des PSU

cr0x@server:~$ ipmitool sdr type Voltage
12V         | 11.71 Volts      | ok
5V          | 4.92 Volts       | ok
3.3V        | 3.28 Volts       | ok
VBAT        | 3.02 Volts       | ok

Ce que ça signifie : « ok » n’est pas toute l’histoire ; il vous faut l’historique min/max si disponible. Néanmoins, une lecture 12V proche du seuil bas est suspecte.

Décision : Si les valeurs dérivent sous charge ou flirtent avec les seuils, planifiez un échange et réduisez la charge de pointe jusqu’à la correction.

Tâche 4 : Obtenir les seuils détaillés des capteurs (si le BMC les expose)

cr0x@server:~$ ipmitool sensor get 12V
Locating sensor record...
Sensor ID              : 12V (0x30)
Entity ID             : 7.1
Sensor Type (Voltage) : Voltage
Sensor Reading        : 11.71 (+/- 0.00) Volts
Lower Non-Recoverable : 10.80
Lower Critical        : 11.00
Lower Non-Critical    : 11.20
Upper Non-Critical    : 12.80
Upper Critical        : 13.00
Upper Non-Recoverable : 13.20

Ce que ça signifie : 11.71V est au-dessus du LNC, mais pas avec une marge luxueuse. Sous une charge transitoire, il peut brièvement descendre sous 11.2V.

Décision : Si la plateforme reset ou que des périphériques tombent, considérez cela comme une preuve corroborante et échangez l’alimentation ou testez avec une autre alimentation.

Tâche 5 : Identifier le modèle d’alimentation et la redondance (lorsque supporté)

cr0x@server:~$ ipmitool fru | egrep -i "Power Supply|PSU|Part Number|Product"
Product Name          : Power Supply 1
Part Number           : PWS-920P-SQ
Product Name          : Power Supply 2
Part Number           : PWS-920P-SQ

Ce que ça signifie : Confirme ce que vous avez réellement, pas ce que l’acheteur croyait avoir.

Décision : Si vous dépannez une flotte, regroupez les incidents par numéro de pièce PSU et par lot.

Tâche 6 : Détecter les événements liés aux PSU dans le SEL (System Event Log)

cr0x@server:~$ ipmitool sel list | tail -n 10
1a3c | 01/22/2026 | 08:11:57 | Power Supply PS1 | Power Supply AC lost | Asserted
1a3d | 01/22/2026 | 08:11:58 | Power Supply PS1 | Failure detected | Asserted
1a3e | 01/22/2026 | 08:12:04 | Power Supply PS1 | Power Supply AC lost | Deasserted
1a3f | 01/22/2026 | 08:12:05 | Power Supply PS1 | Failure detected | Deasserted

Ce que ça signifie : Le BMC a vu la perte d’entrée AC ou un défaut sur le PSU. C’est proche d’une preuve irréfutable.

Décision : Remplacez PS1 et inspectez l’alimentation en amont (câble, prise PDU, disjoncteur).

Tâche 7 : Vérifier les signaux de qualité de l’alimentation en amont depuis un UPS (si connecté via USB/NUT)

cr0x@server:~$ upsc myups@localhost | egrep "input\.voltage|input\.frequency|ups\.status|ups\.load|battery\.charge"
input.voltage: 228.0
input.frequency: 50.0
ups.status: OL
ups.load: 41
battery.charge: 100

Ce que ça signifie : OL veut dire « on line ». Si vous voyez des transitions fréquentes OL/OB, votre alimentation peut mal réagir aux événements de transfert.

Décision : Si les transitions se corrèlent avec des redémarrages, testez avec un autre mode UPS ou une alimentation de meilleure qualité ayant un temps de maintien supérieur.

Tâche 8 : Vérifier les resets de périphériques PCIe (courants lors de transitoires de sous-tension)

cr0x@server:~$ journalctl -k | egrep -i "pcie.*error|AER|link down|link reset|Surprise Down" | tail -n 25
Jan 22 08:11:59 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
Jan 22 08:11:59 server kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
Jan 22 08:12:00 server kernel: pcieport 0000:00:1c.0: device [8086:a110] error status/mask=00000001/00002000

Ce que ça signifie : Les erreurs corrigées de couche physique peuvent être liées à l’intégrité du signal, mais si elles augmentent avec la charge et coïncident avec des resets, l’alimentation est suspecte.

Décision : Combinez avec les données des capteurs de tension ; si les deux pointent dans la même direction, cessez d’accuser le firmware en premier.

Tâche 9 : Vérifier la stabilité des liens SATA/NVMe

cr0x@server:~$ dmesg -T | egrep -i "ata[0-9]|link down|hard resetting link|nvme.*reset" | tail -n 30
[Mon Jan 22 08:12:03 2026] ata3: SATA link down (SStatus 0 SControl 300)
[Mon Jan 22 08:12:03 2026] ata3: hard resetting link
[Mon Jan 22 08:12:05 2026] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Mon Jan 22 08:12:06 2026] nvme nvme0: controller is down; will reset: CSTS=0x1

Ce que ça signifie : Les liens de stockage ne devraient pas vaciller dans un serveur sain. Les baisses de puissance peuvent provoquer des resets de contrôleurs.

Décision : Si vous voyez des resets de lien plus des redémarrages brutaux, priorisez l’inspection du PSU et du câblage immédiatement.

Tâche 10 : Stresser le CPU pour reproduire des problèmes transitoires (test contrôlé)

cr0x@server:~$ sudo apt-get update -qq && sudo apt-get install -y stress-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  stress-ng
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Setting up stress-ng (0.17.12-1ubuntu0.1) ...

cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --timeout 120s --metrics-brief
stress-ng: info:  [21412] dispatching hogs: 32 cpu
stress-ng: metrc: [21412] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [21412] cpu               5231    120.00  3790.11     0.31        43.59
stress-ng: info:  [21412] successful run completed in 120.02s

Ce que ça signifie : Si cela déclenche de manière consistante des redémarrages ou des resets de périphériques, vous regardez la distribution d’alimentation, les thermiques ou les VRM de la carte.

Décision : Si des pannes apparaissent sous ce test, échangez l’alimentation et retestez avant d’accuser le noyau/l’application.

Tâche 11 : Surveiller tensions et températures pendant la charge (lm-sensors)

cr0x@server:~$ sudo apt-get install -y lm-sensors
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  lm-sensors
Setting up lm-sensors (1:3.6.0-7.1ubuntu1) ...

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +71.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +67.0°C  (high = +90.0°C, crit = +100.0°C)

nct6798-isa-0a20
Adapter: ISA adapter
in0:          +1.02 V
in1:          +1.81 V
in2:          +12.00 V
in3:          +5.02 V
in4:          +3.33 V
fan1:        1200 RPM

Ce que ça signifie : Ces lectures peuvent être approximatives, mais vous cherchez une dérive ou des chutes soudaines sous charge.

Décision : Si 12V/5V s’effondrent significativement pendant le stress, arrêtez—votre chemin PSU/VRM est instable.

Tâche 12 : Vérifier les erreurs mémoire (l’alimentation peut se faire passer pour un problème RAM)

cr0x@server:~$ journalctl -k | egrep -i "EDAC|ecc|memory error" | tail -n 20
Jan 22 08:11:58 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
Jan 22 08:11:58 server kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR

Ce que ça signifie : Les erreurs correctibles (CE) peuvent être une vraie dégradation de DIMM, mais des rafales alignées avec des événements d’alimentation sont suspectes.

Décision : Si les erreurs ECC augmentent pendant des événements PSU/transitoires, corrigez d’abord l’alimentation, puis réévaluez les DIMM.

Tâche 13 : Vérifier le système de fichiers et la couche bloc pour les erreurs IO après les événements

cr0x@server:~$ journalctl -p err..alert -b | egrep -i "I/O error|EXT4-fs error|XFS.*CORRUPT|blk_update_request|Buffer I/O" | tail -n 30
Jan 22 08:12:01 server kernel: blk_update_request: I/O error, dev nvme0n1, sector 428032, op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Jan 22 08:12:01 server kernel: Buffer I/O error on dev nvme0n1p2, logical block 53504, lost async page write

Ce que ça signifie : Les erreurs IO après un reset peuvent être une chaîne de reset de périphériques, ou le disque lui-même. L’instabilité d’alimentation augmente les deux probabilités.

Décision : Ne commencez pas à remplacer les disques à l’aveugle. Stabilisez l’alimentation, puis lancez des tests SMART/autodiagnostics.

Tâche 14 : Vérifier SMART et les logs d’erreurs (pour séparer « disque mort » de « alimentation »)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count|Power_Cycle_Count|Power-Off_Retract_Count"
Reallocated_Sector_Ct     0
Current_Pending_Sector    0
UDMA_CRC_Error_Count      19
Power_Cycle_Count         142
Power-Off_Retract_Count   27

Ce que ça signifie : Les UDMA CRC errors indiquent souvent un problème de câble ou de signal. Un compteur « Power-Off Retract » en hausse pointe vers des pertes d’alimentation abruptes.

Décision : Si les erreurs CRC augmentent, inspectez/remplacez les câbles SATA et le faisceau d’alimentation ; si les événements power-off augmentent, corrigez le chemin PSU/UPS.

Tâche 15 : Inspecter et vérifier le throttling de fréquence CPU (interactions puissance/thermique)

cr0x@server:~$ sudo apt-get install -y linux-tools-common linux-tools-generic
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-tools-common linux-tools-6.8.0-41-generic linux-tools-generic
Setting up linux-tools-common (6.8.0-41.41) ...
Setting up linux-tools-generic (6.8.0-41.41) ...

cr0x@server:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,TSC_MHz,PkgTmp --interval 1 --num_iterations 5
Busy%   Bzy_MHz  TSC_MHz  PkgTmp
12.34   2101     2200     74
89.02   3298     2200     89
91.11   2980     2200     94
88.50   2750     2200     96
90.20   2605     2200     97

Ce que ça signifie : Une baisse de Bzy_MHz à fort Busy% et une augmentation de la température Package suggèrent du throttling. Le throttling modifie les schémas de charge et peut exposer une faiblesse PSU.

Décision : Réglez le refroidissement d’abord si vous êtes proche des limites thermiques ; puis évaluez la stabilité de l’alimentation dans les conditions thermiques attendues.

Tâche 16 : Si double-PSU, tester la redondance sous charge (contrôlé)

cr0x@server:~$ sudo stress-ng --cpu 0 --timeout 60s --metrics-brief
stress-ng: info:  [21901] dispatching hogs: 32 cpu
stress-ng: info:  [21901] successful run completed in 60.01s

cr0x@server:~$ ipmitool sel clear
Clearing SEL.  Please allow a few seconds to erase.

cr0x@server:~$ ipmitool sel list
SEL has no entries

Ce que ça signifie : Effacer le SEL vous permet de voir de nouveaux événements de redondance PSU pendant votre test contrôlé (pendant que vous retirez physiquement une PSU).

Décision : Si retirer l’alimentation A provoque de l’instabilité mais retirer la B non, A (ou son alimentation/câble) est suspect.

Remarque : vos mains ne sont pas une commande. Mais elles font partie de l’outillage diagnostique. Si vous faites des tests physiques, faites-les pendant une fenêtre de maintenance, sous supervision,
et avec des étapes de retour clairement définies.

Erreurs courantes : symptôme → cause racine → correction

1) « Redémarrages aléatoires, pas de logs » → brownouts/temps de maintien insuffisant → tester et échanger

Symptôme : Le système redémarre sans arrêt propre ; les logs montrent un trou.

Cause racine : La sortie PSU tombe en dessous de la tolérance pendant un transitoire de charge ou une baisse d’entrée AC ; temps de maintien trop court.

Correction : Échangez pour une PSU connue bonne ; vérifiez les événements de transfert UPS ; assurez une marge et une qualité suffisantes.

2) « NVMe disparaît, puis revient » → sous-tension transitoire → améliorer la réponse transitoire PSU

Symptôme : Boucles de reset NVMe, erreurs IO, déclenchement de rebuild RAID.

Cause racine : Resets de périphériques PCIe causés par de brefs creux de 12V ou un rail bruité.

Correction : Remplacez l’alimentation par une meilleure en termes de réponse transitoire ; réduisez les pics de charge ; vérifiez câblage et connecteurs backplane.

3) « Erreurs CRC SATA qui montent » → câble défaillant ou faisceau d’alimentation pauvre → remplacez le bon câble

Symptôme : SMART montre UDMA_CRC_Error_Count en hausse ; les disques tombent sous charge.

Cause racine : Problème de câblage signal (câble SATA, backplane), parfois aggravé par le ripple et la chauffe des connecteurs.

Correction : Remplacez les câbles de données SATA/backplane ; inspectez les connecteurs d’alimentation brunis ; assurez des connexions propres et serrées.

4) « Erreurs ECC correctibles qui augmentent seulement pendant un IO lourd » → bruit d’alimentation → corrigez l’alimentation d’abord

Symptôme : Rafale d’erreurs mémoire corrigibles pendant les scrubs/sauvegardes.

Cause racine : Bruit dans la distribution d’énergie provoquant des timings marginaux ; peut apparaître comme une instabilité RAM.

Correction : Validez les rails PSU et échangez l’alimentation avant de remplacer des DIMM ; retestez après la correction de l’alimentation.

5) « Ça ne tombe en panne que quand il fait chaud » → vieillissement des condensateurs et dérating thermique → ventilation et PSU de qualité

Symptôme : Stable en hiver ou boîtier ouvert ; échoue sous ambiance chaude ou courbes de ventilateurs élevées.

Cause racine : L’intérieur d’une PSU bon marché chauffe ; les condensateurs perdent leur capacité effective ; la régulation se dégrade.

Correction : Améliorez le flux d’air du châssis, dépoussiérez, et remplacez la PSU par un modèle avec une meilleure tolérance thermique ; évitez de fonctionner près de la puissance max.

6) « Le ventilateur PSU hurle, puis s’arrête, puis le serveur meurt » → ventilateur défaillant/mauvais comportement OTP → remplacer immédiatement

Symptôme : Comportement erratique du ventilateur PSU ; arrêts intermittents.

Cause racine : Roulement de ventilateur en fin de vie ou mauvais contrôle thermique ; la protection sur température peut se déclencher tard.

Correction : Remplacez la PSU. Ne « remplacez juste le ventilateur » en production que si vous aimez prendre des risques avec votre café.

7) « Nous avons remplacé des disques et ça continue » → chasser la victime plutôt que l’attaquant → arrêter et re-baseliner

Symptôme : Multiples remplacements de composants ne résolvent pas les resets et erreurs IO.

Cause racine : PSU ou alimentation en amont causant des erreurs en cascade sur plusieurs périphériques.

Correction : Re-baselinez : corrélez les resets avec les capteurs de puissance ; faites un échange PSU connu bon ; vérifiez le comportement PDU/UPS.

8) « La marque veut dire sûr » → variance selon modèle/plateforme → qualifier l’unité exacte

Symptôme : « Mais c’est une marque réputée » alors que les problèmes persistent.

Cause racine : Les marques sous-traitent ; la qualité varie selon la plateforme, la révision et l’OEM.

Correction : Sélectionnez les PSU par performance électrique et protections vérifiées, pas par logo ; standardisez sur des modèles connus bons.

Listes de contrôle / plan étape par étape

Liste d’achat : comment ne pas acheter des ennuis

• Achetez pour le comportement électrique, pas pour la puissance. Recherchez des validations indépendantes du ripple, de la réponse transitoire, des protections et du temps de maintien.
• Prévoyez de la marge. Visez une charge typique autour de 40–60 % de la puissance PSU pour l’efficacité et la marge transitoire (les chiffres exacts dépendent de la plateforme, mais « près du max » est à éviter).
• Privilégiez les designs DC-DC modernes pour les rails mineurs si vous construisez des systèmes ATX, et les PSU serveurs réputés pour le matériel en rack.
• Vérifiez la qualité des connecteurs et la section des faisceaux. Surtout pour les GPU et les nœuds à grand nombre de disques.
• Standardisez les modèles. Moins de références PSU signifie moins d’inconnues et des remplacements plus rapides.
• Décidez votre stratégie de redondance en amont. Dual-PSU avec feeds séparés si la disponibilité compte ; PSU unique plus spare froid si ce n’est pas le cas.

Checklist de montage : détails d’installation qui préviennent les pannes

• Utilisez des PDUs/circuits séparés pour les PSUs redondants. « Deux PSUs sur la même multiprise » est du théâtre.
• Étiquetez le mapping PSU→PDU. Les humains déboguent plus vite quand le monde physique est documenté.
• N’écrasez pas un seul faisceau de câbles. Évitez les coudes brusques et la tension sur les connecteurs.
• Pour les serveurs de stockage, vérifiez la distribution d’alimentation des disques. Échelonnez les spin-up si possible.
• Mettez en place du monitoring pour « redondance PSU perdue », événements de tension et redémarrages inattendus.

Checklist opérationnelle : quand un hôte devient hanté

1. Geler les écritures risquées : suspendre scrubs/rebuilds/backfills si le système flappe.
2. Classer la panne : reset brutal vs redémarrage propre vs resets de périphériques.
3. Récupérer les logs : last -x, journalctl -k, SMART, BMC SEL.
4. Corréler avec la charge : y a-t-il eu un pic de jobs, une sauvegarde ou une tempête de compilations ?
5. Vérifier l’amont : transitions d’état UPS, alertes PDU, disjoncteurs qui déclenchent.
6. Échanger avec une PSU connue bonne (ou permuter la position PSU dans un châssis double-PSU).
7. Relancer un stress contrôlé et confirmer la stabilité avant de clôturer.
8. Rédiger une note d’incident courte : ce que vous avez vu, ce que vous avez changé et ce que vous avez remplacé.

Checklist de conception : stockage et virtualisation

• Arrays ZFS/RAID : préférez une alimentation stable et un UPS ; évitez le comportement brownout instable qui provoque des resets répétés de périphériques.
• Nœuds riches en SSD : envisagez des disques avec protection contre la perte de puissance ; les PSU bon marché plus des SSD grand public font un mauvais mélange.
• Nœuds GPU : priorisez le câblage, la qualité des connecteurs et la réponse transitoire ; les GPU ont des charges très explosives.
• Hôtes de virtualisation : dual-PSU, feeds séparés et alerting sur perte de redondance sont non négociables si vous tenez à la haute disponibilité.

FAQ

1) Un 80 PLUS Gold suffit-il pour garantir une bonne alimentation ?

Non. Cela indique surtout l’efficacité à des points de charge spécifiques. Une alimentation peut être efficace et avoir quand même un ripple médiocre, une faible réponse transitoire
ou des protections mal réglées. Traitez 80 PLUS comme « un point de donnée », pas comme un certificat de sécurité.

2) Quel est le symptôme le plus courant en production d’une mauvaise alimentation ?

Des redémarrages brutaux sous charge. Surtout lorsqu’ils s’accompagnent de resets de liens de stockage (SATA/NVMe) ou d’erreurs PCIe AER.

3) Une alimentation bon marché peut-elle provoquer une corruption de données sans redémarrer ?

Oui, bien que ce soit plus difficile à prouver. Le ripple et les creux transitoires peuvent déstabiliser les contrôleurs et les chemins mémoire de façon à provoquer des écritures erronées ou
des incohérences de métadonnées. Les systèmes de fichiers et les bases de données sont résistants, mais pas magiques.

4) Si mon système démarre et fait tourner des jeux, pourquoi n’exécuterait-il pas une charge serveur ?

Les serveurs exécutent souvent des IO soutenus et une charge CPU élevée pendant des heures, plus des rafales simultanées (scrubs, backups, compactions).
Les tests « ça marche sur mon bureau » ne couvrent pas ces schémas ni l’environnement thermique d’un rack.

5) Quelle marge laisser lors du dimensionnement d’une alimentation ?

Assez pour que l’exploitation normale ne vive pas au bord du gouffre. Une cible pratique est de maintenir la charge typique entre 40–60 % et de s’assurer que les pics restent confortablement
en dessous de la puissance continue de la PSU. La marge exacte dépend des transitoires (les nœuds GPU en demandent plus).

6) Les câbles modulaires sont-ils interchangeables entre marques d’alimentation ?

Généralement non, et « généralement » n’est pas une stratégie de gestion du risque. Les brochages diffèrent même au sein d’une même marque selon les gammes.
Mélanger les câbles peut instantanément tuer des disques et des cartes mères. N’utilisez que les câbles prévus pour ce modèle exact de PSU.

7) Un UPS rend-il les alimentations bon marché sûres ?

Un UPS aide pour les coupures et certaines anomalies d’alimentation, mais il ne corrige pas une mauvaise réponse transitoire ou un ripple élevé.
De plus, certaines PSU se comportent mal lors des événements de transfert UPS. Testez votre couplage exact.

8) Et la redondance PSU — peut-on utiliser deux unités bon marché et être tranquilles ?

La redondance réduit le temps d’arrêt dû à une seule PSU défaillante, mais elle ne garantit pas une alimentation propre ou un bon comportement sous charge.
Deux mauvaises PSU peuvent toujours produire de l’instabilité, et une unité défaillante peut stresser l’autre ou injecter du bruit avant de mourir.

9) Comment distinguer PSU défaillante versus VRM de carte mère ?

On ne peut souvent pas trancher proprement sans échanger. Mais les schémas aident : les problèmes PSU se corrèlent avec des événements AC/SEL PSU, des resets multiples de périphériques à la fois,
et des changements quand vous déplacez les circuits. Les problèmes VRM peuvent se corréler à une charge CPU spécifique et à la température et persister à travers les PSU.
En exploitation, vous échangez d’abord le composant le moins cher/le plus rapide à remplacer—souvent l’alimentation.

10) Quelle est la voie de mise à niveau la plus sûre pour une machine de stockage homelab ?

Achetez une alimentation connue pour être fiable avec de bonnes protections et une marge décente, mettez le système sur un UPS, et évitez de mélanger les câbles modulaires.
Si vous gérez des données importantes, priorisez la stabilité plutôt que l’esthétique et les fonctionnalités RGB.

Prochaines étapes que vous pouvez faire cette semaine

Si vous gérez des systèmes de production, traitez les alimentations comme des pneus sur une flotte de véhicules : vous n’achetez pas les moins chers et espérez que vos conducteurs deviennent meilleurs en physique.
La qualité de l’alimentation est fondamentale. Tout le reste en dépend.

Actions pratiques

• Inventoriez les PSU (modèle et numéro de pièce) sur votre flotte via BMC si possible, et identifiez les unités inconnues/à faible confiance.
• Choisissez un ou deux modèles standardisés et éprouvés pour chaque classe de châssis (stockage, calcul, GPU) et cessez les improvisations à l’achat.
• Mettez en place des alertes pour les redémarrages inattendus, « redondance PSU perdue » et événements de tension BMC.
• Lancez un test de stress contrôlé sur le matériel neuf pendant le burn-in et surveillez les signes de reset PSU/PCIe/stockage.
• Gardez des spares froids des modèles PSU standardisés. L’incident le plus rapide est celui que vous terminez par un échange et une note.
• Pour les services critiques, passez au dual-PSU avec feeds séparés et testez le basculement trimestriellement—ennuyeux, répétable, efficace.

Si vous êtes encore tenté par une alimentation à pas cher, posez-vous une autre question : « Quel est mon taux horaire pendant une panne ? »
Soudainement, l’économie de 20 $ ressemble à un prêt à intérêt agressif.