Weiterlesen mit NEWS. Jetzt testen.
Lesezeit ca. 9 Min.

Unermüdlich


IT Administrator - epaper ⋅ Ausgabe 8/2021 vom 30.07.2021

SQL Server 2019 Always On

Artikelbild für den Artikel "Unermüdlich" aus der Ausgabe 8/2021 von IT Administrator. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: IT Administrator, Ausgabe 8/2021

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

Weiterlesen
epaper-Einzelheft 10,99€
NEWS 30 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von IT Administrator. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1000 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 8/2021 von Negatives Testergebnis zum Zweiten. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Negatives Testergebnis zum Zweiten
Titelbild der Ausgabe 8/2021 von Jetzt Preview von Windows 11 testen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Jetzt Preview von Windows 11 testen
Titelbild der Ausgabe 8/2021 von OTRS zurück in der Community. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
OTRS zurück in der Community
Titelbild der Ausgabe 8/2021 von Kubernetes macht Sorgen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Kubernetes macht Sorgen
Titelbild der Ausgabe 8/2021 von Die Würfel sind gekommen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Die Würfel sind gekommen
Titelbild der Ausgabe 8/2021 von »Es reicht nicht mehr, nur zu wissen, ob die Infrastruktur verfügbar ist«. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
»Es reicht nicht mehr, nur zu wissen, ob die Infrastruktur verfügbar ist«
Vorheriger Artikel
Gemeinsam stark
aus dieser Ausgabe
Nächster Artikel Buchbesprechung
aus dieser Ausgabe

... 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 Windowsbasierten 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ägeroder 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) - T-SQL [6] - 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://<IP oder FQDN>:<Port>" 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 \ <IN- STANZ-ID> \ MSSQLServer \ Super - SocketNetLib". 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:

SELECT client_net_address,

net_transport, local_tcp_port,

encrypt_option

FROM sys.dm_exec_connections00

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/<Listener-FQDN>, MSSQLSvc/<Listener-FQDN>: <Listener-Port> und MSSQLSvc/<Listener-FQDN>: <Instanz-Port> sowie für jede Instanz:

MSSQLSvc/<Instanz-FQDN> und MSSQLSvc/<Instanz-FQDN>: <Instanz-Port>

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.

SELECT client_net_address,

net_transport, local_tcp_port,

auth_scheme

FROM sys.dm_exec_connections

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 CO- PY_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.

(dr)

Link-Codes

[1] SQL Always On AG in Microsoft Docs l8z61

[2] Basic AG l8z64

[3] Linux Pacemaker l8z62

[4] Failover Clustering und AG l8z63

[5] dbatools l8z66

[6] Create Availability Group l8z65

[7] Backup der AG l8z67