Microsoft soluciona un problema que afecta a los clústeres y máquinas virtuales en Windows Server

Microsoft acaba de publicar el parche KB5063877 para Windows Server 2019. Esta actualización detiene los reinicios en bucle de las máquinas virtuales y los repetidos apagados del servicio de clúster reportados desde la instalación del parche de julio. De esta forma, los administradores obtienen un valioso tiempo de actividad: se acabaron los nodos bloqueados, los registros saturados con errores 7031 y los volúmenes cifrados con BitLocker inaccesibles en los volúmenes compartidos de clúster. Requisitos previos: implementar la SSU KB5005112 y, a continuación, enviar la actualización KB5063877 a través de Windows Update, WSUS o el Catálogo. El tiempo apremia; algunos equipos ya han programado un periodo de mantenimiento nocturno para proteger sus cargas de trabajo críticas antes del próximo pico de actividad. Parche KB5063877: Comprensión de la causa raíz del problema En julio, el parche KB5062557 puso en duda varias granjas de clústeres de conmutación por error. El servicio de clúster se detenía repentinamente, reiniciaba los nodos y se negaba a reintegrarlos. Como resultado, las máquinas virtuales de Hyper-V implosionaban, presentando apagados inesperados mientras las aplicaciones seguían convencidas de estar protegidas por alta disponibilidad. Los volúmenes CSV cifrados también causaban un error de acceso, dejando los discos virtuales girando en un bucle de bloqueo de BitLocker. El nuevo paquete acumulativo mensual de Redmond aborda específicamente esta anomalía. Restaura la lógica interna del árbitro de clúster, evita la cuarentena innecesaria de nodos y corrige la gestión de memoria que desencadenó la cascada de fallos. Las pruebas realizadas en un laboratorio de cuatro hosts confirman que, 30 segundos después del reinicio, cada rol vuelve a estar en línea sin previo aviso. Impacto directo en los entornos de Hyper-V y los SLA empresariales.Un proveedor de servicios parisino que aloja 200 máquinas virtuales de bases de datos cuantificó el daño: una pérdida del 17 % de disponibilidad entre dos ciclos de parches. Las máquinas virtuales críticas arrancan, fallan y se reinician hasta diez veces antes de reincorporarse al clúster. Los usuarios finales solo ven una interfaz congelada; en el área administrativa, el equipo detecta picos de CPU e intercambios masivos, indicios del sobrecalentamiento que precede a una interrupción total. En System Center, los informes de rendimiento se vuelven rojos; los paneles del Centro de administración de Windows anuncian un número récord de 7031 eventos.

Desde la aplicación de KB5063877, la misma tabla ahora muestra cero alertas críticas en 48 horas. El consumo de CPU se está normalizando, las conexiones SQL están volviendo a su latencia nominal y los acuerdos de nivel de servicio (SLA) han vuelto a la normalidad. Los equipos de monitorización, a veces acostumbrados al pánico de las 2 de la madrugada, finalmente pueden respirar aliviados. Implementar la actualización sin bloquear la producción.

Primer paso: validación sin conexión. Un clon del anillo de producción recibe primero la SSU y, a continuación, la KB5063877. Los ingenieros inician una conmutación por error manual, supervisan los registros y verifican que cada máquina virtual monte sus discos CSV sin demora. A continuación, llega la ventana de mantenimiento: dos nodos a la vez, nunca más, para evitar la pérdida de quórum. Los scripts de PowerShell automatizan la reubicación de roles y limitan la intervención humana a unos pocos comandos. Azure Stack HCI sigue el mismo procedimiento, pero el portal de Arc acelera la entrega. Con un solo clic, la actualización conmuta por error a los hosts, mientras los servicios en la nube siguen respondiendo. Por lo tanto, las infraestructuras híbridas se benefician de una ventaja inicial: menos parches, más servicio. Supervisión posterior a la aplicación de parches: herramientas y señales que no deben pasarse por alto. Una vez que la tormenta ha pasado, es hora de la trazabilidad. El módulo de estado de Active Directory. Debe confirmar que los objetos del clúster hayan vuelto a estar en fase; un cambio que indique la infame contraseña de CNO no sincronizada podría causar otra desconexión. En el host, el comando Get-ClusterLog proporciona una vista granular: busque cierres repentinos del servicio o tiempos de espera de RPC superiores a 20 segundos.

En el Centro de administración de Windows, la pestaña «Rendimiento» muestra la curva de IOPS; cualquier nivel anormal justifica una investigación. Finalmente, System Center Operations Manager puede generar una alerta si reaparece el evento 7031. El objetivo es claro: identificar la más mínima recaída antes de que el usuario envíe un ticket.

¿Qué sucede si el error persiste a pesar del parche? Para algunos clientes, el servicio de clúster sigue fallando incluso después de la actualización KB5063877. Microsoft recomienda entonces habilitar un volcado de memoria circular y contactar con el soporte técnico empresarial; a veces se proporciona un parche privado adicional en 24 horas. Los administradores también informan de la eliminación temporal de un agente antivirus antiguo, responsable de inyectar un controlador en la ruta de RPC.

Otra posibilidad: comprobar la versión del microcódigo de la CPU. Un host obsoleto puede generar una excepción de hardware que el programador no gestiona; en este caso, actualizar la BIOS resuelve el reinicio en cadena. Finalmente, un simple cambio a un dispositivo de almacenamiento diferente, como un NAS o una SAN, aísla los problemas relacionados con el firmware desactualizado de la controladora RAID. De esta forma, la infraestructura vuelve a funcionar correctamente, lista para la siguiente tanda de parches. Fuente:www.bleepingcomputer.com