Unermüdlich

von Evgenij Smirnov

In relationalen Datenbanken liegen meist kritische Unternehmensdaten. Entsprechend wichtig ist es, diese Datenspeicherung an den Grundsätzen der Informationssicherheit – Verfügbarkeit, Integrität und Vertraulichkeit – auszurichten. SQL Server setzt seit Version 2012 auf die Always-On-Technologien, um die Verfügbarkeit der Daten zu gewährleisten. Wir zeigen, wie weit Always On in der aktuellen Version 2019 gereift ist.

Die Hochverfügbarkeits-Architektur von Microsoft SQL Server war ursprünglich von zwei Konzepten geprägt: Datenbankreplikation und Failover Clustering. Während die transaktionsbasierte Replikation ein hohes Maß an Verfügbarkeit und Integrität – bis hin zur Multi-Master-Replikation mit mehreren schreibbaren Replikaten – gewährleistet, ist sie nicht mit jedem Datenbankschema und nicht mit jedem Transaktionsverhalten gleichermaßen kompatibel.

Gerade wenn die Datenbank durch eine Drittanbieter-Applikation bereitgestellt wird, sind Sie darauf angewiesen, dass der Hersteller dieser Anwendung die Replikationsfähigkeit in seinem Datenbankdesign berücksichtigt. Failover Clustering ist nach wie vor das Mittel der Wahl, wenn es darum geht, dass der Zugriff auf die Datenbank selbst bei Ausfall eines Datenbankservers keinesfalls unterbrochen werden darf. Dafür existiert von jeder Datenbank, die in solch einer geclusterten Instanz (FCI) bereitgestellt wird, nur eine physische Kopie, die demnach den Single Point of Failure in diesem Konstrukt bildet.

Später kamen das Log Shipping und die darauf basierende Datenbankspiegelung dazu, die ein Aktiv-Passiv-Hochverfügbarkeitsmodell pro Datenbank bietet. Das Konzept erlaubt sogar ein automatisches Failover bei Ausfall der aktiven Kopie. Der Nachteil der herkömmlichen Datenbankspiegelung liegt in der zwingenden Notwendigkeit, der zugreifenden Clientanwendung den Spiegelpartner bereits beim Verbindungsaufbau mitzuteilen. Es ist also nicht möglich, die Spiegelung im Hintergrund auf einen anderen Server umzuleiten, ohne sämtliche zugreifenden Applikationen anpassen zu müssen.

Always On vereint den einfachen und robusten Zugriff auf die Datenbank, wie er beim Failover Clustering üblich ist, mit einer Unabhängigkeit von einem einzigen physischen Speicherort, die sowohl der transaktionellen Replikation als auch der Datenbankspiegelung eigen ist. Sogar eine gewisse Lastverteilung ist mit Always On möglich. Das zentrale Konzept dabei ist die Verfügbarkeitsgruppe (Availability Group, AG).

Microsoft legt in der zugehörigen Dokumentation [1] übrigens großen Wert darauf, dass die korrekte Abkürzung für Always-On-Verfügbarkeitsgruppen "AG" lautet und nicht – wie vielfach im Internet zu lesen ist – "AOAG", "AAG" oder sogar "DAG". Die funktionale Ähnlichkeit zu einer DAG in Microsoft Exchange geht jedoch weit über den gleich verwendeten Begriff der "Verfügbarkeitsgruppe" hinaus.

Bis zu acht Datenbankkopien

Eine Always-On-AG ist ein Zusammenschluss mehrerer SQL-Server, die eine oder mehrere Datenbanken hochverfügbar bereitstellen. Jeder beteiligte Server kann dabei durchaus auch Datenbanken beherbergen, die nicht an der Hochverfügbarkeit durch die AG teilnehmen. Wie bei der herkömmlichen Datenbankspiegelung besitzt eine AG für jede darin enthaltene Datenbank eine einzige schreibbare Kopie (Primary). Zusätzlich können bis zu acht weitere Kopien der Datenbank (Secondary) vorgehalten werden, die entweder zum reinen Lesezugriff angeboten werden oder nur als Failover-Partner ohne Clientzugriff dienen.

