Подготовка среды для миграции ссылок управляемого экземпляра — миграция SQL Server в Azure Arc

Применимо к:SQL Server

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

С помощью ссылки можно перенести базы данных SQL Server в Управляемый экземпляр SQL Azure с помощью репликации в режиме реального времени с распределенной группой доступности (онлайн-миграция):

Схема миграции ссылок Managed Instance.

Замечание

Вы можете предоставить отзывы о вашем опыте миграции непосредственно в группу продуктов.

Предпосылки

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

Активная подписка Azure. Если ее нет, создайте бесплатную учетную запись.
Поддерживаемый экземпляр SQL Server, включён с помощью Azure Arc с расширением Azure для SQL Server версии 1.1.3238.349 или более поздней. Расширение можно обновить с помощью портала Azure или Azure CLI.

Поддерживаемые версии SQL Server

Уровни служб "Общего назначения" и "Критически важный для бизнеса" управляемого экземпляра SQL Azure поддерживают ссылку "Управляемый экземпляр". Миграция с помощью функции ссылки работает с выпусками SQL Server Enterprise, Developer и Standard на Windows Server.

В следующей таблице перечислены минимальные поддерживаемые версии SQL Server для ссылки:

Версия SQL Server	Минимальное требуемое обновление обслуживания
SQL Server 2025 (17.x)	SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x)	SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x)	SQL Server 2019 CU20 (15.0.4312.2)
SQL Server 2017 (14.x)	SQL Server 2017 CU31 (14.0.3456.2) или более поздней версии и соответствующая сборка пакета SQL Server 2017 Azure Connect (14.0.3490.10)
SQL Server 2016 (13.x)	SQL Server 2016 с пакетом обновления 3 (SP3, 13.0.6300.2) и соответствующий пакет SQL Server 2016 Azure Connect (13.0.7000.253)
SQL Server 2014 (12.x) и более ранних версий	Версии до SQL Server 2016 не поддерживаются.

Обратная миграция поддерживается только в SQL Server 2025 и SQL Server 2022 из управляемых экземпляров SQL с соответствующей политикой обновления. Вы можете вручную отменить миграцию с помощью других средств, таких как собственное резервное копирование и восстановление, или вручную настроить ссылку в SSMS.

Permissions

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

В исходном экземпляре SQL Server вам потребуются следующие разрешения:

Если включить минимальные привилегии, необходимые разрешения, такие как sysadmin , предоставляются по мере необходимости во время процесса миграции базы данных.
Если вы не можете использовать минимальные привилегии, пользователь, выполняющий миграцию, нуждается в разрешениях sysadmin в исходном экземпляре SQL Server. Кроме того, если необходимо отменить миграцию, также вручную назначьте разрешения sysadmin учетной NT AUTHORITY\SYSTEM записи.

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

роль участника Управляемого экземпляра SQL.
Роль участника уровня подписки или владельца

Минимальные разрешения см. в разделе "Пользовательские разрешения".

Замечание

Пользователи с разрешениями SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink, и SqlServerAvailabilityGroups_deleteMiLink в Azure могут выполнять действия на панели миграции базы данных в процессе миграции, которые повышают права доступа SQL Server учетной записи, которую использует расширение, включая роль sysadmin.

Подготовка экземпляра SQL Server

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

Убедитесь, что вы находитесь в поддерживаемой версии.
Создайте главный ключ базы данных в master базе данных.
Включите функцию групп доступности.
Добавьте правильные флаги трассировки при запуске.
Перезапустите SQL Server и проверьте конфигурацию.
Задайте для базы данных полную модель восстановления.
Импорт ключей доверенных корневых центров сертификации Azure в SQL Server.

Чтобы эти изменения вступили в силу, необходимо перезапустить SQL Server .

Установка обновлений службы

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

Чтобы проверить версию SQL Server, запустите следующий скрипт Transact-SQL (T-SQL) на экземпляре SQL Server:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Создание главного ключа базы данных в базе данных master

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

Создайте главный ключ базы данных в master базе данных. Вставьте пароль вместо следующего скрипта <strong_password> и сохраните его в конфиденциальном и безопасном месте. Запустите этот скрипт T-SQL в SQL Server:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

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

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Подготовка экземпляров SQL Server 2016

Для SQL Server 2016 (13.x) необходимо выполнить дополнительные действия, описанные в разделе "Подготовка необходимых компонентов SQL Server 2016 для ссылки". Эти дополнительные действия не требуются для SQL Server 2017 (14.x) и более поздних версий, поддерживаемых ссылкой.

