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

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

  • Статья

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

Совет

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

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

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

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

Примечание.

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

Необходимые компоненты

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

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

Разрешения

Для настройки группы доступности 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/'
#  --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'

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

При добавлении первой виртуальной машины 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 2016 и более поздних версий, могут заменить прослушиватель традиционных виртуальных сетей (VNN) и Azure Load Balancer на прослушиватель распределенной сети (DNN). Если вы хотите использовать DNN, пропустите все инструкции по настройке 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.

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

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

Azure CLI

  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>

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

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

Azure CLI

  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 для SQL удаляются метаданные прослушивателя группы доступности, а из группы доступности физически удаляется прослушиватель.

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

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