Im Folgenden finden besonders interessierte Leser ausführliche Informationen zu den im Kurs behandelten Themen.

Am 1. Tag    Jeder Teilnehmer baut seinen eigenen SQL 2022 Always On Multisubnet Cluster auf.

Am 2. Tag    Grundlagen 2022 Always On

Am 3. Tag    Advanced Administration 2022 Always On

Für Always On wird dabei ein Windows Server 2022 Failover Cluster aufgebaut und das Quorum sinnvoll konfiguriert. Es handelt sich dabei um einen Multisubnet Cluster, der sich über zwei Subnetze erstreckt. Auch wenn der Cluster mit 4x Nodes genügend Stimmen hat, wird ein File Shared Witness konfiguriert um eine ungerade Anzahl an Stimmen zu haben. Wichtig ist dabei zu verstehen unter welchen Bedingungen es bei Always On zu einem Failover kommt. Auf dem Windows 2022 Failover Cluster wird SQL Server 2022 auf jedem Node installiert und anschliessend für Always On eingerichtet.

Es wird gezeigt, wie Always On zu konfigurieren ist und eine AAG (Always On Availability Group) erstellt wird. Dabei wird ein Knoten asynchron angebunden und die restlichen synchron. Bei den asynchronen Knoten wird dabei Kompression für die Replikation aktiv sein, bei den synchron angebundenen Knoten keine Kompression verwendet. Die Initialisierung der Sekundärdatenbanken erfolgt per Automatic Seeding oder über ein SMB Network Share. Dabei wird der Replikations-Traffic auf ein zweites Netzwerkinterface gelegt und die entsprechenden Endpunkte konfiguriert (auch so, dass jeweils AES Verschlüsselung für die Replikation verwendet wird).

Database Health Detection ermöglicht dabei auch den Failover, wenn es zu Problemen auf Datenbankebene kommt, der Cluster selbst aber stabil läuft (beispielsweise wenn eine Datenbank inkonsistente Dateien hat und in den Suspect State wechselt).

Mit Always On ist es möglich, auch DataLoss Protection einzusetzen um sicherzustellen, dass bestätigte Transaktionen garantiert auf anderen Knoten synchronisiert werden.

Für Backups lässt sich weiterhin eine Reihenfolge einstellen, um festzulegen auf welchen Replicas Backups bevorzugt durchgeführt werden.

Bei Erstellung des Always On Listeners muss beachtet werden, dass dieser nur auf dem Public Netz antwortet. Durch den Listener kann sich das Failover Verhalten verändern, da die IP des Listeners eine abhängige Resource des Clusters wird. Der Listener verfügt über einen eigenen Eintrag im Active Directory und für funktionierende Kerberos Authentication mit dem Listener muss der Service Principal Name des Listeners richtig gesetzt werden.

Es wird gezeigt wie Always On für Performance Optimierungen genutzt werden kann in dem Reports, Backups und andere Lesevorgänge auf Secondary Replicas weitergeleitet werden. Dabei kann die Weiterleitung über Read-Intent Read Only Routing per Routing Tabelle über den Listener vollautomatisch erfolgen. Weiterhin ist es mittlerweile möglich hier auch einen Load Balancer zu konfigurieren, welcher die Leseanfragen automatisch per Round Robin Verfahren auf die Secondary Replicas verteilt.

Sobald Always On läuft wird der automatische und geplante Failover demonstriert und getestet. Weiterhin wird das Monitoring über das Always On Dashboard (im Hintergrund mit SQL Server Policies) behandelt. Erweitertes Performance Monitoring über die Zeit ist mittlerweile mit der Always On Latency Data Collection möglich.

Ein Teil des Always On Clusterkurses ist die Verwendung von Registered Servers, um alle Knoten einer AAG zentral zu verwalten. Hierbei wird auch gezeigt, wie man eingetragene Registered Servers direkt per Powershell ansprechen kann, um T-SQL Scripte auf allen Knoten durchzuführen und so beispielsweise die Konfiguration der einzelnen Knoten zu ändern.

Zusätzlich werden die einzelnen Knoten der AAG per Linked Server verbunden, um erweiterte Abfragen über Instanzgrenzen hinweg durchzuführen. Dabei ist es wichtig Kerberos Delegation richtig einzustellen, damit sich die Linked Server auch direkt in SQL Server Agent Jobs einsetzen lassen. Mittels Linked Server ist es dann möglich ein Konfigurationsabgleich zwischen den einzelnen Knoten durchzuführen.

Weiterhin erlauben Linked Server direkt ein Vergleich von SIDs, die auf allen Knoten einer AAG gespeichert sind. Auf diese Weise lassen sich fehlende Logins ermitteln aber auch ganze Server Roles die auf einzelnen Servern nicht vorhanden sind. Per T-SQL lassen sich fehlende Logins und Server Rollen erstellen.

Ein weiterer wichtiger Punkt des Kurses ist die vollautomatische Migration von Server Objekten. Dabei werden Powershell Tools eingesetzt um automatisch Logins und Server Rollen auf alle Knoten einer AAG zu migrieren. Ebenfalls sollen Berechtigungen von Logins sowie Server Rollen übernommen und synchronisiert werden. Um dies zu bewerkstelligen werden T-SQL Cursor erklärt und verwendet.

Zuerst läuft die Automatisierung dabei über SQL Server Agent Jobs ab. Es wird dann weiterhin gezeigt, wie die Migration über Server Trigger arbeitet und wie mittels DDL Server Trigger Jobs asynchron und verzögert gestartet werden.

Zur automatischen Migration von Server Objekten in Always On Umgebungen gehört auch das Kopieren von Jobs selbst. Dabei ist es oft wichtig nur bestimmte Job Categories zu kopieren oder auszulassen.

Always On unterstützt mit SQL Server 2022 jetzt auch Contained AAGs, mit denen vollautomatisch Logins und Jobs auf zweite Knoten repliziert werden können. Können eigenen Kopien der Systemdatenbanken für jeweils eine AAG vorgehalten werden.

Backup und Restore Vorgänge müssen unter Always On teilweise anders durchgeführt werden, wie auf klassischen SQL Servern. Dazu wird im Kurs ein Backup Plan für Always On entworfen. Das Backup basiert dabei auf T-SQL. Hier wird auch beachtet, dass die Backups in Always On von Secondary Replicas gezogen werden können. Mit dem Backup wird danach ein kompletter Point in Time Restore durchgeführt.

Bei weiteren Wartungsaufgaben muss Always On ebenfalls berücksichtigt werden. So sind auch Index Rebuild (und Reorganize) sowie Integritätschecks auf Always On Clustern möglich. Diese müssen automatisch auf den jeweils richtigen Knoten durchgeführt werden, was sich mit T-SQL bewerkstelligen lässt. Im Kurs werden dafür auch externe Tools vorgestellt, welche kostenlos und kommerziell einsatzbar sind und den SQL Server optimal ergänzen für den Einsatz in Enterprise Szenarien.

Bei den erweiterten Konfigurationen in Always On Umgebungen wird dabei auf die Database Scoped Configurations eingegangen, welche erstmals Datenbankkonfigurationen erlauben, die auf Secondary Replicas abweichen. Auch wird betrachtet, wie sich Log Files und der Replications-Traffic verhalten. Compression lässt sich dabei nicht nur für die eigentliche Replikation einsetzen sondern auch bei Automatic Seeding per Trace Flag aktivieren.

Um die optimale Performance zu gewährleisten müssen auch Konfigurationen wie Instant File Initialization, richtiges Index Fill Ratio und Indirect Checkpoints beachtet werden. Mit SQL Server 2022 sind Indirect Checkpoints skalierbar.

Ein weiterer wichtiger Teil des Kurses ist das Steuern/Automatisieren und Überwachen von Always On mit T-SQL. Dafür werden verschiedene Dynamic Management Views und skalare sowie Table-Valued Stored Functions für Always On betrachtet. Mit Hilfe dieser Views lassen sich dann auch komplexe Anwendungszenarien umsetzen.

Im Kurs wird dabei gezeigt, wie man auch in Always On Clustern einen Preferred Owner mit automatischem Failback setzen kann (d.h. ein Knoten auf dem der Dienst bevorzugt laufen soll), obwohl dies von Microsoft selbst bei Always On nicht angeboten wird. Dabei muss auch beachtet werden, dass es direkt nach dem Neustart des SQL Servers nicht zu einem Failover kommen sollte.

Zusammen mit Automatic Seeding und T-SQL lässt sich dann ein System schaffen, bei dem neu erstellte Datenbanken auf dem Primary Replica vollautomatisch einer AAG zugewiesen und repliziert werden. Dafür wird auch eine eigene Management Datenbank außerhalb der AAG erstellt, welche die neue Funktionalität verwaltet und überwacht welche Datenbanken noch der AAG hinzugefügt werden müssen.

Seit SQL Server 2019 ist lässt sich die Perfomance in Always On Szenarien deutlich steigern. Hier hat man jetzt die Möglichkeit mit Accelerated Database Recovery (ADR) Transaktionen in sekundenschnelle bei einem Failover zurück zu rollen.

Um Always On zu überwachen werden Extended Events verwendet. Hier lassen sich Fehler schnell lokalisieren. Dabei wird auch die Standard Extended Event Session Alwayson_health betrachtet und optimiert. Ein weiterer wichtiger Punkt ist das Verbinden von Extended Event Informationen verschiedener Knoten, was vor Allem über Linked Server eine besondere Herausforderung darstellt. Hierbei werden nicht nur Extended Event Session Target Files per Merge verbunden, sondern auch per T-SQL über Linked Server direkt XML Daten durchsucht um auf bestimmte Events zu filtern.

Will man Verschlüsselung mittels Transparent Data Encryption für eine Datenbank innerhalb einer AAG einsetzen, müssen entsprechende Zertifikate erzeugt werden. Dabei muss beachtet werden, dass das Zertifikat richtig über alle Server verteilt wird. Im Kurs wird die Transparent Data Encryption für eine Datenbank innerhalb einer AAG aktiviert. Dabei werden auch die entsprechenden Dynamic Management Views betrachtet mit denen ermittelt werden kann, ob die Verschlüsselung bereits vollständig durchgeführt wurde. Auch wird gezeigt, wie man eine bestehende Verschlüsselung wieder deaktiviert und die Database Encryption Keys sicher löscht.

Im Kurs wird auch gezeigt, was im Disaster Fall zu beachten ist, wenn die Mehrheit der Knoten wegbricht und der Cluster dass Quorum verliert. In diesem Fall lässt sich auch ein einzelner Knoten per Disaster Recovery retten und wieder online bringen.

Am Ende des Kurses können die Teilnehmer auch komplexe Always On Cluster verwalten und Automatisierungen für Always On vornehmen. Weiterhin werden Konzepte von T-SQL vorgestellt, welche für die Automatisierung wichtig sind.

Optional, wenn die Zeit reicht, werden Distributed AAGs vorgestellt und implementiert, mit denen sich verschiedene Always On Cluster verbinden lassen.