Auch für Datenbanksicherungen lässt sich eine sekundäre Kopie verwenden, um den Server mit der primären Kopie zu entlasten. In SQL Server 2019 können bis zu vier dieser sekundären Kopien synchron laufen und somit ein hohes Maß an Datenintegrität gewährleisten; in der Vorgängerversion waren es lediglich zwei. Die restlichen Kopien sind asynchron, sind also möglicherweise bei Failover verlustbehaftet. Dafür wirken sich diese Kopien nicht auf die Schreibperformance aus, im Gegensatz zu synchronen Kopien, die eine Datenbankänderung erst gegenüber der primären Kopie bestätigen müssen, bevor sie als geschrieben gilt.

Der Zugriff auf die Datenbanken in einer AG wird durch einen gemeinsamen Zugriffspunkt, den sogenannten Listener, bereitgestellt. Dieser läuft auf einem der SQL-Server in der AG und nimmt die Anfragen der Clientanwendungen an. Abhängig von der Art der Anfrage und der Konfiguration der AG leitet der Listener die Anfrage an die primäre Kopie (zum Schreiben oder Lesen) oder an eine der sekundären Kopien (zum Lesen) weiter.

Die gesamte Funktionalität der Always-On-AG erfordert SQL-Server, die mit einer Enterprise-Lizenz versehen sind. Die Standard-Lizenz beinhaltet zwar sogenannte "Basic AG" [2], diese entsprechen jedoch der herkömmlichen Datenbankspiegelung. Sie sind beschränkt auf zwei Kopien einer Datenbank und erlauben keinerlei Zugriff auf die passive Kopie. Auch eine Sicherung von der passiven Kopie ist nicht möglich.

Always On und Failover Clustering

Eine AG lässt sich in zwei Modi betreiben:

- Read-Scale: In diesem Szenario sind ausschließlich manuelle Failover möglich. Es sind hierfür keine besonderen Voraussetzungen notwendig. Dieser Modus ist, wie der Name vermuten lässt, gut dafür geeignet, die Lesezugriffe der Anwendungen auf mehrere SQL-Server zu verteilen, während die primäre Kopie für die Schreibzugriffe reserviert ist. Der Listener kann nur mit einer fixen IP-Adresse konfiguriert werden.

- Full AG: Dieser Modus unterstützt manuelle und automatische Failover sowie eine dynamische Konfiguration des Listeners mit einer DHCP-Adresse. Um dies zu ermöglichen, müssen Sie die SQL-Server, die die AG bilden, zu einem Windows-Server-Failover-Cluster zusammenfassen. Im Falle der Bereitstellung von SQL auf Linux müssen Sie die Cluster-Funktionalität mittels Pacemaker [3] oder einer gleichwertigen Technologie herstellen.

Für die Funktion der AG [4] im vollständigen Modus ist es nicht erforderlich, dass die SQL-Server als Failover-Cluster-Instanzen (FCI) ausgeführt werden. Das Clustering-Feature dient ausschließlich dem Erkennen von Ausfällen und dem Verschieben der aktiven Ressourcen, inklusive des Listeners, auf einen aktiven Knoten. Sie können aber den bereits eingerichteten Failover-Cluster dafür verwenden, die Verfügbarkeit einer Kopie (in der Regel der primären) zu erhöhen. Dafür müssen Sie dem Cluster einen clusterfähigen Speicher hinzufügen und eine geclusterte SQL-Instanz erstellen, die Teil der AG wird und eine Datenbankkopie hostet.

Always On Availability Group erstellen

Um eine vollständige AG aus Windows-basierten SQL-Servern anzulegen, erstellen Sie als Erstes auf die übliche Art einen Failover-Cluster entsprechend der gewünschten RZ-Topologie. Planen Sie die Anzahl und Platzierung der synchronen und asynchronen Kopien und deren Verwendung für die Sicherung der Datenbanken.

