Share via

Migración de una instancia de clúster de conmutación por error Always On de SQL Server a Azure VMware Solution

  • Artículo

En este artículo, aprenderá a migrar una instancia de clúster de conmutación por error de SQL Server a Azure VMware Solution. Actualmente, el servicio Azure VMware Solution no admite VMware Hybrid Linked Mode para conectar una instancia local de vCenter Server con una que se ejecuta en Azure VMware Solution. Esta restricción hace que este proceso requiera el uso de VMware HCX para la migración. Para más información sobre cómo configurar HCX, consulte Instalación y activación de VMware HCX en Azure VMware Solution.

VMware HCX no admite la migración de máquinas virtuales con controladores SCSI en modo de uso compartido físico conectado a una máquina virtual. Sin embargo, para superar esta limitación es preciso seguir los pasos que se muestran en este procedimiento y usar la migración en frío de VMware HCX para mover las distintas máquinas virtuales que componen el clúster.

Diagrama que muestra la arquitectura de conmutación por error de SQL Server para Azure VMware Solution.

Nota:

Este procedimiento requiere un apagado completo del clúster. Como el servicio SQL Server no va a estar disponible durante la migración, realice el planeamiento en consecuencia para el período de tiempo de inactividad.

Microsoft SQL Server (2019 y 2022) se ha probado con servidores con Windows Server 2019 y 2022, Data Center Edition, con las máquinas virtuales implementadas en el entorno local. Para configurar Windows Server y SQL Server se han seguido los procedimientos recomendados de Microsoft y VMware. La infraestructura de origen local era VMware vSphere 7.0 Update 3 y VMware vSAN que se ejecutan en servidores Dell PowerEdge y dispositivos NVMe SSD Intel Optane P4800X.

Requisitos previos

  • Consulte y registre la configuración de almacenamiento y red de todos los nodos del clúster.
  • Consulte y registre la configuración de WSFC.
  • Mantenga copias de seguridad de todas las bases de datos de SQL Server.
  • Realice una copia de seguridad de las máquinas virtuales del clúster.
  • Quite todas las máquinas virtuales del nodo de clúster de los grupos y reglas del Programador de recursos distribuidos (DRS) de los que forman parte.
  • 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 instalar VMware HCX, consulte la documentación de Azure VMware Solution.
  • Asegúrese de que todos los segmentos de red que usa 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.

Consideraciones del 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. La migración de instancias Always On del clúster de conmutación por error de SQL Server a Azure VMware Solution requiere un tiempo de inactividad completo de la base de datos y de todos los nodos de clúster, pero debe planear que la migración se ejecute durante las horas de poca actividad con una ventana de cambio aprobada.

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 sobre el cuórum del clúster de conmutación por error de Windows Server

El clúster de conmutación por error de Windows Server requiere un mecanismo de cuórum para mantener el clúster.

Utilice un número impar de elementos de votación que se puede lograr mediante un número impar de nodos en el clúster o mediante el uso de 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 disco testigo, el disco se debe migrar con el almacenamiento compartido del clúster mediante la opción de migrar el clúster de conmutación por error.

Si el clúster usa un testigodel recurso compartido de archivos que se ejecuta en un entorno local, el tipo de testigo del clúster migrado depende del escenario de Azure VMware Solution:

  • Extensión del centro de datos: mantenga el testigo del recurso compartido de archivos en un entorno local. Las cargas de trabajo se distribuyen entre el centro de datos y Azure VMware Solution, por lo que la conectividad entre ambos debería estar disponible en todo momento. En cualquier caso, tenga en cuenta las restricciones de ancho de banda y realice su planeamiento en consecuencia.
  • Salida del centro de datos: para este escenario hay dos opciones. En ambas puede mantener el testigo del recurso compartido de archivos en un entorno local durante la migración, por si necesita realizar alguna reversión.
    • Implemente un nuevo testigo de recurso compartido de archivos en su 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: en el caso de un escenario de recuperación ante desastres, la mejor y más confiable opción es crear un testigo en la nube que se ejecute 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 la configuración y administración del cuórum, consulte la documentación de los clústeres de conmutación por error. Para más información sobre la implementación de testigos en la nube en Azure Blob Storage, consulte el documento sobre la implementación de un testigo en la nube para un clúster de conmutación por error para obtener los detalles.

Migración de un clúster de conmutación por error

