Oracle Failover mit Oracle Clusterware

Oracle Clusterware als kostenfreies Werkzeug mit allen kommerziellen Datenbank Editionen zum Aufbau von Failover Szenarien ohne Datenverlust. Failoverszenarien mit der kostenfreien Oracle Clusterware ermöglichen einen signifikant günstigen Einstieg in den Bereich der Oracle Hochverfügbarkeitslösungen.

Icon Services

Mit Oracle Grid Infrastructure bringt Oracle eine eigene Clusterlösung in wesentlichen Teilen ohne Zusatzkosten *) mit. Sie beinhaltet Oracle Clusterware, Oracle Automatic Storage Management (Oracle ASM), ASM Cluster File System (ACFS) und ASM Dynamic Volumes (ADVM). Primär bildet sie natürlich die Grundlage für den Betrieb von Oracle RAC Datenbanken, ist aber bei weitem nicht darauf beschränkt. Insbesondere Oracle Clusterware und ASM können ebenso für die Absicherung von Drittanwendungen oder für Cold-Failover-Konfigurationen eingesetzt werden. In reduziertem Umfang, aber grundsätzlich mit der selben Codebase, ist Oracle Grid Infrastructure auch die Basis für Oracle Restart.


 


Um mögliche Einsatzgebiete der Oracle Grid Infrastructure zu identifizieren, ist in jedem Fall eine saubere Abgrenzung zu anderen Produkten wichtig. Auch wenn die Oracle Grid Infrastructure gern mit Oracle RAC verwechselt oder „in einen Topf geworfen“ wird, handelt es sich tatsächlich um eine eigenständige Produktsuite.

Wie jede andere Clustersoftware auch, fasst die Oracle Grid Infrastructure eine Zahl von Servern zu einem logischen Konstrukt - idealerweise zu einem transparenten Ressourcenpool – zusammen und organisiert sowohl den ausbalancierten Betrieb als auch bei einem Ausfall eines Teils der Ressourcen die Verteilung der Aufgaben auf die verbliebenen Ressourcen. Neben der Bereitstellung dieses logischen Serververbundes und eines Shared Storage über Automatic Storage Management (ASM) Instanzen besteht die Hauptaufgabe der Oracle Grid Infrastructure also in der ständigen Überwachung der eigenen, internen Prozesse und der aufgesetzten RAC-Datenbanken, zusammen mit den sie umgebenden Komponenten, wie etwa Listener und ASM Disk Groups. Im Falle von Fehlerzuständen startet die Oracle Grid Infrastructure ausgefallene Komponenten selbständig neu oder organisiert bei nicht behebbaren Problemen das Failover auf andere Server im Clusterverbund.

Diese Funktionalität ist allerdings nicht auf Oracle RAC Datenbanken beschränkt, sondern kann über ein von Oracle implizit bereitgestelltes, simples Skript-API auf beliebige Drittanwendungen ausgeweitet werden, sofern diese auf Start- und Stoppereignisse reagieren und auf Statusanfragen adäquat antworten können.

Das wiederum eröffnet den aus mehreren Gründen interessanten Ansatz, auch Single Datenbanken unter die Überwachung der Oracle Grid Infrastructure zu stellen:

  • Hochverfügbarkeit: Eine Cold Failover Datenbank ist gegen einen Serverausfall geschützt, da sie in diesem Fall von einem anderen Server des Clusterverbundes übernommen und dort weiter betrieben wird. Gleiches gilt für geplante Wartungsarbeiten, da eine Cold Failover Datenbank auch proaktiv auf einen anderen Clusterserver verschoben werden kann
     
  • Bessere Hardwareauslastung: Durch die Nutzung von Serverpools können alle Serversysteme im Cluster dynamisch mit angemessener Last versehen werden. Die Verteilung der Ressourcenanforderungen ermöglicht den Einsatz sparsamer ausgestatteter Server bei gleichzeitig höherer Gesamtverfügbarkeit als bei aufwändigen Single-Servern 
     
  • Nutzung der "10-Tage-Regel": Ein Server im Cluster kann ohne Lizenz als reine Ausfallsicherung betrieben werden, wenn er im Kalenderjahr für nicht mehr als 10 Kalendertage tatsächlich Datenbanken betreibt. Häufig trifft man diese Konstellation in einem 2-Node-Cluster an, in dem im Normalbetrieb nur ein Server die Cold Failover Datenbank betreibt und der zweite, für Ausfallsicherung vorgesehene, währenddessen andere Aufgaben übernimmt. So steht für den Notfall oder für Wartungsarbeiten ein Ausweichserver bereit, der trotzdem keine zusätzlichen Kosten für Oracle Datenbank Lizenzen verursacht. 
     
  • Nutzung der Notification-Mechanismen: Die Oracle Clusterware propagiert über entsprechende APIs Clusterereignisse (Ausfälle, up/down-Events usw.) an Clientanwendungen und ermöglicht damit schnelles und adäquates Reagieren auf Anwendungsseite (z.B. reconnects, Wiederholen von Transaktionen) und damit weitgehende Transparenz des Clusterzustandes

Die Oracle Datenbank läuft dann zwar weiterhin als Single-Instanz, ist aber nicht mehr fest an einen Server gebunden. Im Falle eines Serverausfalls oder eines anderen, für die Oracle Datenbank fatalen Fehlers auf dem aktuellen Server, organisiert die Oracle Grid Infrastructure das Failover und fährt die betroffene Datenbank auf einem anderen Server im Clusterverbund (wiederum als Single-Instanz) hoch. Dieser Prozess wird als "Cold Failover" bezeichnet, da eine Datenbankinstanz auf dem „Ausweichknoten“ erst im Bedarfsfall gestartet wird.

In gleicher Art und Weise lassen sich von der Oracle Grid Infrastructure auch beliebige weitere Prozesse hochverfügbar auslegen, z.B. Web- oder Applicationserver, Netzwerkdienste oder Fileshares.


 

Voraussetzungen und Kosten

Während einzelne Komponenten der Oracle Grid Infrastructure generell kostenfrei genutzt werden dürfen (ASM, ASM Dynamic Volumes (ADVM), ACFS in der Basisausführung, Oracle Clusterware (ausschließlich für ASM, ADVM, ACFS), Oracle Restart), muss für den Betrieb einer Cold Failover Datenbank mindestens eine der folgenden Voraussetzungen erfüllt sein:

  • Die Serverbetriebssysteme stehen unter einem gültigen ULN Supportvertrag, oder
  • Die abgesicherte Anwendung ist ein Produkt von Oracle, oder
  • Die abgesicherte Anwendung speichert Daten in einer Oracle Datenbank, oder
  • Mindestens einer der Clusterserver ist für Oracle Datenbank Standard Edition One (SE1), Standard Edition (SE), Standard Editon2 (SE2) oder Enterprise Edition (EE) lizenziert.

Anders als die RAC-Option in der Oracle Datenbank Standard Edition ist die Oracle Grid Infrastructure damit auch nicht hinsichtlich der CPU-Socket-Anzahl im Cluster limitiert. D.h. Cold-Failover-Datenbanken können auf praktisch beliebig großen Clustern betrieben werden. Die Einschränkung auf vier CPU-Sockets, wie sie z.B. in der Oracle Datenbank Standard Edition existiert, greift hier nicht, da die Oracle RAC-Option nicht installiert werden muss. Selbst eine Oracle Datenbank Standard Edition One , auf der per Definition kein Oracle RAC betrieben werden darf, kann auf einer Oracle Grid Infrastructure mit beliebig vielen Servern als Cold Failover Datenbank gearbeitet werden.


 

Weitere Einsatzgebiete

In größeren Clustern ist es zusätzlich interessant, sich über die klassische Ausfallsicherung hinaus das Server-Pool Konzept der Oracle Grid Infrastructure anzuschauen. Server laufen dann nicht mehr zwingend gleichberechtigt, sondern können einzelnen, untereinander priorisierten, Pools zugeordnet werden. Die auf dem Cluster betriebenen Anwendungen wiederum werden hinsichtlich der Serverzuweisung gesteuert, indem sie einem der Pools zugewiesen werden.

Unter anderem ist es so möglich:

  • eine Mindestanzahl von Servern für den Betrieb kritischer Anwendungen zu garantieren, indem notfalls und vollautomatisch Server aus niedriger priorisierten Pools abgezogen werden
  • Anwendungen dynamisch zwischen Pools zu verschieben und damit z.B. vorübergehend höheren Ressourcenanforderungen gerecht zu werden bzw. den Weiterbetrieb von Datenbanken auch bei Wartungsarbeiten abzusichern
  • über Ausschlussregeln zu verhindern, dass unverträgliche Services auf dem selben Server ausgeführt werden

 

Architektur und Funktionsweise

Das folgende Schaubild stellt die grundsätzliche Funktionsweise einer typischen mit Oracle Clusterware aufgebauten Oracle Cold Failover Infrastruktur dar.

Oracle Clusterware, Funktionsweise Cold Failover


 

Fazit

Sofern wenigstens zwei vergleichbare Datenbankserver in der Infrastruktur betrieben werden, spricht ansich nichts dagegen, diese Server zu einem Cluster zu verbinden und die Datenbanken dort hochverfügbar in einer Cold-Failover-Konstellation zu betreiben. Abgesehen vom Einrichtungsaufwand entstehen dafür keine nennenswerten Mehrkosten. Im Gegenzug profitieren die Datenbanken und damit letztlich die Endanwender und das Unternehmen von einer höheren Gesamtverfügbarkeit, besserer Hardwareauslastung und gesteigerter Flexibilität.

Aktuelle Meldungen zum Thema