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

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

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

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

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

Обзор

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

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

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

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

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

Создание ресурса 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. Можно выбрать уникальное значение. Или, если у вас уже есть FCI и вы не хотите обновлять строки подключения клиента. Вы можете настроить DNN для использования текущей виртуальной сети, которую клиенты уже используют. Для этого необходимо переименовать 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 в строку подключения при подключении к FCI SQL Server.

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

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

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

После переименования VNN задайте DNS-имя DNN кластера.

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

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

Start-ClusterResource -Name <dnnResourceName>

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

Start-ClusterResource -Name dnn-demo

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

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

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

1. Перейдите к ресурсу DNN в диспетчере отказоустойчивости кластеров.

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

   

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

   

4. Нажмите ОК, чтобы сохранить параметры.

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

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

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

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

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

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

Data Source=FCIDNN, MultiSubnetFailover=True

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

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

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

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

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

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

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

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

Установите последнюю версию SQL Server Management Studio (SSMS).

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

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

Хотя клиенты теперь используют DNN для подключения к FCI SQL Server, вы не можете удалить имя виртуальной сети (VNN) и виртуальный IP-адрес, так как они необходимы компоненты инфраструктуры FCI. Однако в системе Azure больше нет балансировщика нагрузки, резервирующего виртуальный IP-адрес. Таким образом, существует риск того, что другой ресурс в виртуальной сети может быть назначен тем же IP-адресом, что и виртуальный IP-адрес, используемый FCI. Эта ситуация может привести к возникновению проблемы с повторяющимся 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.

Связанный контент

• Отказоустойчивый кластер Windows Server с SQL Server на виртуальных машинах Azure
• Экземпляры кластера отказоустойчивости с SQL Server на Виртуальных машинах Azure
• Общие сведения об экземпляре отказоустойчивого кластера
• Рекомендации по настройке HADR (SQL Server на виртуальных машинах Azure)