AlwaysOn Availability Groups · ASPICON Newsarchiv https://www.aspicon.de/news/tag/alwayson-availability-groups/ Database Technology and Service Tue, 21 May 2024 08:03:31 +0000 de hourly 1 https://wordpress.org/?v=7.1.4 https://www.aspicon.de/wp-content/uploads/2023/12/favicon_white_verlauf_2-50x50.png AlwaysOn Availability Groups · ASPICON Newsarchiv https://www.aspicon.de/news/tag/alwayson-availability-groups/ 32 32 Darauf haben wir gewartet: Contained Availability Groups im Microsoft SQL Server 2022 https://www.aspicon.de/news/contained-availability-groups-im-microsoft-sql-server-2022/ Tue, 06 Feb 2024 08:58:20 +0000 https://www.aspicon.de/?p=21183 Wir sind der Meinung, dass viele SQL Server Admins (uns eingeschlossen) schon jahrelang auf diese Verbesserung gewartet haben und möchten heute ein bisschen tiefer in das Thema eintauchen. Wenn du also in der Vergangenheit schon mit Always On Availability Groups gearbeitet hast, solltest du dir die folgenden Zeilen nicht entgehen lassen.

Der Beitrag Darauf haben wir gewartet: Contained Availability Groups im Microsoft SQL Server 2022 erschien zuerst auf ASPICON.

]]>

Darauf haben wir gewartet: Contained Availability Groups im Microsoft SQL Server 2022

Neuerungen wie der SQL Ledger oder die verbesserte Zusammenarbeit des SQL Server 2022 mit Microsoft Azure werden seitens Microsoft intensiv beworben. Allerdings verstecken sich unter der Haube des SQL Server 2022 noch andere coole und vor allem sehr nützliche Features. Eine wesentliche Verbesserung haben wir in unserem Beitrag “Was ist neu und nützlich am MS SQL Server 2022?” im vergangenen Jahr bereits kurz angerissen. Es geht um die Möglichkeit, Instanz-Konfigurationen an eine Availability Group zu binden. Damit kann die Gefahr, Konfigurationsarbeiten zu vergessen, erheblich reduziert werden. Im Microsoft SQL Server 2022 heißt diese ausgesprochen schicke Lösung “Contained Availability Groups”.

Wir sind der Meinung, dass viele SQL Server Admins (uns eingeschlossen) schon jahrelang auf diese Verbesserung gewartet haben und möchten heute ein bisschen tiefer in das Thema eintauchen. Wenn du also in der Vergangenheit schon mit Always On Availability Groups gearbeitet hast, solltest du dir die folgenden Zeilen nicht entgehen lassen.

Wie sah die Arbeit in einer klassischen Always On Availability Group bisher aus?

Um den Vorteil der Contained Availability Groups schätzen zu lernen, braucht man sich nur eine klassische Always On Availability Group vorzustellen. Dort werden alle Inhalte und Eigenschaften einer Nutzerdatenbank zwischen dem primären Replikat und allen sekundären Replikaten synchronisiert. So weit, so gut. Doch es gibt immer auch Inhalte, welche auf Instanzebene angelegt werden. Diese landen somit nicht in der Nutzerdatenbank, sondern in einer Systemdatenbank. Daraus folgt, dass eine Änderung auf dem primären Replikat auch nur dort wirkt. Die gleiche Aktion muss auf allen sekundären Replikaten separat durchgeführt werden. Keine große Sache, möchte man meinen. Doch in der Realität werden die sekundären Replikate sehr oft vergessen. Geschieht dies über einen längeren Zeitraum, geraten die sekundären Replikate (also die Instanzen) in eine Art “Aschenputtel-Situation”. Nach dem Motto “Die guten ins Töpfchen, die schlechten ins Kröpfchen” wird das primäre Replikat in Punkto Konfiguration aktuell gehalten, doch die sekundären Replikate werden regelrecht vernachlässigt und fallen hinten runter.

Folgende Inhalte landen besonders häufig in den Systemdatenbanken und geraten damit leicht in Vergessenheit:

  • Anmeldungen (besonders, wenn es sich um SQL-Konten handelt)
  • Aufträge (Jobs) des SQL Server Agents (vorwiegend mit Benutzerlogik)
  • Verbindungs-Server


Natürlich ist vielen Admins dieses Problem bewusst, was wiederum zu den erstaunlichsten Selfmade-Lösungen geführt hat, wie:

  • Export der relevanten Daten in eine Text-Datei auf Primärseite und anschließender Import jener Text-Datei auf Sekundärseite
    oder
  • Auslesen der relevanten Daten auf der Primärseite und “Wiederholung” der Befehle mittels eines Verbindungsservers


