Compartir a través de

Uso de PowerShell o la CLI de Azure para configurar un grupo de disponibilidad de una sola subred para SQL Server en una máquina virtual de Azure

  • Artículo

Se aplica a: SQL Server en máquina virtual 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.

En este artículo se describe cómo usar PowerShell o la CLI de Azure para implementar un clúster de conmutación por error de Windows, agregarle máquinas virtuales con SQL Server, así como crear el equilibrador de carga interno y el cliente de escucha de un grupo de disponibilidad Always On con una única subred.

La implementación del grupo de disponibilidad se sigue realizando manualmente con SQL Server Management Studio (SSMS) o Transact-SQL (T-SQL).

Si bien en este artículo se usa PowerShell y la CLI de Azure para configurar el entorno del grupo de disponibilidad, también es posible hacerlo mediante Azure Portal, plantillas de inicio rápido de Azure o manualmente.

Nota:

Ahora es posible migrar mediante lift and shift la solución de grupo de disponibilidad a SQL Server en máquinas virtuales de Azure mediante Azure Migrate. Para más información, consulte Migración del grupo de disponibilidad.

Requisitos previos

Para configurar un grupo de disponibilidad Always On, debe cumplir los siguientes requisitos previos:

  • Una suscripción de Azure.
  • Un grupo de recursos con un controlador de dominio.
  • Una o varias máquinas virtuales en Azure, unidas a un dominio, con SQL Server 2016 (o superior) Enterprise Edition en el mismo conjunto de disponibilidad o en zonas de disponibilidad distintas que se hayan registrado con la extensión Agente de IaaS de SQL.
  • La versión más reciente de PowerShell o la CLI de Azure.
  • Dos direcciones IP disponibles (no utilizadas por ninguna entidad). Una es para el equilibrador de carga interno. La otra es para el cliente de escucha de grupo de disponibilidad dentro de la misma subred que el grupo de disponibilidad. Si se usa un equilibrador de carga existente, solo se necesita una dirección IP disponible para la escucha de grupo de disponibilidad.
  • Windows Server Core no es un sistema operativo compatible con los comandos de PowerShell a los que se hace referencia en este artículo, ya que existe una dependencia de RSAT, que no se incluye en las instalaciones principales de Windows.

Permisos

Los siguientes permisos de cuenta son necesarios para configurar el grupo de disponibilidad Always On mediante la CLI de Azure:

  • Una cuenta de usuario de dominio existente que tenga el permiso Crear objeto de equipo en el dominio. Por ejemplo, una cuenta de administrador de dominio normalmente tiene permisos suficientes (como account@domain.com). Esta cuenta también debe formar parte del grupo de administradores local en cada máquina virtual para crear el clúster.
  • La cuenta de usuario del dominio que controla SQL Server.

Crear una cuenta de almacenamiento

El clúster necesita una cuenta de almacenamiento para que actúe como el testigo en la nube. Puede usar una cuenta de almacenamiento existente o crear una desde cero. Si quiere utilizar una cuenta de almacenamiento existente, avance a la siguiente sección.

Con el siguiente fragmento de código se crea una cuenta de almacenamiento:

# Create the storage account
# example: az storage account create -n 'cloudwitness' -g SQLVM-RG -l 'West US' `
#  --sku Standard_LRS --kind StorageV2 --access-tier Hot --https-only true

az storage account create -n <name> -g <resource group name> -l <region> `
  --sku Standard_LRS --kind StorageV2 --access-tier Hot --https-only true

Sugerencia

Puede aparecer el error az sql: 'vm' is not in the 'az sql' command group si usa una versión obsoleta de la CLI de Azure. Descargue la versión más reciente de la CLI de Azure para solucionar este error.

Definición de metadatos de clúster

El grupo de comandos az sql vm group de la CLI de Azure administra los metadatos del servicio Clúster de conmutación por error de Windows Server (WSFC) que hospeda el grupo de disponibilidad. Los metadatos del clúster engloban el dominio de Active Directory, las cuentas de clúster, las cuentas de almacenamiento que se van a usar como testigo en la nube y la versión de SQL Server. Use az sql vm group create para definir los metadatos del WSFC de forma que, cuando se agregue la primera máquina virtual con SQL Server, el clúster se cree tal y como esté definido.

Con el siguiente fragmento de código se definen los metadatos del clúster:

# Define the cluster metadata
# example: az sql vm group create -n Cluster -l 'West US' -g SQLVM-RG `
#  --image-offer SQL2017-WS2016 --image-sku Enterprise --domain-fqdn domain.com `
#  --operator-acc vmadmin@domain.com --bootstrap-acc vmadmin@domain.com --service-acc sqlservice@domain.com `
#  --sa-key '4Z4/i1Dn8/bpbseyWX' `
#  --storage-account 'https://cloudwitness.blob.core.windows.net/'
#  --cluster-subnet-type 'SingleSubnet'

