Przygotowywanie środowiska pod kątem linku — Azure SQL Managed Instance

Dotyczy: Azure SQL Managed Instance

W tym artykule pokazano, jak przygotować środowisko do połączenia wystąpienia zarządzanego, aby można było replikować między programem SQL Server zainstalowanym w systemach Windows lub Linux i Azure SQL Managed Instance.

Uwaga

Możesz zautomatyzować przygotowywanie środowiska dla linku wystąpienia zarządzanego przy użyciu skryptu do pobrania. Aby uzyskać więcej informacji, zobacz blog Automatyzowanie konfiguracji linku.

Wymagania wstępne

Aby utworzyć połączenie między programem SQL Server i usługą Azure SQL Managed Instance, potrzebne są następujące wymagania wstępne:

• Aktywna subskrypcja platformy Azure. Jeśli jej nie masz, utwórz bezpłatne konto.
• Obsługiwana wersja programu SQL Server z wymaganą aktualizacją usługi.
• Usługa Azure SQL Managed Instance. Rozpocznij pracę , jeśli jej nie masz.
• Zdecyduj, z którego serwera zamierzasz być początkowym serwerem podstawowym, aby określić, skąd ma zostać utworzone łącze.
  • Skonfigurowanie linku z usługi SQL Managed Instance podstawowej do pomocniczej usługi SQL Server jest obsługiwane tylko w przypadku programu SQL Server 2022 CU10 i przez wystąpienia skonfigurowane przy użyciu zasad aktualizacji programu SQL Server 2022.

Uwaga

Podczas tworzenia wystąpienia zarządzanego SQL do użycia z funkcją linku należy wziąć pod uwagę wymagania dotyczące pamięci dla wszystkich funkcji OLTP w pamięci używanych przez program SQL Server. Aby uzyskać więcej informacji, zobacz Omówienie limitów zasobów usługi Azure SQL Managed Instance.

Uprawnienia

W przypadku programu SQL Server należy mieć uprawnienia administratora systemu .

W przypadku usługi Azure SQL Managed Instance należy być członkiem współautora usługi SQL Managed Instance lub mieć następujące uprawnienia do roli niestandardowej:

Microsoft.Sql/ zasób	Wymagane uprawnienia
Microsoft.Sql/managedInstances	/read, /write
Microsoft.Sql/managedInstances/hybridCertificate	/akcję
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	/czytać
Microsoft.Sql/managedInstances/hybridLink	/read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates	/write, /delete, /read

Przygotowywanie wystąpienia programu SQL Server

Aby przygotować wystąpienie programu SQL Server, należy sprawdzić, czy:

• Korzystasz z minimalnej obsługiwanej wersji.
• Włączono funkcję grup dostępności.
• Dodano odpowiednie flagi śledzenia podczas uruchamiania.
• Bazy danych znajdują się w modelu pełnego odzyskiwania i są tworzone kopie zapasowe.

Aby zmiany zaczęły obowiązywać, należy ponownie uruchomić program SQL Server.

Instalowanie aktualizacji usługi

Upewnij się, że wersja programu SQL Server ma zainstalowaną odpowiednią aktualizację obsługi, jak pokazano w tabeli obsługi wersji. Jeśli musisz zainstalować jakiekolwiek aktualizacje, musisz ponownie uruchomić wystąpienie programu SQL Server podczas aktualizacji.

Aby sprawdzić wersję programu SQL Server, uruchom następujący skrypt języka Transact-SQL (T-SQL) w programie SQL Server:

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

Tworzenie klucza głównego bazy danych w master bazie danych

Utwórz klucz główny bazy danych w master bazie danych, jeśli jeszcze go nie ma. Wstaw hasło zamiast <strong_password> w poniższym skrypcie i zachowaj je w bezpiecznym miejscu. Uruchom ten skrypt języka T-SQL w programie SQL Server:

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

Aby upewnić się, że masz klucz główny bazy danych, użyj następującego skryptu języka T-SQL w programie SQL Server:

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

Włączanie grup dostępności

Funkcja linku korzysta z funkcji Zawsze włączone grupy dostępności, która jest domyślnie wyłączona. Aby uzyskać więcej informacji, zobacz Włączanie funkcji Zawsze włączone grupy dostępności.

Uwaga

