Dimensionamiento de fuentes para servidores — Deja de adivinar, empieza a medir

Por qué el dimensionamiento de PSUs es un problema de SRE, no de compras

El dimensionamiento de PSUs a menudo se trata como una casilla de compra: elegir una potencia, marcar “redundante”, enviarlo. En sistemas de producción, ese enfoque falla por la misma
razón que “simplemente añadiremos más nodos” falla: ignora los límites duros que saltan primero.

La PSU es donde tu carga de trabajo se encuentra con la física. Los picos de carga se convierten en picos de corriente. El comportamiento del firmware se convierte en potencia de ventilador.
Una NIC nueva suma unos vatios que nunca presupuestaste. Y lo más humillante: cuando la energía actúa raro, los síntomas no siempre gritan “energía.”
Obtienes discos inestables, reinicios sorpresa, resets de NIC, sensores BMC corruptos o panics de kernel “aleatorios”. Los problemas de energía se disfrazan de problemas de software.

Quieres tres resultados:

• No más caídas causadas por disparos de disyuntores, sobrecarga de PSU o bajadas de tensión.
• No desperdicio por PSUs sobredimensionadas que funcionan de forma ineficiente a baja carga.
• Recuperación rápida cuando falla una PSU, una alimentación cae o un PDU te da lecturas erróneas.

Si tu método actual para dimensionar PSUs es “sumar TDPs y redondear hacia arriba”, estás ejecutando producción con esperanza. La esperanza no es una fuente de energía.

Hechos interesantes y un poco de historia (para que dejes de repetir viejos errores)

1. Las primeras fuentes de PC se centraban en cargas con mucho 5V. Los servidores modernos son en gran parte centrados en 12V, y la conversión DC-DC pasó a la placa.
2. ATX12V (principios de 2000) desplazó más potencia a 12V para alimentar CPUs, cambiando cómo importaban los “rails” y los límites de corriente en montajes reales.
3. 80 PLUS (mediados de 2000) convirtió la eficiencia en un elemento de marketing y compra, pero sus puntos de prueba no cubren tus cargas de trabajo con picos.
4. Los centros de datos migraron del pensamiento “una UPS grande” a UPS distribuidas y PDUs inteligentes, facilitando la medición—si realmente la usas.
5. Las PSUs redundantes se volvieron estándar no porque sean bonitas, sino porque intercambiar una PSU en caliente es mejor que una ventana de mantenimiento a las 2 a. m.
6. CPUs y GPUs modernas introdujeron comportamientos agresivos de boost; la potencia instantánea puede exceder el “TDP” de formas que los equipos de compras rara vez mencionan.
7. Las curvas de ventilador cambiaron el juego: ventiladores de alta presión estática pueden consumir potencia significativa a full, y las actualizaciones de firmware pueden alterar ese comportamiento de la noche a la mañana.
8. La densidad de rack explotó con la llegada de la virtualización y GPUs; la potencia y la refrigeración se convirtieron en las primeras limitaciones, no las unidades de rack.
9. La coordinación de disyuntores en las instalaciones evolucionó, pero los disyuntores siguen actuando más rápido que tu alerting a veces—especialmente con inrush.

Un modelo mental sensato: promedio, pico y los feos segundos intermedios

Los errores de dimensionamiento de PSU surgen de usar un número cuando necesitas al menos tres:

• Promedio en estado estable: lo que el servidor consume la mayor parte del tiempo.
• Pico sostenido: lo que consume durante trabajo real, no matemáticas sintéticas de “TDP”.
• Transitorio/irrupción: lo que consume durante el arranque, el giro simultáneo de discos, la subida de ventiladores o picos de boost de GPU.

Añade un cuarto si trabajas con redundancia:
modo de una sola PSU—porque en una configuración 1+1 aún necesitas sobrevivir con una sola PSU sin colapsar.

Qué significa realmente “potencia de la PSU”

Una PSU “1200W” normalmente está especificada para cierta tensión de entrada, temperatura, flujo de aire y a veces altitud. También implica una salida máxima DC bajo esas
condiciones. No significa que tu sistema pueda extraer de forma segura 1200W continuamente en cualquier rack, a cualquier temperatura, con cualquier alimentación, mientras los
pelusas de polvo hacen una red aislante dentro del chasis.

