Migración de un grupo de disponibilidad Always On de SQL Server a Azure VMware Solution

Artículo
01/08/2025

En este artículo, obtendrá información sobre cómo migrar un grupo de disponibilidad AlwaysOn de SQL Server a Azure VMware Solution. Para VMware HCX, puede seguir el procedimiento de migración de VMware vMotion.

Microsoft SQL Server (2019 y 2022) se probó con Windows Server (2019 y 2022) edición Data Center con las máquinas virtuales implementadas en el entorno local. Windows Server y SQL Server están configurados siguiendo los procedimientos recomendados y recomendaciones de Microsoft y VMware. La infraestructura de origen local era VMware vSphere 7.0 Update 3 y VMware vSAN que se ejecuta en servidores Dell PowerEdge y dispositivos NVMe SSD Intel Optane P4800X.

Requisitos previos

Estos son los requisitos previos para migrar la instancia de SQL Server a Azure VMware Solution.

Revise y registre la configuración de almacenamiento y red de cada nodo del clúster.
Mantenga copias de seguridad de todas las bases de datos de SQL Server.
Realice una copia de seguridad de la máquina virtual o de las máquinas virtuales que hospedan SQL Server.
Quite la máquina virtual de cualquier grupo y reglas de VMware vSphere Distributed Resource Scheduler (DRS).
VMware HCX debe configurarse entre el centro de datos local y la nube privada de Azure VMware Solution que ejecuta las cargas de trabajo migradas. Para más información sobre cómo configurar HCX, consulte Documentación de Azure VMware Solution.
Asegúrese de que todos los segmentos de red que usan SQL Server y las cargas de trabajo que lo usan se extienden a la nube privada de Azure VMware Solution. Para comprobar este paso, consulte Configuración de la extensión de red de VMware HCX.

La conectividad de VMware HCX a través de VPN o ExpressRoute se puede usar como configuración de red para la migración.

Con VMware HCX a través de VPN, debido a su ancho de banda limitado, suele ser adecuado para cargas de trabajo que pueden mantener períodos de inactividad más largos (como entornos de no producción).

Para cualquiera de las siguientes instancias, se recomienda la conectividad de ExpressRoute para una migración:

Entornos de producción
Cargas de trabajo con tamaños de base de datos grandes
En los casos en los que es necesario minimizar el tiempo de inactividad, se recomienda la conectividad de ExpressRoute para la migración.

En la siguiente sección se describen más consideraciones sobre el tiempo de inactividad.

Consideraciones de tiempo de inactividad

El tiempo de inactividad durante una migración depende del tamaño de la base de datos que se va a migrar y de la velocidad de la conexión de red privada a la nube de Azure. Aunque las migraciones de grupos de disponibilidad de SQL Server pueden ejecutarse con un tiempo de inactividad mínimo de la solución, es óptimo realizar la migración durante las horas de menor actividad dentro de una ventana de cambio aprobada previamente.

En la siguiente tabla se indica el tiempo de inactividad estimado para la migración de cada topología de SQL Server.

Escenario	Tiempo de inactividad esperado	Notas
Instancia independiente de SQL Server	Bajo	La migración se realiza mediante VMware vMotion, la base de datos está disponible durante el tiempo de migración, pero no se recomienda confirmar ningún dato crítico durante ella.
Grupo de disponibilidad Always On de SQL Server	Bajo	La réplica principal siempre estará disponible durante la migración de la primera réplica secundaria y la réplica secundaria se convertirá en la principal después de la conmutación por error inicial a Azure.
Instancia de clúster de conmutación por error Always On de SQL Server	Alto	Todos los nodos del clúster se apagan y migran mediante la migración en frío de VMware HCX. La duración del tiempo de inactividad depende del tamaño de la base de datos y la velocidad de red privada a la nube de Azure.

Consideraciones de cuórum de clúster de conmutación por error de Windows Server

Los grupos de disponibilidad AlwaysOn de Microsoft SQL Server dependen del clúster de conmutación por error de Windows Server, que requiere un mecanismo de votación de cuórum para mantener la coherencia del clúster.

Se requiere un número impar de elementos de votación, que se logra mediante un número impar de nodos en el clúster o mediante un testigo. El testigo se puede configurar de tres maneras diferentes:

Testigo de disco
Testigo de recurso compartido de archivos
Testigo en la nube

Si el clúster usa un testigo de disco, el disco debe migrarse con el resto del almacenamiento compartido del clúster mediante el procedimiento descrito en este documento.

Si el clúster usa un testigo de recurso compartido de archivos que se ejecuta de forma local, el tipo de testigo para el clúster migrado depende del escenario de Azure VMware Solution, hay varias opciones que se deben tener en cuenta.