Letzten Endes läuft es darauf hinaus, dass die Inhalte einiger Systemtabellen manuell abgeglichen wurden. Man könnte von einer Art “Synchronisation durch Replikation” für Systemdatenbanken sprechen. Tatsächlich erfolgt ja eine Art Wiederholung auf den sekundären Replikaten. Wie man in jedem Falle sieht, war der Wunsch vieler Administratoren nach einer simplen Lösung für die Konfigurationsgleichheit aller Instanzen groß. Aus unserer Sicht absolut verständlich.

Microsoft hat sich dieser Thematik angenommen und eine ausgesprochen elegante Lösung entwickelt:
Die Contained Availability Groups.

Contained Availability Groups im Microsoft SQL Server 2022: Was ist das eigentlich genau?

Zunächst einmal sei gesagt, dass es sich um vollwertige Availability Groups handelt, so dass man keine lieb gewonnenen Eigenschaften verliert. Alle bekannten Fähigkeiten und Features, wie etwa automatisches Seeding oder die bevorzugten Replikate für Datenbank-Backups, sind enthalten.

Es handelt sich vielmehr um eine Erweiterung zur verbindungsabhängigen Instanzkonfiguration. Sofern man sich gezielt (sprich mittels AG-Listener) zur AG verbindet, erhält man gewissermaßen einen anderen Blick auf die Instanz. Der Clou dabei ist, dass die gewünschten Objekte mit der AG zusammen umziehen. Gewünschte Objekte können in dem Falle sein:

  • Anmeldungen (Konten)
  • Server-Rollen
  • SQL Server Agent Jobs
  • Database Mails
  • und ähnliches


Das heißt also, eine Contained Availability Group kann dedizierte Konfigurationen der Instanz enthalten.

Wie funktioniert der Umgang mit den Contained Availability Groups im Microsoft SQL Server 2022?

Die eigentliche Nutzerdatenbank, welche man in einer Contained Availability Group hochverfügbar betreiben will, wird nicht verändert. Die Methodik basiert vielmehr auf einer Art Layer-Prinzip, wie man es von Views auf Tabellen kennt. Und erneut: Es ist von entscheidender Bedeutung, dass man mit dem Listener der AG verbunden ist. Denn – und das ist der eigentliche Trick – im Hintergrund werden individuelle Exemplare der Systemdatenbanken erstellt. Diese legen sich anschließend transparent über die echten Systemdatenbanken und nehmen die gewünschten Konfigurationen auf. In der Konsequenz bedeutet dies, dass beispielsweise neu angelegte Konten (Anmeldungen/Logins) nicht tatsächlich in der Instanz erstellt werden, sondern stattdessen (durch Umleitung) in einer Art “Schatten-Systemdatenbank”. Und genau diese Datenbanken sind (von Beginn an) Mitglied der Contained Availability Group und wechseln daher bei jedem Failover mit. Das Verfahren ähnelt dabei einer Überlagerung. Verbindet man sich zum Listener der AG, so sieht man die individuellen System-Datenbanken, nicht die echten.

Zum besseren Verständnis:

Man könnte sagen, der SQL Server 2022 “schummelt” beim Anlegen von Anmeldungen. Neue Logins werden nicht in der echten master-Datenbank und neue SQL Server Agent Jobs nicht in der echten msdb-Datenbank abgelegt. Aber: Der Zweck heiligt die Mittel.

Was passiert dann mit der Verwaltung einer individuellen Instanz?

An der Verwaltung einer individuellen Instanz hat sich nichts geändert. Denn der Effekt wirkt nur dann, wenn man sich von Beginn an zum Listener der AG verbindet. Baut man hingegen eine Verbindung zu einer der individuellen Instanzen auf (ohne auf primäre und sekundäre Rollen der AGs zu achten), so bleibt alles beim Alten. Man arbeitet wie gewohnt mit den echten Systemdatenbanken.

Dazu hier eine kurze Gegenüberstellung. Stellt man sich eine simple Always On Umgebung aus zwei Teilnehmern …

1. Standardinstanz auf Host SERVER1

2. Standardinstanz auf Host SERVER2

… vor, welche gemeinsam eine Contained Availability Group namens ALWAYSON bilden, die wiederum den Listener HASERVER verwendet, und legt beispielsweise eine neue SQL-Anmeldung (ein Login) an …

CREATE LOGIN                   [TestAccount]
 WITH  PASSWORD              = 'SimplePassword4Test!',
       DEFAULT_DATABASE      = [master],
       DEFAULT_LANGUAGE      = [English];

… so gilt:

bei Verbindung zu SERVER1
(dediziert)

Die Anmeldung existiert anschließend real in der [master]-Datenbank von Instanz SERVER1.
Die Nutzung dieser Anmeldung ist wie gewohnt möglich.

bei Verbindung zu SERVER2
(dediziert)

Die Anmeldung existiert anschließend real in der [master]-Datenbank von Instanz SERVER2.
Die Nutzung dieser Anmeldung ist wie gewohnt möglich.

bei Verbindung zu HASERVER
(als Listener der AG)

Die Anmeldung existiert in keiner der [master]-Datenbanken, sondern in den “Schattendatenbanken” der Contained Availability Group ALWAYSON, welche von der Synchronisation erfasst werden.

Die Nutzung dieser Anmeldung ist nur im Kontext der Contained Availability Group möglich.

Instanzen verwalten ohne Umgewöhnung

Somit ist sichergestellt, dass man ohne jegliche Umgewöhnung die einzelnen Instanzen verwalten kann. Gleichermaßen können Konfigurationsaspekte gewissermaßen an eine Availability Group gebunden werden, welche auf allen teilnehmenden Replikaten identisch sind. Und genau das ist schließlich auch das Schöne an dieser Implementierung.

Übrigens:

Jene Art der Einbindung geht sogar so weit, dass man nicht nur neue Sachen in den “Schattendatenbanken” anlegen kann. Es ist darüber hinaus möglich, vorhandene Konfigurationen zeitweilig zu überschreiben, indem man bereits existierende Objekte mit gleichnamigen überlagert. So funktioniert der zuvor beschriebene Trick nicht nur mit dem (neu anzulegenden) Konto “TestAccount”, sondern sogar mit dem ab Werk vorhandenen sa-Konto.

Fazit und Ausblick

Zur Arbeit mit Contained Availability Groups gäbe es noch viel mehr zu schreiben. Doch der wichtigste Punkt ist klar: Sie sind eine zuverlässige Möglichkeit, um einzelne Instanzeigenschaften und ‑konfigurationen an einer Availability Group festzumachen. Somit wird die Konfigurationsgleichheit aller Instanzen sichergestellt.

Die neue Art der Contained Availability Groups ist ein höchst willkommener Schritt im Hinblick auf eine langfristig sinnvolle Nutzung des Availability Group Konzepts. Egal, ob man eine Datenbank in einer kleinen und schlichten Availability Group aus zwei Instanzen, oder 20 große Datenbanken in einer Distributed Availability Group aus vier Instanzen betreibt. Es lohnt sich allein schon wegen dieses Features, auf den Microsoft SQL Server 2022 zu wechseln.

Bei Fragen zur Arbeit mit den Contained Availability Groups oder zum Upgrade auf den Microsoft SQL Server 2022 helfen wir dir gern weiter.

Hier findest du weitere Beiträge rund um Microsoft aus unserem News & Insights Bereich.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Darauf haben wir gewartet: Contained Availability Groups im Microsoft SQL Server 2022 erschien zuerst auf ASPICON.

]]> Microsoft SQL Server on VMware – Verfügbarkeit https://www.aspicon.de/news/sql-server-on-vmware-verfuegbarkeit/ Wed, 11 Nov 2020 07:53:00 +0000 https://www.aspicon.de/?p=6209 Der aktuelle DBA Tipp beschreibt Überlegungen zum Betrieb des SQL Servers in einer VMware Umgebung.

Der Beitrag Microsoft SQL Server on VMware – Verfügbarkeit erschien zuerst auf ASPICON.

]]>

Microsoft SQL Server on VMware – Verfügbarkeit

In diesem Tipp werden Überlegungen zum Betrieb von einem hochverfügbaren Microsoft SQL Server auf einer VMware vSphere Plattform beschrieben.

VMware vSphere ist in vielen Unternehmen der Standard für die Betriebssystem-Virtualisierung. Bei der Konfiguration einer virtuellen Maschine für einen Microsoft SQL Server gibt es allerdings ein paar Dinge zu beachten. Und nicht jede Hochverfügbarkeitslösung vom SQL Server ist auch für VMware vSphere geeignet oder sinnvoll.

Anfangsüberlegungen

Zunächst sollte man die Architektur des aktuellen VMware Clusters und der gewünschten Verfügbarkeit des SQL Servers betrachten.

