Dimensionnement des alimentations pour serveurs — Arrêtez de deviner, commencez à mesurer

Pourquoi le dimensionnement des alimentations est un problème SRE, pas un problème d’achat

Le dimensionnement des alimentations est souvent vu comme une case à cocher procurement : choisir une puissance, indiquer « redondant », expédier. En production, cette approche échoue pour la même
raison que « on ajoutera juste des nœuds » échoue : elle ignore les limites physiques qui claquent en premier.

L’alimentation est l’endroit où votre charge de travail rencontre la physique. Les pics de workload deviennent des pics de courant. Le comportement du firmware devient la puissance des ventilateurs.
Une nouvelle carte réseau devient quelques watts supplémentaires que vous n’aviez jamais budgétisés. Et la partie la plus humiliante : quand l’alimentation déraille, les symptômes n’annoncent pas toujours
« alimentation ». Vous obtenez des disques instables, des réboots surprises, des réinitialisations de NIC, des capteurs BMC corrompus, ou des panics kernel « aléatoires ». Les problèmes d’alimentation se déguisent en problèmes logiciels.

Vous voulez trois résultats :

• Pas d’incidents causés par des disjonctions, surcharge d’alimentation ou baisses de tension.
• Pas de gaspillage dû à des alimentations massivement surdimensionnées fonctionnant à faible charge inefficace.
• Rétablissement rapide lorsqu’une alimentation tombe, qu’un circuit chute ou qu’un PDU vous ment.

Si votre méthode actuelle de dimensionnement est « additionner les TDP et arrondir à la hausse », vous faites tourner la production sur de l’espoir. L’espoir n’est pas une source d’alimentation.

Faits intéressants et un peu d’histoire (pour que vous cessiez de répéter de vieilles erreurs)

1. Les premières alimentations PC étaient centrées sur des charges lourdes en 5V. Les serveurs modernes sont largement centrés sur le 12V, et la conversion DC-DC a migré sur la carte.
2. ATX12V (début des années 2000) a poussé plus de puissance vers le 12V pour alimenter les CPU, changeant l’importance des « rails » et des limites de courant dans les vraies configurations.
3. 80 PLUS (milieu des années 2000) a fait de l’efficacité un argument marketing et d’achat, mais ses points de test ne couvrent pas vos charges de travail impulsionnelles.
4. Les datacenters ont basculé de la pensée « un gros UPS » vers des UPS distribués et des PDUs intelligents, rendant la mesure plus simple—si vous l’utilisez vraiment.
5. Les alimentations redondantes sont devenues la norme non pas parce qu’elles sont sexy, mais parce que le hot-swap d’une alimentation vaut mieux qu’une fenêtre de maintenance à 2h du matin.
6. Les CPU et GPU modernes ont introduit des comportements de boost agressifs ; la puissance instantanée peut dépasser le « TDP » de façons que les dossiers procurement mentionnent rarement.
7. Les courbes des ventilateurs ont changé la donne : des ventilateurs haute pression statique peuvent consommer une puissance significative en pleine vitesse, et une mise à jour de firmware peut altérer ce comportement du jour au lendemain.
8. La densité en rack a explosé avec la virtualisation et les GPU ; la puissance et le refroidissement sont devenus les premières contraintes, pas les unités en rack.
9. La coordination des disjoncteurs dans les installations a évolué, mais les disjoncteurs réagissent encore plus vite que vos alertes parfois—surtout lors d’inrush.

Un modèle mental sain : moyenne, pic et les secondes gênantes entre les deux

Les erreurs de dimensionnement viennent de l’utilisation d’un seul chiffre alors qu’il en faut au moins trois :

• Moyenne en régime permanent : ce que le serveur consomme la plupart du temps.
• Pic soutenu : ce qu’il tire pendant le vrai travail, pas les calculs synthétiques « TDP ».
• Transitoire/inrush : ce qu’il tire au démarrage, lors d’un spin-up simultané de disques, d’un ramping de ventilateurs ou de pics GPU.

Ajoutez un quatrième si vous avez de la redondance :
mode mono-alimentation—car dans une configuration 1+1, vous devez quand même survivre avec une seule alimentation sans vous effondrer.

Ce que « puissance PSU » signifie réellement

Une alimentation « 1200W » est typiquement spécifiée pour une certaine tension d’entrée, température, flux d’air, et parfois altitude. Elle implique aussi une puissance DC maximale en sortie dans ces
conditions. Elle ne signifie pas que votre système peut tirer en toute sécurité 1200W en continu dans n’importe quel rack, à n’importe quelle température, sur n’importe quelle alimentation,
pendant que les moutons de poussière montent un fonds d’investissement isolant à l’intérieur du châssis.

Une citation à garder au mur

« L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

Pas un SRE, mais le sentiment est cruellement pertinent. En planification de puissance, « ça ne montera probablement pas » est de l’espoir déguisé en ingénierie.

