{"id":654,"date":"2026-10-24T12:36:45","date_gmt":"2026-10-24T11:36:45","guid":{"rendered":"https:\/\/www.darifer.net\/?p=654"},"modified":"2026-10-23T12:58:32","modified_gmt":"2026-10-23T11:58:32","slug":"azure-local-2610-una-actualizacion-centrada-en-consolidar-la-plataforma","status":"publish","type":"post","link":"http:\/\/www.darifer.net\/index.php\/2026\/10\/24\/azure-local-2610-una-actualizacion-centrada-en-consolidar-la-plataforma\/","title":{"rendered":"Azure Local 2610: una actualizaci\u00f3n centrada en consolidar la plataforma"},"content":{"rendered":"\n

Actualizaci\u00f3n, validaci\u00f3n y buenas pr\u00e1cticas para entornos de producci\u00f3n<\/strong><\/p>\n\n\n\n

Hola a tod@s,<\/p>\n\n\n\n

Volvemos con una nueva entrega sobre Azure Local<\/strong>. Despu\u00e9s de analizar c\u00f3mo Microsoft<\/strong> ha ido evolucionando la plataforma, llegamos a Azure Local 2610<\/strong>, correspondiente a la rama de octubre de 2026.<\/p>\n\n\n\n

No todas las versiones tienen que venir acompa\u00f1adas de grandes funcionalidades para ser importantes. En una plataforma de infraestructura, donde ejecutamos m\u00e1quinas virtuales y servicios cr\u00edticos, estabilidad, fiabilidad y mantenimiento son tan importantes como incorporar nuevas capacidades.<\/p>\n\n\n\n

De 2609 a 2610: una plataforma, no solo un sistema operativo<\/h1>\n\n\n\n

Azure Local 2609 <\/strong>fue principalmente una actualizaci\u00f3n 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\u00f3n coordinada de plataforma.<\/p>\n\n\n\n

    \n
  • Sistema operativo de los nodos y Lifecycle Manager.<\/li>\n\n\n\n
  • Azure Arc, agentes y extensiones de administraci\u00f3n.<\/li>\n\n\n\n
  • Firmware, drivers y Solution Builder Extension (SBE), cuando corresponda.<\/li>\n\n\n\n
  • Servicios de m\u00e1quinas virtuales, networking, storage y runtimes internos.<\/li>\n<\/ul>\n\n\n\n

    Por eso, aunque la actualizaci\u00f3n parezca peque\u00f1a, debemos tratarla con el mismo rigor que cualquier cambio de infraestructura Enterprise.<\/p>\n\n\n\n

    Principales novedades de Azure Local 2610<\/h1>\n\n\n\n

    Esta vez s\u00ed tenemos novedades funcionales importantes. Microsoft publica 2610 como la versi\u00f3n de soluci\u00f3n 12.2610.1004.41 para despliegues hiperconvergidos, acompa\u00f1ada del OS Build 26100.33650. La release tambi\u00e9n actualiza .NET 8 a 8.0.32, .NET 10 a 10.0.13 y PowerShell a 7.6.6.<\/p>\n\n\n\n

    Componente<\/strong><\/td>Azure Local 2610<\/strong><\/td><\/tr>
    Solution<\/td>12.2610.1004.41<\/td><\/tr>
    OS Build<\/td>26100.33650<\/td><\/tr>
    .NET<\/td>8.0.32 \/ 10.0.13<\/td><\/tr>
    PowerShell<\/td>7.6.6 sobre .NET 10<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Confidential VMs con AMD SEV-SNP llegan a GA<\/h2>\n\n\n\n

    En la pr\u00e1ctica, SEV-SNP protege la memoria de la VM mediante claves asociadas al procesador y a\u00f1ade comprobaciones de integridad sobre el estado de la m\u00e1quina 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.<\/p>\n\n\n\n

    Requisito operativo:<\/strong> no basta con actualizar el software. Debemos confirmar que el modelo de servidor, la generaci\u00f3n de CPU AMD EPYC Genoa, el firmware y la configuraci\u00f3n BIOS est\u00e1n soportados por el fabricante. Tambi\u00e9n conviene validar backup, monitorizaci\u00f3n, extensiones de seguridad y procedimientos de recuperaci\u00f3n con este tipo de VM.<\/p>\n\n\n\n

    Una de las novedades m\u00e1s relevantes es que las Confidential VMs con AMD SEV-SNP sobre plataformas AMD Genoa pasan a disponibilidad general. Azure Local<\/strong> incorpora as\u00ed attestation y cifrado de memoria para reforzar la protecci\u00f3n de cargas sensibles.<\/p>\n\n\n\n

    Rack-aware clusters con SAN, en preview<\/h2>\n\n\n\n

    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\u00f3n s\u00edncrona 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.<\/p>\n\n\n\n

    Antes de evaluar esta preview<\/strong> debemos revisar latencia entre salas, redundancia de fabric, zoning Fibre Channel o conectividad iSCSI, MPIO, pol\u00edticas de path failover y comportamiento ante una p\u00e9rdida simult\u00e1nea de red y almacenamiento. Preview significa que la capacidad requiere una validaci\u00f3n separada y no debe asumirse autom\u00e1ticamente como adecuada para producci\u00f3n.<\/p>\n\n\n\n

    Los cl\u00fasteres rack-aware ampl\u00edan soporte a despliegues SAN desagregados. Esto permite proteger workloads entre dos salas mediante replicaci\u00f3n sincronizada del almacenamiento y gestionar compute y storage de forma independiente. Adem\u00e1s, el asistente del Azure Portal<\/strong> permite configurar disk witness para despliegues SAN.<\/p>\n\n\n\n

    iSCSI por nodo desde Azure Portal<\/h2>\n\n\n\n

    La configuraci\u00f3n por nodo resulta \u00fatil cuando cada servidor presenta iniciadores, VLAN, direcciones IP o rutas de almacenamiento diferentes. Centralizar el flujo en Azure Portal reduce errores de transcripci\u00f3n, pero no elimina la necesidad de dise\u00f1ar correctamente MTU, redundancia de switches, aislamiento de tr\u00e1fico, CHAP si se utiliza y sesiones MPIO hacia cada target.<\/p>\n\n\n\n

    2610 permite configurar iSCSI individualmente para cada nodo desde el asistente de despliegue de Azure Portal<\/strong>. Es un cambio interesante para simplificar SAN y reducir configuraci\u00f3n manual.<\/p>\n\n\n\n

    Actualizaci\u00f3n conjunta de OS y SBE con CAU<\/h2>\n\n\n\n

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

    El punto cr\u00edtico es la compatibilidad:<\/strong> 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\u00f3n, rebalanceo o resilvering activos.<\/p>\n\n\n\n

    Cluster-Aware Updating puede coordinar en una \u00fanica ejecuci\u00f3n la actualizaci\u00f3n del sistema operativo junto con firmware y drivers OEM mediante SBE. El objetivo es reducir el tiempo de mantenimiento y la disrupci\u00f3n de los workloads.<\/p>\n\n\n\n

    Cambios de conectividad despu\u00e9s del despliegue, en preview<\/h2>\n\n\n\n

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

    Microsoft<\/strong> a\u00f1ade opciones Day-2 que antes eran m\u00e1s r\u00edgidas: actualizar la configuraci\u00f3n de proxy, habilitar Azure Arc gateway sobre una instancia ya desplegada y migrar la conectividad de public path a la arquitectura private path.<\/p>\n\n\n\n

    Seguridad: baseline ampliado y personalizable<\/h2>\n\n\n\n

    El aumento de controles ampl\u00eda la superficie evaluada frente a referencias CIS y DISA STIG. La personalizaci\u00f3n permite introducir excepciones justificadas sin perder la supervisi\u00f3n del estado deseado. Drift control ayuda a detectar o revertir cambios fuera del baseline, mientras los guardrails impiden modificar par\u00e1metros que podr\u00edan comprometer la plataforma.<\/p>\n\n\n\n

    La recomendaci\u00f3n<\/strong> es documentar cada excepci\u00f3n con propietario, motivo, riesgo y fecha de revisi\u00f3n. En un entorno regulado, esa trazabilidad es tan importante como el propio valor t\u00e9cnico del setting.<\/p>\n\n\n\n

    El security baseline pasa de 408 a 429 settings evaluados, ampliando la cobertura frente a recomendaciones CIS y DISA STIG. Adem\u00e1s, 2610 permite personalizar ajustes del baseline manteniendo drift control y guardrails para proteger configuraciones cr\u00edticas.<\/p>\n\n\n\n

    Azure Migrate conserva los recursos Arc<\/h2>\n\n\n\n

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

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

    Mejor diagn\u00f3stico y operaci\u00f3n<\/h2>\n\n\n\n

    SANDiagnostics concentra evidencias que normalmente recopilar\u00edamos desde varias capas: MPIO, Fibre Channel, iSCSI, discos, vol\u00famenes, Cluster Shared Volumes y eventos. Esto facilita entregar un paquete coherente al fabricante o a soporte. Get-SolutionHealthSummary aporta una vista r\u00e1pida de los \u00faltimos health checks, pero no sustituye el an\u00e1lisis de alertas, eventos, latencia de storage y estado de cada workload.<\/p>\n\n\n\n

    Se incorpora el rol SANDiagnostics para recopilar informaci\u00f3n de MPIO, Fibre Channel, iSCSI, discos, vol\u00famenes, CSV y logs. Tambi\u00e9n llega Get-SolutionHealthSummary, un cmdlet que resume los \u00faltimos health checks y destaca problemas cr\u00edticos o importantes.<\/p>\n\n\n\n

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

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

    Antes de actualizar a 2610<\/h1>\n\n\n\n

    1. Comprobar el estado del cl\u00faster<\/h2>\n\n\n\n

    Verificaremos nodos, storage, networking, m\u00e1quinas virtuales, Azure Arc, alertas activas, capacidad disponible y actualizaciones pendientes. Una actualizaci\u00f3n no deber\u00eda utilizarse para corregir un cl\u00faster que ya presenta problemas: primero resolvemos la incidencia y despu\u00e9s actualizamos.<\/p>\n\n\n\n

    2. Revisar hardware, firmware y SBE<\/h2>\n\n\n\n

    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\u00f3n. Cuando exista un SBE compatible, revisaremos su versi\u00f3n y requisitos.<\/p>\n\n\n\n

    3. Revisar las incidencias conocidas<\/h2>\n\n\n\n

    Antes de la ventana de mantenimiento conviene contrastar la documentaci\u00f3n oficial y buscar impactos sobre inicio o migraci\u00f3n de VMs, Trusted Launch, networking, storage, Azure Arc, Lifecycle Manager y AKS enabled by Azure Arc, si est\u00e1 desplegado.<\/p>\n\n\n\n

    Validaci\u00f3n t\u00e9cnica recomendada en laboratorio<\/h2>\n\n\n\n

    Adem\u00e1s de confirmar que el update termina correctamente, ejecutar\u00eda una prueba controlada de Live Migration, reinicio de una VM cr\u00edtica no productiva, p\u00e9rdida de un path SAN, acceso a Azure Portal, estado de Arc y recuperaci\u00f3n desde backup. En cl\u00fasteres con SAN medir\u00eda tambi\u00e9n latencia y errores MPIO antes y despu\u00e9s para disponer de una l\u00ednea base comparable.<\/p>\n\n\n\n

    Checklist de decisi\u00f3n<\/h1>\n\n\n\n
    \u00c1rea<\/strong><\/td>Validaci\u00f3n m\u00ednima<\/strong><\/td>Criterio de avance<\/strong><\/td><\/tr>
    Cl\u00faster<\/td>Sin alertas cr\u00edticas; nodos online<\/td>Salud estable<\/td><\/tr>
    Hardware<\/td>Compatibilidad, firmware, drivers y SBE<\/td>Matriz validada<\/td><\/tr>
    Workloads<\/td>VMs, red, storage, backup y AKS<\/td>Pruebas superadas<\/td><\/tr>
    Despliegue<\/td>Laboratorio o cl\u00faster canary<\/td>Paso progresivo<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    \u00bfActualizar inmediatamente?<\/h1>\n\n\n\n

    No necesariamente. En laboratorio, s\u00ed; en producci\u00f3n, prefiero un recorrido progresivo: laboratorio \u2192 validaci\u00f3n \u2192 preproducci\u00f3n \u2192 producci\u00f3n. Si administramos varios cl\u00fasteres, podemos utilizar el menos cr\u00edtico como canary, observar su comportamiento y continuar despu\u00e9s con el resto.<\/p>\n\n\n\n

    Disponible no significa instalar inmediatamente.<\/strong><\/p>\n\n\n\n

    Qu\u00e9 validar despu\u00e9s de actualizar<\/h1>\n\n\n\n
      \n
    • Estado de nodos, salud general, storage y vol\u00famenes.<\/li>\n\n\n\n
    • Conectividad, Live Migration y encendido de m\u00e1quinas virtuales.<\/li>\n\n\n\n
    • Registro y acceso desde Azure Arc y Azure Portal.<\/li>\n\n\n\n
    • Monitorizaci\u00f3n, alertas, backup y workloads cr\u00edticos.<\/li>\n\n\n\n
    • Estado de AKS enabled by Azure Arc, si se utiliza.<\/li>\n<\/ul>\n\n\n\n

      Que Lifecycle Manager indique que la actualizaci\u00f3n ha terminado correctamente no significa que el trabajo haya concluido. Una validaci\u00f3n breve y estructurada evita descubrir horas despu\u00e9s un problema que ya estaba presente al cerrar la ventana.<\/p>\n\n\n\n

      Mi visi\u00f3n sobre Azure Local 2610<\/h1>\n\n\n\n

      Lo m\u00e1s interesante de 2610 no tiene por qu\u00e9 estar \u00fanicamente en una lista de funcionalidades. Tambi\u00e9n debemos observar la direcci\u00f3n de la plataforma: operaci\u00f3n h\u00edbrida, administraci\u00f3n desde Azure<\/strong> y evoluci\u00f3n coordinada de software y hardware.<\/p>\n\n\n\n

      Consolidar tambi\u00e9n es evolucionar. En infraestructura Enterprise prefiero una versi\u00f3n que aumente la estabilidad a una release mensual que a\u00f1ada novedades sin el tiempo necesario para madurarlas, especialmente cuando debajo tenemos cargas de producci\u00f3n.<\/p>\n\n\n\n

      Para finalizar<\/h1>\n\n\n\n

      Azure Local<\/strong> contin\u00faa evolucionando a trav\u00e9s de un modelo de actualizaci\u00f3n continua. Nuestra responsabilidad como administradores es separar disponibilidad de conveniencia operativa y actualizar \u00fanicamente cuando el entorno est\u00e9 preparado.<\/p>\n\n\n\n

        \n
      • Revisar la release y la documentaci\u00f3n oficial.<\/li>\n\n\n\n
      • Validarla primero en laboratorio.<\/li>\n\n\n\n
      • Comprobar hardware, drivers, firmware y SBE.<\/li>\n\n\n\n
      • Revisar incidencias conocidas y dependencias.<\/li>\n\n\n\n
      • Actualizar progresivamente los entornos productivos.<\/li>\n\n\n\n
      • Validar plataforma y workloads despu\u00e9s del cambio.<\/li>\n<\/ul>\n\n\n\n

        Las nuevas funcionalidades llaman la atenci\u00f3n, pero en infraestructura hay algo todav\u00eda m\u00e1s importante: que un lunes por la ma\u00f1ana todo siga funcionando exactamente como esperamos.<\/p>\n\n\n\n

        Nos vemos en el pr\u00f3ximo art\u00edculo.<\/p>\n\n\n\n

        Saludos.<\/p>\n","protected":false},"excerpt":{"rendered":"

        Actualizaci\u00f3n, validaci\u00f3n y buenas pr\u00e1cticas para entornos de producci\u00f3n Hola a tod@s, Volvemos con una nueva entrega sobre Azure Local. Despu\u00e9s de analizar c\u00f3mo 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\u00f1adas de grandes funcionalidades para […]<\/p>\n","protected":false},"author":1,"featured_media":368,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,12,7,15],"tags":[13,10,17],"class_list":["post-654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-azure-local","category-general","category-hiperconvergencia","tag-azure-local","tag-hci","tag-hiperconvergencia"],"_links":{"self":[{"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts\/654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/comments?post=654"}],"version-history":[{"count":3,"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts\/654\/revisions"}],"predecessor-version":[{"id":657,"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts\/654\/revisions\/657"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/media\/368"}],"wp:attachment":[{"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/media?parent=654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/categories?post=654"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/tags?post=654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}