Включение групп доступности

Функция ссылки использует функцию групп доступности AlwaysOn, которая по умолчанию отключена. Дополнительные сведения см. в разделе "Включить групп доступности AlwaysOn".

Чтобы убедиться, что функция групп доступности включена, выполните следующий скрипт T-SQL на SQL Server:

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Если функция групп доступности не включена, выполните следующие шаги, чтобы её включить:

Откройте Диспетчер конфигурации SQL Server.
Выберите элемент Службы SQL Server на панели слева.
Щелкните правой кнопкой мыши службу SQL Server, а затем выберите свойства:
Перейдите на вкладку Группы доступности Always On.
Установите флажок "Включить группы доступности AlwaysOn ", а затем нажмите кнопку "ОК".
- Если вы используете SQL Server 2016 (13.x) и параметр "Enable Always On Availability Groups" отключен с сообщением This computer is not a node in a failover cluster, выполните действия, описанные в разделе "Подготовка предварительных условий для SQL Server 2016". После выполнения этих действий вернитесь к этому шагу и повторите попытку.
Нажмите кнопку "ОК " в диалоговом окне.
Перезапустите службу SQL Server.

Включите флаги трассировки запуска

Чтобы оптимизировать производительность ссылки, включите следующие флаги трассировки при запуске:

-T1800: этот флаг трассировки оптимизирует производительность, если файлы журнала для основных и вторичных реплик в группе доступности находятся на дисках с разными размерами сектора, такими как 512 байтов и 4 КБ. Если первичные и вторичные реплики используют размер сектора диска размером 4 КБ, этот флаг трассировки не нужен. Дополнительные сведения см. здесь: KB3009974.
-T9567. Этот флаг трассировки включает сжатие потока данных для групп доступности во время автоматического заполнения. Сжатие увеличивает нагрузку на процессор, но может значительно сократить время передачи во время посева.

Чтобы включить эти флаги трассировки при запуске, сделайте следующее:

Откройте диспетчер конфигурации SQL Server.
Выберите элемент Службы SQL Server на панели слева.
Щелкните правой кнопкой мыши службу SQL Server, а затем выберите "Свойства".
Перейдите на вкладку Параметры запуска. В поле Укажите параметр запуска введите -T1800 и выберите Добавить, чтобы добавить параметр запуска. Затем введите -T9567 и выберите команду Добавить, чтобы добавить другой флаг трассировки. Щелкните Применить, чтобы сохранить изменения.
Щелкните OK, чтобы закрыть окно Свойства.

Для получения дополнительной информации см. синтаксис включения флагов трассировки.

Перезапуск SQL Server и проверка конфигурации

Если вам не нужно обновить версию SQL Server, включите функцию группы доступности или добавьте флаги трассировки запуска, можно пропустить этот раздел.

Убедившись, что вы используете поддерживаемую версию SQL Server, включите функцию групп доступности AlwaysOn и добавьте флаги трассировки запуска, перезапустите экземпляр SQL Server, чтобы применить все эти изменения:

Откройте Диспетчер конфигурации SQL Server.
Выберите элемент Службы SQL Server на панели слева.
Щелкните правой кнопкой мыши службу SQL Server, а затем выберите "Перезапустить".

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

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

Ваша версия SQL Server должна быть одной из поддерживаемых версий с соответствующими обновлениями службы. Функция групп доступности AlwaysOn должна быть включена, и флаги трассировки -T1800 и -T9567 также должны быть включены. На следующем снимок экрана показан пример ожидаемого результата для правильно настроенного экземпляра SQL Server:

Снимок экрана с ожидаемым результатом в S S M S.

Настройка модели полного восстановления базы данных

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

Выполните следующий код в SQL Server для всех баз данных, которые вы хотите перенести. Замените <DatabaseName> фактическим именем базы данных.

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Импорт ключей доверенного корневого центра сертификации Azure в SQL Server

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

Ключи корневого ЦС можно скачать из раздела сведений о центре сертификации Azure. Как минимум, скачайте сертификаты DigiCert Global Root G2 и Microsoft RSA Root Certificate Authority 2017 и импортируйте их в экземпляр SQL Server.

Замечание

Корневой сертификат в цепочке сертификации для сертификата открытого ключа управляемого экземпляра SQL выдан доверенным корневым центром сертификации Azure. Определенный корневой ЦС может измениться со временем, так как Azure обновляет список доверенных ЦС. Чтобы упростить настройку, установите все сертификаты корневого центра сертификации, перечисленные в корневых удостоверяющих центрах Azure. Вы можете установить только необходимый ключ ЦС, определив издателя ранее импортированного открытого ключа управляемого экземпляра SQL.

