Dbvisit Standby vs Failover Cluster

By | 22. Juli 2019

Sucht man nach einem Disaster-Recovery-Konzept für seine Oracle Datenbanken in der Standard Edition, sind verschiedene Technologien verfügbar. Eine solches Konzept stellt den Betrieb einer Oracle Datenbank, für den Fall, dass die Datenbank an einem Standort (Stadt, Gebäude, Brandabschnitt) ungeplant ausfällt, sicher. Die Ursachen für einen solches Disaster können vielfältig sein: Stromausfall, Brand, Wasserschaden, Sabotage etc. Aber auch gegen einen einfachen Serverausfall schützt eine implementierte Disaster-Recovery Lösung.

In diesem Beitrag möchte ich als Entscheidungshilfe kurz auf die einzelnen Möglichkeiten eingehen und insbesondere die Lösungen Dbvisit Standby und Failover Cluster (Streched) gegenüberstellen. Der vollständigkeitshalber beschreibe ich auch kurz den Einsatz eines VM-Clusters zur Absicherung von Datenbanken, ohne sie mit den beiden Erstgenannten zu vergleichen.

Neben den hier dargestellten Lösungen gibt es natürlich noch andere tolle Lösungen, wie z.B. Oracle Data Guard und Oracle Golden Gate, die allerdings ausschließlich für die Enterprise Edition verfügbar sind und daher nicht Bestandteil dieses Artikels sind. Dies gilt auch für die Real Application Option (RAC), die ab 19c nur in der Enterprise Edition verfügbar ist.

Für eine Datenbank der Oracle Standard Edition kommen folgende Technologien in Frage.

1. Physical Standby Datenbank (Dbvisit Standby)

Eine Physical Standby Datenbank ist eine physikalische Kopie einer Oracle Datenbank, die fortlaufend mittels übertragender Archivelogs mit den Datenänderungen der primären Datenbank auf dem zweiten Server synchronisiert wird. Die Standby Datenbank befindet sich ständig im Recovery-Modus und ist für Lese- oder Schreiboperationen nicht geöffnet. Sowohl die Primary Datenbank als auch die Standby Datenbank speichert seine Datenbankdateien auf dem jeweils an ihrem Standort verfügbaren Storage – unabhängig voneinander. Software von Drittherstellern, wie z.B. das Produkt Dbvisit Standby unterstützen beim Aufsetzen, Überwachen und den Betrieb einer Standby Datenbank. Sie machen den Betrieb einer Standby Datenbank nicht nur einfacher, sondern auch um ein vielfaches robuster. Im Fehlerfall kann man mit Hilfe der Dbvisit Standby Software ein Failover von der primären auf die überlebende Standby Datenbank durchgeführen, die dann für Schreib- und Lesezugriffe geöffnet wird.

2. Oracle Failover Cluster (Streched)

Ein Oracle Failover Cluster (Streched) ist ein aus zwei Server bestehender Cluster, dessen Shared Storage jedoch aus zwei Storage-Arrays besteht, die an unterschiedlichen Standorten stehen. Eine andere übliche Bezeichnung ist auch Extended Distance Cluster. Die Datenbankdateien befinden sich auf dem Shared Storage und Datenänderungen werden gleichzeitig über ein durch Oracle ASM durchgeführtes Mirroring auf beide Storage-Arrays geschrieben. Im Gegensatz zu einem Real Application Cluster (RAC), der ebenfalls auf der Oracle Clusterware basiert, haben wir nur eine Datenbankinstanz, sprich die Datenbankprozesse und der allokierte Memory, die auf einem der beiden Server läuft (Single Instance). Im Fehlerfall wird einfach die Datenbankinstanz automatisch durch die Clusterware auf dem überlebenden Server gestartet. Das Stoppen und Starten der Instance erfolgt über ein sogenanntes Action-Script, welches man selbst bereitstellen muss. Grundsätzlich hat diese Implementierung Ähnlichkeit mit der RAC One Node Option, ist jedoch nicht nur in der Enterprise Edition verfügbar und erfordert das Anlegen eigener Cluster-Ressourcen in der Clusterware. Eine Implementierung eines Failover Clusters (Streched) habe ich in meinem Blog-Artikel „Oracle SE2 im Cluster – Es geht auch ohne RAC!“ beschrieben.

3. VM-Cluster

Bei dieser Methode wird die Datenbank in einer Virtuellen Maschine (VM) eines VM-Clusters bereitgestellt, der aus mindestens zwei physikalischen Servern an unerschiedlichen Standorten besteht. Am weitesten verbreitet sind VMware, Microsoft Hyper-V und auch Citrix XEN Server. Beim Ausfall eines Server wird die VM einfach auf dem überlebenden Server gestartet. Wegen der Lizenzproblematik, sofern man nicht das Oracle eigene Produkt Oracle VM einsetzt, sollte der Einsatz genau geprüft werden, will man nicht gegen Oracle Lizenzbedingungen verstoßen. Im schlimmsten Fall müssen alle phyikalischen Server bei der Lizenzierung berücksichtigt werden, die rein theoretisch eine „Oracle Datenbank“-VM laufen lassen könnten. Dies kann zu sehr hohen Lizenzkosten führen. Diese Lösung kann aber attraktiv sein, wenn man Named User Plus Lizenzen einsetzen kann und keine allzugroße VM-Infratruktur besitzt, bei der die Mindestlizenzierungsregel das ganze unwirtschaftlich machen könnte.