Una cita que debes tener en la pared

“La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan

No era un SRE, pero el sentimiento es dolorosamente relevante. En la planificación de energía, “probablemente no alcanzará picos” es esperanza, vestida de ingeniería.

Broma #1: Una PSU de servidor es como un paracaídas: si solo descubres que es insuficiente cuando la necesitas, vas a tener un mal día.

Qué medir (y qué no te dirán las hojas de especificaciones)

Las hojas de especificaciones están escritas para vender hardware, no para mantener tu clúster vivo. Aun así son útiles—pero solo como condiciones límite. Tu trabajo es
medir la realidad en tu entorno, con tu firmware y tu mezcla de cargas.

Mide en múltiples capas

• Potencia de entrada en pared / PDU: lo que pagas y lo que hace saltar disyuntores.
• Salida de la PSU (rara vez visible directamente): lo que el sistema consume en términos DC.
• Pistas a nivel de componentes: potencia del paquete CPU, potencia GPU, actividad de discos, RPM y PWM de ventiladores.

Conoce los límites que importan

• Circuito ramal (calificación del disyuntor; las prácticas de derating por carga continua varían por región y código).
• Límites de PDU y enchufe (C13/C14 vs C19/C20, calibre del cable, límites por toma).
• Clasificación por unidad de la PSU a tu tensión de entrada (obvia trampa: rendimiento y margen disponibles difieren entre 120V y 208/230V).
• Modo de redundancia (compartición de carga vs activo/standby; y si la plataforma puede sobrevivir con una PSU a plena carga).

No confundas estos términos

• TDP: un punto de diseño térmico, no un techo contractual de potencia.
• PL1/PL2 (y equivalentes de los proveedores): política de potencia sostenida vs boost; el firmware puede cambiarlos.
• Potencia aparente (VA) vs potencia real (W): los UPS y PDUs pueden reportar cualquiera; el factor de potencia importa cuando estás cerca de los límites.

Tareas prácticas de medición (comandos, salidas, decisiones)

No puedes “arquitectar” evitando la medición. A continuación hay tareas concretas y ejecutables. Cada una incluye: un comando, qué significa la salida y la decisión que soporta.
Úsalas para construir un perfil de potencia por modelo de servidor y por clase de carga.

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

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

Significado: El BMC piensa que el sistema está consumiendo ~312W ahora mismo (a menudo potencia de entrada, a veces calculada).
Decisión: Si esto está lejos de tu expectativa, valida la fuente BMC contra la medición del PDU antes de confiar en ella para planificación de capacidad.

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

Significado: Algunos proveedores exponen máximo/mínimo desde el arranque o reinicio.
Decisión: Si el máximo está cerca de los límites de la PSU o del circuito, no lo “promedies” y lo ignores. Planea para él o limita la potencia.

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

Significado: 225,000,000 µW = 225W límite sostenido del paquete (algo parecido a PL1) para ese dominio RAPL.
Decisión: Si tu dimensionamiento de PSU asumía “CPU de 165W”, pero el firmware permite 225W sostenidos, actualiza tu presupuesto o aplica un límite.

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

Significado: Aproximadamente 186W de media para ese paquete durante 10 segundos (energía en µJ dividida por 10s).
Decisión: Identifica cargas con CPU sostenida alta; son las que convierten “pico” en un evento frecuente.

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

Significado: La potencia real de la GPU es 126W, con un límite de 150W.
Decisión: Para servidores GPU, dimensionar PSUs sin telemetría real de potencia GPU es postureo. Si varias GPUs pueden alcanzar el límite simultáneamente, presupuestalo.

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

Significado: La frecuencia actual no está en boost; bajo carga puede dispararse e incrementar la potencia.
Decisión: Si ves frecuencia persistentemente baja bajo carga, puede que estés limitado por potencia o por temperatura—ambos vuelven al tema de PSU y refrigeración.

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

Significado: Hardware/firmware reportó throttling o errores que pueden estar relacionados con la entrega de potencia (no siempre, pero vale la pena correlacionarlo).
Decisión: Si esto se correlaciona con picos o reinicios, deja de depurar “inestabilidad aleatoria” e inspecciona las alimentaciones, PSUs y termales.

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

