Wir haben bereits in zwei Artikeln aus 2022 und 2023 die Einrichtung eines Links zur Microsoft Azure SQL Managed Instance (kurz Managed Instance) thematisiert. Bisher war es jedoch nicht möglich, den Link mithilfe eines Assistenten direkt im SQL Management Studio herzustellen, sondern es mussten manuell PowerShell Installationsskripte ausgeführt werden. Dies hat sich zwischenzeitlich geändert.
In diesem Artikel wird erläutert, wie ein Upgrade von SQL Server 2017 auf SQL Server 2022 durchgeführt und anschließend in eine Managed Instance mithilfe des integrierten Assistenten im SQL Management Studio als Link bzw. zusätzliche verteilte Verfügbarkeitsgruppe eingerichtet wird. Diese dient im Falle eines Ausfalls als Ersatz und bietet zudem stets eine aktuelle lesbare Datenquelle.
Als Beispiel wurden zwei Windows Server 2019 mit SQL Server 2017 in einer lokalen Umgebung eingerichtet. Beide Server sind zu einer High Availability Gruppe hinzugefügt und bilden einen Cluster. Zusätzlich ist auf beiden Servern SQL Server Analysis Services (SSAS) installiert, und der Datawarehouse Cube “Adventure Works” wird dort bereitgestellt. Die Adventure Works DWH Beispieldatenbank AdventureWorksDW2017 ist als Relationale Datenbank in die Hochverfügbarkeitsgruppe eingebunden. Diese Datenbank dient als Quelle für das Prozessieren des Cubes. Während eines Prozessierens werden Daten extrahiert, transformiert und in den Cube geladen. Der Zugriff auf den Cube selbst erfolgt testweise über eine Excel Datenquelle.
Managed Instance Link
In nachfolgender Abbildung ist das Zielbild skizziert. Es soll eine weitere sekundäre Datenbank erstellt werden, die jederzeit lesbar ist und als Backup in der Azure Cloud bereitgestellt wird. Im Notfall kann über ein manuelles Failover auf diese Datenbank geschwenkt werden. Die Daten werden jederzeit in nahezu Echtzeit auf diese zusätzliche Datenbank von der primären Datenbank repliziert. Die bestehende Verfügbarkeitsgruppe wird dazu nicht verändert.
Es ist ebenfalls möglich, mehrere Datenbanken zu replizieren, in dem mehrere Verfügbarkeitsgruppen zunächst angelegt und dann jeweils ein Link zur Managed Instance hergestellt wird. Mehr Informationen folgen später im Artikel im Abschnitt “Eine Datenbank pro Verfügbarkeitsgruppe”.
Unterstützte SQL Server Versionen
Ein Managed Instance Link wird von SQL Server 2016, 2019 und 2022 unterstützt.
In den Versionen 2016 und 2019 können Daten in eine Richtung von einer SQL-Instanz zu einer Managed Instance repliziert werden. Im Notfall kann ein manueller Failover auf die Managed Instance erfolgen, aber dadurch wird die Verbindung unterbrochen und ein Failback wird nicht unterstützt.
Ab der Version 2022 wird eine Notfallwiederherstellung unterstützt. Das bedeutet, dass ebenfalls ein Failover auf die Managed Instance erfolgen kann. Anschließend kann erneut ein Failback erfolgen, wenn der Notfall abgewendet wurde. Die ursprüngliche Primärinstanz kann demnach entweder von SQL Server- oder Managed Instance gebildet werden. Laut Microsoft befindet sich das Feature zur Notfallwiederherstellung derzeit noch in der Vorschau. Da die Desynchronisation an sich jedoch stabil ist, eignet sich das Link-Feature grundsätzlich für produktive Systeme.
Weitere Informationen liefert dieser Artikel Verbindungsfeature von Managed Instance (microsoft.com)
Geplante Schritte
Da im Beispiel ein SQL Server 2017 vorliegt, der keinen Link zur Managed Instance unterstützt, muss zunächst ein Update auf die aktuelle Version 2022 erfolgen, um dieses Feature nutzen zu können. Anschließend wird wie im Schaubild gezeigt, ein Link zu einer Managed Instance hergestellt. Die Managed Instance kann über das Azure Portal unter dem Punkt “SQL Managed Instance” erstellt werden und liegt in diesem Beispiel im Initialzustand (ohne Datenbanken) bereits vor.
Nachfolgend ist der Artikel in drei Teile gegliedert. Teil 1 beschreibt das Update von SQL Server 2017 nach 2022 inkl. Analysis Server. In Teil 2 werden alle Voraussetzungen zum Einrichten vorgestellt um dann abschließend in Teil 3 den Link über den integrierten Assistenten zu konfigurieren und zu aktivieren.
Teil 1: Migration des Clusters SQL Server 2017 nach 2022
Update der Availability Gruppe
Das Upgrade bzw. die Migration einer SQL Server Always On Availability Gruppe läuft schematisch nach folgendem Muster ab. Zu Beginn sollte über das Availability Group Dashboard geprüft werden, ob der Availability Group State Healthy ist, denn mindestens ein manuelles Failover wird im Installationsprozess benötigt.
Anschließend verbindet man sich mit dem Secondary Node Server und startet im Setup der Installations Iso-Datei den Punkt Upgrade from a previous version of SQL Server. Wichtig ist hierbei ist, dass die Installation immer nur auf dem Secondary gestartet werden muss. Während des Updates werden auch die Analysis Komponenten entsprechend mit aktualisiert. Diese werden bei Select Features entsprechend mit ausgewählt: Database Engine Service und Analysis Services.
Nach dem Abschluss der Installation auf dem Secondary Server muss ein manueller Failover erfolgen um den anderen Server ebenfalls upgraden zu können. Dieser wird nun durch das manuelle Failover vom Primary zum Secondary. Anschließend erfolgt ebenfalls die Upgrade Installation analog zum Server zuvor.
Wichtig nach dem Abschluss der Arbeiten muss der Datenfluss zwischen den Instanzen wieder aktiviert werden. Dies erfolgt mit einem Rechtsklick auf die Availability Databases und dort Resume Data Movement. Dieser Schritt ist wichtig um beide Datenbank-Instanzen wieder in den Status Synchronized zu bekommen.
Hier sind die Punkte zum Upgrade zusammengefasst:
- Kurzer Check der Availability Gruppe vor dem Start (ein Failover muss prinzipiell funktionieren)
- Upgrade Installation auf dem Secondary Server starten
- Manuelles Failover vom Primary auf den Secondary Server
- SQL Server Upgrade Installation auf dem ursprünglichen Primary Server (jetzt Secondary)
- In der Availability Group den Datenfluss aktivieren
- Optional: Ein erneutes manuelles Failover zurück auf den ursprünglichen Primary Server (zum Testen)
Test des Analysis Cubes
Um die Migration abzuschließen wird testweise noch auf den Datawarehouse Cube zugegriffen. Dazu verbindet man sich über Excel mit dem Cube. Anschließend wird ein manuelles Prozessieren des Cubes angestoßen und der Zugriff auf den Cube erneut geprüft.
In nachfolgender Abbildung ist auf der linken Seite das erfolgreiche Prozessieren des Cubes erkennbar nachdem auf SQL Server 2022 aktualisiert wurde. Auf der rechten Seite wurde mit Excel über Daten Analysis Server auf den Cube zugegriffen und ein Diagramm erzeugt. Ein Klick auf Daten Aktualisieren innerhalb von Excel funktioniert und zeigt die Ergebnisse weiterhin an.
Teil 2: Vorbereitungen für den Managed Instance Link
Eine Datenbank pro Verfügbarkeitsgruppe
Eine aktuelle Limitation besteht darin, dass nur Datenbanken zum Link hinzugefügt werden können, die einzeln in einer Verfügbarkeitsgruppe konfiguriert sind (vgl. Verbindungsfeature von Managed Instance (microsoft.com). Sollte eine Verfügbarkeitsgruppe mit beispielsweise zwei synchronisierten Datenbanken bestehen und eine oder beide der Datenbanken per Link verbunden werden sollen, dann muss eine der Datenbanken aus der Verfügbarkeitsgruppe entfernt und in eine neue Verfügbarkeitsgruppe hinzugefügt werden. Andernfalls können beide Datenbanken nicht zum Link hinzugefügt werden. Dieser Schritt sollte vor dem Start des Assistenten erfolgen, da dieser diesen Umstand ebenfalls prüft. Es können auf diese Weise mehrere Links (Limit liegt bei 100) erstellt werden.
Es können ebenfalls mehrere Datenbanken zum Link hinzugefügt werden, die keiner Verfügbarkeitsgruppe zugeordnet sind. Dort gibt es keine weiteren Einschränkungen. Dieser Fall ist jedoch nicht Teil dieses Artikels.
Im vorliegenden Beispiel ist eine Verfügbarkeitsgruppe auf zwei Servern mit einer DWH Datenbank konfiguriert. So sollte es exemplarisch im SQL Management Studio aussehen:
Berechtigungen
Für den lokalen SQL Server werden sysadmin-Berechtigungen benötigt. In der Managed Instance muss der Benutzer Mitglied der Rolle Mitwirkender für verwaltete SQL-Instanzen sein oder die Berechtigungen entsprechend Vorbereiten SQL Managed Instance Berechtigungen (microsoft.com) zugeordnet bekommen.
Trace Flags setzen
Es wird empfohlen im SQL Server folgende Traceflags zu setzen. Es ist zu beachten, dass dies auf allen Knoten durchgeführt werden muss. Ebenso muss der Service der Database Engine nach der Änderung neu gestartet werden. Aus diesem Grund solle die Einstellung zunächst auf dem sekundären Server vorgenommen werden. Anschließend folgt ein manuelles Failover um den zweiten Server entsprechend zu konfigurieren.
- T1800: Ein Trace Flag, das die Performance optimiert, wenn Transaktionslogdateien der primären und sekundären Replikate innerhalb der Availability Group auf Platten mit unterschiedlichen Sektorengrößen gespeichert werden. Wenn die Platten alle auf eine Sektorengröße von 4K konfiguriert sind (was zu empfehlen ist), kann dieser Parameter wegfallen.
- T9567: Wichtiger Parameter beim automatischen Seeding in der Availability Group, wenn wir mit großen Datenbanken arbeiten. Dieser Parameter aktiviert die Datenkompression beim Seeding. Belastet zusätzlich die CPUs, kann aber die Zeit für die Datenübertragung signifikant verkürzen.
Diese beiden Flags werden im SQL Server Configuration Manager bei Startup Parameters hinzugefügt:
Masterkey erstellen
Mit folgendem Script auf beiden SQL Servern wird ein neuer Masterkey erzeugt, falls nicht bereits vorhanden. Bitte das Passwort StrongPassword123 auf ein eigenes anpassen. Der Masterkey wird für ein Zertifikat benötigt, welches der Endpoint benutzen muss. Eine unverschlüsselte Kommunikation ist nicht möglich.
Mithilfe dieser Abfrage kann geprüft werden ob die Erstellung erfolgreich war:
Netzwerk einrichten
Es müssen folgende Ports ein- und ausgehend auf der Managed Instance und auf den SQL Servern freigeschaltet werden:
- TCP 1433 bzw. TCP-Port mit dem die Instanzen betrieben werden
- TCP 5022
- TCP 11000-11999
Es ist zu empfehlen, die Source und Destination IP Adressbereiche auf das eigene Netzwerk einzuschränken bzw. einen privaten VPN Tunnel in das entsprechende Azure Netzwerk zu konfigurieren. Sollte der öffentliche Endpunkt aktiviert sein und in der Network Security Group “Any” als Source eingestellt sein, dann wäre die Managed Instance öffentlich im Internet erreichbar.
Im Beispiel wird über ein Azure Netzwerk Peering auf den SQL-Server zugegriffen. Der Netzbereich 10.3.2.0/24, in dem sich beide SQL Server befinden, muss in der Network Security Group des virtuellen Netzwerks der Managed Instance freigeschaltet werden (siehe nachfolgende Abbildung). Über den Port TCP 1433 kann direkt über das SQL Managemend Studio auf die Instanz zugegriffen werden. Die Ports TCP 5022 sowie TCP 11000-11999 werden für die Replikation und den Link benötigt.
Netzwerkverbindung testen
Bevor der Assistent zum Einrichten des Links gestartet wird, sollte ein Test der Network Connection erfolgen.
Dieser Assistent erzeugt automatisch im SQL Server und in der Managed Instance einen neuen Job um auf die jeweils benötigten Ports der anderen Datenbankinstanz zuzugreifen (technisch erfolgt dies über Powershell Test-NetworkConnection).
Zunächst wird der SQL Server Agent geprüft. Dieser wird benötigt um die Test-Jobs auszuführen.
Anschließend erfolgt ein Login bei der Managed Instance und eine Bestätigung der lokalen Server Adresse. Nach einer Zusammenfassung kann der Test gestartet werden.
Durch unsere Tests zeigte sich, dass der Job in der Managed Instance ohne Owner angelegt wird. Daraufhin schlägt der Assistent fehl, mit folgender Meldung:
“Failed to run Agent job on a MI. Error message: The job failed.
Unable to determine if the owner () of job […] has server access.”
Sollte der Fehler an dieser Stelle auftreten, kann der Test trotzdem ausgeführt werden: Es müssten dazu die Properties des auf der Managed Instance angelegten Jobs eingestellt und der Job manuell gestartet werden. Dazu zunächst per SQL Management Studio eine Verbindung zur Managed Instance aufbauen und die Properties des zuletzt angelegten Job beginnend mit “TestMiLinkConnection…” öffnen.
Dort als Owner sa eintragen und den Job speichern.
Anschließend den Job manuell ausführen über Rechtsklick auf den Job und Start Job.
Dieser sollte nun erfolgreich durchlaufen. Das Testergebnis steht in der Historie des Jobs. Dazu erneut die Properties öffnen und View Job History anklicken.
Dort nach dem neuesten Eintrag und unterhalb die Message kontrollieren. Die Ausgabe TcpTestSucceeded: True (siehe Abbildung unten) zeigt an, dass der Verbindungstest erfolgreich war.
Sollte an dieser Stelle TcpTestSucceeded: False stehen, dann wird der Assistent zum Einrichten des Links fehlschlagen. In diesem Fall muss die Netzwerkverbindung, insb. die Firewall eingehend auf dem SQL Server geprüft werden (siehe Kapitel Netzwerk zuvor im Artikel).
Teil 3: Managed Instance Link erstellen
Nachdem nun alle Vorbereitungen abgeschlossen sind kann der eigentliche Assistent zum Erstellen eines neuen Links zur Managed Instance aufgerufen werden.
Der Assistent verlangt nun einen Namen für den Link. Optional lässt sich hier das Disaster recovery intent deaktivieren. Damit wäre aber ein Failback nach einem Failover auf die Managed Instance nicht mehr möglich. Daher sollte es aktiviert bleiben.
Server readiness prüfen
Anschließend werden die geprüft. Die Server readiness sollte vollständig erfüllt sein, wenn alle Schritte zuvor ausgeführt wurden.
Im zweiten Reiter befindet sich das Ergebnis der Überprüfung der Availability Gruppe. Hier ist zu erwarten, dass kein Zertifikat vorhanden ist (daher das gelbe Ausrufezeichen). Dies wird jedoch im Rahmen des Assistenten automatisch erzeugt und stellt an dieser Stelle kein Problem dar. Unterhalb der Tabelle sollte demnach Server is ready stehen.
Im nächsten Schritt wird die Datenbank selektiert. Wie bereits in Teil 2 Vorbereitungen für den Managed Instance Link erläutert, können hier nur Datenbanken selektiert werden, die einzeln in einer Availability Group konfiguriert sind.
Im Beispiel wird zunächst die Datawarehouse Datenbank zum Link hinzugefügt. Es ist ebenfalls möglich, vom Assistenten mehrere Links gleichzeitig zu erstellen.
Anschließend erfolgt der Login in der Managed Instance um diese als Secondary Replica hinzuzufügen.
Replica hinzufügen
Nach dem Klick auf Add Secondary Replica öffnet sich ein Azure Sign-In-Fenster und die Auswahl sowie Anmeldung an der entsprechenden MI.
Anschließend wird diese Instanz automatisch als Secondary hinzugefügt. Der Availability Mode ist auf Asynchronous automatisch eingestellt. Ebenfalls ist der Failover Mode fest auf Manual eingestellt und ein lesen der replizierten Daten ist durch die Einstellung Readable secondary ebenfalls vorgesehen. Veränderungen an den Einstellungen sind an dieser Stelle nicht möglich.
Link durch den Assistenten einrichten
Nach einer Validation können die Schritte direkt vom Assistenten ausgeführt werden. Dieser Vorgang kann ein paar Minuten dauern.
Nachdem der Assistent erfolgreich durchgelaufen ist, sollte der Status der neu erstellen verteilten Verfügbarkeitsgruppe überprüft werden.
Unter Availability Groups wurde eine neue verteilte Distributed Gruppe mit dem gewählten Namen erzeugt. Innerhalb dieser wurden die zwei Replicas, lokaler Cluster sql17avg und ein neuer AG_AdventureWorksDW2017_MI hinzugefügt (für die MI).
In der Managed Instance wurde die gewählte Datenbank erstellt und vollautomatisch synchronisiert. Es kann nun jederzeit auf eine aktuelle Kopie der Daten lesend zugegriffen werden.
Fazit
In diesem Artikel wurde gezeigt, wie ein existierender SQL Server Cluster zunächst auf den aktuellen Server 2022 migriert wird, um anschließend einen Link zur Managed Instance über den integrierten Assistenten herzustellen.
Es wird nach Abschluss aller Schritte eine nahezu Echtzeitsynchronisation der Daten erreicht. Im Falle eines Ausfalls des lokalen Clusters kann die Managed Instance über ein manuelles Failover zur primären Datenbank erklärt werden und die Aufgaben bis zur Beseitigung der Störung übernehmen.
Ebenfalls können zusätzliche lesende Anwendungen, wie das Prozessieren eines Data Warehouse Cubes auf die Managed Instance ausgelagert werden oder diese Rolle auch im Notfall übernehmen, bis der lokale Cluster wieder zur Verfügung steht.
Generell bietet der Link seit der Version SQL Server 2022 deutlich verbesserte Flexibilität was die Möglichkeiten einer automatischen Synchronisierung und eines Failovers betrifft, beispielsweise ist es ebenfalls möglich, den Assistenten in die andere Richtung zu starten sollte bereits eine Managed Instance existieren und eine Synchronisation auf ein lokales Cluster gewünscht sein.
Wenn Sie mehr zu diesem Thema erfahren möchten, stehen Ihnen unsere Experten gerne zur Verfügung. Vereinbaren Sie unverbindlich ein Beratungsgespräch über unser Kontaktformular. Wir unterstützen Sie gerne weiter!
