cómo diseñar el datacenter menos eficiente

Lo que estás construyendo

Cada guía en este sitio enseña a hacer algo correctamente: los comandos en orden, cómo se ve un resultado correcto y los modos de fallo identificados. Esta guía es diferente. Hoy, de forma totalmente hipotética, vamos a diseñar el datacenter menos eficiente que el dinero, la electricidad y la arrogancia puedan producir.

Necesitamos una métrica, así que tomaremos la de la industria: PUE, Power Usage Effectiveness — la potencia total de la instalación dividida por la potencia que realmente llega al equipo de cómputo. Un datacenter hyperscale funciona alrededor de 1.1: casi cada watt realiza un trabajo útil. Una sala de servidores empresarial decente gestiona un 1.5. Nuestro objetivo es 4.0 o superior, lo que significa que por cada watt de cómputo, tres watts más se pierden sin utilidad. Nos referiremos a este número con frecuencia, de la misma forma que las guías serias se refieren a los backups.

Selección del sitio: el calor es el objetivo

La refrigeración es el mayor gasto operativo en un datacenter real, por eso el nuestro luchará contra la termodinámica en su propio terreno. La ubicación ideal es un ático. Orientado al sur. Idealmente con un tragaluz posicionado para iluminar directamente el servidor, de modo que la máquina reciba tanto su propio calor residual como el del sol, una colaboración entre tu factura de electricidad y una estrella.

En invierno, la refrigeración se gestiona abriendo la ventana. Los datacenters reales usan aire exterior — la técnica se llama free cooling, y está diseñada, filtrada y controlada en humedad. Nosotros la usaremos accidentalmente, a través de una ventana que también permite la entrada de lluvia, polen y al menos un pájaro confundido por trimestre.

Para un arte verdadero, instala un aire acondicionado y luego coloca un calefactor a dos pies de su termostato, configurado dos grados más caliente que el objetivo del aire acondicionado. Ambas máquinas funcionarán ahora continuamente, para siempre, en un desacuerdo perfecto. La compañía eléctrica te enviará una tarjeta en Navidad.

Un servidor, grande, amado

La redundancia diluye el compromiso. Nuestro datacenter contiene exactamente un servidor, y es enorme, porque una sola máquina con 512 GB de RAM se siente como infraestructura, mientras que cuatro pequeñas se sienten como una lista de tareas pendientes.

El servidor tiene un nombre. No un hostname — un nombre. Gandalf, usualmente, u Odin. No puedes desmantelar a Odin. Odin ha estado encendido durante cinco años:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

Ese número es un motivo de orgullo, razón por la cual le tomas una captura de pantalla y la publicas, y por qué cada atacante que ve la captura también la encuentra impresionante: 1,847 días de uptime significan 1,847 días de vulnerabilidades de kernel, sin parchar por nadie. Reiniciar no es una opción de todos modos — un reinicio es como descubres qué servicios se iniciaron manualmente en 2021 y nunca se escribieron en una unidad de systemd. Nadie recuerda cuáles son. El servidor es ahora un pilar estructural en el organigrama.

Almacenamiento: velocidad y otras formas de perder datos

Los discos están configurados en RAID 0, para rendimiento. El cero se refiere al número de discos que pueden fallar. Para el máximo efecto, realiza un stripe del array usando almacenamiento de procedencia mixta: dos SSD reales, un disco mecánico envejecido y una memoria USB de una conferencia. El array es exactamente tan confiable como la memoria de la conferencia, que es el diseño.

Los backups se gestionan mediante un directorio en el mismo array llamado backup_final_v2_REAL, que contiene un tarball del esquema de nombres anterior. Los backups off-site están representados por una nota adhesiva que dice "configurar backups off-site", lo cual es, técnicamente, almacenado off-site cuando te lo llevas a casa en la tapa de tu laptop.

Un resultado correcto se ve así: df reportando 97% de uso, y un plan para lidiar con ello en el próximo sprint.

Networking: un solo hilo de todo

El servidor DNS se ejecuta en la propia máquina, de modo que cuando el servidor caiga, se llevará consigo el registro DNS que usarías para averiguar por qué. Esto se llama consolidación.

El firewall se desactivó en 2021 — temporalmente, para depurar algo. La depuración concluyó; el firewall no regresó. Cada puerto en el router está redirigido al servidor "para ahorrar tiempo después", y el panel de administración del router es alcanzable desde el lado WAN con su contraseña de fábrica, para una gestión remota conveniente. La tuya, y la de otros.

El servidor ha estado funcionando inusualmente caliente últimamente, incluso para los estándares de un ático, y top muestra que el proceso más ocupado es algo llamado xmrig. Asumimos que esta es la herramienta de monitoreo que estamos usando. No la instalamos — apareció por sí sola poco después de que se redirigieran los puertos, lo cual tomamos como una señal de que el ecosistema está prosperando. Monitorea las 24 horas.

La energía llega a través de una cadena de regletas de consumo cuya longitud combinada excede la distancia de caminata hasta el panel de interruptores — lo cual es eficiente, en cierto sentido, porque visitarás el panel de interruptores con frecuencia.