Dbisit Standby vs Failover Cluster

Die folgende Gegenüberstellung und Bewertung soll die einzelnen Stärken und Schwächen beider Lösungen herausheben und eine Entscheidungshilfe bieten.

  DBvisit Standby Failover Cluster (Streched)
Anforderungen Infrastruktur gering mittel
Komplexität gering hoch
Aufwand Installation gering hoch
Aufwand Betrieb gering mittel
Synchronisierung Oracle Archivelog-Shipping Oracle ASM Mirroring
Datenverlust im Desasterfall Ja, im geringen Umfang möglich Nein, Zero Data Loss
Installation zusätzlicher Software Ja, Dbvisit Standby Ja, Oracle Clusterware (Grid Infratructure)
Root Berechtigung notwendig (Linux) Nein, nicht für Dbvisit Standby Ja, für Oracle Clusterware Installation
Maximale Entfernung der Server Hoch (< 1000 Km) Mittel (< 10 Km)
Database Storage ASM Diskgroups, ACFS oder OS Filesystem ASM Disk Groups oder Oracle ACFS
Tyische Storage -Typen SAN, NAS, DAS SAN, NAS
Storage für 3. Voting Disks (Quorum) Nein Ja, erforderlich (NFS möglich)
Interconnect-Netzwerk Nein Ja, erforderlich
Einsetzbare Oracle Editions XE, SE, SE1, SE2, EE XE, SE, SE1, SE2, EE
Betriebssystem Linux, Solaris, AIX, Windows Linux, Solaris, AIX, Windows (nicht empfohlen)
Empfohlenes Betriebssystem Linux oder Windows Linux (Oracle, Red hat)
Automatischer Failover Ja, via Dbisit Observer Ja, via Clusterware
Für andere Datenbanken/Anwendungen nutzbar Nein Ja
Dauer Failover Wenige Minuten Wenige Minuten
Automatischer Client-Failover Ja, sofern Verbindungen dafür konfiguriert Ja, mittels Single Client Access Name (SCAN)
Switchover/Failover via Web-GUI Ja, Dbvisit Central Console (dbvserver) Nein
Switchover/Failover via Kommandozeile ja, Dbvisit Control (dbvctl) Ja, Oracle Clusterware Control (crsctl)
Multiple Network Support Ja Ja
Hersteller Support Ja, Oracle und Dbvisit Ja, Oracle (Ausnahme, eigene Action-Scripts)
Unterstützung durch Oracle Cloud Control Nein Nein
Zero-Downtime Patching Nein Nein
Zusätzliche Kenntnisse Betrieb Ja, Dbvisit Standby Produkt Ja, Oracle Clusterware (Grid Infratructure)
Automatische Benachrichtung per Mail Ja Nein
Lizenzierung Oracle Datenbanken Ja, für beide Knoten erforderlich Ja, für beide Knoten erforderlich
Erforderliche zusätzliche Lizenzen Ja, für Dbvisit Standby Nein

 

Fazit

Beide Technologien haben ihre Daseinsberechtigung und ihren jeweiligen Charme. Dbvisit ist eine robuste und einfach zu implementierende Lösung, die keine hohen Anforderungen an die Infrastruktur hat. Nachteilig ist allerdings, dass Kosten für die zusätzlichen Lizenzen für das Produkt Dbvisit entstehen und vor allem dass kein Zero Data Loss gerantiert werden kann. Im schlimmsten Fall wurden zuletzt an der Primary Database durchgeführte Änderungen nicht an die Standy Datenbank übertragen und gehen somit verloren. Dies kann architekurbedingt bei dem Failover Cluster nicht passiert. Außerdem erzeugt dieser keine zusätzlichen Kosten für weitere Software, da die benötigte Oracle Clusterware kostenlos ist, sobald man ein lizenziertes Oracle Produkt auf dem Server betreibt (z.B. Oracle Datenbank, Oracle Linux). Allerdings hat ein Failover Cluster etwas höhere Anforderungen an die Infrastruktur und benötigt eine dritte Voting Disk (Quorum) an einem dritten Standort (NFS möglich). Des Weiteren ist bei einem Failover Cluster der Implementierungsaufwand höher.

Welche ist nun die beste Lösung?
Diese Antwort ist sehr individuell und von den eigenen Anforderungen, der Befähigung und der Bereitschaft Geld in Software, Infrastruktur oder Manpower zum investieren abhängig. Mit beiden Lösungen habe ich gute Erfahrungen gemacht und können empfohlen werden.

Referenzen

Dbvisit Standby
Clusterware Administration and Deployment Guide
Clusterware Installation Guide Linux