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 dos niveles basada en Windows .NET de máquinas virtuales de VMware a una máquina virtual de Azure mediante el servicio Azure Migrate. En este artículo también se muestra cómo Contoso migra la base de datos de la aplicación a Azure SQL Managed Instance. Esta migración sigue la preparación que se describe en Implementación de una infraestructura de migración.

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

Nota

La aplicación de ejemplo de este artículo, SmartHotel360, está archivada, pero sigue disponible en GitHub para su consulta.

Impulsores del negocio

El equipo directivo de TI de Contoso trabaja estrechamente con los socios comerciales de la empresa para comprender qué quieren conseguir con esta migración. Quieren que cumpla los siguientes objetivos:

• 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. Para que la empresa cumpla rápidamente con los requisitos de los clientes, su equipo de TI debe ser rápido y no perder tiempo ni dinero.

• Aumentar la agilidad. El equipo de TI necesita más capacidad de respuesta a las necesidades de la empresa. Para propiciar el éxito de la empresa dentro de una economía global, Contoso tiene que ser capaz de anticiparse a los cambios que se producen en el mercado. 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 debe proporcionar sistemas que puedan crecer al mismo ritmo.

Objetivos de la migración

Contoso usa los objetivos de migración para determinar los mejores métodos de migración. El equipo de la nube de Contoso identificó los objetivos de esta migración:

• Mismo rendimiento de la aplicació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. Migrar la aplicación a la nube no significa que su rendimiento sea menos esencial.

• No se requiere desarrollar la aplicación. Contoso no quiere invertir en la aplicación. La aplicación es esencial e importante para la empresa, pero simplemente quieren moverla a la nube en su forma actual.

• Administración mínima. Después de migrar la aplicación, las tareas de la base de datos deberían disminuirse.

• Se evita Azure SQL Database. Contoso no quiere usar Azure SQL Database para esta aplicación y busca alternativas.

Diseño de la solución

Después de aclarar los objetivos y requisitos de la empresa, Contoso diseña y revisa una solución de implementación. Contoso identifica asimismo el proceso de migración y los servicios de Azure que se van a usar.

Arquitectura actual

• Contoso tiene un centro de datos principal, contoso-datacenter, que se encuentra en la ciudad de Nueva York. Tiene una conexión de fibra óptica a Internet desde redes Metro Ethernet que proporciona 500 megabits por segundo. El centro de datos principal está completamente virtualizado con productos de VMware. Contoso tiene dos hosts de VMware que ejecutan ESXi 6.5 y que están administrados por vCenter Server 6.5.

• Contoso tiene tres sucursales en los Estados Unidos. Cada una de las sucursales está conectada localmente a Internet mediante conexiones de categoría empresarial, y cada sucursal está conectada al centro de datos principal mediante VPN con IPsec. Esta configuración permite que la red entera de Contoso esté siempre conectada y optimiza la conectividad a Internet.

• Contoso usa servidores DNS en su red interna.

• Contoso usa Active Directory para la administración de identidades.

• Contoso tiene un controlador de dominio local, contosodc1. Los controladores de dominio de las sucursales locales se ejecutan en servidores físicos. Los controladores de dominio se ejecutan en las máquinas virtuales de VMware. El entorno de VMware se administra con vCenter Server 6.5, vcenter.contoso.com, que se ejecuta en una máquina virtual.

• SmartHotel360 se divide en capas en dos máquinas virtuales, WEBVM y SQLVM, que se encuentran en un host de VMware la versión 6.5 de ESXi, contosohost1.contoso.com.

Arquitectura propuesta

En este contexto, Contoso migra 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 de SQL Managed Instance.
• Se migra la máquina virtual WEBVM de front-end a una máquina virtual de Azure.
• Se retiran las máquinas virtuales locales en el centro de datos de Contoso una vez completada la migración.

Consideraciones sobre la base de datos

Como parte del diseño de la solución, Contoso compara las características de Azure SQL Database y SQL Managed Instance. La empresa elige SQL Managed Instances por las siguientes consideraciones:

• Compatibilidad con el software existente.

  • 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. Para más información, consulte ¿Qué es Azure SQL Managed Instance?

  • Contoso planea migrar un gran número de aplicaciones desde el entorno local a IaaS. Muchas de estas aplicaciones las proporciona el fabricante de software independiente. En Contoso se dan cuenta de que el uso de SQL Managed Instance ayuda a garantizar la compatibilidad de las bases de datos con estas aplicaciones. Por el contrario, es posible que no se admita SQL Database.

  • SQL Managed Instance es compatible con el Agente SQL Server, un componente importante de SmartHotel360. Sin esta compatibilidad, Contoso tendría que rediseñar los planes de mantenimiento que requiere la aplicación.

