Servidores en armarios calientes: cómo la “sin ventilación” mata la disponibilidad

Por qué los armarios calientes matan la disponibilidad (y por qué es sigiloso)

“Sin ventilación” rara vez es literal. La mayoría de los armarios tienen algún intercambio de aire: una rendija en la puerta, una placa del techo que no encaja bien,
una devolución de HVAC en algún punto del edificio. El problema es que los armarios están diseñados para escobas, no para kilovatios.
No puedes verter 2–8 kW de calor continuo en un volumen pequeño y esperar que el “aire acondicionado del edificio” lo absorba sin más.

El patrón de fallo es predecible:
el calor sube, el aire de entrada se calienta, los ventiladores suben revoluciones, el polvo se mueve, la presión estática aumenta, comienza la recirculación,
las CPU se estrangulan, los discos se calientan, las fuentes de alimentación se degradan y entonces algo salta. A veces obtienes un apagado térmico limpio.
Más a menudo obtienes timeouts, errores CRC, enlaces que se caen y corrupción de datos que solo aparece después como “bugs de aplicación”.

La otra razón por la que los armarios calientes son sigilosos: la gente mide la temperatura equivocada. Revisan el termostato del pasillo.
O apuntan un termómetro IR a la puerta del rack. El aire que importa es el aire en la entrada de los dispositivos más calientes,
bajo carga, durante la peor parte del día, con la puerta cerrada tal como está en la operación normal.

Una verdad incómoda más: los armarios invitan a “una cosa más”. Un rack pequeño se convierte en un vertedero para cajas NAS,
UPS, switches PoE, un KVM y ese 1U viejo que nadie quiere retirar. El presupuesto térmico no comparte tu optimismo.

Chiste corto #1: Un armario de servidores sin ventilación es solo una olla lenta con luces intermitentes.

El impacto en la disponibilidad no es lineal

El calor no degrada la fiabilidad suavemente. Empuja componentes a regímenes donde las tasas de error se disparan.
El sistema puede parecer mayormente bien—hasta que no lo está. Eso es lo que hace que los problemas térmicos sean tan caros: generan
“incógnitas desconocidas” y líneas temporales largas de incidentes, porque cada equipo puede encontrar un culpable plausible en su propia capa.

El indicador más fiable en producción no es la temperatura absoluta; es la combinación de:
aumento de RPM de ventiladores, incremento de errores corregibles, contadores de throttling y un cambio en la latencia base.
Ese conjunto de señales es la firma del calor.

Hechos y contexto histórico: por qué seguimos repitiendo esto

• Las primeras “salas de computación” se construyeron pensando primero en la refrigeración. Los mainframes de los años 60–70 impulsaron diseños HVAC dedicados; la gestión del calor era parte de la arquitectura, no una ocurrencia tardía.
• ASHRAE amplió con el tiempo los rangos recomendados de temperatura de entrada. El hardware moderno a menudo tolera aire más cálido, pero “tolerar” no es “operar con bajas tasas de error”.
• El pasillo frío/pasillo caliente se generalizó en los 90. No fue una moda; fue una respuesta al aumento de densidad por rack y a los problemas de recirculación.
• El control de velocidad de los ventiladores se hizo más inteligente—y más ruidoso. Los servidores modernos pueden subir los ventiladores agresivamente para sobrevivir en entornos pobres, lo que enmascara la causa raíz mientras aumenta el consumo y atrae más polvo.
• La densidad de potencia explotó más rápido que las reformas de los edificios. Muchos “armarios IT” se diseñaron cuando unas pocas centenas de vatios eran lo normal; hoy, un solo 2U puede superar eso.
• Los discos empresariales empezaron a reportar temperatura y telemetría de errores hace años. Los atributos S.M.A.R.T. son lo más parecido a una confesión que obtendrás de un disco antes de que falle.
• El equipo de red funciona a altas temperaturas por diseño. Los ASICs de switches y las etapas de PoE generan calor serio; los armarios los hacen perder enlaces mucho antes de morir por completo.
• Las baterías de los UPS son sensibles al calor. La vida útil de las baterías de plomo-ácido cae drásticamente a temperaturas elevadas, convirtiendo la “protección de energía” en una “sorpresa de corte futuro”.

El tema recurrente: la industria resolvió este problema en centros de datos hace décadas, y luego olvidó la lección
en cuanto alguien etiquetó un armario como “MDF” y le puso un candado.

Una cita que vale la pena colgar en la pared, porque aplica dolorosamente bien a fallos térmicos:
“La esperanza no es una estrategia.” — General Gordon R. Sullivan

La física que realmente necesitas: calor, flujo de aire y presión

Carga térmica: el armario es una batería que estás cargando

Los servidores convierten casi toda la energía eléctrica en calor. Si tu rack consume 3 kW, estás añadiendo aproximadamente 3 kW de calor de forma continua.
En una sala pequeña con intercambio de aire pobre, la temperatura sube hasta que el calor saliente iguala al entrante. “Salir” es el problema.

El armario no necesita estar sellado para ser malo. Si el aire se intercambia lentamente—digamos, por una puerta con fugas—el aire caliente se estratifica cerca del techo,
las entradas de los equipos absorben ese aire más cálido y obtienes una fuga térmica local en la parte superior del rack.

Dirección del flujo: front-to-back solo funciona si el aire frontal se mantiene frío

Casi todos los servidores modernos de rack están diseñados para flujo de aire frontal a posterior. Ese diseño asume:

• El aire frío está disponible en las entradas frontales.
• El escape caliente puede salir por la parte trasera sin volver a entrar.
• La presión estática no es tan alta que los ventiladores no puedan mover el caudal nominal.

Un armario rompe los tres con entusiasmo. La gente coloca racks de lado, bloquea la parte trasera con cajas o empuja el rack contra una pared.
Luego cierra la puerta “por seguridad”. Felicidades, has construido una cámara de recirculación.

Presión e impedancia: por qué “solo agrega un ventilador” falla a menudo

El flujo de aire no es magia; es flujo a través de una red de impedancias. Filtros, racimos de cables, puertas perforadas y ventiladores mal colocados
aumentan la resistencia. Los ventiladores de servidores pueden superar cierta presión estática, pero están diseñados para rutas de rack previsibles,
no para tirar aire a través de una grieta del armario bajo presión negativa.

Los ventiladores de extracción del armario también pueden volverse en tu contra creando presión negativa que jala aire caliente desde falsos techos y cavidades de pared,
o dejando sin aire acondicionado las salas adyacentes. Necesitas un camino deliberado de suministro y retorno, no una turbina cualquiera atornillada al tabique.

Punto de rocío y condensación: el fallo que no ves venir

Los problemas de calor a veces vienen con reparaciones equivocadas: “Vamos a meter aire más frío.” Si ese aire está por debajo del punto de rocío,
puedes condensar humedad en superficies metálicas. Es menos común en edificios de oficinas típicos, pero ocurre cuando se usan mal unidades de aire portátil
o se introduce aire exterior sin control de humedad.

Qué falla primero: modos reales de fallo por componente

CPU y memoria: throttling, luego reintentos, luego colapso

Las CPU se protegen con thermal throttling. Eso suena seguro hasta que entiendes lo que hace a cargas sensibles a la latencia:
el sistema permanece “activo” pero se vuelve impredeciblemente lento. Si ejecutas servicios de almacenamiento, el throttling puede encadenarse en
presión de write-back, colas de IO más largas y timeouts que parecen problemas de red.

Los controladores de memoria y los DIMM también pueden tener más errores a altas temperaturas. Muchos sistemas corrigen errores silenciosamente (ECC),
lo que puede hacer que un problema térmico parezca “ruido de rendimiento aleatorio” hasta que los contadores ECC se disparan o un DIMM se retira.

Almacenamiento: el calor convierte “bien” en “¿por qué se está reconstruyendo el RAID?”

A los discos no les gusta el calor. Eso no es superstición; es física más tolerancias. A temperaturas más altas:
los lubricantes se comportan distinto, la expansión cambia los claros y la electrónica trabaja más cerca de sus límites.
Ves más reintentos de lectura, más timeouts y a veces un aumento de UDMA CRC errors por cableado marginal que se vuelve sensible a medida que todo se calienta.

Las SSD añaden otra variable: pueden throttlear mucho cuando los controladores se calientan. Eso crea picos de latencia que son brutales
para bases de datos y plataformas de virtualización. Los discos no fallarán de inmediato; simplemente harán que tu “almacenamiento rápido”
se comporte como si estuviera replanteándose su vida.

Equipo de red: enlaces que se caen y rarezas con PoE

Los switches en armarios suelen morir por muerte de mil cortes: alta temperatura ambiente, ventilaciones bloqueadas y carga PoE.
El sobrecalentamiento puede causar:

• Link flaps (puertos que rebotan) debido a estrés térmico o protecciones internas.
• Pérdida de paquetes cuando buffers y ASICs se comportan mal bajo restricciones térmicas.
• Cambios en la asignación de potencia PoE, causando reinicios de cámaras y APs.

Fuentes de alimentación y UPS: degradación y decaimiento de baterías

Las fuentes de alimentación están calificadas bajo condiciones térmicas específicas. En armarios calientes, las PSU trabajan más calientes, los ventiladores giran más rápido
y el envejecimiento de componentes se acelera. Cuando una PSU falla en un par redundante, rara vez es “solo una PSU”. Es una advertencia
de que ambas unidades han estado horneándose.

