Rehospedaje de una aplicación local mediante la migración a máquinas virtuales de Azure y Azure SQL Managed Instance

En este artículo se muestra cómo la empresa ficticia Contoso migra una aplicación front-end de Windows .NET de dos niveles que se ejecuta en máquinas virtuales de VMware a una máquina virtual de Azure mediante el servicio Azure Migrate. También se muestra cómo Contoso migra la base de datos de la aplicación a Azure SQL Managed Instance.

SmartHotel360, la aplicación usada en este ejemplo, se proporciona como software de código abierto. Si quiere utilizarla para realizar sus propias pruebas, descárguela en GitHub.

Impulsores del negocio

El equipo directivo de TI de Contoso ha trabajado en estrecha colaboración con sus asociados comerciales para comprender lo que quiere lograr la empresa con esta migración. Quieren:

  • Abordar el crecimiento del negocio. Contoso está creciendo. Como resultado, ha aumentado la presión sobre los sistemas locales y la infraestructura de la empresa.
  • Aumentar la eficacia. Contoso debe quitar procedimientos innecesarios y optimizar los procesos para sus desarrolladores y usuarios. La empresa necesita que el departamento de TI actúe con rapidez y no pierda el tiempo ni malgaste dinero, para que la empresa pueda satisfacer más rápidamente los requisitos de los clientes.
  • Aumentar la agilidad. el equipo de TI de Contoso necesita más capacidad de respuesta a las necesidades de la empresa. Tiene que ser capaz de anticiparse a los cambios que se producen en el mercado para propiciar el éxito de la empresa dentro de una economía global. No debe ser un obstáculo ni convertirse en un inhibidor del negocio.
  • Escala. a medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe proporcionar sistemas que puedan crecer al mismo ritmo.

Objetivos de la migración

El equipo de la nube de Contoso ha establecido los objetivos de esta migración. La empresa usa los objetivos de migración para determinar el mejor método de migración.

  • Tras la migración, la aplicación de Azure debe tener las mismas funcionalidades de rendimiento que las que tiene actualmente en su entorno de VMware local. Pasar a la nube no significa que el rendimiento de las aplicaciones sea menos crítico.
  • Contoso no quiere invertir en la aplicación. La aplicación es crítica e importante para la empresa, pero Contoso solo quiere mover la aplicación en su formato actual a la nube.
  • Después de migrar la aplicación, las tareas administrativas de la base de datos deberían ser menores.
  • Contoso no quiere usar Azure SQL Database para esta aplicación. Busca alternativas.

Diseño de la solución

Una vez precisados los objetivos y requisitos, Contoso diseña y revisa una solución de implementación e identifica el proceso de migración. También se identifican los servicios de Azure que usarán para la migración.

Arquitectura actual

  • Contoso tiene un centro de datos principal (contoso-datacenter). El centro de datos está situado en la ciudad de Nueva York, al este de Estados Unidos.
  • Contoso tiene tres sucursales locales más en los Estados Unidos.
  • El centro de datos principal está conectado a Internet con una conexión Metro Ethernet de fibra óptica (500 megabits por segundo).
  • Cada una de las sucursales está conectada localmente a Internet mediante conexiones de categoría empresarial, y con túneles VPN con IPSec hacia el centro de datos principal. Esta configuración permite que la red entera de Contoso esté conectada de forma permanente, y además optimiza la conectividad a Internet.
  • El centro de datos principal está completamente virtualizado con VMware. Contoso tiene dos hosts de virtualización ESXi 6.5 que están administrados por vCenter Server 6.5.
  • Contoso usa Active Directory para la administración de identidades. Contoso usa servidores DNS en la red interna.
  • Contoso tiene un controlador de dominio local (contosodc1).
  • Los controladores de dominio se ejecutan en las máquinas virtuales de VMware. Los controladores de dominio de las sucursales locales se ejecutan en servidores físicos.
  • La aplicación SmartHotel360 se divide en capas en dos máquinas virtuales (WEBVM y SQLVM) que se encuentran en un host de VMware ESXi versión 6.5 (contosohost1.contoso.com).
  • El entorno de VMware se administra con vCenter Server 6.5 (vcenter.contoso.com) que se ejecuta en una máquina virtual.

Diagrama de la arquitectura actual de Contoso.

Arquitectura propuesta

En este escenario, Contoso quiere migrar su aplicación de viajes local de dos capas como se indica a continuación:

  • Se migra la base de datos de la aplicación (SmartHotelDB) a una instancia administrada de SQL.
  • Se migra la máquina virtual WEBVM de front-end a una máquina virtual de Azure.
  • Las máquinas virtuales locales del centro de datos de Contoso se retirarán cuando finalice la migración.

Diagrama de la arquitectura del escenario

Consideraciones sobre la base de datos