• Intercambio de licencias. 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.

• Tecnología de seguridad y aislamiento de la red.

  • SQL Managed Instance admite muchas características de seguridad, entre las que se encuentran Always Encrypted, el enmascaramiento dinámico de datos, seguridad a nivel de fila y detección de amenazas.

  • SQL Managed Instance está totalmente incluida en la red virtual, lo que ofrece un mayor nivel de aislamiento y seguridad a 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.

• Migración automatizada. Contoso puede mirar a SQL Managed Instance con el servicio totalmente automatizado de Azure Database Migration Service. Con este servicio, Contoso puede reutilizarla para las migraciones futuras de la base de datos.

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	Contoso puede mover WEBVM 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 es totalmente compatible con la implementación actual de Contoso y además hace que la empresa deje 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 Azure admita este sistema operativo, ya no es 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 debe seguir dando soporte a la capa 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 migra a Azure la capas web y de datos de su aplicación, SmartHotel360, siguiendo estos pasos:

1. Agregar un par de componentes específicos a la infraestructura de Azure que Contoso configuró anteriormente (como se describe en Implementación de una infraestructura de migración). Gran parte de la infraestructura necesaria para esta migración ya existe.

2. Migrar la capa de datos mediante Azure Database Migration Service. Este servicio se conecta a la máquina virtual local que ejecuta 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. Migrar la capa web mediante Azure Migrate. Este proceso requiere la preparación del entorno local de VMware, la configuración y habilitación de la replicación y, después, la migración de las máquinas virtuales mediante su conmutación por error a Azure.

   

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 creó 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. El host ESXi debe ejecutar una o varias máquinas virtuales de VMware.
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 externa. 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. Para más información, vea 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 para conectarse a la instancia de SQL Server de origen y a la 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 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á establecido en 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 mirar 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 la herramienta de Migración y modernización. Contoso agrega esta herramienta, que forma parte de Azure Migrate, a su proyecto de Azure Migrate. La herramienta de Migración y modernización se denominaba anteriormente Azure Migrate: Server Migration.

• Paso 4: Preparación de VMware local para la herramienta de Migración y modernización. 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 la herramienta de Migración y modernización. 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 de SQL Managed Instance, Contoso necesita una subred que cumpla los requisitos siguientes:

• Que conecte solo la instancia administrada. 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.

• Que no esté en un grupo de seguridad de red. La subred no puede tener asociado un grupo de seguridad de red.

• Que solo enrute a Internet. 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.

• Que no tenga un punto de conexión de servicio. La subred no puede tener un punto de conexión de servicio asociado a ella, ya sea para almacenamiento o SQL. Los puntos de conexión de servicio se deben deshabilitar en la red virtual.

• Que tenga al menos 16 direcciones IP. La subred tiene que tener como mínimo 16 direcciones IP. Para más información sobre el ajuste de tamaño de la subred de la instancia administrada, consulte Configuración de una red virtual existente para Azure SQL Managed Instance.

• Que tenga DNS personalizado e incluya un solucionador específico. Contoso configura la resolución de nombres DNS para usar uno o varios de los servidores de Azure DNS de la empresa. Debido al entorno híbrido de Contoso, también deben usar la configuración de DNS personalizado. Para usar DNS personalizado, Contoso debe agregar 168.63.129.16, una dirección IP virtual, a la lista de solucionadores recursivos de Azure. Para más información sobre DNS personalizado para una instancia administrada, consulte Resolución de nombres de dominio privados en Azure SQL Managed Instance.

Configurar una red virtual para la instancia administrada

Para configurar la red virtual, los administradores de Contoso deben seguir los pasos siguientes:

1. Crear una nueva red virtual, VNET-SQLMI-EUS2, en la región primaria,East US 2. Contoso agrega la red virtual a ContosoNetworkingRG, un grupo de recursos.

2. Asignan un espacio de direcciones de 10.235.0.0/24. Contoso verifica que el intervalo no se superponga con ninguna otra red de su empresa.

3. Agregan dos subredes a la red:

   • SQLMI-DB-EUS2 con un intervalo de direcciones de 10.235.0.0/25.
   • SQLMI-SAW-EUS2 con un intervalo de direcciones de 10.235.0.128/29. Esta subred asocia un directorio a la instancia administrada.

   

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

   • Emparejar VNET-SQLMI-EUS2 con VNET-HUB-EUS2, que es la red virtual de centro en East US 2.
   • Emparejar VNET-SQLMI-EUS2 con VNET-PROD-EUS2, que es la red de producción.

   

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

   • Se ubican en la subred PROD-DC-EUS2 de VNET-PROD-EUS2, que es la red de producción de East US 2.
   • CONTOSODC3 con la dirección IP 10.245.42.4.
   • La dirección CONTOSODC4 con la dirección IP 10.245.42.5.
   • El solucionador de Azure DNS con la dirección IP 168.63.129.16.

   

