LinuxParty

Que un servidor arranque y permita instalar Linux no significa que esté preparado para trabajar en producción. Un módulo de memoria inestable, una unidad con errores pendientes, una interfaz de red mal negociada o una refrigeración insuficiente pueden pasar inadvertidos durante la instalación y provocar fallos cuando el equipo ya aloja máquinas virtuales, bases de datos o servicios internos.

La validación previa es especialmente importante al ampliar la infraestructura de una pyme, construir un laboratorio o incorporar hardware reacondicionado. El objetivo no consiste en comprobar si el servidor funciona durante cinco minutos, sino en revisar sus componentes, someterlos a una carga controlada y registrar una línea base para futuras comparaciones.

Preparar el entorno de pruebas

Las comprobaciones deben realizarse antes de copiar datos reales. Puede utilizarse una instalación temporal de Debian, Ubuntu Server, Rocky Linux o AlmaLinux, preferiblemente en una red separada del entorno de producción. Los discos empleados durante las pruebas deben estar vacíos, ya que algunas mediciones de rendimiento generan escrituras.

Antes de comprar o configurar el equipo conviene definir cuántos procesadores, ranuras de memoria, bahías, interfaces de red y fuentes de alimentación requiere la carga prevista. Para comparar diferentes configuraciones de servidores en rack y torre puede consultarse:

https://servermall.com/es/catalog/servers/

La elección no debería basarse únicamente en el número de núcleos. Una plataforma para virtualización necesita suficiente RAM y ancho de banda de memoria; un servidor de copias de seguridad requiere capacidad de almacenamiento y una controladora adecuada; una base de datos transaccional puede depender más de la latencia de los discos que de la frecuencia máxima de la CPU.

Crear un inventario del hardware

El primer paso es verificar qué componentes reconoce Linux. Para obtener información sobre los procesadores se utiliza:

lscpu

La salida muestra la arquitectura, el modelo de CPU, el número de sockets, núcleos e hilos y las extensiones de virtualización disponibles. En sistemas con varios procesadores también indica cuántos nodos NUMA ha detectado el kernel. Su distribución puede examinarse con:

numactl --hardware

NUMA divide los recursos en nodos asociados a distintos procesadores. Si una máquina virtual utiliza CPU de un nodo y memoria conectada a otro, puede aumentar la latencia. Conocer esta topología ayuda a distribuir correctamente los recursos en cargas intensivas.

Para revisar la memoria instalada:

free -h
sudo dmidecode --type memory

El primer comando indica cuánta RAM puede utilizar Linux. El segundo muestra la capacidad, el tipo, la velocidad y la ubicación de cada módulo según la información del firmware. Hay que comprobar que la capacidad total coincida con la configuración prevista y que no aparezcan como vacías ranuras que deberían estar ocupadas.

Los dispositivos PCIe y sus controladores se consultan mediante:

lspci -nnk

En la lista deberían figurar las interfaces de red, controladoras RAID, adaptadores Fibre Channel, GPU y otros dispositivos instalados. El campo Kernel driver in use permite identificar el controlador utilizado por Linux.

Buscar errores durante el arranque

Un servidor puede arrancar con normalidad y registrar, al mismo tiempo, errores corregidos o problemas de inicialización. Los avisos relevantes del arranque actual pueden consultarse así:

sudo journalctl -k -p warning..alert -b

No todos los mensajes de nivel warning indican una avería. Sin embargo, deben investigarse las referencias a errores ECC, tiempos de espera, reinicios de controladoras, enlaces PCIe degradados, fallos de entrada y salida o problemas térmicos.

Una búsqueda inicial puede hacerse con:

sudo dmesg -T | grep -Ei "error|fail|timeout|mce|edac|thermal"

El filtro facilita la revisión, pero no sustituye la lectura del contexto completo. Un mensaje aislado puede ser informativo, mientras que su repetición bajo carga puede revelar un problema real.

Comprobar la memoria RAM

La memoria ECC puede corregir determinados errores, pero los eventos repetitivos no deben ignorarse. En sistemas compatibles, rasdaemon registra los fallos de fiabilidad comunicados por el hardware y el kernel:

sudo systemctl enable --now rasdaemon
sudo ras-mc-ctl --errors

Para una prueba profunda puede utilizarse memtest86+ desde el menú de arranque. Al ejecutarse fuera del sistema operativo puede examinar más memoria que una herramienta iniciada dentro de Linux.

También es posible generar presión controlada sobre la RAM:

stress-ng --vm 4 --vm-bytes 80% --timeout 30m --metrics-brief

El comando utiliza hasta el 80% de la memoria durante treinta minutos. Debe ejecutarse únicamente en el servidor de pruebas. Al finalizar hay que volver a consultar los eventos ECC y el registro del kernel.

Examinar discos SAS, SATA y NVMe

Para identificar las unidades reconocidas por el sistema:

lsblk -o NAME,SIZE,ROTA,TYPE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS

El modelo, el número de serie y la capacidad deben coincidir con la configuración esperada. La columna ROTA ayuda a distinguir unidades rotatorias de dispositivos de estado sólido.

El estado de una unidad SATA o SAS puede revisarse con:

sudo smartctl -x /dev/sdX

Es necesario sustituir /dev/sdX por el dispositivo correcto. Conviene prestar atención a los sectores reasignados, sectores pendientes, errores no corregibles, temperatura, horas de funcionamiento y registro de errores.

Para una unidad NVMe se utiliza:

sudo nvme smart-log /dev/nvme0

Los campos más útiles son critical_warning, media_errors, percentage_used y la temperatura. Un estado general correcto es una buena señal, pero no garantiza por sí solo que la unidad esté libre de problemas. Los contadores y su evolución aportan más información.

Cuando los discos están detrás de una controladora RAID, quizá no aparezcan directamente en Linux. En ese caso debe emplearse la utilidad del fabricante, como StorCLI, PERCCLI o SSACLI, para revisar cada unidad física, la batería o caché protegida y el estado del array.

Medir el almacenamiento con seguridad

fio permite comprobar el rendimiento y la estabilidad del subsistema de almacenamiento. La prueba debe ejecutarse sobre un sistema de archivos temporal y vacío, nunca sobre un volumen que contenga datos importantes.

fio --name=prueba \
    --filename=/mnt/pruebas/fio.test \
    --size=10G \
    --rw=readwrite \
    --bs=1M \
    --direct=1 \
    --ioengine=libaio \
    --iodepth=16 \
    --runtime=300 \
    --time_based \
    --group_reporting

Además del ancho de banda, interesa observar la latencia y comprobar si aparecen errores de entrada y salida. El resultado depende del RAID, la caché, el número de discos, el tamaño de bloque y la profundidad de cola. Su principal utilidad es detectar valores anómalos y crear una referencia inicial.

Probar CPU y refrigeración

Un equipo estable en reposo puede fallar cuando todos los núcleos trabajan simultáneamente. Para generar carga durante veinte minutos:

stress-ng --cpu 0 --timeout 20m --metrics-brief

Mientras se ejecuta, las temperaturas pueden observarse con:

watch -n 2 sensors

En servidores con administración mediante IPMI también puede utilizarse:

sudo ipmitool sensor

No existe una temperatura máxima universal para todos los procesadores. Lo importante es comprobar que no se active la limitación térmica, que los ventiladores respondan a la carga y que ningún sensor alcance un estado crítico.

Validar las interfaces de red

La velocidad negociada y el estado de una interfaz Ethernet se consultan con:

sudo ethtool eno1
ip -s link show eno1

Una interfaz de 10 GbE que negocia a 1 GbE puede indicar un problema de cableado, transceptor, configuración o puerto del switch. También deben vigilarse los errores CRC, paquetes descartados y reinicios del enlace.

Para medir el rendimiento entre dos sistemas puede iniciarse iperf3 en el primero:

iperf3 -s

Desde el segundo se ejecuta una prueba con varios flujos:

iperf3 -c 192.0.2.10 -P 4 -t 60

La dirección debe sustituirse por la IP real del equipo. La medición debería repetirse en ambos sentidos mientras se comprueba que los contadores de errores no aumentan.

Verificar alimentación y gestión remota

Si el servidor dispone de fuentes redundantes, ambas deben aparecer como operativas. Los sensores IPMI pueden revisarse mediante:

sudo ipmitool sdr elist

También hay que confirmar que la consola remota permita encender el equipo, consultar alertas, acceder al arranque y montar una imagen de instalación. Esta interfaz debe mantenerse en una red administrativa protegida y utilizar credenciales diferentes de las cuentas ordinarias.

Documentar una línea base

Al terminar conviene guardar un informe con el modelo y número de serie, procesadores, memoria, unidades, versiones de firmware, temperaturas máximas y resultados de las pruebas. También deben anotarse los errores encontrados y las acciones realizadas.

Esta línea base permitirá comparar el comportamiento futuro. Si aumenta la latencia del almacenamiento, aparecen errores de red o cambian las temperaturas, será posible determinar si se trata de una variación normal o de una degradación progresiva.

Conclusión

Validar un servidor requiere más que instalar Linux y ejecutar uptime. Es necesario comprobar inventario, memoria, almacenamiento, red, refrigeración, alimentación y administración remota bajo condiciones controladas.

Ninguna prueba puede garantizar que un componente nunca fallará. Sin embargo, una revisión sistemática permite detectar configuraciones incorrectas y hardware inestable antes de que afecten a usuarios o datos reales. La regla final es sencilla: si el servidor no supera las pruebas con información prescindible, todavía no está preparado para producción.

Fuente:

Excepcional artículo, cuya fuente ha sido:

https://servermall.com/es/catalog/servers/