Подготовка среды для канала: Управляемый экземпляр SQL Azure

Статья
10/03/2024

Область применения: Управляемый экземпляр SQL Azure

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

Примечание.

Вы можете автоматизировать подготовку среды для ссылки Управляемый экземпляр с помощью скачиваемого скрипта. Дополнительные сведения см. в блоге по настройке канала автоматизации.

Необходимые компоненты

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

Активная подписка Azure. Если ее нет, создайте бесплатную учетную запись.
Поддерживаемая версия SQL Server с необходимым обновлением службы.
Управляемый экземпляр SQL Azure Руководство по началу работы (при необходимости).
Определите, какой сервер должен быть начальным основным, чтобы определить, откуда следует создать ссылку.
- Настройка ссылки из Управляемый экземпляр SQL основного на дополнительный сервер SQL Server поддерживается только с SQL Server 2022 CU10 и экземплярами, настроенными с политикой обновления SQL Server 2022.

Внимание

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

Разрешения

Для SQL Server у вас должны быть разрешения sysadmin .

Для Управляемый экземпляр SQL Azure вы должны быть членом участника Управляемый экземпляр SQL или иметь следующие разрешения для пользовательской роли:

Microsoft.Sql/ ресурс	Необходимые разрешения
Microsoft.Sql/managedInstances	/read, /write
Microsoft.Sql/managedInstances/hybridCertificate	/действие
Microsoft.Sql/managedInstances/databases	/read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups	/read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates	/read
Microsoft.Sql/managedInstances/hybridLink	/read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates	/write, /delete, /read

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

