Используйте PowerShell или Azure CLI для настройки группы доступности для SQL Server на виртуальной машине Azure с помощью Azure CLI

ОБЛАСТЬ ПРИМЕНЕНИЯ: SQL Server на виртуальной машине Azure

Совет

устраните необходимость в Azure Load Balancer для группы доступности Always On, создав виртуальные машины SQL Server в нескольких подсетях в одной виртуальной сети Azure.

в этой статье описывается, как использовать PowerShell или Azure CLI для развертывания Windows отказоустойчивого кластера, добавления виртуальных машин SQL Server в кластер и создания внутренней подсистемы балансировки нагрузки и прослушивателя для группы доступности Always On в одной подсети.

Развертывание группы доступности по-прежнему выполняется вручную с помощью SQL Server Management Studio (SSMS) или Transact-SQL (T-SQL).

Хотя в этой статье используются PowerShell и Azure CLI для настройки среды групп доступности, ее также можно выполнить из портала Azure с помощью шаблонов быстрого запуска Azure или вручную.

Примечание

Теперь можно выполнить перенос решения группы доступности по методу lift-and-shift на SQL Server на виртуальных машинах Azure с помощью Azure Migrate. Дополнительные сведения см. в разделе Перенос группы доступности.

Предварительные требования

Чтобы настроить группы доступности AlwaysOn, должны выполняться предварительные требования:

Разрешения

Для настройки группы доступности Always On с помощью Azure CLI необходимы разрешения следующих учетных записей:

  • Существующая учетная запись пользователя домена с разрешением на создание объекта компьютера в домене. Как правило, учетная запись администратора домена обычно имеет соответствующие разрешения (например, account@domain.com). Эта учетная запись также должна входить в группу локальных администраторов на каждой виртуальной машине для создания кластера.
  • Учетная запись пользователя домена, которая используется для управления SQL Server.

Создание учетной записи хранения

Для кластера требуется учетная запись хранения, которая будет использоваться в качестве облака-свидетеля. Вы можете использовать существующую учетную запись хранения или создать ее. Если вы хотите использовать существующую учетную запись хранения, перейдите к следующему разделу.

Следующий фрагмент кода создает учетную запись хранения:

# 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

Совет

Если вы используете устаревшую версию Azure CLI, может появиться сообщение об ошибке az sql: 'vm' is not in the 'az sql' command group. Скачайте последнюю версию Azure CLI, чтобы устранить эту ошибку.

Определение метаданных кластера

Группа команд az sql vm group Azure CLI управляет метаданными службы отказоустойчивого кластера Windows Server (WSFC), в которой размещается группа доступности. К метаданным кластера относятся домен Active Directory, учетные записи кластера, учетные записи хранения, которые используются в роли облака-свидетеля, и версия SQL Server. Используйте az sql vm group create для определения метаданных для WSFC, чтобы при добавлении первой виртуальной машины SQL Server был создан кластер в соответствии с определением.

Следующий фрагмент кода определяет метаданные для кластера:

# 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/'

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/>'

Добавление виртуальных машин в кластер

При добавлении первой виртуальной машины SQL Server в кластер создается кластер. Вы можете создать кластер с указанным ранее именем, установить для него роль на виртуальных машинах SQL Server, а также добавить их в кластер с помощью команды az sql vm add-to-group. Выполните команду az sql vm add-to-group еще раз, чтобы добавить в созданный кластер дополнительные виртуальные машины SQL Server.

Следующий фрагмент кода создает кластер и добавляет в него первую виртуальную машину 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>

Используйте эту команду, чтобы добавить в кластер любые другие виртуальные машины SQL Server. Для имени виртуальной машины SQL Server измените только параметр -n.

Настройка кворума

Хотя диск-свидетель является самым устойчивым вариантом кворума, для него требуется общий диск Azure, который накладывает некоторые ограничения на группу доступности. Поэтому рекомендуемым решением кворума для кластеров с группами доступности для SQL Server на виртуальных машинах Azure является облачный свидетель.

Если в кластере четное число голосов, настройте решение кворума, которое лучше всего подходит для бизнес-задач. Дополнительные сведения см. в разделе Кворум с виртуальными машинами SQL Server.

Проверка кластера

Майкрософт поддерживает только отказоустойчивые кластеры, конфигурация которых прошла проверку. Подключитесь к виртуальной машине предпочтительным методом, например с помощью протокола удаленного рабочего стола (RDP), и убедитесь, что кластер прошел проверку, прежде чем продолжить. Несоблюдение этого действия оставляет кластер в неподдерживаемом состоянии.

Вы можете проверить кластер с помощью диспетчера отказоустойчивости кластеров (FCM) или следующей команды PowerShell:

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

Создание группы доступности

Создайте группу доступности вручную, как обычно, с помощью SQL Server Management Studio, PowerShell или Transact-SQL.

Важно!

Не создавайте прослушиватель на этом шаге. Это действие будет выполнено с помощью Azure CLI в следующих разделах.

Создание внутренней подсистемы балансировки нагрузки

Примечание

Клиенты, использующие SQL Server 2019 версии CU8 и выше в Windows Server 2016 и более поздних версий, могут использовать прослушиватель имени распределенной сети (DNN) вместо стандартного прослушивателя VNN и Azure Load Balancer. Пропустите остальные инструкции, приведенные в этой статье, по созданию прослушивателя и подсистемы балансировки нагрузки.

Прослушивателю группы доступности Always On требуется внутренний экземпляр Azure Load Balancer. Внутренняя подсистема балансировки нагрузки предоставляет "плавающий" IP-адрес прослушивателю группы доступности, что обеспечивает более быструю отработку отказа и восстановление подключения. Если виртуальные машины SQL Server в группе доступности входят в одну группу доступности, вы можете использовать подсистему балансировки нагрузки ценовой категории "Базовый". В противном случае используйте подсистему балансировки нагрузки ценовой категории "Стандартный".

Примечание

Внутренняя подсистема балансировки нагрузки должна находиться в той же виртуальной сети, что и экземпляры виртуальных машин SQL Server.

Следующий фрагмент кода создает внутреннюю подсистему балансировки нагрузки:

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

Важно!

Ресурс общедоступного IP-адреса для каждой виртуальной машины SQL Server должен иметь номер SKU "Стандартный", чтобы обеспечить совместимость с подсистемой балансировки нагрузки ценовой категории "Стандартный". Чтобы определить номер SKU для ресурса общедоступного IP-адреса виртуальной машины, найдите группу ресурсов и выберите ресурс Общедоступный IP-адрес для требуемой виртуальной машины SQL Server, а затем найдите для него значение параметра Номер SKU на панели Обзор.

Создание прослушивателя

После создания группы доступности вручную можно создать прослушиватель с помощью команды az sql vm ag-listener.

Идентификатор ресурса подсети — это значение /subnets/<subnetname>, которое добавляется к идентификатору ресурса виртуальной сети. Чтобы определить идентификатор ресурса подсети, выполните следующие действия:

  1. Перейдите к группе ресурсов на портале Azure.
  2. Выберите ресурс виртуальной сети.
  3. Выберите Свойства в области Параметры.
  4. Определите идентификатор ресурса для виртуальной сети и добавьте /subnets/<subnetname> к нему в конце, чтобы создать идентификатор ресурса подсети. Пример:
    • Ваш идентификатор ресурса виртуальной сети — /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet.
    • Ваше имя подсети — default.
    • Таким образом, ваш идентификатор ресурса подсети — /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default.

Следующий фрагмент кода создает прослушиватель группы доступности:

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

Изменение числа реплик

Существует дополнительный уровень сложности при развертывании группы доступности в виртуальных машинах SQL Server, размещенных в Azure. Поставщик ресурсов и группа виртуальных машин теперь управляют ресурсами. Таким образом, при добавлении или удалении реплик в группе доступности выполняется дополнительная задача добавления сведений о виртуальных машинах SQL Server в метаданные прослушивателя. При изменении числа реплик в группе доступности необходимо также использовать команду az sql vm group ag-listener update, чтобы добавить в прослушиватель метаданные виртуальных машин SQL Server.

Добавление реплики

Чтобы добавить новую реплику в группу доступности, выполните следующие действия:

  1. Добавьте виртуальную машину SQL Server в группу кластера, выполнив следующую команду:

    
    # 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. Используйте SQL Server Management Studio, чтобы добавить экземпляр SQL Server в качестве реплики в группу доступности.

  3. Добавьте метаданные виртуальной машины 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>
    

Удаление реплики

Чтобы удалить реплику из группы доступности, выполните следующие действия:

  1. Удалите реплику из группы доступности с помощью SQL Server Management Studio.
  2. Удалите метаданные виртуальной машины SQL Server из прослушивателя, выполнив следующую команду:
    # 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. Удалите виртуальную машину SQL Server из кластера, выполнив следующую команду:
    # 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> 
    

Удаление прослушивателя

Если вам потребуется удалить прослушиватель группы доступности, настроенный с помощью Azure CLI, это нужно делать через расширение агента IaaS. Так как прослушиватель зарегистрирован в расширении агента IaaS, недостаточно просто удалить его с помощью SQL Server Management Studio.

Лучший способ — удалить его с помощью расширения агента IaaS, используя приведенный ниже фрагмент кода в Azure CLI. Так из расширения агента IaaS удаляются метаданные прослушивателя группы доступности, а из группы доступности физически удаляется прослушиватель.

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

Удаление кластера

Удалите все узлы из кластера, чтобы уничтожить его, а затем удалите метаданные кластера из расширения агента IaaS SQL. Это можно сделать с помощью Azure CLI или PowerShell.

Сначала удалите все виртуальные машины SQL Server из кластера:

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

Если это единственные виртуальные машины в кластере, кластер будет уничтожен. Если в кластере есть виртуальные машины, отличающиеся от удаленных виртуальных машин SQL Server, другие виртуальные машины не удаляются и кластер не будет уничтожен.

Затем удалите метаданные кластера из расширения агента IaaS 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>

Дальнейшие действия

После развертывания группы доступности рассмотрите возможность оптимизации параметров HADR для SQL Server на виртуальных машинах Azure.

Дополнительные сведения см. на следующих ресурсах: