Qué hacemos
Reparación de hardware Mantenimiento de servidores Recuperación de datos Ampliación & upgradePor fabricante
Dell PowerEdge HPE ProLiant Lenovo ThinkSystem Fujitsu Primergy Supermicro IBM System x / Power Acer AltosIntervención & diferenciadores
Datacenter Lombardía Aruba Ponte San Pietro Más allá del soporte del fabricanteActualización de firmware: planificada, no improvisada.
Firmware de BIOS, BMC, controladoras RAID, NIC, expansión y microcode de CPU: las actualizaciones del fabricante suelen ser obligatorias por security advisory o por compatibilidad con las cargas de trabajo más recientes, pero aplicadas sin planificación pueden romper la producción. Matriz de compatibilidad verificada, saltos intermedios obligatorios respetados, plan de rollback documentado.
Tres riesgos típicos de una actualización de firmware mal gestionada.
- Saltos de versión no admitidos: algunos firmware exigen una actualización intermedia (p. ej. de iLO 5 v2.40 a v3.00 pasando por v2.78). Saltárselos es la causa número uno de sistemas que no arrancan tras la actualización.
- Desajuste entre firmware y carga de trabajo: una versión nueva puede cambiar el valor por defecto de una función (p. ej. SR-IOV, UEFI Secure Boot) y alterar el comportamiento del sistema operativo ya instalado.
- Restricciones de licenciamiento: algunas funciones del fabricante quedan deshabilitadas a partir de determinadas versiones de firmware si la licencia no es coherente.
Pre-flight, aplicación, validación.
- Pre-flight: verificación de la matriz de compatibilidad del fabricante, lectura de las release notes para detectar impactos en licenciamiento y funciones, confirmación de los saltos intermedios obligatorios.
- Backup de configuración: exportación de BIOS, backup de la configuración iDRAC/iLO, volcado de la configuración de la controladora RAID, capturas de los ajustes de arranque.
- Plan de rollback documentado: cómo devolver la máquina a la versión anterior si surgen problemas.
- Aplicación en la ventana acordada: out-of-band cuando es posible (vía iDRAC / iLO / XClarity sin parar el sistema operativo), in-band si es necesario.
- Validación posterior a la actualización: pruebas de estrés dirigidas antes de volver a producción, verificación de las funciones críticas, comparación de sensores antes/después.
Las preguntas que más nos hacen.
¿Qué firmware necesita actualizarse con más urgencia?
Por orden de criticidad: 1) microcode de CPU con security advisory (p. ej. mitigaciones Spectre/Meltdown y posteriores), 2) firmware del BMC (iDRAC/iLO/XClarity) con CVE abiertos, por estar expuestos en la red de management, 3) firmware de la controladora RAID cuando hay bugs conocidos en el rebuild o en el reconocimiento de discos, 4) BIOS/UEFI para compatibilidad con CPU/RAM nuevas. El fabricante publica security advisory: los monitorizamos para los clientes que lo solicitan.
¿La actualización requiere parar el sistema?
Depende del componente. iDRAC/iLO/BMC: a menudo sin parar el sistema operativo. BIOS/UEFI: requiere reinicio. Microcode de CPU: requiere reinicio. Controladora RAID: normalmente sin parada si la controladora admite la actualización en línea (la mayoría de los modelos recientes). Planificamos las actualizaciones en una única ventana para minimizar el número de reinicios necesarios.
¿Puedo saltarme versiones para llegar antes a la última?
Casi nunca sin riesgo. La matriz de compatibilidad del fabricante indica los upgrade path admitidos: donde se prescriben saltos intermedios, omitirlos suele romper el proceso (sistema que no arranca, BMC que se queda en modo recovery). Lo verificamos sistemáticamente antes de proponer un plan.