¿Necesita más ayuda?

• Inicio rápido: Creación de una red virtual mediante el Portal de Azure
• Incorporación, cambio o eliminación de una subred de red virtual
• Crear, cambiar o eliminar un emparejamiento de red virtual
• Configuración de una red virtual para Instancia administrada de Azure SQL
• Creación y configuración de un dominio administrado de Azure Active Directory Domain Services

Configuración del enrutamiento

Una red virtual privada conecta la instancia administrada. 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.
• Cada paquete que sale de una subred sigue la ruta especificada por la tabla de rutas asociada.
• Una subred tiene una sola tabla de rutas asociada, pero una tabla de rutas puede especificar el enrutamiento para varias subredes.
• 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 rutas definida por el usuario, denominada MIRouteTable, que se asigna a ContosoNetworkingRG, un grupo de recursos.

   

2. Agregan una ruta que tenga un prefijo de dirección de 0.0.0.0/0. La opción Tipo de próximo salto está establecida en Internet. Esta configuración cumple los requisitos que corresponden a SQL Managed Instance.

   

3. Asociar la tabla de enrutamiento con la subred SQLMI-DB-EUS2 en la red VNET-SQLMI-EUS2.

   

¿Necesita más ayuda?

• Creación, modificación o eliminación de una tabla de rutas
• Visualización y cambio de rutas de una instancia administrada

Creación de una instancia administrada

Una vez implementadas la red virtual y la tabla de rutas, los administradores de Contoso pueden aprovisionar una instancia administrada de SQL siguiendo los pasos siguientes:

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, el tamaño de proceso y el almacenamiento de la instancia. Para más información sobre los costos, consulte Precios de Azure SQL Managed Instance.

   

3. Con la implementación de la instancia administrada, ContosoRG incluye dos nuevos recursos:

   • La instancia de SQL Managed Instance.
   • Un clúster virtual que puede admitir varias instancias administradas.

   

¿Necesita más ayuda?

Inicio rápido: Creación de una instancia de Azure SQL Managed Instance.

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

Para preparar Azure Database Migration Service, los administradores de Contoso tienen que llevar a cabo las siguientes tareas:

• Registrar al proveedor de Database Migration Service en Azure.

• Dan a Database Migration Service acceso a Azure Storage para cargar los archivos de copia de seguridad que el servicio usa 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.

Los administradores de Contoso siguen los siguientes pasos:

1. Registran el proveedor de migración de base de datos en la suscripción de Contoso.

   

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

   

3. Crear una instancia de Azure Database Migration Service.

   

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

   • La instancia debe estar en PROD-DC-EUS2 porque el servicio tiene que estar en una red virtual que pueda acceder a la máquina virtual local que ejecuta SQL Server mediante una puerta de enlace de VPN.
   • VNET-PROD-EUS2 se empareja con VNET-HUB-EUS2 y tiene permiso para usar puertas de enlace remotas. Este permiso garantiza que la instancia pueda comunicarse cuando sea necesario. Contoso selecciona Usar puertas de enlace remotas para habilitar esta configuración.

   

¿Necesita más ayuda?

• Tutorial: Migración en línea de SQL Server a Azure SQL Managed Instance mediante Azure Data Studio
• Inicio rápido: Creación de una instancia de Azure Database Migration Service mediante Azure Portal
• Generar un token de SAS
• Creación de una SAS de servicio para un contenedor o blob
• Grant limited access to Azure Storage resources using shared access signatures (SAS) (Otorgar acceso limitado a recursos de Azure Storage con firmas de acceso compartido [SAS])

Paso 3: Preparación de Azure para la herramienta de Migración y modernización

Para poder migrar las máquinas virtuales, Contoso debe realizar las siguientes tareas:

• Crear una red virtual para las máquinas virtuales de Azure que se crean durante la migración.
• Aprovisionar la herramienta Migración y modernización, que es parte de Azure Migrate.

Cuando Contoso se preparó para la migración a Azure en Implementación de una infraestructura de migración, configuró una red que la herramienta de Migración y modernización pudiera usar.