Чтобы подготовить экземпляр 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` базе данных

Создайте главный 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%';

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

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

Примечание.

Сведения о SQL Server на Linux см. в разделе "Включить группы доступности 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 2016 (13.x), если необходимо включить функцию групп доступности, вам потребуется выполнить дополнительные действия, описанные в разделе "Подготовка предварительных требований SQL Server 2016" — Управляемый экземпляр SQL Azure ссылку. Эти дополнительные шаги не требуются для SQL Server 2019 (15.x) и более поздних версий, поддерживаемых ссылкой.

Если компонент групп доступности не включен:

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

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

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

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

Примечание.

Сведения о SQL Server на Linux см. в разделе "Включение флагов трассировки".

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

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

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

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

Убедившись, что вы используете поддерживаемую версию SQL Server, включили компонент групп доступности Always On и добавили флаги трассировки при запуске, перезапустите экземпляр 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 S S.

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

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

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

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

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

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

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

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

SQL Server вне Azure

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

VPN-подключение "сеть —сеть";
Подключение Azure ExpressRoute

Совет

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

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

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

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

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

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

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

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

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

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

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

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 Server, номера портов для Управляемый экземпляр SQL нельзя изменить или настроить.
Диапазоны IP-адресов подсетей, в которые размещаются управляемые экземпляры, и SQL Server не должен перекрываться.

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

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

Ниже перечислены ресурсы, которые следует добавить в список разрешений:

Полное доменное имя Управляемый экземпляр SQL. Например: managedinstance1.6d710bcf372b.database.windows.net.
Центр записи Майкрософт
Идентификатор ресурса конечной точки Microsoft Entra
Конечная точка Resource Manager
Конечная точка сервиса

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

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

Для работы канала требуется двунаправленное сетевое подключение между экземпляром SQL Server и Управляемым экземпляром SQL. После открытия портов на стороне SQL Server и настройки правила NSG на стороне Управляемый экземпляр SQL проверьте подключение с помощью SQL Server Management Studio (SSMS) или Transact-SQL.

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

Примечание.

Выполнение скриптов PowerShell агент SQL Server в SQL Server на Linux в настоящее время не поддерживается, поэтому в настоящее время невозможно выполнить Test-NetConnection задание агент SQL Server в SQL Server на Linux.

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

Пользователь, выполняющий тест, должен иметь разрешения на создание задания (как sysadmin или принадлежит роли SQLAgentOperator для msdb) для SQL Server и Управляемый экземпляр SQL.
Служба агент SQL Server должна работать в SQL Server. Так как агент по умолчанию включен в Управляемый экземпляр SQL, никаких дополнительных действий не требуется.

SSMS
T-SQL

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

Подключитесь к экземпляру, который будет основной репликой в SSMS.
В обозреватель объектов разверните базы данных и щелкните правой кнопкой мыши базу данных, которую вы планируете связать со вторичной. Выберите "Задачи> Управляемый экземпляр SQL Azure ссылку> Проверить подключение, чтобы открыть мастер проверки сети:
Нажмите кнопку "Далее" на странице "Введение" мастера проверки сети.
Если все требования выполнены на странице "Предварительные требования" , нажмите кнопку "Далее". В противном случае устраните все необходимые компоненты, а затем выберите повторную проверку.
На странице входа выберите "Войти", чтобы подключиться к другому экземпляру, который будет вторичной репликой. Выберите Далее.
При необходимости проверьте сведения на странице "Указать параметры сети" и укажите IP-адрес. Выберите Далее.
На странице "Сводка" просмотрите действия мастера, а затем нажмите кнопку "Готово", чтобы проверить подключение между двумя репликами.
Просмотрите страницу результатов , чтобы проверить наличие подключения между двумя репликами, а затем нажмите кнопку "Закрыть ", чтобы завершить работу.

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

Проверка подключения между экземпляром SQL Server и Управляемым экземпляром SQL

Используйте агент SQL Server в SQL Server для выполнения тестов подключения из SQL Server в Управляемый экземпляр SQL.

Подключитесь к Управляемый экземпляр SQL и запустите следующий скрипт, чтобы создать параметры, которые потребуется позже:

SELECT 'DECLARE @serverName NVARCHAR(512) = N''' + value + ''''
FROM sys.dm_hadr_fabric_config_parameters
WHERE parameter_name = 'DnsRecordName'

UNION

SELECT 'DECLARE @node NVARCHAR(512) = N''' + NodeName + '.' + Cluster + ''''
FROM (
    SELECT SUBSTRING(replica_address, 0, CHARINDEX('\', replica_address)) AS NodeName,
        RIGHT(service_name, CHARINDEX('/', REVERSE(service_name)) - 1) AppName,
        JoinCol = 1
    FROM sys.dm_hadr_fabric_partitions fp
    INNER JOIN sys.dm_hadr_fabric_replicas fr
        ON fp.partition_id = fr.partition_id
    INNER JOIN sys.dm_hadr_fabric_nodes fn
        ON fr.node_name = fn.node_name
    WHERE service_name LIKE '%ManagedServer%'
        AND replica_role = 2
) t1
LEFT JOIN (
    SELECT value AS Cluster,
        JoinCol = 1
    FROM sys.dm_hadr_fabric_config_parameters
    WHERE parameter_name = 'ClusterName'
    ) t2
    ON (t1.JoinCol = t2.JoinCol)
INNER JOIN (
    SELECT [value] AS AppName
    FROM sys.dm_hadr_fabric_config_parameters
    WHERE section_name = 'SQL'
        AND parameter_name = 'InstanceName'
    ) t3
    ON (t1.AppName = t3.AppName)

UNION

SELECT 'DECLARE @port NVARCHAR(512) = N''' + value + ''''
FROM sys.dm_hadr_fabric_config_parameters
WHERE parameter_name = 'HadrPort';

Результаты должны выглядеть следующим образом:

Снимок экрана: выходные данные скрипта, создающего значения параметров для тестирования подключения в SSMS.

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

Соединитесь с SQL Server.

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

--START
-- Parameters section
DECLARE @node NVARCHAR(512) = N''
DECLARE @port NVARCHAR(512) = N''
DECLARE @serverName NVARCHAR(512) = N''

--Script section
IF EXISTS (
        SELECT job_id
        FROM msdb.dbo.sysjobs_view
        WHERE name = N'TestMILinkConnection'
        )
    EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
        @delete_unused_schedule = 1

DECLARE @jobId BINARY (16),
    @cmd NVARCHAR(MAX)

EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
    @enabled = 1,
    @job_id = @jobId OUTPUT

SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'Test Port 5022',
    @step_id = 1,
    @cmdexec_success_code = 0,
    @on_success_action = 3,
    @on_fail_action = 3,
    @subsystem = N'PowerShell',
    @command = @cmd,
    @database_name = N'master'

SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'Test HADR Port',
    @step_id = 2,
    @cmdexec_success_code = 0,
    @subsystem = N'PowerShell',
    @command = @cmd,
    @database_name = N'master'

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)'
GO

EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
GO

--Check status every 5 seconds
DECLARE @RunStatus INT

SET @RunStatus = 10

WHILE (@RunStatus >= 4)
BEGIN
    SELECT DISTINCT @RunStatus = run_status
    FROM [msdb].[dbo].[sysjobhistory] JH
    INNER JOIN [msdb].[dbo].[sysjobs] J
        ON JH.job_id = J.job_id
    WHERE J.name = N'TestMILinkConnection'
        AND step_id = 0

    WAITFOR DELAY '00:00:05';
END

--Get logs once job completes
SELECT [step_name],
    SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
    SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
    [run_status],
    [run_duration],
    [message]
FROM [msdb].[dbo].[sysjobhistory] JH
INNER JOIN [msdb].[dbo].[sysjobs] J
    ON JH.job_id = J.job_id
WHERE J.name = N'TestMILinkConnection'
    AND step_id <> 0
    --END

Замените @nodeзначения, @portполученные на первом шаге, и @serverName параметры.
Запустите скрипт и проверьте результаты. Результаты должны отображаться в следующем примере:
Проверьте результаты:
- Результат каждого теста в TcpTestSucceeded должен быть TcpTestSucceeded : True.
- RemoteAddresses должен принадлежать диапазону IP-адресов для подсети Управляемый экземпляр SQL.
Если тест не удался, проверьте следующие параметры сети:
- Существуют правила как в сетевом брандмауэре, так и в брандмауэре ОС узла SQL Server (Windows/Linux), что позволяет трафику всего диапазона IP-адресов подсети Управляемый экземпляр SQL.
- Существует правило NSG, разрешающее обмен данными через порт 5022 для виртуальной сети, в которой размещен Управляемый экземпляр SQL.

Проверка подключения между Управляемым экземпляром SQL и экземпляром SQL Server

Чтобы проверить, что Управляемый экземпляр SQL может получить доступ к SQL Server, сначала создайте тестовую конечную точку. Затем вы используете агент SQL Server для запуска скрипта PowerShell с tnc помощью команды pinging SQL Server через порт 5022 из управляемого экземпляра SQL.

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

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

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

tnc localhost -port 5022

Успешный тест показывает TcpTestSucceeded : True. Затем можно перейти к созданию задания агент SQL Server в управляемом экземпляре SQL, чтобы попробовать проверить конечную точку тестирования SQL Server на порту 5022 из управляемого экземпляра SQL.

Затем создайте задание агент SQL Server в управляемом экземпляре SQL, выполнив NetHelper следующий скрипт T-SQL в управляемом экземпляре SQL. Замена:

<SQL_SERVER_IP_ADDRESS> с IP-адресом SQL Server, к которому можно получить доступ из управляемого экземпляра SQL.

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

Совет

Если необходимо изменить IP-адрес SQL Server для пробы подключения из управляемого экземпляра SQL, удалите задание NetHelper, выполнив и EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'повторно создав задание NetHelper с помощью предыдущего скрипта.

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

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

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

-- Run on managed instance
EXEC ExecuteNetHelper;

Если подключение выполнено успешно, показано Trueв журнале. Если подключение не выполнено, показано Falseв журнале.

Снимок экрана: ожидаемые выходные данные задания агента SQL NetHelper.

Если подключение не выполнено, проверьте следующие элементы:

Брандмауэр экземпляре узла SQL Server разрешает входящие и исходящие соединения через порт 5022.
Правило NSG для виртуальной сети, в которой размещен Управляемый экземпляр SQL, разрешает обмен данными через порт 5022.
Если ваш экземпляр SQL Server размещен на виртуальной машине Azure, существует правило NSG, разрешающее обмен данными через порт 5022 в виртуальной сети, где размещена виртуальная машина.
Экземпляр SQL Server работает.
В SQL Server существует тестовая конечная точка.

После устранения проблем снова запустите проверку сети NetHelper, выполнив ее EXEC ExecuteNetHelper в управляемом экземпляре.

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

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

Внимание

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

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

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

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

Примечание.

Azure Key Vault поддерживается SQL Server на Linux начиная с SQL Server 2022 CU 14.

установка SSMS

SQL Server Management Studio (SSMS) — самый простой способ использовать ссылку Управляемый экземпляр. Скачайте SSMS версии 19.0 или более поздней версии и установите его на клиентский компьютер.

По завершении установки откройте SSMS и подключитесь к поддерживаемому экземпляру SQL Server. Щелкните правой кнопкой мыши пользовательскую базу данных и убедитесь, что в меню появляется параметр Azure SQL Managed Instance link (Канал Управляемого экземпляра SQL Azure).

Настройка SSMS для облачных служб для государственных организаций

Если вы хотите развернуть Управляемый экземпляр SQL в облаке для государственных организаций, необходимо изменить параметры SQL Server Management Studio (SSMS), чтобы использовать правильное облако. Если вы не развертываете Управляемый экземпляр SQL в облаке для государственных организаций, пропустите этот шаг.

Чтобы обновить параметры SSMS, выполните следующие действия.

Откройте SSMS.
В меню выберите "Сервис" и выберите пункт "Параметры".
Разверните службы Azure и выберите Azure Cloud.
В разделе "Выбор облака Azure" используйте раскрывающийся список для выбора AzureUSGovernment или другого облака для государственных организаций, например AzureChinaCloud:

Снимок экрана: пользовательский интерфейс SSMS, страница параметров, службы Azure с выделенным облаком Azure.

Если вы хотите вернуться в общедоступное облако, выберите AzureCloud из раскрывающегося списка.

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

Дополнительные сведения о ссылке:

Для других сценариев репликации и миграции рекомендуется:

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

Подготовка среды для канала: Управляемый экземпляр SQL Azure

Необходимые компоненты

Разрешения

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

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

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

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

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

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

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

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

SQL Server вне Azure

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

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

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

Проверка подключения между экземпляром SQL Server и Управляемым экземпляром SQL

Проверка подключения между Управляемым экземпляром SQL и экземпляром SQL Server

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

установка SSMS

Настройка SSMS для облачных служб для государственных организаций

Обратная связь

Дополнительные ресурсы

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

Подготовка среды для канала: Управляемый экземпляр SQL Azure

Необходимые компоненты

Разрешения

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

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

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

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

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

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

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

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

SQL Server вне Azure

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

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

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

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

установка SSMS

Настройка SSMS для облачных служб для государственных организаций

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

Обратная связь

Дополнительные ресурсы

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