Las baterías del UPS son las víctimas silenciosas. La temperatura ambiente elevada acorta dramáticamente la vida útil de la batería, lo que significa que
el siguiente bache de la red eléctrica se convierte en un corte porque el UPS no puede mantener la carga. No lo sabrás hasta que pruebes,
y la mayoría no lo hace.

Factores humanos: la puerta es un cambio

En un armario en el límite, “puerta abierta” es una configuración. La gente la deja abierta durante el día, la cierra por la noche
por seguridad, y obtienes eventos térmicos nocturnos que parecen problemas de trabajos programados.
Trata el estado de la puerta como parte del sistema.

Chiste corto #2: Lo único que escala más rápido que tu cómputo es la cantidad de cajas de cartón que bloquean el escape del rack.

Guion de diagnóstico rápido

Este es el orden de operaciones de “deja de debatir y encuentra el cuello de botella”. El objetivo no es mediciones perfectas.
El objetivo es identificar si estás en un incidente térmico y qué capa recibe el primer impacto.

Primero: confirma estrés térmico, no solo un mal día

1. Busca rampa de ventiladores y logs térmicos en los hosts más calientes. El comportamiento de los ventiladores es una canaria.
2. Revisa la frecuencia de CPU y los indicadores de throttling. Si los relojes están bajos bajo carga, no estás en “capacidad”, estás en “supervivencia”.
3. Revisa temperaturas de discos y contadores de errores. Las fallas de almacenamiento por calor pueden imitar cualquier otra cosa.

Segundo: identifica el modo de fallo de flujo de aire

1. Mide delta entrada vs salida (incluso con sensores rudimentarios). Entrada alta significa que la sala está caliente; delta alto significa que hay flujo pero la sala puede estar hambrienta.
2. Revisa recirculación: escape caliente que entra a las entradas por sellado deficiente o salidas bloqueadas.
3. Revisa presión estática / obstrucción: filtros obstruidos, ventilaciones bloqueadas, cortinas de cables.

Tercero: cuantifica riesgo y elige la mitigación menos mala

1. Reduce carga (mueve trabajos, limita CPU, pausa reconstrucciones) si necesitas detener la hemorragia.
2. Restaura la ruta de flujo (puerta abierta temporalmente, quita obstrucciones, reposiciona ventiladores portátiles correctamente).
3. Planifica la solución real: refrigeración dedicada, ventilación, contención, monitorización y disciplina operativa.

Si haces estas nueve comprobaciones y aún no sabes, o no estás en un problema térmico—o el armario es tan malo que todo falla a la vez.
Ambos resultados justifican tomarse en serio la monitorización ambiental.

Tareas prácticas con comandos: pruébalo, no lo intuyas

A continuación hay tareas prácticas que puedes ejecutar durante un incidente o como parte de una validación rutinaria. Cada una incluye un comando,
salida de ejemplo, lo que significa y qué decisión tomar.

Tarea 1: Comprobar sensores de temperatura de CPU (Linux)

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

Qué significa: Estás cerca del “alto” y no lejos de los umbrales de throttling/apagado.

Decisión: Reduce la carga inmediatamente y verifica el flujo de aire. No inicies mantenimiento que aumente IO/CPU (backups, scrub, rebuilds).

Tarea 2: Confirmar throttling de CPU / frecuencia reducida

cr0x@server:~$ lscpu | egrep 'Model name|CPU MHz'
Model name:                           Intel(R) Xeon(R) CPU
CPU MHz:                              1198.734

Qué significa: Bajo carga, muchos servidores deberían funcionar muy por encima de ~1.2 GHz. Esto sugiere throttling térmico o cap de potencia.

Decisión: Correlaciona con temperatura y políticas de potencia. Si es térmico, trátalo como incidente de refrigeración; si es cap de potencia, inspecciona BIOS/políticas iDRAC.

Tarea 3: Revisar logs del kernel por eventos térmicos

cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i 'thermal|thrott|overheat|temperature' | tail -n 20
Feb 02 10:41:12 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Feb 02 10:41:12 server kernel: CPU0: Package temperature above threshold, cpu clock throttled
Feb 02 10:52:40 server kernel: mce: [Hardware Error]: Machine check events logged

Qué significa: El SO está reportando throttling térmico y posiblemente errores de hardware inducidos por calor.

Decisión: Deja de perseguir bugs de aplicación. Estás en territorio de hardware/entorno. Mitiga el calor primero.

Tarea 4: Observar velocidades de ventiladores (IPMI)

cr0x@server:~$ sudo ipmitool sdr type fan
FAN1             | 16800 RPM        | ok
FAN2             | 17200 RPM        | ok
FAN3             | 16950 RPM        | ok

Qué significa: Los ventiladores están cerca del máximo. El hardware está luchando contra el entorno.

