Поделиться через

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

Область применения:SQL Server на виртуальной машине Azure

Совет

Существует множество методов для развертывания группы доступности. Упрощение развертывания и устранение необходимости использования Azure Load Balancer или распределенного сетевого имени (DNN) для группы доступности AlwaysOn путем создания виртуальных машин SQL Server в нескольких подсетях в одной виртуальной сети Azure. Если вы уже создали группу доступности в одной подсети, ее можно перенести в среду с несколькими подсетами.

В этой статье описывается, как использовать PowerShell или Azure CLI для развертывания отказоустойчивого кластера Windows Server (WSFC), добавить SQL Server на виртуальные машины Azure в WSFC и создать внутреннюю подсистему балансировки нагрузки и прослушиватель для группы доступности AlwaysOn в одной подсети.

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

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

Примечание.

Теперь можно перенести ваше решение на SQL Server на виртуальные машины Azure, используя службу Azure Migrate. См. раздел Перенос группы доступности для получения дополнительной информации.

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

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

  • Подписка Azure
  • Группа ресурсов с контроллером домена.
  • Одна или несколько присоединенных к домену виртуальных машин в Azure с установленной версией SQL Server 2016 (или более поздней) в редакции Enterprise, размещенных в той же группе доступности или в разных зонах доступности, которые зарегистрированы с расширением агента SQL IaaS.
  • Последняя версия PowerShell или Azure CLI.
  • Два доступных IP-адреса, не используемых никакой сущностью. Один IP-адрес — для внутренней подсистемы балансировки нагрузки. Другой IP-адрес предназначен для слушателя группы доступности (AG) в той же подсети, что и сама группа доступности. Если вы используете существующий балансировщик нагрузки, вам нужен только один доступный IP-адрес для слушателя AG.
  • Windows Server Core не является поддерживаемой операционной системой для команд PowerShell, на которые ссылается эта статья, так как существует зависимость от RSAT, которая не включена в основные установки Windows.

Разрешения

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

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

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

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

Используйте команду Azure CLI az storage account create, чтобы создать учетную запись хранения для свидетеля в облаке кластера.

# 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, чтобы устранить эту ошибку.

Проверка: Команда возвращает ProvisioningState: Succeeded , а учетная запись хранения отображается в группе ресурсов.

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

Группа виртуальных машин SQL управляет метаданными службы WSFC, в которую размещается группа доступности. Метаданные WSFC включают домен Active Directory, учетные записи кластера, учетные записи хранения, которые будут использоваться в качестве облачного свидетеля, и версии SQL Server. Определите метаданные для WSFC так, чтобы при добавлении первой виртуальной машины SQL Server WSFC создавался согласно заданным параметрам.

Используйте команду az sql vm group create Azure CLI, чтобы определить метаданные для WSFC.

Ключевые параметры:

Параметр Пример значения / По умолчанию
-n Имя кластера
-l eastus (регион)
-g Имя группы ресурсов
--image-offer SQL2017-WS2016 sql2019-ws2019 sql2022-ws2022 sql2025-ws2025
--image-sku Enterprise
--domain-fqdn domain.com
--operator-acc vmadmin@domain.com
--bootstrap-acc vmadmin@domain.com
--service-acc sqlservice@domain.com
--storage-account https://cloudwitness.blob.core.windows.net/
--cluster-subnet-type SingleSubnet

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

# Define the cluster metadata

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'

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

Добавление первой виртуальной машины SQL Server в WSFC (WSFC, созданный с помощью az sql vm group create) создает физический WSFC. Команда az sql vm add-to-group создает WSFC с указанным ранее именем, устанавливает роль WSFC на виртуальных машинах SQL Server и добавляет эти виртуальные машины в WSFC. Последующие использования команды az sql vm add-to-group добавляют дополнительные виртуальные машины SQL Server в только что созданное WSFC.

Используйте команду az sql vm add-to-group Azure CLI для добавления виртуальных машин SQL Server в кластер.

# Add SQL Server VMs to WSFC
# example: az sql vm add-to-group -n SQLVM1 -g SQLVM-RG --sqlvm-group Cluster `
#  -b <password> -p <password> -s <password>
# example: az sql vm add-to-group -n SQLVM2 -g SQLVM-RG --sqlvm-group Cluster `
#  -b <password> -p <password> -s <password>

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>

# Verify VM registration
az sql vm show -n <VM1 Name> -g <Resource Group Name>

Ожидаемые выходные данные: Команда возвращает "provisioningState": "Succeeded" и "sqlVirtualMachineGroupResourceId", заполненные идентификатором ресурса группы кластера.

Проверки: Команда возвращается ProvisioningState: Succeeded для каждой виртуальной машины, а WSFC создается при первом добавлении виртуальной машины.

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

Хотя диск-свидетель является наиболее устойчивым вариантом кворума, для него требуется общий диск Azure, что накладывает некоторые ограничения на группу доступности (AG). Таким образом, облако-свидетель — это рекомендуемое решение кворума для WSFCs, в котором размещаются группы доступности для SQL Server на виртуальных машинах Azure.

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

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

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

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

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

Проверки: Проверка кластера завершается без сбоев; Предупреждения допустимы, но просмотрите их на наличие потенциальных проблем.

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

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

Внимание

Не создавайте прослушиватель в настоящее время, так как регистрация прослушивателя выполняется в следующем разделе.

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

Примечание.

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

Прослушиватель группы доступности требует внутреннего экземпляра балансировщика нагрузки Azure. Внутренний балансировщик нагрузки предоставляет «плавающий» IP-адрес для прослушивателя AG, который позволяет ускорить быстрое восстановление после отказа и повторное подключение. Внутренняя подсистема балансировки нагрузки должна находиться в той же виртуальной сети, что и экземпляры виртуальных машин SQL Server.

Примечание.

Базовый балансировщик нагрузки выведен из эксплуатации. Для новых развертываний используйте подсистему балансировки нагрузки уровня "Стандартный". Если у вас есть существующее развертывание, использующее подсистему балансировки нагрузки "Базовый", обновите ее до стандартной подсистемы балансировки нагрузки.

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

Используйте команду az network lb create Azure CLI, чтобы создать внутреннюю подсистему балансировки нагрузки.

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

Проверка: Балансировщик нагрузки создается с ProvisioningState: Succeeded и отображается в группе ресурсов виртуальной сети.

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

После создания группы доступности вручную можно создать прослушиватель.

Идентификатор ресурса подсети — это значение /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.

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

Используйте команду Azure CLI az sql vm group ag-listener create, чтобы создать AG-полушиватель.

Ключевые параметры:

Параметр Пример значения / По умолчанию
--ag-name SQLAG
--group-name Имя кластера из метаданных
--ip-address 10.0.0.27 (IP-адрес прослушивателя AG, доступный IP-адрес в подсети)
--load-balancer Имя подсистемы балансировки нагрузки
--probe-port 59999 (по умолчанию)
--subnet Идентификатор ресурса подсети (см. ниже)
--sqlvms sqlvm1 sqlvm2 
# Create the AG 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>

Настройка порта пробы

При использовании Azure Load Balancer для поддержки ресурса виртуального сетевого имени (VNN) необходимо настроить кластер для ответа на запросы проб работоспособности. Если проверка состояния не сможет получить ответ от серверного экземпляра, то новые подключения не отправляются в этот серверный экземпляр до тех пор, пока проверка состояния не завершится успешно снова.

Чтобы задать параметр порта пробы в PowerShell, используйте следующий сценарий один раз на соответствующий ресурс IP-адреса:

$ClusterNetworkName = "<MyClusterNetworkName>" # The cluster network name. Use Get-ClusterNetwork on Windows Server 2012 or later to find the name.
$IPResourceName = "<IPResourceName>" # The IP address resource name.
[int]$ProbePort = <nnnnn> # The probe port that you configured in the health probe of the load balancer for a given Frontend IP Address. Any unused TCP port is valid.

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$IPResourceName";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

Внесенные изменения не вступают в силу до тех пор, пока ресурс IP-адреса не будет отключен и снова подключен к сети. Выполните переключение на резервный ресурс, чтобы это изменение вступило в силу.

После настройки пробы кластера используйте следующий скрипт PowerShell для проверки параметров кластера:

Get-ClusterResource $IPResourceName | Get-ClusterParameter

Исключение портов из динамического диапазона портов

При использовании порта пробы работоспособности от 49 152 до 65 535 ( динамический диапазон портов по умолчанию для TCP/IP) добавьте исключение для каждого порта пробы работоспособности на каждой виртуальной машине.

Настройка исключения портов не позволяет динамически назначать другим системным процессам тот же порт на виртуальной машине.

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

  • для каждого порта пробы работоспособности
  • на каждой виртуальной машине
[int]$ProbePort = <nnnnn> # The probe port that you configured in the health probe of the load balancer. Any unused TCP port is valid.

netsh int ipv4 add excludedportrange tcp startport=$ProbePort numberofports=1 store=persistent

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

netsh int ipv4 show excludedportrange tcp

Проверки: Исключение порта успешно добавлено.

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

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

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

  1. Добавьте виртуальную машину SQL Server в группу WSFC. Замените <password> допустимым паролем.

    
# Add the SQL Server VM to the WSFC group
# example: az sql vm add-to-group -n SQLVM3 -g SQLVM-RG --sqlvm-group Cluster `
# -b <password> -p <password> -s <password>

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. Используйте SSMS для добавления экземпляра SQL Server в качестве реплики в группу доступностей (AG).

  3. Добавьте метаданные виртуальной машины SQL Server в прослушиватель группы доступности (AG):

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

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

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

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

  1. Удалите реплику из AG с помощью SSMS.
  2. Удалите метаданные виртуальной машины SQL Server из слушателя AG. 
    # 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 из WSFC: 
    # Remove the SQL VM from the WSFC
# 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>

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

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

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

Используйте команду Azure CLI az sql vm group ag-listener delete, чтобы удалить прослушиватель группы доступности.

# Remove the AG 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>

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

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

Примечание.

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

Используйте команду az sql vm remove-from-group Azure CLI, чтобы удалить виртуальные машины SQL Server из WSFC.

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

# Remove the VM from the WSFC 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>

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

Следующие шаги

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

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

  • Last updated on