Significado: Ambas PSUs están activas y comparten la carga de forma aproximada.
Decisión: Si esperabas 1+1 con una inactiva y otra activa, puede que no estés en el modo de redundancia que crees. Actualiza tu modelo de fallo.

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

Significado: El OID del proveedor devuelve potencia de la salida en vatios (ejemplo: 356W). Las semánticas del MIB varían; confirma las unidades una vez y luego automatiza.
Decisión: Usa las lecturas del PDU como la verdad base para planificación de circuitos y riesgo de disyuntor. Las lecturas del BMC son “agradables de tener”, no tu contabilidad.

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

Significado: Corriente de la salida (ejemplo: 2.8A si el dispositivo usa deci-amperios; de nuevo, específico del proveedor).
Decisión: Convierte a amperios, compáralo con los límites del circuito y del PDU por toma. Si estás cerca, no añadas “solo un nodo más”.

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

Significado: Has creado una carga de CPU repetible. Combínala con lecturas simultáneas del PDU/BMC.
Decisión: Construye una línea base “pico solo CPU” por plataforma. Luego haz lo mismo con disco y red para ver picos combinados.

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

Significado: El almacenamiento está haciendo trabajo real. Las unidades y controladores consumen más bajo carga; los HDDs también tienen picos de spin-up.
Decisión: Si tu pico de potencia coincide con rebuilds/resyncs, presupuestado la “potencia en modo fallo”, no solo la potencia en camino feliz.

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

Significado: Los módulos de protección de caché pueden consumir potencia extra mientras cargan tras mantenimiento o inactividad prolongada.
Decisión: Si has tenido arranques en frío o mantenimiento, espera un aumento temporal de potencia. No lo trates como “vatios misteriosos”.

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

Significado: RPM altas implican mayor consumo de ventilador y a menudo indican estrés térmico o un cambio de perfil de firmware.
Decisión: Si ves velocidades altas sostenidas, investiga el flujo de aire y las temperaturas de entrada; tu presupuesto de potencia y las térmicas de la PSU ahora son peores.

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

Significado: Las PSUs ven 208V, lo que generalmente mejora la eficiencia y reduce la corriente para la misma potencia.
Decisión: Si estás en 120V y empujando densidad, considera moverte a alimentaciones de mayor tensión cuando sea factible. A menudo es la victoria de capacidad más sencilla.

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

Significado: Un contador tipo “pico de corriente desde el último reinicio” (ejemplo). El OID exacto depende del proveedor y modelo.
Decisión: Si el pico de corriente está muy por encima del estado estable, escalona arranques y evita encendidos sincronizados tras cortes.

PSUs redundantes: 1+1 no siempre es 1+1

Las PSUs redundantes se venden como confiabilidad. En la práctica, lo son solo si las dimensionas y alimentas correctamente.
Dos PSUs no garantizan que puedas funcionar a potencia completa tras la falla de una. Eso depende de:

• Capacidad por PSU frente al pico del sistema.
• Comportamiento de reparto de carga (activo/activo o activo/standby).
• Comportamiento de limitación de potencia cuando falta una PSU (algunos sistemas limitan automáticamente; otros simplemente se caen).
• Independencia de las alimentaciones (dos PSUs en la misma PDU no son redundancia; es optimismo con pasos extra).

Dimensionamiento N+1 en términos sencillos

Si tienes dos PSUs de 800W en una configuración 1+1, la pregunta relevante es:
¿Puede el servidor funcionar a pico con una sola PSU de 800W?
Si tu pico real medido es 780W en la pared y tu PSU se deratea a altas temperaturas de entrada, no estás “seguro”. Estás equilibrado en una delgada tecnicidad.

El reparto de carga no está garantizado

Si dos PSUs comparten mal (firmware, PSUs desajustadas, envejecimiento o cableado), una PSU puede trabajar más caliente y cerca del límite. Cuando falle, la otra recibe
una carga de paso que puede causar una segunda falla o un reinicio. Ese es el “doble golpe de PSU redundante”, y es tan divertido como suena.

Corriente de irrupción: al disyuntor no le importan tus hojas de cálculo

