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