Comparteix a través de

Planificación de la migración de recursos de IaaS del modelo clásico a Azure Resource Manager

  • Article

Se aplica a: ✔️ Máquinas virtuales Linux ✔️ Máquinas virtuales Windows

Importante

En la actualidad, aproximadamente el 90 % de las VM de IaaS usan Azure Resource Manager. A partir del 28 de febrero de 2020, las máquinas virtuales clásicas han quedado en desuso y se retirarán por completo el 6 de septiembre de 2023. Obtenga más información sobre esta caída en desuso y cómo se verá afectado.

Aunque Azure Resource Manager ofrece muchas características increíbles, es fundamental planear la trayectoria de migración para asegurarse de que el proceso se desarrolla con facilidad. Dedicar tiempo a la planificación garantizará que no se planteen problemas al ejecutar las actividades de migración.

Nota

El equipo de asesoramiento al cliente de Azure y los arquitectos de soluciones en la nube han contribuido significativamente en la elaboración de la guía siguiente en colaboración con los clientes en relación con la migración de entornos grandes. Habida cuenta de que este documento estará sujeto a actualizaciones continuas a medida que surjan nuevos patrones de éxito, resulta conveniente consultarlo de vez en cuando para ver si existen nuevas recomendaciones.

La trayectoria de migración consta de cuatro fases generales:

Fases de migración

Plan

Consideraciones técnicas y compromisos

En función de la envergadura de los requisitos técnicos, de las zonas geográficas y de las prácticas operativas, debería tener en cuenta lo siguiente:

  1. ¿Por qué le interesa contar con Azure Resource Manager en su organización? ¿Por qué motivos empresariales desea realizar una migración?
  2. ¿Cuáles son las razones técnicas para disponer de Azure Resource Manager? ¿De qué servicios adicionales de Azure desearía beneficiarse, si procede?
  3. ¿Qué aplicación o conjuntos de máquinas virtuales se incluyen en la migración?
  4. ¿Qué escenarios son compatibles con la API de migración? Revise las configuraciones y características no admitidas.
  5. ¿Los equipos operativos ahora admiten aplicaciones y máquinas virtuales tanto en el modelo clásico como en Azure Resource Manager?
  6. ¿Cómo Azure Resource Manager cambia los procesos de creación de informes, la supervisión, la administración y la implementación de máquinas virtuales, en caso de que sea posible? ¿Es necesario actualizar los scripts de implementación?
  7. ¿Cuál es el plan de comunicaciones para avisar a las partes interesadas (usuarios finales, propietarios de aplicaciones y propietarios de infraestructuras)?
  8. Según la complejidad del entorno, ¿debe haber un período de mantenimiento durante el cual la aplicación no está disponible para los usuarios finales y los propietarios de aplicaciones? En su caso, ¿durante cuánto tiempo?
  9. ¿Cuál es el plan de aprendizaje para asegurarse de que las partes interesadas conocen y dominan Azure Resource Manager?
  10. ¿Cuál es el plan de administración de programas o de proyectos para la migración?
  11. ¿Cuáles son las escalas de tiempo para la migración de Azure Resource Manager y para otros mapas de rutas tecnológicos relacionados? ¿Están perfectamente alineados?

Patrones de éxito

Los clientes de éxito disponen de planes detallados en los que se abordan, documentan y administran las preguntas anteriores. Asegúrese de que los planes de migración se comunican de forma amplia a los patrocinadores y a las partes interesadas. Adquiera conocimientos sobre las opciones de migración; se recomienda leer este documento de migración a continuación.

Errores que hay que evitar

  • Errores de planificación. Los pasos tecnológicos de esta migración se han comprobado y el resultado es predecible.
  • En todos los escenarios se tendrá en cuenta la suposición de que la plataforma admite la API de migración. Leer las configuraciones y características no admitidas para saber qué escenarios se admiten.
  • Ausencia de planificación de interrupciones potenciales de la aplicación para los usuarios finales. Planee suficiente búfer para advertir a los usuarios finales del tiempo durante el cual la aplicación posiblemente no estará disponible.