Blague #1 : Une alimentation de serveur, c’est comme un parachute : si vous découvrez qu’elle est sous-dimensionnée quand vous en avez besoin, vous allez passer une mauvaise journée.

Ce qu’il faut mesurer (et ce que les fiches techniques ne vous diront pas)

Les fiches techniques sont écrites pour vendre du matériel, pas pour garder votre cluster en vie. Elles sont utiles—mais seulement comme conditions limites. Votre travail est de
mesurer la réalité dans votre environnement, avec votre firmware, et votre mix de charges.

Mesurer à plusieurs niveaux

• Puissance d’entrée mur/PDU : ce que vous payez et ce qui fait sauter les disjoncteurs.
• Sortie PSU (rarement visible directement) : ce que le système consomme en termes DC.
• Indices au niveau composant : puissance package CPU, puissance GPU, activité des disques, RPM et PWM des ventilateurs.

Connaître les limites qui comptent

• Circuit branché (calibre du disjoncteur ; les pratiques de dérating de charge continue varient selon la région et le code).
• PDU et prise limites (C13/C14 vs C19/C20, calibre du cordon, limites par prise).
• Puissance unitaire PSU selon votre tension d’entrée (piège fréquent : performances 120V vs 208/230V et marge disponible).
• Mode redondance (partage de charge vs actif/standby ; et si la plateforme peut survivre sur une seule alimentation à pleine charge).

Ne confondez pas ces termes

• TDP : un point de conception thermique, pas un plafond contractuel de puissance.
• PL1/PL2 (et équivalents constructeurs) : politique de puissance soutenue vs boost ; le firmware peut les modifier.
• Puissance apparente (VA) vs puissance active (W) : les UPS et PDUs peuvent rapporter l’un ou l’autre ; le facteur de puissance compte quand vous êtes près des limites.

Tâches de mesure pratiques (commandes, sorties, décisions)

Vous ne pouvez pas « architecturer » votre chemin hors de la mesure. Voici des tâches concrètes et exécutables. Chacune a : une commande, ce que signifie la sortie, et la décision qu’elle soutient.
Utilisez-les pour construire un profil de puissance par modèle de serveur et par classe de charge.

Task 1: Read BMC-reported instantaneous power (IPMI)

cr0x@server:~$ ipmitool sensor | egrep -i 'Power|Pwr Consumption|Watts'
Pwr Consumption   | 312        | Watts      | ok

Signification : Le BMC estime que le système tire ~312W en ce moment (souvent la puissance d’entrée, parfois calculée).
Décision : Si c’est loin de votre attente, validez la source BMC contre la mesure PDU avant de lui faire confiance pour la planification de capacité.

Task 2: Pull power history / min-max if the platform exposes it

cr0x@server:~$ ipmitool sdr elist | egrep -i 'Pwr|Power'
System Level      | 00h | ok  |  3.1 | Power Meter
System Level      | 01h | ok  |  3.2 | Power Max
System Level      | 02h | ok  |  3.3 | Power Min

Signification : Certains vendeurs exposent max/min depuis le boot ou la réinitialisation.
Décision : Si le max est proche des limites PSU ou circuit, ne l’« moyennez » pas. Prévoyez-le ou limitez-le.

Task 3: Measure CPU package power limits and current draw (Intel RAPL via powercap)

cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
225000000

Signification : 225,000,000 µW = 225W limite package long terme (style PL1) pour ce domaine RAPL.
Décision : Si votre dimensionnement PSU supposait « CPU = 165W », mais que le firmware permet 225W soutenu, mettez à jour votre budget ou imposez une limite.

Task 4: Sample RAPL energy to estimate average CPU power over an interval

cr0x@server:~$ E1=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); sleep 10; E2=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); echo $(( (E2-E1)/10000000 ))
186

Signification : Environ 186W en moyenne pour ce package sur 10 secondes (énergie en µJ divisée par 10s).
Décision : Identifiez les charges avec une puissance CPU soutenue élevée ; ce sont elles qui transforment un « pic » en événement fréquent.