W przypadku programu SQL Server w systemie Linux zobacz Włączanie zawsze włączonych grup dostępności.

Aby potwierdzić, że funkcja grup dostępności jest włączona, uruchom następujący skrypt języka T-SQL w programie 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'

Ważne

W przypadku programu SQL Server 2016 (13.x), jeśli musisz włączyć funkcję grup dostępności, musisz wykonać dodatkowe kroki opisane w artykule Przygotowywanie wymagań wstępnych programu SQL Server 2016 — link Azure SQL Managed Instance. Te dodatkowe kroki nie są wymagane w przypadku programu SQL Server 2019 (15.x) i nowszych wersji obsługiwanych przez łącze.

Jeśli funkcja grup dostępności nie jest włączona, wykonaj następujące kroki, aby ją włączyć:

1. Otwórz Menedżera konfiguracji programu SQL Server.

2. Wybierz pozycję Usługi programu SQL Server w okienku po lewej stronie.

3. Kliknij prawym przyciskiem myszy usługę SQL Server, a następnie wybierz polecenie Właściwości.

   

4. Przejdź do karty Zawsze włączone grupy dostępności.

5. Zaznacz pole wyboru Włącz zawsze włączone grupy dostępności, a następnie wybierz przycisk OK.

   

   • Jeśli używasz programu SQL Server 2016 (13.x), a jeśli opcja Włącz zawsze włączone grupy dostępności jest wyłączona z komunikatem This computer is not a node in a failover cluster., wykonaj dodatkowe kroki opisane w artykule Przygotowywanie wymagań wstępnych programu SQL Server 2016 — link Azure SQL Managed Instance. Po wykonaniu tych innych kroków wróć i spróbuj ponownie wykonać ten krok.

6. Wybierz przycisk OK w oknie dialogowym.

7. Uruchom ponownie usługę SQL Server.

Włączanie flag śledzenia uruchamiania

Aby zoptymalizować wydajność linku, zalecamy włączenie następujących flag śledzenia podczas uruchamiania:

• -T1800: ta flaga śledzenia optymalizuje wydajność, gdy pliki dziennika dla replik podstawowych i pomocniczych w grupie dostępności są hostowane na dyskach o różnych rozmiarach sektorów, takich jak 512 bajtów i 4 KB. Jeśli zarówno repliki podstawowe, jak i pomocnicze mają rozmiar sektora dysku o rozmiarze 4 KB, ta flaga śledzenia nie jest wymagana. Aby uzyskać więcej informacji, zobacz KB3009974.
• -T9567: Ta flaga śledzenia umożliwia kompresję strumienia danych dla grup dostępności podczas automatycznego rozmieszczania. Kompresja zwiększa obciążenie procesora, ale może znacznie skrócić czas transferu podczas rozmieszczania.

Uwaga

W przypadku programu SQL Server w systemie Linux zobacz Włączanie flag śledzenia.

Aby włączyć te flagi śledzenia podczas uruchamiania, wykonaj następujące kroki:

1. Otwórz Menedżera konfiguracji programu SQL Server.

2. Wybierz pozycję Usługi programu SQL Server w okienku po lewej stronie.

3. Kliknij prawym przyciskiem myszy usługę SQL Server, a następnie wybierz polecenie Właściwości.

   

4. Przejdź do karty Parametry uruchamiania. W obszarze Określ parametr uruchamiania wprowadź -T1800 i wybierz pozycję Dodaj, aby dodać parametr startowy. Następnie wprowadź -T9567 i wybierz pozycję Dodaj , aby dodać inną flagę śledzenia. Wybierz pozycję Zastosuj, aby zapisać zmiany.

   

5. Wybierz przycisk OK , aby zamknąć okno Właściwości .

Aby uzyskać więcej informacji, zobacz składnię umożliwiającą włączanie flag śledzenia.

Uruchom ponownie program SQL Server i zweryfikuj konfigurację

Po upewnieniu się, że korzystasz z obsługiwanej wersji programu SQL Server, włączono funkcję Zawsze włączone grupy dostępności i dodano flagi śledzenia uruchamiania, uruchom ponownie wystąpienie programu SQL Server, aby zastosować wszystkie te zmiany:

1. Otwórz program SQL Server Configuration Manager.

2. Wybierz pozycję Usługi programu SQL Server w okienku po lewej stronie.