Como parte del proceso de diseño de la solución, Contoso hizo una comparación de características entre Azure SQL Database y SQL Managed Instance. Las siguientes consideraciones ayudaron a la empresa a decidirse por SQL Managed Instance.

  • El objetivo de SQL Managed Instance es proporcionar casi un 100 % de compatibilidad con la versión de la instalación local de SQL Server más reciente. Recomendamos SQL Managed Instance para los clientes que ejecutan SQL Server de forma local o en máquinas virtuales de infraestructura como servicio (IaaS), y que desean migrar sus aplicaciones a un servicio totalmente administrado con cambios mínimos en el diseño.
  • Contoso planea migrar un gran número de aplicaciones del en el entorno local a IaaS. Muchas de estas aplicaciones las proporciona el fabricante de software independiente. Contoso se da cuenta de que el uso de SQL Managed Instance le ayudará a garantizar la compatibilidad de la base de datos con estas aplicaciones, en lugar de utilizar SQL Database, que podría no ser compatible.
  • Contoso puede realizar una migración a SQL Managed Instance mediante lift-and-shift con el servicio Azure Database Migration Service totalmente automatizado. Con este servicio, Contoso puede reutilizarla para las migraciones futuras de la base de datos.
  • SQL Managed Instance admite el Agente SQL Server, un componente importante de la aplicación SmartHotel360. Contoso necesita esta compatibilidad. Sin ella, tendrá que volver a diseñar los planes de mantenimiento que requiere la aplicación.
  • Con Software Assurance, Contoso puede intercambiar sus licencias existentes para obtener descuentos en una instancia de SQL Managed Instance con la Ventaja híbrida de Azure para SQL Server. Por esta razón, Contoso podrá ahorrar hasta un 30 % en SQL Managed Instance.
  • Instancia administrada de SQL se incluye totalmente en la red virtual, por lo que ofrece un mayor nivel de aislamiento y seguridad para los datos de Contoso. Contoso puede obtener las ventajas de la nube pública y, al mismo tiempo, mantener el entorno aislado de la red Internet pública.
  • SQL Managed Instance admite muchas características de seguridad. Entre estas se incluyen Always Encrypted, el enmascaramiento dinámico de datos, la seguridad de nivel de fila y la detección de amenazas.

Revisión de la solución

Contoso evalúa el diseño propuesto y crea una lista de ventajas y desventajas.

Consideración Detalles
Ventajas WEBVM se moverá a Azure sin cambios, lo que simplifica la migración.

Instancia administrada de SQL admite los requisitos técnicos y los objetivos de Contoso.

SQL Managed Instance proporcionará compatibilidad total con la implementación actual de Contoso, mientras la empresa deja de usar SQL Server 2008 R2.

Contoso puede aprovechar su inversión en Software Assurance y usar la Ventaja híbrida de Azure para SQL Server y Windows Server.

Puede volver a usar Azure Database Migration Service para futuras migraciones adicionales.

SQL Managed Instance tiene tolerancia a errores integrada que Contoso no necesita configurar. Esta característica garantiza que la capa de datos ya no sea un único punto de error.
Desventajas WEBVM ejecuta Windows Server 2008 R2. Aunque este sistema operativo es compatible con Azure, ha dejado de ser una plataforma compatible. Para más información, consulte Directiva de soporte técnico para productos de Microsoft SQL Server.

El nivel web sigue siendo un punto único de conmutación por error en el que WEBVM es la única máquina virtual que proporciona servicios.

Contoso tendrá que seguir dando soporte al nivel web de la aplicación como una máquina virtual, en lugar de pasarse a un servicio administrado, como Azure App Service.

Para la capa de datos, es posible que SQL Managed Instance no sea la mejor solución si Contoso desea personalizar el sistema operativo o el servidor de base de datos, o si la empresa desea ejecutar aplicaciones de terceros junto con SQL Server. La ejecución de SQL Server en una máquina virtual IaaS puede proporcionar esta flexibilidad.

Proceso de migración

Contoso migrará la capas web y de datos de su aplicación SmartHotel360 a Azure mediante estos pasos:

  1. Contoso ya tiene su infraestructura de Azure, por lo que solo necesita agregar un par de componentes de Azure específicos a este escenario.

  2. La capa de datos se migrará con Azure Database Migration Service. Este servicio se conecta a la máquina virtual local con SQL Server mediante una conexión VPN de sitio a sitio entre el centro de datos de Contoso y Azure. Después, el servicio migra la base de datos.

  3. La capa web se migrará con una migración mediante lift-and-shift por medio de Azure Migrate. Este proceso supone la preparación del entorno local de VMware, la configuración y habilitación de la replicación y la migración de las máquinas virtuales mediante su conmutación por error a Azure.

    Diagrama de la arquitectura de migración.

Servicios de Azure

Servicio Descripción Coste
Azure Database Migration Service Azure Database Migration Service permite migraciones completas de varios orígenes de base de datos a plataformas de datos de Azure, con un tiempo de inactividad mínimo. Obtenga información sobre las regiones admitidas y los precios de Azure Database Migration Service.
Instancia administrada de Azure SQL SQL Managed Instance es un servicio de base de datos administrada que representa una instancia de SQL Server completamente administrada en la nube de Azure. Usa el mismo código que la versión más reciente del motor de base de datos de SQL Server, y tiene las características, mejoras de rendimiento y actualizaciones de seguridad más recientes. El uso de una instancia administrada de SQL que se ejecute en Azure genera cargos en función de la capacidad. Más información acerca de los precios de SQL Managed Instance.
Azure Migrate Contoso usa Azure Migrate para evaluar sus máquinas virtuales de VMware. Azure Migrate valora la idoneidad de las máquinas para la migración. Proporciona estimaciones de tamaño y costos para su ejecución en Azure. Azure Migrate está disponible sin costo adicional. Se pueden aplicar cargos según las herramientas (propias o de un fabricante de software independiente) que decidan usar para la evaluación y la migración. Más información sobre los precios de Azure Migrate.