Extensión del centro de datos: mantenga el testigo del recurso compartido de archivos local. Las cargas de trabajo se distribuyen entre el centro de datos y Azure. Por lo tanto, la conectividad entre el centro de datos y Azure siempre debe estar disponible. En cualquier caso, tenga en cuenta las restricciones de ancho de banda y planifique en consecuencia.
Salida del centro de datos: para este escenario, hay dos opciones. En ambas opciones, puede mantener el testigo del recurso compartido de archivos local durante la migración en caso de que tenga que revertir durante el proceso.
- Implemente un nuevo testigo de recurso compartido de archivos en la nube privada de Azure VMware Solution.
- Implemente un testigo en la nube que se ejecute en Azure Blob Storage en la misma región que la nube privada de Azure VMware Solution.
Recuperación ante desastres y continuidad empresarial: para un escenario de recuperación ante desastres, la mejor y la opción más confiable es crear un testigo en la nube que se ejecuta en Azure Storage.
Modernización de aplicaciones: para este caso de uso, la mejor opción es implementar un testigo en la nube.

Para más información sobre cómo configurar y administrar el cuórum, consulte Documentación sobre clústeres de conmutación por error. Para obtener información sobre la implementación del testigo en la nube en Azure Blob Storage, consulte Administración de un cuórum de clúster para un clúster de conmutación por error.

Migración del grupo de disponibilidad AlwaysOn de SQL Server

Acceda al grupo de disponibilidad AlwaysOn con SQL Server Management Studio mediante credenciales de administración.
- Seleccione la réplica principal y abra Grupo de disponibilidad Propiedades.
- Cambie Modo de disponibilidad a Confirmación asincrónica solo para que se migre la réplica.
- Cambie Modo de conmutación por error a Manual para cada miembro del grupo de disponibilidad.
Acceda a vCenter Server local y continúe con el área HCX.
En Servicios, seleccione Migración>Migrar.
- Seleccione una máquina virtual que ejecute la réplica secundaria de la base de datos que se va a migrar.
- Establezca el clúster de vSphere en la nube privada remota, que ahora hospeda la máquina virtual o las máquinas virtuales de SQL Server migradas como contenedor de proceso.
- Seleccione el Almacén de datos vSAN como almacenamiento remoto.
- Selecciona una carpeta. No es obligatorio, pero se recomienda separar las distintas cargas de trabajo de la nube privada de Azure VMware Solution.
- Mantenga el mismo formato que el de origen.
- Seleccione vMotion como perfil de migración.
- En Opciones extendidas seleccione Migrar atributos personalizados.
- Compruebe que los segmentos de red locales tienen el segmento extendido remoto correcto en Azure.
- Seleccione Validar y asegúrese de que todas las comprobaciones se completan con el estado de paso. El error más común está relacionado con la configuración de almacenamiento. Compruebe de nuevo que no haya controladores SCSI virtuales con la configuración de uso compartido físico.
- Seleccione Continuar para iniciar la migración.
Una vez completada la migración, acceda a la réplica migrada y compruebe la conectividad con el resto de los miembros del grupo de disponibilidad.
En SQL Server Management Studio, abra el panel del grupo de disponibilidad y compruebe que la réplica aparece como En línea.
- El estado Pérdida de datos en la columna Preparación de conmutación por error es el esperado, ya que la réplica no está sincronizada con la principal durante la migración.
Edite de nuevo el Grupo de disponibilidad Propiedades y vuelva a establecer el Modo de disponibilidad en Confirmación sincrónica.
- La réplica secundaria comienza a sincronizar todos los cambios realizados en la réplica principal durante la migración. Espere hasta que aparezca en estado Sincronizado.
En el panel del grupo de disponibilidad, en SSMS, seleccione Asistente para iniciar conmutación por error.
Seleccione la réplica migrada y seleccione Siguiente.
Conéctese a la réplica en la siguiente pantalla con las credenciales de administrador de la base de datos.
Revise los cambios y seleccione Finalizar para iniciar la operación de conmutación por error.
Supervise el progreso de la conmutación por error en la siguiente pantalla, seleccione Cerrar cuando finalice la operación.
Actualice la vista del Explorador de objetos en SQL Server Management Studio (SSMS), compruebe que la instancia migrada es ahora la réplica principal.
Repita los pasos del 1 al 6 para el resto de las réplicas del grupo de disponibilidad.

Nota:

Migre una réplica cada vez y compruebe que todos los cambios se vuelven a sincronizar con la réplica después de cada migración. No migre todas las réplicas al mismo tiempo con la Migración masiva de HCX.
Una vez completada la migración de todas las réplicas, acceda al grupo de disponibilidad AlwaysOn con SQL Server Management Studio.
- Abra el panel y compruebe que no haya pérdida de datos en ninguna de las réplicas y que todas estén en estado Sincronizado.
- Edite las Propiedades del grupo de disponibilidad y establezca el Modo de conmutación por error en Automático en todas las réplicas.