• SmartHotel360 es una aplicación de producción y la migración pone a las máquinas virtuales en la red de producción de Azure, VNET-PROD-EUS2, en la región primaria, East US 2.
• ContosoRG, un grupo de recursos para los recursos de producción, incluye ambas máquinas virtuales.
• La máquina virtual de front-end de la aplicación, WEBVM, se migra 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 migra a la subred de base de datos, PROD-DB-EUS2, de la red de producción.

Paso 4: Preparación de VMware local para la herramienta de Migración y modernización

Para migrar las máquinas virtuales a Azure, Contoso debe tener los siguientes componentes de Azure:

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

Los administradores de Contoso configuran estos componentes siguiendo los siguientes pasos:

1. Cuando Contoso se preparó para la migración a Azure en Implementación de una infraestructura de migración, configuró una red que la herramienta de Migración y modernización pudiera usar.

   • La aplicación SmartHotel360 es una aplicación de producción y, en la migración, las máquinas virtuales se moverán a la red de producción de Azure, VNET-PROD-EUS2, en la región primaria, East US 2.
   • ContosoRG, un grupo de recursos para los recursos de producción, incluye ambas máquinas virtuales.
   • La máquina virtual de front-end de la aplicación, WEBVM, se migra 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 migra a la subred de base de datos, PROD-DB-EUS2, de la red de producción.

2. Aprovisionamiento de la aplicación de Azure Migrate.

   1. Desde Azure Migrate, se descarga el archivo de la imagen .OVA y se importa en VMWare.

      

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

      1. Configure los requisitos previos.

         

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

         

      3. Configure las credenciales de VMWare vCenter.

         

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

         

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

¿Necesita más ayuda?

Herramienta de Migración y modernización

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.
   • Si es necesario, agregue reglas TCP y UDP para el perfil Público.
   • Compruebe que el firewall del sistema operativo permite conexiones RDP o SSH.

2. Para el acceso a través de VPN de sitio a sitio:

   • Habilite RDP o SSH en la VM local antes de la migración.
   • Compruebe que el firewall del sistema operativo permite conexiones RDP o SSH.
   • Para Windows, establezca la directiva de SAN del sistema operativo de la VM local en OnlineAll.

3. Instale el agente de Azure:

   • Agente Linux de Azure
   • Agente de Windows de Azure

4. Otras consideraciones:

   • Para Windows, no debe haber actualizaciones de Windows pendientes en la VM al iniciar una migración. Si hay actualizaciones pendientes, nadie puede iniciar sesión en la máquina virtual hasta que Windows complete sus actualizaciones.
   • Después de la migración, un administrador puede comprobar los diagnósticos de arranque para ver una captura de pantalla de la máquina virtual. Si este método no funciona, un administrador debe comprobar si la máquina virtual está en ejecución, así como revisar estas sugerencias de solución de problemas.

¿Necesita más ayuda?

• Preparación de las máquinas locales para la migración a Azure

Paso 5: Replicar máquinas virtuales locales

Antes de que los administradores de Contoso puedan migrar servidores a Azure, tienen que configurar y habilitar la replicación.

Una vez completada la detección, los administradores pueden comenzar la replicación de máquinas virtuales de VMware en Azure. Realizan los siguientes pasos:

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

   

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

3. En Dispositivo local, seleccione el nombre del dispositivo de Azure Migrate que configuró y, luego, seleccione Aceptar.

   

4. En Máquinas virtuales, seleccionar las máquinas que se van a replicar y elegir si desea importar la configuración de migración desde una evaluación.

   • Si los administradores ejecutaron 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. En ¿Quiere importar la configuración de migración de evaluación de Azure Migrate?, seleccionar Sí.
   • Si los administradores no ejecutaron una evaluación o no quisieron usar la configuración de la evaluación, seleccionar No.
   • Si los administradores deciden usar la evaluación, seleccionar el grupo de máquinas virtuales y el nombre de la evaluación.

   

5. En Máquinas virtuales, busque las máquinas virtuales necesarias y compruebe todas las que quiere migrar. Después, seleccione Next: Configuración de destino.

6. En Configuración de destino, seleccionar la suscripción y la región de destino a la que se van a migrar las máquinas virtuales. Especifique el grupo de recursos en el que residen las máquinas virtuales de Azure después de la migración. En Red virtual, seleccionar la red o subred virtual de Azure a la que se unen las máquinas virtuales de Azure después de la migración.

7. En Ventaja híbrida de Azure:

   • Seleccionar No para aplicar la Ventaja híbrida de Azure.
   • Seleccionar Sí para aplicar opcionalmente suscripciones de Software Assurance o Windows Server a máquinas aptas que usan Windows Server.

   Luego, seleccione Siguiente.