Análisis de laboratorio

Replicación de un entorno y realización de una migración de prueba

Nota

La replicación exacta de un entorno existente se ejecuta mediante una herramienta en la que ha contribuido la comunidad que no es compatible oficialmente con el Soporte técnico de Microsoft. Por lo tanto, se trata de un paso opcional, pero es la mejor manera de encontrar los problemas sin tocar los entornos de producción. Si no tiene la opción de usar una herramienta en la que ha contribuido la comunidad, lea la recomendación Simulacro de validación, preparación y anulación a continuación.

Realizar un análisis de laboratorio de un escenario exacto (proceso, red y almacenamiento) es la mejor forma de asegurar una migración sin problemas. Esto le ayudará a garantizar:

  • Que dispone para el análisis de un laboratorio totalmente independiente o de un entorno existente que no sea de producción. Se recomienda un laboratorio completamente independiente que se pueda migrar varias veces y que se pueda modificar de forma destructiva. A continuación se indican los scripts para recopilar e hidratar metadatos de suscripciones reales.

  • Es una buena idea crear el laboratorio en una suscripción independiente. El motivo es que el laboratorio se desactivará varias veces, por lo que disponer de una suscripción aislada e independiente reducirá la posibilidad de eliminar por error cualquier elemento real.

    Esto puede realizarse con la herramienta AsmMetadataParser. Aquí puede encontrar más información sobre esta herramienta.

Patrones de éxito

A continuación se indican problemas detectados en muchas de las migraciones más grandes. No se trata de una lista exhaustiva, por lo que debe remitirse a Configuraciones y características no admitidas para más detalles. Puede encontrarse o no con estos problemas técnicos, pero, de plantearse, podrá tener una experiencia más fluida si los soluciona antes de intentar realizar la migración.

  • Realice un simulacro de validación, preparación y anulación: se trata quizás del paso más importante para asegurarse de que la migración del modelo clásico a Azure Resource Manager se realiza correctamente. La API de migración se compone de tres pasos principales: validación, preparación y confirmación. Con la validación se leerá el estado del entorno clásico y se devolverá un resultado de todos los problemas. Sin embargo, como algunos problemas pueden existir en la pila de Azure Resource Manager, la validación no lo detectará todo. En el paso siguiente del proceso de migración, la preparación ayudará a exponer los problemas detectados. Con la preparación, todos los metadatos se moverán del modelo clásico a Azure Resource Manager, pero no se confirmará la migración ni se eliminará ni modificará nada del modelo clásico. El simulacro conlleva preparar la migración y, después, anular (no confirmar) la preparación de la migración. El objetivo del simulacro de validación, preparación y anulación es que todos los metadatos se encuentren en la pila de Azure Resource Manager, para después examinarlos (mediante programación o en el portal) y verificar que todo se ha migrado correctamente, pero también con el propósito de abordar los problemas técnicos. También le permitirá hacerse una idea de la duración de la migración, a fin de que pueda planear el tiempo de inactividad. Un simulacro de validación, preparación y anulación no causa ningún tiempo de inactividad al usuario, por lo que no produce ninguna interrupción del uso de la aplicación.

    • Será necesario solucionar los puntos siguientes antes del simulacro, aunque, en caso de omitirlos, la prueba de simulacro vaciará con seguridad estos pasos de preparación. Durante la migración empresarial, se ha observado que el simulacro es una forma segura e inestimable de garantizar la preparación de la migración.
    • Cuando la preparación se encuentra en ejecución, el plano de control (operaciones de administración de Azure) se bloquearán en toda la red virtual, por lo que no se puede realizar ninguna modificación en los metadatos de máquinas virtuales durante el proceso de validación, preparación y anulación. No obstante, en caso contrario, ninguna función de la aplicación (Escritorio remoto, uso de máquina virtual, etc.) se verá afectada. Los usuarios de las máquinas virtuales no sabrán que el simulacro está en ejecución.

  • VPN y circuitos ExpressRoute. Actualmente no se pueden migrar las puertas de enlace de ExpressRoute con vínculos de autorización sin tiempos de inactividad. Para consultar una solución alternativa, vea Migración de circuitos ExpressRoute y las redes virtuales asociadas del modelo de implementación clásica a Resource Manager.

  • Extensiones de máquina virtual: las extensiones de máquina virtual posiblemente son uno de los obstáculos más importantes para migrar las máquinas virtuales en ejecución. La corrección de extensiones de máquina virtual puede tardar de 1 a 2 días, por lo que es necesario realizar la planificación teniendo esto en cuenta. Se precisa de un agente de Azure operativo para informar del estado de las extensiones de las máquinas virtuales en ejecución. Si se notifica un estado incorrecto de una máquina virtual en ejecución, la migración se detendrá. El agente no necesita estar operativo para habilitar la migración, pero, si existen extensiones en la máquina virtual, se necesitará un agente operativo Y una conectividad saliente a Internet con DNS para que la migración progrese.

    • Si se pierde la conectividad con un servidor DNS durante la migración, hay que eliminar todas las extensiones de máquina virtual, excepto BGInfo v1.*, de todas las máquinas virtuales antes de preparar la migración y, después, volver a agregarlas a la máquina virtual después de la migración de Azure Resource Manager. Esto solo se aplica a las máquinas virtuales en ejecución. Si las máquinas virtuales se detienen cuando están desasignadas, no es necesario eliminar las extensiones de la máquina virtual. Nota: Muchas extensiones, como la supervisión de Defender for Cloud y Azure Diagnostics, se reinstalarán automáticamente después de la migración, por lo que su eliminación no plantea ningún problema.

    • Además, asegúrese de que los Grupos de seguridad de red no restrinjan el acceso saliente a Internet. Esto puede suceder con algunas configuraciones de Grupos de seguridad de red. El acceso saliente a Internet, y DNS, resulta necesario para migrar las extensiones de máquina virtual a Azure Resource Manager.

    • Hay dos versiones de la extensión BGInfo: v1 y v2. Si la máquina virtual se creó mediante Azure Portal o PowerShell, probablemente tendrá la extensión v1. Esta extensión no deben quitarse y la API de migración la omitirá, es decir, que no se migrará. No obstante, si la máquina virtual clásica se ha creado con el nuevo Azure Portal, probablemente tenga la versión v2 basada en JSON de BGInfo, que sí se puede migrar a Azure Resource Manager, siempre que el agente esté operativo y que haya acceso saliente a Internet y DNS.

    • Opción de corrección 1. Si sabe que las máquinas virtuales no tendrán acceso saliente a Internet, un servicio DSN activo y agentes de Azure operativos en las máquinas virtuales, desinstale las extensiones de máquina virtual como parte de la migración antes de la fase de preparación y luego reinstálelas después de la migración.

    • Opción de corrección 2. Si las extensiones de máquina virtual plantean un gran obstáculo, otra opción consiste en apagar o desasignar todas las máquinas virtuales antes de la migración. Migre las máquinas virtuales desasignadas y luego reinícielas en Azure Resource Manager. Aquí la ventaja es que las extensiones de máquina virtual se migrarán. El inconveniente es que todas las IP virtuales públicas se perderán, algo que no tiene sentido, ya que las máquinas virtuales se apagarán con un impacto mucho mayor en las aplicaciones operativas.

      Nota

      Si se configura una directiva de Microsoft Defender para la nube con respecto a las VM en ejecución que se van a migrar, es necesario detener dicha directiva de seguridad antes de quitar las extensiones, ya que, de lo contrario, la extensión de supervisión de seguridad se reinstalará automáticamente en la VM después de quitarla.

  • Conjuntos de disponibilidad: para migrar una red virtual (vNet) a Azure Resource Manager, todas las máquinas virtuales contenidas en la implementación clásica, es decir, el servicio en la nube, deben encontrarse en un conjunto de disponibilidad, o bien ninguna máquina virtual debe pertenecer a ningún conjunto de disponibilidad. Azure Resource Manager no admite que haya más de un conjunto de disponibilidad en el servicio en la nube; de ser así, la migración se detendrá. Además, no puede haber solo algunas máquinas virtuales en un conjunto de disponibilidad y hay máquinas virtuales que no están en ningún conjunto de disponibilidad. Para solucionar esto, será necesario corregir o reorganizar el servicio en la nube. Tenga esto en cuenta para realizar la planificación, ya que esta operación puede llevar bastante tiempo.

  • Implementaciones de roles web y roles de trabajo: Cloud Services con roles web y roles de trabajo no se puede migrar a Azure Resource Manager. Hay que quitar primero los roles web y los roles de trabajo de la red virtual para que la migración pueda empezar. Una solución habitual consiste solo en mover las instancias de roles web y de roles de trabajo a una red virtual clásica independiente que también esté vinculada a un circuito ExpressRoute, o bien en migrar el código a App Services PaaS más recientes (este tema queda fuera del ámbito de este documento). En el caso de reimplementación anterior, cree una red virtual clásica nueva, mueva los roles web y los roles de trabajo a esa nueva red virtual o reimpleméntelos ahí y luego elimine las implementaciones de la red virtual que se va a migrar. No se requiere ningún cambio de código. La nueva funcionalidad Emparejamiento de red virtual se puede utilizar para emparejar la red virtual clásica que contiene los roles web y los roles de trabajo con otras redes virtuales de la misma región de Azure, como la red virtual que se va a migrar (después de que termine la migración de la red virtual, ya que las máquinas virtuales emparejadas no se pueden migrar), a fin de ofrecer las mismas funcionalidades sin perder rendimiento y sin penalizaciones de latencia o ancho de banda. Gracias a la adición del Emparejamiento de red virtual, las implementaciones de roles web y roles de trabajo ahora pueden mitigarse con facilidad y no bloquean la migración a Azure Resource Manager.

  • Cuotas de Azure Resource Manager: las regiones de Azure tienen cuota y límites independientes para el modelo clásico y Azure Resource Manager. Aunque en un escenario de migración no se utiliza ningún hardware nuevo (se están cambiando las máquinas virtuales existentes del modelo clásico a Azure Resource Manager) , todavía es necesario que haya cuotas de Azure Resource Manager con capacidad suficiente para poder iniciar la migración. A continuación, se especifican los límites principales con los que se han detectado problemas. Abra un vale de soporte sobre cuotas para aumentar los límites.

    Nota

    Estos límites hay que aumentarlos en la misma región a la que se va a migrar el entorno actual.

    • Interfaces de red

    • Equilibradores de carga

    • Direcciones IP públicas

    • Direcciones IP públicas estáticas

    • Núcleos

    • Grupos de seguridad de red

    • Tablas de ruta

      Puede comprobar las cuotas actuales de Azure Resource Manager mediante los comandos siguientes con la última versión de la CLI de Azure.

      Proceso (núcleos, conjuntos de disponibilidad)

      az vm list-usage -l <azure-region> -o jsonc

      Red (redes virtuales, direcciones IP públicas estáticas, direcciones IP públicas, grupos de seguridad de red, interfaces de red, equilibradores de carga y tablas de rutas)

      az network list-usages -l <azure-region> -o jsonc

      Almacenamiento (cuenta de almacenamiento)

      az storage account show-usage

  • Límites de la API de Azure Resource Manager: si tiene un entorno lo suficientemente grande (por ejemplo, >400 máquinas virtuales en una red virtual), puede alcanzar los límites predeterminados de la API para escrituras (actualmente 1200 escrituras/hora) en Azure Resource Manager. Antes de iniciar la migración, debe presentar un vale de soporte para aumentar este límite en la suscripción.

  • Estado de máquina virtual de tiempo de espera de aprovisionamiento agotado: si alguna máquina virtual presenta el estado Tiempo de espera de aprovisionamiento agotado, es necesario resolver este problema antes de la migración. La única manera de hacerlo es que el tiempo de inactividad, mediante el desaprovisionamiento y el reaprovisionamiento de la máquina virtual, es decir, eliminarla, conservar el disco y volver a crearla.

  • Estado de máquina virtual RoleStateUnknown: si la migración se detiene debido a un mensaje de error de estado del rol desconocido, inspeccione la máquina virtual en el portal y asegúrese de que esté en funcionamiento. Este error suele desaparecer por sí solo (no se precisa de ninguna corrección) transcurridos unos minutos, suele ser de carácter transitorio y suele detectarse durante las operaciones de inicio, detención y reinicio de una máquina virtual. Práctica recomendada: vuelva a intentar la migración después de unos minutos.

  • El clúster de Fabric no existe: en algunos casos, determinadas máquinas virtuales no se pueden migrar por distintas razones poco comunes. Uno de estos casos conocidos se da si la máquina virtual se ha creado recientemente (durante la última semana más o menos) y ha iniciado un clúster de Azure que aún no está equipado para cargas de trabajo de Azure Resource Manager. Recibirá un error que dice que el clúster de Fabric no existe y no se puede migrar la máquina virtual. Normalmente, basta con esperar un par de día para que este problema concreto se resuelva, ya que el clúster no tardará en estar habilitado para Azure Resource Manager. Sin embargo, una solución inmediata consiste en stop-deallocate la máquina virtual, continuar después con la migración e iniciar la copia de seguridad de la máquina virtual en Azure Resource Manager después de la migración.

