Actualización, validación y buenas prácticas para entornos de producción

Hola a tod@s,

Volvemos con una nueva entrega sobre Azure Local. Después de analizar cómo Microsoft ha ido evolucionando la plataforma, llegamos a Azure Local 2610, correspondiente a la rama de octubre de 2026.

No todas las versiones tienen que venir acompañadas de grandes funcionalidades para ser importantes. En una plataforma de infraestructura, donde ejecutamos máquinas virtuales y servicios críticos, estabilidad, fiabilidad y mantenimiento son tan importantes como incorporar nuevas capacidades.

De 2609 a 2610: una plataforma, no solo un sistema operativo

Azure Local 2609 fue principalmente una actualización de servicing. La lectura de 2610 debe partir de la misma idea: actualizar Azure Local no equivale a instalar un cumulative update sobre varios servidores Windows. Es una actualización coordinada de plataforma.

• Sistema operativo de los nodos y Lifecycle Manager.
• Azure Arc, agentes y extensiones de administración.
• Firmware, drivers y Solution Builder Extension (SBE), cuando corresponda.
• Servicios de máquinas virtuales, networking, storage y runtimes internos.

Por eso, aunque la actualización parezca pequeña, debemos tratarla con el mismo rigor que cualquier cambio de infraestructura Enterprise.

Principales novedades de Azure Local 2610

Esta vez sí tenemos novedades funcionales importantes. Microsoft publica 2610 como la versión de solución 12.2610.1004.41 para despliegues hiperconvergidos, acompañada del OS Build 26100.33650. La release también actualiza .NET 8 a 8.0.32, .NET 10 a 10.0.13 y PowerShell a 7.6.6.

Confidential VMs con AMD SEV-SNP llegan a GA

En la práctica, SEV-SNP protege la memoria de la VM mediante claves asociadas al procesador y añade comprobaciones de integridad sobre el estado de la máquina virtual. La attestation permite validar que la carga se ejecuta sobre una plataforma esperada antes de liberar secretos o datos sensibles. Es especialmente interesante para bases de datos, servicios de identidad y aplicaciones sujetas a requisitos regulatorios.

Requisito operativo: no basta con actualizar el software. Debemos confirmar que el modelo de servidor, la generación de CPU AMD EPYC Genoa, el firmware y la configuración BIOS están soportados por el fabricante. También conviene validar backup, monitorización, extensiones de seguridad y procedimientos de recuperación con este tipo de VM.

Una de las novedades más relevantes es que las Confidential VMs con AMD SEV-SNP sobre plataformas AMD Genoa pasan a disponibilidad general. Azure Local incorpora así attestation y cifrado de memoria para reforzar la protección de cargas sensibles.

Rack-aware clusters con SAN, en preview

El enfoque rack-aware introduce conocimiento de dominio de fallo a nivel de rack o sala. En una arquitectura desagregada, los nodos de compute y la SAN pueden evolucionar con ciclos distintos, mientras la replicación síncrona mantiene copias consistentes entre ubicaciones. El disk witness aporta un voto adicional de quorum para evitar decisiones ambiguas si se pierde conectividad entre ambos lados.

Antes de evaluar esta preview debemos revisar latencia entre salas, redundancia de fabric, zoning Fibre Channel o conectividad iSCSI, MPIO, políticas de path failover y comportamiento ante una pérdida simultánea de red y almacenamiento. Preview significa que la capacidad requiere una validación separada y no debe asumirse automáticamente como adecuada para producción.

Los clústeres rack-aware amplían soporte a despliegues SAN desagregados. Esto permite proteger workloads entre dos salas mediante replicación sincronizada del almacenamiento y gestionar compute y storage de forma independiente. Además, el asistente del Azure Portal permite configurar disk witness para despliegues SAN.

iSCSI por nodo desde Azure Portal

La configuración por nodo resulta útil cuando cada servidor presenta iniciadores, VLAN, direcciones IP o rutas de almacenamiento diferentes. Centralizar el flujo en Azure Portal reduce errores de transcripción, pero no elimina la necesidad de diseñar correctamente MTU, redundancia de switches, aislamiento de tráfico, CHAP si se utiliza y sesiones MPIO hacia cada target.

2610 permite configurar iSCSI individualmente para cada nodo desde el asistente de despliegue de Azure Portal. Es un cambio interesante para simplificar SAN y reducir configuración manual.

Actualización conjunta de OS y SBE con CAU

CAU orquesta el drenaje del nodo, aplica el contenido de la actualización, reinicia cuando es necesario y devuelve el nodo al clúster antes de continuar con el siguiente. Al integrar SBE, firmware y drivers OEM pueden avanzar en la misma ejecución que el sistema operativo, reduciendo ventanas separadas y evitando combinaciones de versiones no validadas.

El punto crítico es la compatibilidad: debemos comprobar que el paquete SBE corresponde exactamente al fabricante y modelo desplegado. Antes de iniciar conviene disponer de capacidad suficiente para mover las VMs, validar Live Migration y confirmar que no existen trabajos de reparación, rebalanceo o resilvering activos.

Cluster-Aware Updating puede coordinar en una única ejecución la actualización del sistema operativo junto con firmware y drivers OEM mediante SBE. El objetivo es reducir el tiempo de mantenimiento y la disrupción de los workloads.

Cambios de conectividad después del despliegue, en preview

Estas operaciones Day-2 son relevantes porque proxy, Arc gateway y private path forman parte de la conectividad de administración, registro y actualización. Una migración a private path debe contemplar resolución DNS, Private Endpoints, rutas, firewalls, inspección TLS y acceso a los endpoints requeridos por Azure Arc y Lifecycle Manager.

Microsoft añade opciones Day-2 que antes eran más rígidas: actualizar la configuración de proxy, habilitar Azure Arc gateway sobre una instancia ya desplegada y migrar la conectividad de public path a la arquitectura private path.

Seguridad: baseline ampliado y personalizable

El aumento de controles amplía la superficie evaluada frente a referencias CIS y DISA STIG. La personalización permite introducir excepciones justificadas sin perder la supervisión del estado deseado. Drift control ayuda a detectar o revertir cambios fuera del baseline, mientras los guardrails impiden modificar parámetros que podrían comprometer la plataforma.

La recomendación es documentar cada excepción con propietario, motivo, riesgo y fecha de revisión. En un entorno regulado, esa trazabilidad es tan importante como el propio valor técnico del setting.

El security baseline pasa de 408 a 429 settings evaluados, ampliando la cobertura frente a recomendaciones CIS y DISA STIG. Además, 2610 permite personalizar ajustes del baseline manteniendo drift control y guardrails para proteger configuraciones críticas.

Azure Migrate conserva los recursos Arc

La continuidad del recurso Arc reduce el trabajo posterior a la migración. Mantener tags, RBAC, Azure Policy, monitorización y extensiones evita recrear manualmente el gobierno de la VM al pasar desde VMware o Hyper-V. Aun así, debemos comprobar dependencias de red, identidad administrada, extensiones con configuración local y reglas que utilicen el identificador o la ubicación del recurso.

Azure Migrate puede reutilizar durante la migración los recursos de Azure Arc-enabled servers existentes en VMs origen VMware y Hyper-V. Tags, asignaciones RBAC, Azure Policy, monitorización y extensiones pueden continuar en la VM de Azure Local. Azure Migrate mantiene una cadencia independiente de la release 2610.

Mejor diagnóstico y operación

SANDiagnostics concentra evidencias que normalmente recopilaríamos desde varias capas: MPIO, Fibre Channel, iSCSI, discos, volúmenes, Cluster Shared Volumes y eventos. Esto facilita entregar un paquete coherente al fabricante o a soporte. Get-SolutionHealthSummary aporta una vista rápida de los últimos health checks, pero no sustituye el análisis de alertas, eventos, latencia de storage y estado de cada workload.

Se incorpora el rol SANDiagnostics para recopilar información de MPIO, Fibre Channel, iSCSI, discos, volúmenes, CSV y logs. También llega Get-SolutionHealthSummary, un cmdlet que resume los últimos health checks y destaca problemas críticos o importantes.