3. Kliknij prawym przyciskiem myszy usługę SQL Server, a następnie wybierz polecenie Uruchom ponownie.

   

Po ponownym uruchomieniu uruchom następujący skrypt języka T-SQL w programie SQL Server, aby zweryfikować konfigurację wystąpienia programu 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;

Wersja programu SQL Server powinna być jedną z obsługiwanych wersji zastosowanych z odpowiednimi aktualizacjami usługi, funkcja Zawsze włączone grupy dostępności powinna być włączona i powinna być włączona flagi -T1800 -T9567 śledzenia. Poniższy zrzut ekranu to przykład oczekiwanego wyniku dla wystąpienia programu SQL Server, które zostało prawidłowo skonfigurowane:

Konfigurowanie łączności sieciowej

Aby połączenie działało, musisz mieć łączność sieciową między programem SQL Server i usługą SQL Managed Instance. Wybrana opcja sieci zależy od tego, czy wystąpienie programu SQL Server znajduje się w sieci platformy Azure.

Program SQL Server na maszynach wirtualnych platformy Azure

Wdrażanie programu SQL Server na maszynach wirtualnych platformy Azure w tej samej sieci wirtualnej platformy Azure, która hostuje usługę SQL Managed Instance, jest najprostszą metodą, ponieważ łączność sieciowa będzie automatycznie istnieć między dwoma wystąpieniami. Aby uzyskać więcej informacji, zobacz Szybki start: konfigurowanie maszyny wirtualnej platformy Azure w celu nawiązania połączenia z usługą Azure SQL Managed Instance.

Jeśli wystąpienie programu SQL Server w usłudze Azure Virtual Machines znajduje się w innej sieci wirtualnej niż wystąpienie zarządzane, musisz nawiązać połączenie między obiem sieciami wirtualnymi. Aby ten scenariusz działał, sieci wirtualne nie muszą znajdować się w tej samej subskrypcji.

Istnieją dwie opcje łączenia sieci wirtualnych:

• Komunikacja równorzędna sieci wirtualnych platformy Azure
• Brama sieci VPN między sieciami wirtualnymi (witryna Azure Portal, program PowerShell, interfejs wiersza polecenia platformy Azure)

Komunikacja równorzędna jest preferowana, ponieważ korzysta z sieci szkieletowej firmy Microsoft, dlatego z perspektywy łączności nie ma zauważalnej różnicy w opóźnieniu między maszynami wirtualnymi w równorzędnej sieci wirtualnej i w tej samej sieci wirtualnej. Komunikacja równorzędna sieci wirtualnych jest obsługiwana między sieciami w tym samym regionie. Globalna komunikacja równorzędna sieci wirtualnych jest obsługiwana w przypadku wystąpień hostowanych w podsieciach utworzonych po 22 września 2020 r. Aby uzyskać więcej informacji, zobacz Często zadawane pytania.

Program SQL Server poza platformą Azure

Jeśli wystąpienie programu SQL Server jest hostowane poza platformą Azure, ustanów połączenie sieci VPN między programem SQL Server i usługą SQL Managed Instance przy użyciu jednej z następujących opcji:

• Połączenie sieci VPN typu lokacja-lokacja
• Połączenie usługi Azure ExpressRoute

Napiwek

Zalecamy usługę ExpressRoute w celu uzyskania najlepszej wydajności sieci podczas replikowania danych. Aprowizuj bramę z wystarczającą przepustowością dla twojego przypadku użycia.

Porty sieciowe między środowiskami

Niezależnie od mechanizmu łączności istnieją wymagania, które muszą zostać spełnione, aby ruch sieciowy przepływł między środowiskami:

Reguły sieciowej grupy zabezpieczeń (NSG) w podsieci hostowania wystąpienia zarządzanego muszą zezwalać na:

• Port przychodzący 5022 i zakres portów 11000–11999 do odbierania ruchu ze źródłowego adresu IP programu SQL Server
• Port wychodzący 5022 do wysyłania ruchu do docelowego adresu IP programu SQL Server

Wszystkie zapory w sieci hostowania programu SQL Server, a system operacyjny hosta musi zezwalać na:

• Port przychodzący 5022 otwarty w celu odbierania ruchu z źródłowego zakresu adresów IP podsieci MI /24 (na przykład 10.0.0.0/24)
• Porty wychodzące 5022 i zakres portów 11000-11999 otwarty w celu wysyłania ruchu do docelowego zakresu adresów IP podsieci MI (na przykład 10.0.0.0/24)