Сохраните сертификаты локально на экземпляре SQL Server, например по примеру пути C:\certs\<name of certificate>.crt, а затем импортируйте сертификаты из этого пути, используя следующий скрипт Transact-SQL. Замените <name of certificate> фактическим именем сертификата: DigiCert Global Root G2 и Microsoft RSA Root Certificate Authority 2017которые являются обязательными именами для этих двух сертификатов.

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

Подсказка

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

Наконец, проверьте все созданные сертификаты с помощью следующего динамического административного представления (DMV):

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

Настройка сетевого подключения

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

SQL Server вне Azure

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

Межсайтовое VPN-подключение
Подключение Azure ExpressRoute

Подсказка

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

SQL Server на Виртуальных машинах Microsoft Azure

Развертывание SQL Server на виртуальных машинах Azure в той же виртуальной сети Azure, где размещен управляемый экземпляр SQL, является самым простым методом, так как сетевое подключение автоматически существует между двумя экземплярами. Для получения дополнительной информации см. Краткое руководство: настройка виртуальной машины Azure для подключения к Управляемому экземпляру Azure SQL.

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

У вас есть два варианта подключения виртуальных сетей:

Пиринговое соединение виртуальных сетей Azure
VPN-шлюз между виртуальными сетями (портал Azure, PowerShell, Azure CLI).

Пиринг предпочтительнее, так как он использует магистральную сеть Майкрософт. Таким образом, с точки зрения подключения нет заметной разницы в задержке между виртуальными машинами в одноранговой виртуальной сети и в одной виртуальной сети. Поддерживается пиринг виртуальных сетей, находящихся в одном регионе. Пиринг глобальной виртуальной сети поддерживается для экземпляров, размещенных в подсетях, созданных после 22 сентября 2020 г. Дополнительные сведения см. в разделе часто задаваемые вопросы (часто задаваемые вопросы).

Сетевые порты между средами

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

Правила группы безопасности сети (NSG) в подсети, в которую размещается управляемый экземпляр SQL, должны разрешать:

Входящий порт 5022 и диапазон портов 11000–11999 для получения трафика с исходного IP-адреса SQL Server
Исходящий порт 5022 для отправки трафика в целевой IP-адрес SQL Server

Порт 5022 нельзя изменить в Управляемом экземпляре SQL.

Все брандмауэры в сети, на которых размещен SQL Server, и ос узла должны разрешать:

Входящий порт 5022 открыт для получения трафика из исходного диапазона IP-адресов подсети MI /24 (например, 10.0.0.0/24)
Исходящие порты 5022 и диапазон портов 11000-11999, открытый для отправки трафика в диапазон IP-адресов целевой подсети MI (например, 10.0.0.0/24)

Порт 5022 можно настроить на стороне SQL Server, но диапазон портов 11000–11999 должен быть открыт как есть.

В таблице ниже описаны действия портов для каждой среды.

Окружающая среда	Что следует делать
SQL Server (вне Azure)	Откройте входящий и исходящий трафик через порт 5022 для сетевого брандмауэра для всего диапазона IP-адресов подсети Управляемого экземпляра SQL. При необходимости сделайте то же самое в брандмауэре ОС Windows для узла SQL Server.
SQL Server (в Azure)	Откройте входящий и исходящий трафик через порт 5022 для сетевого брандмауэра для всего диапазона IP-адресов подсети Управляемого экземпляра SQL. При необходимости сделайте то же самое в брандмауэре ОС Windows для узла SQL Server. Чтобы разрешить обмен данными через порт 5022, создайте правило группы безопасности сети (NSG) в виртуальной сети, на котором размещена виртуальная машина.
Управляемый экземпляр SQL	Создайте правило NSG на портале Azure, чтобы разрешить входящий и исходящий трафик из IP-адреса и сети, на котором размещен SQL Server через порт 5022 и диапазон портов 11000–11999.

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

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

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

Это важно

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

Добавление URL-адресов в список разрешений

В зависимости от параметров безопасности сети может потребоваться добавить URL-адреса в список разрешений для полного доменного имени управляемого экземпляра SQL и некоторые конечные точки управления ресурсами, используемые Azure.

Добавьте следующие ресурсы в список разрешений:

Полное доменное имя Управляемый экземпляр SQL. Например: managedinstance.a1b2c3d4e5f6.database.windows.net.
Управление Microsoft Entra
Идентификатор ресурса конечной точки Microsoft Entra
Конечная точка диспетчера ресурсов
Конечная точка сервиса