Requisitos previos

Contoso y otros usuarios tienen que cumplir los requisitos previos a continuación en este escenario.

Requisitos Detalles
Suscripción de Azure Contoso ya ha creado una suscripción en el primer artículo de esta serie. Si no tiene una suscripción a Azure, cree una cuenta gratuita.

Si crea una cuenta gratuita, será el administrador de su suscripción y podrá realizar todas las acciones.

Si usa una suscripción existente pero no es el administrador de la misma, solicite al administrador que le asigne permisos de propietario o colaborador para los recursos o grupos de recursos necesarios.
Infraestructura de Azure Contoso configura su infraestructura de Azure según se describe en la infraestructura de Azure para la migración.
Servidores locales La versión de la instalación local de vCenter Server debe ser 5.5, 6.0 o 6.5.

Un host ESXi debe ejecutar la versión 5.5, 6.0 o 6.5.

Una o más VM VMware se deben ejecutar en el host ESXi.
Máquinas virtuales locales Revise las máquinas Linux que se han aprobado para ejecutarse en Azure.
Database Migration Service Para Azure Database Migration Service, necesita un dispositivo de VPN local compatible.

Tiene que poder configurar el dispositivo VPN local. Debe tener una dirección IPv4 pública de uso externo. Esta dirección no puede estar situada detrás de un dispositivo NAT.

Asegúrese de que tiene acceso a la base de datos local de SQL Server.

Firewall de Windows debe poder acceder al motor de base de datos de origen. Aprenda a configurar Firewall de Windows para el acceso al motor de base de datos.

Si hay un firewall delante de la máquina de base de datos, agregue reglas para permitir el acceso a la base de datos y a los archivos a través del puerto 445 de SMB.

Las credenciales usadas para conectar con la instancia de SQL Server de origen y esa instancia de SQL Managed Instance de destino tienen que ser miembros del rol de servidor sysadmin.

Es necesario tener un recurso compartido de red en la base de datos local que Azure Database Migration Service pueda usar para realizar una copia de seguridad de la base de datos de origen.

Asegúrese de que la cuenta de servicio que ejecuta la instancia de SQL Server de origen tenga permisos de escritura sobre el recurso compartido de red.

Anote un nombre de usuario y una contraseña de Windows que tengan permisos de control completos sobre el recurso compartido de red. Azure Database Migration Service suplanta estas credenciales de usuario para cargar los archivos de copia de seguridad en el contenedor de Azure Storage.

El proceso de instalación de SQL Server Express establece el protocolo TCP/IP en deshabilitado de forma predeterminada. Asegúrese de que esté habilitado.

Pasos del escenario

A continuación se indica cómo Contoso configura la implementación:

  • Paso 1: Preparación de una instancia administrada de SQL. Contoso necesita una instancia administrada existente a la que se migrará la base de datos de SQL Server local.
  • Paso 2: Preparación de Azure Database Migration Service. Contoso tiene que registrar al proveedor de migración de base de datos, crear una instancia y, luego, crear un proyecto de Database Migration Service. Contoso también tiene que configurar un identificador de recursos uniforme (URI) de una firma de acceso compartido (SAS) para la instancia de Database Migration Service. Un URI de SAS proporciona acceso delegado a los recursos de la cuenta de almacenamiento de Contoso para que Contoso puede conceder permisos limitados a los objetos de almacenamiento. Contoso configura un URI de SAS, así Azure Database Migration Service puede acceder al contenedor de cuenta de almacenamiento en el que el servicio carga los archivos de copia de seguridad de SQL Server.
  • Paso 3: Preparación de Azure para Azure Migrate: herramienta Server Migration. Contoso agrega la herramienta de migración del servidor al proyecto de Azure Migrate.
  • Paso 4: Preparación del entorno de VMware local para Azure Migrate: Server Migration. Contoso prepara las cuentas para la detección de máquinas virtuales y prepara la conexión a las máquinas virtuales de Azure tras la migración.
  • Paso 5: Replicación de las máquinas virtuales locales. Contoso configura la replicación y comienza a replicar las máquinas virtuales en Azure Storage.
  • Paso 6: Migración de la base de datos mediante Azure Database Migration Service. Contoso migra la base de datos.
  • Paso 7: Migración de las máquinas virtuales con Azure Migrate: Server Migration. Contoso ejecuta una migración de prueba para garantizar que todo funciona y, luego, ejecuta una migración completa para mover las máquinas virtuales a Azure.

Paso 1: Preparación de una instancia administrada de SQL

