Rehospedaje de una aplicación local en VM de Azure y grupos de disponibilidad Always On de SQL Server

  • Artículo
  • 29 minutos para leer

En este artículo se muestra cómo la compañía ficticia Contoso rehospeda una aplicación de Windows .NET de dos niveles que se ejecuta en máquinas virtuales (VM) de VMware como parte de una migración a Azure. Contoso migra la VM de front-end de la aplicación a una VM de Azure, y la base de datos de la aplicación a otra VM de Azure con SQL Server, que se ejecuta en el clúster de conmutación por error de Windows Server con grupos de disponibilidad Always On de SQL Server.

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 ha trabajado estrechamente con sus socios comerciales para comprender lo quieren lograr con esta migración. Quieren:

  • Abordar el crecimiento del negocio. Contoso está creciendo y, como resultado, los sistemas y la infraestructura locales están bajo presión.
  • 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 sea rápido y no gaste tiempo ni dinero para satisfacer más rápidamente los requisitos del cliente.
  • Aumentar la agilidad. el equipo de TI de Contoso necesita más capacidad de respuesta a las necesidades de la empresa. Debe poder reaccionar con más rapidez que los cambios del mercado para facilitar el éxito en una economía global. No debe entorpecer el avance ni ser un obstáculo para la empresa.
  • Escala. A medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe proporcionar sistemas que crezcan al mismo ritmo.

Objetivos de la migración

El equipo de la nube de Contoso ha establecido los objetivos de esta migración. Estos objetivos se usaron para determinar el mejor método de migración:

  • Después de la migración, la aplicación de Azure debería tener las mismas funcionalidades de rendimiento que tiene actualmente en VMware. La aplicación seguirá siendo tan imprescindible en la nube como lo ha sido en el entorno local.
  • Contoso no quiere invertir en esta aplicación. Es importante para la empresa, pero, en su formato actual, Contoso solo quiere trasladarla a la nube de forma segura.
  • La base de datos local de la aplicación ha tenido problemas de disponibilidad. Contoso quiere implementarla en Azure como un clúster de alta disponibilidad con funcionalidades de conmutación por error.
  • Contoso quiere actualizar su plataforma actual de SQL Server 2008 R2 a SQL Server 2017.
  • Contoso no quiere usar Azure SQL Database para esta aplicación y 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

  • La aplicación se divide en niveles entre dos VM (WEBVM y SQLVM).
  • Las máquinas virtuales se encuentran en el host de VMware ESXi contosohost1.contoso.com (versión 6.5).
  • El entorno de VMware se administra con vCenter Server 6.5 (vcenter.contoso.com), que se ejecuta en una máquina virtual.
  • Contoso tiene un centro de datos local (contoso-datacenter) con un controlador de dominio local (contosodc1).

Arquitectura propuesta

En este escenario:

  • Contoso va a migrar el front-end de la aplicación, WEBVM, a una máquina virtual de infraestructura como servicio (IaaS) de Azure.

    • La VM de front-end de Azure se implementará en el grupo de recursos ContosoRG (usado con los recursos de producción).
    • Se ubicará en la red de producción de Azure (VNET-PROD-EUS2) en la región primaria (East US 2).

  • La base de datos de la aplicación se migrará a una VM de Azure que ejecute SQL Server.

    • Se ubicará en la red de base de datos de Azure de Contoso (PROD-DB-EUS2) en la región primaria (East US 2).
    • Se colocará en un clúster de conmutación por error con Windows Server con dos nodos que usa grupos de disponibilidad Always On de SQL Server.
    • En Azure, los dos nodos de VM de SQL Server del clúster se implementarán en el grupo de recursos ContosoRG.
    • Los nodos de VM se ubicarán en la red de producción de Azure (VNET-PROD-EUS2) en la región primaria (East US 2).
    • Las VM ejecutarán Windows Server 2016 con SQL Server 2017 Enterprise Edition. Contoso no tiene licencias para este sistema operativo. Usará una imagen de Azure Marketplace que ofrece la licencia como un cargo con respecto al compromiso de Contrato Enterprise de Azure de la empresa.
    • A parte de los nombres únicos, ambas máquinas virtuales utilizan la misma configuración.

  • Contoso implementará un equilibrador de carga interno que escucha el tráfico en el clúster y lo dirige al nodo de clúster adecuado.

    • El equilibrador de carga interno se implementará en ContosoNetworkingRG (utilizado para los recursos de redes).

  • Las VM locales del centro de datos de Contoso se retirarán después de realizar la migración.

    Screenshot that shows a diagram of the scenario architecture.

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 Server. Las siguientes consideraciones ayudaron a la empresa a decidirse por usar una máquina virtual de IaaS de Azure que ejecuta SQL Server:

  • El uso de una VM de Azure que ejecuta SQL Server parece ser una solución óptima si Contoso necesita personalizar el sistema operativo o el servidor de bases de datos, o si quisiera ubicar conjuntamente y ejecutar aplicaciones de terceros en la misma VM.

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.