Task 5: Check GPU power draw and limits (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,power.draw,power.limit,clocks.sm --format=csv,noheader
NVIDIA A10, 126.54 W, 150.00 W, 1395 MHz

Signification : La puissance GPU en temps réel est de 126W, avec une limite à 150W.
Décision : Pour les serveurs GPU, dimensionner sans télémétrie réelle GPU, c’est du cosplay. Si plusieurs GPU peuvent atteindre leur limite simultanément, budgétez ce pic.

Task 6: Verify current CPU frequency and throttle status (quick sanity check)

cr0x@server:~$ lscpu | egrep -i 'Model name|CPU max MHz|CPU MHz'
Model name:          Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU max MHz:         3200.0000
CPU MHz:             2001.102

Signification : La fréquence actuelle n’est pas en boost ; sous charge elle peut grimper et augmenter la consommation.
Décision : Si vous observez une fréquence basse persistante sous charge, vous êtes peut-être limité en puissance ou en thermique—les deux renvoient à l’alimentation et au refroidissement.

Task 7: Check for power-related events in kernel logs

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'power|brown|thrott|vrm|PSU|over current|watchdog' | tail -n 20
kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 27: b200000000070005
kernel: EDAC MC0: CPU power throttling detected

Signification : Le hardware/firmware rapporte du throttling ou des erreurs qui peuvent être liées à la distribution d’énergie (pas toujours, mais à corréler).
Décision : Si cela corrèle avec des pics ou des reboots, arrêtez de debugger une « instabilité aléatoire » et inspectez les feeds d’alimentation, les PSU et les thermiques.

Task 8: Check PSU status and redundancy mode via IPMI (if supported)

cr0x@server:~$ ipmitool sdr type 'Power Supply'
PS1 Status       | ok
PS2 Status       | ok
PS1 Input Power  | 165 Watts
PS2 Input Power  | 162 Watts

Signification : Les deux PSUs sont actifs et partagent la charge à peu près également.
Décision : Si vous vous attendiez à un mode 1+1 avec une unité au repos et une active, vous n’êtes peut‑être pas dans le mode de redondance attendu. Mettez à jour votre modèle de défaillance.

Task 9: Measure wall power via a metered rack PDU (SNMP example)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.7.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.7.1 = INTEGER: 356

Signification : L’OID fournisseur retourne la puissance de la prise en watts (exemple : 356W). La sémantique des MIB varie ; confirmez les unités une fois, puis automatisez.
Décision : Utilisez les relevés PDU comme vérité terrain pour la planification de circuit et le risque de disjonction. Les lectures BMC sont « utiles », pas votre référence comptable.

Task 10: Check PDU outlet current to spot near-trip risk

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.5.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.5.1 = INTEGER: 28

Signification : Courant de la prise (exemple : 2.8A si l’appareil utilise des déci-ampères ; encore une fois dépendant du fournisseur).
Décision : Convertissez en ampères, comparez aux limites du circuit et de la prise PDU. Si vous êtes proche, n’ajoutez pas « juste un nœud de plus ».

Task 11: Correlate workload with power using a controlled load test (CPU)

cr0x@server:~$ sudo apt-get -y install stress-ng
...
cr0x@server:~$ stress-ng --cpu 32 --cpu-method matrixprod --timeout 60s --metrics-brief
stress-ng: info:  [8421] dispatching hogs: 32 cpu
stress-ng: metrc: [8421] cpu                60.00s  19184.12 bogo ops/s

Signification : Vous avez généré une charge CPU reproductible. Associez ceci à des relevés PDU/BMC simultanés.
Décision : Construisez une base de référence « pic CPU seul » par plateforme. Faites ensuite la même chose avec disque et réseau pour voir les pics combinés.

Task 12: Disk activity and drive count matter—measure it (storage load)

cr0x@server:~$ iostat -dx 2 3
Device            r/s     w/s   rMB/s   wMB/s avgrq-sz avgqu-sz await  svctm  %util
nvme0n1         820.0   110.0   128.0    24.0     358     2.10   2.1   0.6   55.0

Signification : Le stockage fait du vrai travail. Les disques et contrôleurs consomment plus en charge ; les HDD ont aussi des pics de spin-up.
Décision : Si votre pic de puissance coïncide avec des rebuilds/resyncs, budgétez la « puissance en mode défaillance », pas seulement la puissance en chemin heureux.

Task 13: Check for RAID/HBA controller battery/flash module charging events

cr0x@server:~$ sudo dmesg | egrep -i 'battery|cachevault|supercap|charging' | tail -n 20
megaraid_sas 0000:3b:00.0: CacheVault charging started

Signification : Les modules de protection de cache peuvent consommer de la puissance supplémentaire lors de la charge après maintenance ou longue inactivité.
Décision : Si vous avez eu des démarrages à froid ou des maintenances, attendez-vous à un pic temporaire de puissance. Ne le traitez pas comme des « watts mystères ».

Task 14: Check fan RPM and PWM—fans are not free

cr0x@server:~$ sudo ipmitool sdr | egrep -i 'FAN|RPM' | head
FAN1            | 7800   | RPM  | ok
FAN2            | 8100   | RPM  | ok

Signification : Un RPM élevé implique une consommation plus importante par les ventilateurs et indique souvent un stress thermique ou un changement de profil firmware.
Décision : Si vous voyez des vitesses de ventilateur élevées et soutenues, investiguez l’aération et les températures d’entrée ; votre budget de puissance et les thermiques PSU s’en trouvent affectés.

Task 15: Validate PSU input voltage (because 120V vs 208V matters)

cr0x@server:~$ ipmitool sensor | egrep -i 'Inlet|VIN|AC|Voltage' | head
PS1 Inlet Volt   | 208        | Volts     | ok
PS2 Inlet Volt   | 208        | Volts     | ok

Signification : Les PSUs voient 208V, ce qui améliore généralement l’efficacité et réduit le courant pour la même puissance.
Décision : Si vous êtes en 120V et poussez la densité, envisagez de passer à des alimentations en tension plus élevée si possible. C’est souvent le gain de capacité le plus simple.

Task 16: Quick-and-dirty inrush observation with PDU peak logging (if supported)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.4.3.1.6.1
SNMPv2-SMI::enterprises.318.1.1.26.4.3.1.6.1 = INTEGER: 47

Signification : Un compteur « pic de courant depuis le dernier reset » (exemple). L’OID exacte dépend du fournisseur et du modèle.
Décision : Si le courant pic est bien au-dessus de l’état permanent, étalez les démarrages et évitez l’alimentation synchronisée après coupures.

Alimentations redondantes : 1+1 n’est pas toujours 1+1

Les alimentations redondantes sont vendues comme fiabilité. En pratique, elles n’apportent de la fiabilité que si vous les dimensionnez et alimentez correctement.
Deux alimentations ne garantissent pas que vous pourrez fonctionner à pleine puissance après la défaillance d’une unité. Cela dépend de :

• Capacité par alimentation vs pic système.
• Comportement de partage de charge (active/active ou actif/standby).
• Comportement en capping lorsqu’une alimentation disparaît (certains systèmes se mettent automatiquement à limiter ; d’autres tombent simplement).
• Indépendance des feeds (deux alimentations sur le même PDU n’est pas de la redondance ; c’est de l’optimisme avec un câble en plus).

Dimensionnement N+1 en termes simples

Si vous avez deux alimentations de 800W en configuration 1+1, la question pertinente est :
Le serveur peut‑il tourner au pic sur une seule alimentation de 800W ?
Si votre pic mesuré réel est de 780W au mur et que votre PSU se dérate à haute température d’entrée, vous n’êtes pas « safe ». Vous êtes équilibré sur une mince subtilité technique.

Le partage de charge n’est pas garanti

Si deux PSUs partagent mal (firmware, PSUs mal appariées, vieillissement ou câblage), une unité peut chauffer et fonctionner près de sa limite. Lorsqu’elle tombe, l’autre prend la charge supplémentaire
qui peut provoquer une deuxième défaillance ou un reboot. C’est le « double-tap de l’alimentation redondante », et ce n’est pas une expérience agréable.

Courant d’appel (inrush) : le disjoncteur se moque de vos tableaux

L’inrush est la surtension quand vous appliquez l’alimentation—chargement des condensateurs, démarrage des ventilateurs, spin-up des disques, réveil des GPU, et chaque régulateur décidant qu’il est temps de faire la fête.
Votre budget de puissance en régime permanent peut sembler correct alors que l’inrush fait sauter le disjoncteur lors d’un reboot massif.

Les équipes facilities s’en soucient parce que c’est la différence entre « l’alimentation rétablie » et « la moitié de la rangée reste dans le noir ». Vous devez vous en préoccuper parce qu’après un événement
datacenter, tout le monde va couper et remettre l’alimentation en même temps, et votre orchestrateur pourrait utilement faire la même chose simultanément.

Blague #2 : Les disjoncteurs sont comme les ingénieurs d’astreinte : ils tolèrent beaucoup, mais ils retiennent exactement une dernière paille.

Comment réduire le risque d’inrush

• Échelonner les démarrages (PDUs, automatisation hors bande, ou crochets d’orchestration).
• Éviter le ramping synchronisé des ventilateurs en déployant les firmwares par vagues contrôlées, pas par « toute la flotte le vendredi ».
• Connaître le comportement des HDD : les réglages de spin-up échelonné sur les HBA peuvent sauver votre disjoncteur et votre fierté.
• Mesurer le courant pic lorsque possible : certains PDUs et UPS mesurés consignent des pics et événements d’inrush.

Derating : température, altitude, poussière et pourquoi « 1200W » est parfois de la fantaisie

Les spécifications PSU supposent des conditions particulières. Puis vous installez le serveur dans un rack avec des blanking partiels, une allée chaude plus « suggestion tiède » qu’autre chose, et de la poussière
qui transforme les radiateurs en feutre.

Le dérating se manifeste par :

• Moins de sortie disponible à des températures d’entrée plus élevées.
• Plus de puissance consommée par les ventilateurs (ce qui augmente la consommation système et réduit l’efficacité).
• Arrêt thermique plus précoce ou throttling protecteur.

La température est un multiplicateur de risque

Un serveur qui est « correct » à 18°C en entrée peut devenir fragile à 30°C en entrée lorsque l’une des alimentations tombe et que la restante fonctionne plus chaude et plus bruyante.
C’est le pire moment pour apprendre que votre hypothèse de redondance était basée sur une brochure de laboratoire.

L’altitude existe vraiment (oui, vraiment)

La haute altitude réduit la densité d’air, réduisant l’efficacité du refroidissement. Beaucoup de vendeurs spécifient un dérating au‑delà de certaines élévations. Vous pouvez l’ignorer si vous voulez,
mais l’alimentation ne sera pas convaincue par votre confiance.

Courbes d’efficacité : les watts que vous ne tirez pas vous coûtent quand même

L’efficacité n’est pas une constante. C’est une courbe. La plupart des PSUs sont les plus heureux quelque part autour de 40–60% de charge, selon la conception. À très faible charge, l’efficacité chute,
et vous gaspillez de la puissance en chaleur. À très haute charge, l’efficacité peut aussi chuter et les thermiques deviennent désagréables.

Le surdimensionnement par défaut donne l’impression d’être « sûr », mais il peut coûter de l’argent de trois façons :

• Capex : les modèles d’alimentations plus gros coûtent plus cher.
• Opex : une efficacité plus faible à l’inactivité sur une flotte n’est pas jolie sur la facture d’électricité.
• Refroidissement : les watts gaspillés deviennent de la chaleur que votre installation doit évacuer.

Que faire au lieu de surdimensionner aveuglément

Mesurez votre pic réel et choisissez une alimentation telle que :

• Votre régime permanent se situe dans la zone efficace de la courbe.
• Votre pic soutenu reste sous un seuil conservateur (surtout en mode N+1).
• Votre inrush ne fait pas sauter les circuits pendant les événements de flotte.

C’est moins glamour que d’acheter la plus grosse unité disponible. C’est aussi la façon d’éviter de passer vos weekends dans une allée froide avec une lampe torche.

Trois mini-histoires d’entreprise du pays du « ça devrait aller »

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

Une entreprise a déployé un nouveau lot de serveurs orientés stockage : beaucoup de disques, contrôleurs doubles et PSUs « redondantes ». Procurement a dimensionné les PSUs en ajoutant
TDP CPU, mémoire, et « un peu pour les disques ». Ils se sont aussi standardisés sur une alimentation 120V dans une salle legacy parce que « c’était déjà là ».

Tout semblait correct en régime permanent. Les racks étaient silencieux, les graphes de monitoring ennuyeux, et le déploiement a été déclaré réussi. Puis la facility a fait une maintenance planifiée.
Au retour de l’alimentation, toute la rangée a essayé de démarrer en même temps. Plusieurs disjoncteurs ont sauté immédiatement. Une poignée de racks ont redémarré à moitié : certains serveurs étaient en boot-loop,
certains ont perdu des disques, et quelques contrôleurs sont revenus dégradés.

Le postmortem a été désordonné parce que la première vague de debugging a visé le logiciel : versions du kernel, ordre de boot, firmware RAID. L’indice révélateur fut que les défaillances s’agglutinaient par rack et PDU,
pas par build OS. Quelqu’un a finalement extrait les logs de pic courant du PDU et les a comparés à la capacité du circuit.

La cause racine n’était pas que les serveurs tiraient « trop de puissance » en moyenne. C’était que l’inrush et le spin-up simultané des disques dépassaient la tolérance du disjoncteur en 120V, où le courant est plus élevé
pour la même puissance. Les PSUs « redondantes » n’ont pas aidé parce que la redondance ne protège pas un disjoncteur contre une surcharge.

La correction a été peu excitante : séquençage des démarrages, activation du spin-up échelonné sur les HBA, et déplacement des racks les plus denses vers des alimentations à tension plus élevée disponibles.
Ils ont aussi commencé à capturer la puissance pic au PDU comme test d’acceptation. Le prochain événement de maintenance s’est déroulé sans incident—ce qui est le meilleur type d’événement.

Mini-histoire 2 : L’optimisation qui a échoué

Une autre organisation s’est sérieusement engagée sur l’efficacité et a décidé de « right-size » de manière agressive. Ils ont remarqué que leurs serveurs idlaient entre 120–160W et ont conclu que
des PSUs plus petites amélioreraient l’efficacité à l’inactivité. Ils ont standardisé une config avec des PSUs de moindre puissance sur une nouvelle flotte compute.

Les tests en laboratoire semblaient bons. L’efficacité à l’inactivité s’est améliorée légèrement. Procurement a adoré la réduction de coût. La flotte a été déployée en production, où la charge était bursty—
pensez analytics batch mélangé avec trafic API en pics. Pendant les rafales, le boost CPU a poussé la puissance soutenue plus haut que prévu par quiconque.
C’était encore « dans la spécification » pour une seule alimentation—jusqu’à la défaillance d’un PSU.

En redondance 1+1, une seule alimentation devait maintenant supporter la charge complète. Sur le papier, elle le pouvait. En pratique, avec des températures d’entrée plus élevées et des conditions plus poussiéreuses
que le labo, la PSU restante a chauffé. Le firmware de la plateforme a répondu en bridé la performance. Le service n’est pas tombé, mais la latence est passée de « correcte » à « pourquoi la file fond ? ».
Les SREs l’ont perçu comme une régression logicielle parce que rien n’a planté. C’était juste lent et imprévisible.

L’échec n’était pas l’idée de right-sizing. C’était de le faire basé sur des tests d’inactivité en ignorant le mode défaillance N+1 et le dérating environnemental. La correction a été d’augmenter la taille PSU d’un cran,
d’imposer des caps de puissance sur les nœuds les plus bursty, et d’arrêter d’utiliser uniquement l’efficacité à l’inactivité comme métrique de succès. L’efficacité compte. La prévisibilité compte davantage.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe gérant une flotte mixte (quelques boîtes GPU, quelques nœuds stockage, quelques compute simples) avait une politique terne : chaque nouveau modèle matériel devait passer une « checklist de
caractérisation de puissance » avant d’entrer en production. Cela signifiait mesurer l’inactivité, le 50e centile de charge, le pic soutenu et l’inrush au boot—en utilisant le même modèle de PDU qu’en production.

La checklist demandait aussi de tester la redondance : retirer une alimentation sous charge et confirmer que le nœud reste stable, avec enregistrement de la puissance et des thermiques.
Ce n’était pas optionnel. Ce n’était pas « quand on a le temps ». C’était aussi obligatoire que les tests de rebuild RAID.

Un jour, un vendeur a livré une « révision mineure » d’un modèle serveur. Même famille SKU, même fiche marketing, firmware différent et comportement ventilateur légèrement modifié.
La caractérisation a révélé que la nouvelle révision avait un ramping de ventilateur beaucoup plus abrupt sous certains seuils de capteur, augmentant le pic de consommation suffisamment pour importer
quand une PSU tombait. Le système est resté en ligne, mais la marge a disparu.

Parce qu’ils disposaient de données de référence, cela n’est pas devenu un incident. Ils ont ajusté le placement en rack (densité plus faible par circuit pour cette révision), réglé les paramètres firmware
quand c’était possible, et mis à jour le budget de puissance. Un mois plus tard, une vraie défaillance PSU s’est produite en production pendant un job lourd. Le nœud est resté en ligne.
Aucun impact client. Pas d’héroïsme. Juste la satisfaction discrète d’une ingénierie ennuyeuse qui fonctionne comme prévu.

Guide de diagnostic rapide

Quand quelque chose sent l’alimentation—reboots aléatoires, défaillances corrélées par rack, chutes de performance après une défaillance PSU—ne vous égarez pas. Vérifiez dans cet ordre.
L’objectif est de trouver le goulot en minutes, pas après avoir réécrit la moitié de l’ordonnanceur.

Premier : confirmer ce qui échoue (nœud, rack, feed ou salle)

• Les défaillances se regroupent-elles par rack/PDU ou par modèle matériel ?
• Les événements sont-ils corrélés avec des boot storms, de la maintenance ou des pics de température ?
• Voyez-vous des disjonctions ou des alarmes UPS ?

Deuxième : faites confiance au PDU/UPS pour la puissance d’entrée, puis recoupez avec le BMC

• Vérifiez les watts/ampères par prise du PDU rack et tout compteur de pic.
• Comparez aux watts rapportés par le BMC ; de grandes différences suggèrent des capteurs décalés ou des bugs firmware.
• Validez la tension d’entrée. Une tension basse signifie plus de courant pour la même charge, et moins de marge.

Troisième : testez le comportement de redondance sous charge

• En condition contrôlée, retirez une PSU et observez : la puissance saute‑t‑elle ? les ventilateurs montent‑ils en régime ? l’hôte est‑il bridé ?
• Confirmez que chaque PSU est sur des feeds séparés et que les feeds sont réellement indépendants.
• Si la performance change matériellement, considérez-le comme un risque de production, pas un « agréable à savoir ».

Quatrième : isoler les causes transitoires

• Démarrage inrush et spin-up disque : cherchez des événements de pic PDU ou disjoncteur pendant la restauration de l’alimentation.
• Changements firmware / courbe ventilateur : corrélez avec des mises à jour récentes.
• Rafales de charge : corrélez avec la télémétrie CPU/GPU et le timing des incidents.

Erreurs courantes (symptôme → cause racine → fix)

1) Reboots aléatoires sous charge

