Настройка прослушивателя внутреннего балансировщика нагрузки для виртуальных машин SQL Server в Azure

  • Статья

Обзор

Важно!

В Azure предлагаются две модели развертывания для создания ресурсов и работы с ними: развертывание с помощью Azure Resource Manager и классическая модель развертывания. В этой статье рассматривается использование классической модели развертывания. Для большинства новых развертываний рекомендуется использовать модель Resource Manager.

Дополнительные сведения о настройке прослушивателя для группы доступности AlwaysOn в модели Resource Manager см. в этой статье.

В группе доступности могут быть реплики, доступные только локально или только в Azure. В гибридных конфигурациях возможны оба способа доступа одновременно. Реплики в Azure могут находиться в одном или нескольких регионах, использующих несколько виртуальных сетей. В процедурах, приведенных в этой статье, предполагается, что вы уже настроили группу доступности, но еще не настроили прослушиватель.

Рекомендации и ограничения для внутренних прослушивателей

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

  • Прослушиватель группы доступности поддерживается в Windows Server 2008 R2, Windows Server 2012 и Windows Server 2012 R2.
  • Для каждой облачной службы поддерживается только один внутренний прослушиватель группы доступности, так как он настраивается только на использование ILB, а в облачной службе только один ILB. Однако можно создать несколько внешних прослушивателей. Дополнительные сведения см. в статье Настройка внешнего прослушивателя для групп доступности AlwaysOn в Azure.

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

Важно понимать, что есть два способа настройки прослушивателя группы доступности в Azure. Они отличаются типом подсистемы балансировки нагрузки Azure, используемой при создании прослушивателя. Различия описаны в следующей таблице:

Тип подсистемы балансировки нагрузки Реализация Используется, когда:
Внешний Использование общедоступного виртуального IP-адреса облачной службы, на которой размещены виртуальные машины. Необходимо, чтобы прослушиватель был доступен за пределами виртуальной сети, в том числе через Интернет.
Внутренний Использование внутренней подсистемы балансировки нагрузки с частным адресом для прослушивателя. Необходимо, чтобы прослушиватель был доступен только в этой виртуальной сети. Сюда относится VPN типа "сеть — сеть" в гибридных сценариях.

Важно!

Если прослушиватель использует общедоступный VIP-адрес облачной службы (внешний балансировщик нагрузки), то при условии, что клиент, прослушиватель и база данных находятся в одном регионе Azure, вам не будет начисляться плата за исходящий трафик. В противном случае все данные, возвращаемые через прослушиватель, считаются исходящим трафиком и оплачиваются по обычным тарифам на передачу данных.

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

В этой статье рассматривается создание прослушивателя, использующего внутренний балансировщик нагрузки. Если вам требуется общедоступный (внешний) прослушиватель, см. другую версию этой статьи, где приведены инструкции по настройке внешнего прослушивателя.

Создание конечных точек балансировки нагрузки в ВМ со службой Direct Server Return

Сначала создайте внутренний балансировщик нагрузки, запустив скрипт (следуя указаниям далее в этом разделе).

