Las máquinas virtuales son la respuesta correcta para muchas cargas de trabajo, pero no para todas. Cuando necesitas acceso exclusivo a la topología de CPU, dispositivos NVMe sin una capa de virtualización en el camino, o un entorno de tenant único donde controlas cada parámetro del kernel, la configuración de un servidor bare metal es la única opción que lo garantiza. Esta checklist cubre las cinco fases que importan: hardening de BIOS, bonding de red, aprovisionamiento del sistema operativo, diseño de almacenamiento y validación previa a producción. Trabájalas en orden y no tendrás que pasar tu primer incidente en producción rastreando un problema que introdujiste al montar el rack.

Fase 1: Hardening de BIOS y UEFI

El firmware se sitúa por debajo de casi todas las defensas que los equipos realmente monitorean. Si un atacante llega hasta él, puede eludir por completo los controles a nivel de sistema operativo, razón por la que el hardening de BIOS es el primer ítem de cualquier checklist seria de despliegue bare metal, no algo que se hace después. La Publicación Especial 800-147B del NIST cubre las directrices de protección del BIOS de servidor y es la referencia de autoridad para esta capa.

Los controles prácticos que debes aplicar antes de instalar el sistema operativo: bloquea la configuración del firmware con acceso basado en roles para que el acceso físico a la consola no implique acceso irrestricto a la política de arranque; restringe o deshabilita el arranque por red (PXE) en las interfaces que no estés usando activamente para el aprovisionamiento; exige actualizaciones de firmware autenticadas para que un parche rutinario no pueda reemplazarse de forma silenciosa; y habilita TPM 2.0 con Secure Boot para que solo se carguen componentes de firmware y sistema operativo autenticados al inicio. En Linux, mokutil --sb-state y efivar -l confirman si Secure Boot está realmente aplicado y no solo configurado.

Una nota sobre las vulnerabilidades de Secure Boot: BootHole, BlackLotus y PKFail demostraron que la mala configuración de Secure Boot, la reutilización de claves de plataforma y las políticas de arranque permisivas generan una exposición real. Habilitar la función no es suficiente; verifica la jerarquía de claves y confirma que tu bootloader no figure en ninguna lista de revocación conocida.

La deriva del firmware es un riesgo operativo subestimado. Dos nodos con CPU y memoria idénticas pueden comportarse de forma distinta si sus configuraciones UEFI divergen, afectando el rendimiento, el tiempo de arranque y la recuperación ante fallos. Captura tu configuración de BIOS validada como línea base inmediatamente después del hardening, antes de aprovisionar el sistema operativo. Cada nodo posterior en el mismo rol debe coincidir exactamente con ella.

Fase 2: Bonding de red

El driver de bonding del kernel Linux ofrece siete modos (Mode 0 al Mode 6). Para el aprovisionamiento de servidores dedicados en producción, la decisión casi siempre se reduce a dos: active-backup (Mode 1) o 802.3ad LACP (Mode 4).

Usa Mode 1 cuando solo necesitas failover y no puedes o no quieres configurar el switch upstream. Una interfaz está activa; la otra espera. Simple, confiable, sin necesidad de involucrar al switch. Usa Mode 4 cuando tu switch soporte LACP y quieras tanto redundancia como throughput agregado. Mode 4 utiliza el estándar IEEE 802.3ad de agregación dinámica de enlaces, proporciona tolerancia a fallos y requiere que el puerto del switch esté configurado como grupo de puertos LACP. Para servidores en producción con un switch gestionado, Mode 4 es el valor por defecto correcto.

Elegir el modo de bonding incorrecto al momento del aprovisionamiento es uno de esos errores que no aparece hasta que un enlace cae en producción. Hazlo bien desde el rack.

Independientemente del modo que elijas, verifica que ambas interfaces físicas muestren el estado esperado antes de continuar. En RHEL y sus derivados, cat /proc/net/bonding/bond0 muestra el slave activo, el estado del enlace y el intervalo de polling MII. Si usas Mode 4, confirma que la negociación LACP se completó correctamente en el lado del switch antes de avanzar.

Fase 3: Aprovisionamiento del sistema operativo

El aprovisionamiento del sistema operativo en bare metal es donde los equipos importan con más frecuencia deuda técnica de sus hábitos con máquinas virtuales. Algunos aspectos que debes resolver desde el principio.

Usa una imagen base mínima y agrega solo lo que la carga de trabajo requiere. Un nodo de base de datos y un nodo worker de Kubernetes no necesitan el mismo conjunto de paquetes; resiste la tentación de partir de una imagen de propósito general y recortarla después. Configura tu gestor de paquetes para obtenerlos desde un mirror interno controlado, de modo que tengas un software bill of materials reproducible y auditable desde el primer día.

Establece el hostname, los resolvers DNS, las fuentes NTP y las claves SSH autorizadas a través de tu cadena de herramientas de aprovisionamiento (cloud-init, Kickstart o Ignition según tu stack) y no de forma interactiva. La configuración interactiva no es reproducible. Usa chronyc tracking para confirmar la sincronización NTP antes de declarar el nodo aprovisionado; el desfase de tiempo provoca fallos sutiles en sistemas distribuidos que son genuinamente difíciles de diagnosticar a posteriori.

Deshabilita el acceso root por SSH. Usa únicamente autenticación por clave. Si tu sistema de aprovisionamiento requiere autenticación por contraseña para el bootstrap inicial, rota esas credenciales inmediatamente después del primer ciclo automatizado exitoso.

Fase 4: Diseño de almacenamiento

Los consejos sobre almacenamiento en las guías de configuración de servidores físicos suelen ser genéricos. Esto es lo que realmente importa para bare metal en producción.

Separa el disco del sistema operativo del disco de datos. No se trata solo de capacidad, sino de recuperación. Si el disco del sistema operativo falla o necesita ser reimaginado, tus datos sobreviven. Si usas NVMe, evalúa si tu carga de trabajo se beneficia del aislamiento de namespaces o si un único namespace con un esquema de particiones es suficiente.

Para RAID, decide en el momento del aprovisionamiento si quieres RAID por software (mdadm) o RAID por hardware, y documenta cuál elegiste. Mezclarlos o cambiar después es costoso. Para la mayoría de las cargas de trabajo que no requieren características específicas del controlador RAID, el RAID por software con mdadm ofrece mejor observabilidad y portabilidad. Usa mdadm --detail /dev/md0 para verificar el estado del array después del aprovisionamiento y antes de que el nodo entre en rotación.

La elección del sistema de archivos importa para la carga de trabajo. XFS es el predeterminado en las distribuciones de la familia RHEL y gestiona bien los archivos grandes y la alta concurrencia. ext4 es más simple y adecuado para la mayoría de las cargas de trabajo generales. Evita tomar esta decisión basándote únicamente en lo que te resulta familiar; adáptala al patrón de I/O que producirá la carga de trabajo.

En AMS1, donde operamos nodos bare metal con peering denso en AMS-IX, las decisiones de diseño de almacenamiento se intersectan directamente con los patrones de I/O de red para cargas de trabajo sensibles a la latencia que sirven a los mercados de Europa occidental. Definir correctamente el sistema de archivos y la profundidad de cola en el momento del aprovisionamiento evita una clase de problemas de rendimiento que son difíciles de corregir bajo carga.

Fase 5: Validación previa a producción

Una verificación de preparación para producción en bare metal no es una formalidad. Es la barrera entre un nodo aprovisionado y un nodo en el que puedes confiar realmente bajo carga.

Ejecuta una prueba de memoria antes de que el nodo entre en producción. Herramientas como memtest86+ o la prueba de memoria integrada del kernel detectan defectos de hardware que de otro modo se manifestarían como errores intermitentes en la aplicación. Esto toma tiempo; inclúyelo en tu flujo de aprovisionamiento en lugar de omitirlo porque el cronograma es ajustado.

Somete los subsistemas de CPU y almacenamiento a carga sintética antes de que lleguen las cargas de trabajo reales. stress-ng cubre CPU, memoria e I/O. fio te proporciona benchmarks de almacenamiento detallados con patrones de I/O configurables. Establece una línea base para la configuración de hardware y consérvala; cuando un nodo del mismo rol comience a comportarse de forma diferente, querrás esa línea base para comparar.

Verifica que tu agente de monitoreo, el shipper de logs y las rutas de alertas estén funcionando antes de entregar el nodo. Un nodo que no está siendo observado no está listo para producción, independientemente de lo bien aprovisionado que esté. Confirma que tu interfaz IPMI o de gestión fuera de banda sea accesible y esté autenticada de forma independiente del sistema operativo; si el sistema operativo deja de responder, esa interfaz es la que te permite recuperarte sin una visita física al rack.

Ejecuta tu runbook para un apagado ordenado y un reinicio en frío. Verifica que el nodo vuelva con la configuración esperada, que el bonding se restablezca correctamente y que tu monitoreo detecte el retorno. Haz esto antes de la primera carga de trabajo real, no después.

Mantener la checklist viva

Una checklist de despliegue bare metal solo es útil si refleja lo que realmente haces. Trátala como un documento vivo: cuando un paso del aprovisionamiento cause un problema en producción, agrega un paso de validación que lo habría detectado. Cuando una nueva vulnerabilidad de BIOS cambie tu línea base de hardening, actualiza la sección de firmware. La brecha entre la checklist que escribiste al lanzar y la infraestructura que realmente estás operando es donde viven los fallos más interesantes.