El nivel de SQL Server se ejecutará en SQL Server 2017 y Windows Server 2016, que retira el sistema operativo Windows Server 2008 R2 actual. La ejecución de SQL Server 2017 hace posibles los requisitos técnicos y los objetivos de Contoso. Proporciona el 100 % de compatibilidad en la transición desde SQL Server 2008 R2.

Contoso puede aprovechar su inversión en Software Assurance si usa la Ventaja híbrida de Azure.

Una implementación de SQL Server de alta disponibilidad en Azure proporciona tolerancia a errores, para que el nivel de datos de la aplicación ya no sea un único punto de error en la conmutación por error.
Desventajas WEBVM ejecuta Windows Server 2008 R2. El sistema operativo se admite en Azure para roles específicos (julio de 2018). Para más información, consulte Compatibilidad de software de Microsoft Server para Azure Virtual Machines.

La capa web de la aplicación sigue siendo un único punto de conmutación por error.

Contoso debe seguir admitiendo la capa web como una VM de Azure en lugar de pasar a un servicio administrado, como Azure App Service.

Con la solución elegida, Contoso debe seguir administrando dos máquinas virtuales con SQL Server en lugar de pasar a una plataforma administrada como Azure SQL Managed Instance. Además, con Software Assurance, Contoso puede intercambiar sus licencias existentes por descuentos en Azure SQL Managed Instance.

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

Proceso de migración

Los administradores de Contoso migrarán las máquinas virtuales de la aplicación a Azure.

  • Migrarán la máquina virtual de front-end a una máquina virtual de Azure mediante Azure Migrate:

    • Primero, prepararán y configurarán los componentes de Azure, y prepararán la infraestructura local de VMware.
    • Con todo preparado, podrá empezar a replicar la VM.
    • Una vez que se haya habilitado la replicación y esté en funcionamiento, la máquina virtual se migra con Azure Migrate.

  • Después de comprobar la base de datos, se migrará a un clúster de SQL Server en Azure con Azure Database Migration Service.

    • Para empezar, deberán aprovisionar las máquinas virtuales con SQL Server en Azure, configurar el clúster y un equilibrador de carga interno y configurar los grupos de disponibilidad Always On.
    • Cuando complete todo esto, podrá migrar la base de datos.

  • Después de la migración, deberá habilitar los grupos de disponibilidad Always On para la base de datos.

    Screenshot that shows a diagram of the migration process.

Requisitos previos

Esto es lo que debe hacer Contoso en este escenario.

Requisitos Detalles
Suscripción de Azure Contoso ya ha creado una suscripción en un artículo anterior 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 y no es el administrador, solicite al administrador que le asigne permisos de propietario o colaborador.

Infraestructura de Azure Contoso configura la infraestructura de Azure según se describe en la infraestructura de Azure para la migración.

Más información sobre los requisitos previos específicos para Azure Migrate: Server Migration.
Servidores locales La versión de la instalación local de vCenter Server debe ser la 5.5, 6.0, 6.5 o 6.7.

Un host ESXi que ejecute la versión 5.5, 6.0, 6.5 o 6.7.

Una o más máquinas virtuales VMware que se ejecuten en el host ESXi.
Máquinas virtuales locales Revise las máquinas Linux que se han aprobado para ejecutarse en Azure.

Pasos del escenario