W poniższej tabeli opisano akcje portów dla każdego środowiska:

Środowisko	Postępowanie
SQL Server (na platformie Azure)	Otwórz zarówno ruch przychodzący, jak i wychodzący na porcie 5022 dla zapory sieciowej do całego zakresu adresów IP podsieci usługi SQL Managed Instance. W razie potrzeby wykonaj to samo w zaporze systemu operacyjnego hosta programu SQL Server (Windows/Linux). Aby zezwolić na komunikację na porcie 5022, utwórz regułę sieciowej grupy zabezpieczeń w sieci wirtualnej, która hostuje maszynę wirtualną.
SQL Server (poza platformą Azure)	Otwórz zarówno ruch przychodzący, jak i wychodzący na porcie 5022 dla zapory sieciowej do całego zakresu adresów IP podsieci usługi SQL Managed Instance. W razie potrzeby wykonaj to samo w zaporze systemu operacyjnego hosta programu SQL Server (Windows/Linux).
Wystąpienie zarządzane SQL	Utwórz regułę sieciowej grupy zabezpieczeń w witrynie Azure Portal, aby zezwolić na ruch przychodzący i wychodzący z adresu IP oraz sieci hostowania programu SQL Server na porcie 5022 i zakresie portów 11000-11999.

Użyj następującego skryptu programu PowerShell w systemie operacyjnym hosta systemu Windows wystąpienia programu SQL Server, aby otworzyć porty w zaporze systemu 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

Na poniższym diagramie przedstawiono przykład środowiska sieciowego lokalnego wskazującego, że wszystkie zapory w środowisku muszą mieć otwarte porty, w tym zaporę systemu operacyjnego hostująca program SQL Server oraz wszystkie zapory firmowe i/lub bramy:

Ważne

• Porty muszą być otwarte w każdej zaporze w środowisku sieciowym, w tym na serwerze hosta, a także w przypadku zapór i bram firmowych w sieci. W środowiskach firmowych może być konieczne wyświetlenie administratorowi sieci informacji w tej sekcji, aby ułatwić otwieranie dodatkowych portów w warstwie sieci firmowej.
• Chociaż można dostosować punkt końcowy po stronie programu SQL Server, nie można zmienić ani dostosować numerów portów dla usługi SQL Managed Instance.
• Zakresy adresów IP podsieci hostowania wystąpień zarządzanych i programu SQL Server nie mogą się nakładać.

Dodawanie adresów URL do listy dozwolonych

W zależności od ustawień zabezpieczeń sieci może być konieczne dodanie adresów URL dla nazwy FQDN usługi SQL Managed Instance i niektórych punktów końcowych zarządzania zasobami używanych przez platformę Azure do listy dozwolonych.

Poniżej wymieniono zasoby, które powinny zostać dodane do listy dozwolonych:

• W pełni kwalifikowana nazwa domeny (FQDN) wystąpienia zarządzanego SQL. Na przykład: managedinstance1.6d710bcf372b.database.windows.net.
• Microsoft Entra Authority
• Identyfikator zasobu punktu końcowego firmy Microsoft Entra
• Punkt końcowy usługi Resource Manager
• Punkt końcowy usługi

Wykonaj kroki opisane w sekcji Konfigurowanie programu SSMS dla chmur dla instytucji rządowych, aby uzyskać dostęp do interfejsu narzędzi w programie SQL Server Management Studio (SSMS) i zidentyfikuj określone adresy URL zasobów w chmurze, które należy dodać do listy dozwolonych.

Testowanie łączności sieciowej

Dwukierunkowa łączność sieciowa między programem SQL Server i usługą SQL Managed Instance jest niezbędna, aby połączenie działało. Po otwarciu portów po stronie programu SQL Server i skonfigurowaniu reguły sieciowej grupy zabezpieczeń po stronie wystąpienia zarządzanego SQL przetestuj łączność przy użyciu programu SQL Server Management Studio (SSMS) lub języka Transact-SQL.