Выполните действия, описанные в разделе "Настройка SSMS для облачных служб для государственных организаций ", чтобы получить доступ к интерфейсу tools в SQL Server Management Studio (SSMS) и определить определенные URL-адреса ресурсов в облаке, которые необходимо добавить в список разрешений.

Перенос сертификата защищенной TDE базы данных (необязательно)

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

Базы данных управляемого экземпляра SQL, зашифрованные с помощью ключей TDE, управляемых службой, не могут быть связаны с SQL Server. При шифровании базы данных, управляемой клиентом, можно связать только зашифрованную базу данных с SQL Server, а целевой сервер имеет доступ к тому же ключу, который используется для шифрования базы данных. Дополнительные сведения см. в статье "Настройка TDE SQL Server с помощью Azure Key Vault".

Замечание

Azure Key Vault поддерживается SQL Server в Linux, начиная с накопительного обновления 14 для SQL Server 2022.

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

Перед началом миграции проверьте сетевое подключение между экземпляром SQL Server и Управляемым экземпляром SQL. Вы можете проверить подключение непосредственно с портала Azure в рамках процесса миграции. Однако вы также можете проверить подключение вручную с помощью Transact-SQL и агента SQL Server. Дополнительные сведения см. в разделе "Тестирование сетевого подключения".

Чтобы проверить подключение через портал Azure, выполните следующие действия.

Выберите "Миграция данных " в области миграции базы данных для ресурса экземпляра SQL Server.
Выберите опцию MI ссылка.
Выберите целевые базы данных, которые вы хотите перенести, а затем используйте Дальше: Параметры для перехода на следующую вкладку.
На вкладке "Параметры" укажите имя ссылки и исходную группу доступности. Затем используйте тестовое подключение для проверки сетевого подключения между SQL Server и Управляемым экземпляром SQL:

Рассмотрим следующие моменты:

Чтобы избежать ложных отрицательных значений, все брандмауэры по сетевому пути должны разрешать трафик протокола ICMP.
Чтобы избежать ложных срабатываний, все брандмауэры по сетевому пути должны разрешать трафик по проприетарному протоколу SQL Server UCS. Блокировка протокола может привести к успешному тестированию подключения, но соединение создать не удается.
Расширенные настройки брандмауэра с ограничениями на уровне пакетов должны быть правильно настроены, чтобы разрешить трафик между SQL Server и SQL Managed Instance.

Ограничения

Необходимо учитывать следующие ограничения.

Ограничения ссылки управляемого экземпляра применяются к миграциям через портал Azure.
Для отмены миграции требуются разрешения sysadmin в исходном экземпляре SQL Server. Если экземпляр SQL Server не использует минимальные привилегии, вручную назначьте разрешения sysadmin учетной записи NT AUTHORITY\SYSTEM.
Настройка ссылки на портале Azure для миграции несовместима с ссылками, созданными вручную, с помощью SQL Server Management Studio (SSMS) или Transact-SQL (T-SQL). Ознакомьтесь с известной проблемой , чтобы узнать больше.
Мониторинг миграции с помощью портала Azure доступен только для экземпляров SQL Server, которые соответствуют требованиям к лицензированию мониторинга.

Устранение распространенных неполадок

Чтобы устранить распространенные проблемы при миграции в Управляемый экземпляр SQL Azure, см. статью "Устранение неполадок миграции".

Кері байланыс

Бет пайдалы болды ма?

Last updated on 2025-12-12

Бөлісу құралы:

Подготовка среды для миграции ссылок управляемого экземпляра — миграция SQL Server в Azure Arc

Предпосылки

Поддерживаемые версии SQL Server

Permissions

Подготовка экземпляра SQL Server

Установка обновлений службы

Создание главного ключа базы данных в базе данных master

Подготовка экземпляров SQL Server 2016

Включение групп доступности

Включите флаги трассировки запуска

Перезапуск SQL Server и проверка конфигурации

Настройка модели полного восстановления базы данных

Импорт ключей доверенного корневого центра сертификации Azure в SQL Server

Настройка сетевого подключения

SQL Server вне Azure

SQL Server на Виртуальных машинах Microsoft Azure

Сетевые порты между средами

Добавление URL-адресов в список разрешений

Перенос сертификата защищенной TDE базы данных (необязательно)

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

Ограничения

Устранение распространенных неполадок

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

Кері байланыс

Қосымша ресурстар