Was soll mit einer hoch verfügbaren Lösung erreicht werden?

  • eine maximal Ausfallzeit von 15 Minuten?

  • ein Patchen der Windows oder Linux Betriebssysteme ohne Ausfall der Instanzen oder Wartungsfenster für die Anwendungen? 

  • Sollen bestimmte Workloads auf weitere, nur lesbare Instanzen ausgelagert werden?

  • Benötigt man, aus Compliance Gründen, eine Möglichkeit zum Betrieb der Instanz in einem anderen Brandabschnitt oder Rechenzentrum?

Wenn man sich diese Fragen am Anfang stellt, sollte die Entscheidung, welche Lösung am Ende in Frage kommt, leichter zu beantworten sein.

VMware Verfügbarkeit vs. SQL Server Verfügbarkeit

Verfügbarkeit durch VMware Cluster

  • Wiederherstellungszeit: ca. 5 – 10 Minuten

  • Installations- und Wartungsaufwand: gering

Wer einen VMware Cluster aus mehreren ESXi Knoten mit einem zentralen SAN oder vSAN betreibt, erhält damit schon eine Verfügbarkeit der virtuellen Maschinen im Falle eines Hardwareausfalls. Falls also einer der Hardware ESXi Knoten ausfällt, wird die virtuelle Maschine auf einem anderen Knoten neu gestartet. Das bedeutet wiederum, dass das komplette Windows System wie nach einem Power Off neu gestartet wird und die Datenbank anschließend auf Integrität vom SQL Server Dienst geprüft wird. Falls zum Zeitpunkt des Ausfalls gerade eine Transaktion ausgeführt wurde, ist diese nicht in der Datenbank. Die Datenbankdateien an sich könnten auch Schaden genommen haben. Eine vernünftige Backup Strategie ist in diesem Fall unabdingbar. Alle Benutzerdatenbanken sollten im vollständigen Wiederherstellungsmodus betrieben werden und Transaktionslog Backups alle 10 – 15 Minuten auf ein externes Laufwerk erfolgen.

Verfügbarkeit durch SQL Server AlwaysOn Failover Cluster

  • Wiederherstellungszeit: ca. 1 – 5 Minuten

  • Installations- und Wartungsaufwand: Mittel bis Hoch (Je nach Anzahl der Instanzen)

Eine der ältesten Hochverfügbarkeitstechniken für den Microsoft SQL Server ist der Failover Cluster. Hierbei wird die Datenbankinstanz auf einem zentralen, gemeinsamen Speicher (SAN) betrieben und 2 oder mehr Knoten, stehen dem Cluster zur Verfügung. Dabei ist die Instanz immer auf einem der Knoten gestartet. Fällt einer der Knoten aus, startet der SQL Server Dienst automatisch auf einem anderen, im Cluster verfügbaren Knoten. Da hierbei der Neustart des gesamten Windows Systems entfällt und nur der SQL Server Dienst gestartet werden muss, verringert sich die Wiederherstellungszeit. 

Durch die Konfiguration des Failover Clusters erhöht sich allerdings die Komplexität des Setups. Aus VMware Sicht muss vermieden werden, dass die zum Cluster gehörenden Knoten auf dem gleichen ESXi Host betrieben werden. Weiterhin muss ein SAN Speicher an die virtuellen Maschinen angebunden werden, was laut Supportrichtlinien entweder über ein RAW Device oder über einen iSCSI Device im Betriebssystem realisiert werden muss.

Verfügbarkeit durch SQL Server AlwaysOn Availability Groups

  • Wiederherstellungszeit: ca. 1 – 30 Sekunden

  • Installations- und Wartungsaufwand: Mittel bis Hoch (je nach Anzahl der Instanzen und Availability Groups)

Eine neuere Verfügbarkeitstechnik (seit dem SQL Server 2012) sind die AlwaysOn Availability Groups. Hierbei werden die Datenbanken zwischen einer oder mehreren Instanzen gespiegelt. d.h. hier wird auf mehreren Servern der Speicherplatz für die Datenbank benötigt, da der jeweils lokale Speicher benutzt wird.
Da die Datenbankkopien jederzeit synchron gehalten werden, ist der Failover innerhalb weniger Sekunden erledigt. Zu Grunde liegt hier ebenfalls ein Windows Server Failover Cluster, der allerdings nur die IP Adresse für den Datenbanklistener zwischen den Knoten verschiebt. 

Durch die Synchronisierung entsteht allerdings zusätzlicher Netzwerktraffic und der Speicher für die doppelte Datenhaltung.

Fazit

Wer eine nur moderate Verfügbarkeit benötigt, sollte auf die zusätzliche Komplexität mit einem Failover Cluster oder Availability Groups verzichten und die Verfügbarkeit durch den VMware Cluster bereitstellen.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Microsoft SQL Server on VMware – Verfügbarkeit erschien zuerst auf ASPICON.

]]>