← Volver a las notas de campoNota de campo 03 — Hyper-V

Infraestructura temporal. Tomada en serio.

Construcción de clúster Hyper-V temporal y migración DEV/UAT

Una plataforma de transición fiable, construida con hardware retirado de servicio mientras la infraestructura más reciente se trasladaba a otro lugar.

ContextoOrganización británica de servicios tecnológicos
FunciónIngeniero de infraestructuras
En detalleEstudio de caso técnico sin datos sensibles, disponible en PDF, en inglés.

La situación

Los hosts más recientes debían trasladarse a un centro de datos antes de que llegara el hardware de sustitución definitivo. Los entornos de desarrollo y UAT seguían necesitando una plataforma, así que la opción práctica fue recuperar tres servidores HPE retirados de servicio y construir un clúster temporal con equipos que ya estaban en las instalaciones.

Lo que encontré

El hardware antiguo podía ejecutar Windows Server 2022 e integrarse con almacenamiento SAN compartido, pero la validación del clúster reveló un fallo mucho más interesante. La conectividad de red habitual funcionaba, mientras que las llamadas de administración WinRM, CIM, WMI e Hyper-V fallaban entre hosts. Eso hacía cada vez menos convincentes las explicaciones más evidentes relacionadas con la red, el cortafuegos, las directivas y la autenticación.

Lo que cambié

Reinstalé los hosts, documenté la correspondencia entre las interfaces de red físicas y los puertos de los switches, configuré las VLAN necesarias, creé el clúster de conmutación por error y separé el tráfico de gestión, migración en vivo y máquinas virtuales. El fallo de administración remota se localizó en el comportamiento de las tarjetas de red antiguas; ajustar las opciones de offload y virtualización restableció el tráfico de gestión. Después validé la migración en vivo, el drenaje de nodos (traslado de sus máquinas virtuales a otros nodos) y el reinicio y recuperación controlados, antes de preparar el entorno de origen y utilizar Hyper-V Replica para la migración DEV/UAT.

El resultado

Tres servidores con una década de antigüedad se convirtieron en un clúster de conmutación por error temporal y operativo, con almacenamiento compartido, conectividad resiliente para las máquinas virtuales y un plan de reversión documentado. La migración pudo avanzar mientras continuaba la transición del centro de datos, en lugar de esperar meses al hardware de sustitución.

Lo que me llevo al siguiente proyecto

Temporal no significa improvisado. Si un sistema provisional va a soportar cargas de trabajo reales, merece una separación clara de los distintos tipos de tráfico, validación, reversión y suficiente documentación para que «temporal» no acabe convirtiéndose discretamente en «misterioso».

¿Quieres saber más?

El estudio de caso completo incluye los detalles de implementación, el diagnóstico y la documentación técnica que sustentan esta nota de campo. El PDF está en inglés.