También cambia la cadencia de las Composed ISO: pasan a una publicación semestral alineada con los ciclos de validación de los OEM. Para entornos Government, US Gov Arizona entra en preview como región adicional, con soporte indicado por Microsoft hasta Impact Level 5 (IL5).

Mi lectura: 2610 no es solo una release de consolidación. Tiene cambios importantes en seguridad, SAN, conectividad Day-2, Confidential VMs y lifecycle. Para producción, las funciones marcadas como preview deben evaluarse por separado y no asumir el mismo nivel de soporte que las capacidades GA.

Antes de actualizar a 2610

1. Comprobar el estado del clúster

Verificaremos nodos, storage, networking, máquinas virtuales, Azure Arc, alertas activas, capacidad disponible y actualizaciones pendientes. Una actualización no debería utilizarse para corregir un clúster que ya presenta problemas: primero resolvemos la incidencia y después actualizamos.

2. Revisar hardware, firmware y SBE

Si utilizamos hardware integrado o validado por fabricantes como Dell, HPE o Lenovo, debemos comprobar sus recomendaciones. BIOS, controladoras, NIC, drivers y firmware forman parte de la estabilidad de la solución. Cuando exista un SBE compatible, revisaremos su versión y requisitos.

3. Revisar las incidencias conocidas

Antes de la ventana de mantenimiento conviene contrastar la documentación oficial y buscar impactos sobre inicio o migración de VMs, Trusted Launch, networking, storage, Azure Arc, Lifecycle Manager y AKS enabled by Azure Arc, si está desplegado.

Validación técnica recomendada en laboratorio

Además de confirmar que el update termina correctamente, ejecutaría una prueba controlada de Live Migration, reinicio de una VM crítica no productiva, pérdida de un path SAN, acceso a Azure Portal, estado de Arc y recuperación desde backup. En clústeres con SAN mediría también latencia y errores MPIO antes y después para disponer de una línea base comparable.

Checklist de decisión

¿Actualizar inmediatamente?

No necesariamente. En laboratorio, sí; en producción, prefiero un recorrido progresivo: laboratorio → validación → preproducción → producción. Si administramos varios clústeres, podemos utilizar el menos crítico como canary, observar su comportamiento y continuar después con el resto.

Disponible no significa instalar inmediatamente.

Qué validar después de actualizar

• Estado de nodos, salud general, storage y volúmenes.
• Conectividad, Live Migration y encendido de máquinas virtuales.
• Registro y acceso desde Azure Arc y Azure Portal.
• Monitorización, alertas, backup y workloads críticos.
• Estado de AKS enabled by Azure Arc, si se utiliza.

Que Lifecycle Manager indique que la actualización ha terminado correctamente no significa que el trabajo haya concluido. Una validación breve y estructurada evita descubrir horas después un problema que ya estaba presente al cerrar la ventana.

Mi visión sobre Azure Local 2610

Lo más interesante de 2610 no tiene por qué estar únicamente en una lista de funcionalidades. También debemos observar la dirección de la plataforma: operación híbrida, administración desde Azure y evolución coordinada de software y hardware.

Consolidar también es evolucionar. En infraestructura Enterprise prefiero una versión que aumente la estabilidad a una release mensual que añada novedades sin el tiempo necesario para madurarlas, especialmente cuando debajo tenemos cargas de producción.

Para finalizar

Azure Local continúa evolucionando a través de un modelo de actualización continua. Nuestra responsabilidad como administradores es separar disponibilidad de conveniencia operativa y actualizar únicamente cuando el entorno esté preparado.

• Revisar la release y la documentación oficial.
• Validarla primero en laboratorio.
• Comprobar hardware, drivers, firmware y SBE.
• Revisar incidencias conocidas y dependencias.
• Actualizar progresivamente los entornos productivos.
• Validar plataforma y workloads después del cambio.

Las nuevas funcionalidades llaman la atención, pero en infraestructura hay algo todavía más importante: que un lunes por la mañana todo siga funcionando exactamente como esperamos.

Nos vemos en el próximo artículo.

Saludos.