Eine der am häufigsten von Kunden nachgefragten Funktionen in SQL waren bereits seit SQL 2012 Always On-Verfügbarkeitsgruppen. Dadurch werden Desaster Recovery und Hochverfügbarkeit auf ein neues Niveau gehoben, da mehrere Kopien der Datenbank verfügbar sind, schreibgeschützte Workloads möglich sind und Verwaltungsaufgaben, wie etwa Backups, ausgelagert werden können.
In dieser Schritt-für-Schritt-Anleitung wird die Erstellung einer SQL Server 2022 Always On-Verfügbarkeitsgruppe beschrieben, um eine hohe Verfügbarkeit geschäftskritischer Datenbanken sicherzustellen.
Voraussetzungen
Damit eine Availability Group einwandfrei funktioniert, müssen einige Voraussetzungen bezüglich der Windows Host und SQL Server Instanzen erfüllt sein:
- Es darf kein Domaincontroller als Knoten für unsere Availability Group konfiguriert sein.
- Das Betriebssystem darf nicht älter als Windows 2012 sein.
- Auf jedem Knoten des Clusters muss ein Windows Server Failover Cluster (WSFC) installiert sein.
Als Voraussetzungen für die SQL Server Instanzen gilt, dass
- jedes Replikat einen Knoten im WSFC darstellt,
- keines der Replikate einen Active Directory Dienst ausführt,
- jede Instanz derselben SQL Server Version entspricht.
Hinzufügen des Windows Failover Clusters auf allen Replikaten
Hierfür gehen wir auf all unseren Servern, welche wir als Ziel der Replikation verwenden wollen, wie folgt vor:
- Wir öffnen den Server Manager auf dem gewünschten Host
- Anschließend klicken wir auf Add roles and features
Als installation type wählen wir Role-based or feature-based installation aus
In der Server selection wählen wir unseren aktuellen Server aus
Wählen in der Feature Liste die Option Failoverclustering aus.
Sollten Sie auf Ihrer Maschine noch nicht über das .NET Framework 3.5.1 oder höher verfügen, setzen sie diesen Haken ebenfalls in der Feature Liste.
Mit einem finalen Klick auf Installieren werden alle ausgewählten Features installiert.
Haben wir diese Schritte auf allen gewünschten Hosts durchgeführt, können wir damit beginnen, das WSFC auf unserem primären Replikat zu konfigurieren.
Konfigurieren des WSFC auf dem primären Replikat
Hierfür öffnen wir den Server Manager auf dem primären Replikat und wählen unter Tools am oberen rechten Bildschirmrand den Failover Cluster Manager aus und klicken auf Validate Configuration
Hier tragen wir nun die Namen aller Server ein, welche wir in unseren Failover Cluster aufnehmen wollen.
Nach einem Klick auf Weiter kommen wir auf die Seite Testing Options. Hier wählen wir Alle Tests durchführen. Sollten hier Warnmeldungen auftreten, so stellen Sie sicher dass Sie mögliche Fehler korrigieren, da sonst Microsoft den Support ablehnt.
Nachdem nun die Validierung und die Zusammenfassung abgeschlossen sind, öffnet sich der Clustererstellungs-Assistent. Im Register Zugriffspunkt für die Clusterverwaltung geben wir nun den gewünschten Namen für unser Cluster an.
Konfiguration und Einrichtung der Always On Availability Group
Für die Installation müssen wir die einzelnen SQL Server Instanzen konfigurieren. Hierfür öffnen wir den SQL Server Configuration Manager auf jedem Replikat. Anschließen klicken wir mit einem Rechtsklick unter SQL Server Services auf den Dienst unserer SQL Server Instanz und wählen Eigenschaften aus. Wir öffnen nun den AlwaysOn High Availablity Reiter und setzen einen Haken bei Enable Always On Availability Groups.
Anschließend starten wir den SQL Server Dienst neu, damit unsere Änderungen angewendet werden.
Als nächsten Schritt stellen wir sicher, dass alle unsere Datenbanken im Full Recovery Mode sind.
Nun führen wir auf allen Datenbanken, welche wir in unsere Availability Group aufnehmen wollen, eine Sicherung der Datenbankund des Transaktionslogs durch.
Auf unserer primären Instanz öffnen wir nun das SQL Server Management Studio (SSMS) und klappen den AlwaysOn High Availability Ordner aus. Mit einem Rechtsklick wählen wir nun Availability Groups und anschließend New Availability Group Wizard aus.
Hier spezifizieren wir als Erstes den AlwaysOn Group Namen. Ebenfalls setzen wir hier einen Haken für die Database Level Health Detection.
Nun wählen wir all die Datenbanken aus, die in unsere Availability Group aufgenommen werden sollen:
Neben jeder Datenbank befindet sich ein blauer Link, der angibt, ob eine Datenbank bereit ist, in unsere Gruppe aufgenommen zu werden oder nicht. Wenn der Link nicht "Meets prerequisites" lautet, bestehen noch Fehler. Mit einem Klick auf den Link, erhalten wir hierzu eine Nähere Erläuterung. Ein typischer Fehler könnte sein, dass zu dem Kandidaten noch keine Sicherung existiert.
Als Nächstes gelangen wir auf die Specify Replicas Seite, in welcher wir nun alle Replikate angeben, welche Teil unserer Availiability Group sein sollen. Mit einem Klick auf add Replica fügen wir diese hinzu:
Unter dem Reiter Endpoint am oberen Rand geben wir den Port 5022 an. Sollten Sie über mehrere SQL Server Instanzen auf einem Server verfügen, muss hier gegebenenfalls ein anderer Port angegeben werden.
Der nächste Reiter ist für die Sicherungseinstellungen. Hier können wir auswählen, wo unsere Sicherungen ausgeführt werden sollen.
Prefer Secondary
Gibt an, dass Sicherungen auf einem sekundären Replikat erfolgen müssen, außer wenn es sich beim primären Replikat um das einzige Onlinereplikat handelt. In diesem Fall muss die Sicherung auf dem primären Replikat erfolgen. Dies ist die Standardoption.
Secondary only
Gibt an, dass Sicherungen nie auf dem primären Replikat ausgeführt werden dürfen. Wenn es sich beim primären Replikat um das einzige Onlinereplikat handelt, darf keine Sicherung erfolgen.
Primary
Gibt an, dass die Sicherungen immer auf dem primären Replikat erfolgen müssen. Diese Option ist hilfreich, wenn Sie Sicherungsfunktionen benötigen, z. B. das Erstellen differenzieller Sicherungen, die nicht unterstützt werden, wenn die Sicherung auf einem sekundären Replikat ausgeführt wird.
Any Replica
Gibt an, dass Sicherungsaufträge die Rolle der Verfügbarkeitsreplikate ignorieren sollen, wenn Sie das Replikat zum Durchführen der Sicherungen auswählen. Sicherungsaufträge können andere Faktoren auswerten, wie z. B. die Sicherungspriorität jedes Verfügbarkeitsreplikats in Verbindung mit seinem Betriebszustand und Verbindungsstatus.
Der nächste Reiter auf der Seite ist der für den Listener. Hier wählen wir Create an availability group listener. Hier geben wir den DNS-Namen ein, der anschließend in der Anwendungsverbindungszeichenfolge verwendet wird. Wir vergeben den Port 1433 und geben die IP-Adresse für unseren Listener ein. Dies sollte eine nicht verwendete IP-Adresse in Ihrem Netzwerk sein:
Der letzte Reiter ist Read-Only Routing. Dies wird verwendet, wenn SQL Server schreibgeschützte Verbindungen zu einem sekundären Replikat leiten soll. Diese Funktion muss über eine Routing-URL und eine schreibgeschützte Routing-Liste verfügen. Innerhalb des Assistenten können wir die Routing-URL angeben, die Routing-Liste können wir jedoch zu diesem Zeitpunkt noch nicht angeben. Um die Routingliste anzugeben, müssen wir die Eigenschaften der AlwaysOn-Gruppe nach ihrer Erstellung öffnen oder mit TSQL oder PowerShell hinzufügen
Wir fahren fort und klicken auf Next.
Als Nächstes kommen wir auf die Seite Select Initial Data Synchronization. Wir wählen hier die Option Automatic seeding aus, damit SQL Server automatisch auf allen Replikaten die gewünschten Datenbanken erstellt.
Automatic seeding
SQL Server erstellt die sekundären Replikate für jede Datenbank in der Gruppe automatisch. Automatisches Seeding erfordert, dass die Pfade für Daten- und Protokolldateien für jede SQL Server-Instanz der Gruppe identisch sind. Verfügbar auf SQL Server 2016 (13.x) und höher.
Full database and log backup
Für jede primäre Datenbank werden mit der Option Vollständige Datenbank- und Protokollsicherung mehrere Vorgänge in einem Workflow ausgeführt: Erstellen einer vollständigen und Protokollsicherung der primären Datenbank, Erstellen der entsprechenden sekundären Datenbanken durch Wiederherstellen dieser Sicherungen auf jeder Serverinstanz, die ein sekundäres Replikat hostet, und Verknüpfen jeder sekundären Datenbank mit der Verfügbarkeitsgruppe.
Join only
Aktivieren Sie diese Option nur, wenn die neuen sekundären Datenbanken bereits auf jeder Serverinstanz vorhanden sind, die ein sekundäres Replikat für die Verfügbarkeitsgruppe hostet.
Wenn Sie Nur verknüpfen auswählen, versucht der Assistent jede vorhandene sekundäre Datenbank mit der Verfügbarkeitsgruppe zu verknüpfen.
Skip initial data synchronization
Aktivieren Sie diese Option, wenn Sie eigene Datenbank- und Protokollsicherungen für jede primäre Datenbank ausführen und diese auf jeder Serverinstanz, die ein sekundäres Verfügbarkeitsreplikat hostet, wiederherstellen möchten. Nach dem Beenden des Assistenten müssen Sie jede sekundäre Datenbank auf jedem sekundären Replikat verknüpfen.
Als letzten Schritt stellen wir sicher, dass unsere Validierungsprüfungen erfolgreiche Ergebnisse liefern. Ist dies der Fall, haben wir es fast geschafft.
Auf der Summary Seite können wir nun noch einmal überprüfen, ob unsere Konfiguration korrekt ist.
Ist hier nun alles zu unserer Zufriedenheit und treten keine weiteren Fehler auf, können wir unsere Availability Group mit einem Klick auf Finish erfolgreich erstellen.
Mit einem Rechtsklick auf unsere Availability Group können wir die Option Show Dashboard auswählen. Es öffnet sich ein von SSMS bereitgestelltes Dashboard, mit dem wir den Zustand und die Gesundheit unserer Group überwachen können:
Fazit
In dieser Schritt-für-Schritt Anleitung haben wir gelernt, wie wir eine Always On High Availability Group einrichten.
Wenn Sie mehr zu diesem Thema erfahren möchten, stehen Ihnen unsere erfahren Expert:innen bei Rückfragen zur Verfügung. Kontaktieren Sie uns dafür gerne über unser Kontaktformular.
