News zu Microsoft SQL Server
Der Bericht wurde nachträglich um eine Stellungnahme von ASPICON ergänzt. » Hier findest du den Nachtrag.
Schon seit vielen Jahren nutzen wir bei ASPICON Dbvisit Standby Produkte, um bei unseren Oracle Kunden hochverfügbare Datenbank-Infrastrukturen aufzubauen und zu betreiben. Nun bietet Dbvisit mit dem Produkt “Standby MultiPlatform 11.x” auch ein Angebot für SQL Server Installationen und ermöglicht durch den MultiPlatform Ansatz den parallelen Einsatz für Oracle und SQL Server.
Nachdem wir in unserem letzten Beitrag “Dbvisit Standby Multiplatform v11 – we are excited” bereits einen ersten, globalen Blick auf das neue Produkt geworfen haben, wollen wir hier etwas tiefer in den Bereich Standby for SQL Server einsteigen. Wir haben dazu die Software im Bereich SQL Server intern getestet und können schon jetzt sagen:
Es lohnt sich!
Zum Einstieg geben wir einen kurzen Überblick zu der Funktionsweise der “Dbvisit Standby MP”, unserer Testumgebung sowie den notwendigen Vorbereitungsschritten. Danach schauen wir uns den Einsatz bei SQL Server Datenbanken unter Windows und Linux genauer an.
Auf die Installation der SQL Server Datenbanksoftware gehen wir in diesem Artikel nicht näher ein. Stattdessen konzentrieren wir uns hier ganz auf die Konfiguration von Dbvisit Standby MP.
Im Bereich des SQL Servers basiert der technologische Ansatz von Dbvisit auf dem Backup und Restore von Transactionlog Backups. Im Prinzip funktioniert es wie die schon lange vorhandene Lösung des Microsoft SQL Server, das Log Shipping.
Im Gegensatz zum Log Shipping gelingt hier erfreulicherweise die Einrichtung deutlich einfacher und schneller. Doch der wohl entscheidende Vorteil liegt im Handling von Dbvisit Standby MP. Während bei Log Shipping das hin und her switchen durchaus ein wenig herausfordernd ist, kann man mit Hilfe von Dbvisit Standby MP sowohl einen geplanten Switchover, einen automatischen Failover sowie auch ein Switchback machen, wenn die Datenbank wieder auf der ehemals primären Seite betrieben werden soll. Der ganze Prozess kann dazu bequem mit nur wenigen Klicks über eine Weboberfläche eingerichtet werden.
Für unsere Testumgebung haben wir folgende Hosts bereitgestellt:
2 x Hosts mit installiertem SQL Server 2019
Als Voraussetzung sind zum einen die oben erwähnten Maschinen vorzubereiten und zum anderen die entsprechende Datenbanksoftware zu installieren.
Auf den Windows Hosts muss zudem die Firewall angepasst werden. Dabei sind entsprechende Eingangsregeln für folgende Ports zu konfigurieren:
5533/TCP
7890/TCP
Die Software haben wir als Teststellung von der Dbvisit Website bezogen (Zielplattform und Version von Standby angegeben):
WICHTIG: Damit alles funktioniert, ist auf Windows Systemen darauf zu achten, dass entsprechende Dienstbenutzer in der “Local Security Policy” unter “Local Policies” → “User Rights Assignment” für das Recht “Log on as a service” konfiguriert werden.
Nachdem die Software geladen wurde, kann der Installer für das Control Center auf dem entsprechenden Host einfach gestartet werden. Der Installer ist aus unserer Sicht recht selbsterklärend. Hier muss nur darauf geachtet werden, dass eine entsprechende Passphrase gesetzt und sich diese an einem sicheren Ort notiert wird. Diese wird im nächsten Schritt ebenfalls für die Agent Installationen benötigt.
Die Installation der Agents unter Windows gestaltet sich ähnlich einfach wie die Installation des Control Centers. Der Installationswizard führt Schritt für Schritt durch den Prozess. Zu beachten sind die Angaben beim FQDN des Control Centers und beim Agent Host (hier kann auch eine IP Adresse angegeben werden). Wie bereits erwähnt, wird an dieser Stelle noch einmal die Passphrase benötigt, welche bereits im Control Center gesetzt wurde.
Nach Abschluss der Installation startet der Windows Dienst. Dieser ist in der “services.msc” sichtbar.
Nun schauen wir uns die Installation der Agents unter Linux an. Auf den Linux Systemen ist, anders als bei der Installation der Agents unter Windows, vor der Installation ein Ordner vorzubereiten:
Danach kann der Installer über die Shell ausgeführt werden:
Im Anschluss daran müssen, wie auch unter Windows, ein paar Angaben zum Host und zum Control Center gemacht werden.
Nach Abschluss der beschriebenen Schritte sollte auch dieser Host im Control Center angezeigt werden.
An dieser Stelle schauen wir uns zuerst die Konfiguration und das Verhalten von SQL Server Datenbanken unter Windows an.
Zum Testen haben wir hierfür zunächst einige leere Datenbanken angelegt. Um überprüfen zu können, ob etwaige Änderungen auch ordentlich auf die zweite Seite überspielt werden, haben wir für die Replizierung zusätzlich noch eine Datenbank mit veränderbaren Inhalten hinzugefügt. Diese Datenbank haben wir mit dem OpenSource Tool HammerDB erstellt.
Wichtig ist, dass alle Datenbanken im vollständigen Wiederherstellungsmodell betrieben werden. Wenn der Dbvisit Agent korrekt installiert wurde und alle Firewall-Regeln richtig eingestellt sind, wird dieser umgehend im Control Center angezeigt.
Um eine neue Datenbank für die Verfügbarkeit zu konfigurieren, können im Dashboard unter “New Configuration” eine oder mehrere Datenbanken von einer Instanz ausgewählt werden.
Ist die Zielinstanz ausgewählt und werden alle Voraussetzungen erfüllt, kann die Verfügbarkeit initiiert werden.
Nachdem die Konfiguration angelegt wurde, ist diese im Dashboard sichtbar. Hier kann jetzt das Disaster Recovery initiiert werden.
Im sich danach öffnenden Dialog können noch einmal alle Parameter für die Synchronisierung überprüft werden.
Insbesondere die Pfade für die Backupdateien auf beiden Hosts, sowie die Ablageorte der Datenbankdateien auf der Zielinstanz können hier noch einmal angepasst werden. Wenn alles korrekt eingestellt ist, kann der Vorgang über den Button “Start” eingeleitet werden.
Anschließend wird von den Dbvisit Agents ein vollständiges Backup der Datenbank auf der Quellinstanz erstellt und danach auf der Zielinstanz wiederhergestellt. Die Wiederherstellung belässt die Datenbank im RECOVERY Modus, so dass anschließend Transaktionslog Backups eingespielt werden. Je nachdem was für ein Intervall eingestellt wurde, werden ab jetzt regelmäßig Transaktionslog Backups auf der Quelldatenbank erstellt und in der Zieldatenbank eingespielt. Der voreingestellte Standardwert beträgt 300 Sekunden, also 5 Minuten. Er kann aber individuell angepasst werden.
Je nachdem wie groß nun die Datenbank ist, kann dieser Vorgang einige Minuten beanspruchen. Danach ist die Datenbank auf der Zielinstanz - wie hier zu sehen – im Restoring Modus. Das ist der finale Stand. Über die Zeitangabe (in unserem Beispiel “18 seconds”) kann man erkennen, wie lang die letzte Synchronisierung her ist. Das sollte nicht länger als die konfigurierten 300 Sekunden, bzw. die individuell gewählte Intervallzeit sein.
Ein Switchover kann hier vergleichsweise einfach über das Dashboard initiiert werden.
Über den “Actions” Button der jeweiligen Datenbank können verschiedene Aktionen ausgewählt werden, so auch ein “Graceful Switchover”.
Mit dem Drücken des “Start” Buttons wird nun der Switchover Vorgang initialisiert. Nach Abschluss des Vorgangs ist die Datenbank auf der ehemaligen Standby-Instanz als Primary aktiv und die Datenbank auf der ehemaligen primären Instanz läuft jetzt als Standby im Recovery Modus. Das Einspielen der regelmäßigen Transaktionslog Backups erfolgt nun in gegengesetzter Richtung, also auf der neuen Standby Instanz.
Hier sehen wir im Grunde auch den größten Vorteil von Dbvisit Standby:
Im Gegensatz zum nativen Log Shipping vom Microsoft SQL Server, wird mit Dbvisit Standby direkt die Richtung der Synchronisierung umgekehrt, sodass eine Verfügbarkeit weiterhin gewährleistet wird. Mit der nativen Log Shipping Lösung ist hier einiges an Handarbeit nötig, um diesen Zustand wiederherzustellen.
Beim automatisierten Failover scheiden sich immer wieder die Geister. Während einige im Fehlerfall keine Zeit verlieren wollen, möchte eine Vielzahl der Administratoren einen solchen Vorgang lieber kontrolliert durchführen bzw. individuell entscheiden. Von daher folgt Dbvisit hier eher dem mehrheitlichen Ansatz, dass der Failover in der Standardeinstellung nicht automatisch durchgeführt wird. Das kann aber auf Wunsch entsprechend eingestellt werden. Zuständig für den Failover ist die “Observer” Komponente von Dbvisit. Diese überwacht die Erreichbarkeit der Datenbanken und leitet gegebenenfalls den Failover ein. Wenn kein automatischer Failover eingestellt ist, kann der “Observer” entsprechende Benachrichtigungen versenden. Zur Verfügung stehen hier Slack- und E‑Mail Notifications sowie die Ausführung eines Custom Scripts.
Die Parameter des “Observer” können einzeln eingestellt werden. Beispielsweise kann man so das Check Intervall oder die maximale Anzahl von Versuchen, bevor eine Aktion eingeleitet wird, festlegen.
Aus unserer Sicht ist es generell eine sinnvolle Einstellung, den Failover nicht automatisch geschehen zu lassen, falls keine entsprechende Loadbalancer-Konfiguration für die Applikation implementiert ist.
Die Konfiguration und das Verhalten von SQL Server Datenbanken unter Linux gestaltet sich tatsächlich größtenteils analog zu den SQL Server Datenbanken unter Windows.
Sobald sich die Agents beim Control Center gemeldet haben, können die Datenbanken konfiguriert werden. Die einzigen Unterschiede sind die Pfade im Dateisystem und, dass eine Anmeldung mit einem SQL Server Login empfohlen ist (wenn keine Kerberos Authentifizierung auf dem SQL Server unter Linux konfiguriert ist).
WICHTIG: Dbvisit Standby unterstützt aktuell die Linux Distributionen Oracle Enterprise Linux 6–8, Red Hat Enterprise Linux 6–8 und SUSE Linux Enterprise Server 11 und 12. Microsoft unterstützt die Distributionen Red Hat Enterprise Linux 7.7 – 7.9 und 8.0 – 8.5, SUSE Linux Enterprise Server 12 und 15 und Ubuntu Linux 16.04, 18.04 und 20.04.
Somit schränkt sich die Auswahl auf RHEL und SUSE Linux ein.
Unser Fazit für “Dbvisit Standby MP” fällt eindeutig positiv aus!
Neben dem bereits erwähnten, einfachen Handling und der sauber aufbereiteten grafischen Benutzeroberfläche ist die Lösung im Bereich SQL Server besonders vorteilhaft, wenn die Datenbankhosts geographisch weit voneinander entfernt betrieben werden. Dann kann auch auf Basis der SQL Server Standard Lizenz eine bequeme und sichere Disaster Recovery konfiguriert werden.
Aber auch wenn die Datenbankhosts näher zusammenliegen, kann sich der Einsatz von Dbvisit Standby MP lohnen. Beispielsweise dann, wenn der Aufwand für Basic Availability Groups unter der Standard Lizenz nicht betrieben werden soll und die Anforderung an die Synchronisierung der Datenbanken nicht so hoch ist.
Share this article