Errores que hay que evitar

  • No use métodos abreviados para omitir las migraciones del simulacro de validación, preparación y anulación.
  • La mayoría de los problemas potenciales, si no todos, se detectarán durante los pasos del simulacro de validación, preparación y anulación.

Migración

Consideraciones técnicas y compromisos

Ahora está listo porque ha trabajado para resolver los problemas conocidos en su entorno.

Para las migraciones reales, conviene tener en cuenta lo siguiente:

  1. Planifique y programe la red virtual (unidad más pequeña de migración) con mayor prioridad. Céntrese primero en las redes virtuales sencillas y continúe después con las más complicadas.
  2. La mayoría de los clientes tendrán entornos de producción y de no producción. Programe la producción en última instancia.
  3. (OPCIONAL) Programe un tiempo de inactividad por mantenimiento con una gran cantidad de búfer en caso de que surjan problemas inesperados.
  4. Comuníquese con los equipos de soporte y póngase de acuerdo con ellos en caso de que surjan problemas.

Patrones de éxito

Es necesario tener en cuenta y abordar la orientación técnica de la sección de análisis de laboratorio anterior antes de realizar la migración real. Con las pruebas oportunas, la migración realmente no es ningún evento. Para entornos de producción, puede resultar útil contar con soporte técnico adicional, como un asociado de Microsoft de confianza o Microsoft Premier Services.