La irrupción es la sobretensión cuando aplicas alimentación—cargando condensadores, arrancando ventiladores, haciendo girar discos, despertando GPUs y dejando que cada regulador decida que es
hora de fiestear. Tu presupuesto de potencia en estado estable puede parecer correcto mientras la irrupción hace saltar el disyuntor durante un reinicio masivo.

A la gente de instalaciones le importa porque es la diferencia entre “energía restaurada” y “la mitad de la fila quedó a oscuras”. Debería importarte porque tras un evento en el centro de datos,
todos harán ciclos de energía al mismo tiempo, y tu orquestador podría ayudar amigablemente a hacer lo mismo.

Broma #2: Los disyuntores son como los ingenieros de guardia: toleran mucho, pero recuerdan exactamente una última paja.

Cómo reducir el riesgo por irrupción

• Escalonar arranques (PDUs, automatización fuera de banda o ganchos de orquestación).
• Evitar rampas de ventilador sincronizadas actualizando firmware en olas controladas, no “todo el viernes de la flota”.
• Conocer el comportamiento de los HDD: opciones de giro escalonado en HBAs pueden salvar tu disyuntor y tu orgullo.
• Medir corriente pico donde sea posible: algunos PDUs y UPS medidos registran picos y eventos de irrupción.

Derating: temperatura, altitud, polvo y por qué “1200W” a veces es fantasía

Las especificaciones de las PSUs asumen condiciones concretas. Luego instalas el servidor en un rack con tapones parciales, un pasillo caliente que es más una “sugerencia cálida”, y polvo
que convierte los disipadores en fieltro.

El derating aparece como:

• Menor salida disponible a mayor temperatura de entrada.
• Mayor potencia de ventilador (lo que aumenta el consumo del sistema y reduce la eficiencia).
• Apagado térmico anticipado o throttling protector.

La temperatura es un multiplicador de riesgo

Un servidor que “está bien” a 18°C de entrada puede volverse frágil a 30°C cuando falla una PSU y la PSU restante trabaja más caliente y ruidosa.
Ese es el peor momento para descubrir que tu suposición de redundancia se basaba en un folleto de laboratorio.

La altitud es real (sí, de verdad)

La altitud alta reduce la densidad del aire, disminuyendo la eficacia del enfriamiento. Muchos proveedores especifican derating por encima de ciertas elevaciones. Puedes ignorarlo si quieres,
pero la PSU no se convencerá por tu confianza.

Curvas de eficiencia: los vatios que no dibujas también te cuestan

La eficiencia no es constante. Es una curva. La mayoría de las PSUs rinden mejor alrededor del 40–60% de carga, dependiendo del diseño. A muy baja carga, la eficiencia cae,
y desperdicias potencia en calor. A muy alta carga, la eficiencia también puede caer y las térmicas se ponen feas.

Sobredimensionar por defecto parece “seguro”, pero puede desperdiciar dinero de tres maneras:

• Capex: los modelos de PSU más grandes cuestan más.
• Opex: menor eficiencia en idle a través de la flota no es lindo en la factura eléctrica.
• Refrigeración: los vatios desperdiciados se convierten en calor que tu instalación debe eliminar.

Qué hacer en lugar de sobredimensionar a ciegas

Mide tu pico real y elige una PSU tal que:

• Tu estado estable quede en la parte eficiente de la curva.
• Tu pico sostenido se mantenga por debajo de un umbral conservador (especialmente en modo N+1).
• Tu irrupción no haga saltar circuitos ramales durante eventos de flota.

Esto es menos glamuroso que comprar la unidad más grande disponible. También es cómo evitas pasar fines de semana en un pasillo frío con una linterna.

Tres mini-historias corporativas desde la tierra del “debería estar bien”

Mini-historia 1: El incidente causado por una suposición errónea

Una empresa desplegó una nueva tanda de servidores orientados a almacenamiento: muchos discos, controladores duales y PSUs “redundantes”. Compras dimensionó las PSUs sumando
TDP de CPU, RAM y “un poco por discos”. También estandarizaron una alimentación de 120V en una sala legacy porque “ya estaba ahí”.