Symptôme : Les hôtes rebootent quand des jobs batch démarrent ou que l’utilisation GPU grimpe.
Cause racine : Surcharge PSU ou problèmes de réponse transitoire ; parfois une seule PSU est faible/vieillissante et s’effondre sur une montée en charge rapide.
Fix : Mesurez au PDU pendant la charge. Testez avec une PSU retirée. Remplacez la PSU suspecte. Si les pics sont légitimes, augmentez la capacité PSU ou limitez la puissance.

2) Disjoncteurs qui sautent après maintenance ou rétablissement

Symptôme : Des racks entiers restent dans le noir, les disjoncteurs sautent juste quand tout se remet sous tension.
Cause racine : Courant d’appel plus boot synchronisé ; spin-up HDD et ramping ventilateur amplifient cela, surtout en 120V.
Fix : Échelonnez les démarrages. Activez le spin-up échelonné. Réduisez la densité par circuit ou passez à des feeds en tension plus élevée.

3) « Redondant » mais une défaillance provoque un effondrement de performance

Symptôme : Pas d’arrêt, mais des pics de latence et un effondrement du débit quand une PSU meurt.
Cause racine : Le mode mono-alimentation déclenche du capping ou du stress thermique ; la PSU restante chauffe et le firmware bride CPU/GPU.
Fix : Dimensionnez pour qu’une PSU puisse gérer le pic soutenu avec marge à la pire température d’entrée. Testez et documentez la performance en mode défaillance.

