Wenn es darum geht, eine Anwendung hochverfügbar zu machen, denkt man in der Regel sofort an die entsprechenden HA- bzw. Cluster-Technologien für Datenbank und Application Server. Allerdings ist es damit nicht getan: Wenn der Endanwender vom Ausfall eines Rechnerknotens nichts mitbekommen, das Failover also völlig transparent ablaufen soll, dann muss der Anwendungsentwickler dafür etwas tun.

Dieser Tipp beschätigt sich mit den für den DBA und Anwendungsentwickler wichtigen Komponenten wie Transparent Application Failover (TAF), Fast Application Notification (FAN) und Fast Connection Failover (FCF).

Was passiert eigentlich beim Ausfall einer Datenbankinstanz resp. Servers?

Auf Serverseite passiert natürlich eine ganze Menge, wie das Recovery der ausgefallenen Instanz (im Falle eines RACs) oder das aktivieren der Standbyumgebung (im Falle einer Data Guard Umgebung).
Interessant ist aber auch anzuschauen, was eigentlich mit der Datenbanksitzung (Session) auf dem ausgefallenen Knoten passiert. Eine Session ist ja weit mehr als nur die Netzverbindung:

Failover "klassisch": Transparent Application Failover (TAF)

TAF ist Bestandteil des Oracle Call Interface (OCI), also des Oracle-Clients. Beim Ausfall des Clusterknotens passiert zunächst noch nichts. Erst wenn die Datenbanksitzung aktiv wird, also mit dem Server kommunizieren möchte, "merkt" TAF, dass der Knoten "nicht mehr da" ist - denn es tritt ein Netzwerkfehler auf. Dieser wird abgefangen, wobei TAF transparent eine neue Datenbankverbindung zum verbliebenen Clusterknoten oder zur verbleibenden Data Guard Umgebung aufbaut und dort weiterarbeitet.

Dabei ist die von TAF transparent aufgebaute Datenbank Session eine völlig neue, so dass der Zustand der "alten" Session nicht mehr zur Verfügung steht. Wenn der Session State für die Anwendung von Bedeutung ist, muss der Entwickler dafür sorgen, dass der Session State wieder korrekt gesetzt wird: Die Anwendung muss auf das Failover reagieren. Dazu stellt TAF spezielle Callback-Mechanismen bereit, die vom Entwickler implementiert werden und mit denen die Anwendung auf das Failover reagieren kann. Speziell für offene Cursor bietet TAF ein Feature (FAILOVER_TYPE=SELECT) an: Wird während des Failovers gerade ein Cursor abgearbeitet, kann TAF die SQL-Abfrage sofort nach Verbindungsaufbau nochmals absetzen, die Cursorposition abpassen, an welcher der Failover erfolgte, und dort die Bearbeitung fortsetzen.

Da TAF auf der Erkennung eines Netzwerkfehlers im Client basiert hat man mit TAF aber auch keine Funktionalität neue Knoten zu erkennen und zurückzuschalten: Sollen alle Knoten wieder gleichmäßig ausgelastet werden, so kann TAF das nicht realisieren; die Datenbankverbindungen müssen explizit geschlossen und neu geöffnet werden. Für die Client/Server-Architektur kann das akzeptiert werden, denn die Client-Applikationen werden typischerweise morgens gestartet und abends beendet. Zwar erkennt TAF das "Wieder-Hochfahren" eines Knotens nicht - die Applikationen nutzen ihn also nicht. Am Abend werden die Anwendungen jedoch geschlossen und am nächsten Tag neu gestartet; spätestens dann sind die Knoten des Clusters wieder gleichmäßig ausgelastet.

Für eine Drei-Schichten-Architektur wie J2EE oder ASP.NET ist diese Situation jedoch untragbar: Denn der Application-Server, welcher die Datenbankverbindungen im Connection-Pool hält, wird am Abend eben nicht heruntergefahren. Insofern wird eine Technologie benötigt, welche den wieder verfügbaren Clusterknoten automatisch und möglichst zeitnah nutzt.

Fast Connection Failover (FCF)

Fazit

1. TAF eignet sich vor allem für Client/Server-Umgebungen: Wenn der Session State in der Datenbank beim Failover vernachlässigt werden kann, besticht TAF durch seine Einfachheit - der Entwickler muss sich schlicht um nichts kümmern. Hat der Session State in der Datenbank jedoch eine Bedeutung für die Anwendung, ist TAF nicht mehr "transparent": Der Entwickler bzw. die Anwendung muss auf das Failover reagieren.
2. In einer 3-Schichten-Architektur sollte allerdings stets FCF verwendet werden, da die Datenbankverbindungen in der Middleware gehalten werden und diese längere Zeit durchlaufen soll. FCF ist im Gegensatz zu TAF in der Lage, auf das "Wieder Hochfahren" der Clusterknoten zu reagieren. FCF ist allerdings nicht transparent; der Entwickler muss in jedem Fall im Rahmen des Exception Handlings auf ein mögliches Failover reagieren.

Hands On Workshop Unterlagen:

Damit Sie Erfahrungen mit TAF und FCF machen können, veröffentlichen wir hier die HA Test Unterlagen von den RAC Workshops, die in den letzten Wochen in Deutschland stattgefunden haben. Vorraussetzung für die Skripte ist eine laufende RAC Test Umgebung:

Nützliche Links und Referenzen

Zurück zur Community-Seite