Настройка внешнего прослушивателя для групп доступности на виртуальных машинах сервера Azure SQL
В этом разделе показано, как настроить прослушиватель для группы доступности AlwaysOn, доступный через Интернет. Такую настройку можно выполнить, связав общедоступный виртуальный IP-адрес (VIP) облачной службы с прослушивателем.
Важно!
В Azure предлагаются две модели развертывания для создания ресурсов и работы с ними: модель развертывания с помощью Resource Manager и классическая модель. В этой статье рассматривается использование классической модели развертывания. Для большинства новых развертываний Майкрософт рекомендует использовать модель диспетчера ресурсов.
В группе доступности могут быть реплики, доступные только локально или только в Azure. В гибридных конфигурациях возможны оба способа доступа одновременно. Реплики в Azure могут находиться в одном или нескольких регионах (при использовании нескольких виртуальных сетей). В приведенных ниже указаниях предполагается, что вы уже настроили группу доступности, но еще не настроили прослушиватель.
Рекомендации и ограничения для внешних прослушивателей
Обратите внимание на следующие рекомендации для прослушивателя группы доступности в Azure при развертывании с использованием общедоступного виртуального IP-адреса облачной службы.
- Прослушиватель группы доступности поддерживается в Windows Server 2008 R2, Windows Server 2012 и Windows Server 2012 R2.
- Клиентское приложение должно находиться в облачной службе, отличной от той, которая содержит виртуальные машины группы доступности. Azure не поддерживает службу Direct Server Return для клиента и сервера в одной облачной службе.
- По умолчанию действия в этой статье показывают, как настроить один прослушиватель для использования виртуального IP-адреса облачной службы. Тем не менее, для облачной службы можно зарезервировать и создать несколько виртуальных IP-адресов. Это позволяет использовать описанные в этой статье шаги, чтобы создать несколько прослушивателей, привязанных к собственному виртуальному IP-адресу. Дополнительные сведения о том, как создать несколько виртуальных IP-адресов, см. в статье Несколько виртуальных IP-адресов для облачной службы.
- Если вы создаете прослушиватель в гибридной среде, в локальной сети должно быть настроено подключение к сети Интернет помимо VPN-подключения типа "сеть-сеть" к виртуальной сети Azure. В подсети Azure прослушиватель группы доступности будет доступен только через общедоступный IP-адрес соответствующей облачной службы.
- Создание внешнего прослушивателя в той же облачной службе, что и внутренний прослушиватель, использующий внутренний балансировщик нагрузки (ILB), не поддерживается.
Определение доступности прослушивателя
Важно понимать, что есть два способа настройки прослушивателя группы доступности в Azure. Они отличаются типом подсистемы балансировки нагрузки Azure, используемой при создании прослушивателя. Различия описаны в следующей таблице:
Тип подсистемы балансировки нагрузки | Реализация | Используется, когда: |
---|---|---|
Внешний | Использование общедоступного виртуального IP-адреса облачной службы, на которой размещены виртуальные машины. | Необходимо, чтобы прослушиватель был доступен за пределами виртуальной сети, в том числе через Интернет. |
Внутренний | Использование внутренней подсистемы балансировки нагрузки с частным адресом для прослушивателя. | Необходимо, чтобы прослушиватель был доступен только в этой виртуальной сети. Сюда относится VPN типа "сеть — сеть" в гибридных сценариях. |
Важно!
Если прослушиватель использует общедоступный VIP-адрес облачной службы (внешний балансировщик нагрузки), то при условии, что клиент, прослушиватель и база данных находятся в одном регионе Azure, вам не будет начисляться плата за исходящий трафик. В противном случае все данные, возвращаемые через прослушиватель, считаются исходящим трафиком и оплачиваются по обычным тарифам на передачу данных.
Внутреннюю подсистему балансировки нагрузки можно настроить только в виртуальных сетях регионального масштаба. В имеющихся виртуальных сетях, настроенных для территориальной группы, невозможно использовать внутреннюю балансировку нагрузки. Дополнительные сведения см. в статье Обзор внутренней подсистемы балансировки нагрузки.
В этой статье рассматривается создание прослушивателя, использующего внешнюю балансировку нагрузки. Если вы хотите использовать закрытый прослушиватель из своей виртуальной сети, см. другую версию этой статьи, где приведены пошаговые инструкции по настройке прослушивателя с помощью внутреннего балансировщика нагрузки.
Создание конечных точек балансировки нагрузки в ВМ со службой Direct Server Return
Внешняя балансировка нагрузки использует общедоступный виртуальный IP-адрес облачной службы, на которой размещены виртуальные машины. В таком случае вам не обязательно создавать или настраивать балансировщик нагрузки.
Для каждой виртуальной машины с репликой Azure необходимо создать конечную точку с балансировкой нагрузки. Все реплики одного региона должны быть в одной облачной службе и одной виртуальной сети. Чтобы создать реплики группы доступности, охватывающие несколько регионов Azure, необходимо настроить несколько виртуальных сетей. Дополнительные сведения о настройке подключения между виртуальными сетями см. в разделе "Настройка подключения виртуальной сети к виртуальной сети".
На портале Azure перейдите к каждой виртуальной машине с репликой и просмотрите сведения.
Щелкните вкладку Конечные точки каждой из ВМ.
Убедитесь, что Имя и Общий порт конечной точки прослушивателя, которые вы собираетесь использовать, еще не используются. В следующем примере используется имя MyEndpoint и порт 1433.
На локальном клиенте скачайте и установите последний модуль PowerShell.
Запустите Azure PowerShell. Откроется новый сеанс PowerShell с загруженными административными модулями Azure.
Выполните командлет Get-AzurePublishSettingsFile. Он перенаправит вас в браузер для скачивания файла параметров публикации в локальный каталог. Может потребоваться ввод учетных данных подписки Azure.
Выполните команду Import-AzurePublishSettingsFile , указав путь к скачанному файлу параметров публикации:
Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
После импорта файла параметров публикации вы сможете управлять подпиской Azure в сеансе PowerShell.
Скопируйте приведенный ниже сценарий 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 # Configure a load balanced endpoint for each node in $AGNodes, with direct server return enabled ForEach ($node in $AGNodes) { Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name "ListenerEndpoint" -Protocol "TCP" -PublicPort 1433 -LocalPort 1433 -LBSetName "ListenerEndpointLB" -ProbePort 59999 -ProbeProtocol "TCP" -DirectServerReturn $true | Update-AzureVM }
Присвоив значения переменным, скопируйте сценарий из текстового редактора в текущий сеанс Azure PowerShell и выполните его. Если при этом появится запрос >>, нажмите ВВОД снова, чтобы начать выполнение скрипта.
Проверка наличия пакета KB2854082
Далее, если серверы в кластере работают под управлением Windows Server 2008 R2 или Windows Server 2012, необходимо убедиться, что исправление KB2854082 установлено на всех локальных серверах или виртуальных машинах Azure, которые являются частью кластера. Это исправление необходимо установить на все сервера или виртуальные машины в кластере, даже если их нет в группе доступности.
В сеансе удаленного рабочего стола для каждого узла кластера скачайте исправление KB2854082 в локальный каталог. Затем последовательно установите его на всех узлах кластера. Если на узле кластера выполняется служба кластеров, после установки исправления сервер перезапустится.
Предупреждение
Остановка службы кластеров и перезапуск сервера влияют на работоспособность кворума кластера и группы доступности и могут привести к отключению кластера. Чтобы обеспечить высокий уровень доступности кластера во время установки, убедитесь, что выполняются следующие условия:
- Кластер имеет оптимальную работоспособность кворума.
- Перед установкой исправления на любом узле все узлы кластера подключены к сети.
- Дождитесь завершения установки исправления на одном узле, в том числе полного перезапуска сервера, перед установкой исправления на другом узле в кластере.
Открытие портов брандмауэра в узлах групп доступности.
На этом шаге создается правило брандмауэра для открытия порта пробы для конечной точки с балансировкой нагрузки (59999, как указано выше) и правило для открытия порта прослушивателя группы доступности. Так как вы создали конечную точку с балансировкой нагрузки на виртуальных машинах, которые содержат реплики группы доступности, необходимо открыть порт пробы и порт прослушивателя на соответствующих виртуальных машинах.
На виртуальных машинах, на которых размещены реплики, запустите брандмауэр Windows в режиме повышенной безопасности.
Щелкните правой кнопкой мыши элемент Правила для входящих подключений и выберите команду Новое правило.
На странице Тип правила выберите Порт и нажмите кнопку Далее.
На странице Протокол и порты выберите TCP и введите 59999 в поле Specific local ports (Определенные локальные порты), а затем щелкните Далее.
На странице Действие оставьте установленным флажок Разрешить подключение и нажмите кнопку Далее.
На странице Профиль примите параметры по умолчанию и нажмите кнопку Далее.
На странице Имя в текстовом поле Имя укажите имя правила, например Порт пробы прослушивателя AlwaysOn, и щелкните Готово.
Повторите предыдущие действия для порта прослушивателя группы доступности (как указано выше в параметре сценария $EndpointPort), а затем укажите соответствующее имя правила, например Порт прослушивателя AlwaysOn.
Создание прослушивателя группы доступности
Создайте прослушиватель группы доступности в два этапа. Сначала создайте ресурс кластера точки доступа клиента и настройте зависимости. Затем настройте кластерные ресурсы с помощью PowerShell.
Создание точки доступа клиента и настройка кластерных зависимостей
На этом шаге вручную создается прослушиватель группы доступности в диспетчере отказоустойчивости кластеров и службе SQL Server Management Studio.
Откройте диспетчер отказоустойчивого кластера из узла, на котором размещена первичная реплика.
Выберите узел Сети и запишите имя сети кластера. Это имя будет использоваться в переменной $ClusterNetworkName в скрипте PowerShell.
Разверните имя кластера и щелкните пункт Роли.
На панели Роли щелкните правой кнопкой мыши имя группы доступности и выберите Добавить ресурс>Точка доступа клиента.
В поле Имя создайте имя для этого нового прослушивателя, а затем дважды щелкните Далее и нажмите кнопку Готово.
Не подключайте прослушивателя или ресурс на этом этапе.Перейдите на вкладку Ресурсы и разверните созданную точку доступа клиента. Отобразится ресурс IP-адреса для каждой сети в кластере. Если это решение только для Azure, вы увидите только один ресурс IP-адреса.
Выполните одно из приведенных ниже действий.
Для настройки гибридного решения:
а. Щелкните правой кнопкой мыши ресурс IP-адреса, соответствующий локальной подсети, и выберите Свойства. Запишите имя IP-адреса и имя сети.
b. Выберите Статический IP-адрес, присвойте неиспользуемый IP-адрес и нажмите кнопку ОК.
Для настройки решения только для Azure:
а. Щелкните правой кнопкой мыши ресурс IP-адреса, соответствующий подсети Azure, и выберите пункт "Свойства".
Примечание
Если позднее прослушиватель не будет подключаться из-за конфликтующего IP-адреса, выбранного протоколом DHCP, вы сможете настроить допустимый статический IP-адрес в этом окне свойств.
b. В том же окне свойств IP-адрес измените имя IP-адреса.
Это имя будет использоваться в переменной $IPResourceName скрипта PowerShell. Повторите этот шаг для каждого IP-ресурса, если решение распространяется на несколько виртуальных сетей Azure.
Настройка кластерных ресурсов в PowerShell
Для использования внешней балансировки нагрузки вам потребуется получить общедоступный виртуальный IP-адрес облачной службы, на которой размещены ваши реплики. Войдите на портал Azure. Перейдите к облачной службе, в которой находится виртуальная машина вашей группы доступности. Откройте представление Панель мониторинга.
Запишите адрес в поле Общедоступный виртуальный IP-адрес (VIP). Если ваше решение располагается в нескольких виртуальных сетях, повторите этот шаг для каждой облачной службы с виртуальной машиной, на которой размещается реплика.
Войдите на одну из виртуальных машин и скопируйте приведенный ниже сценарий PowerShell в текстовый редактор. Затем присвойте переменным записанные ранее значения.
# Define variables $ClusterNetworkName = "<ClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name) $IPResourceName = "<IPResourceName>" # the IP Address resource name $CloudServiceIP = "<X.X.X.X>" # Public Virtual IP (VIP) address of your cloud service Import-Module FailoverClusters # If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. # Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$CloudServiceIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0} # cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$CloudServiceIP probeport=59999 subnetmask=255.255.255.255
Присвоив значения переменным, откройте окно Windows PowerShell с повышенными правами. Затем скопируйте сценарий из текстового редактора, вставьте его в текущий сеанс Azure PowerShell и выполните сценарий. Если при этом появится запрос >>, нажмите ВВОД снова, чтобы начать выполнение скрипта.
Повторите эти действия на каждой виртуальной машине. Этот сценарий настраивает ресурс IP-адреса путем установки IP-адреса облачной службы и прочих параметров, таких как порт зонда. После подключения ресурс IP-адреса сможет отвечать на запросы, отправляемые на порт зонда из созданной ранее конечной точки балансировки нагрузки.
Подключите прослушиватель.
В диспетчере отказоустойчивости кластеров разверните Роли и выделите свою группу доступности.
На вкладке Ресурсы щелкните правой кнопкой мыши имя прослушивателя и выберите Свойства.
Перейдите на вкладку " Зависимости ". Если в списке указано несколько ресурсов, убедитесь, что IP-адреса имеют зависимости OR, а не AND.
Нажмите кнопку ОК.
Щелкните правой кнопкой мыши имя прослушивателя, а затем щелкните Подключить.
После подключения прослушивателя на вкладке Ресурсы щелкните правой кнопкой мыши группу доступности и выберите Свойства.
Создайте зависимость для ресурса имени прослушивателя (не имени ресурсов IP-адреса), а затем щелкните ОК.
Запустите SQL Server Management Studio и подключитесь к основной реплике.
Перейдите кпрослушивателям группдоступностиAvailabilityGroupName>с высоким уровнем доступности<>>AlwaysOn.>
Теперь должно отобразиться имя прослушивателя, созданного в диспетчере отказоустойчивости кластеров.Щелкните правой кнопкой мыши имя прослушивателя и выберите Свойства.
В поле Порт укажите номер порта для прослушивателя группы доступности с помощью использованного ранее параметра $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.
При тестировании прослушивателя обязательно выполните отработку отказа для группы доступности, чтобы убедиться, что клиенты могут подключаться к прослушивателю при сбое.
Проверьте прослушиватель группы доступности (из сети Интернет)
Чтобы получить доступ к прослушивателю извне виртуальной сети, необходимо использовать внешнюю или общедоступную балансировку нагрузки (описанную в этом разделе), а не ILB, которая доступна только в той же виртуальной сети. В строке подключения укажите имя облачной службы. Например, если ваша облачная служба называется mycloudservice, оператор sqlcmd будет выглядеть так:
sqlcmd -S "mycloudservice.cloudapp.net,<EndpointPort>" -d "<DatabaseName>" -U "<LoginId>" -P "<Password>" -Q "select @@servername, db_name()" -l 15
В отличие от предыдущего примера здесь потребуется проверка подлинности SQL. Это связано с тем, что вызывающий объект не может использовать проверку подлинности Windows через Интернет. Дополнительные сведения см. в публикации блога AlwaysOn Availability Group in Windows Azure VM: Client Connectivity Scenarios (Группы доступности AlwaysOn на виртуальной машине Azure: сценарии клиентских подключений). При использовании проверки подлинности SQL учетные данные для входа на обоих репликах должны совпадать. Дополнительные сведения об устранении неполадок с учетными данными, возникающих при использовании групп доступности, см. в статье Сопоставление учетных записей или использование пользователей автономных баз данных SQL для подключения к другим репликам и сопоставления баз данных доступности.
Если реплики AlwaysOn размещены в разных подсетях, клиенты должны указывать MultisubnetFailover=True в строке подключения. В результате будут выполняться попытки параллельного подключения к репликам в разных подсетях. Обратите внимание, что этот сценарий включает развертывание межрегиональной группы доступности AlwaysOn.
Дальнейшие действия
Кроме автоматического подключения клиентов к первичной реплике, прослушиватель можно использовать для перенаправления рабочих нагрузок только для чтения на вторичные реплики. Это может повысить производительность и масштабируемость решения в целом. Дополнительные сведения см. в записи блога 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.