4) PDU montre des watts élevés, le BMC montre des watts faibles (ou l’inverse)

Symptôme : Deux chiffres « autoritaires » divergent de 20–40%.
Cause racine : Différents points de mesure (entrée vs calculé), dérive de calibration des capteurs ou bugs de firmware BMC.
Fix : Considérez PDU/UPS en entrée comme la vérité pour la facturation et les disjoncteurs. Utilisez le BMC pour les tendances. Calibrez une fois avec un wattmètre de référence si nécessaire.

5) Nouveau firmware provoque des dépassements du budget de puissance

Symptôme : Après une mise à jour BIOS/BMC, la puissance rack augmente ou la puissance ventilateur saute ; disjoncteurs ou alarmes UPS apparaissent.
Cause racine : Courbes ventilateur mises à jour, limites de boost CPU plus élevées, ou profils de puissance par défaut différents.
Fix : Re‑caractérisez la puissance après les changements de firmware. Verrouillez les profils de puissance. Déployez les mises à jour par vagues avec monitoring PDU.

6) « On a dimensionné par TDP » et maintenant tout est serré

Symptôme : Le calcul sur la plaque signalétique dit que vous êtes à l’aise ; les mesures réelles disent le contraire.
Cause racine : Le TDP n’est pas un plafond ; overhead plateforme, mémoire, disques, NICs, ventilateurs et comportement de boost n’ont pas été inclus.
Fix : Construisez un modèle de puissance mesuré par plateforme : inactivité, typique, pic soutenu, inrush et mode N+1. Arrêtez d’utiliser la somme des TDP comme réponse finale.

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