Para configurar una instancia administrada de SQL Contoso necesita una subred que cumpla los requisitos siguientes:

  • La subred debe estar dedicada. Tiene que estar vacía. No puede contener ningún otro servicio en la nube. La subred no puede ser una subred de puerta de enlace.
  • Una vez creada la instancia administrada, Contoso no debe agregar recursos a la subred.
  • La subred no puede tener asociado un grupo de seguridad de red.
  • La subred debe tener una tabla de rutas definida por el usuario. La única ruta asignada debe ser 0.0.0.0/0, con Internet como próximo salto.
  • Si se especifica un DNS personalizado para la red virtual, es necesario agregar a la lista la dirección IP virtual 168.63.129.16 de las resoluciones recursivas de Azure. Más información sobre cómo configurar un DNS personalizado para una instancia de SQL Managed Instance.
  • La subred no puede tener un punto de conexión de servicio (de almacenamiento o SQL) asociado a ella. Los puntos de conexión de servicio se deben deshabilitar en la red virtual.
  • La subred tiene que tener como mínimo 16 direcciones IP. Aprenda cómo cambiar el tamaño de la subred de la instancia administrada.
  • En el entorno híbrido de Contoso, se requiere la configuración de DNS personalizada. Contoso configura los valores de DNS para usar uno o varios de los servidores de Azure DNS de la empresa. Más información sobre la personalización de DNS.

Configurar una red virtual para la instancia administrada

Para configurar la red virtual, los administradores de Contoso:

  1. Crean una nueva red virtual (VNET-SQLMI-EU2) en la región primaria (East US 2). Agregan la red virtual al grupo de recursos ContosoNetworkingRG.

  2. Asignan un espacio de direcciones de 10.235.0.0/24. Garantizan que el intervalo no se solapa con otras redes de su empresa.

  3. Agregan dos subredes a la red:

    • SQLMI-DS-EUS2 (10.235.0.0/25).

    • SQLMI-SAW-EUS2 (10.235.0.128/29). Esta subred se usa para asociar un directorio a la instancia administrada.

      Captura de pantalla que muestra la instancia administrada de SQL: Panel Crear red virtual.

  4. Después de implementar la red virtual y las subredes, emparejan las redes como se indica a continuación:

    • Se empareja VNET-SQLMI-EUS2 con VNET-HUB-EUS2 (la red virtual del centro de conectividad de East US 2).

    • Se empareja VNET-SQLMI-EUS2 con VNET-PROD-EUS2 (la red de producción).

      Captura de pantalla que muestra el emparejamiento de red.

  5. Establecen una configuración de DNS personalizada. DNS primero apunta a los controladores de dominio de Azure de Contoso. Azure DNS es secundario. Los controladores de dominio de Azure de Contoso están ubicados de la manera siguiente:

    • Ubicados en la subred PROD-DC-EUS2, en la red de producción East US 2 (VNET-PROD-EUS2).

    • Dirección de CONTOSODC3: 10.245.42.4.

    • Dirección de CONTOSODC4: 10.245.42.5.

    • Solucionador de Azure DNS: 168.63.129.16.

      Captura de pantalla que muestra los servidores DNS de la red.

¿Necesita más ayuda?

Configuración del enrutamiento

La instancia administrada se coloca en una red privada virtual. Contoso necesita una tabla de enrutamiento para que la red virtual se comunique con el servicio de administración de Azure. Si la red virtual no puede comunicarse con el servicio que la administra, se vuelve inaccesible.

Contoso tiene en cuenta estos factores:

  • La tabla de enrutamiento contiene un conjunto de reglas (rutas) que especifican cómo se deben enrutar los paquetes enviados en la red virtual desde la instancia administrada.
  • La tabla de enrutamiento se asocia con subredes en las que se implementan instancias administradas. Cada paquete que sale de una subred se controla en función de la tabla de rutas asociada.
  • Una subred puede asociarse con una sola tabla de rutas.
  • No hay ningún cargo adicional por la creación de tablas de redirección en Microsoft Azure.

Para configurar el enrutamiento, los administradores de Contoso siguen estos pasos:

  1. Crean una tabla de enrutamiento definida por el usuario en el grupo de recursos ContosoNetworkingRG.

    Captura de pantalla que muestra la tabla de enrutamiento.

  2. Para cumplir los requisitos de SQL Managed Instance, tras implementar la tabla de enrutamiento (MIRouteTable), se agrega una ruta que tiene el prefijo de dirección 0.0.0.0/0. La opción Tipo de próximo salto está establecida en Internet.

    Captura de pantalla que muestra el prefijo de la tabla de enrutamiento.

  3. Asocian la tabla de enrutamiento con la subred SQLMI-DB-EUS2 (en la red VNET-SQLMI-EUS2).

    Captura de pantalla que muestra la subred de la tabla de enrutamiento.

¿Necesita más ayuda?

Aprenda cómo configurar rutas para una instancia administrada.

Creación de una instancia administrada