Decisión: Si los ventiladores están al máximo y las temperaturas siguen altas, el suministro/retorno de aire es insuficiente. Necesitas soluciones a nivel de sala, no “más ventilador”.

Tarea 5: Comprobar sensores de PSU y temperatura de entrada (IPMI)

cr0x@server:~$ sudo ipmitool sensor | egrep -i 'inlet|ambient|psu'
Inlet Temp       | 36 degrees C     | ok
Ambient Temp     | 38 degrees C     | ok
PSU1 Temp        | 63 degrees C     | ok
PSU2 Temp        | 65 degrees C     | ok

Qué significa: La entrada ya está caliente. Las temperaturas de PSU están elevadas.

Decisión: Trata la temperatura de entrada como tu KPI primario. Si la entrada está >30–32°C de forma sostenida, planifica remediación, no heroísmos.

Tarea 6: Comprobar temperatura NVMe y flags de throttling

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep -i 'temperature|warning|critical'
temperature                             : 79 C
warning_temp_time                       : 124
critical_comp_time                      : 0

Qué significa: La unidad ha pasado tiempo por encima de la temperatura de advertencia. Probablemente ocurrió throttling.

Decisión: Mueve cargas intensivas de escritura fuera del host hasta que se arregle la refrigeración. Considera añadir disipadores o guías de flujo si el proveedor lo soporta.

Tarea 7: Comprobar temperaturas y historial de errores de discos SATA/SAS

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'temperature|reallocated|pending|crc'
194 Temperature_Celsius     0x0022   060   045   000    Old_age   Always       -       40
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       12

Qué significa: 40°C es aceptable para muchos discos, pero los CRC errors indican problemas de enlace (cableado/backplane), que pueden empeorar con calor/vibración.

Decisión: Inspecciona/respeta cables y conexiones del backplane en una ventana de mantenimiento. Si las temperaturas superan rutinariamente mediados de 40°C, arregla el flujo de aire primero.

Tarea 8: Vigilar latencia IO y colas (iostat)

cr0x@server:~$ iostat -xz 1 5
avg-cpu:  %user %system %iowait  %idle
          18.2    6.1    22.7   52.3

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              12.0   180.0   512.0  8192.0  48.2   3.1   98.7

Qué significa: Alto await con utilización cercana al 100% sugiere que el almacenamiento está saturado o luchando. Bajo calor, el throttling de SSD/HDD puede provocar esto.

Decisión: Difere operaciones intensivas de IO (scrubs, rebuilds, backups) y verifica temperaturas/throttling de discos. Si el calor es la causa raíz, la solución es refrigeración.

Tarea 9: Revisar estado de pool ZFS y contadores de errores (si aplica)

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Replace the device or clear the errors if the device is otherwise healthy.
  scan: scrub repaired 0B in 02:13:44 with 0 errors on Sun Feb  2 07:00:11 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     2
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-104-disk-0

Qué significa: Los errores de checksum pueden ser por disco, cableado o controlador. El calor puede empujar componentes marginales por encima del límite.

Decisión: Trátalo como riesgo de datos. Estabiliza la temperatura, luego reemplaza/inspecciona el dispositivo sospechoso y verifica cableado/backplane. No “limpies y reces”.

Tarea 10: Revisar errores NIC y estabilidad de enlace (ethtool)

cr0x@server:~$ sudo ethtool -S eno1 | egrep -i 'err|drop|crc' | head
rx_crc_errors: 41
rx_errors: 41
rx_dropped: 0
tx_errors: 0

Qué significa: Los CRC errors indican problemas de capa física: cableado, óptica, transceptores o hardware sobrecalentado.

Decisión: Revisa también errores en el switch. Si los errores aumentan cuando el armario está más caliente, sospecha estrés térmico en NIC/switch/óptica.

Tarea 11: Revisar logs del switch por alarmas térmicas (ejemplo genérico NOS basado en Linux)

cr0x@server:~$ ssh admin@switch01 'show logging | include -i temp'
%PLATFORM-1-TEMP_WARNING: Temperature warning detected on sensor 2
%PLATFORM-2-FAN_SPEED: Fan speed increased to 95%

Qué significa: El switch advierte explícitamente sobre temperatura y compensa subiendo la velocidad de ventiladores.

Decisión: Prioriza la refrigeración. Los switches a menudo fallan “suavemente” (caídas/flaps) antes de fallar “duro”, lo que hace los cortes desordenados.

Tarea 12: Verificar estado del UPS y temperatura interna (ejemplo NUT)

cr0x@server:~$ upsc ups@localhost | egrep -i 'ups.temperature|battery.charge|battery.runtime|ups.load'
battery.charge: 97
battery.runtime: 820
ups.load: 41
ups.temperature: 39.2

Qué significa: La temperatura interna del UPS está elevada. Es un impuesto diario a la vida de la batería.

