Vorbereiten Ihrer Umgebung für einen Managed Instance-Link: Azure SQL Managed Instance

Gilt für: Azure SQL Managed Instance

In diesem Artikel erfahren Sie, wie Sie Ihre Umgebung für einen Managed Instance-Link vorbereiten, um aus dem SQL Server auf Windows oder Linux und Azure SQL Managed Instance replizieren zu können.

Hinweis

Sie können die Vorbereitung Ihrer Umgebung für den Managed Instance-Link mit Hilfe eines herunterladbaren Skripts automatisieren. Weitere Informationen finden Sie im Blog Automatisieren der Link-Setup-Einrichtung.

Voraussetzungen

Um einen Link zwischen SQL Server und Azure SQL Managed Instance zu erstellen ist Folgendes erforderlich:

• Eine aktive Azure-Subscription. Falls Sie nicht über ein Abonnement verfügen, können Sie ein kostenloses Konto erstellen.
• Unterstützte Version von SQL Server mit erforderlichem Dienstupdate
• Azure SQL Managed Instance. Erstellen Sie eine verwaltete Azure SQL-Instanz, falls Sie noch nicht über eine Instanz verfügen.
• Entscheiden Sie, welcher Server zunächst als primärer Server dienen soll, um zu bestimmen, von wo aus Sie den Link erstellen sollten.
  • Das Konfigurieren einer Verknüpfung von der primären SQL Managed Instance zur sekundären SQL Server-Instanz wird erst ab dem SQL Server 2022 CU10 und von Instances unterstützt, die mit der SQL Server 2022 Update-Richtlinie konfiguriert wurden.

Achtung

Wenn Sie Ihre verwaltete SQL Managed-Instance für die Verwendung mit dem Linkfeature erstellen, werden die Speicheranforderungen für alle von SQL Server verwendeten In-Memory-OLTP-Features berücksichtigt. Weitere Informationen finden Sie unter Übersicht über Ressourceneinschränkungen für Azure SQL Managed Instance.

Berechtigungen

Für SQL Server sollten Sie über sysadmin-Berechtigungen verfügen.

Für Azure SQL Managed Instance sollten Sie Mitglied der Rolle Mitwirkender für verwaltete SQL-Instanzen sein oder über die folgenden Berechtigungen für eine benutzerdefinierte Rolle verfügen:

Microsoft.Sql/resource	Erforderliche Berechtigungen
Microsoft.Sql/managedInstances	/read, /write
Microsoft.Sql/managedInstances/hybridCertificate	/action
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

Vorbereiten der SQL Server-Instanz

Vergewissern Sie sich zur Vorbereitung Ihrer SQL Server-Instanz, dass Folgendes zutrifft:

• Sie verwenden die unterstützte Mindestversion.
• Sie haben das Verfügbarkeitsgruppenfeature aktiviert.
• Sie haben die richtigen Ablaufverfolgungsflags beim Start hinzugefügt.
• Ihre Datenbanken befinden sich im vollständigen Wiederherstellungsmodell und wurden gesichert.

Sie müssen SQL Server neu starten, damit diese Änderungen wirksam werden.

Installieren von Dienstupdates

Vergewissern Sie sich, dass auf Ihrer SQL Server-Version das entsprechende Wartungsupdate installiert ist, wie in der folgenden Tabelle der Versionsunterstützung aufgeführt. Wenn Sie Updates installieren, müssen Sie Ihre SQL Server-Instanz während des Updates neu starten.

Führen Sie das folgende Transact-SQL-Skript (T-SQL) in SQL Server aus, um zu überprüfen, welche SQL Server-Version Sie verwenden:

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

Erstellen eines Datenbankhauptschlüssels in der master-Datenbank

Erstellen Sie den Hauptschlüssel der Datenbank in der master-Datenbank, falls noch keiner vorhanden ist. Geben Sie Ihr Kennwort anstelle von <strong_password> in das nachfolgende Skript ein, und bewahren Sie es an einem vertraulichen und sicheren Ort auf. Führen Sie dieses T-SQL-Skript unter SQL Server aus:

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

Verwenden Sie das folgende T-SQL-Skript in SQL Server, um sich zu vergewissern, dass Sie über den Datenbankhauptschlüssel verfügen:

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

Aktivieren von Verfügbarkeitsgruppen

Das Linkfeature basiert auf der Funktion für Always On-Verfügbarkeitsgruppen, die standardmäßig deaktiviert ist. Weitere Informationen finden Sie unter Aktivieren des Features für Always On-Verfügbarkeitsgruppen.

Hinweis

Für SQL Server auf Linux siehe Always On-Verfügbarkeitsgruppen aktivieren.

Führen Sie das folgende T-SQL-Skript in SQL Server aus, um sich zu vergewissern, dass die Funktion Verfügbarkeitsgruppen aktiviert ist:

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

Wichtig

Wenn Sie für SQL Server 2016 (13.x) das Feature „Verfügbarkeitsgruppen“ aktivieren müssen, müssen Sie zusätzliche Schritte durchführen, die unter Vorbereiten der SQL Server 2016-Voraussetzungen - Azure SQL Managed Instance-Link dokumentiert sind. Diese zusätzlichen Schritte sind für SQL Server 2019 (15.x) und spätere Versionen, die von dem Link unterstützt werden, nicht erforderlich.

Wenn das Feature für Verfügbarkeitsgruppen nicht aktiviert ist, führen Sie die folgenden Schritte aus, um es zu aktivieren:

1. Öffnen Sie den SQL Server-Konfigurations-Manager.

2. Wählen Sie im linken Bereich SQL Server-Dienste aus.

3. Klicken Sie mit der rechten Maustaste auf den SQL Server-Dienst, und wählen Sie Eigenschaften aus.

   

4. Wechseln Sie zur Registerkarte Always On-Verfügbarkeitsgruppen.

5. Aktivieren Sie das Kontrollkästchen Always On-Verfügbarkeitsgruppen aktivieren, und wählen Sie anschließend OK aus.

   

   • Wenn Sie SQL Server 2016 (13.x) verwenden und die Option Always-On-Verfügbarkeitsgruppen aktivieren mit der Meldung This computer is not a node in a failover cluster. deaktiviert ist, führen Sie die zusätzlichen Schritte aus, die unter Vorbereitung der SQL Server 2016-Voraussetzungen - Azure SQL Managed Instance-Link beschrieben sind. Wenn Sie diese anderen Schritte abgeschlossen haben, kommen Sie zurück und wiederholen Sie diesen Schritt.

6. Wählen Sie im Dialogfeld OK aus.

7. Starten Sie den SQL Server-Dienst neu.

Aktivieren von Flags für die Ablaufverfolgung beim Starten

Um die Leistung Ihres Links zu optimieren, empfiehlt es sich, beim Start die folgenden Ablaufverfolgungs-Flags zu aktivieren:

• -T1800: Mit diesem Ablaufverfolgungsflag wird die Leistung für den Fall verbessert, dass die Protokolldateien für das primäre und das sekundäre Replikat in einer Verfügbarkeitsgruppe auf Datenträgern gehostet werden, die unterschiedliche Sektorgrößen aufweisen, z. B. 512 Bytes und 4 KB. Wenn die Sektorgröße des Datenträgers sowohl für das primäre als auch für das sekundäre Replikat 4 KB beträgt, ist dieses Ablaufverfolgungsflag nicht erforderlich. Weitere Informationen finden Sie unter KB3009974.
• -T9567: Dieses Ablaufverfolgungsflag aktiviert die Komprimierung des Datenstroms für Verfügbarkeitsgruppen während des automatischen Seedings. Die Komprimierung erhöht die Auslastung des Prozessors, kann jedoch die Übertragungszeit während des Seedings erheblich reduzieren.

Hinweis

Für SQL Server auf Linux siehe Ablaufverfolgungsflags aktivieren.

Führen Sie die folgenden Schritte aus, um diese Ablaufverfolgungsflags beim Start zu aktivieren:

1. Öffnen Sie den SQL Server-Konfigurations-Manager.

2. Wählen Sie im linken Bereich SQL Server-Dienste aus.

3. Klicken Sie mit der rechten Maustaste auf den SQL Server-Dienst, und wählen Sie Eigenschaften aus.

   

4. Wechseln Sie zur Registerkarte Startparameter. Geben Sie unter Startparameter angeben -T1800 ein, und wählen Sie Hinzufügen aus, um den Startparameter hinzuzufügen. Geben Sie dann -T9567 ein, und wählen Sie Hinzufügen aus, um das andere Ablaufverfolgungsflag hinzuzufügen. Wählen Sie Übernehmen aus, um die Änderungen zu speichern.

   

5. Wählen Sie OK aus, um das Fenster Eigenschaften zu schließen.

Weitere Informationen finden Sie in der Syntax zum Aktivieren von Ablaufverfolgungs-Flags.

Neustarten von SQL Server und Überprüfen der Konfiguration

Nachdem Sie sichergestellt haben, dass Sie eine unterstützte Version von SQL Server verwenden, sowie das Feature für Always On-Verfügbarkeitsgruppen aktiviert und die Flags für die Ablaufverfolgung beim Starten hinzugefügt haben, starten Sie Ihre SQL Server-Instanz neu, um alle Änderungen anzuwenden:

1. Öffnen Sie den SQL Server-Konfigurations-Manager.

2. Wählen Sie im linken Bereich SQL Server-Dienste aus.

3. Klicken Sie mit der rechten Maustaste auf den SQL Server-Dienst, und wählen Sie Neu starten aus.

   

Führen Sie nach dem Neustart das folgende T-SQL-Skript in SQL Server aus, um die Konfiguration Ihrer SQL Server-Instanz zu überprüfen:

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

Ihre SQL Server-Version sollte eine der unterstützten Versionen mit angewandten Dienstupdates sein, die Funktionen Always On-Verfügbarkeitsgruppen sollte aktiviert sein, und Sie sollten die Ablaufverfolgungs-Flags -T1800 und -T9567 aktiviert haben. Der folgende Screenshot zeigt ein Beispiel für das erwartete Ergebnis bei einer ordnungsgemäß konfigurierten SQL Server-Instanz:

Konfigurieren der Netzwerkverbindung

Damit der Link funktioniert, muss zwischen SQL Server und SQL Managed Instance eine Netzwerkverbindung bestehen. Die von Ihnen ausgewählte Netzwerkoption hängt davon ab, ob sich Ihre SQL Server-Instanz in einem Azure-Netzwerk befindet.

SQL Server auf Azure-VMs

Am einfachsten ist es, SQL Server auf Azure Virtual Machines im gleichen virtuellen Azure-Netzwerk bereitzustellen, in dem auch SQL Managed gehostet wird, da so automatisch Netzwerkkonnektivität zwischen den beiden Instanzen besteht. Weitere Informationen finden Sie unter Schnellstart: Konfigurieren einer Azure-VM für das Herstellen einer Verbindung mit Azure SQL Managed Instance.

Wenn sich Ihre SQL Server auf Azure Virtual Machines-Instanz in einem anderen virtuellen Netzwerk befindet als Ihre verwaltete Instanz, müssen Sie eine Verbindung zwischen beiden virtuellen Netzwerken herstellen. Die virtuelle Netzwerke müssen für dieses Szenario nicht demselben Abonnement angehören.

Es gibt zwei Optionen zum Verbinden virtueller Netzwerke:

• Peering in virtuellen Azure-Netzwerken
• VNET-zu-VNET-VPN-Gateway (Azure-Portal, PowerShell, Azure CLI)

Dabei ist Peering vorzuziehen, da dabei das Microsoft-Backbonenetzwerk verwendet wird, sodass es im Hinblick auf die Konnektivität keinen spürbaren Unterschied bei der Latenz zwischen virtuellen Computern im Peering-VNET und im selben VNET gibt. Das Peering virtueller Netzwerke wird zwischen Netzwerken in der gleichen Region unterstützt. Das globale Peering virtueller Netzwerke wird für Instanzen unterstützt, die in Subnetzen gehostet werden, die ab dem 22. September 2020 erstellt wurden. Weitere Informationen finden Sie unter Häufig gestellte Fragen (FAQ).

SQL Server außerhalb von Azure

Wenn Ihre SQL Server-Instanz außerhalb von Azure gehostet wird, stellen Sie mithilfe einer der folgenden Optionen eine VPN-Verbindung zwischen SQL Server und SQL Managed Instance her:

• Site-to-Site-VPN-Verbindung
• Azure ExpressRoute-Verbindung

Tipp

Wir empfehlen ExpressRoute, um beim Replizieren von Daten die bestmögliche Netzwerkleistung zu erzielen. Stellen Sie ein Gateway mit genügend Bandbreite für Ihren Anwendungsfall bereit.

Netzwerkports zwischen den Umgebungen

Unabhängig vom Mechanismus der Netzwerkkonnektivität müssen bestimmte Anforderungen erfüllt sein, damit der Datenverkehr zwischen den Umgebungen fließen kann:

Die Regeln der Netzwerksicherheitsgruppe (NSG) in dem Subnetz, das die verwaltete Instanz hostet, müssen zugelassen werden:

• Eingehender Port 5022 und Portbereich 11000–11999 zum Empfangen von Datenverkehr von der SQL Server-Quell-IP-Adresse
• Ausgehender Port 5022 zum Senden von Datenverkehr an die SQL Server-Ziel-IP-Adresse

Alle Firewalls des Netzwerks, in dem SQL Server gehostet wird, und des Hostbetriebssystems müssen Folgendes zulassen:

• Offener eingehender Port 5022 zum Empfang von Datenverkehr aus dem Quell-IP-Adressbereich des /24-Subnetzes der verwalteten Instanz (z. B. 10.0.0.0/24)
• Offener ausgehender Port 5022 und Portbereich 11000–11999 zum Senden von Datenverkehr an den Ziel-IP-Adressbereich des Subnetzes der verwalteten Instanz (z. B. 10.0.0.0/24)

In der folgenden Tabelle werden Portaktionen für die einzelnen Umgebungen beschrieben:

Environment	Aktion
SQL Server (in Azure)	Öffnen Sie für die Netzwerkfirewall sowohl eingehenden als auch ausgehenden Datenverkehr am Port 5022 für den gesamten IP-Adressbereich des Subnetzes von SQL Managed Instance. Führen Sie diesen Schritt bei Bedarf auch für die Firewall des SQL Server-Hostbetriebssystems (Windows/Linux) aus. Um die Kommunikation über Port 5022 zu ermöglichen, erstellen Sie eine NSG-Regel (Network Security Group) in dem virtuellen Netzwerk, in dem die VM gehostet wird.
SQL Server (außerhalb von Azure)	Öffnen Sie für die Netzwerkfirewall sowohl eingehenden als auch ausgehenden Datenverkehr am Port 5022 für den gesamten IP-Adressbereich des Subnetzes von SQL Managed Instance. Führen Sie diesen Schritt bei Bedarf auch für die Firewall des SQL Server-Hostbetriebssystems (Windows/Linux) aus.
Verwaltete SQL-Instanz	Erstellen Sie eine NSG-Regel im Azure-Portal, um den ein- und ausgehenden Datenverkehr von der IP-Adresse und dem Netzwerk, das SQL Server hostet, an Port 5022 und im Portbereich 11000-11999 zuzulassen.

Verwenden Sie das folgende PowerShell-Skript auf dem Windows-Hostbetriebssystem der SQL Server-Instanz, um Ports in der Windows-Firewall zu öffnen:

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

Das folgende Diagramm zeigt ein Beispiel für eine lokale Netzwerkumgebung, das angibt, dass alle Firewalls in der Umgebung über offene Ports verfügen müssen, einschließlich der Firewall des Betriebssystems, auf dem SQL Server gehostet wird, sowie aller Unternehmensfirewalls und/oder Gateways:

Wichtig

• Die Ports müssen in jeder Firewall in der Netzwerkumgebung geöffnet sein, einschließlich des Hostservers sowie aller Unternehmensfirewalls oder Gateways im Netzwerk. In Unternehmensumgebungen müssen Sie möglicherweise den Netzwerkadministrator*innen die Informationen in diesem Abschnitt zeigen, damit sie die zusätzlichen Ports auf Ebene des Unternehmensnetzwerks öffnen.
• Sie können den Endpunkt zwar auf der SQL Server-Seite anpassen, die Portnummern für SQL Managed Instance können jedoch nicht geändert oder angepasst werden.
• Die IP-Adressbereiche der Subnetze zum Hosten der verwalteten Instanz und von SQL Server dürfen sich nicht überschneiden.

Hinzufügen von URLs zur Zulassungsliste

Je nach Ihren Netzwerksicherheitseinstellungen kann es erforderlich sein, URLs für den SQL Managed Instance-FQDN und einige der Ressourcenverwaltungsendpunkte, die von Azure für Ihre Zulassungsliste verwendet werden, hinzuzufügen.

Im Folgenden werden die Ressourcen aufgeführt, die Ihrer Zulassungsliste hinzugefügt werden sollen:

• Der Vollqualifizierter Domänenname (FQDN) der SQL Managed Instance z. B. managedinstance1.6d710bcf372b.database.windows.net.
• Microsoft Entra-Autorität
• Microsoft Entra Endpoint Resource ID
• Resource Manager-Endpunkt
• Dienstendpunkt

Führen Sie die Schritte im Abschnitt Konfigurieren von SSMS für Government Clouds aus, um auf die Tools-Schnittstelle in SQL Server Management Studio (SSMS) zuzugreifen und die spezifischen URLs für die Ressourcen in Ihrer Cloud zu identifizieren, die Sie ihrer Zulassungsliste hinzufügen müssen.

Netzwerkkonnektivität testen

Der Link funktioniert nur, wenn zwischen SQL Server und SQL Managed Instance eine bidirektionale Netzwerkverbindung besteht. Testen Sie die Verbindung, nachdem Sie auf der SQL Server-Seite Ports geöffnet und auf der SQL Managed Instance Seite eine NSG-Regel konfiguriert haben verwenden Sie entweder SQL Server Management Studio (SSMS) oder Transact-SQL. .

Testen Sie das Netzwerk, indem Sie einen temporären SQL-Agent-Auftrag für SQL Server und SQL Managed Instance erstellen, um die Verbindung zwischen den beiden Instanzen zu überprüfen. Wenn Sie Network Checker in SSMS verwenden, wird der Auftrag automatisch für Sie erstellt und nach Abschluss des Tests gelöscht. Sie müssen den SQL-Agent-Job manuell löschen, wenn Sie Ihr Netzwerk mithilfe von T-SQL testen.

Hinweis

Das Ausführen von PowerShell-Skripts durch den SQL Server-Agent auf SQL Server für Linux wird derzeit nicht unterstützt, sodass es derzeit nicht möglich ist, über den SQL ServerAgent-Auftrag auf SQL Server für Linux auszuführenTest-NetConnection.

Um den SQL-Agent zum Testen der Netzwerkkonnektivität zu verwenden, benötigen Sie die folgenden Anforderungen:

• Der Benutzer, der den Test durchführt, muss über Berechtigungen zum Erstellen eines Jobs verfügen (entweder als Sysadmin oder als zugehörigt zur SQLAgentOperator-Rolle für msdb) für SQL Server und SQL Managed Instance.
• Der SQL Server -Agent-Dienst muss auf SQL Server ausgeführt werden. Da der Agent standardmäßig in SQL Managed Instance aktiviert ist, ist keine zusätzliche Aktion erforderlich.

SSMS

Führen Sie die folgenden Schritte aus, um die Netzwerkkonnektivität zwischen SQL Server und SQL Managed Instance in SSMS zu testen:

1. Stellen Sie eine Verbindung mit der Instanz her, die das primäre Replikat in SSMS sein wird.

2. Erweitern Sie in Objekt-Explorer Datenbanken, und klicken Sie mit der rechten Maustaste auf die Datenbank, die Sie mit der sekundären Datenbank verknüpfen möchten. Wählen Sie Aufgaben> in Azure SQL Managed Instance Link >Test Verbindung aus, um den Netzwerkprüfer-Assistenten zu öffnen:

   

3. Wählen Sie Weiter auf der Seite Einführung des Network Assistenten.

4. Wenn alle Anforderungen auf der Seite Voraussetzungen erfüllt sind, wählen Sie Weiter. Lösen Sie andernfalls alle nicht erfüllten Voraussetzungen auf, und wählen Sie dann Überprüfung erneut ausführen.

5. Wählen Sie auf der Seite Anmeldung die Option Anmeldung, um eine Verbindung mit der anderen Instanz herzustellen, die das sekundäre Replikat ist. Wählen Sie Weiter aus.

6. Überprüfen Sie die Details auf der Seite Netzwerkoptionen angeben, und geben Sie gegebenenfalls eine IP-Adresse an. Wählen Sie Weiter aus.

7. Überprüfen Sie auf der Seite Zusammenfassung die Aktionen, die der Assistent ausführt, und wählen Sie dann Fertig stellen aus, um die Verbindung zwischen den beiden Replikaten zu testen.

8. Überprüfen Sie die Seite Ergebnisse, um die Konnektivität zwischen den beiden Replikaten zu überprüfen, und wählen Sie dann Schließen.

T-SQL

Um T-SQL zum Testen der Konnektivität zu verwenden, müssen Sie die Verbindung in beide Richtungen überprüfen. Testen Sie zunächst die Verbindung von SQL Server zu SQL Managed Instance, und testen Sie dann die Verbindung von SQL Managed Instance zu SQL Server

Testen der Verbindung von SQL Server zu SQL Managed Instance

Verwenden Sie den SQL Server-Agent auf SQL Server, um Verbindungstests von SQL Server zu SQL Managed Instance durchzuführen.

1. Stellen Sie eine Verbindung zu SQL Managed Instance her, und führen Sie das folgende Skript aus, um einige Parameter zu generieren, die Sie später benötigen:

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

   Ergebnisse sollten wie in der folgenden Tabelle aussehen:

   

   Speichern Sie das Ergebnis, das in den nächsten Schritten verwendet werden soll. Da sich diese Parameter nach einem Failover ändern können, müssen Sie sie bei Bedarf erneut generieren.

2. Stellen Sie eine Verbindung mit SQL Server her.

3. Öffnen Sie ein neues Abfragefenster und fügen Sie das folgende Skript ein:

   --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. Ersetzen Sie die @node, @port und @serverName Parameter durch die Werte, die Sie aus dem ersten Schritt erhalten haben.

5. Führen Sie das Skript aus und prüfen Sie die Ergebnisse. Die angezeigten Ergebnisse sollten wie das folgende Beispiel aussehen:

   

6. Überprüfen Sie die Ergebnisse:

   • Das Ergebnis der einzelnen Tests bei TcpTestSucceeded sollte TcpTestSucceeded : True lauten.
   • Die RemoteAddresses sollten zum IP-Bereich für das SQL Managed Instance-Subnetz gehören.

   Überprüfen Sie folgende Netzwerkeinstellungen, wenn der Test nicht erfolgreich ist:

   • Es gibt Regeln in der Netzwerkfirewall und in der Firewall des SQL Server-Hostbetriebssystems (Windows/Linux), die Datenverkehr an den gesamten IP-Adressbereich des Subnetzes von SQL Managed Instance zulassen.
   • Es gibt eine NSG-Regel, die die Kommunikation über den Port 5022 für das virtuelle Netzwerk ermöglicht, in dem SQL Managed Instance gehostet wird.

Testen der Verbindung von SQL Managed Instance zu SQL Server

Um zu überprüfen, ob SQL Server für SQL Managed Instance erreichbar ist, erstellen Sie zunächst einen Testendpunkt. Anschließend verwenden Sie den SQL Server Agent, um ein PowerShell-Skript mit dem Befehl tnc auszuführen. Dadurch wird SQL Server am Port 5022 von der SQL Managed Instance aus gepingt.

Stellen Sie zum Erstellen eines Testendpunkts eine Verbindung mit SQL Server her, und führen Sie das folgende T-SQL-Skript aus:

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

Führen Sie im Hostbetriebssystem Ihrer SQL Server-Instanz den folgenden PowerShell-Befehl aus, um sich zu vergewissern, dass der SQL Server-Endpunkt Verbindungen am Port 5022 empfängt:

tnc localhost -port 5022

Bei einem erfolgreichen Test wird TcpTestSucceeded : True angezeigt. Anschließend können Sie einen SQL Server Agent-Auftrag in der verwalteten Instanz erstellen, um den SQL Server-Testendpunkt am Port 5022 von der SQL Managed Instance aus zu testen.

Als nächstes erstellen Sie auf der SQL Managed Instance einen SQL verwalteten Agent-Auftrag mit dem Namen NetHelper, indem Sie das folgende T-SQL-Skript auf der SQL Managed Instance ausführen. Ersetzen Sie:

• <SQL_SERVER_IP_ADDRESS> durch die IP-Adresse von SQL Server, auf die von der SQL Managed Instance aus zugegriffen werden kann.

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

Tipp

Falls Sie die IP-Adresse Ihrer SQL Server-Instanz für den Verbindungstest von der SQL Managed Instance aus ändern müssen, löschen Sie den NetHelper-Auftrag, indem Sie EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' ausführen, und erstellen Sie den NetHelper-Auftrag mithilfe des vorherigen Skripts neu.

Erstellen Sie dann eine gespeicherte Prozedur ExecuteNetHelper, mit deren Hilfe Sie den Auftrag ausführen und Ergebnisse vom Netzwerktest erhalten können. Führen Sie auf der SQL Managed Instance das folgende T-SQL-Skript aus:

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

Führen Sie die folgende Abfrage auf der SQL Managed Instance aus, um die gespeicherte Prozedur auszuführen, die den Auftrag des NetHelper-Agenten ausführt und das resultierende Protokoll anzeigt:

-- Run on managed instance
EXEC ExecuteNetHelper;

Wenn die Verbindung erfolgreich hergestellt wurde, wird im Protokoll True angezeigt. Wenn die Verbindung nicht hergestellt werden konnte, wird im Protokoll False angezeigt.

Überprüfen Sie folgende Punkte, wenn die Verbindung nicht hergestellt werden konnte:

• Die Firewall der SQL Server-Hostinstanz lässt eingehende und ausgehende Kommunikation am Port 5022 zu.
• Eine NSG-Regel für das virtuelle Netzwerk, in dem SQL Managed Instance gehostet wird, lässt die Kommunikation am Port 5022 zu.
• Wenn sich Ihre SQL Server-Instanz auf einem virtuellen Azure-Computer befindet, lässt eine NSG-Regel die Kommunikation am Port 5022 in dem virtuellen Netzwerk zu, in dem der virtuelle Computer gehostet wird.
• SQL Server wird ausgeführt.
• Es gibt einen Testendpunkt auf der SQL Server-Instanz.

Nachdem Sie die Probleme behoben haben, führen Sie den NetHelper-Netzwerktest erneut aus, indem Sie EXEC ExecuteNetHelper auf der verwalteten Instanz ausführen.

Nachdem der Netzwerktest erfolgreich verlaufen ist, löschen Sie den Testendpunkt und das Zertifikat auf dem SQL Server mithilfe der folgenden T-SQL-Befehle:

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

Achtung

Fahren Sie mit den nächsten Schritten nur fort, wenn Sie sich vergewissert haben, dass die Netzwerkverbindung zwischen Ihrer Quell- und Zielumgebung funktioniert. Behandeln Sie andernfalls Probleme mit der Netzwerkverbindung, bevor Sie fortfahren.

Migrieren eines Zertifikats einer durch TDE geschützten Datenbank (optional)

Wenn Sie eine durch Transparent Data Encryption (TDE) geschützte SQL Server-Datenbank mit einer verwalteten Instanz verknüpfen, muss das entsprechende Verschlüsselungszertifikat von der lokalen SQL Server-Instanz bzw. von der SQL Server-Instanz auf dem virtuellen Azure-Computer vor der Verwendung des Links zur verwalteten Instanz migriert werden. Detaillierte Schritte finden Sie unter „Migrieren des Zertifikats einer durch TDE geschützten Datenbank zu einer Azure SQL Managed Instance“

SQL Managed Instance Datenbanken, die mit dienstseitig verwalteten TDE-Schlüsseln verschlüsselt sind, können nicht in SQL Server wiederhergestellt werden. Sie können eine verschlüsselte Datenbank nur dann mit dem SQL Server verknüpfen, wenn sie mit einem kundenseitig verwalteten Schlüssel verschlüsselt wurde und der Zielserver Zugriff auf denselben Schlüssel hat, der zum Verschlüsseln der Datenbank verwendet wurde. Weitere Informationen finden Sie unter Einrichten SQL Server-TDE mit Azure Key Vault.

Hinweis

Azure Key Vault wird von SQL Server für Linux ab SQL Server 2022 CU 14 unterstützt.

Installieren von SSMS

SQL Server Management Studio (SSMS) ist die einfachste Möglichkeit, um den Managed Instance-Link zu verwenden. Laden Sie die SSMS-Version 19.0 oder höher herunter, und installieren Sie sie auf Ihrem Clientcomputer.

Öffnen Sie SSMS nach Abschluss der Installation, und stellen Sie eine Verbindung mit Ihrer unterstützten SQL Server-Instanz her. Klicken Sie mit der rechten Maustaste auf eine Benutzerdatenbank, und vergewissern Sie sich, dass im Menü die Option Azure SQL Managed Instance link (Link für Azure SQL Managed Instance) angezeigt wird.

Konfigurieren von SSMS für die Cloud für Regierungsbehörden

Wenn Sie Ihre SQL Managed Instance-Instanz in einer Cloud für Regierungsbehörden bereitstellen möchten, müssen Sie Ihre SQL Server Management Studio-Einstellungen (SSMS) ändern, um die richtige Cloud zu verwenden. Wenn Sie Ihre SQL Managed Instance-Instanz nicht in einer Cloud für Regierungsbehörden bereitstellen, überspringen Sie diesen Schritt.

Führen Sie die folgenden Schritte aus, um Ihre SSMS-Einstellungen zu aktualisieren:

1. Öffnen Sie SSMS.
2. Wählen Sie im Menü Extras und dann Optionen aus.
3. Erweitern Sie Azure-Dienste, und wählen Sie Azure Cloud aus.
4. Verwenden Sie unter Azure-Cloud auswählen die Dropdownliste, um AzureUSGovernment oder eine andere Cloud für Regierungsbehörden auszuwählen, z. B. AzureChinaCloud:

Wenn Sie zur öffentlichen Cloud zurückkehren möchten, wählen Sie im Dropdownmenü AzureCloud aus.

Zugehöriger Inhalt

So verwenden Sie den Link:

• Konfigurieren der Verknüpfung zwischen SQL Server und SQL Managed Instance mit SSMS
• Konfigurieren der Verknüpfung zwischen SQL Server und SQL Managed Instance mit Skripten
• Führen Sie ein Failover des Links aus
• Migrieren mit dem Link
• Bewährte Methoden zum Verwalten des Links

Weitere Informationen zum Link finden Sie unter:

• Übersicht der verwalteten Instanz-Links
• Notfallwiederherstellung mit Managed Instance Link

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter:

• Transaktionsreplikation mit SQL Managed Instance
• Protokollwiedergabedienst (Log Replay Service, LRS)