Ahora, los administradores de Contoso pueden aprovisionar una instancia administrada de SQL:

  1. Como la instancia administrada da servicio una aplicación empresarial, la instancia administrada se implementa en la región primaria de la empresa (East US 2). La instancia administrada se agrega al grupo de recursos ContosoRG.

  2. Seleccionan un plan de tarifa y el tamaño de los recursos de tamaño y almacenamiento de la instancia. Más información acerca de los precios de SQL Managed Instance.

    Captura de pantalla que muestra el panel de SQL Managed Instance.

  3. Una vez implementada la instancia administrada, aparecen dos nuevos recursos en el grupo de recursos ContosoRG:

    • La instancia administrada de SQL.

    • Un clúster virtual en caso de que Contoso tenga varias instancias administradas.

      Captura de pantalla que muestra dos nuevos recursos.

¿Necesita más ayuda?

Aprenda cómo aprovisionar una instancia administrada.

Paso 2: Preparación de una instancia de Azure Database Migration Service

Para preparar Azure Database Migration Service, los administradores de Contoso tienen que realizar varias operaciones:

  • Registrar al proveedor de Database Migration Service en Azure.
  • Dar a Database Migration Service acceso a Azure Storage para cargar los archivos de copia de seguridad que se usan para migrar una base de datos. Para proporcionar acceso a Azure Storage, crean un contenedor de Azure Blob Storage. Generan un identificador URI de SAS para el contenedor de Blob Storage.
  • Crear un proyecto de Azure Database Migration Service.

Realizan los siguientes pasos:

  1. Registran el proveedor de migración de base de datos en su suscripción. Captura de pantalla que muestra el registro de Database Migration Service.

  2. Crean un contenedor de Azure Blob Storage. Contoso genera un URI de SAS para que Azure Database Migration Service pueda acceder a él.

    Captura de pantalla que muestra la generación de un URI de SAS.

  3. Crear una instancia de Azure Database Migration Service.

    Captura de pantalla que muestra la creación de una instancia.

  4. Colocan la instancia de Database Migration Service en la subred PROD-DC-EUS2de la red virtual VNET-PROD-DC-EUS2.

    • La instancia se coloca ahí porque el servicio tiene que estar en una red virtual que pueda acceder a la máquina virtual de SQL Server local mediante una puerta de enlace de VPN.

    • VNET-PROD-EUS2 está emparejado con VNET-HUB-EUS2 y puede usar puertas de enlace remotas. La opción Usar puertas de enlace remotas garantiza que la instancia pueda comunicarse cuando sea necesario.

      Captura de pantalla que muestra la configuración de una red.

¿Necesita más ayuda?

Paso 3: Preparación de Azure para Azure Migrate: Herramienta Server Migration

Estos son los componentes de Azure que Contoso necesita para migrar las VM a Azure:

  • Una red virtual en la que se encontrarán las máquinas virtuales de Azure cuando se creen durante la migración.
  • Azure Migrate: Server Migration aprovisionada.

Los administradores de Contoso configuran estos componentes:

  1. Configuran una red. Contoso ya configuró una red que se puede usar para Azure Migrate: Server Migration cuando implementó la infraestructura de Azure.

    • La aplicación SmartHotel360 es una aplicación de producción, y las máquinas virtuales se migrarán a la red de producción de Azure (VNET-PROD-EUS2) en la región primaria (East US 2).
    • Ambas máquinas virtuales se colocarán en el grupo de recursos ContosoRG, que se usa para los recursos de producción.
    • La máquina virtual de front-end de la aplicación (WEBVM) se migrará a la subred de front-end (PROD-FE-EUS2) de la red de producción.
    • La base de datos de la aplicación (SQLVM) se migrará a la subred de base de datos (PROD-DB-EUS2) de la red de producción.

Paso 4: Preparación del entorno de VMware local para Azure Migrate: Server Migration

Estos son los componentes de Azure que Contoso necesita para migrar las VM a Azure:

  • Una red virtual en la que se ubicarán las máquinas virtuales de Azure cuando se creen durante la migración.
  • La aplicación de Azure Migrate, aprovisionada y configurada.

Los administradores de Contoso configuran estos componentes siguiendo estos pasos:

  1. Configuran una red. Contoso ya configuró una red que se puede usar para Azure Migrate: Server Migration cuando implementó la infraestructura de Azure.

    • La aplicación SmartHotel360 es una aplicación de producción, y las máquinas virtuales se migrarán a la red de producción de Azure (VNET-PROD-EUS2) en la región primaria (East US 2).
    • Ambas máquinas virtuales se colocarán en el grupo de recursos ContosoRG, que se usa para los recursos de producción.
    • La máquina virtual de front-end de aplicaciones (WEBVM) se migrará a la subred de front-end (PROD-FE-EUS2), en la red de producción.
    • La máquina virtual de base de datos de aplicaciones (SQLVM) se migrará a la subred de base de datos (PROD-DB-EUS2), en la red de producción.
  2. Aprovisionamiento de la aplicación de Azure Migrate.

    1. Desde Azure Migrate, descargue la imagen de OVA e impórtela en VMware.

      Captura de pantalla que muestra la descarga del archivo OVA.

    2. Inicie la imagen importada y configure la herramienta siguiendo los pasos a continuación:

      1. Configure los requisitos previos.

        Captura de pantalla que muestra cómo configurar los requisitos previos.

      2. Dirija la herramienta a la suscripción de Azure.

        Captura de pantalla que muestra la selección de la suscripción

      3. Configure las credenciales de VMWare vCenter.

        Captura de pantalla que muestra cómo establecer las credenciales de VMware vCenter.

      4. Agregue las credenciales basadas en Linux o en Windows para la detección.

        Captura de pantalla que muestra cómo establecer las credenciales de Windows y Linux.

  3. Una vez configurada, la herramienta tardará algún tiempo en enumerar todas las máquinas virtuales. Una vez finalizado el proceso, los administradores de Contoso pueden ver las máquinas virtuales rellenadas en la herramienta de Azure Migrate de Azure.

