News zu Microsoft SQL Server

Dbvisit Standby MP v11 – Getestet für SQL Server!

Schon seit vielen Jahren nutzen wir bei ASPICON Dbvisit Standby Produkte, um bei unseren Oracle Kunden hochver­fügbare Datenbank-Infrastrukturen aufzu­bauen und zu betreiben. Nun bietet Dbvisit mit dem Produkt “Standby MultiPlatform 11.x” auch ein Angebot für SQL Server Installationen und ermög­licht durch den MultiPlatform Ansatz den paral­lelen 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 auf Herz und Nieren getestet und können schon jetzt sagen: 

Es lohnt sich!

Dbvisit Standby MP Logo, Certified SQL Server

Inhaltsverzeichnis 

Einstieg

Zum Einstieg geben wir einen kurzen Überblick zu der Funktionsweise der “Dbvisit Standby MP”, unserer Testumgebung sowie den notwen­digen 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 konzen­trieren wir uns hier ganz auf die Konfiguration von Dbvisit Standby MP.

Funktionsweise

Im Bereich des SQL Servers basiert der techno­lo­gische Ansatz von Dbvisit auf dem Backup und Restore von Transactionlog Backups. Im Prinzip funktio­niert es wie die schon lange vorhandene Lösung des Microsoft SQL Server, das Log Shipping.

Im Gegensatz zum Log Shipping gelingt hier erfreu­li­cher­weise die Einrichtung deutlich einfacher und schneller. Doch der wohl entschei­dende Vorteil liegt im Handling von Dbvisit Standby MP. Während bei Log Shipping das hin und her switchen durchaus ein wenig heraus­for­dernd ist, kann man mit Hilfe von Dbvisit Standby MP sowohl einen geplanten Switchover, einen automa­ti­schen 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 einge­richtet werden.

Testumgebung

Für unsere Testumgebung haben wir folgende Hosts bereitgestellt:

  • 3 x Windows Server 2019 Standard
    • 1 x Host für Control Center
    • 2 x Hosts mit instal­liertem SQL Server 2019

  • 2 x Oracle Enterprise Linux 8 (= analog RHEL 8)
    • 2 x Hosts mit instal­liertem SQL Server 2019 auf Linux

Vorbereitung

Als Voraussetzung sind zum einen die oben erwähnten Maschinen vorzu­be­reiten und zum anderen die entspre­chende Datenbanksoftware zu installieren.

Auf den Windows Hosts muss zudem die Firewall angepasst werden. Dabei sind entspre­chende Eingangsregeln für folgende Ports zu konfigurieren:

  • Dbvisit Control Center
    • 4433/TCP
    • 5533/TCP

  • SQL Server Host
    • 1433/TCP
    • 5533/TCP
    • 7890/TCP

Die Software haben wir als Teststellung von der Dbvisit Website bezogen (Zielplattform und Version von Standby angegeben)

WICHTIG: Damit alles funktio­niert, ist auf Windows Systemen darauf zu achten, dass entspre­chende Dienstbenutzer in der “Local Security Policy” unter “Local Policies” → “User Rights Assignment” für das Recht “Log on as a service” konfi­gu­riert werden.

Installation

Control Center unter Windows

Nachdem die Software geladen wurde, kann der Installer für das Control Center auf dem entspre­chenden Host einfach gestartet werden. Der Installer ist aus unserer Sicht recht selbst­er­klärend. Hier muss nur darauf geachtet werden, dass eine entspre­chende 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.

Agents unter Windows

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.

Agents unter Linux

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 ausge­fü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 beschrie­benen Schritte sollte auch dieser Host im Control Center angezeigt werden.

SQL Server Datenbanken unter Windows

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än­der­baren Inhalten hinzu­gefügt. Diese Datenbank haben wir mit dem OpenSource Tool HammerDB erstellt.

Wichtig ist, dass alle Datenbanken im vollstän­digen Wiederherstellungsmodell betrieben werden. Wenn der Dbvisit Agent korrekt instal­liert wurde und alle Firewall-Regeln richtig einge­stellt sind, wird dieser umgehend im Control Center angezeigt.

Neue Datenbank aufnehmen

Um eine neue Datenbank für die Verfügbarkeit zu konfi­gu­rieren, können im Dashboard unter “New Configuration” eine oder mehrere Datenbanken von einer Instanz ausge­wählt werden.