Contoso ejecutará la migración de la forma siguiente:

  • Paso 1: Preparación de un clúster del grupo de disponibilidad Always On de SQL Server. cree un clúster para implementar dos nodos de máquina virtual de SQL Server en Azure.
  • Paso 2: Implementación y configuración del clúster. Prepare un clúster de SQL Server en Azure. Las bases de datos se migran a este clúster existente.
  • Paso 3: Implementación de Azure Load Balancer. implemente un equilibrador de carga para equilibrar el tráfico entre los nodos de SQL Server.
  • Paso 4: Preparación de Azure para Azure Migrate. Cree una cuenta de Azure Storage para almacenar los datos replicados.
  • Paso 5: Preparación del entorno de VMware local para Azure Migrate. prepare cuentas para la instalación del agente y la detección de máquinas virtuales. Prepare las máquinas virtuales locales para que los usuarios puedan conectarse a las máquinas virtuales de Azure después de la migración.
  • Paso 6: Replicación de las máquinas virtuales locales en Azure. habilite la replicación de máquinas virtuales en Azure.
  • Paso 7: Migración de la base de datos mediante Azure Database Migration Service. Migre la base de datos a Azure con Azure Database Migration Service.
  • Paso 8: Protección de la base de datos con Always On de SQL Server. Cree un grupo de disponibilidad AlwaysOn para el clúster.
  • Paso 9: Migración de la máquina virtual con Azure Migrate. Ejecute una migración de prueba para asegurarse de que todo funciona de la forma esperada. A continuación, ejecute una migración a Azure

Paso 1: Preparación de un clúster del grupo de disponibilidad AlwaysOn de SQL Server

Para configurar el clúster, los administradores de Contoso:

  1. Crean dos máquinas virtuales con SQL Server mediante la selección de la imagen de Windows Server 2016 con SQL Server 2017 Enterprise en Azure Marketplace.

    Screenshot that shows a SQL VM SKU.

  2. En el Asistente para crear máquinas virtuales>Conceptos básicos, se configura:

    • Nombres de las VM: SQLAOG1 y SQLAOG2.
    • Dado que las máquinas son críticas para la empresa, se habilita SSD para el tipo de disco de la máquina virtual.
    • Especifican las credenciales de la máquina.
    • Implementan las máquinas virtuales en la región primaria (East US 2), en el grupo de recursos ContosoRG.

  3. En Tamaño, comienza con D2S v3 instancias para ambas VM. Posteriormente, se escalarán según sea necesario.

  4. En Configuración, realizan las siguientes acciones:

    • Dado que en estas máquinas virtuales hay bases de datos críticas para la aplicación, se usan discos administrados.

    • Coloca las máquinas en la subred de base de datos (PROD-DB-EUS2) de la red de producción (VNET-PROD-EUS2) en la región primaria (East US 2).

    • Crea un nuevo conjunto de disponibilidad, denominado SQLAOGAVSET, con dos dominios de error y cinco dominios de actualización.

      Screenshot that shows a new availability set.

  5. En Configuración de SQL Server, se limita la conectividad de SQL a la red virtual (privada) del puerto 1433 predeterminado. Para la autenticación, se usan las mismas credenciales que en el entorno local (contosoadmin).

    Screenshot that shows SQL Server settings.

¿Necesita más ayuda?

Paso 2: Implementación y configuración del clúster

Para configurar el clúster, los administradores de Contoso:

  1. Configuran una cuenta de Azure Storage para que actúe como testigo en la nube.
  2. Agregan las máquinas virtuales con SQL Server en el dominio de Active Directory del centro de datos local de Contoso.
  3. Crean el clúster en Azure.
  4. Configuran el testigo en la nube.
  5. Habilitan grupos de disponibilidad Always On de SQL.

Configuración de una cuenta de almacenamiento como testigo en la nube

Para configurar un testigo en la nube, Contoso necesita una cuenta de Azure Storage que contendrá el archivo de blob que se usa para el arbitraje de clúster. La misma cuenta de almacenamiento puede utilizarse para configurar el testigo en la nube para varios clústeres.

Para crear una cuenta de almacenamiento, los administradores de Contoso:

  1. Especifican un nombre reconocible para la cuenta (contosocloudwitness).

  2. Implementan una cuenta de uso general con LRS.

  3. Colocan la cuenta en una tercera región (South Central US). La coloca fuera de la región principal y secundaria para que permanezca disponible durante un error regional.

  4. La colocan en el grupo de recursos que contiene los recursos de infraestructura, ContosoInfraRG.

    Screenshot that shows the cloud witness account name.

  5. Al crear la cuenta de almacenamiento, se generan las claves de acceso principal y secundaria. La clave de acceso principal es necesaria para crear al testigo en la nube. La clave aparece bajo el nombre de la cuenta de almacenamiento >Claves de acceso.

    Screenshot that shows the access key.

