Подготовка виртуальных машин для FCI (SQL Server на виртуальных машинах Azure)

Применимо к:SQL Server на виртуальной машине Azure

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

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

Примечание.

Теперь решение экземпляра отказоустойчивого кластера можно перенести на SQL Server в Виртуальных машинах Azure с помощью службы "Миграция Azure", используя метод lift-and-shift. См. дополнительные сведения о переносе экземпляра отказоустойчивого кластера.

Предварительные требования

• подписка Microsoft Azure; Начало работы с бесплатной учетной записью Azure.
• Домен Windows на виртуальных машинах Azure или локальный активный каталог обработки данных, который был расширен в Azure с помощью связывания виртуальных сетей.
• Учетная запись с разрешениями на создание объектов как на виртуальных машинах Azure, так и в доменные службы Active Directory.
• Виртуальная сеть Azure и одна или несколько подсетей с достаточным пространством IP-адресов для этих компонентов:
  • Обе виртуальные машины
  • IP-адрес для отказоустойчивого кластера Windows
  • IP-адрес для каждого FCI
• служба DNS, настроенная в сети Azure, которая указывает на контроллеры домена;

Выбор параметра хранилища FCI

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

Выбор доступности виртуальных машин

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

Тщательно выберите вариант доступности виртуальной машины, соответствующий предполагаемой конфигурации кластера.

• Общие диски Azure: вариант доступности зависит от того, используется ли ssd класса Premium или UltraDisk:
  • Хранилище, избыточное между зонами (ZRS), на основе дисков SSD (цен. категория "Премиум"): Зона доступности в различных зонах. ZRS на основе дисков SSD (цен. категория "Премиум") синхронно реплицирует данные управляемого диска Azure в три зоны доступности Azure в выбранном регионе. Часть отказоустойчивого кластера, связанная с виртуальными машинами, может находиться в разных зонах доступности, помогая вам достичь экземпляра отказоустойчивого кластера SQL Server, избыточного между зонами, который обеспечивает доступность виртуальной машины в соответствии с соглашением об уровне обслуживания (99,99%). Задержка ZRS на диске выше из-за перекрестной зональной копии данных.
  • Локально избыточное хранилище (LRS) на основе SSD (цен. категория "Премиум"): группа доступности в разных доменах сбоев/обновлений для LRS на основе SSD (цен. категория "Премиум"). Вы также можете разместить виртуальные машины внутри группы размещения близкого взаимодействия, чтобы расположить их ближе друг к другу. Объединение группы доступности и группы размещения близкого взаимодействия обеспечивает наименьшую задержку для общих дисков, так как данные реплицированы локально в одном центре обработки данных и обеспечивают доступность виртуальных машин в соответствии с соглашением об уровне обслуживания (99,95%).
  • Локально избыточное хранилище (LRS) на основе SSD (цен. категория "Ультра"): зона доступности, но виртуальные машины должны размещаться в той же зоне доступности. SSD (цен. категория "Ультра") обеспечивают наименьшую задержку и являются лучшим вариантом для интенсивной рабочей нагрузки ввода-вывода. Т. к. все части отказоустойчивого кластера, связанные с виртуальными машинами, имеют одну и ту же зону доступности, доступность виртуальных машин составляет всего 99,9 %.
• Общие файловые ресурсы категории "Премиум": группа доступности или зона доступности.
• Локальные дисковые пространства: группа доступности.

Важно!

После создания виртуальной машины установить или изменить группу доступности невозможно.

подсети;

В случае с SQL Server на виртуальных машинах Azure вы можете развернуть свои SQL Server в одной или нескольких подсетях.

При развертывании виртуальных машин в нескольких подсетях для IP-адресов максимально используется зависимость кластера ИЛИ, что соответствует локальному опыту подключения к экземпляру отказоустойчивого кластера. Чтобы упростить управление и ускорить отработку отказа рекомендуется подход, предполагающий использование нескольких подсетей для SQL Server на виртуальных машинах Azure.

Для развертывания виртуальных машин в одной подсети требуется дополнительная зависимость от имени Azure Load Balancer или распределенного имени сети (DNN) для маршрутизации трафика в FCI.