Ist die Zielinstanz ausge­wä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 einge­stellt ist, kann der Vorgang über den Button “Start” einge­leitet werden.

Anschließend wird von den Dbvisit Agents ein vollstän­diges Backup der Datenbank auf der Quellinstanz erstellt und danach auf der Zielinstanz wieder­her­ge­stellt. Die Wiederherstellung belässt die Datenbank im RECOVERY Modus, so dass anschließend Transaktionslog Backups einge­spielt werden. Je nachdem was für ein Intervall einge­stellt wurde, werden ab jetzt regel­mäßig Transaktionslog Backups auf der Quelldatenbank erstellt und in der Zieldatenbank einge­spielt. Der vorein­ge­stellte Standardwert beträgt 300 Sekunden, also 5 Minuten. Er kann aber indivi­duell 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 konfi­gu­rierten 300 Sekunden, bzw. die indivi­duell gewählte Intervallzeit sein.

(Graceful) Switchover

Ein Switchover kann hier vergleichs­weise einfach über das Dashboard initiiert werden. 

Über den “Actions” Button der jewei­ligen Datenbank können verschiedene Aktionen ausge­wählt werden, so auch ein “Graceful Switchover”.

Mit dem Drücken des “Start” Buttons wird nun der Switchover Vorgang initia­li­siert. Nach Abschluss des Vorgangs ist die Datenbank auf der ehema­ligen Standby-Instanz als Primary aktiv und die Datenbank auf der ehema­ligen primären Instanz läuft jetzt als Standby im Recovery Modus. Das Einspielen der regel­mä­ßigen Transaktionslog Backups erfolgt nun in gegen­ge­setzter 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ähr­leistet wird. Mit der nativen Log Shipping Lösung ist hier einiges an Handarbeit nötig, um diesen Zustand wiederherzustellen.

Failover

Beim automa­ti­sierten 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 kontrol­liert durch­führen bzw. indivi­duell entscheiden. Von daher folgt Dbvisit hier eher dem mehrheit­lichen Ansatz, dass der Failover in der Standardeinstellung nicht automa­tisch durch­ge­führt wird. Das kann aber auf Wunsch entspre­chend einge­stellt werden. Zuständig für den Failover ist die “Observer” Komponente von Dbvisit. Diese überwacht die Erreichbarkeit der Datenbanken und leitet gegebe­nen­falls den Failover ein. Wenn kein automa­ti­scher Failover einge­stellt ist, kann der “Observer” entspre­chende 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 einge­stellt werden. Beispielsweise kann man so das Check Intervall oder die maximale Anzahl von Versuchen, bevor eine Aktion einge­leitet wird, festlegen.

Aus unserer Sicht ist es generell eine sinnvolle Einstellung, den Failover nicht automa­tisch geschehen zu lassen, falls keine entspre­chende Loadbalancer-Konfiguration für die Applikation imple­men­tiert ist.

SQL Server Datenbanken unter Linux

Die Konfiguration und das Verhalten von SQL Server Datenbanken unter Linux gestaltet sich tatsächlich größten­teils analog zu den SQL Server Datenbanken unter Windows.

Sobald sich die Agents beim Control Center gemeldet haben, können die Datenbanken konfi­gu­riert 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 konfi­gu­riert ist).

WICHTIG: Dbvisit Standby unter­stü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 unter­stü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.

Fazit

Unser Fazit für “Dbvisit Standby MP” fällt eindeutig positiv aus!

Neben dem bereits erwähnten, einfachen Handling und der sauber aufbe­rei­teten grafi­schen Benutzeroberfläche ist die Lösung im Bereich SQL Server besonders vorteilhaft, wenn die Datenbankhosts geogra­phisch weit vonein­ander entfernt betrieben werden. Dann kann auch auf Basis der SQL Server Standard Lizenz eine bequeme und sichere Disaster Recovery konfi­gu­riert werden.

Aber auch wenn die Datenbankhosts näher zusam­men­liegen, 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.

Hier gibt es weitere Posts zum Thema Dbvisit Standby vom Dbvisit Platinum Partner ASPICON. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Share on facebook
Facebook 
Share on twitter
Twitter 
Share on linkedin
LinkedIn 
Share on xing
XING 
Share on whatsapp
WhatsApp 
Share on email
Email