Adición de las VM con SQL Server al dominio de Contoso

  1. Contoso agrega SQLAOG1 y SQLAOG2 al dominio contoso.com.
  2. Los administradores instalan en cada máquina virtual la característica de clúster de conmutación por error con Windows y las herramientas.

Configuración del clúster

Antes de configurar el clúster, los administradores de Contoso toman una instantánea del disco del sistema operativo en cada máquina.

Screenshot that shows the Create snapshot pane.

  1. Ejecutan un script para crear el clúster de conmutación por error con Windows.

    Screenshot that shows a script to create the Windows failover cluster.

  2. Después de crear el clúster, comprueban que las máquinas virtuales aparecen como nodos de clúster.

    Screenshot that shows the clusters are created.

Configuración del testigo en la nube

  1. Los administradores de Contoso configuran el testigo en la nube mediante el Asistente para la configuración de cuórum en el Administrador de clústeres de conmutación por error.

  2. En el asistente, se selecciona la opción para crear a un testigo en la nube con la cuenta de almacenamiento.

  3. Después de configurar el testigo en la nube, este aparece en el complemento Administrador de clústeres de conmutación por error.

    Screenshot that shows the cloud witness is configured.

Habilitación de Grupos de disponibilidad Always On de SQL Server

Los administradores de Contoso ahora pueden habilitar grupos de disponibilidad Always On:

  1. En el Administrador de configuración de SQL Server, se habilita Grupos de disponibilidad Always On para el servicio SQL Server (MSSQLSERVER) .

    Screenshot that shows the Enable Always On Availability Groups checkbox.

  2. Reinicia el servicio para que los cambios surtan efecto.

Con los grupos de disponibilidad Always On habilitados, Contoso puede configurar el grupo de disponibilidad Always On que protegerá la base de datos de SmartHotel360.

¿Necesita más ayuda?

Paso 3: Implementación de Azure Load Balancer

Ahora, los administradores de Contoso quieren implementar un equilibrador de carga interno que se ubique delante de los nodos del clúster. El equilibrador de carga escucha el tráfico y lo dirige al nodo adecuado.

Diagram that shows load balancing.

Para crear el equilibrador de carga, los administradores de Contoso:

  1. En Azure Portal, seleccionan Redes>Equilibrador de carga y configuran un equilibrador de carga interno nuevo: ILB-PROD-DB-EUS2-SQLAOG.

  2. Colocan el equilibrador de carga en la subred de la base de datos (PROD-DB-EUS2) de la red de producción (VNET-PROD-EUS2).

  3. Le asignan una dirección IP estática (10.245.40.100).

  4. Al ser un elemento de redes, implementan el equilibrador de carga en el grupo de recursos de redes ContosoNetworkingRG.

    Screenshot that shows the Create load balancer pane.

Una vez implementado el equilibrador de carga interno, los administradores de Contoso deben configurarlo. Se crea un grupo de direcciones de back-end, configura un sondeo de estado y establece una regla de equilibrio de carga.

Adición de un grupo de back-end

Para distribuir el tráfico a las máquinas virtuales del clúster, los administradores de Contoso configuran un grupo de direcciones de back-end que contiene las direcciones IP de las NIC de las máquinas virtuales que van a recibir tráfico de red del equilibrador de carga.

  1. En la configuración del equilibrador de carga del portal, Contoso agrega un grupo de back-end: ILB-PROD-DB-EUS-SQLAOG-BEPOOL.

  2. Los administradores asocian el grupo con el conjunto de disponibilidad SQLAOGAVSET. Las VM del conjunto (SQLAOG1 y SQLAOG2) se agregan al grupo.

    Screenshot that shows the Add backend pool screen.

Creación de un sondeo de estado

Para que el equilibrador de carga pueda supervisar el estado de la aplicación, los administradores de Contoso crean un sondeo de estado. El sondeo agrega o elimina de forma dinámica las máquinas virtuales de la rotación del equilibrador de carga en función de cómo responden a las comprobaciones de estado.

Para crear el sondeo, los administradores de Contoso:

  1. Crean un sondeo de estado en la configuración del equilibrador de carga en el portal: SQLAlwaysOnEndPointProbe.

  2. Lo establecen para supervisar las máquinas virtuales en el puerto TCP 59999.

  3. Establecen un intervalo de 5 segundos entre sondeos y un umbral de 2. Si se produce un error en los dos sondeos, se considerará que el estado de la VM es incorrecto.

    Screenshot that shows the Add health probe screen.