Создайте конечную точку с балансировкой нагрузки для каждой виртуальной машины с репликой Azure. Все реплики одного региона должны быть в одной облачной службе и одной виртуальной сети Azure. Чтобы создать реплики группы доступности, охватывающие несколько регионов Azure, необходимо настроить несколько виртуальных сетей. Дополнительные сведения о настройке подключения между виртуальными сетями см. в этой статье.

  1. Для просмотра сведений на портале Azure перейдите к каждой виртуальной машине, на которой размещена реплика.

  2. Перейдите на вкладку Конечные точки для каждой виртуальной машины.

  3. Убедитесь, что имя и общий порт необходимой конечной точки прослушивателя еще не используются. В примере, рассматриваемом в этом разделе, используется имя MyEndpoint и порт 1433.

  4. На локальном клиенте скачайте и установите последнюю версию модуля PowerShell.

  5. Запустите Azure PowerShell.
    Откроется новый сеанс PowerShell с загруженными административными модулями Azure.

  6. Выполните Get-AzurePublishSettingsFile. Он перенаправит вас в браузер для скачивания файла параметров публикации в локальный каталог. Может потребоваться ввод учетных данных для входа в подписку Azure.

  7. Выполните следующую команду Import-AzurePublishSettingsFile, указав путь к скачанному файлу параметров публикации:

    Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>

    После импорта файла параметров публикации вы сможете управлять подпиской Azure в сеансе PowerShell.

  8. Для балансировщика нагрузки вам потребуется назначить статический IP-адрес. Изучите текущую конфигурацию виртуальной сети, выполнив следующую команду:

    (Get-AzureVNetConfig).XMLConfiguration

  9. Обратите внимание на имя Subnet для подсети, содержащей виртуальные машины с репликами. Это имя присваивается параметру $SubnetName в скрипте.

  10. Обратите внимание на имя VirtualNetworkSite и начальный префикс подсети AddressPrefix, содержащей виртуальные машины с репликами. Определите доступные IP-адреса. Для этого передайте оба значения в команду Test-AzureStaticVNetIP и изучите значение AvailableAddresses. Например, если виртуальная сеть называется MyVNet, а диапазон адресов подсети начинается с 172.16.0.128, следующая команда выведет список доступных адресов:

    (Test-AzureStaticVNetIP -VNetName "MyVNet"-IPAddress 172.16.0.128).AvailableAddresses

  11. Выберите один из доступных адресов и используйте его в качестве значения параметра $ILBStaticIP в приведенном ниже скрипте.

  12. Скопируйте приведенный ниже скрипт PowerShell в текстовый редактор и задайте подходящие для среды значения переменных. Для некоторых параметров указаны значения по умолчанию.

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

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

    # Define variables
$ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
$AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
$SubnetName = "<MySubnetName>" # subnet name that the replicas use in the virtual network
$ILBStaticIP = "<MyILBStaticIPAddress>" # static IP address for the ILB in the subnet
$ILBName = "AGListenerLB" # customize the ILB name or use this default value

# Create the ILB
Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP

# Configure a load-balanced endpoint for each node in $AGNodes by using ILB
ForEach ($node in $AGNodes)
{
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name "ListenerEndpoint" -LBSetName "ListenerEndpointLB" -Protocol tcp -LocalPort 1433 -PublicPort 1433 -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM
}

  13. Присвоив значения переменным, скопируйте скрипт из текстового редактора в текущий сеанс PowerShell и выполните его. Если в командной строке отображается >> , нажмите клавишу ВВОД еще раз, чтобы начать выполнение скрипта.

Проверка наличия пакета KB2854082

Далее, если серверы в кластере работают под управлением Windows Server 2008 R2 или Windows Server 2012, необходимо убедиться, что исправление KB2854082 установлено на всех локальных серверах или виртуальных машинах Azure, которые являются частью кластера. Это исправление необходимо установить на все сервера или виртуальные машины в кластере, даже если их нет в группе доступности.

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

Предупреждение

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

  • Кластер имеет оптимальную работоспособность кворума.
  • Перед установкой исправления на любом узле все узлы кластера подключены к сети.
  • Дождитесь завершения установки исправления на одном узле, в том числе полного перезапуска сервера, перед установкой исправления на другом узле в кластере.

Открытие портов брандмауэра в узлах групп доступности.

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

  1. На виртуальных машинах, на которых размещены реплики, запустите брандмауэр Windows в режиме повышенной безопасности.

  2. Щелкните правой кнопкой мыши элемент Правила для входящих подключений и выберите команду Новое правило.

  3. На странице Тип правила выберите Порт и нажмите кнопку Далее.

  4. На странице Протокол и порты выберите TCP и введите 59999 в поле Specific local ports (Определенные локальные порты), а затем щелкните Далее.

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

  6. На странице Профиль примите параметры по умолчанию и нажмите кнопку Далее.

  7. На странице Имя в текстовом поле Имя укажите имя правила, например Порт пробы прослушивателя AlwaysOn, и щелкните Готово.

  8. Повторите предыдущие действия для порта прослушивателя группы доступности (как указано выше в параметре сценария $EndpointPort), а затем укажите соответствующее имя правила, например Порт прослушивателя AlwaysOn.

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