Przetestuj sieć, tworząc tymczasowe zadanie agenta SQL w programie SQL Server i usłudze SQL Managed Instance, aby sprawdzić połączenie między dwoma wystąpieniami. Gdy używasz narzędzia do sprawdzania sieci w programie SSMS, zadanie zostanie automatycznie utworzone i usunięte po zakończeniu testu. Jeśli testujesz sieć przy użyciu języka T-SQL, musisz ręcznie usunąć zadanie agenta SQL.

Uwaga

Wykonywanie skryptów programu PowerShell przez agenta programu SQL Server w programie SQL Server w systemie Linux nie jest obecnie obsługiwane, więc obecnie nie można wykonać Test-NetConnection zadania agenta programu SQL Server w programie SQL Server w systemie Linux.

Aby przetestować łączność sieciową przy użyciu agenta SQL, potrzebne są następujące wymagania:

• Użytkownik wykonujący test musi mieć uprawnienia do utworzenia zadania (jako administrator systemu lub należy do roli SQLAgentOperator dla msdbprogramu ) zarówno dla programu SQL Server, jak i usługi SQL Managed Instance.
• Usługa SQL Server Agent musi być uruchomiona w programie SQL Server. Ponieważ agent jest domyślnie włączony w usłudze SQL Managed Instance, nie jest wymagana żadna dodatkowa akcja.

SSMS

Aby przetestować łączność sieciową między programem SQL Server i usługą SQL Managed Instance w programie SSMS, wykonaj następujące kroki:

1. Połącz się z wystąpieniem, które będzie repliką podstawową w programie SSMS.

2. W Eksplorator obiektów rozwiń węzeł bazy danych, a następnie kliknij prawym przyciskiem myszy bazę danych, którą chcesz połączyć z pomocniczym. Wybierz pozycję Zadania>usługi Azure SQL Managed Instance link>Testuj połączenie, aby otworzyć kreatora sprawdzania sieci:

   

3. Wybierz przycisk Dalej na stronie Wprowadzenie kreatora sprawdzania sieci.

4. Jeśli wszystkie wymagania zostały spełnione na stronie Wymagania wstępne , wybierz pozycję Dalej. W przeciwnym razie rozwiąż wszelkie niezaspokojonych wymagań wstępnych, a następnie wybierz pozycję Uruchom ponownie walidację.

5. Na stronie Logowanie wybierz pozycję Zaloguj się, aby nawiązać połączenie z innym wystąpieniem, które będzie repliką pomocniczą. Wybierz Dalej.

6. Sprawdź szczegóły na stronie Określanie opcji sieciowych i w razie potrzeby podaj adres IP. Wybierz Dalej.

7. Na stronie Podsumowanie przejrzyj akcje podejmowane przez kreatora, a następnie wybierz pozycję Zakończ, aby przetestować połączenie między dwiema replikami.

8. Przejrzyj stronę Wyniki, aby sprawdzić, czy łączność istnieje między dwiema replikami, a następnie wybierz pozycję Zamknij, aby zakończyć.

T-SQL

Aby przetestować łączność przy użyciu języka T-SQL, należy sprawdzić połączenie w obu kierunkach. Najpierw przetestuj połączenie z programu SQL Server do usługi SQL Managed Instance, a następnie przetestuj połączenie z usługi SQL Managed Instance do programu SQL Server.

Testowanie połączenia z programu SQL Server do usługi SQL Managed Instance

Użyj programu SQL Server Agent w programie SQL Server, aby uruchomić testy łączności z programu SQL Server do usługi SQL Managed Instance.

1. Połącz się z usługą SQL Managed Instance i uruchom następujący skrypt, aby wygenerować parametry potrzebne później:

   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';
   

   Wyniki powinny wyglądać podobnie do następującego przykładu:

   

   Zapisz wyniki, aby wykonać następne kroki. Ponieważ te parametry mogą ulec zmianie po przejściu w tryb failover, pamiętaj, aby wygenerować je ponownie, jeśli to konieczne.

2. Nawiązywanie połączenia z programem SQL Server.

3. Otwórz nowe okno zapytania i wklej następujący skrypt:

   --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
   

4. Zastąp @nodeparametry , @porti @serverName wartościami uzyskanymi w pierwszym kroku.

5. Uruchom skrypt i sprawdź wyniki. Powinny zostać wyświetlone wyniki, takie jak poniższy przykład:

   