Configuración del equilibrador de carga para recibir tráfico

Ahora, los administradores de Contoso configuran una regla del equilibrador de carga para definir cómo se distribuye el tráfico a las máquinas virtuales.

  • La dirección IP de front-end controla el tráfico entrante.
  • El grupo de IP de back-end recibe el tráfico.

Para crear la regla, los administradores de Contoso:

  1. Agregan una nueva regla en la configuración del equilibrador de carga en el portal: SQLAlwaysOnEndPointListener.

  2. Establecen un cliente de escucha de front-end para recibir el tráfico entrante del cliente de SQL en el puerto TCP 1433.

  3. Especifican el grupo de back-end al que se enrutará el tráfico y el puerto en el que las máquinas virtuales escuchan el tráfico.

  4. Habilitan la dirección IP flotante (Direct Server Return), que siempre es necesaria para Always On de SQL Server.

    Screenshot that shows health probe settings.

¿Necesita más ayuda?

Paso 4: Preparación de Azure para Azure Migrate

Estos son los componentes de Azure que Contoso necesita para implementar Azure Migrate:

  • Una red virtual en la que ubicar las máquinas virtuales cuando se migren.
  • Una cuenta de Azure Storage para almacenar los datos replicados.

Los administradores de Contoso configuran estos componentes:

  1. Contoso ya creó una red y una subred que se puede utilizar para Azure Migrate cuando se implementó la infraestructura de Azure.

    • La aplicación SmartHotel360 es una aplicación de producción, y WEBVM se migrará a la red de producción de Azure (VNET-PROD-EUS2) en la región primaria (East US 2).
    • WEBVM se colocará en el grupo de recursos ContosoRG, que se utiliza para los recursos de producción, y en la subred de producción (PROD-FE-EUS2).

  2. Los administradores de Contoso crean una cuenta de Azure Storage (contosovmsacc20180528) en la región primaria.

    • Se utiliza una cuenta de uso general con almacenamiento estándar y replicación LRS.

Paso 5: Preparación del entorno de VMware local para Azure Migrate

Así preparan el entorno local los administradores de Contoso:

  • Una cuenta en vCenter Server o en el host ESXi de vSphere para automatizar la detección de máquinas virtuales.
  • Configuración de la máquina virtual local para que Contoso pueda conectarse a la máquina virtual de Azure replicada después de la migración.

Preparación de una cuenta de detección automática

Azure Migrate necesita acceso a los servidores de VMware para:

  • Detectar automáticamente las máquinas virtuales.
  • Organizar la replicación y la migración.
  • Se requiere al menos una cuenta de solo lectura. Se necesita una cuenta que pueda ejecutar operaciones como la creación y eliminación de discos, así como la activación de máquinas virtuales.

Para configurar la cuenta, los administradores de Contoso:

  1. Cree un rol en el nivel de vCenter.
  2. Asignan a ese rol los permisos necesarios.

Preparación para la conexión a VM de Azure después de la migración

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 realizan las siguientes tareas 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.
    • Para Windows, establezca la directiva de SAN del sistema operativo de la VM local en OnlineAll.

  3. Instale el agente de Azure:

  4. Varios

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

¿Necesita más ayuda?

Más información sobre cómo preparar las máquinas virtuales para la migración.

Paso 6: Replicar VM locales en Azure

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

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

  1. En el proyecto de Azure Migrate, seleccionan Servidores>Azure Migrate: Migración del servidor y seleccionan Replicar.

    Screenshot that shows the Replicate option.

  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.

    Screenshot that shows the Source settings tab.

  4. En Máquinas virtuales, seleccionan las máquinas que se van a replicar.

    • Si los administradores de Contoso han ejecutado una evaluación de 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? , seleccionan la opción Sí.
    • 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.

    Screenshot that shows selecting assessments.

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

  6. En Configuración de destino, seleccionan la suscripción y la región de destino a la que se va a migrar y 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 y 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, los administradores de Contoso:

    • Seleccionan No si no desean aplicar la Ventaja híbrida de Azure. A continuación, seleccionan Siguiente.
    • Seleccionan Sí 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. A continuación, 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 la 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 SSD prémium) 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 7: Migración de la base de datos mediante Azure Database Migration Service

