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

  • Статья

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

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

Перенос одной или нескольких баз данных из изолированного экземпляра с помощью распределенной группы доступности — это простое решение, которое не требует использования отказоустойчивого кластера Windows Server или прослушивателя группы доступности на исходном или целевом серверах. Для переноса группы доступности необходим кластер и прослушиватель на исходном и целевом серверах.

Исходный SQL Server

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

  • При переносе изолированного экземпляра минимальной поддерживаемой версией является SQL Server 2017. При переносе группы доступности поддерживается SQL Server 2016 и более поздних версий.
  • Выпуском SQL Server должен быть Enterprise.
  • Вы также должны включить функцию Always On.
  • Для баз данных, которые вы хотите перенести, созданы резервные копии в полном режиме.
  • Если у вас уже есть группа доступности, она должна быть состоянии работоспособности. Если вы создаете группу доступности в рамках этого процесса, она должна быть в состоянии работоспособности до начала миграции.
  • Порты, используемые экземпляром SQL Server (по умолчанию 1433), и конечная точка зеркалирования базы данных (по умолчанию 5022) должны быть открыты в брандмауэре. Чтобы перенести базы данных в группу доступности, обязательно откройте в брандмауэре порт, используемый прослушивателем.

Виртуальная машина целевого SQL Server

Перед подготовкой виртуальных машин целевого SQL Server к миграции убедитесь, что они удовлетворяют следующим требованиям:

  • Учетная запись Azure, выполняющая миграцию, назначена как владелец или участник для группы ресурсов, которая включает виртуальные машины целевого SQL Server.
  • Чтобы вы могли использовать автоматическое заполнение для создания распределенной группы доступности, имя экземпляра для глобального первичного сервера (источника) распределенной группы доступности должно совпадать с именем экземпляра сервера пересылки (назначения) распределенной группы доступности. Если имена экземпляров на глобальном первичном сервере и на сервере пересылки отличаются, вы должны воспользоваться заполнением вручную, чтобы создать распределенную группу доступности, и вручную добавлять все дополнительные файлы баз данных в будущем.
  • Для простоты версия экземпляра целевого SQL Server должна совпадать с версией экземпляра исходного SQL Server. Если вы выбрали выполнить обновление на целевом сервере во время процесса миграции на более позднюю версию SQL Server, вам потребуется вручную заполнить базу данных, а не полагаться на автоматическое заполнение, которое описывается в этой серии статей. Дополнительные сведения см. в разделе Миграция на более поздние версии SQL Server.
  • Выпуском SQL Server должен быть Enterprise.
  • Вы также должны включить функцию Always On.
  • Порты, используемые экземпляром SQL Server (по умолчанию 1433), и конечная точка зеркалирования базы данных (по умолчанию 5022) должны быть открыты в брандмауэре. Чтобы перенести базы данных в группу доступности, обязательно откройте в брандмауэре порт, используемый прослушивателем.

Соединение

Экземпляры исходного и целевого SQL Server должны быть связаны сетевым подключением.

Если экземпляр исходного SQL Server располагается в локальной сети, настройте VPN-подключение типа "сеть — сеть" или подключение Azure ExpressRoute между локальной сетью и виртуальной сетью, в которой располагается виртуальная машина целевого SQL Server.

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

Проверка подлинности

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

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

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

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