6. Sprawdź wyniki:

   • Wynik każdego testu w tcpTestSucceeded powinien mieć wartość TcpTestSucceeded : True.
   • Adresy zdalne powinny należeć do zakresu adresów IP dla podsieci wystąpienia zarządzanego SQL.

   Jeśli odpowiedź nie powiedzie się, sprawdź następujące ustawienia sieciowe:

   • Istnieją reguły zarówno w zaporze sieciowej, jak i zaporze systemu operacyjnego hosta programu SQL Server (Windows/Linux), która umożliwia ruch do całego zakresu adresów IP podsieci usługi SQL Managed Instance.
   • Istnieje reguła sieciowej grupy zabezpieczeń, która zezwala na komunikację na porcie 5022 dla sieci wirtualnej, która hostuje usługę SQL Managed Instance.

Testowanie połączenia z usługi SQL Managed Instance do programu SQL Server

Aby sprawdzić, czy usługa SQL Managed Instance może nawiązać połączenie z programem SQL Server, najpierw utwórz testowy punkt końcowy. Następnie użyjesz agenta programu SQL Server, aby uruchomić skrypt programu PowerShell za tnc pomocą polecenia pingowania programu SQL Server na porcie 5022 z wystąpienia zarządzanego SQL.

Aby utworzyć testowy punkt końcowy, połącz się z programem SQL Server i uruchom następujący skrypt języka 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
    )

Aby sprawdzić, czy punkt końcowy programu SQL Server odbiera połączenia na porcie 5022, uruchom następujące polecenie programu PowerShell w systemie operacyjnym hosta wystąpienia programu SQL Server:

tnc localhost -port 5022

Pomyślny test pokazuje wartość TcpTestSucceeded : True. Następnie możesz utworzyć zadanie agenta programu SQL Server w wystąpieniu zarządzanym SQL, aby spróbować przetestować testowy punkt końcowy programu SQL Server na porcie 5022 z wystąpienia zarządzanego SQL.

Następnie utwórz zadanie agenta programu SQL Server w wystąpieniu zarządzanym SQL o nazwie NetHelper , uruchamiając następujący skrypt języka T-SQL w wystąpieniu zarządzanym SQL. Wymiana:

• <SQL_SERVER_IP_ADDRESS> z adresem IP programu SQL Server, do którego można uzyskać dostęp z wystąpienia zarządzanego 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)';

Napiwek

Jeśli musisz zmodyfikować adres IP programu SQL Server dla sondy łączności z wystąpienia zarządzanego SQL, usuń zadanie NetHelper, uruchamiając EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'polecenie i ponownie utwórz zadanie NetHelper przy użyciu poprzedniego skryptu.

Następnie utwórz procedurę ExecuteNetHelper składowaną, która ułatwia uruchamianie zadania i uzyskuje wyniki z sondy sieciowej. Uruchom następujący skrypt języka T-SQL w wystąpieniu zarządzanym 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;

Uruchom następujące zapytanie w wystąpieniu zarządzanym SQL, aby wykonać procedurę składowaną, która wykona zadanie agenta NetHelper i wyświetli wynikowy dziennik:

-- Run on managed instance
EXEC ExecuteNetHelper;

Jeśli połączenie zakończyło się pomyślnie, w dzienniku jest wyświetlany komunikat True. Jeśli połączenie nie powiodło się, w dzienniku jest wyświetlana wartość False.

Jeśli połączenie nie powiodło się, sprawdź następujące elementy:

• Zapora na hoście wystąpienia programu SQL Server zezwala na komunikację przychodzącą i wychodzącą na porcie 5022.
• Reguła sieciowej grupy zabezpieczeń dla sieci wirtualnej, która hostuje usługę SQL Managed Instance, umożliwia komunikację na porcie 5022.
• Jeśli wystąpienie programu SQL Server znajduje się na maszynie wirtualnej platformy Azure, reguła sieciowej grupy zabezpieczeń zezwala na komunikację na porcie 5022 w sieci wirtualnej, która hostuje maszynę wirtualną.
• Program SQL Server jest uruchomiony.
• W programie SQL Server istnieje testowy punkt końcowy.

Po rozwiązaniu problemów ponownie uruchom sondę sieci NetHelper, uruchamiając polecenie EXEC ExecuteNetHelper w wystąpieniu zarządzanym.