Der Cluster kann sich in einem IP-Subnetz befinden oder auf mehrere Subnetze verteilt sein. Dies ist besonders wichtig, wenn Ihre Hochverfügbarkeits-Strategie auf Multi-Site-Failover aufbaut. Denken Sie daran, die Subnetz-Topologie in Ihrem Active Directory abzubilden. Der Cluster braucht zwingend einen administrativen Zugriffspunkt und einen Datenträger- oder Dateifreigabenzeugen.

Bei der Vorprüfung der Cluster-Fähigkeit können Sie den Storage-Teil normalerweise auslassen, da die AG keinen Shared Storage verwendet. Falls Sie jedoch vorhaben, geclusterte SQL-Instanzen oder einen Datenträgerzeugen einzusetzen, sollten Sie den Shared Storage ebenfalls überprüfen lassen und etwaige Warnungen korrigieren.

Installieren Sie die SQL-Datenbank-Engine auf allen Cluster-Knoten. Für die grundlegende Funktionalität der AG ist es nicht zwingend erforderlich, dass die Datenbankdienste unter ein und demselben Service-Account laufen. Dies bringt im Betrieb und bei der Absicherung der Kommunikation mit der AG jedoch große Vorteile mit sich, daher sollten Sie es von vornherein so einrichten. Besonders sicher und praktisch ist es, für Ihre AG ein Group Managed Service Account (gMSA) zu verwenden. Um dieses auf den Servern zu registrieren, müssen Sie auf jedem Knoten das Active-Directory-Modul für PowerShell aus dem RSAT-Feature installieren.

Bevor Sie nun eine AG erstellen können, müssen Sie bei jeder Instanz die Unterstützung für Always On aktivieren. Diesen Schritt erledigen Sie im SQL Server Configuration Manager in den Eigenschaften des Datenbankdienstes für die entsprechende Instanz. Im Feld "Windows Server Failovercluster" sollte dabei bereits der Name Ihres soeben erzeugten Clusters stehen.

Sollten Sie die SQL-Installation und die Aktivierung von Always On bereits vor dem Beitritt zum Cluster vorgenommen haben, werden Sie in diesem Feld einen falschen Wert sehen. Um dies zu korrigieren, müssen Sie den Haken für die Always-On-Unterstützung herausnehmen, den SQL-Server-Datenbankdienst neu starten und den Haken anschließend wieder setzen, gefolgt von einem weiteren Neustart des Dienstes. Das Aktivieren und Deaktivieren der Always-On-Funktionalität ist auch mit PowerShell möglich. Dafür stehen Ihnen sowohl die Funktionen aus dem offiziellen SqlServer-Modul als auch aus dem Community-Modul dbatools [5] zur Verfügung.

Bevor Sie nun mit dem Anlegen der AG fortfahren, müssen Sie noch mindestens eine Datenbank auswählen oder einrichten, die in der neuen AG gehostet werden soll. Soll die AG mehrere Datenbanken hochverfügbar bereitstellen, können Sie gleich mit allen Datenbanken starten oder die AG vorerst mit einer Datenbank erzeugen und später weitere Datenbanken hinzufügen. Erstellen Sie von jeder betroffenen Datenbank eine vollständige Datensicherung.

Je nach Größe der Datenbanken und der verfügbaren Bandbreite können Sie diese Sicherung auf die restlichen Knoten kopieren und für das Seeding verwenden. Das Verfahren ist dabei identisch mit der Einrichtung der Datenbankspiegelung. Bei kleineren Datenbanken und schnellen Netzwerkverbindungen können Sie das Seeding der sekundären Replikate auch "on-the-fly" während der Einrichtung Ihrer AG durchführen lassen. Für die Anlage der AG stehen Ihnen mehrere Wege zur Verfügung:

- Der grafische Assistent im SQL Server Management Studio (SSMS)

- PowerShell-Cmdlets aus dem offiziellen Modul

- PowerShell-Cmdlets aus dem Community-Modul "dbatools"

Beim Hinzufügen der Knoten sollten Sie FQDNs statt Computernamen verwenden, das erweist sich später als nützlich. Fügen Sie der fertigen AG bei Bedarf weitere Datenbanken hinzu. Jede Datenbank muss, wie zuvor beschrieben, über ein Vollbackup verfügen. Der Seeding-Modus ist allerdings pro Knoten und nicht pro Datenbank gesetzt, sodass Sie eventuell auch dann das Backup auf die sekundären Knoten kopieren müssen, wenn die Bandbreite das automatische Seeding hergäbe.