8. En Proceso, revisar los nombres, los tamaños, los tipos de disco del sistema operativo y los conjuntos de disponibilidad de las máquinas virtuales. Deben cumplir los requisitos de Azure. Para más información, consulte los requisitos de VMware en Matriz de compatibilidad para la detección de VMware.

   • Tamaño de máquina virtual: Al usar las recomendaciones de los resultados de la evaluación, la lista de tamaños 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 puede elegir un tamaño de manera manual en Tamaño de la máquina virtual de Azure.
   • Disco del sistema operativo: especifique 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, especifique el conjunto. El conjunto tiene que estar en el grupo de recursos de destino que se especifica para la migración.

9. En Discos, especifique si los discos de máquina virtual se deben replicar en Azure. Después, seleccione el tipo de disco (SSD o HDD estándar o SSD prémium) de Azure y elija Siguiente.

   • De manera opcional, excluir discos de la replicación.
   • Un disco excluido no estará en la máquina virtual de Azure después de la migración.

10. En Revisar e iniciar replicación, revisar la configuración. A continuación, seleccione Replicar para iniciar la replicación inicial de los servidores.

Nota:

Actualice la configuración de replicación en cualquier momento antes de que esta comience; para ello, vaya a 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

Los administradores de Contoso siguen los siguientes pasos:

1. Crear un proyecto de Database Migration Service.

2. Seleccionar el tipo de servidor de origen de SQL Server y Azure SQL Managed Instance como destino.

   

   Se abre el Asistente para migración.

Migración de la base de datos

Los administradores de Contoso siguen los siguientes pasos:

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.

   

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

   

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

   

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 guarda las copias de seguridad de origen en 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.
     • La ruta de acceso al recurso compartido debe ser su nombre de dominio completo.
   • 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.

   

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

6. En Información general, supervisan el estado de la migración.

   

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

   

Paso 7: Migración de las máquinas virtuales con la herramienta de Migración y modernización

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

Los administradores de Contoso siguen los siguientes pasos:

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

   

2. Mantenga presionada o haga clic con el botón derecho en la máquina virtual que va a probar y, a continuación, seleccione 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.

   Comienza el trabajo de Migración de prueba.

4. Supervise 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, en Replicación de máquinas, mantienen presionada o hacen clic con el botón derecho en la máquina virtual de Azure y seleccionan 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 Replicar servidores.

   

2. En Replicación de máquinas, mantenga presionada o haga clic con el botón derecho en la máquina virtual y seleccione Migrar.

3. En Migrar>¿Quiere apagar las máquinas virtuales y realizar una migración planificada sin perder datos? , seleccione Sí>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.
   • Para omitir el apagado de la máquina virtual, seleccionan No.

   Se inicia un trabajo de migración de la máquina virtual.

4. Realice un seguimiento del trabajo en las notificaciones de Azure.

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

6. 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.

   

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

3. Tras configurar 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.

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

5. Apague la máquina SQLVM local.

   La migración ha finalizado.

¿Necesita más ayuda?

• Ejecución de un simulacro de recuperación ante desastres en Azure
• Creación y personalización de los planes de recuperación
• Ejecutar una conmutación por error del entorno local a Azure

Limpiar después de la migración

Una vez finalizada la migración, una máquina virtual de Azure ejecuta la aplicación SmartHotel360 y SQL Managed Instance hospeda la base de datos SmartHotel360.

Ahora, Contoso realiza 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 controlan 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 estudia 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. En caso de amenaza, la detección de amenazas envía una alerta al sistema del equipo o departamento de seguridad de Contoso para abrir una incidencia. Para obtener más información sobre la detección de amenazas, consulte Configuración de Advanced Threat Protection en Azure SQL Managed Instance.

  

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:

• Mantener seguros los datos. Contoso realiza la copia de seguridad de los datos de las máquinas virtuales mediante el servicio Azure Backup. Para más información, consulte la introducción a la copia de seguridad de máquinas virtuales de Azure.
• Mantener las aplicaciones en funcionamiento. Contoso replica las máquinas virtuales de aplicaciones en Azure en una región secundaria mediante Site Recovery. Para más información, consulte Configuración de la recuperación ante desastres en una región secundaria de Azure de una máquina virtual de Azure.
• Más información. Contoso obtiene más información acerca de cómo administrar SQL Managed Instance, incluidas las copias de seguridad de la base de datos.

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 usa Azure Cost Management + Billing para que la empresa permanezca dentro de los presupuestos que la dirección de TI estableció.

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.

Pasos siguientes

• Tailwind Traders: aplicaciones de referencia de ejemplo
• Piedra, papel, tijeras, lagarto, Spock: aplicación de ejemplo