Nos llamaron un enero por "servidores que se apagan solos en la tarde". El "datacenter" era una bodega de tres por tres con un rack, un split de pared y una orden de gerencia: apagar el aire al cierre, para ahorrar. Cada tarde de verano la sala subía de 22 a casi 40 °C, los servidores se protegían apagándose solos, y a la mañana siguiente todo "volvía a funcionar". Los equipos estaban perfectos. El problema era un malentendido con la física.
Tu sala ya es un datacenter
Un datacenter no es un edificio con guardias y puertas biométricas: es cualquier sala donde el negocio guarda sus equipos. La sala del NVR, el clóset del rack, la oficina que "mientras tanto" aloja el servidor de facturación. Y aquí viene la parte incómoda: esa sala obedece exactamente las mismas leyes que un datacenter Tier IV. La electricidad se convierte en calor, el calor hay que sacarlo con aire, los discos fallan con calendario propio y la disponibilidad se compra con dinero. La diferencia entre Google y tu bodega no es la física — es cuánto presupuesto le pusieron a cada ley.
Esta guía recorre las cuatro cuentas que deciden si tu sala es un datacenter pequeño o una freidora lenta: espacio (el rack), calor (los BTU), aire (el caudal) y promesas (los nueves). Todas con números verificables, porque en este rubro los "más o menos" se pagan en madrugadas.
El rack: 42U de orden y de física
La unidad rack existe para que todo encaje: 1U = 1,75 pulgadas = 44,45 mm, un estándar que sobrevive desde la época de los tableros telefónicos. El gabinete típico es de 42U: 42 × 44,45 = 1.866,9 mm — 1,87 m de espacio útil en una estructura de unos dos metros. En teoría caben 42 servidores de 1U. En la práctica caben bastantes menos, y casi nunca por espacio: te quedas sin energía o sin frío mucho antes que sin U.
El peso es el otro número que se subestima. Un switch pesa unos 5 kg, un servidor de 1U entre 12 y 18, un UPS de rack con sus baterías pasa los 60 con facilidad, y un banco de baterías externo puede duplicarlo. Un rack medianamente poblado supera la media tonelada — por eso los gabinetes serios declaran carga estática de 1.000 a 1.500 kg, y por eso importa dónde va cada cosa. La regla es cargar desde abajo: lo más pesado (UPS, baterías) al fondo, servidores al medio, switches y patch panels arriba, donde llegan los cables. No es manía de orden: es centro de gravedad. Cuando extiendes un equipo pesado sobre sus rieles, todo su peso queda en voladizo frente al rack; si ese equipo está arriba, el rack se puede venir encima — contigo agarrándolo. Antes de comprar el gabinete, cuadra U, kilos y kilowatts en la calculadora de capacidad de rack.
Todo watt entra como electricidad y sale como calor
La primera ley del datacenter es la primera ley de la termodinámica: prácticamente cada watt que consumen tus equipos se convierte en calor dentro de la sala. No "una parte" — todo. Los datos que procesa un servidor no pesan ni abrigan; el 100 % de esa energía termina en el aire. Un rack de 10 kW es, térmicamente, cinco estufas eléctricas de 2 kW encendidas 24/7 en una habitación cerrada. Nadie dejaría cinco estufas a puerta cerrada un fin de semana largo; un rack de densidad media es exactamente eso.
Para hablar con el proveedor de clima hay que traducir unidades: kW IT × 3412 = BTU/h, que es la unidad en que se venden los equipos, y kW ÷ 3,517 = toneladas de refrigeración (1 TR = 12.000 BTU/h). A la carga IT súmale lo que no sale en la ficha: el UPS disipa entre un 4 y un 10 % de lo que pasa por él, la iluminación aporta lo suyo, y si la sala tiene un muro al sol de la tarde, ese muro también es una estufa. La calculadora de carga térmica junta todas las piezas.
Aire: pasillo frío, pasillo caliente
Sacar el calor no es solo "poner frío": es organizar el tránsito. Los servidores respiran de adelante hacia atrás — aire frío por el frente, aire caliente por la espalda. Si ese aire caliente da la vuelta y entra al frente del rack vecino (o al propio), el equipo respira aire pre-cocido y trabaja con fiebre. La solución tiene décadas y sigue vigente: enfrentar los racks cara a cara formando un pasillo frío donde se inyecta el aire, y dejar que las espaldas descarguen al pasillo caliente, que retorna al CRAC por arriba. Frío y caliente no se mezclan: se saludan de lejos.
¿Y cuánto aire hay que mover? La fórmula es Q = P ÷ (ρ × cp × ΔT): la potencia térmica dividida por la densidad del aire (≈ 1,2 kg/m³), su calor específico (≈ 1005 J/kg·°C) y el ΔT — cuánto se calienta el aire al cruzar los servidores, típicamente entre 10 y 15 °C. Puedes jugar con kW y ΔT en la calculadora de caudal y CRAC, pero hagamos la sala completa de 10 kW a mano, de una vez:
- Calor a evacuar: 10 kW × 3412 = 34.120 BTU/h. Ese es el número que entiende el proveedor de clima.
- En toneladas de refrigeración: 10 ÷ 3,517 = 2,84 TR (la misma cuenta por el otro camino: 34.120 ÷ 12.000 = 2,84). Un equipo de 3 TR queda justo; con redundancia N+1, dos de 3 TR.
- Caudal de aire con ΔT de 12 °C: Q = 10.000 ÷ (1,2 × 1005 × 12) = 0,69 m³/s.
- En la unidad de las fichas técnicas: 0,69 m³/s × 2119 ≈ 1.464 CFM. Para dimensionarlo mentalmente: son unos 2.490 m³/h — 25 extractores de baño soplando al mismo tiempo, para una sala de tres por tres.
- El ΔT manda: si el aire se mezcla y tu ΔT real baja a 6 °C, necesitas el doble de caudal para el mismo calor. Contener pasillos y tapar huecos no es cosmética: es caudal gratis.
¿Y cómo saber tu ΔT real? Los propios servidores lo miden — sin instrumentos extra:
$ ipmitool sdr type Temperature Inlet Temp | 04h | ok | 7.1 | 24 degrees C Exhaust Temp | 01h | ok | 7.1 | 36 degrees C CPU1 Temp | 0Eh | ok | 3.1 | 58 degrees C
Entrada 24 °C, salida 36 °C: ΔT de 12 °C, justo el de nuestra cuenta. Si el inlet marca 30 °C o más, el problema no es el CRAC: es aire caliente recirculando hacia el frente.
Los nueves: la disponibilidad se compra con dinero
"Necesitamos que nunca se caiga" es la frase más cara del rubro, medida por palabra. La disponibilidad se expresa en nueves, y la trampa está en que la escala engaña: entre 99 % y 99,999 % parece que hay "casi nada", pero cada nueve extra divide la caída anual por diez — y multiplica el presupuesto por algo muy parecido.
| Disponibilidad | Caída máx. / año | Se siente como | Qué la logra |
|---|---|---|---|
| 99 % | 3,65 días | un fin de semana largo sin sistema | un servidor solo, sin redundancia |
| 99,5 % | 43,8 horas | casi dos días hábiles | buen hardware, cero respaldo eléctrico |
| 99,9 % | 8,77 horas | una jornada laboral completa | UPS + clima serio + monitoreo |
| 99,99 % | 52,6 minutos | una reunión que se alargó | N+1 en energía y clima |
| 99,999 % | 5,26 minutos | ir a buscar un café | redundancia total, dos sitios |
¿Cómo se suben peldaños? Con redundancia N+1: si la carga necesita N equipos, instalas N+1 para que la falla de cualquiera no afecte el servicio. Y la regla de oro para combinar componentes: en serie, las disponibilidades se multiplican — todo debe funcionar, así que dos eslabones de 99 % encadenados dan 0,99 × 0,99 = 98,01 % (la cadena es peor que su peor eslabón). En paralelo, el sistema perdona: basta que uno funcione, y dos equipos de 99 % en paralelo alcanzan 99,99 %. La cadena completa — empresa eléctrica, UPS, clima, servidor, switch — se modela en la calculadora de disponibilidad y SLA, con los nueves y los minutos de cada configuración.
Discos: RAID no es backup (y escribe con recargo)
Primero lo doloroso: RAID no es backup. RAID protege contra la falla de un disco; no protege contra el borrado accidental, el ransomware, ni el incendio — todos replican su desastre a los demás discos con entusiasmo y en tiempo real. Backup es otra copia, en otro equipo, idealmente en otra parte. Dicho eso, el RAID correcto sí decide cuánto rinde y cuánto aguanta tu almacenamiento, y ahí hay un número que casi nadie mira: la penalización de escritura.
Cada escritura lógica se convierte en varias operaciones físicas. En RAID 10 se escribe el dato y su espejo: 2 operaciones. En RAID 5 hay que leer el dato viejo, leer la paridad, escribir el dato nuevo y escribir la paridad nueva: 4. En RAID 6, con doble paridad, son 6. La cuenta con un arreglo real: 8 discos de 150 IOPS suman 1.200 IOPS crudos; con una carga típica de 70 % lectura / 30 % escritura en RAID 5, quedan 1.200 ÷ (0,7 + 0,3 × 4) = 632 IOPS funcionales. La paridad se comió casi la mitad del arreglo — antes de encender la primera máquina virtual.
| Nivel | Penalización de escritura | IOPS funcionales (8×150, 70/30) | Aguanta |
|---|---|---|---|
| RAID 0 | ×1 | 1.200 | 0 discos — ni lo pienses |
| RAID 10 | ×2 | 923 | 1 disco por espejo |
| RAID 5 | ×4 | 632 | 1 disco |
| RAID 6 | ×6 | 480 | 2 discos |
La capacidad útil y la tolerancia de cada nivel están en la calculadora RAID; el rendimiento con tu mezcla real de lectura/escritura, en la de IOPS con penalización.
Crecimiento: que el 80 % no te tome por sorpresa
El almacenamiento nunca se llena por carta certificada: se llena un viernes a las 18:30. La defensa es aburrida y efectiva — mide tu tasa de crecimiento mensual real (la de tu negocio, no la del folleto del proveedor) y proyecta. Ojo, que el crecimiento suele ser compuesto: más clientes generan más cámaras, más correos y más respaldos, y la curva se empina sola.
Un ejemplo con números: tienes 6 TB usados de 10, creciendo 4 % mensual compuesto. Llegas al 80 % (8 TB) en 7,3 meses y al disco lleno en 13. ¿Por qué importa el 80 %? Porque sobre ese umbral muchos sistemas de archivos y arreglos empiezan a degradar rendimiento, y porque ahí se acaba tu margen de maniobra: migrar, hacer snapshots o reconstruir un RAID necesita espacio libre. Proyecta la fecha exacta con la calculadora de crecimiento de almacenamiento y agenda la compra con meses de ventaja: la orden de compra tarda menos que un disco averiado un día domingo.
La sala pequeña y el datacenter grande obedecen la misma física; la diferencia es quién hizo las cuentas antes. Empieza hoy: mide el consumo real de tu rack, convierte esos kW en BTU y caudal, y anota cuánto cuesta una hora tuya caída. Con esos tres números, cada decisión de la sala — clima, UPS, RAID, espacio — deja de ser un acto de fe y pasa a ser aritmética.