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

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

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

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

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

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

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

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

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

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

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

• Общих дисков Azure: параметр доступности зависит от того, используется ли SSD-диск премиум-класса или ультра-диск.

  • Зонально-избыточное хранилище на базе премиум SSD (ZRS): Зона доступности в разных зонах. Premium SSD ZRS синхронно реплицирует ваш управляемый диск Azure в три зоны доступности Azure в выбранном регионе. Виртуальные машины, часть отказоустойчивого кластера, могут размещаться в разных зонах доступности, помогая достичь уровня обслуживания, избыточного между зонами SQL Server, который обеспечивает доступность виртуальной машины. Задержка записи на диске для ZRS выше из-за перекрестного копирования данных между зонами.

  • Локально избыточное хранилище (LRS) на основе SSD (цен. категория "Премиум"): группа доступности в разных доменах сбоев/обновлений для LRS на основе SSD (цен. категория "Премиум"). Вы также можете разместить виртуальные машины внутри группы близкого размещения, чтобы расположить их ближе друг к другу. Объединение группы доступности и размещения близкого взаимодействия обеспечивает наименьшую задержку для общих дисков, так как данные реплицируются локально в одном центре обработки данных и предоставляют соглашение об уровне обслуживания виртуальной машины.

  • Локально избыточное хранилище Ultra Disk (LRS): Зоны доступности, однако виртуальные машины должны размещаться в одной и той же зоне. Ultra Disks обеспечивают наименьшую задержку на диске и лучше всего подходят для рабочих нагрузок с интенсивным вводом/выводом. Так как все виртуальные машины, которые являются частью FCI, должны находиться в одной зоне доступности, доступность виртуальной машины ниже.

• Общие папки класса Premium: группа доступности или зоны доступности.

• Storage Spaces Direct: набор доступности.

• Azure Elastic SAN: зоны доступности.

подсети;

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

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

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

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

Настройка DNS

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

Определение IP-адреса DNS

Определите IP-адрес DNS-сервера и добавьте его в конфигурацию виртуальной сети. В этом разделе показано, как определить DNS-IP-адрес, если 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 с виртуальной машины перед настройкой экземпляра отказоустойчивого кластера.

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

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

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

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

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

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

Если вы развернули SQL Server виртуальные машины в одной подсети, пропустите этот шаг.

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

Назначьте вторичные 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. Укажите Name для 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, а затем удалить SQL Server.

Удаление расширения агента IaaS SQL

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

Чтобы удалить расширение из виртуальной машины SQL Server с помощью Azure PowerShell, используйте следующий пример кода:

Remove-AzSqlVM -ResourceGroupName <resource_group_name> -Name <SQL VM resource name>

Удалите SQL Server

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

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

2. Откройте Программы и компоненты в Control Panel.

3. В Programs and Features щелкните правой кнопкой мыши Microsoft SQL Server 201_ (64-разрядная версия) и выберите Uninstall/Change.

4. Выберите Удалить.

5. Выберите экземпляр по умолчанию.

6. На экране Select Features удалите все функции в Database Engine Services, Analysis Services и Reporting Services — Native. Не удаляйте ничего в разделе Общие компоненты. Он должен выглядеть примерно так, как на следующем снимке экрана.

   

7. Щелкните Далее, а затем Удалить.

8. После успешного удаления экземпляра перезапустите виртуальную машину.

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

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

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

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

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

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

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

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

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

• Создать FCI с общими дисками Azure
• Создайте FCI с файл-шарингом класса Premium
• Создайте FCI с Storage Spaces Direct
• Создание FCI с Azure Elastic SAN
• Отказоустойчивый кластер Windows Server с SQL Server на виртуальных машинах Azure
• Экземпляры отказоустойчивого кластера SQL Server на виртуальных машинах Azure
• Обзор экземпляра отказоустойчивого кластера
• Рекомендации по настройке HADR