Todo parecía bien en estado estable. Los racks estaban tranquilos, los gráficos de monitorización eran aburridos y el despliegue fue declarado un éxito. Entonces la instalación
realizó un mantenimiento planificado de energía. Tras restaurar la energía, toda la fila intentó arrancar a la vez. Varios disyuntores saltaron de inmediato. Un puñado de racks volvió
medio vivo: algunos servidores entraron en boot-loop, otros perdieron discos y un par de controladores arrancaron degradados.

La postmortem fue un desastre porque la primera ola de depuración fue contra software: versiones de kernel, orden de arranque, firmware de RAID. La pista fue que las fallas
se agruparon por rack y PDU, no por build del SO. Alguien finalmente sacó los logs de picos de corriente del PDU y los comparó con la calificación del circuito ramal.

La causa raíz no fue que los servidores consumieran “demasiada potencia” en promedio. Fue que la irrupción y el giro sincronizado de discos sobrepasaron la tolerancia del disyuntor
a 120V, donde la corriente es mayor para la misma potencia. Las “PSUs redundantes” no ayudaron porque la redundancia no evita que salte un disyuntor.

La solución fue aburrida: secuenciar arranques, habilitar giro escalonado en los HBAs y mover los racks de mayor densidad a alimentaciones de mayor tensión donde fue posible. También
empezaron a capturar picos de potencia en el PDU como parte de las pruebas de aceptación. El siguiente mantenimiento fue sin incidentes—que es el mejor tipo de evento.

Mini-historia 2: La optimización que salió mal

Otra organización se puso seria con la eficiencia y decidió “redimensionar” agresivamente. Notaron que sus servidores reposaban entre 120–160W y concluyeron que PSUs más pequeñas
mejorarían la eficiencia en idle. Impusieron una configuración estándar con PSUs de menor potencia para una nueva flota de cómputo.

Las pruebas de laboratorio se vieron bien. La eficiencia en idle mejoró ligeramente. Compras adoró la reducción de coste. La flota se desplegó en producción, donde la carga era con picos:
análisis por lotes mezclado con tráfico API explosivo. Durante los picos, el comportamiento de boost de la CPU impulsó potencia sostenida más alta de lo que nadie esperaba.
Seguía “dentro de la especificación” para una sola PSU—hasta que una PSU falló.

En redundancia 1+1, una sola PSU ahora tenía que llevar la carga completa. En papel, podía. En la práctica, con temperaturas de entrada más altas y condiciones más polvorientas que el
laboratorio, la PSU restante trabajó al rojo vivo. El firmware de la plataforma respondió con throttling de rendimiento. El servicio no cayó, pero la latencia pasó de “bien” a “por qué se está derritiendo la cola”.
Los SRE lo vieron como una regresión de software porque nada colapsó. Simplemente se volvió lento e impredecible.

Lo que salió mal no fue la idea de redimensionar. Fue hacerlo basándose en pruebas de idle e ignorar el modo de fallo N+1 más el derating ambiental. La solución fue aumentar la PSU
un paso, aplicar límites de potencia en los nodos más propensos a picos y dejar de usar solo la eficiencia en idle como métrica de éxito. La eficiencia importa. La previsibilidad importa más.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo con flota mixta (algunos equipos GPU, algunos nodos de almacenamiento, otros de cómputo) tenía una política simple: cada nuevo modelo de hardware debía pasar una lista de
verificación de “caracterización de potencia” antes de entrar en producción. Eso significaba medir idle, percentil 50 de carga, pico sostenido y la irrupción de arranque—usando el mismo
modelo de PDU que usaban en producción.

La lista también requería probar redundancia: quitar una PSU bajo carga y confirmar que el nodo se mantiene estable, registrando potencia y térmicas. No era opcional. No era “cuando tengamos tiempo”.
Era tan obligatorio como las pruebas de rebuild de RAID.

Un día, un proveedor entregó una “revisión menor” de un modelo de servidor. Misma familia SKU, misma hoja de marketing, diferente firmware y comportamiento de ventilador ligeramente distinto.
La caracterización detectó que la nueva revisión tenía una rampa de ventilador mucho más agresiva bajo ciertos umbrales de sensor, aumentando el pico de consumo lo suficiente para importar
cuando una PSU fallaba. El sistema se mantuvo en línea, pero el margen desapareció.