az sql vm group create -n <cluster name> -l <region ex:eastus> -g <resource group name> `
  --image-offer <SQL2016-WS2016 or SQL2017-WS2016> --image-sku Enterprise --domain-fqdn <FQDN ex: domain.com> `
  --operator-acc <domain account ex: testop@domain.com> --bootstrap-acc <domain account ex:bootacc@domain.com> `
  --service-acc <service account ex: testservice@domain.com> `
  --sa-key '<PublicKey>' `
  --storage-account '<ex:https://cloudwitness.blob.core.windows.net/>'
  --cluster-subnet-type 'SingleSubnet'

Adición de máquinas virtuales al clúster

Al agregar la primera máquina virtual de SQL Server al clúster, se crea el clúster. El comando az sql vm add-to-group crea el clúster con el nombre que se le haya dado, instala el rol de clúster en las máquinas virtuales de SQL Server y las agrega al clúster. Los usos posteriores del comando az sql vm add-to-group hacen que se agreguen más máquinas virtuales con SQL Server al clúster recién creado.

Con el siguiente fragmento de código se crea el clúster y se agrega a él la primera máquina virtual de SQL Server:

# Add SQL Server VMs to cluster
# example: az sql vm add-to-group -n SQLVM1 -g SQLVM-RG --sqlvm-group Cluster `
#  -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!
# example: az sql vm add-to-group -n SQLVM2 -g SQLVM-RG --sqlvm-group Cluster `
#  -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!

az sql vm add-to-group -n <VM1 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
  -b <bootstrap account password> -p <operator account password> -s <service account password>
az sql vm add-to-group -n <VM2 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
  -b <bootstrap account password> -p <operator account password> -s <service account password>

Use este comando para agregar cualquier otra máquina virtual con SQL Server al clúster. Modifique solo el parámetro -n para el nombre de la máquina virtual con SQL Server.

Configuración de un cuórum

Aunque el testigo de disco es la opción de cuórum más resistente, requiere un disco compartido de Azure que impone algunas limitaciones al grupo de disponibilidad. Por lo tanto, el testigo en la nube es la solución de cuórum recomendada para los clústeres que hospedan grupos de disponibilidad de SQL Server en VM de Azure.

Si tiene un número par de votos en el clúster, configure la solución de cuórum que mejor se adapte a sus necesidades empresariales. Para más información, consulte Cuórum con VM SQL Server.

Validar el clúster

Para que un clúster de conmutación por error sea compatible con Microsoft, debe pasar la validación del clúster. Conéctese a la máquina virtual mediante el método que prefiera, por ejemplo, Protocolo de escritorio remoto (RDP), y compruebe que el clúster pasa la validación antes de continuar. Si no lo hace, el clúster queda en un estado no admitido.

Puede validar el clúster mediante el Administrador de clústeres de conmutación por error (FCM) o el siguiente comando de PowerShell:

Test-Cluster –Node ("<node1>","<node2>") –Include "Inventory", "Network", "System Configuration"

Crear grupo de disponibilidad

Cree el grupo de disponibilidad manualmente del modo habitual, ya sea mediante SQL Server Management Studio, PowerShell o Transact-SQL.

Importante

No cree un cliente de escucha en este momento, ya que esto se realiza mediante la CLI de Azure en las secciones siguientes.

Creación del equilibrador de carga interno

Nota:

Las implementaciones del grupo de disponibilidad en varias subredes no requieren un equilibrador de carga. En un entorno de una sola subred, los clientes de SQL Server 2019 CU8 y versiones posteriores en Windows 2016 y versiones posteriores pueden reemplazar el cliente de escucha de nombre de red virtual (VNN) tradicional y Azure Load Balancer con un cliente de escucha de nombre de red distribuida (DNN). Si quiere usar un DNN, omita los pasos del tutorial que configuren Azure Load Balancer para el grupo de disponibilidad.

El cliente de escucha de grupo de disponibilidad Always On requiere una instancia interna de Azure Load Balancer. El equilibrador de carga interno proporciona una dirección IP "flotante" para la escucha de grupo de disponibilidad, que permite conmutar por error y volver a conectarse de manera más rápida. Si las máquinas virtuales con SQL Server de un grupo de disponibilidad forman parte del mismo conjunto de disponibilidad, puede usar un equilibrador de carga básico. De lo contrario, debe usar uno estándar.

Nota:

El equilibrador de carga interno debe estar en la misma red virtual que las instancias de máquina virtual con SQL Server.

Con el siguiente fragmento de código se crea la instancia del equilibrador de carga interno:

# Create the internal load balancer
# example: az network lb create --name sqlILB -g SQLVM-RG --sku Standard `
# --vnet-name SQLVMvNet --subnet default

az network lb create --name sqlILB -g <resource group name> --sku Standard `
  --vnet-name <VNet Name> --subnet <subnet name>

Importante

El recurso de IP pública de cada máquina virtual con SQL Server debe tener una SKU estándar para que sea compatible con el equilibrador de carga estándar. Para determinar la SKU del recurso de IP pública de la máquina virtual, vaya a Grupo de recursos, seleccione su recurso Dirección IP pública para la máquina virtual con SQL Server que desee y busque el valor que aparece debajo de SKU en el panel Información general.

Eliminar el agente de escucha

Después de haber creado el grupo de disponibilidad manualmente, puede crear el cliente de escucha mediante az sql vm ag-listener.

El identificador de recurso de subred es el valor de /subnets/<subnetname> anexado al identificador de recurso del recurso de red virtual. Para detectar el identificador de recurso de subred:

  1. Vaya al grupo de recursos en Azure Portal.
  2. Seleccione el recurso de red virtual.
  3. Seleccione Propiedades en el panel Configuración.
  4. Encuentre el identificador de recurso de la red virtual y anéxele /subnets/<subnetname> al final para crear el identificador de recurso de subred. Por ejemplo:
    • Su identificador de recurso de red virtual es /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet
    • Su nombre de subred es default
    • Por lo tanto, su identificador de recurso de subred es /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default

Con el siguiente fragmento de código se creará el cliente de escucha de grupo de disponibilidad:

# Create the availability group listener
# example: az sql vm group ag-listener create -n AGListener -g SQLVM-RG `
#  --ag-name SQLAG --group-name Cluster --ip-address 10.0.0.27 `
#  --load-balancer sqlilb --probe-port 59999  `
#  --subnet /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default `
#  --sqlvms sqlvm1 sqlvm2

az sql vm group ag-listener create -n <listener name> -g <resource group name> `
  --ag-name <availability group name> --group-name <cluster name> --ip-address <ag listener IP address> `
  --load-balancer <lbname> --probe-port <Load Balancer probe port, default 59999>  `
  --subnet <subnet resource id> `
  --sqlvms <names of SQL VM's hosting AG replicas, ex: sqlvm1 sqlvm2>

Modificación del número de réplicas

Hay una capa de complejidad agregada al implementar un grupo de disponibilidad en máquinas virtuales con SQL Server hospedadas en Azure. El proveedor de recursos y el grupo de máquinas virtuales ahora administran los recursos. En este sentido, al agregar o quitar réplicas en el grupo de disponibilidad, hay un paso más que consiste en actualizar los metadatos del cliente de escucha con información relativa a las máquinas virtuales con SQL Server. Cuando se modifica el número de réplicas del grupo de disponibilidad, hay que usar también el comando az sql vm group ag-listener update para actualizar el cliente de escucha con los metadatos de las máquinas virtuales con SQL Server.

Adición de una réplica

Para agregar una réplica nueva al grupo de disponibilidad:

CLI de Azure

  1. Agregue la máquina virtual de SQL Server al grupo de clústeres:

    
# Add the SQL Server VM to the cluster group
# example: az sql vm add-to-group -n SQLVM3 -g SQLVM-RG --sqlvm-group Cluster `
# -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!

az sql vm add-to-group -n <VM3 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
-b <bootstrap account password> -p <operator account password> -s <service account password>

  2. Use SQL Server Management Studio para agregar la instancia de SQL Server como una réplica dentro del grupo de disponibilidad.

  3. Agregue a la escucha los metadatos de la máquina virtual de SQL Server:

    # Update the listener metadata with the new VM
# example: az sql vm group ag-listener update -n AGListener `
# -g sqlvm-rg --group-name Cluster --sqlvms sqlvm1 sqlvm2 sqlvm3

az sql vm group ag-listener update -n <Listener> `
-g <RG name> --group-name <cluster name> --sqlvms <SQL VMs, along with new SQL VM>

Eliminación de una réplica

Para quitar una réplica del grupo de disponibilidad:

CLI de Azure

  1. Quite la réplica del grupo de disponibilidad mediante SQL Server Management Studio.
  2. Quite los metadatos de máquina virtual de SQL Server de la escucha: 
    # Update the listener metadata by removing the VM from the SQLVMs list
# example: az sql vm group ag-listener update -n AGListener `
# -g sqlvm-rg --group-name Cluster --sqlvms sqlvm1 sqlvm2

az sql vm group ag-listener update -n <Listener> `
-g <RG name> --group-name <cluster name> --sqlvms <SQL VMs that remain>
  3. Quite la máquina virtual de SQL Server del clúster: 
    # Remove the SQL VM from the cluster
# example: az sql vm remove-from-group --name SQLVM3 --resource-group SQLVM-RG

az sql vm remove-from-group --name <SQL VM name> --resource-group <RG name>

Quitar el agente de escucha

Si posteriormente necesita quitar el cliente de escucha de grupo de disponibilidad configurado con la CLI de Azure, deberá pasar por la extensión Agente de IaaS de SQL. Puesto que el cliente de escucha se registra mediante la extensión Agente de IaaS de SQL, no basta con eliminarlo mediante SQL Server Management Studio.

El mejor método consiste en eliminarlo a través de la extensión Agente de IaaS de SQL mediante el siguiente fragmento de código en la CLI de Azure. Al hacerlo, se quitan los metadatos del cliente de escucha de grupo de disponibilidad de la extensión Agente de IaaS de SQL. También elimina físicamente el cliente de escucha de grupo de disponibilidad.

# Remove the availability group listener
# example: az sql vm group ag-listener delete --group-name Cluster --name AGListener --resource-group SQLVM-RG

az sql vm group ag-listener delete --group-name <cluster name> --name <listener name > --resource-group <resource group name>

Eliminación del clúster

Quite todos los nodos del clúster para destruirlo y luego quite los metadatos del clúster de la extensión Agente de IaaS de SQL. Para ello, puede usar la CLI de Azure o PowerShell.

En primer lugar, quite todas las VM con SQL Server del clúster:

# Remove the VM from the cluster metadata
# example: az sql vm remove-from-group --name SQLVM2 --resource-group SQLVM-RG

az sql vm remove-from-group --name <VM1 name>  --resource-group <resource group name>
az sql vm remove-from-group --name <VM2 name>  --resource-group <resource group name>

Si estas son las únicas máquinas virtuales del clúster, este se destruirá. Si hay otras máquinas virtuales en el clúster aparte de las VM con SQL Server que se han quitado, las otras no se quitan y el clúster no se destruirá.

Luego, quite los metadatos del clúster de la extensión Agente de IaaS de SQL:

# Remove the cluster from the SQL VM RP metadata
# example: az sql vm group delete --name Cluster --resource-group SQLVM-RG

az sql vm group delete --name <cluster name> Cluster --resource-group <resource group name>

Pasos siguientes

Una vez que se haya implementado el grupo de disponibilidad, puede optimizar la configuración de alta disponibilidad y recuperación ante desastres para SQL Server en máquinas virtuales de Azure.

Para obtener más información, consulte: