Managed Instance Links - On-Prem Managed Instance

Managed Instance Links (“MI-Links”) stellen ein Mittel dar, mit dem man seine SQL–Server Instanz mit einer Azure Managed Instanz verbinden kann. Bei der Einrichtung eines solchen Links sind einige Schritte durchzuführen und einige Voraussetzungen zu betrachten. Ein solcher Link kann eingesetzt werden, um

• eine Migration einer On-Prem Instanz zu einer Azure Managed Instanz durchzuführen
• eine Notfallwiederherstellung durchzuführen
• ein Replikat in die Cloud zu erstellen

In diesem Dokument stellen wir die Schritte vor, die zur Vorbereitung der Umgebung und zum Erstellen eines MI-Links erforderlich sind, der eine Datenreplikation nahezu in Echtzeit zwischen SQL–Server und Azure SQL Managed Instance mithilfe von verteilten Verfügbarkeitsgruppen ermöglicht.

Anforderungen

• Managed Instance Link Setup Skript Paket welches hier heruntergeladen werden kann.

• Administratorzugriff auf beide Instanzen mithilfe des T–SQL-Endpunkts.

• Zertifikatbasierte Authentifizierung mit Austauschen der öffentlichen Schlüssel beider Instanzen

• Sichere Konnektivität (VPN) zwischen dem lokalen Netzwerk und Azure. Zwischen den beiden Instanzen muss eine Site-to-Site-Konnektivität erstellt werden (ein MI-Link kann nur über private Konnektivität hergestellt werden). Folgende Ports auf der Netzwerksicherheitsgruppe (NSG) im Azure SQL Managed Instance-Subnetz müssen freigeschaltet werden:

  • 1433
  • 5022
  • 11000-11999 (In & Out)
  • Port 5022 auf dem SQL–Server muss freigeschaltet werden

• Power Shell Zugriff auf die Managed Azure Instanz, wobei mindestens Version 3.9.0 benötigt wird

• PowerShell Az.Accounts-Modul Version 2.8.0 oder neuer.

• SQL–Server-Modul Version 21.1.18256 oder neuer.

Trace-Flags (empfohlen):

T9567: aktiviert die Komprimierung des Datastreams für Verfügbarkeitsgruppen während des automatischen Seedings. Die Komprimierung erhöht die Belastung der CPU, kann aber die Übertragungszeiten während des Seedings erheblich verkürzen. Um das Flag einzustellen muss man den SQL Server Configuration Manager starten, SQL–Server Services auswählen und auf den SQL–Server mit Rechtsklick Properties auswählen

• T1800 (optional): optimiert die Leistung, wenn die Protokolldateien für die primären und sekundären Replikate in einer Verfügbarkeitsgruppe auf Datenträgern mit unterschiedlichen Sektorgrößen gehostet werden, z. B. 512 Byte und 4 KB.

Einschränkungen

Obwohl der Managed Instanz Link sehr hilfreich ist, existieren Einschränkungen die ein Setup verhindern könnten. MI-Links unterstützen zur Zeit keine:

• Systemdatenbanken, also nur Benutzerdatenbanken
• Verfügbarkeitsgruppen mit mehreren Datenbanken
• Betriebssysteme wie Windows 10 & 11 (nur Windows Server 2012 oder höher)
• SQL–Server 2014 oder ältere Versionen (nur SQL–Server 2016 SP3 oder neuer, SQL–Server 2019 CU15 oder neuer, SQL-Server 2022)
• Datenbanken mit In-Memory Objekten
• Dateitabellen und Dateistreams
• Windows-Authentifizierung (nur Zertifikate)

Eine vollständige Liste der Einschränkungen befindet sich in der hier verlinkten Microsoft Dokumentation.

Das Managed Instance Link Setup Module

Dieses Modul automatisiert die Erstellung eines Managed Instance Links. Es prüft und erstellt die lokale Instanz für die Integration in eine verteilte Verfügbarkeitsgruppe (zwischen lokaler Instanz und Azure SQL Managed Instanz).

Wenn die lokale Instanz schon Teil einer Verfügbarkeitsgruppe ist, werden alle beteiligten Instanzen mit geprüft.

Vorbereitung und Validierung der SQL–Server Instance

Zur Vorbereitung und Validierung brauchen wir jeweils das gleiche cmdlet, nämlich ValidateAndPrepareMiLinkSetup.

Ausführungsberechtigung erteilen

Modul Import (vgl. Download Link im Kapitel "Anforderungen")

Ausführung des Cmdlets

Das cmdlet ValidateAndPrepareMiLinkSetup

Das cmdlet führt 11 Schritte aus:

1. Prüft ob die Instanz Teil einer Always On Availability Gruppe oder ob es sich um eine Single Instanz handelt

2. Prüft, ob die Instanzversion die Mindestvoraussetzungen erfüllt.

3. Prüft den Database Master Key. Falls dieser nicht vorhanden ist, wird er in der Master DB erstellt.

4. Die HADR / AlwaysOn Funktion muss aktiviert sein. Falls dies nicht der Fall ist, muss sie manuell aktiviert werden (Neustart erforderlich).

5. Importiert die notwendigen Zertifikate

6. Überprüft, ob der Database Mirroring Endpoint eine Zertifikatsauthentifizierung verwendet. Sollte dies nicht der Fall sein, wird diese eingerichtet.

7. Anschließend wird die Erreichbarkeit des Database Mirroring Endpoint (“DBM”) überprüft.

8. Nach einem Azure Login wird sichergestellt, dass die maximale Anzahl der Datenbanken in der Managed Instanz nicht überschritten wird (Max. 100 pro Managed Instanz) und dass die Instanz nicht Teil einer Auto Failover Gruppe ist.

9. Das DBM Zertifikat der Managed Instanz wird in die SQL–Server Instanz kopiert.

10. Das DBM Zertifikat der SQL–Server Instanz wird in die Managed Instanz kopiert.

11. Die Verbindung zwischen den beiden Instanzen wird geprüft.

Damit sind die Prüfungsschritte abgeschlossen:

Das cmdlet CreateMiLink

Zur Erstellung des Links zwischen den beiden Instanzen wird das CreateMiLink cmdlet benutzt. Es prüft, ob die Instanzen in einem Link zwischen lokaler und Managed Instanz benutzt werden können. Wenn alles den Anforderungen entspricht, wird ein Link erstellt und die lokale Datenbank in die Managed Instanz synchronisiert.

Wichtig! Wenn die Datenbank Teil einer Always On Gruppe ist, darf nur eine Datenbank in der Gruppe sein, andernfalls erscheint die folgende Fehlermeldung:

Ausführung

Ausführungberechtigung korrigieren falls nötig

Modul Import

Die Ausführung des cmdlets kann mit mehreren Parametern je nach Bedarf ausgeführt werden. Hier ein paar Beispiele:

Der Standard Befehl, lediglich mit den Pflichtparametern für

• die Quellinstanz
• die (managed) Zielinstanz
• und die zu übernehmende(n) Datenbank(en)

lautet dann:

Der folgende Befehl validiert die DB und wenn kein Full Backup existiert, wird dieses vor der Erstellung des Links erstellt.

Der folgende Aufruf validiert alle Datenbanken und synchronisiert die Datenbanken unter Verwendung einer Parallelität von zwei:

Das cmdlet CreateMiLink führt 8 Schritte aus:

1. Prüft ob die Instanz Teil einer Always On Availability Gruppe ist oder es sich um eine Single Instanz handelt

2. Prüft, ob die Instanzversion die Mindestvoraussetzungen erfüllt.

3. Nach einem Azure Login wird die Resource Gruppe gesucht, zu welcher die Managed Instanz gehört, und es wird geprüft, dass die maximale Anzahl der Datenbanken in der Managed Instanz nicht überschritten wird (max. 100 DBs pro Managed Instanz).

4. Alle Datenbanken werden unter anderem auf folgendes geprüft:
   • ob sie Online sind
   • nicht Teil der Managed Instance sind
   • ob sie weder Filestream Container noch In-Memory Container haben uvm.

5. Das Recoverymodell muss bei allen Datenbanken auf FULL gesetzt sein.

6. Der Verschlüsselungsstatus jeder Datenbank (in der bereitgestellten Datenbankliste) wird überprüft. Wenn die Datenbank TDE-geschützt ist, wird der Benutzer gefragt, ob das Verschlüsselungszertifikat gesichert und in die verwaltete Azure SQL-Instanz hochgeladen werden soll. Wenn nicht, wird die Datenbank ausgelassen. Wenn es erlaubt ist, wird das TDE-Zertifikat an dem im Parameter BackupPathLocation angegebenen Speicherort gesichert, konvertiert und in Azure SQL Managed Instance hochgeladen.

7. Zusammenfassung und Bestätigung der geprüften Datenbanken

8. Managed Instanz Link wird erstellt

Fazit

Der Managed Instanz Link zwischen der lokalen Datenbank und Azure SQL Managed Instance ist damit erstellt und in Betrieb genommen und dadurch die Migrationen einer lokalen auf eine Managed Instanz ohne Ausfall ermöglicht worden.

Sollten Sie Fragen zu diesem Artikel oder Probleme mit bei der Migration haben, stehen wir Ihnen gerne zur Verfügung. Nutzen Sie dafür unverbindlich unser Kontaktformular.