Na koniec po pomyślnym zakończeniu testu sieciowego upuść punkt końcowy testu i certyfikat w programie SQL Server przy użyciu następujących poleceń języka T-SQL:

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

Uwaga

Wykonaj kolejne kroki tylko wtedy, gdy sprawdzono łączność sieciową między środowiskami źródłowymi i docelowymi. W przeciwnym razie przed kontynuowaniem rozwiąż problemy z łącznością sieciową.

Migrowanie certyfikatu bazy danych chronionej przez funkcję TDE (opcjonalnie)

Jeśli łączysz bazę danych programu SQL Server chronioną przez funkcję Transparent Data Encryption (TDE) z wystąpieniem zarządzanym, przed użyciem linku musisz przeprowadzić migrację odpowiedniego certyfikatu szyfrowania z wystąpienia lokalnego lub wystąpienia programu SQL Server maszyny wirtualnej platformy Azure do wystąpienia zarządzanego. Aby uzyskać szczegółowe instrukcje, zobacz Migrowanie certyfikatu bazy danych chronionej przez funkcję TDE do usługi Azure SQL Managed Instance.

Bazy danych usługi SQL Managed Instance szyfrowane za pomocą kluczy TDE zarządzanych przez usługę nie mogą być połączone z programem SQL Server. Zaszyfrowaną bazę danych można połączyć z programem SQL Server tylko wtedy, gdy została zaszyfrowana przy użyciu klucza zarządzanego przez klienta, a serwer docelowy ma dostęp do tego samego klucza, który jest używany do szyfrowania bazy danych. Aby uzyskać więcej informacji, zobacz Konfigurowanie funkcji TDE programu SQL Server za pomocą usługi Azure Key Vault.

Uwaga

Usługa Azure Key Vault jest obsługiwana przez program SQL Server w systemie Linux, począwszy od programu SQL Server 2022 CU 14.

Instalowanie programu SSMS

Program SQL Server Management Studio (SSMS) to najprostszy sposób korzystania z linku wystąpienia zarządzanego. Pobierz program SSMS w wersji 19.0 lub nowszej i zainstaluj go na komputerze klienckim.

Po zakończeniu instalacji otwórz program SSMS i połącz się z obsługiwanym wystąpieniem programu SQL Server. Kliknij prawym przyciskiem myszy bazę danych użytkownika i sprawdź, czy w menu jest wyświetlana opcja linku usługi Azure SQL Managed Instance.

Konfigurowanie programu SSMS dla chmur dla instytucji rządowych

Jeśli chcesz wdrożyć usługę SQL Managed Instance w chmurze dla instytucji rządowych, musisz zmodyfikować ustawienia programu SQL Server Management Studio (SSMS), aby używać odpowiedniej chmury. Jeśli nie wdrażasz wystąpienia zarządzanego SQL w chmurze dla instytucji rządowych, pomiń ten krok.

Aby zaktualizować ustawienia programu SSMS, wykonaj następujące kroki:

1. Otwórz program SSMS.
2. Z menu wybierz pozycję Narzędzia , a następnie wybierz pozycję Opcje.
3. Rozwiń węzeł Usługi platformy Azure i wybierz pozycję Azure Cloud.
4. W obszarze Wybierz chmurę platformy Azure użyj listy rozwijanej, aby wybrać pozycję AzureUSGovernment lub inną chmurę dla instytucji rządowych, taką jak AzureChinaCloud:

Jeśli chcesz wrócić do chmury publicznej, wybierz pozycję AzureCloud z listy rozwijanej.

Powiązana zawartość

Aby użyć linku:

• Konfigurowanie połączenia między programem SQL Server i wystąpieniem zarządzanym SQL za pomocą programu SSMS
• Konfigurowanie połączenia między programem SQL Server i wystąpieniem zarządzanym SQL za pomocą skryptów
• Przełącz łącze w tryb failover
• Migrowanie za pomocą linku
• Najlepsze rozwiązania dotyczące obsługi linku

Aby dowiedzieć się więcej na temat linku:

• Omówienie linku wystąpienia zarządzanego
• Połączenie odzyskiwania po awarii z wystąpieniem zarządzanym

W przypadku innych scenariuszy replikacji i migracji należy wziąć pod uwagę następujące kwestie:

• Replikacja transakcyjna za pomocą usługi SQL Managed Instance
• Usługa ponownego odtwarzania dziennika (LRS)