Если вы развернете виртуальные SQL Server-сети в нескольких подсетях, выполните действия, которые выполните в этом разделе, чтобы создать виртуальные сети с дополнительными подсетями, а затем после создания виртуальных машин SQL Server назначьте им дополнительные IP-адреса в этих подсетях. Для развертывания виртуальных машин SQL Server в одной подсети не требуется дополнительная конфигурация сети.

Одна подсеть

Поместите обе виртуальные машины в одну подсеть с достаточным количеством IP-адресов для виртуальных машин и всех FCI, которые со временем можно будет установить на кластер. Для этого подхода требуется дополнительный компонент для направления подключений к FCI, например Azure Load Balancer или распределенное сетевое имя (DNN).

Если вы решите развернуть виртуальные машины SQL Server в одной подсети, просмотрите различия между вариантами подключения Azure Load Balancer и DNN и решите, какой из вариантов лучше всего работает перед подготовкой остальной среды к FCI.

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

Несколько подсетей

Если вы хотите маршрутизировать подключения непосредственно к FCI SQL Server, поместите обе виртуальные машины в отдельные подсети в пределах виртуальной сети. Назначьте дополнительный IP-адрес виртуальной машине SQL Server для экземпляра отказоустойчивого кластера и, если вы работаете в Windows Server 2016 и ниже, назначьте дополнительный IP-адрес для отказоустойчивого кластера Windows Server. Windows Server 2019 и более поздних версий использует распределенное имя сети (DNN) для имени кластера, поэтому дополнительный IP-адрес для кластера не требуется.

Этот подход устраняет необходимость в Azure Load Balancer или распределенном сетевом имени (DNN) при подключении к FCI SQL Server.

Если вы решите развернуть виртуальные SQL Server в нескольких подсетях, сначала потребуется создать виртуальную сеть с двумя дополнительными подсетями, а затем после создания виртуальных машин SQL Server назначить дополнительные IP-адреса для виртуальной машины. Дополнительные сведения см. в статье Общие сведения о виртуальных сетях. Имена и IP-адреса подсети в этом разделе предоставляются в качестве примера и могут отличаться в вашей среде. Чтобы создать виртуальную сеть на портале Azure, сделайте следующее:

1. Перейдите к своей группе ресурсов на портале Azure и выберите + Создать.

   

2. Введите виртуальная сеть в поле поиска на Marketplace и выберите плитку виртуальная сеть от Майкрософт. Выберите Создать на странице Виртуальная сеть.

3. В диалоговом окне Создание виртуальной сети введите или следующие сведения на вкладке Основы:

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

   

4. Во вкладке IP-адреса выберите + Добавить подсеть, чтобы добавить дополнительную подсеть к первой виртуальной машине SQL Server, и введите следующие значения:

   1. Укажите значение для параметра Имя подсети, например SQL-subnet-1.
   2. Укажите уникальный диапазон адресов подсети в адресном пространстве виртуальной сети. Например, можно выполнить итерацию третьего октета диапазона адресов подсети контроллера домена по значению 1.
      • Например, если в качестве диапазона по умолчанию вы используете диапазон 10.38.0.0/24, введите диапазон IP-адресов 10.38.1.0/24 для SQL-subnet-1.
      • Аналогично, если по умолчанию вы используете диапазон IP-адресов 10.5.0.0/24, введите 10.5.1.0/24 для новой подсети.
   3. Выберите Добавить, чтобы добавить новую подсеть.

   

5. Повторите предыдущий шаг, чтобы добавить дополнительный уникальный диапазон подсети для второй виртуальной машины SQL Server VM с именем SQL-subnet-2. Вы можете снова выполнить итерацию третьего октета.

   • Например, если по умолчанию используется диапазон IP-адресов 10.38.0.0/24, а ваша подсеть SQL-subnet-1 имеет диапазон 10.38.1.0/24, введите 10.38.2.0/24 для новой подсети
   • Например, если по умолчанию используется диапазон IP-адресов 10.5.0.0/24, а ваша подсеть SQL-subnet-1 имеет диапазон 10.5.1.0/24, введите 10.5.2.0/24 для SQL-subnet-2.

   

6. После добавления второй подсети просмотрите имена и диапазоны подсети (ваши диапазоны могут отличаться от приведенных на рисунке). Если все верно, нажмите Просмотреть и создать и Создать, чтобы создать виртуальную сеть.

   

   Вы вернетесь к панели мониторинга портала Azure и получите уведомление о создании сети.