¿Necesita más ayuda?

Aprenda cómo configurar la aplicación de Azure Migrate.

Preparación de las VM locales

Después de la migración, Contoso quiere conectarse a las VM de Azure y permitir que Azure administre las VM. Para ello, los administradores de Contoso tienen que realizar los siguientes pasos antes de la migración:

  1. Para el acceso a través de Internet:

    • Habilite RDP o SSH en la VM local antes de la migración.
    • Se asegura de que se agregan las reglas TCP y UDP para el perfil público.
    • Compruebe que se permite RDP o SSH en el firewall del sistema operativo.
  2. Para el acceso a través de la VPN de sitio a sitio:

    • Habilite RDP o SSH en la VM local antes de la migración.
    • Compruebe que se permite RDP o SSH en el firewall del sistema operativo.
    • En Windows, establezca en OnlineAll la directiva de SAN del sistema operativo de la máquina virtual local.
  3. Instalan el agente de Azure:

  4. Otras consideraciones:

    • Para Windows, no debe haber actualizaciones de Windows pendientes en la VM cuando se desencadene una migración. Si las hay, no podrá iniciar sesión en la máquina virtual hasta que se completen las actualizaciones.
    • Después de la migración, se pueden comprobar los diagnósticos de arranque para ver una captura de pantalla de la VM. Si no funciona, debe comprobar que la máquina virtual está en ejecución, así como revisar estas sugerencias de solución de problemas.

¿Necesita más ayuda?

Aprenda cómo preparar las máquinas virtuales para la migración.

Paso 5: Replicar máquinas virtuales locales

Antes de que los administradores de Contoso puedan ejecutar una migración a Azure, tienen que configurar y habilitar la replicación.

Una vez completada la detección, se puede comenzar la replicación de máquinas virtuales de VMware en Azure.

  1. En el proyecto de Azure Migrate, van a Servidores > Azure Migrate: Server Migration. A continuación, seleccionan Replicar.

    Captura de pantalla que muestra la opción Replicar.

  2. En Replicar > Configuración de origen > ¿Las máquinas están virtualizadas? , seleccionan Sí, con VMware vSphere.

  3. En Dispositivo local, seleccionan el nombre del dispositivo de Azure Migrate que se configuró y, a continuación, seleccionan Aceptar.

    Captura de pantalla que muestra la pestaña Configuración de origen.

  4. En Máquinas virtuales, seleccionan las máquinas que quieren replicar:

    • Si han ejecutado una evaluación para las máquinas virtuales, pueden aplicar las recomendaciones de tamaño y tipo de disco (Premium/Estándar) de máquina virtual que sugieren los resultados de dicha evaluación. Para ello, en ¿Quiere importar la configuración de migración de evaluación de Azure Migrate? , seleccionan la opción .
    • Si no han ejecutado una evaluación o no desean usar la configuración de la evaluación, seleccionan la opción No.
    • Si han decidido usar la evaluación, seleccionan el grupo de máquinas virtuales y el nombre de la evaluación.

    Captura de pantalla que muestra la selección de evaluaciones.

  5. En Máquinas virtuales, buscan las máquinas virtuales que necesitan y comprueban todas las que desean migrar. Luego, seleccionan Siguiente: Configuración de destino.

  6. En Configuración de destino, seleccionan la suscripción y la región de destino a la que migrarán. También especifican el grupo de recursos en el que residirán las máquinas virtuales de Azure después de la migración. En Red virtual, seleccionan la red virtual o la subred de Azure a la que se unirán las máquinas virtuales de Azure después de la migración.

  7. En Ventaja híbrida de Azure:

    • Seleccionan No si no desean aplicar la Ventaja híbrida de Azure. Luego, seleccionan Siguiente.
    • Seleccionan si tienen equipos con Windows Server que están incluidos en suscripciones activas de Software Assurance o Windows Server y desean aplicar la ventaja a las máquinas que va a migrar. Luego, seleccionan Siguiente.
  8. En Proceso, revisan el nombre de la máquina virtual, su tamaño, el tipo de disco del sistema operativo y el conjunto de disponibilidad. Las máquinas virtuales deben cumplir los requisitos de Azure.

    • Tamaño de VM: si usan las recomendaciones de la evaluación, la lista desplegable de tamaño de máquina virtual contiene el tamaño recomendado. De lo contrario, Azure Migrate elige un tamaño en función de la coincidencia más cercana en la suscripción de Azure. También pueden elegir un tamaño de manera manual en Tamaño de la máquina virtual de Azure.
    • Disco del sistema operativo: especifican el disco del sistema operativo (arranque) de la máquina virtual. Este es el disco que tiene el cargador de arranque y el instalador del sistema operativo.
    • conjunto de disponibilidad: si la máquina virtual debe estar incluida en un conjunto de disponibilidad de Azure después de la migración, especifican el conjunto. El conjunto tiene que estar en el grupo de recursos de destino que se especifica para la migración.
  9. En Discos, especifican si los discos de la máquina virtual se deben replicar en Azure. Después, seleccionan el tipo de disco (SSD/HDD Estándar o discos administrados Premium) de Azure y seleccionan Siguiente.

    • Pueden excluir discos de la replicación.
    • Si se excluyen discos, no estarán presentes en la máquina virtual de Azure después de la migración.
  10. En Revisar + iniciar replicación, revisan la configuración. A continuación, seleccionan Replicar para iniciar la replicación inicial de los servidores.