Étape par étape : comment dimensionner une alimentation pour un modèle de serveur (sans deviner)

1. Établissez la source de vérité de mesure. Utilisez les watts d’entrée mesurés par PDU/UPS pour la planification de capacité ; utilisez le BMC pour les tendances et l’état de redondance.
2. Enregistrez les conditions d’entrée. Notez la tension d’entrée et la température d’entrée approximative pendant les tests. Les données de puissance sans conditions, c’est du commérage.
3. Mesurez quatre points de puissance :
   • Inactivité (post‑boot, services stables)
   • Charge typique (mix représentatif de production)
   • Pic soutenu (test de stress correspondant aux vrais goulets)
   • Pic de démarrage/inrush (cold boot, pas warm reboot)
4. Testez le comportement N+1. Sous charge, retirez une PSU et observez stabilité, throttling et comportement des ventilateurs. Enregistrez puissance et thermiques.
5. Appliquez une marge intentionnelle. Ajoutez de la marge pour l’erreur capteur, la dérive environnementale, le vieillissement et la « surprise firmware ». Évitez le réflexe de doubler.
6. Validez contre le circuit. Convertissez les watts en ampères à votre tension, et assurez‑vous de ne pas flirter avec les limites du circuit sous pics et inrush.
7. Décidez de la taille PSU et de la redondance. Choisissez un modèle PSU où le mode mono‑alimentation reste stable au pic soutenu, avec une marge réelle.
8. Documentez le profil. Stockez les valeurs mesurées et les conditions de test dans votre runbook matériel pour que la prochaine personne n’ait pas à refaire l’archéologie.
9. Opérationnalisez le monitoring. Alarmez sur les augmentations inhabituelles, mais aussi sur la perte de redondance et les changements inattendus de partage de charge.
10. Retestez après changements significatifs. BIOS/BMC, nouvelles NICs/HBAs, changements de modèle GPU ou shifts de workload méritent une nouvelle mesure.