Настройка DNS

Настройте виртуальную сеть для использования DNS-сервера. Сначала определите IP-адрес DNS, а затем добавьте его в виртуальную сеть.

Указание IP-адреса DNS

Определите IP-адрес DNS-сервера и добавьте его в конфигурацию виртуальной сети. В этом разделе показано, как определить IP-адрес DNS, если DNS-сервер находится на виртуальной машине в Azure.

Чтобы определить IP-адрес виртуальной машины DNS-сервера на портале Azure, сделайте следующее:

1. Перейдите к своей группе ресурсов на портале Azure и выберите виртуальную машину DNS-сервера.
2. На странице виртуальной машины выберите Сеть в области Параметры.
3. Обратите внимание на частный IP-адрес сетевого интерфейса, так как это IP-адрес DNS-сервера. На рисунке с примером приведен частный IP-адрес 10.38.0.4.

Настройка DNS виртуальной сети

Настройте виртуальную сеть для использования этого IP-адреса DNS-сервера.

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

1. Перейдите к группе ресурсов на портале Azureи выберите виртуальную сеть.
2. Выберите DNS-серверы в области Параметры и выберите Пользовательский.
3. Ведите частный IP-адрес, указанного ранее в поле IP-адрес, например 10.38.0.4, или укажите внутренний IP-адрес вашего внутреннего DNS-сервера.
4. Щелкните Сохранить.

Создание виртуальных машин

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

Аспекты сетевого интерфейса

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

Разместите обе виртуальные машины:

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

Можно создать виртуальную машину Azure с помощью образа с предварительно установленными SQL Server или без него. При выборе образа SQL Server необходимо вручную удалить экземпляр SQL Server перед установкой экземпляра отказоустойчивого кластера.

Назначение дополнительных IP-адресов

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

Назначьте дополнительные IP-адреса каждой виртуальной машине SQL Server, чтобы использовать имя сети экземпляра отказоустойчивого кластера, а в Windows Server 2016 и более ранних случаях — дополнительные IP-адреса для каждой виртуальной машины SQL Server для названия сети кластера. Это устранит необходимость в Azure Load Balancer, который обязательно использовать в среде с одной подсетью.

В Windows Server 2016 и более ранних версий вам нужно назначить дополнительный IP-адрес каждой виртуальной машине SQL Server для использования в качестве IP-адреса кластера Windows, так как кластер использует имя сети кластера, а не имя распределенной сети (DNN) по умолчанию, реализованное в Windows Server 2019. При использовании DNN объект имени кластера (CNO) автоматически регистрируется с IP-адресами всех узлов кластера, устраняя необходимость в выделенном IP-адресе кластера Windows.

Если вы используете Windows Server 2016 и более ранних версий, выполните действия в этом разделе, чтобы назначить дополнительный IP-адрес каждой виртуальной машине SQL Server и для имени сети FCI, и для кластера.

Если вы используете Windows Server 2019 или более поздней версии, назначьте дополнительный IP-адрес для имени сети FCI и пропустите действия по назначению IP-адреса кластера Windows, если вы не планируете настраивать кластер с именем виртуальной сети (VNN). В противном случае назначьте оба IP-адреса каждой виртуальной машине SQL Server, как в случае Windows Server 2016.

Чтобы назначить дополнительные IP-адреса виртуальным машинам, сделайте следующее:

1. Перейдите к группе ресурсов на портале Azure и выберите первую виртуальную машину SQL Server.

2. Выберите Сеть в области Параметры и выберите Сетевой интерфейс:

   

3. На странице Сетевой интерфейс выберите Конфигурации IP в области Параметры и щелкните + Добавить, чтобы добавить дополнительный IP-адрес:

   

4. На странице Добавление конфигурации IP сделайте следующее:

   1. Укажите для параметра Имя значение IP-адреса кластера Windows, напримерwindows-cluster-ip для Windows 2016 и более ранних версий. Пропустите этот шаг, если вы используете Windows Server 2019 или более поздней версии.
   2. Задайте для параметра Выделение значение Статическое.
   3. Введите неиспользуемый IP-адрес в той же подсети (SQL-subnet-1), в которой располагается виртуальная машина SQL Server, например 10.38.1.10.
   4. Оставьте для параметра Общедоступный IP-адрес значение по умолчанию Отмена связи.
   5. Нажмите кнопку ОК, чтобы завершить добавление конфигурации IP.

   

