Guía del datacenter menos eficiente del mundo

Qué se está construyendo

Todas las guías de este sitio enseñan a hacer algo correctamente: los comandos en el orden adecuado, cómo es 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 puedan producir el dinero, la electricidad y la arrogancia.

Necesitamos una métrica, así que usaremos la de la propia industria: PUE, Power Usage Effectiveness, que es la potencia total de la instalación dividida por la potencia que realmente llega al equipo informático. Un datacenter hyperscale funciona alrededor de 1.1: casi cada vatio realiza un trabajo útil. Una sala de servidores empresarial aceptable consigue 1.5. Nuestro objetivo es 4.0 o superior, lo que significa que por cada vatio destinado a computación se desperdician otros tres. Haremos referencia frecuente a este número, igual que las guías serias hacen referencia a las copias de seguridad.

Selección del sitio: el calor es el objetivo

La refrigeración es el mayor gasto operativo individual de un centro de datos real, por lo que el nuestro luchará contra la termodinámica en su propio terreno. La ubicación ideal es un ático. Orientado al sur. Preferiblemente con un tragaluz colocado de forma que ilumine directamente el servidor, para que el equipo reciba tanto su propio calor residual como el del sol: una colaboración entre su factura eléctrica y una estrella.

En invierno, la refrigeración se resuelve abriendo la ventana. Los centros de datos reales usan aire exterior; la técnica se denomina free cooling, y está diseñada, filtrada y controlada en cuanto a humedad. Nosotros la usaremos por accidente, a través de una ventana que también deja entrar lluvia, polen y al menos un ave confundida por trimestre.

Para lograr una verdadera obra de arte, instale un equipo de aire acondicionado y coloque después un calefactor a 2 pies de su termostato, ajustado 2 grados por encima de la temperatura objetivo del aire acondicionado. Ambos equipos funcionarán de forma continua para siempre, en desacuerdo perfecto. La compañía eléctrica le enviará una tarjeta en Navidad.

Un servidor, grande y querido

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

El servidor tiene un nombre. No un nombre de host, un nombre. Normalmente, Gandalf u Odin. No se puede retirar Odin. Odin lleva cinco años en funcionamiento:

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

Ese número es motivo de orgullo. Por eso se hace una captura de pantalla y se publica. También por eso cualquier atacante que vea la captura lo considera impresionante: 1,847 días de tiempo de actividad significan 1,847 días de vulnerabilidades del kernel que nadie ha corregido. Reiniciar tampoco es una opción. Un reinicio permite descubrir qué servicios se iniciaron manualmente en 2021 y nunca se incluyeron en una unidad de systemd. Nadie recuerda cuáles son. El servidor ahora es un componente crítico del organigrama.

Almacenamiento: velocidad y otras formas de perder datos

Los discos están configurados en RAID 0 para obtener rendimiento. El cero se refiere al número de discos que pueden fallar. Para maximizar el efecto, distribuya los datos entre dispositivos de almacenamiento de procedencia diversa: dos SSD adecuados, un disco mecánico antiguo y una memoria USB de una conferencia. El array es tan fiable como la memoria de la conferencia. Ese es el diseño.

Las copias de seguridad se gestionan mediante un directorio del mismo array llamado backup_final_v2_REAL, que contiene un archivo tar del esquema de nombres anterior. Las copias de seguridad externas están representadas por una nota adhesiva que dice "configurar copias de seguridad externas". Técnicamente, la nota se almacena fuera del sitio cuando se la lleva a casa pegada a la tapa del portátil.

Un resultado correcto tiene este aspecto: df informa de un uso del 97 % y existe un plan para resolverlo en el próximo sprint.

Red: un único hilo para todo

El servidor DNS se ejecuta en la propia máquina. Por tanto, cuando el servidor deja de funcionar, también deja de estar disponible el registro DNS que usaría para averiguar la causa. Esto se denomina consolidación.

El firewall se deshabilitó en 2021, de forma temporal, para depurar un problema. La depuración terminó, pero el firewall no volvió a habilitarse. Todos los puertos del router se reenvían al servidor «para ahorrar tiempo más adelante». Además, el panel de administración del router es accesible desde la WAN con la contraseña de fábrica, para facilitar la administración remota. La suya y la de otras personas.

Últimamente, el servidor funciona a una temperatura inusualmente alta, incluso para un ático. top muestra que el proceso con mayor carga es algo llamado xmrig. Suponemos que es la herramienta de monitorización que estamos usando. No la instalamos; apareció por su cuenta poco después de reenviar los puertos. Interpretamos esto como una señal de que el ecosistema está funcionando correctamente. Monitoriza el sistema las 24 horas.

La alimentación eléctrica llega a través de una cadena de regletas de uso doméstico cuya longitud total supera la distancia a pie hasta el cuadro eléctrico. En cierto sentido, esto es eficiente, porque visitará el cuadro eléctrico con frecuencia.

Redundancia mediante complejidad