Como tenían datos de base, esto no se convirtió en incidente. Ajustaron la colocación en rack (menor densidad por circuito para esa revisión), afinó configuraciones de firmware donde fue posible
y actualizaron el presupuesto de potencia. Un mes después ocurrió una falla real de PSU en producción durante un trabajo pesado. El nodo se mantuvo en línea. Sin impacto al cliente. Sin heroísmos.
Simplemente la satisfacción silenciosa de la ingeniería aburrida funcionando como prometido.

Guía rápida de diagnóstico

Cuando algo huele a energía—reinicios aleatorios, fallas correlacionadas por rack, caídas de rendimiento tras la falla de una PSU—no divagues. Revisa en este orden.
El objetivo es encontrar el cuello de botella en minutos, no después de haber reescrito la mitad del scheduler.

Primero: confirma qué está fallando (nodo, rack, alimentación o sala)

• ¿Las fallas se agrupan por rack/PDU o por modelo de hardware?
• ¿Los eventos se correlacionan con tormentas de arranque, mantenimiento o picos de temperatura?
• ¿Ves saltos de disyuntores o alarmas del UPS?

Segundo: confía en el PDU/UPS para la potencia de entrada y luego coteja con BMC

• Revisa watts/amps por toma del PDU del rack y cualquier contador de picos.
• Compáralo con los vatios reportados por el BMC; grandes discrepancias sugieren sensores malos o puntos de medición distintos.
• Valida la tensión de entrada. Baja tensión significa más corriente para la misma carga y menos margen.

Tercero: prueba el comportamiento de redundancia bajo carga

• En condiciones controladas, quita una PSU y observa: ¿salta la potencia? ¿suben los ventiladores? ¿se estrangula el host?
• Confirma que cada PSU está en alimentaciones separadas y que las alimentaciones son verdaderamente independientes.
• Si el rendimiento cambia materialmente, trátalo como un riesgo de producción, no como un “gusto por saber”.

Cuarto: aisla causas transitorias

• Arranque e irrupción de discos: busca eventos de picos en disyuntores o PDU durante la restauración de energía.
• Cambios de firmware/curvas de ventilador: correlaciona con actualizaciones recientes.
• Picos de carga: correlaciona con telemetría de potencia CPU/GPU y la cronología de los incidentes.

Errores comunes (síntoma → causa raíz → solución)

1) Reinicios aleatorios bajo carga

Síntoma: Hosts se reinician cuando empiezan jobs por lotes o sube la utilización de GPU.
Causa raíz: Sobrecarga de PSU o problemas de respuesta transitoria; a veces una PSU individual está débil/envejecida y colapsa con cargas de paso.
Solución: Mide en el PDU durante la carga. Prueba con una PSU retirada. Reemplaza la PSU sospechosa. Si los picos son legítimos, aumenta la capacidad de PSU o limita la potencia.

2) Saltos de disyuntor tras mantenimiento o restauración de energía

Síntoma: Racks enteros quedan a oscuras, los disyuntores saltan justo cuando todo se enciende.
Causa raíz: Corriente de irrupción más arranque sincronizado; el giro de HDDs y la rampa de ventiladores lo amplifican, especialmente a 120V.
Solución: Escalonar arranques. Habilitar giro escalonado. Reducir densidad por circuito o moverse a alimentaciones de mayor tensión.

3) “Redundante” pero la falla de una PSU colapsa el rendimiento

Síntoma: Sin caída total, pero la latencia se dispara y el rendimiento cae cuando una PSU muere.
Causa raíz: El modo de una sola PSU activa limitación de potencia o estrés térmico; la PSU restante se calienta y el firmware estrangula CPU/GPU.
Solución: Dimensiona para que una sola PSU pueda manejar el pico sostenido con margen a la peor temperatura de entrada. Prueba y documenta el rendimiento en modo fallo.

4) PDU muestra watts altos, BMC muestra watts bajos (o viceversa)

Síntoma: Dos números “autoritativos” difieren entre 20–40%.
Causa raíz: Puntos de medición distintos (entrada vs calculado), deriva de calibración de sensores o bugs de firmware BMC.
Solución: Trata la entrada del PDU/UPS como la verdad para facturación y disyuntores. Usa BMC para tendencias relativas. Calibra una vez con un medidor conocido si hace falta.

5) Firmware nuevo causa sobrepaso del presupuesto de potencia

Síntoma: Tras una actualización de BIOS/BMC, la potencia del rack sube o la potencia de ventilador salta; aparecen alarmas de disyuntores o UPS.
Causa raíz: Curvas de ventilador actualizadas, límites de boost más altos o perfiles de potencia por defecto distintos.
Solución: Re-caracteriza la potencia tras cambios de firmware. Bloquea perfiles de potencia. Rueda actualizaciones en olas con monitorización de PDU.

6) “Dimensionamos por TDP” y ahora todo está justo

Síntoma: Las cuentas de placa dicen que estás seguro; las mediciones reales dicen que no.
Causa raíz: TDP no es un límite; los overhead de la plataforma, memoria, discos, NICs, ventiladores y comportamiento boost no estaban incluidos.
Solución: Construye un modelo de potencia medido por plataforma: idle, típico, pico sostenido, irrupción y modo N+1. Deja de usar sumas de TDP como respuesta final.

Listas de verificación / plan paso a paso

Paso a paso: cómo dimensionar una PSU para un modelo de servidor (sin adivinar)

1. Establece la fuente de verdad de medición. Usa watts de entrada medidos en PDU/UPS para planificación de capacidad; usa BMC para tendencias y estado de redundancia.
2. Registra condiciones de entrada. Anota tensión de entrada y temperatura aproximada de entrada durante las pruebas. Los datos de potencia sin condiciones son chismes.
3. Mide cuatro puntos de potencia:
   • Idle (post-arranque, servicios estables)
   • Carga típica (mezcla representativa de producción)
   • Pico sostenido (stress test que coincida con cuellos reales)
   • Pico de arranque/irrupción (arranque en frío, no reinicio en caliente)
4. Prueba comportamiento N+1. Bajo carga, quita una PSU y observa estabilidad, throttling y comportamiento de ventiladores. Registra potencia y térmicas.
5. Aplica margen intencionalmente. Añade margen por error de sensor, deriva ambiental, envejecimiento y “firmware sorpresa.” Evita el reflejo de duplicar todo.
6. Valida contra el circuito. Convierte vatios a amperios a tu tensión y asegúrate de no coquetear con los límites ramales bajo picos e irrupción.
7. Decide tamaño de PSU y redundancia. Elige un modelo de PSU donde el modo de una sola PSU se mantenga estable al pico sostenido, con margen real.
8. Documenta el perfil. Guarda valores medidos y condiciones de prueba en tu runbook de hardware para que la siguiente persona no haga arqueología.
9. Operacionaliza la monitorización. Alerta por aumentos inusuales, pero también por pérdida de redundancia y cambios inesperados en reparto de carga.
10. Re-testea después de cambios relevantes. BIOS/BMC, nuevas NICs/HBAs, cambios de modelo GPU o cambios de carga merecen una re-medición.

Lista de verificación: presupuesto de potencia por rack que puedas defender en una reunión

• Por rack: típico medido y pico medido, no solo suma de placas de características.
• Por circuito: amperaje a la tensión real, con suposición clara sobre utilización continua permitida.
• Plan de irrupción: procedimiento de escalonado de arranque documentado y probado.
• Plan de redundancia: PSUs en alimentaciones separadas; PDUs en upstreams separados cuando sea posible.
• Pruebas de aceptación: cada nuevo modelo de hardware pasa una caracterización de potencia antes del despliegue.

Lista de verificación: edición “estamos a punto de añadir GPUs”

• Mide límite de potencia por GPU y confirma el sobreenvolvente total de potencia de la plataforma.
• Confirma límites de alimentación auxiliar PCIe y de risers; no asumas que el cableado del chasis coincide con el marketing de la GPU.
• Prueba pico combinado CPU+GPU bajo cargas reales (no solo sintéticas).
• Confirma comportamiento de redundancia cuando se retire una PSU durante carga GPU.
• Valida circuito de rack y tipo de toma PDU (C13 vs C19) y límites por toma.

Preguntas frecuentes

1) ¿Puedo dimensionar una PSU sumando TDP de componentes?

Usa sumas de TDP solo como un límite inferior aproximado. Los sistemas reales lo superan por comportamiento de boost, potencia de ventiladores, carga de controladores y picos transitorios.
Mide en el PDU.

2) ¿Siempre debo comprar la opción de PSU de mayor potencia?

No. Sobredimensionar puede desperdiciar dinero y reducir la eficiencia a baja carga. Compra para el pico sostenido medido más margen, y asegúrate de que el modo de una sola PSU sea seguro si usas redundancia.

3) ¿Qué margen debería añadir?

No hay un número universal. Añade margen por error de medición, cambios ambientales, envejecimiento y futuras adiciones. El margen correcto es el que sobrevive al modo N+1 a la peor temperatura de entrada sin throttling ni inestabilidad.

4) ¿Qué es más confiable: vatios del BMC o vatios del PDU?

Para planificación de disyuntores y capacidad: vatios de entrada del PDU/UPS. Para tendencias por host y estado de redundancia: el BMC es útil. Si discrepan, investiga, pero presupuestea según el PDU.

5) ¿Por qué salta el consumo tras una actualización de BIOS/BMC?

El firmware puede cambiar límites de potencia de CPU, curvas de ventilador, comportamiento de entrenamiento de memoria y valores por defecto de gestión de periféricos. Trata las actualizaciones de firmware como un cambio de hardware: vuelve a medir la potencia.

6) ¿Cómo afectan las PSUs redundantes a la eficiencia?

Con reparto de carga, cada PSU funciona a un porcentaje menor, lo que puede sacarte del punto óptimo de eficiencia. Con activo/standby, una PSU puede estar cerca del punto óptimo mientras la otra consume energía en standby. Mide, no asumas.

7) ¿Qué pasa con VA vs W al dimensionar UPS y circuitos?

W es potencia real; VA es potencia aparente. Los UPS y PDUs pueden cotizar cualquiera. Si el factor de potencia no está cerca de 1.0, VA puede ser significativamente mayor que W, y eso puede ser el factor limitante para la capacidad del UPS incluso cuando los vatios parecen estar bien.

8) ¿Cómo prevengo saltos de disyuntores durante reinicios de flota?

Escalonar arranques, habilitar giro escalonado de discos cuando aplique y evitar comportamientos orquestados de “todos los nodos arriba ahora”. Confirma con logs de picos del PDU y haz una prueba controlada.

9) ¿Necesito preocuparme por los límites de rail de la PSU todavía?

Menos que en el viejo drama de múltiples rails de desktop, pero aún sí en ciertas plataformas. Las PSUs de servidor y los backplanes suelen abstraer esto, pero una alta densidad de GPU y la distribución de potencia en risers pueden exponer límites ocultos.
Si ves inestabilidad bajo carga GPU, verifica la distribución de potencia de la plataforma, no solo los vatios totales.

10) ¿Cuál es una forma práctica de limitar potencia en servidores para mantenerte dentro de los límites?

Usa herramientas del proveedor o perfiles de firmware cuando sea posible y valida con mediciones del PDU. Para CPUs, los límites basados en RAPL pueden ayudar, pero confirma el comportamiento con tu carga—algunas cargas intercambian latencia por vatios de forma desagradable.

Siguientes pasos que puedes hacer esta semana

• Elige un modelo de servidor y crea un perfil de potencia: idle, típico, pico sostenido, arranque/irrupción y resultados de prueba N+1.
• Haz del PDU tu fuente de verdad para potencia de entrada y picos; conecta sondeos SNMP a tu canal de métricas.
• Realiza una prueba controlada de redundancia: bajo carga relevante, quita una PSU y observa throttling, subida de ventiladores y saltos de potencia.
• Escribe un procedimiento de arranque escalonado y practícalo. Tras un corte no es momento de descubrir que tu herramienta no puede secuenciar.
• Actualiza tu especificación de compra: exige PSUs/PDU medidos y sensores BMC cuando sea posible, y pide a los proveedores que declaren el comportamiento en modo una sola PSU.
• Vuelve a comprobar tras actualizaciones de firmware. Trata a “revisión menor” de hardware como nuevo hasta que la hayas medido.

El objetivo no es convertirte en ingeniero de potencia. Es dejar de tratar a los vatios como folklore. Mide, presupuestea, prueba modos de fallo y avanza a los problemas que realmente son interesantes—como por qué tu ventana de rebuild de almacenamiento sigue siendo demasiado larga.