5. Выберите + Добавить еще раз, чтобы настроить дополнительный IP-адрес для имени сети FCI (с таким именем, как FCI-network-name), снова указав неиспользуемый IP-адрес в SQL-subnet-1, например 10.38.1.11:

   

6. Повторите эти действия для второй виртуальной машины SQL Server. Назначьте два неиспользуемых дополнительных IP-адреса в SQL-subnet-2. Используйте значения из таблицы ниже, чтобы добавить конфигурацию IP-адреса (хотя IP-адреса являются только примерами, ваш адрес может отличаться):

   Поле	Входные данные	Входные данные
   имя;	windows-cluster-ip	FCI-network-name
   Распределение	Статические	Статические
   IP-адрес	10.38.2.10	10.38.2.11

Удаление SQL Server

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

Отмена регистрации в расширении агента IaaS SQL

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

Удаление SQL Server

После отмены регистрации в расширении можно удалить SQL Server. Выполните следующие шаги на каждой виртуальной машине.

1. Подключитесь к виртуальной машине с помощью протокола удаленного рабочего стола (RDP). При первом подключении к виртуальной машине с помощью протокола удаленного рабочего стола вы получаете запрос, должен ли этот компьютер быть доступным в сети. Выберите Да.
2. Откройте Программы и признаки на Панели управления.
3. В разделе Программы и компоненты правой кнопкой мыши щелкните Microsoft SQL Server 201_ (64-разрядная версия) и выберите Удалить/Изменить.
4. Щелкните Удалить.
5. Выберите экземпляр по умолчанию.
6. Удалите все признаки, относящиеся к службам ядра СУБД, Analysis Services и Reporting Services (в собственном режиме). Не удаляйте ничего в области SharedFeatures. Вы увидите примерно следующий снимок экрана:
7. Щелкните Далее, а затем Удалить.
8. После успешного удаления экземпляра перезапустите виртуальную машину.

Открытие брандмауэра

На каждой виртуальной машине откройте TCP-порт брандмауэра Windows, который использует SQL Server. По умолчанию SQL Server использует порт 1433, но если вы изменили его в своей среде, откройте порт, который SQL Server использовать. Порт 1433 автоматически открывается в образах SQL Server, развернутых из Azure Marketplace.

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

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

Назначение	Port	Примечания
SQL Server	TCP 1433	Обычный порт для экземпляров SQL Server по умолчанию. Если используется образ из коллекции, этот порт будет автоматически открыт. Используется: всеми конфигурациями FCI.
Проверка работоспособности	TCP 59999	Любой открытый TCP-порт. Настройте пробу работоспособности подсистемы балансировки нагрузки и кластер на использование этого порта. Используется: FCI с балансировой нагрузки в сценарии с одной подсетью.
Общая папка	UDP 445	Порт, используемый службой файлового ресурса. Используется: FCI с общей папкой "Премиум".

Присоединение к домену.

Кроме того, необходимо присоединить к домену виртуальные машины. Это можно сделать с помощью шаблона быстрого запуска.

Проверка конфигурации хранилища

Виртуальные машины, созданные из Azure Marketplace, имеют подключенное хранилище. Если вы планируете настроить хранилище FCI с помощью файловых ресурсов уровня "Премиум" или общих дисков Azure, можно удалить подключенное хранилище, чтобы сэкономить на затратах, поскольку локальное хранилище не используется для экземпляра отказоустойчивого кластера. Однако можно использовать подключенное хранилище для Локальных дисковых пространств решений FCI, поэтому их удаление в этом случае может оказаться бесполезным. Ознакомьтесь с решением хранилища FCI, чтобы определить, оптимально ли удаление подключенного хранилища для экономии затрат.

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

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

Выберите одно из следующих руководств, чтобы настроить среду FCI, подходящую для вашего бизнеса:

• Настройка FCI с общими дисками Azure
• Настройка FCI с помощью файлового ресурса "Премиум"
• Настройка FCI с помощью Локальных дисковых пространств

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

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