Con fines ilustrativos, en este documento se usa un clúster de dos nodos con Windows Server 2019 Datacenter y SQL Server 2019 Enterprise. Windows Server 2022 y SQL Server 2022 también se admiten para este procedimiento.

  1. Desde el apagado de vSphere Client, el segundo nodo del clúster.

  2. Acceda al primer nodo del clúster y abra Administrador de clústeres de conmutación por error.

    • Compruebe que el segundo nodo está en estado Sin conexión y que todos los servicios y almacenamiento en clústeres están bajo el control del primer nodo. Diagrama que muestra la comprobación del almacenamiento en clústeres de Administrador de clústeres de conmutación por error de Windows Server.

    • Apague el clúster.

      Diagrama que muestra el apagado de un clúster desde el Administrador de clústeres de conmutación por error de Windows Server.

    • Compruebe que todos los servicios del clúster se detienen correctamente sin errores.

  3. Apague el primer nodo del clúster.

  4. En vSphere Client, edite la configuración del segundo nodo del clúster.

    • Quite todos los discos compartidos de la configuración de la máquina virtual.
    • Asegúrese de que la casilla Eliminar archivos del almacén de datos no está seleccionada, ya que si lo estuviera, el disco del almacén de datos se eliminaría de forma permanente, en cuyo caso, debería recuperar el clúster de una copia de seguridad anterior.
    • Cambie la opción de Uso compartido de bus SCSI de Físico a Ninguno en los controladores SCSI virtuales usados para el almacenamiento compartido. Normalmente, estos controladores son del tipo VMware Paravirtual.

  5. Edite la configuración de la máquina virtual del primer nodo. Cambie la opción de Uso compartido de bus SCSI de Físico a Ninguno en los controladores SCSI.

  6. En vSphere Client, vaya al área de complementos de HCX. En Servicios, seleccione Migración>Migrar.

    • Seleccione la segunda máquina virtual del nodo.
    • Establezca el clúster de vSphere en la nube privada remota, este hospeda la máquina virtual, máquinas virtuales, de SQL Server migradas como contenedor de proceso.
    • Seleccione el almacén de datos vSAN como almacenamiento remoto.
    • Si desea colocar las máquinas virtuales en una carpeta concreta, selecciónela. No es obligatorio, pero se recomienda separar las distintas cargas de trabajo en la nube privada de Azure VMware Solution.
    • Mantenga el mismo formato que el de origen.
    • Seleccione Migración en frío en Perfil de migración.
    • En Opcionesextendidas, 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 y tienen un estado correcto. El error más común tiene que ver con la configuración del almacenamiento. Vuelva a comprobar que no queden controladores SCSI virtuales con el valor de uso compartido físico.
    • Seleccione Ir para que se inicie la migración.

  7. Repita el mismo proceso para el primer nodo.

  8. Acceda a Azure VMware Solution vSphere Client, edite la configuración del primer nodo y vuelva a seleccionar la opción Físico en Uso compartido de bus SCSI del controlador o los controladores SCSI que administran los discos compartidos.

  9. Edite la configuración del nodo 2 en vSphere Client.

    • Vuelva a seleccionar la opción Físico en Uso compartido de bus SCSI del controlador SCSI que administra el almacenamiento compartido.
    • Agregue los discos compartidos del clúster al nodo como almacenamiento adicional. Asígnelos al segundo controlador SCSI.
    • Asegúrese de que toda la configuración del almacenamiento sea la misma que la registrada antes de la migración.

  10. Encienda la máquina virtual del primer nodo.

  11. Acceda a la máquina virtual del primer nodo con la consola remota de VMware.

    • Compruebe la configuración de red de la máquina virtual y asegúrese de que puede acceder a los recursos locales y de Azure.

    • Abra Administrador de clústeres de conmutación por error y compruebe los servicios del clúster.

      Diagrama que muestra un resumen del clúster en Administrador de clústeres de conmutación por error.

  12. Encienda la máquina virtual del segundo nodo.

  13. Acceda a la máquina virtual del segundo nodo desde la consola remota de VMware.

    • Compruebe que Windows Server puede acceder al almacenamiento.
    • En el Administrador de clústeres de conmutación por error, revise que el segundo nodo aparece con el estado En línea. Diagrama que muestra el estado de un nodo de clúster en Administrador de clústeres de conmutación por error.

  14. Utilice SQL Server Management Studio para conectarse al nombre de red del recurso del clúster de SQL Server. Confirme que todas las bases de datos están en línea y que se puede acceder a ellas.

Diagrama que muestra una comprobación de la conexión de SQL Server Management Studio a la base de datos de instancia del clúster migrada.

Compruebe la conectividad con SQL Server desde otros sistemas y aplicaciones de la infraestructura. Compruebe que todas las aplicaciones que usan la base de datos, o las bases de datos, pueden acceder a ellas.

Información adicional