Los administradores de Contoso siguen el tutorial de migración paso a paso para migrar la base de datos con Azure Database Migration Service. Pueden realizar migraciones en línea, sin conexión e híbridas (versión preliminar).

En resumen, deben realizar las siguientes tareas:

  • Usar el plan de tarifa Premium para crear una instancia de Azure Database Migration Service que se conecte a la red virtual.
  • Asegúrese de que la instancia pueda acceder a la instancia remota de SQL Server a través de la red virtual. Asegurarse de que todos los puertos de entrada están permitidos desde Azure a SQL Server en el nivel de la red virtual, la VPN de red y la máquina que hospeda SQL Server.
  • Configure la instancia:
    • Cree un proyecto de migración.
    • Agregue un origen (base de datos local).
    • Seleccione un destino.
    • Seleccione las bases de datos que se van a migrar.
    • Configure las opciones avanzadas.
    • Inicie la replicación.
    • Resuelva posibles errores.
    • Realice la migración final.

Paso 8: Protección de la base de datos con Always On de SQL Server

Una vez que la base de datos de la aplicación se ejecuta en SQLAOG1, los administradores de Contoso pueden protegerla ahora con grupos de disponibilidad Always On. Configuran Always On de SQL Server con SQL Server Management Studio y, a continuación, asignan un cliente de escucha mediante la agrupación en clústeres de Windows.

Creación de un grupo de disponibilidad Always On

  1. En SQL Server Management Studio, selecciona y mantiene presionado (o hace doble clic) en Alta disponibilidad de Always On para iniciar el Asistente para nuevo grupo de disponibilidad.

  2. En Especificar opciones, asigna el nombre SHAOG al grupo de disponibilidad. En Seleccionar bases de datos, selecciona la base de datos SmartHotel360.

    Screenshot that shows the Select Databases pane.

  3. En Especificar réplicas, agregan los dos nodos de SQL como réplicas de disponibilidad y los configuran para proporcionar la conmutación por error automática con confirmación sincrónica.

    Screenshot that shows the Replicas tab.

  4. Configura un agente de escucha para el grupo (SHAOG) y el puerto. La dirección IP del equilibrador de carga interno se agrega como dirección IP estática (10.245.40.100).

    Screenshot that shows the Create an availability group listener option.

  5. En Seleccionar sincronización de datos, permite la inicialización automática. Con esta opción, SQL Server crea automáticamente las réplicas secundarias para cada base de datos del grupo, por lo que Contoso no debe realizar manualmente la copia de seguridad ni restaurarla. Después de la validación, se crea el grupo de disponibilidad.

    Screenshot showing that the Always On availability group was created.

  6. Contoso tuvo un problema al crear el grupo. Dado que no usa la seguridad integrada de Windows de Active Directory, debe conceder permisos para el inicio de sesión de SQL para crear los roles del clúster de conmutación por error con Windows.

    Screenshot that shows granting permissions to the SQL login.

  7. Una vez creado el grupo, aparece en SQL Server Management Studio.

Configuración de un agente de escucha en el clúster

Como último paso en la configuración de la implementación de SQL, los administradores de Contoso configuran el equilibrador de carga interno como cliente de escucha del clúster y conectan el cliente de escucha. Utilizan un script para realizar esta tarea.

Screenshot that shows the cluster listener.

Comprobar la configuración

Con todo configurado, Contoso ahora tiene un grupo de disponibilidad funcional en Azure que usa la base de datos migrada. Los administradores comprueban la configuración con una conexión al equilibrador de carga interno desde SQL Server Management Studio.

Screenshot that shows the internal load balancer connection.

¿Necesita más ayuda?

Paso 9: Migración de la VM con Azure Migrate

Los administradores de Contoso ejecutan una conmutación por error de prueba rápida y, a continuación, migran la máquina virtual.

Ejecutar una migración de prueba

