Przygotowywanie środowiska do migracji linków wystąpienia zarządzanego — migracja programu SQL Server w usłudze Azure Arc

Dotyczy:SQL Server

Ten artykuł ułatwia przygotowanie środowiska do migracji linków wystąpienia zarządzanego dla wystąpienia programu SQL Server włączonego przez usługę Azure Arc do usługi Azure SQL Managed Instance w witrynie Azure Portal.

Za pomocą linku możesz migrować bazy danych programu SQL Server do usługi Azure SQL Managed Instance przy użyciu replikacji w czasie rzeczywistym z rozproszoną grupą dostępności (migracja online):

Wymagania wstępne

Aby przeprowadzić migrację baz danych programu SQL Server do usługi Azure SQL Managed Instance za pośrednictwem witryny Azure Portal, potrzebne są następujące wymagania wstępne:

• Aktywna subskrypcja platformy Azure. Jeśli jej nie masz, utwórz bezpłatne konto.
• Obsługiwane wystąpienie programu SQL Server włączone przez usługę Azure Arc z rozszerzeniem platformy Azure dla wersji 1.1.3238.349 programu SQL Server lub nowszej. Rozszerzenie można uaktualnić przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.

Obsługiwane wersje programu SQL Server

Zarówno warstwa Ogólnego przeznaczenia, jak i warstwa Krytyczna dla biznesu w Azure SQL Managed Instance obsługują połączenie wystąpienia zarządzanego. Migracja za pomocą funkcji linku działa z wersjami Enterprise, Developer i Standard programu SQL Server w systemie Windows Server.

W poniższej tabeli wymieniono minimalną obsługiwaną wersję programu SQL Server dla linku:

Migracja odwrotna jest obsługiwana tylko w programach SQL Server 2025 i SQL Server 2022 z wystąpień zarządzanych SQL z odpowiednimi zasadami aktualizacji. Migrację można ręcznie odwrócić za pomocą innych narzędzi, takich jak natywna kopia zapasowa i przywracanie, lub ręcznie skonfigurować link w programie SSMS.

Permissions

W tej sekcji opisano uprawnienia, które należy migrować wystąpienie programu SQL Server do usługi SQL Managed Instance za pośrednictwem witryny Azure Portal.

W źródłowym wystąpieniu programu SQL Server potrzebne są następujące uprawnienia:

• Jeśli włączysz najmniejsze uprawnienia, niezbędne uprawnienia, takie jak sysadmin , są przyznawane zgodnie z potrzebami podczas procesu migracji bazy danych.
• Jeśli nie możesz użyć najniższych uprawnień, osoba wykonująca migrację wymaga uprawnień administratora systemu w źródłowym wystąpieniu programu SQL Server. Ponadto, jeśli musisz anulować migrację, również ręcznie przypisz uprawnienia administratora systemu do NT AUTHORITY\SYSTEM konta.

Aby przeprowadzić migrację za pomocą linku wystąpienia zarządzanego, musisz mieć jedno z następujących uprawnień w docelowym wystąpieniu zarządzanym SQL:

• Rola uczestnika zarządzanej instancji SQL
• Rola współautora lub właściciela na poziomie subskrypcji

Aby uzyskać minimalne uprawnienia, zobacz Uprawnienia niestandardowe.

Przygotowywanie wystąpienia programu SQL Server

Aby przygotować wystąpienie programu SQL Server, wykonaj następujące kroki:

• Sprawdź, czy korzystasz z obsługiwanej wersji.
• Utwórz klucz główny bazy danych w master bazie danych.
• Włącz funkcję grup dostępności.
• Dodaj odpowiednie flagi śledzenia podczas uruchamiania.
• Uruchom ponownie program SQL Server i zweryfikuj konfigurację.
• Ustaw bazę danych na pełny model odzyskiwania.
• Zaimportuj zaufane klucze głównego urzędu certyfikacji platformy Azure do programu SQL Server.

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 bazie danych master

Link używa certyfikatów do szyfrowania uwierzytelniania i komunikacji między programem SQL Server i usługą SQL Managed Instance. Klucz główny bazy danych chroni certyfikaty używane przez łącze. Jeśli masz już klucz główny bazy danych, możesz pominąć ten krok.

Utwórz klucz główny bazy danych w master bazie danych. 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%';

Przygotowywanie wystąpień programu SQL Server 2016

W przypadku programu SQL Server 2016 (13.x) należy wykonać dodatkowe kroki opisane w artykule Przygotowywanie wymagań wstępnych programu SQL Server 2016 dla linku. Te dodatkowe kroki nie są wymagane w przypadku programu SQL Server 2017 (14.x) i nowszych wersji obsługiwanych przez łącze.

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 Grup dostępności Always On.

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'

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

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ę PROGRAMU SQL Server, a następnie wybierz polecenie Właściwości:

   

4. Przejdź do zakładki Always On Availability Groups.

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 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 kroki opisane w artykule Przygotowywanie wymagań wstępnych programu SQL Server 2016 dla linku. Po wykonaniu tych kroków wróć do tego kroku i spróbuj ponownie.

6. Wybierz przycisk OK w oknie dialogowym.

7. Uruchom ponownie usługę SQL Server.

Włącz flagi śledzenia uruchamiania

Aby zoptymalizować wydajność linku, włącz następujące flagi śledzenia podczas uruchamiania:

• -T1800: Flaga śledzenia optymalizuje wydajność, gdy pliki dzienników dla głównych i pomocniczych replik w grupie dostępności są umieszczone 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 używają rozmiaru sektora dysku o rozmiarze 4 KB, nie potrzebujesz tej flagi śledzenia. 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 seedowania.

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 pozycję 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ę włączenia flag śledzenia.

Uruchom ponownie program SQL Server i zweryfikuj konfigurację

Jeśli nie trzeba uaktualnić wersji programu SQL Server, włączyć funkcję grupy dostępności lub dodać flagi śledzenia uruchamiania, możesz pominąć tę sekcję.

Po upewnieniu się, że korzystasz z obsługiwanej wersji programu SQL Server, włącz funkcję grupy dostępności Always On i dodaj flagi śledzenia uruchamiania, a następnie 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 z zastosowanymi odpowiednimi aktualizacjami usługi. Funkcja Always On availability groups powinna być włączona, a flagi śledzenia -T1800 oraz -T9567 powinny być aktywowane. Poniższy zrzut ekranu to przykład oczekiwanego wyniku dla prawidłowo skonfigurowanego wystąpienia programu SQL Server:

Ustawianie bazy danych na model pełnego odzyskiwania

Bazy danych migrowane za pośrednictwem linku muszą znajdować się w modelu pełnego odzyskiwania i mieć co najmniej jedną kopię zapasową.

Uruchom następujący kod w programie SQL Server dla wszystkich baz danych, które chcesz zmigrować. Zastąp <DatabaseName> wartość rzeczywistą nazwą bazy danych.

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

Importowanie zaufanych kluczy głównego urzędu certyfikacji platformy Azure do programu SQL Server

Aby ufać certyfikatom kluczy publicznych usługi SQL Managed Instance, które występują na platformie Azure, należy zaimportować klucze głównego urzędu certyfikacji (CA) zaufanego platformy Azure do programu SQL Server.

Klucze głównego urzędu certyfikacji można pobrać ze szczegółowych informacji o urzędzie certyfikacji Azure. Przynajmniej pobierz certyfikaty DigiCert Global Root G2 i Microsoft RSA Root Certificate Authority 2017 oraz zaimportuj je do instancji SQL Server.

Zapisz certyfikaty lokalne w wystąpieniu programu SQL Server, na przykład w przykładowej C:\certs\<name of certificate>.crt ścieżce, a następnie zaimportuj certyfikaty z tej ścieżki przy użyciu następującego skryptu Transact-SQL. Zastąp <name of certificate> rzeczywistą nazwą certyfikatu: DigiCert Global Root G2 i Microsoft RSA Root Certificate Authority 2017, które są wymaganymi nazwami tych dwóch certyfikatów.

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

Na koniec sprawdź wszystkie utworzone certyfikaty przy użyciu następującego dynamicznego widoku zarządzania (DMV):

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

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 poza platformą Azure

Jeśli hostujesz wystąpienie programu SQL Server poza platformą Azure, możesz ustanowić 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 VPN między lokalizacjami
• Połączenie usługi Azure ExpressRoute

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 automatycznie istnieje 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 SQL, musisz połączyć te dwie sieci wirtualne. Sieci wirtualne nie muszą znajdować się w tej samej subskrypcji, aby ten scenariusz działał.

Dostępne są 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. 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. Peering sieci wirtualnych jest obsługiwany między sieciami w tym samym regionie. Globalne równorzędne połączenia sieci wirtualnych są obsługiwane dla instancji hostowanych w podsieciach utworzonych po 22 września 2020 r. Aby uzyskać więcej informacji, zobacz Często zadawane pytania.

Porty sieciowe między środowiskami

Niezależnie od mechanizmu łączności, należy spełnić następujące wymagania dotyczące ruchu sieciowego do przepływu między środowiskami:

Reguły grupy zabezpieczeń sieciowych (NSG) w podsieci hostującej SQL Managed Instance 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

Nie można zmienić portu 5022 w usłudze SQL Managed Instance.

Wszystkie zapory w sieci hostujące program SQL Server, a system operacyjny hosta musi zezwalać na:

• Port wejściowy 5022 został otwarty w celu odbierania ruchu ze źródłowego zakresu adresów IP podsieci MI /24 (na przykład 10.0.0.0/24)
• Porty wychodzące 5022 oraz zakres portów 11000-11999 zostały otwarte do wysyłania ruchu do docelowego zakresu adresów IP w podsieci MI (na przykład 10.0.0.0/24).

Port 5022 można dostosować po stronie programu SQL Server, ale zakres portów 11000-11999 musi być otwarty w następujący sposób.

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

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

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, która hostuje wystąpienie programu SQL Server, oraz wszystkie zapory i bramy firmowe:

Dodawanie adresów URL do listy dozwolonych

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

Dodaj następujące zasoby do listy dozwolonych:

• Pełna kwalifikowana nazwa domeny (FQDN) dla zarządzanego wystąpienia SQL. Na przykład: managedinstance.a1b2c3d4e5f6.database.windows.net.
• Microsoft Entra Authority
• Identyfikator zasobu końcowego Microsoft Entra
• Punkt końcowy usługi Resource Manager
• Punkt końcowy usługi

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

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 SQL, 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 SQL. 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ć tylko z programem SQL Server, jeśli zaszyfrowano ją przy użyciu klucza zarządzanego przez klienta, a serwer docelowy ma dostęp do tego samego klucza używanego do szyfrowania bazy danych. Aby uzyskać więcej informacji, zobacz Konfigurowanie funkcji TDE programu SQL Server za pomocą usługi Azure Key Vault.

Testowanie łączności sieciowej

Przed rozpoczęciem migracji przetestuj łączność sieciową między wystąpieniem programu SQL Server i usługą SQL Managed Instance. Łączność można przetestować bezpośrednio z witryny Azure Portal w ramach procesu migracji. Można jednak również ręcznie przetestować łączność przy użyciu Transact-SQL i agenta programu SQL Server. Aby uzyskać więcej informacji, zobacz Testowanie łączności sieciowej.

Aby przetestować łączność za pośrednictwem witryny Azure Portal, wykonaj następujące kroki:

1. Wybierz pozycję Migruj dane w okienku Migracja bazy danych dla zasobu wystąpienia programu SQL Server.

2. Wybierz opcję MI link.

3. Wybierz docelowe bazy danych, które chcesz zmigrować, a następnie użyj pozycji Dalej: Ustawienia , aby przejść do następnej karty.

4. Na karcie Ustawienia podaj nazwę linku i źródłową grupę dostępności. Następnie użyj opcji Testuj połączenie , aby zweryfikować łączność sieciową między programem SQL Server i wystąpieniem zarządzanym SQL:

   

Rozważ następujące kwestie:

• Aby uniknąć wyników fałszywie ujemnych, wszystkie zapory wzdłuż ścieżki sieciowej muszą zezwalać na ruch protokołu ICMP (Internet Control Message Protocol).
• Aby uniknąć wyników fałszywie dodatnich, wszystkie zapory wzdłuż ścieżki sieciowej muszą zezwalać na ruch na zastrzeżonym protokole UCS programu SQL Server. Zablokowanie protokołu może prowadzić do pomyślnego testu połączenia, ale nie udaje się utworzyć połączenia.
• Aby zezwolić na ruch między programem SQL Server i usługą SQL Managed Instance, należy prawidłowo skonfigurować zaawansowane konfiguracje zapory z zabezpieczeniami na poziomie pakietów.

Ograniczenia

Rozważ następujące ograniczenia:

• Ograniczenia łącza Wystąpienia Zarządzanego dotyczą migracji za pośrednictwem portalu Azure.
• Anulowanie migracji wymaga uprawnień administratora systemu w źródłowym wystąpieniu programu SQL Server. Jeśli wystąpienie programu SQL Server nie korzysta z najniższych uprawnień, ręcznie przypisz uprawnienia sysadmin do NT AUTHORITY\SYSTEM konta.
• Konfigurowanie linku za pośrednictwem witryny Azure Portal do celów migracji nie jest zgodne z linkami utworzonymi ręcznie, za pomocą programu SQL Server Management Studio (SSMS) lub Transact-SQL (T-SQL). Zapoznaj się ze znanym problemem , aby dowiedzieć się więcej.
• Monitorowanie migracji za pośrednictwem witryny Azure Portal jest dostępne tylko dla wystąpień programu SQL Server spełniających wymagania dotyczące licencjonowania monitorowania.

Rozwiązywanie typowych problemów

Aby rozwiązać typowe problemy podczas migracji do usługi Azure SQL Managed Instance, zobacz Rozwiązywanie problemów z migracją.

Treści powiązane

• Zalecane praktyki dotyczące linków Managed Instance
• Migracja programu SQL Server w usłudze Azure Arc
• Przygotowywanie środowiska do migracji LRS
• Omówienie programu SQL Server włączonego przez usługę Azure Arc
• Przekaż opinie dotyczące migracji bezpośrednio do grupy produktu
• Migracja do usługi Azure SQL Managed Instance — migracja programu SQL Server w usłudze Azure Arc