Настройка DNN для экземпляра отказоустойчивого кластера

Статья
2024-06-18

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

На Виртуальных машинах Azure имя распределенной сети (DNN) маршрутизирует трафик в соответствующий кластерный ресурс. Оно обеспечивает более простой способ подключения к экземпляру отказоустойчивого кластера (FCI) SQL Server, чем имя виртуальной сети (VNN), и не требует использования Azure Load Balancer.

Эта статья предоставляет сведения о том, как настроить ресурс DNN для маршрутизации трафика в экземпляр отказоустойчивого кластера с помощью SQL Server на виртуальных машинах Azure, обеспечивая тем самым высокую доступность и аварийное восстановление (HADR).

Для альтернативного варианта подключения рассмотрите использование имени виртуальной сети и Azure Load Balancer.

Обзор

Имя распределенной сети (DNN) заменяет имя виртуальной сети (VNN) в качестве точки подключения при использовании с экземпляром отказоустойчивого кластера Always On на виртуальных машинах SQL Server. Это позволяет свести к нулю необходимость использования Azure Load Balancer для маршрутизации трафика в VNN, упрощения развертывания, обслуживания и повышения отработки отказа.

При развертывании экземпляра отказоустойчивого кластера, VNN по-прежнему имеется, однако клиент подключается к DNS-имени DNN, а не к имени VNN.

Совет

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

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

Чтобы выполнить действия, описанные в этой статье, необходимо следующее:

SQL Server (SQL Server 2019 CU8 или более поздней версии, SQL Server 2017 CU25 или более поздней версии либо SQL Server 2016 с пакетом обновления 3 (SP3) или более поздней версии) на базе Windows Server 2016 или более поздней версии.
Принято решение о том, что имя распределенной сети является подходящим вариантом подключения для вашего решения HADR.
настройка экземпляров отказоустойчивого кластера;
установление последней версии PowerShell.

Примечание.

Если в одном кластере имеется несколько групп AG или FCIs, и вы используете прослушиватель DNN или VNN, каждая группа доступности или FCI нуждается в отдельной независимой точке подключения.

Создание ресурса DNN

Ресурс DNN создается в той же кластерной группе, что и экземпляр отказоустойчивого кластера SQL Server. Используйте PowerShell для создания ресурса DNN внутри кластерной группы экземпляра отказоустойчивого кластера.

Следующая команда PowerShell добавляет ресурс DNN в кластерную группу экземпляра отказоустойчивого кластера SQL Server с именем ресурса <dnnResourceName>. Имя ресурса используется для уникальной идентификации ресурса. Используйте то, которое имеет для вас смысл и является уникальным в пределах кластера. Тип ресурса должен быть Distributed Network Name.

Значение -Group должно быть именем кластерной группы, соответствующей экземпляру отказоустойчивого кластера SQL Server, в которую требуется добавить имя распределенной сети. Для экземпляра по умолчанию обычно используется формат SQL Server (MSSQLSERVER).

Add-ClusterResource -Name <dnnResourceName> `
-ResourceType "Distributed Network Name" -Group "<WSFC role of SQL Server instance>"

Например, чтобы создать ресурс DNN dnn-demo для экземпляра отказоустойчивого кластера SQL Server по умолчанию, используйте следующую команду PowerShell:

Add-ClusterResource -Name dnn-demo `
-ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"

Присвоение DNS-имени кластеру DNN

Присвойте DNS-имя ресурсу DNN в кластере. Затем кластер использует это значение для маршрутизации трафика к узлу, на котором в настоящее время размещается экземпляр отказоустойчивого кластера SQL Server.

Клиенты используют DNS-имя для подключения к экземпляру отказоустойчивого кластера SQL Server. Можно выбрать уникальное значение. Если же у вас уже есть существующий экземпляр отказоустойчивого кластера и вы не хотите обновлять строки подключения клиента, можно также настроить DNN для использования текущего VNN, которое клиенты уже используют. Для этого необходимо переименовать VNN перед настройкой DNN в DNS.

Используйте эту команду, чтобы задать DNS-имя для DNN:

Get-ClusterResource -Name <dnnResourceName> | `
Set-ClusterParameter -Name DnsName -Value <DNSName>

Значение DNSName используется клиентами для подключения к экземпляру отказоустойчивого кластера SQL Server. Например, чтобы клиенты могли подключиться к FCIDNN, используйте следующую команду PowerShell:

Get-ClusterResource -Name dnn-demo | `
Set-ClusterParameter -Name DnsName -Value FCIDNN

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

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

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

Переименование VNN

Если у вас есть существующее имя виртуальной сети и вы хотите, чтобы клиенты продолжали использовать это значение для подключения к экземпляру отказоустойчивого кластера SQL Server, необходимо переименовать текущее VNN в значение-заполнитель. После переименования текущего VNN, ему можно задать значение DNS-имени для DNN.

Для переименования VNN действуют некоторые ограничения. Дополнительные сведения см. в статье об переименовании экземпляра отказоустойчивого кластера.

Если использование текущего VNN для вашей организации не требуется, этот раздел можно пропустить. После переименования VNN задайте DNS-имя для DNN кластера.

Настройка ресурса DNN в сети