Decisión: Si la temp del UPS es rutinariamente alta, muévelo a aire más frío o mejora la ventilación. Programa una prueba de baterías y acorta los intervalos de reemplazo preventivo.

Tarea 13: Comprobar temperatura de la sala desde un sensor externo (ejemplo Prometheus node_exporter)

cr0x@server:~$ curl -s localhost:9100/metrics | egrep 'node_hwmon_temp_celsius' | head
node_hwmon_temp_celsius{chip="platform_coretemp_0",sensor="temp1"} 92
node_hwmon_temp_celsius{chip="platform_coretemp_0",sensor="temp2"} 90

Qué significa: Puedes exportar y alertar sobre métricas térmicas. Si no alertas, estás eligiendo sorpresas.

Decisión: Añade umbrales de alerta y alertas por tasa de cambio (subir rápido es más accionable que un número absoluto).

Tarea 14: Medir consumo en el host (aproximado pero útil)

cr0x@server:~$ sudo ipmitool dcmi power reading
Instantaneous power reading:                   412 Watts
Minimum during sampling period:                385 Watts
Maximum during sampling period:                498 Watts
Average power reading over sample period:      431 Watts

Qué significa: Los vatios de entrada equivalen a calor de salida. Suma esto entre hosts para estimar la carga térmica del armario.

Decisión: Si no conoces tus vatios, no conoces tu requisito de refrigeración. Usa esto para justificar gasto en ventilación/refrigeración con números reales.

Tarea 15: Confirmar que “puerta abierta” cambia el sistema (experimento controlado)

cr0x@server:~$ for i in {1..5}; do date; sensors | egrep 'Package id 0'; sleep 60; done
Mon Feb  2 11:00:00 UTC 2026
Package id 0: 90.0°C  (high = 100.0°C, crit = 105.0°C)
Mon Feb  2 11:01:00 UTC 2026
Package id 0: 88.0°C  (high = 100.0°C, crit = 105.0°C)
Mon Feb  2 11:02:00 UTC 2026
Package id 0: 86.0°C  (high = 100.0°C, crit = 105.0°C)

Qué significa: Si abrir la puerta baja las temperaturas rápidamente, el armario tiene ventilación/retorno insuficiente.

Decisión: Trata la puerta como una mitigación de emergencia solamente. Construye un camino permanente de suministro/retorno para que la seguridad no luche con la disponibilidad.

Tres microhistorias corporativas desde las trincheras térmicas

Microhistoria #1: El incidente causado por una suposición equivocada

Una compañía mediana se mudó de oficinas y hizo lo que muchos hacen: mantuvieron el “core” on-prem porque el plan de migración era “más tarde.”
El nuevo espacio tenía un armario de red limpio, con cerradura, un rack brillante y un lector de tarjetas. Todos se sintieron responsables.
La responsabilidad es una estética fuerte.

La suposición equivocada fue simple: el HVAC del edificio se encargará. El armario tenía un conducto de suministro pero no retorno,
y el sello de la puerta era apretado. La primera semana pareció bien. Luego llegó el primer día cálido, y el armario se convirtió en
una trampa de calor. El primer síntoma no fueron alarmas de temperatura—no había—sino un clúster de almacenamiento que empezó a tener timeouts.

Operaciones persiguió firmware de almacenamiento. Luego cableado. Luego el hipervisor. Luego el equipo de aplicaciones, que valientemente propuso aumentar los timeouts,
que es el equivalente en TI a subir el volumen de la radio para ignorar el ruido del motor. Mientras tanto, los ventiladores chillaban y la latencia de SSD se disparaba.

Finalmente alguien notó un patrón: los incidentes se concentraban después de las 14:00. El edificio miraba al oeste; el sol de la tarde calentaba la pared exterior;
la temperatura del armario subía; y los nodos de almacenamiento se throttlearon. La solución no fue exótica: añadir un retorno adecuado y monitorización continua,
además de una regla que prohíbe cerrar la puerta del armario durante la carga pico hasta que se instale ventilación.

La lección duradera no fue “el HVAC importa.” Fue: no aceptes “se siente lo suficientemente frío” como validación.
Si no puedes medir temperaturas de entrada y comportamiento de ventiladores, estás adivinando—y las conjeturas son caras.

Microhistoria #2: La optimización que salió mal

Otra organización tenía un armario que funcionaba caliente pero “dentro de especificación.” Alguien propuso una optimización energética: subir puntos de consigna,
reducir velocidades del aire acondicionado portátil en la sala y confiar en los ventiladores del servidor para hacer el trabajo. En teoría, redujo ruido y ahorró energía.
En la práctica, trasladó el impuesto térmico a otro lugar.

El aire acondicionado portátil del armario era de una sola manguera que expulsaba aire fuera de la sala, creando presión negativa.
La presión negativa jalaba aire cálido del plenum del techo y del pasillo adyacente. El sensor de temperatura de la sala, colocado cerca de la puerta,
se veía bien. La entrada superior del rack, naturalmente, no.

El incidente comenzó como pérdida de paquetes intermitente. Las culpas rebotaron: firewall, ISP, firmware del switch.
Un ingeniero senior finalmente revisó los logs del switch y vio advertencias térmicas. El switch no fallaba al azar; se estaba protegiendo.
Fue entonces cuando midieron la temperatura de entrada en la parte superior del rack y encontraron que era considerablemente más caliente que la “ambiente de la sala.”

Revertir la “optimización” detuvo la hemorragia, pero el postmortem fue el verdadero valor: habían optimizado para la métrica
más fácil de medir (temperatura de sala cerca de la puerta) en lugar de la métrica que importaba (entrada del dispositivo).
Movieron sensores, añadieron alertas en RPM de ventiladores y reemplazaron la unidad de una sola manguera por una solución que no despresurizara la sala.

La lección: ahorros energéticos que aumentan la variación térmica te costarán más en tiempo de incidentes de lo que ahorrarás en electricidad.
Optimiza después de instrumentar, no antes.

Microhistoria #3: La práctica aburrida pero correcta que salvó el día

Un equipo gestionaba una huella on-prem pequeña pero crítica: algunos hosts de virtualización, un appliance de almacenamiento, una pila de switches y un UPS.
No era glamoroso. No era grande. Pero ejecutaba nómina y autenticación interna, así que “pequeño” no significaba “opcional.”

Tenían una rutina que a los extraños les parecía casi ridícula: chequeos térmicos trimestrales. Mismo momento, mismo procedimiento.
Puerta cerrada, carga diurna típica, registrar temperaturas de entrada en top/middle/bottom, comprobar líneas base de ventiladores, validar temperatura del UPS,
y revisar deltas de atributos SMART. Tomaba menos de una hora. Producía gráficos aburridos. Los gráficos aburridos son un regalo.

Cuando un cambio en el HVAC del edificio ocurrió (un proyecto de instalaciones que reequilibró el aire), su siguiente chequeo trimestral detectó una subida lenta
en las temperaturas de entrada y una línea base de RPM más alta de lo habitual. Nada había fallado. No hubo tickets de usuarios. No hubo alarmas.
Solo deriva.

Porque tenían líneas base, pudieron presentar un caso creíble a facilities: “La entrada de este armario subió y nuestras RPM de ventilador están 20% más altas
con la misma carga.” Facilities ajustó compuertas y restauró el retorno de aire. Sin corte, sin drama, sin llamada de medianoche.

La lección es agresivamente poco sexy: mediciones de base convierten problemas térmicos en mantenimiento.
Eso es lo que se parece a la fiabilidad en un calendario.

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

1) Reinicios aleatorios por la tarde → apagado térmico o protección de PSU → confirma logs y mejora la refrigeración de entrada

Síntoma: Hosts se reinician “aleatoriamente”, a menudo agrupados alrededor de horas pico.
Causa raíz: CPU/paquete alcanza temperatura crítica o la PSU se sobrecalienta y activa protección; a veces el BMC lo registra, a veces no llega a los logs del SO.
SOLUCIÓN: Revisa System Event Log de BMC/IPMI y logs del kernel; reduce carga; restaura flujo de aire; añade sensor de temp de entrada y alertas; implementa ventilación/retorno real.

2) Picos de latencia de almacenamiento → throttling térmico de SSD/HDD → añade flujo de aire y evita que el chasis se caliente

Síntoma: Bases de datos se detienen, VM IO wait se dispara, pero el throughput parece “ok”.
Causa raíz: Controladores SSD throttlean o HDDs reintentan lecturas a alta temperatura; los ventiladores del chasis ya van al máximo.
Solución: Confirma vía registros SMART NVMe y temperaturas de disco; pausa temporalmente scrubs/rebuilds y migra cargas calientes; arregla flujo de aire de sala y uso de paneles cegados en el chasis.

3) Errores CRC en discos o NICs → capa física marginal empeorada por calor → reseat/reemplazar, luego arreglar el armario

Síntoma: CRC errors en aumento en SATA o Ethernet; timeouts intermitentes.
Causa raíz: Cable/backplane/ótica defectuosa que se vuelve inestable con calor y vibración por ventiladores al máximo.
Solución: Reemplaza cables/ópticas sospechosas, inspecciona backplane, asegura alivio de tensión; luego reduce la temperatura ambiente para evitar recurrencia.

4) Puertos de switch que se caen → alarma térmica en switch → desbloquear ventilaciones y alejar calor PoE

Síntoma: Teléfonos/APs se reinician, uplinks rebotan, spanning tree chorrea.
Causa raíz: ASIC del switch o etapas PoE sobrecalentándose; ventilaciones bloqueadas o equipos apilados sin espacio.
Solución: Revisa logs/temps del switch, despeja rutas de aire, reduce presupuesto PoE si es necesario, añade espacio de rack y extracción/retorno adecuados.

5) “La temp de la sala está bien” pero los servidores están calientes → la colocación de sensores miente → mide la entrada en la parte superior del rack

Síntoma: El termostato de pared marca 22°C; los servidores reportan 35–40°C de entrada; los ventiladores chillan.
Causa raíz: Estratificación y recirculación; el termostato está en el lugar equivocado, usualmente cerca de la puerta o del conducto de suministro.
Solución: Coloca sensores en las entradas de los dispositivos (top/middle/bottom). Alerta en la entrada, no en el ambiente del pasillo.

6) El AC portátil “ayuda” pero la humedad/presión se vuelve rara → presión negativa y mal retorno → corrige la trayectoria del aire

Síntoma: La temp del armario fluctúa, la puerta cuesta abrirse, aumenta el polvo, el rendimiento sigue inestable.
Causa raíz: El AC portátil de una manguera expulsa aire, generando presión negativa que arrastra aire caliente y polvo de otras zonas; no hay retorno controlado.
Solución: Usa refrigeración adecuada con suministro/retorno balanceado o sistema split dedicado; sella puntos de recirculación; evita despresurizar el armario.

7) Baterías UPS fallan temprano → calor del armario → reubica el UPS o mejora ventilación, luego prueba baterías

Síntoma: Auto-tests del UPS fallan; runtime muy por debajo de lo esperado.
Causa raíz: Vida útil de la batería acortada por temperatura ambiente elevada.
Solución: Mejora refrigeración alrededor del UPS, mantenlo fuera de zonas más calientes del rack, programa pruebas de runtime regulares y reemplazos proactivos.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar un incidente de armario caliente (hoy)

1. Confirma estrés térmico: revisa sensors, ipmitool sensor, RPM de ventiladores y logs de thermal/throttle.
2. Deja de empeorarlo: pausa scrubs/rebuilds, difiere backups, mueve jobs por lotes y considera límites temporales de CPU.
3. Restaura flujo de aire inmediatamente: quita obstrucciones, asegúrate de que el escape trasero pueda salir y, como medida temporal, abre la puerta si reduce la temperatura de entrada.
4. Protege los datos primero: si aparecen errores de almacenamiento, prioriza la integridad—scrub/rebuild más tarde cuando la temperatura sea estable.
5. Documenta estado de la puerta y cambios: si “puerta abierta” es una mitigación, regístralo como dependencia operativa.
6. Ponte un temporizador para recontroles: temperaturas y RPM de ventiladores cada 5–10 minutos hasta estabilizar.

Paso a paso: arreglar el armario (este mes)

1. Inventaria fuentes de calor: lista equipos y estima vatios (lecturas BMC, PDU, UPS). Suma. Esa es tu carga térmica.
2. Mapea el flujo de aire: front/back de racks, huecos, perforaciones, paneles cegados, gestión de cables y ruta de escape.
3. Añade sensores de entrada: top/middle/bottom del frente del rack; al menos un sensor cerca de los dispositivos más calientes.
4. Alerta sobre las señales correctas: temp de entrada, RPM de ventiladores, warning time NVMe, alarmas térmicas de switches, temp interna del UPS.
5. Diseña suministro y retorno: necesitas ambos. Un conducto de suministro sin retorno es una mentira presurizada; un retorno sin suministro es un vacío de arrepentimiento.
6. Separa el escape caliente: incluso principios básicos de contención ayudan—evita recirculación y sella vías de bypass evidentes.
7. Reduce la impedancia: limpia filtros, quita foam/mantas de polvo, evita cortinas de cables en la parte trasera, mantén claros los conductos de ventilación.
8. Valida con una prueba de carga: simula carga pico y observa temperaturas de entrada y líneas base de ventiladores con la puerta cerrada.

Checklist operacional: evitar que vuelva (en curso)

• Baseline trimestral: temperaturas de entrada, RPM de ventiladores, temperaturas de discos, temp del UPS y contadores de error.
• Control de cambios con facilities: los ajustes HVAC pueden romperte; exige notificación y revalidación.
• Regla de limpieza: nada almacenado detrás de racks, sin cartón, sin “temporal” montones de cables que bloqueen el escape.
• Política de puerta: o el armario funciona con la puerta cerrada, o no funciona. Diseña para cerrada.
• Planificación de capacidad incluye refrigeración: añadir un host añade calor; trata los vatios como un recurso de primera clase.

Preguntas frecuentes

1) ¿Qué temperatura es “demasiado caliente” para un armario de servidores?

El número que importa es la temperatura de entrada del dispositivo, no el termostato del pasillo. Muchos entornos buscan mantener la entrada
en los bajos a medios 20s °C por margen. Entradas sostenidas en los 30s °C son donde empiezas a ver throttling y riesgo de aumento de tasas de error,
especialmente en la parte superior de los racks.

2) ¿Por qué los problemas aparecen como errores de disco o red en vez de alarmas de “sobrecalentamiento”?

Porque el SO solo ve lo que el hardware informa, y muchos componentes fallan “suavemente” primero: reintentos, timeouts, errores CRC
y colapso de rendimiento. Algunas plataformas registran eventos térmicos en el BMC pero no en el SO. Además, el calor amplifica problemas físicos marginales
(cables, óptica, conectores).

3) ¿Puedo arreglar esto dejando la puerta abierta?

Dejar la puerta abierta es una mitigación, no un diseño. También crea un conflicto de seguridad, lo que significa que eventualmente se cerrará
en el peor momento posible. Úsalo para probar el diagnóstico (las temperaturas bajan rápido), luego construye un camino de suministro/retorno adecuado.

4) ¿Son una buena solución los AC portátiles?

A veces sí, pero son fáciles de desplegar incorrectamente. Las unidades de una manguera suelen crear presión negativa, trayendo aire caliente y polvo de otros sitios.
Si debes usar refrigeración portátil, asegúrate de que la trayectoria de aire esté balanceada y que el escape caliente no recircule.

5) ¿Por qué la parte superior del rack siempre va más caliente?

Estratificación: el aire caliente sube. Además, muchos armarios tienen mal retorno cerca del techo, por lo que el aire caliente se acumula allí.
Si los dispositivos superiores ingieren ese aire, reciben las peores condiciones de entrada aun cuando la “temperatura ambiente” parezca bien.

6) ¿Cuál es la forma más rápida de probar que el calor es el culpable?

Correlaciona tres señales: suben las temperaturas de entrada/CPU, aumenta RPM de ventiladores y empeoran el rendimiento/errores. Luego haz un cambio controlado
en el flujo (quita una obstrucción o abre la puerta temporalmente) y observa si las temperaturas bajan y los errores se estabilizan.

7) ¿El calor causa corrupción de datos?

El calor puede aumentar las tasas de error y los timeouts; la corrupción suele prevenirse con ECC, checksums y la integridad a nivel de protocolo,
pero esas protecciones tienen límites. El riesgo práctico más grande es que el calor cause fallos durante reconstrucciones/scrubs, cuando tu
margen de redundancia ya está reducido.

8) ¿Debo priorizar más refrigeración o mejor monitorización?

Haz ambas, en ese orden: estabiliza la refrigeración lo suficiente para no estar apagando fuegos constantemente, luego añade monitorización para que nunca
tengas que redescubrir el problema durante un outage. Monitorización sin arreglo solo te da mejores gráficos de la miseria.

9) ¿Por qué los ventiladores al máximo empeoran a veces las cosas?

Los ventiladores al máximo aumentan el consumo (más calor), aumentan la vibración (conectores marginales y discos sufren) y atraen polvo más rápido,
obstruyendo filtros y disipadores. Son necesarios en emergencias pero señalan que la refrigeración a nivel sala es insuficiente.

10) ¿Cómo explico esto a facilities o a la dirección no técnica?

Habla en vatios y riesgo. “Este rack consume aproximadamente X vatios continuamente; eso es calor que debemos extraer. Sin un camino de retorno,
la temperatura de entrada sube y la disponibilidad se degrada.” Luego muestra una correlación simple: pico de temperatura versus incidentes/RPM de ventiladores.

Conclusión: siguientes pasos que compran disponibilidad

Los armarios calientes no fallan como una explosión de película. Fallan como una fuga financiera lenta: unos pocos puntos más de latencia aquí,
unos cuantos reintentos allá, una reconstrucción que tarda más de lo que debería y luego un outage un viernes que llega con papeleo.
La solución no es mística. Es aire, medición y disciplina.

Haz esto a continuación, en orden

1. Instrumenta la temperatura de entrada en el rack (top/middle/bottom) y alerta sobre ella.
2. Alerta sobre RPM de ventiladores y eventos térmicos para que “está caliente” sea una página antes de ser un incidente.
3. Cuantifica tu carga térmica en vatios usando lecturas BMC/PDU/UPS. Usa ese número para decisiones con facilities.
4. Arregla rutas de flujo: asegura suministro y retorno, bloquea recirculación y mantiene el escape libre.
5. Operationaliza las comprobaciones aburridas: líneas base trimestrales, pruebas de baterías, deltas SMART y una regla de que las reconstrucciones de almacenamiento no corran durante estrés térmico.

Si ejecutas sistemas de producción en un armario, ya estás jugando en modo difícil. Al menos quita la desventaja del calor.
La disponibilidad es bastante difícil sin convertir tu infraestructura en un calefactor con opinión.