Errores que hay que evitar

El hecho de no realizar las pruebas completas puede generar problemas y retrasos en la migración.

Después de la migración

Consideraciones técnicas y compromisos

Ahora que ya está en Azure Resource Manager, maximice la plataforma. Lea la información general de Azure Resource Manager para obtener información sobre otras ventajas.

Puntos que se deben tener en cuenta:

  • Agrupe la migración con otras actividades. La mayoría de los clientes optan por una ventana de mantenimiento de la aplicación. En su caso, podría usar este tiempo de inactividad para habilitar otras funcionalidades de Azure Resource Manager, como el cifrado y la migración a Managed Disks.
  • Revise los motivos técnicos y empresariales para migrar a Azure Resource Manager; habilite los servicios adicionales disponibles solo en Azure Resource Manager que sean aplicables a su entorno.
  • Modernice el entorno con servicios PaaS.

Patrones de éxito

Determine qué servicios desea habilitar en Azure Resource Manager. Muchos clientes encuentran atractivos los siguientes para sus entornos de Azure:

Errores que hay que evitar

Recuerde por qué ha iniciado esta trayectoria de migración del modelo clásico a Azure Resource Manager. ¿Cuáles eran los objetivos empresariales originales? ¿Ha conseguido el objetivo empresarial?

Pasos siguientes