Создайте прослушиватель группы доступности в два этапа. Сначала создайте ресурс кластера точки доступа клиента и настройте зависимости. Затем настройте кластерные ресурсы в PowerShell.

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

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

  1. Откройте диспетчер отказоустойчивого кластера из узла, на котором размещена первичная реплика.

  2. Выберите узел Сети и запишите имя сети кластера. Это имя будет использоваться в переменной $ClusterNetworkName в скрипте PowerShell.

  3. Разверните имя кластера и щелкните пункт Роли.

  4. На панели Роли щелкните правой кнопкой мыши имя группы доступности и выберите Добавить ресурс>Точка доступа клиента.

    Добавление точки доступа клиента для группы доступности

  5. В поле Имя создайте имя для этого нового прослушивателя, а затем дважды щелкните Далее и нажмите кнопку Готово.
    Не подключайте прослушивателя или ресурс на этом этапе.

  6. Перейдите на вкладку Ресурсы и разверните созданную точку доступа клиента. Отобразится ресурс IP-адреса для каждой сети в кластере. Если это решение только для Azure, вы увидите только один ресурс IP-адреса.

  7. Выполните одно из приведенных ниже действий.

    • Для настройки гибридного решения:

      а. Щелкните правой кнопкой мыши ресурс IP-адреса, соответствующий локальной подсети, и выберите Свойства. Запишите имя IP-адреса и имя сети.

      b. Выберите Статический IP-адрес, присвойте неиспользуемый IP-адрес и нажмите кнопку ОК.

    • Для настройки решения только для Azure:

      а. Щелкните правой кнопкой мыши ресурс IP-адреса, соответствующий подсети Azure, и выберите пункт "Свойства".

      Примечание

      Если позднее прослушиватель не будет подключаться из-за конфликтующего IP-адреса, выбранного протоколом DHCP, вы сможете настроить допустимый статический IP-адрес в этом окне свойств.

      b. В том же окне свойств IP-адрес измените имя IP-адреса.
      Это имя будет использоваться в переменной $IPResourceName скрипта PowerShell. Повторите этот шаг для каждого IP-ресурса, если решение распространяется на несколько виртуальных сетей Azure.

Настройка кластерных ресурсов в PowerShell

  1. Чтобы использовать внутренний балансировщик нагрузки, вам потребуется указать IP-адрес ранее созданного внутреннего балансировщика нагрузки. Этот IP-адрес можно получить в PowerShell, выполнив следующий скрипт:

    # Define variables
$ServiceName="<MyServiceName>" # the name of the cloud service that contains the AG nodes
(Get-AzureInternalLoadBalancer -ServiceName $ServiceName).IPAddress

  2. Войдите на одну из виртуальных машин и скопируйте скрипт PowerShell для операционной системы в текстовый редактор. Затем присвойте переменным записанные ранее значения.

    Для Windows Server 2012 или более поздней версии используйте следующий скрипт:

    # Define variables
$ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP address resource name
$ILBIP = "<X.X.X.X>" # the IP address of the ILB

Import-Module FailoverClusters

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

    Для Windows Server 2008 R2 используйте следующий скрипт:

    # Define variables
$ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP address resource name
$ILBIP = "<X.X.X.X>" # the IP address of the ILB

Import-Module FailoverClusters

cluster res $IPResourceName /priv enabledhcp=0 address=$ILBIP probeport=59999  subnetmask=255.255.255.255

  3. Присвоив значения переменным, откройте окно Windows PowerShell с повышенными правами. Вставьте скрипт из текстового редактора в текущий сеанс PowerShell и выполните скрипт. Если в командной строке отображается >> , нажмите клавишу ВВОД еще раз, чтобы начать выполнение скрипта.

  4. Повторите предыдущие действия для каждой виртуальной машины.
    Этот скрипт настраивает ресурс IP-адреса путем установки IP-адреса облачной службы и прочих параметров, таких как порт зонда. После подключения ресурс IP-адреса сможет отвечать на запросы, отправляемые на порт зонда из созданной ранее конечной точки балансировки нагрузки.