Redundancia mediante complejidad

Habiendo rechazado la redundancia donde importa, ahora la añadimos donde no importa. La página principal de la empresa — un único archivo HTML estático — es servida por un cluster Kubernetes de doce nodos. Esto logra lo que los ingenieros llaman arquitectura impulsada por el currículum: la página carga en los mismos cuarenta milisegundos que nginx habría entregado, pero ahora puede fallar de formas que requieren un consultor.

Para aislamiento, el cluster mismo se ejecuta dentro de una máquina virtual dentro de una máquina virtual dentro de una máquina virtual, cada capa añadiendo seguridad de la misma forma que cada capa de un turducken añade ave. El formulario de contacto son nueve microservicios. Dos de ellos nunca han sido invocados. Uno de ellos es estructural y nadie sabe cuál.

Calefacción como servicio

Un servidor moderno convierte electricidad en cómputo y calor, y pretendemos maximizar el segundo resultado. Un media server sin GPU es la jugada clásica: el transcodificado por CPU de un único stream 4K mantendrá ocupados dieciséis núcleos y calentará una habitación pequeña, un calefactor que también reproduce películas. El operador ambicioso se gradúa a ejecutar un large language model en CPU — un calefactor de 70 mil millones de parámetros con una API, produciendo tokens a un ritmo que se mide mejor estacionalmente.

El monitor se observa a sí mismo

La observabilidad importa, así que desplegamos un monitor de uptime self-hosted — en el mismo servidor que monitorea. Cuando Odin muere, el monitor muere con él, y aquí está la parte elegante: no se disparan alertas. Sin alertas significa sin incidentes. Sin incidentes significa uptime perfecto, según la medición. El reporte mensual nunca se ha visto mejor.

Los correos de alerta, para completar, se retransmiten a través de un servidor de correo que también se ejecuta en Odin. El pipeline de alertas está, por tanto, totalmente autocontenido, de la misma forma que una serpiente que se come su propia cola está totalmente alimentada.

La parte incómoda

Aquí está la sección que he estado posponiendo. Nada de esto es ficción. El servidor amado e irremplazable, el RAID 0 con backups en el mismo volumen, el firewall desactivado "temporalmente", el cluster Kubernetes sirviendo una sola página, el monitor observándose a sí mismo — he visto cada uno de estos en producción. Algunos los he visto este año. Uno o dos de ellos, en mis inicios, los construí yo.

Cómo es la eficiencia real es aburrido, razón por la cual pierde la discusión en el momento pero la gana durante una década: un PUE en el que nunca piensas porque alguien más lo diseñó. Máquinas dimensionadas para su carga de trabajo en lugar de para la autoimagen de su dueño. Un radio de explosión, considerado antes de la explosión. Backups que se prueban restaurándolos, con un cronograma, con un recordatorio de calendario y sin heroísmo. Redundancia que es aburrida — dos de la cosa barata vencen a una de la cosa magnífica, siempre, en cada fallo por el que me han llamado.

Y el datacenter más eficiente que puedes operar es el que no operas. Un VPS te entrega la potencia, la refrigeración, la redundancia y los fallos de hardware a las 3 a.m. a personas que lo hacen a escala, de forma aburrida, que es el mayor cumplido que la infraestructura puede ganar — y te deja la parte genuinamente divertida, que es ejecutar tus propios servicios sobre ella, en una máquina que puedes permitirte perder, que es el único tipo con el que deberías experimentar jamás.

FAQ

¿Debería hacer realmente algo de esto?

No. Cada sección de esta guía es un anti-patrón documentado con un recuento de fines de semana perdidos. Si tu configuración actual se parece a más de dos secciones, salta a la última pregunta de este FAQ — en el orden dado, porque el orden es el triaje.

¿Cuál es un buen PUE, realmente?

Los datacenters hyperscale funcionan alrededor de 1.1, una sala empresarial bien gestionada maneja de 1.4 a 1.6, y un armario sin refrigeración con una disputa de calefactores puede exceder genuinamente el 3. No puedes competir significativamente con 1.1 en casa, lo cual es el argumento económico silencioso para alquilar cómputo de alguien que sí puede.

¿Es real eso de calentar un edificio con servidores?

Sí — hecho correctamente. Los proyectos de calefacción urbana en varios países capturan el calor residual de los datacenters mediante intercambiadores de calor y lo canalizan hacia los hogares, por diseño, con ingeniería y contratos. La sátira anterior no es que el calor del servidor pueda calentar una habitación; es hacerlo por accidente y llamar al accidente una estrategia.

Mi servidor ya se ve así. ¿Qué hago primero?

Backups, esta noche, en algún lugar que no sea el servidor, y luego una restauración de prueba — un backup no probado es solo un rumor. Segundo, parches y el reinicio que has estado evitando, en una ventana planificada, para que aprendas qué se rompe mientras estás observando. Tercero, divide el punto único de fallo: mueve el DNS y el monitoreo fuera de la caja. Todo lo demás puede esperar a una semana más tranquila; esos tres no.