Поделиться через

Предварительные требования для переноса на виртуальные машины 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.
  • Чтобы вы могли использовать автоматическое заполнение для создания распределенной группы доступности, имя экземпляра для глобального первичного сервера (источника) распределенной группы доступности должно совпадать с именем экземпляра сервера пересылки (назначения) распределенной группы доступности. Если имеется несоответствие имени экземпляра между глобальным первичным и переадресатором, необходимо использовать ручное начальное значение для создания DAG и вручную добавить дополнительные файлы базы данных в будущем.
  • Для простоты версия экземпляра целевого 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 принадлежат к одному домену.

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

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