Nota

La configuración de replicación se puede actualizar en cualquier momento antes de que esta comience en Administrar > Replicación de máquinas. Una vez iniciada la replicación, su configuración no se puede cambiar.

Paso 6: Migración de la base de datos mediante Azure Database Migration Service

Los administradores de Contoso tienen que crear un proyecto de Database Migration Service y luego migrar la base de datos.

Creación de un proyecto de Azure Database Migration Service

  1. Los administradores crean un proyecto de Database Migration Service. Seleccionan el tipo de servidor de origen SQL Server y Azure SQL Managed Instance como destino.

    Captura de pantalla que muestra el panel Nuevo proyecto de migración.

  2. Se abre el Asistente para migración.

Migración de la base de datos

  1. En el Asistente para migración, especifican la máquina virtual de origen en la que se encuentra la base de datos local. Escriben las credenciales para acceder a la base de datos.

    Captura de pantalla que muestra el panel Detalles del origen.

  2. Seleccionan la base de datos que se va a migrar (SmartHotel.Registration).

    Captura de pantalla que muestra el panel Seleccionar las bases de datos de origen.

  3. Como destino, escriben el nombre de la instancia administrada de Azure y las credenciales de acceso.

    Captura de pantalla que muestra el panel Detalles de destino.

  4. En Nueva actividad > Ejecutar migración, especifican la configuración para ejecutar la migración:

    • Credenciales de origen y destino.

    • La base de datos para migrar.

    • El recurso compartido de red creado en la máquina virtual local. Azure Database Migration Service lleva las copias de seguridad de origen a este recurso compartido.

      • La cuenta de servicio que ejecuta la instancia de SQL Server de origen debe tener permisos de escritura sobre este recurso compartido.
      • Se debe usar la ruta de acceso del nombre de dominio completo (FQDN) al recurso compartido.
    • El URI de SAS que proporciona a Azure Database Migration Service acceso al contenedor de cuentas de almacenamiento en el que el servicio carga los archivos de copia de seguridad de la migración.

      Captura de pantalla que muestra la pantalla Configurar los valores de la migración.

  5. Guardan la configuración de migración y, después, ejecutan la migración.

  6. En Introducción, supervisa el estado de la migración.

    Captura de pantalla que muestra el estado.

  7. Cuando la migración ha finalizado, comprueban que las bases de datos de destino existen en la instancia administrada.

    Captura de pantalla que muestra la comprobación de la migración de la base de datos.

Paso 7: Migración de las máquinas virtuales con Azure Migrate: Server Migration

Los administradores de Contoso ejecutan una migración de prueba rápida y comprueban que la máquina virtual funciona correctamente. Después, migran la máquina virtual.

Ejecutar una migración de prueba

  1. En Objetivos de migración > Servidores > Azure Migrate: Server Migration, seleccionan Probar servidores migrados.

    Captura de pantalla que muestra el elemento Probar servidores migrados.

  2. Los administradores mantienen presionada (o hacen clic con el botón derecho) la máquina virtual que van a probar y, a continuación, seleccionan Migración de prueba.

    Captura de pantalla que muestra el elemento Migración de prueba.

  3. En Migración de prueba, seleccionan la red virtual de Azure en la que se ubicará la máquina virtual de Azure después de la migración. Se recomienda utilizar una red virtual que no sea de producción.

  4. Comienza el trabajo de Migración de prueba. Los administradores supervisan el trabajo en las notificaciones del portal.

  5. Una vez finalizada la migración, la máquina virtual de Azure migrada se puede ver en Máquinas virtuales en Azure Portal. El nombre de la máquina tiene el sufijo -Test.

  6. Una vez finalizada la prueba, los administradores mantienen presionada (o hacen clic con el botón derecho) en la máquina virtual de Azure, en Replicación de máquinas y seleccionan Limpiar la migración de prueba.

    Captura de pantalla que muestra el elemento Limpiar la migración de prueba.

Migración de la VM

Ahora, los administradores de Contoso ejecutan una migración completa para completar el traslado.

  1. En el proyecto de Azure Migrate, van a Servidores > Azure Migrate: Server Migration, y seleccionan Replicando servidores.

    Captura de pantalla que muestra el elemento Replicando servidores.

  2. En Replicación de máquinas, mantienen presionada (o hacen clic con el botón derecho) la máquina virtual y seleccionan Migrar.

  3. En Migrar > ¿Quiere apagar las máquinas virtuales y realizar una migración planificada sin perder datos? , seleccionan > Aceptar.

    • De forma predeterminada, Azure Migrate apaga la máquina virtual local y ejecuta una replicación a petición para sincronizar los cambios que se han producido en la máquina virtual desde la última replicación. Esta acción garantiza que no se pierdan datos.
    • Si no desean apagar la máquina virtual, seleccionan No.
  4. Se inicia un trabajo de migración de la máquina virtual. Los administradores realizan un seguimiento del trabajo en las notificaciones de Azure.

  5. Una vez finalizado el trabajo, pueden ver y administrar la máquina virtual desde la página Máquinas virtuales.

  6. Por último, se actualizan los registros DNS de WEBVM en uno de los controladores de dominio de Contoso.

Actualización de la cadena de conexión

Como último paso del proceso de migración, los administradores de Contoso actualizan la cadena de conexión de la aplicación para que apunte a la base de datos migrada que se ejecuta en la instancia administrada de SQL.

  1. En Azure Portal, seleccionan Configuración > Cadenas de conexión para buscar la cadena de conexión.

    Captura de pantalla que muestra la opción Cadenas de conexión.

  2. Actualizan la cadena con el nombre de usuario y la contraseña de la instancia administrada de SQL.

  3. Una vez configurada la cadena, reemplazan la cadena de conexión actual en el archivo web.config de su aplicación.

  4. Después de actualizar el archivo y guardarlo, ejecutan iisreset /restart en una ventana del símbolo del sistema para reiniciar IIS en WEBVM.

  5. Después de reiniciar IIS, la aplicación usa la base de datos que se ejecuta en la instancia administrada de SQL.

  6. En este momento, ya pueden apagar la máquina SQLVM local. La migración ha finalizado.

¿Necesita más ayuda?

Limpiar después de la migración

Una vez terminada la migración, la aplicación SmartHotel360 se ejecuta en una máquina virtual de Azure y la base de datos de SmartHotel360 está disponible en la instancia administrada de SQL.

Ahora, Contoso tiene que realizar estas tareas de limpieza:

  • Quitar la máquina WEBVM del inventario de vCenter Server.
  • Quitar la máquina SQLVM del inventario de vCenter Server.
  • Quitar WEBVM y SQLVM de los trabajos de copia de seguridad locales.
  • Actualizar la documentación interna para mostrar la nueva ubicación y la dirección IP de WEBVM.
  • Quitar SQLVM de la documentación interna. Como alternativa, Contoso puede revisar la documentación para mostrar SQLVM como eliminada y ya no aparecerá en el inventario de máquinas virtuales.
  • Revise todos los recursos que interactúan con las máquinas virtuales fuera de servicio. Actualice la configuración o la documentación pertinentes para que reflejen la nueva configuración.

Revisión de la implementación

Con los recursos migrados de Azure, Contoso debe proteger la infraestructura nueva y ponerla totalmente en marcha.

Seguridad

El equipo de seguridad de Contoso comprueba las máquinas virtuales de Azure y la instancia administrada de SQL para determinar posibles problemas de seguridad de la implementación:

  • El equipo revisa los grupos de seguridad de red que se usan para controlar el acceso de la máquina virtual. Los grupos de seguridad de red ayudan a garantizar que solo pueda pasar el tráfico que se permite para la aplicación.

  • El equipo de seguridad de Contoso también está pensando en proteger los datos en el disco mediante Azure Disk Encryption y Azure Key Vault.

  • El equipo permite la detección de amenazas en la instancia administrada. La detección de amenazas envía una alerta al sistema del equipo o departamento de seguridad de Contoso para abrir una incidencia si se detecta una amenaza. Obtenga más información sobre la detección de amenazas para SQL Managed Instance.

    Captura de pantalla que muestra la seguridad de SQL Managed Instance: Pantalla Detección de amenazas.

Para más información sobre los procedimientos de seguridad para máquinas virtuales, consulte Procedimientos de seguridad recomendados para cargas de trabajo de IaaS de Azure.

Continuidad empresarial y recuperación ante desastres

Para la continuidad empresarial y la recuperación ante desastres, Contoso realiza las siguientes acciones:

Optimización de los costos y licencias

  • Contoso ya tiene una licencia para WEBVM. Para aprovechar las ventajas de precios con Ventaja híbrida de Azure, Contoso convierte la máquina virtual de Azure existente.
  • Contoso usará Azure Cost Management + Billing para que la compañía permanezca dentro de los presupuestos establecidos por la dirección de TI.

Conclusión

En este artículo, Contoso vuelve a hospedar la aplicación SmartHotel360 en Azure mediante la migración de la máquina virtual de front-end de aplicaciones a Azure con el servicio Azure Migrate. Contoso migra la base de datos local a una instancia administrada de SQL mediante Azure Database Migration Service.