Подключите прослушиватель.

  1. В диспетчере отказоустойчивости кластеров разверните Роли и выделите свою группу доступности.

  2. На вкладке Ресурсы щелкните правой кнопкой мыши имя прослушивателя и выберите Свойства.

  3. Перейдите на вкладку "Зависимости ". Если указано несколько ресурсов, убедитесь, что IP-адреса имеют ИЛИ, а не И, зависимости.

  4. Нажмите кнопку ОК.

  5. Щелкните правой кнопкой мыши имя прослушивателя, а затем щелкните Подключить.

  6. После подключения прослушивателя на вкладке Ресурсы щелкните правой кнопкой мыши группу доступности и выберите Свойства.

    Настройка ресурса группы доступности

  7. Создайте зависимость для ресурса имени прослушивателя (не имени ресурсов IP-адреса), а затем щелкните ОК.

    Добавление зависимости к имени прослушивателя

  8. Запустите SQL Server Management Studio и подключитесь к основной реплике.

  9. Перейдите кпрослушивателям группы доступности><AvailabilityGroupName>> с высоким уровнем доступности> AlwaysOn.
    Теперь должно отобразиться имя прослушивателя, созданного в диспетчере отказоустойчивости кластеров.

  10. Щелкните правой кнопкой мыши имя прослушивателя и выберите Свойства.

  11. В поле Порт укажите номер порта для прослушивателя группы доступности с помощью использованного ранее параметра $EndpointPort (в этом руководстве по умолчанию использовалось значение 1433) и нажмите кнопку ОК.

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

После создания прослушивателя группы доступности, возможно, придется настроить параметры кластера RegisterAllProvidersIP и HostRecordTTL для ресурса прослушивателя. Эти параметры могут снизить время переподключения после отработки отказа, что может препятствовать истечению времени ожидания подключения. Дополнительные сведения об этих параметрах, а также образец кода см. в разделе Ключевое слово и связанные функции MultiSubnetFailover.

Проверка прослушивателя группы доступности (в пределах одной виртуальной сети)

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

Клиентские подключения имеют следующие требования:

  • Клиентские подключения к прослушивателю должны выполняться с компьютеров в другой облачной службе (не той, на которой не размещены реплики доступности AlwaysOn).
  • Если реплики AlwaysOn размещены в разных подсетях, клиенты должны указывать MultisubnetFailover=True в строке подключения. В результате будут выполняться попытки параллельного подключения к репликам в разных подсетях. Этот сценарий включает развертывание межрегиональной группы доступности AlwaysOn.

Примером может служить подключение к прослушивателю с одной из виртуальных машин в одной виртуальной сети Azure (не той, в которой размещена реплика). Самый простой способ проверки — подключить SQL Server Management Studio к прослушивателю группы доступности. Еще одним простым способом является запуск SQLCMD.exeследующим образом:

sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15

Примечание

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

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

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

Кроме автоматического подключения клиентов к первичной реплике, прослушиватель можно использовать для перенаправления рабочих нагрузок только для чтения на вторичные реплики. Это может повысить производительность и масштабируемость решения в целом. Дополнительные сведения см. в записи блога Use ReadIntent Routing with Azure AlwaysOn Availability Group Listener (Использование маршрутизации ReadIntent с прослушивателем группы доступности AlwaysOn Azure).

Примечание

Советы по устранению неполадок прослушивателей Azure см. в записи Troubleshooting Internal Load Balancer Listener Connectivity in Azure (Устранение неполадок прослушивателя внутреннего балансировщика нагрузки Azure) блога группы поддержки AlwaysOn.

Дополнительные сведения об использовании SQL Server в Azure см. в статье Приступая к работе с SQL Server в виртуальных машинах Azure.