После того, как ресурсу DNN будет присвоено соответствующее имя и вы зададите значение DNS-имени в кластере, с помощью PowerShell настройте ресурс DNN в режиме "в сети" в кластере.

Start-ClusterResource -Name <dnnResourceName>

Например, чтобы запустить ресурс DNN dnn-demo, используйте следующую команду PowerShell:

Start-ClusterResource -Name dnn-demo

Настройка возможных владельцев.

По умолчанию кластер привязывает DNS-имя для DNN ко всем узлам в кластере. Однако узлы в кластере, которые не являются частью экземпляра отказоустойчивого кластера SQL Server, должны быть исключены из списка возможных владельцев DNN.

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

Перейдите к ресурсу DNN в диспетчере отказоустойчивости кластеров.
Щелкните ресурс DNN правой кнопкой мыши и выберите пункт Свойства.
Снимите флажки для всех узлов, которые не участвуют в экземпляре отказоустойчивого кластера. Список возможных владельцев для ресурса DNN должен совпадать со списком возможных владельцев для ресурса экземпляра SQL Server. Например, если предположить, что Data3 не участвует в экземпляре отказоустойчивого кластера, следующее изображение будет примером удаления Data3 из списка возможных владельцев для ресурса DNN:
Нажмите ОК, чтобы сохранить параметры.

Перезапуск экземпляра SQL Server

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

Перейдите к ресурсу SQL Server в диспетчере отказоустойчивости кластеров.
Щелкните правой кнопкой мыши ресурс SQL Server и переведите его в автономный режим.
После отключения всех связанных ресурсов, щелкните правой кнопкой мыши ресурс SQL Server и переведите его в режим "в сети".

Обновление строки подключения

Измените строку подключения для любого приложения, которое подключается к DNN экземпляра отказоустойчивого кластера SQL Server, включив фрагмент MultiSubnetFailover=True в эту строку подключения. Если клиент не поддерживает параметр MultiSubnetFailover, он не совместим с DNN.

Ниже приводится пример строки подключения к DNN экземпляра отказоустойчивого кластера SQL с DNS-именем FCIDNN:

Data Source=FCIDNN, MultiSubnetFailover=True

Кроме того, если DNN не использует исходное VNN, клиенты SQL, подключающиеся к экземпляру отказоустойчивого кластера SQL Server, должны будут обновить строку подключения на DNS-имя для DNN. Во избежание этого, можно обновить значение DNS-имени, чтобы оно стало именем VNN. Однако сначала необходимо заменить существующее VNN заполнителем.

Тестовая отработка отказа

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

Для этого выполните следующие действия.

Подключитесь к одному из узлов кластера SQL Server с помощью RDP или Бастиона.
Откройте диспетчер отказоустойчивости кластеров. Выберите Роли. Обратите внимание, какой узел является владельцем роли SQL Server FCI.
Щелкните правой кнопкой мыши роль SQL Server FCI.
Выберите Переместить, а затем выберите Лучший возможный узел.

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

Проверка подключения

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

При необходимости можно скачать SQL Server Management Studio.

Избежание конфликта IP-адресов

Этот шаг является необязательным действием для предотвращения назначения виртуального IP-адреса (VIP), используемого ресурсом экземпляра отказоустойчивого кластера, другому ресурсу в Azure в качестве дубликата.

Хотя клиенты теперь используют DNN для подключения к экземпляру отказоустойчивого кластера SQL Server, имя виртуальной сети (VNN) и виртуальный IP-адрес не могут быть удалены, поскольку они являются необходимыми компонентами инфраструктуры экземпляра отказоустойчивого кластера. Тем не менее, поскольку в Azure теперь отсутствует балансировщик нагрузки, резервирующий виртуальный IP-адрес, существует риск того, что другому ресурсу в виртуальной сети будет назначен тот же IP-адрес, что и виртуальный IP-адрес, используемый экземпляром отказоустойчивого кластера. Это потенциально может привести к конфликту дублированных IP-адресов.

Настройте адрес APIPA или выделенный сетевой адаптер для резервирования IP-адреса.

Адрес APIPA

Чтобы избежать использования повторяющихся IP-адресов, настройте адрес APIPA (также известный как локальный адрес канала). Для этого выполните следующую команду:

Get-ClusterResource "virtual IP address" | Set-ClusterParameter 
    –Multiple @{"Address"="169.254.1.1";"SubnetMask"="255.255.0.0";"OverrideAddressMatch"=1;"EnableDhcp"=0}

В этой команде "виртуальный IP-адрес" — это имя ресурса кластерного виртуального IP-адреса, а "169.254.1.1" — это APIPA-адрес, выбранный для виртуального IP-адреса. Выберите адрес, наиболее подходящий для вашей организации. Задайте значение OverrideAddressMatch=1, чтобы разрешить IP-адрес в любой сети, включая диапазон адресов APIPA.

Выделенные сетевые адаптеры

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

Ограничения

Клиент, подключающийся к прослушивателю DNN, должен поддерживать параметр MultiSubnetFailover=True в строке подключения.
При работе с другими функциями SQL Server и экземпляром отказоустойчивого кластера с DNN могут возникнуть дополнительные факторы. Дополнительные сведения см. в статье об экземпляре отказоустойчивого кластера со взаимодействием DNN.

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

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