Checklist : budget d’alimentation rack que vous pouvez défendre en réunion

• Par rack : typique mesuré et pic mesuré, pas seulement une somme de nameplates.
• Par circuit : ampérage à la tension réelle, avec hypothèse claire sur l’utilisation continue autorisée.
• Plan inrush : procédure de démarrage échelonné documentée et testée.
• Plan de redondance : PSUs sur feeds séparés ; PDUs sur upstreams séparés quand possible.
• Tests d’acceptation : chaque nouveau modèle matériel passe une caractérisation de puissance avant déploiement.

Checklist : édition « on ajoute des GPU »

• Mesurez la limite de puissance GPU par carte et confirmez l’enveloppe totale de la plateforme.
• Confirmez les limites d’alimentation auxiliaire PCIe et des risers ; ne supposez pas que le câblage du châssis correspond au marketing GPU.
• Testez le pic combiné CPU+GPU sous charges réelles (pas seulement synthétiques).
• Confirmez le comportement de redondance quand une PSU est retirée sous charge GPU.
• Validez le circuit de rack et le type de prise PDU (C13 vs C19) et les caps par prise.

FAQ

1) Puis‑je dimensionner une alimentation en additionnant les TDP des composants ?

Utilisez la somme des TDP seulement comme borne inférieure approximative. Les systèmes réels la dépassent par le comportement de boost, la puissance ventilateur, la charge des contrôleurs et les pics transitoires.
Mesurez au PDU.

2) Dois‑je toujours acheter l’option d’alimentation la plus puissante ?

Non. Le surdimensionnement peut coûter de l’argent et réduire l’efficacité à faible charge. Achetez pour le pic soutenu mesuré plus une marge, et assurez‑vous que le mode mono‑alimentation est sûr si vous
utilisez de la redondance.

3) Quelle marge devrais‑je ajouter ?

Il n’y a pas de chiffre universel. Ajoutez de la marge pour l’erreur de mesure, les changements environnementaux, le vieillissement et les ajouts futurs. La bonne marge est celle qui survive au mode
N+1 à la pire température d’entrée sans throttling ni instabilité.

4) Lequel est le plus fiable : watts BMC ou watts PDU ?

Pour la planification de capacité et les disjoncteurs : watts d’entrée PDU/UPS. Pour le trending par hôte et l’état de redondance : le BMC est utile. S’ils divergent, investiguez, mais budgétez sur le PDU.

5) Pourquoi la consommation augmente‑t‑elle après une mise à jour BIOS/BMC ?

Le firmware peut changer les limites de puissance CPU, les courbes ventilateur, le comportement de training mémoire et les defaults de gestion des périphériques. Traitez les mises à jour firmware comme un
changement matériel : re‑mesurez la puissance.

6) Comment la redondance des PSUs affecte‑t‑elle l’efficacité ?

En partage de charge, chaque PSU fonctionne à un pourcentage de charge inférieur, ce qui peut vous sortir de la zone optimale d’efficacité. En actif/standby, une PSU peut tourner près du point optimal tandis que l’autre
consomme de l’énergie en veille. Mesurez, n’assumez pas.

7) Que signifient VA vs W pour dimensionner UPS et circuits ?

W est la puissance active ; VA est la puissance apparente. Les UPS et PDUs peuvent indiquer l’un ou l’autre. Si le facteur de puissance n’est pas près de 1.0, le VA peut être significativement supérieur au W, et cela peut
devenir le facteur limitant pour la capacité UPS même quand les watts semblent corrects.

8) Comment éviter les disjoncteurs qui sautent lors des redémarrages de flotte ?

Échelonnez les démarrages, activez le spin-up échelonné des disques si applicable, et évitez un comportement d’orchestration « tous les nœuds en même temps ». Confirmez avec les logs de pic PDU et faites un test contrôlé.

9) Dois‑je encore me préoccuper des limites de rails PSU ?

Moins qu’à l’époque des polémiques multi‑rail desktop, mais oui dans certaines plateformes. Les PSUs serveur et les backplanes abstraient généralement cela, mais une forte densité GPU et la distribution de puissance
via les risers peuvent exposer des limites cachées. Si vous observez de l’instabilité sous charge GPU, vérifiez la distribution de puissance de la plateforme, pas seulement le total de watts.

10) Quelle méthode pratique pour limiter la puissance des serveurs et rester dans les limites ?

Utilisez les outils constructeurs ou les profils de firmware lorsque possible, et validez avec des mesures PDU. Pour les CPU, les limites basées sur RAPL peuvent aider, mais confirmez le comportement sous vos workloads—certains
workloads échangent latence contre watts de façon désagréable.

Prochaines étapes que vous pouvez faire cette semaine

• Choisissez un modèle de serveur et créez un profil de puissance : inactivité, typique, pic soutenu, démarrage/inrush et résultats du test N+1.
• Faites du PDU votre source de vérité pour la puissance d’entrée et les pics ; intégrez le polling SNMP dans votre pipeline de métriques.
• Réalisez un test de redondance contrôlé : sous charge significative, retirez une PSU et observez throttling, ramping des ventilateurs et sauts de puissance.
• Rédigez une procédure de démarrage échelonné et répétez‑la. Après une coupure, ce n’est pas le moment de découvrir que vos outils ne savent pas séquencer.
• Mettez à jour votre spécification d’achat : exigez des PSUs/BMC mesurés quand c’est possible, et demandez aux vendeurs de déclarer le comportement en mode mono‑alimentation.
• Recontrôlez après les mises à jour firmware. Traitez un « révision mineure » matérielle comme nouveau matériel jusqu’à ce que vous l’ayez mesuré.

L’objectif n’est pas de devenir ingénieur en puissance. C’est d’arrêter de traiter les watts comme du folklore. Mesurez, budgétez, testez les modes de défaillance, et passez aux problèmes qui sont réellement intéressants—comme pourquoi votre fenêtre de rebuild stockage est encore trop longue.