Compartir vía

Migración de un grupo de disponibilidad de SQL Server a varias subredes: SQL Server en máquinas virtuales de Azure

  • Artículo

Se aplica a:SQL Server en VM de Azure

En este artículo se explica cómo migrar el grupo de disponibilidad (AG) Always On de una sola subred a varias subredes para simplificar la conexión al agente de escucha en Azure con SQL Server en máquinas virtuales (VM) de Azure.

Sugerencia

Hay muchos métodos para implementar un grupo de disponibilidad. Simplifique la implementación y elimine la necesidad de un nombre de red distribuida (DNN) o un equilibrador de carga de Azure para el grupo de disponibilidad Always On mediante la creación de las máquinas virtuales (VM) de SQL Server en varias subredes dentro de la misma red virtual de Azure. Si ya ha creado el grupo de disponibilidad en una sola subred, puede migrarlo a un entorno de varias subredes.

Información general

Los clientes que ejecutan SQL Server en máquinas virtuales de Azure pueden implementar un grupo de disponibilidad (AG) de Always On en una sola subred o en varias subredes. Una configuración de varias subredes simplifica el entorno del grupo de disponibilidad quitando la necesidad de un equilibrador de carga de Azure o un nombre de red distribuida (DNN) para enrutar el tráfico al agente de escucha en la red de Azure. Aunque se recomienda usar un enfoque de varias subredes, requiere que las cadenas de conexión de una aplicación usen MultiSubnetFailover = true, lo que podría no ser posible inmediatamente debido a cambios en el nivel de aplicación.

Si originalmente creó un grupo de disponibilidad en una sola subred y usa un equilibrador de carga de Azure o DNN para el agente de escucha y ahora quiere reducir la complejidad pasando a una configuración de varias subredes, puede hacerlo con algunos pasos manuales.

Antes de iniciar una migración de un entorno existente, evalúe los riesgos de cambiar un entorno en uso.

Considere las dos maneras de migrar el grupo de disponibilidad a varias subredes:

  • Creación de un nuevo entorno para realizar pruebas en paralelo
  • Mover manualmente un grupo de disponibilidad existente

Precaución

Realizar una migración implica riesgos, por lo que siempre se prueba exhaustivamente en un entorno que no sea de producción antes de pasar a un entorno de producción.

Nuevo entorno con pruebas en paralelo

El primer método para pasar a un grupo de disponibilidad de varias subredes es configurar un nuevo entorno. Si se trata de la ruta elegida, deberá hacer lo siguiente:

  1. Crear nuevas máquinas virtuales
  2. Crear un nuevo grupo de disponibilidad en una configuración de varias subredes
  3. Hacer una copia de seguridad de la base de datos actual y restaurar el nuevo entorno

Inicialmente, en el nuevo entorno de varias subredes, cree el agente de escucha con un nombre diferente al del entorno de subred única existente. Un agente de escucha recién denominado en un nuevo grupo de disponibilidad permite realizar pruebas en paralelo de la aplicación (pruebas con la subred múltiple y el equilibrador de carga actual o DNN en su lugar).

Una vez que se valida exhaustivamente el entorno de varias subredes, puede pasar a la nueva infraestructura. En función del entorno (producción, prueba), use una ventana de mantenimiento para completar el cambio. Durante la ventana de mantenimiento, restaure la base de datos en la nueva réplica principal, elimine el agente de escucha del grupo de disponibilidad en ambos entornos y vuelva a crear el agente de escucha en el entorno de varias subredes con el mismo nombre que el agente de escucha anterior, el que se usó en la cadena de conexión de la aplicación.

La configuración de un nuevo entorno en una configuración de varias subredes ahora es más fácil con la experiencia de implementación de Azure Portal.

Mover manualmente un grupo de disponibilidad existente

La otra opción consiste en pasar manualmente del entorno de subred única a un entorno de varias subredes. Para realizar la migración mediante este método, debe cumplir los siguientes requisitos previos:

  • Una dirección IP para cada máquina de una nueva subred
  • Cadenas de conexión que ya usan MultiSubnetFailover = true

Para migrar el grupo de disponibilidad a una configuración de varias subredes, siga estos pasos:

  1. Cree una subred para cada máquina virtual secundaria, ya que todas las máquinas virtuales están actualmente en la misma subred.

  2. Determine la dirección IP del clúster y la dirección IP del agente de escucha para todos los servidores del grupo de disponibilidad. Por ejemplo, si tiene un grupo de disponibilidad con dos nodos, tiene lo siguiente:

    Nombre de la máquina virtual Subnet IP del clúster IP de agente de escucha:
    VM1 (principal) 10.1.1.0/24 (subred existente) 10.1.1.15 10.1.1.16
    VM2 (secundaria) 10.1.2.0/24 (nueva subred) 10.1.2.15 10.1.2.16

  3. Agregue la dirección IP del clúster y la dirección IP del agente de escucha al servidor de réplica principal. Agregar estas direcciones IP es una operación en línea.

  4. En Azure Portal, mueva el servidor secundario a la nueva subred; para ello, vaya a la máquina virtual >Redes > Interfaz de red >Configuraciones IP. Al mover el servidor a una nueva subred, se reinicia el servidor de réplica secundario.

  5. Agregue la dirección IP del clúster y la dirección IP del agente de escucha al servidor de réplica secundario. Agregar estas direcciones IP es una operación en línea.

  6. En este momento, dado que las direcciones IP y las subredes están en su lugar, puede eliminar el equilibrador de carga.

  7. Anule el agente de escucha.

  8. Si usa Windows Server 2019 y versiones posteriores, omita este paso. Si usa Windows Server 2016, agregue manualmente las direcciones IP del clúster a la FCI.

  9. Vuelva a crear el agente de escucha con las nuevas direcciones IP del agente de escucha.

  10. Vacíe DNS en todos los servidores mediante ipconfig /flushdns.

Pasos siguientes