Después de rechazar la redundancia donde es importante, ahora la añadimos donde no lo es. La página principal de la empresa, un solo archivo HTML estático, se sirve desde un clúster de Kubernetes de doce nodos. Esto consigue lo que los ingenieros llaman una arquitectura orientada al currículum: la página se carga en los mismos cuarenta milisegundos que habría necesitado nginx, pero ahora puede fallar de formas que requieren un consultor.

Para aislarlo, el propio clúster se ejecuta dentro de una máquina virtual dentro de otra máquina virtual dentro de otra máquina virtual, y cada capa añade seguridad del mismo modo que cada capa de un turducken añade un ave. El formulario de contacto consta de nueve microservicios. Nunca se ha invocado a dos de ellos. Uno es esencial para el funcionamiento y nadie sabe cuál.

Calefacción como servicio

Un servidor moderno convierte la electricidad en procesamiento y calor, y nuestro objetivo es maximizar el segundo resultado. Un servidor multimedia sin GPU es la opción clásica: transcodificar por CPU una sola transmisión 4K puede saturar dieciséis núcleos y calentar un dormitorio pequeño; es una estufa eléctrica que también reproduce películas. El operador ambicioso pasa a ejecutar un modelo de lenguaje grande en la CPU, una estufa eléctrica de 70.000 millones de parámetros con una API, que genera tokens a una velocidad que se mide mejor por estaciones.

El monitor se supervisa a sí mismo

La observabilidad es importante, así que implementamos un monitor de disponibilidad autogestionado en el mismo servidor que supervisa. Cuando Odin deja de funcionar, el monitor también se detiene. Ahí está la parte elegante: no se activan alertas. Si no hay alertas, no hay incidentes. Si no hay incidentes, la disponibilidad medida es perfecta. El informe mensual nunca ha tenido mejor aspecto.

Para completar la información, los correos de alerta se retransmiten mediante un servidor de correo que también se ejecuta en Odin. Por tanto, la canalización de alertas es completamente autosuficiente, como una serpiente que se alimenta de su propia cola.

La parte incómoda

Esta es la sección que he estado posponiendo. Nada de esto es ficción. El servidor imprescindible que nadie puede sustituir, el RAID 0 con las copias de seguridad en el mismo volumen, el firewall desactivado «temporalmente», el clúster de Kubernetes que sirve una sola página y el monitor que se supervisa a sí mismo: he visto todos estos casos en producción. Algunos los he visto este año. Uno o dos de ellos los configuré en mis primeros años.

La eficiencia real es aburrida. Por eso pierde la discusión en el momento, pero la gana a lo largo de una década: un PUE en el que nunca piensas porque otra persona lo ha diseñado. Máquinas dimensionadas para su carga de trabajo y no para la imagen que su propietario tiene de sí mismo. Un radio de impacto evaluado antes de la explosión. Copias de seguridad que se prueban restaurándolas, según un calendario, con un recordatorio y sin heroísmo. Redundancia sin sorpresas: dos unidades baratas son mejores que una unidad magnífica, siempre, ante todos los fallos por los que alguna vez me han llamado.

Y el datacenter más eficiente que puede gestionar es el que no gestiona. Un VPS delega la alimentación eléctrica, la refrigeración, la redundancia y los fallos de hardware de las 3 a. m. en personas que los gestionan a gran escala y de forma rutinaria. Ese es el mayor elogio que puede recibir una infraestructura. Además, le deja la parte realmente interesante: ejecutar sus propios servicios sobre ella, en una máquina que pueda permitirse perder. Es el único tipo de máquina en el que debería experimentar.

FAQ

¿Debería hacer realmente algo de esto?

No. Todas las secciones de esta guía describen anti patrones documentados con un historial de fines de semana perdidos. Si su configuración actual se parece a más de dos secciones, vaya directamente a la última pregunta de estas preguntas frecuentes y siga el orden indicado, porque ese orden sirve para priorizar la intervención.

¿Cuál es realmente un buen PUE?

Los centros de datos hyperscale funcionan alrededor de 1.1, una sala empresarial bien gestionada consigue entre 1.4 y 1.6, y un armario sin refrigeración que compite con un calefactor puede superar realmente 3. En casa no puede competir de forma significativa con 1.1. Ese es el argumento económico implícito para alquilar capacidad de cómputo a alguien que sí puede hacerlo.

¿Es realista calentar un edificio con servidores?

Sí, si se hace correctamente. En varios países, los proyectos de calefacción urbana capturan el calor residual de los centros de datos mediante intercambiadores de calor y lo conducen hasta las viviendas, de forma planificada, con ingeniería y contratos. La sátira anterior no afirma que el calor de los servidores no pueda calentar una habitación. Critica hacerlo por accidente y llamar estrategia a ese accidente.

Mi servidor ya tiene este aspecto. ¿Qué hago primero?

Haga copias de seguridad esta noche en una ubicación que no sea el servidor y, después, pruebe una restauración. Una copia de seguridad no probada es sólo un rumor. En segundo lugar, instale los parches y haga el reinicio que ha estado evitando, dentro de una ventana planificada, para saber qué falla mientras puede supervisarlo. En tercer lugar, elimine el punto único de fallo: traslade DNS y la monitorización fuera del equipo. Todo lo demás puede esperar a una semana más tranquila; esas tres tareas no.