Listener einrichten

Ist die AG fertig, verfügt sie normalerweise noch über keinen Listener. Der Assistent im SSMS bietet zwar die Möglichkeit an, einen Listener gleich mit anzulegen, sie ist jedoch standardmäßig nicht ausgewählt. Die Anlage des gewünschten Listeners kann ebenso wie die Erzeugung der AG selbst mit allen oben aufgezählten Mitteln erfolgen. Denken Sie daran, dass in einem Multisite-Cluster der Listener entweder eine dynamische oder mehrere statische IP-Konfigurationen haben muss, um die Konnektivität in jedem Standort sicherzustellen.

Die AG und ihr Listener existieren im Cluster als Cluster-Rolle (Ressourcengruppe) und Namens- beziehungsweise IP-Ressource. Sie sollten diese Ressourcen nach Möglichkeit nicht manuell mit den Mitteln des Failover Clustering zwischen den Knoten verschieben, sondern die Platzierung der Ressourcen der Cluster-Logik überlassen.

In den Eigenschaften jeder sekundären Kopie haben Sie bei der Anlage der AG festgelegt, ob sie für den Lesezugriff zur Verfügung steht. Standardmäßig wird der Listener die Lesezugriffe nach einem Round-Robin-ähnlichen Algorithmus auf die zulässigen sekundären Kopien verteilen. Seit SQL Server 2016 können Sie dieses Verhalten mit der sogenannten "Read-Only-Routing-Liste" beeinflussen. In dieser Liste legen Sie für jeden Knoten fest, welche sekundären Kopien mit welcher Priorität für den Lesezugriff angesprochen werden sollen, wenn der jeweilige Knoten gerade aktiv ist.

Um die Read-Only-Routing-Liste definieren zu können, müssen Sie für jeden Knoten eine Read-Only-Routing-URL im Format "tcp://undlt;IP oder FQDNundgt;:undlt;Portundgt;" eintragen, wobei der Port nicht bereits durch andere Dienste belegt sein darf. Seit SSMS 18 können Sie dies komplett mit der GUI erledigen. Den Status Ihrer AG überwachen Sie im Management Studio mittels eines übersichtlichen Dashboards. Übersichtlich bleibt es allerdings nur, solange Sie nicht zu viele Datenbanken in der AG hosten.

Übertragungen verschlüsseln

Es ist heutzutage eine Selbstverständlichkeit, die Zugänge zu den wichtigen Unternehmensdaten mittels TLS-Verschlüsselung abzusichern. Microsoft SQL Server beherrscht diese Disziplin schon länger und auch eine Always-On-AG bildet hier keine Ausnahme. Sie benötigen lediglich ein Serverzertifikat, das den FQDN des Listeners im Subject Name enthält. Theoretisch bietet der SQL Server Configuration Manager in der aktuellen Version sogar einen Assistenten, der das Importieren dieses Zertifikats auf mehrere Knoten gleichzeitig erlaubt. In der Praxis jedoch scheitert dieser Versuch mit der Fehlermeldung, dass der Name im Zertifikat nicht mit dem Hostnamen übereinstimmt.

Dieser Fehler ist bekannt aus der Einrichtung von geclusterten Instanzen (FCI) in den früheren SQL-Versionen und kann auf die gleiche Art behandelt werden: Importieren Sie das Zertifikat in den Computer-Zertifikatsspeicher auf jedem Knoten der AG. Öffnen Sie anschließend die Konsole "certlm.msc" und geben Sie dem Service-Account, unter dem die SQL-Datenbank-Engine ausgeführt wird, Zugriff auf den privaten Schlüssel des Zertifikats.

Schreiben Sie den SHA-1-Fingerabdruck des Zertifikates in den Wert "Certificate" unter dem Registry-Schlüssel "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ undlt;INSTANZ-IDundgt; \ MSSQLServer \ SuperSocketNetLib". Starten Sie anschließend alle Instanzen nacheinander neu, was einen Failover der aktiven Kopien in der AG auslöst. Den Erfolg dieser Konfiguration können Sie mit der folgenden SQL-Abfrage gegen die Management-View "dm_exec_ connections" kontrollieren:

War die Verschlüsselung erfolgreich, steht in der letzten Spalte der Wert "TRUE".

Eine weitere wichtige Maßnahme zur Absicherung Ihrer SQL-Umgebung ist die Verwendung von Kerberos für die Authentifizierung der Clientverbindungen. Hierfür müssen die Service Principal

Names (SPN) der einzelnen Instanzen exakt mit dem FQDN im Clientaufruf übereinstimmen. Always On weist hier eine Besonderheit auf: Die Authentifizierung erfolgt einmal gegen den Listener und anschließend noch einmal gegenüber der Instanz, zu der der Zugriff umgeleitet wird. Daher muss die Kerberos-Konfiguration für eine AG wie folgt aussehen:

- Alle Instanzen innerhalb der AG laufen unter demselben Service-Account beziehungsweise gMSA.

- Dieses Konto bekommt manuell folgende SPNs zugewiesen:

MSSQLSvc/undlt;Listener-FQDNundgt;,

MSSQLSvc/undlt;Listener-FQDNundgt;:

undlt;Listener-Portundgt; und

MSSQLSvc/undlt;Listener-FQDNundgt;:

undlt;Instanz-Portundgt;

sowie für jede Instanz:

MSSQLSvc/undlt;Instanz-FQDNundgt; und

MSSQLSvc/undlt;Instanz-FQDNundgt;:

undlt;Instanz-Portundgt;

Haben Sie die Instanzen bei der Konfiguration der AG als Hostnamen statt FQDN erfasst, müssen Sie dies in den instanzspezifischen SPNs berücksichtigen. Zur Kontrolle können Sie wieder die dynamische Management-View (DMV) "dm_exec_connections" heranziehen. Der Befehl

sollte in der letzten Spalte "KERBEROS" als Wert liefern.

Datensicherung in der AG

Beim Anlegen Ihrer AG konnten Sie bestimmen, ob die Sicherung der Datenbanken von der aktiven Kopie, von einer beliebigen Kopie oder nur von einer sekundären Kopie durchgeführt werden soll. Damit platzieren Sie die Last, die durch die Datensicherung auf dem Datenbankserver entsteht, dort, wo sie die produktive Performance am wenigsten beeinträchtigt.

Eines müssen Sie jedoch in allen Konstellationen zwingend berücksichtigen: Die der AG-Replikation zugrunde liegende Datenbankspiegelung ist eine permanent laufende Datenbanksicherung (der primären Kopie) und Wiederherstellung (der sekundären Kopien). Ein Backup-Job, der den Backup-Stempel setzt oder Transaktionsprotokolle unreflektiert abschneidet, würde die Replikation stören. Daher werden für eine AG folgende Backup-Modi unterstützt:

- Vollbackups, differenzielle Backups und Log-Backups der primären Kopie.

- Vollbackups im Modus "WITH COPY_ONLY" und Log-Backups von sekundären Kopien.

Richten Sie die SQL-Sicherung in einer AG mit einem Wartungsplan ein und konfigurieren die AG mit der Standardeinstellung "sekundäre Kopie bevorzugen", läuft der Wartungsplan auf der primären Kopie zwar fehlerfrei durch, erzeugt aber keine Datenbanksicherung. Der SQL-Code, den ein Wartungsplan generiert, beinhaltet in diesem Fall nämlich eine Prüfung, ob die für die Sicherung angesprochene Kopie tatsächlich die präferierte ist.

Fazit

Wenn Sie über SQL-Server-Enterprise-Lizenzen verfügen, können Sie mit Hilfe von Always-On-Availability-Groups eine robuste, performante und flexible Datenbankplattform für Ihre Anwendungen

bereitstellen. Bedenken Sie dabei den Storage-Bedarf, die Backup- und Failover-Topologie, das Read-Only-Routing wie auch das Monitoring.

SQL Server 2019 Always On