La ejecución de una migración de prueba ayuda a garantizar que todo funciona según lo esperado antes de la migración. Los administradores de Contoso:

  1. Ejecutan una conmutación por error de prueba en el punto más reciente en el tiempo disponible (Latest processed).

  2. Seleccionan Apague la máquina antes de comenzar con la conmutación por error para que Azure Migrate intente apagar la máquina virtual de origen antes de desencadenar la conmutación por error. La conmutación por error continúa aunque se produzca un error de cierre.

  3. Se ejecuta una conmutación por error de prueba:

    • Se ejecuta una comprobación de requisitos previos para garantizar que todas las condiciones necesarias para la conmutación por error están correctamente establecidas.
    • La conmutación por error procesa los datos, de modo que se pueda crear una máquina virtual de Azure. Si se selecciona el último punto de recuperación, se crea un punto de recuperación a partir de los datos.
    • Se crea una máquina virtual de Azure con los datos procesados en el paso anterior.

  4. Una vez finalizada la conmutación por error, la VM de Azure de réplica aparece en Azure Portal. Contoso comprueba si la VM tiene el tamaño adecuado, si está conectada a la red correspondiente y si se está ejecutando.

  5. Después, limpia la conmutación por error y registra y guarda las observaciones.

Ejecución de la conmutación por error

  1. Después de comprobar que la conmutación por error de prueba ha funcionado según lo esperado, crean un plan de recuperación para la migración y agregan WEBVM al plan.

    Screenshot that shows the Create recovery plan pane.

  2. Ejecuta una conmutación por error en el plan. Seleccionan el punto de recuperación más reciente. Especifican que Azure Migrate debe intentar apagar la máquina virtual local antes de desencadenar la conmutación por error.

    Screenshot that shows the Failover pane.

  3. Después de la conmutación por error, Contoso comprueba si la VM de Azure aparece según lo esperado en Azure Portal.

    Screenshot that shows an overview pane for the virtual machine.

  4. Después de verificar la VM en Azure, completa la migración para finalizar el proceso de migración, detiene la replicación para la VM y detiene la facturación de Azure Migrate de la VM.

    Screenshot that shows the Complete migration item.

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 el cliente de escucha SHAOG. Esta configuración se cambiará en WEBVM, que ahora se ejecuta en Azure. Esta configuración se encuentra en el archivo web.config de la aplicación ASP.NET.

  1. Los administradores de Contoso buscan el archivo en C:\inetpub\SmartHotelWeb\web.config y cambian el nombre del servidor para que refleje el FQDN del grupo de disponibilidad Always On: shaog.contoso.com.

    Screenshot that shows the FQDN of the Always On availability group.

  2. Después de actualizar el archivo y guardarlo, reinicia IIS en WEBVM. Utilizan iisreset /restart desde un símbolo del sistema.

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

¿Necesita más ayuda?

Limpiar después de la migración

Después de la migración, la aplicación SmartHotel360 se ejecuta en una máquina virtual de Azure. La base de datos SmartHotel360 se encuentra en el clúster de SQL Server de Azure.

Ahora, Contoso debe completar estos pasos de limpieza:

  • Quitar las VM locales del inventario de vCenter.
  • Quitar las VM de los trabajos de copia de seguridad locales.
  • Actualizar la documentación interna para que muestre las nuevas ubicaciones y las direcciones IP de las VM.
  • 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.
  • Agregar las dos nuevas máquinas virtuales (SQLAOG1 y SQLAOG2) a los sistemas de supervisión de producció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 revisa las máquinas virtuales WEBVM, SQLAOG1 y SQLAOG2 para determinar si existe algún problema de seguridad. El equipo debe:

  • Revisar los grupos de seguridad de red (NSG) de la máquina virtual para controlar el acceso. Los NSG se usan para garantizar que solo el tráfico permitido puede pasar a la aplicación.
  • Considerar la posibilidad de proteger los datos en disco mediante Azure Disk Encryption y Azure Key Vault.
  • Evaluar el cifrado de datos transparente. A continuación, habilitarlo en la base de datos SmartHotel360 que se ejecuta en el nuevo grupo de disponibilidad Always On. Más información sobre el cifrado de discos transparente.

Para obtener más información, 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

  • Actualmente, Contoso tiene licencias existentes para su WEBVM y aprovechará la Ventaja híbrida de Azure. Contoso convertirá las máquinas virtuales de Azure existentes para aprovechar las ventajas que ofrecen estos precios.
  • 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 ha rehospedado la aplicación SmartHotel360 en Azure mediante la migración de la máquina virtual de front-end de la aplicación a Azure con Azure Migrate. Contoso ha migrado la base de datos de la aplicación a un clúster de SQL Server aprovisionado en Azure mediante Azure Database Migration Service y la ha protegido en un grupo de disponibilidad Always On de SQL Server.