Der Artikel richtet sich an Datenbankadministratoren und

Entwickler, die Oracle RAC aufsetzen und betreiben möchten.

Glossar

TAF
Transparent Application Failover. Automatischer Session Failover einer Datenbank-Session. Für die Anwendung verhält sich der Failover transparent. Sessions werden z. B. bei einem Ausfall eines Knotens auf einen anderen Knoten reconnected.

Load Balancing
Mechanismus zur Lastverteilung von Aufgaben auf mehrere Komponenten eines Systems, meist eines Clusters.

Weiterführende Links

Oracle Real Application Cluster (RAC) 10g (Teil IV)

Failover und Load Balancing

Nach Beleuchtung einiger technischer Details der Architektur von Oracle RAC in den bisherigen Artikeln dieser Reihe [1 - 3] ist festzustellen, dass die technischen Voraussetzungen sowohl für die Hochverfügbarkeit als auch für die Skalierbarkeit der Datenbank geschaffen sind. In diesem Artikel werden nun die Vorteile der RAC-Architektur - das Loadbalancing und die Failover-Mechanismen - beschrieben. Den "Preis", den man hierfür zahlen muss, ist jedoch eine nicht zu unterschätzende Komplexität.

Abb. 1: Darstellung des Oracle RAC Hard-/Software Stacks.
Vergrößern

zen =(DESCRIPTION=
		(FAILOVER=ON)
		(LOAD_BALANCE=OFF)
		(ADDRESS_LIST=
			(ADDRESS=(PROTOCOL=tcp)(HOST=ying)(PORT=1521))
			(ADDRESS=(PROTOCOL=tcp)(HOST=yang)(PORT=1521))
		)
		(CONNECT_DATA=(service_name=zen)))

Abb. 2: Beispielkonfi guration zum Client-side CONNECT TIME FAILOVER.

zen_taf=(DESCRIPTION =
	(ADDRESS_LIST =
		(ADDRESS = (PROTOCOL = TCP)(HOST = ying)(PORT = 1521))
		(ADDRESS = (PROTOCOL = TCP)(HOST = yang)(PORT = 1521))
	)
	(CONNECT_DATA =
	(SERVICE_NAME = prod )
	(FAILOVER_MODE = ( TYPE=SELECT)
					 ( METHOD=BASIC)
					 ( RETRIES=20)
					 ( DELAY=30))))

Abb. 3: Beispiel einer TAF-Konfiguration.

TYPE = SESSION	Aktuelle Abfragen werden abgebrochen.
TYPE = SELECT	Ein aktuell laufendes SELECT-Statement wird über die neue Verbindung noch einmal ausgeführt. Die Rückgabe des Resultsets des Statements wird an der richtigen Stelle fortgeführt.
METHOD = BASIC	Bei dieser Standardmethode wird die Verbindung zur Failover-Instanz erst im Failover-Fall aufgenommen.
METHOD = PRECONNECT	Im Gegensatz zur BASIC-Methode werden die Verbindungen zu den anderen Knoten des Systems beim Connect erstellt und in Reserve gehalten. Dadurch wird bei einem Failover der Overhead der Verbindungaufnahme vermieden, sodass es zu einer schnelleren Weiterführung der Session kommt. Nachteilig ist natürlich der damit verbundene Overhead an Prozessen und der Hauptspeicherverbrauch.
BACKUP = TNS_ALIAS	Hier kann ein TNS-Alias einer Backup-Instanz angegeben werden. Bei einem Failover wird dann auf diese Instanz bzw. TNS-Alias-Definition gewechselt.
RETRIES = ANZAHL und DELAY = SEKUNDEN	Definition des zeitlichen Verhaltens bei erneuter Verbindungsaufnahme, also wie oft und mit welchem Abstand wird ein neuer Connect versucht.
Abb. 4: Parameter-Einstellungen zur Steuerung des Failover-Verhaltens.

zen=(DESCRIPTION=
	  (FAILOVER=on)
	  (LOAD_BALANCE=on)
	  (ADDRESS_LIST=
	    (ADDRESS=(PROTOCOL=tcp)(HOST=ying)(PORT=1521))
	    (ADDRESS=(PROTOCOL=tcp)(HOST=yang)(PORT=1521))
	  )
	  (CONNECT_DATA=(service_name=zen)))

Abb. 5: Auszug aus einer Client TNSNAMES.ORA:
Client-side Load Balancing durch den Paramenter Load Balance.

LISTENERS_APACHE =(ADDRESS_LIST =
	(ADDRESS = (PROTOCOL...)(HOST = vip_srv01)(PORT...))
	(ADDRESS = (PROTOCOL...)(HOST = vip_srv02)(PORT...))
)

Abb. 6: Auszug aus einer Server TNSNAMES.ORA: Eintragung der Remote Listener.

REMOTE_LISTENER = LISTENERS_APACHE

Abb. 7: Datenbankparameter: Zuweisung des TNS-Alias für Remote Listener erfolgt über den Parameter REMOTE_LISTENER.

dbms_service.modify_service( service_name => 'zen_srv' -
							, goal =>
dbms_service.goal_throughput -
							, clb_goal =>
dbms_service.clb_goal_long -
							);

Abb. 8: Beispiel für die Einstellung des Server-side Load Balancing.

GOAL => dbms_service.none

GOAL => dbms_service.service_time /
GOAL => dbms_service.throughput

throughput

Abb. 9: Wichtige Parameter des PL/SQL-Packages
dbms_service.modify_service.

Zusammenfassung RAC-Architektur

Die ersten drei Teile dieser Reihe [1 - 3] befassten sich mit der RAC-Architektur. Hier wurden die Anforderungen und technischen Details vom Betriebssystem-Layer bis hin zum Storage Management Layer dargestellt (siehe Abbildung 1).

Durch die Verwendung von virtuellen IP-Adressen und dessen Übernahme im Failover-Fall wird sichergestellt, dass immer mindestens ein Cluster-Knoten erreichbar ist. Allerdings muss die RAC-Architektur deutlich mehr leisten als nur die Übernahme der virtuellen IP-Adressen. Neben dem verteilten Speichermanagement (Cache Fusion) muss jede RAC-Instanz auch in der Lage sein, das Instanz-Recovery von anderen Instanzen zu übernehmen. Das bedeutet, im Fall eines Instance Crash muss die überlebende Instanz sofort aus den Online Redo Logs der abgestürzten Instanz ein Crash Recovery durchführen.

Die Skalierbarkeit der RAC-Architektur basiert auf dem dynamischen Hinzunehmen und Entfernen von Knoten aus dem System. So können quasi Speicher und CPUs von Servern zusammengefasst werden.

Vorteile für die Anwendung

Welche Vorteile ergeben sich nun für die Anwendung? Zum einen wird die Verfügbarkeit verbessert, da beim Ausfall eines Cluster-Knotens alle Sessions auf die oder den "überlebenden" Knoten reconnected werden können. Zum anderen besteht die Möglichkeit, die Leistung zu steigern, da RAC über die Grenzen eines physikalischen Rechners skalieren kann.

Failover und Load Balancing werden nun im Einzelnen dargestellt.

Failover

Das Failover sollte für die Anwendung möglichst transparent sein. Das bedeutet, der Anwender sollte keine oder nur eine kurze Unterbrechung wahrnehmen. RAC unterscheidet die folgenden Failover-Methoden.

Connect Time Failover

Mit der Konfiguration des CONNECT TIME FAILOVER wird sichergestellt, dass der Client eine Verbindung zur Datenbank aufbauen kann, wenn ein funktionsfähiger Knoten des RAC-Systems den gewünschten Net-Service zur Verfügung stellt.

Entscheidend ist dabei, dass zumindest die Verbindung zu einem laufenden Listener-Prozess aufgenommen werden kann. Dieser entscheidet dann, welcher Knoten den in der Verbindungsdefinition genannten Servicenamen bedient. Zu diesem Zweck müssen alle vorhandenen virtuellen Adressen des Knotens in der Adressliste angegeben und der Zusatzparameter FAILOVER definiert werden. Bei einer Verbindungsaufnahme wird dann diese Liste der Adressen durchprobiert, bis eine Verbindung zur Datenbank zustande kommt (siehe Abbildung 2).

Session Time Failover (TAF)

Mit der Oracle-Eigenschaft TAF (Transparent Application Failover) kann auch eine Failover-Funktionalität bei bestehender Verbindung mit der Datenbank realisiert werden. TAF ermöglicht bei einem Knotenausfall den unbemerkten Übergang einer Session auf einen anderen Knoten.

Hierbei bestehen jedoch einige Einschränkungen, die von der Applikation adäquat behandelt werden müssen. Zum einen werden bestehende, noch nicht mittels commit bestätigte Transaktionen abgebrochen, da Transaktionen immer an die ausführende Instanz gebunden sind.

Zum anderen werden Einstellungen zur aktuellen Session (alter session ...), ebenso bei der Datenbankinstanz, gehalten und gehen bei dem Übergang verloren (siehe Abbildung 3).

Definiert wird TAF durch den Bereich FAILOVER_MODE in der TNS-Alias-Definition. Abhängig von den Einstellungen der Parameter kann das Failover-Verhalten gesteuert werden. Maßgebend dabei sind die Parameter in Abbildung 4.

Load Balancing

Ziel des Load Balancing ist es, die Kapazitäten des RAC-Systems bezüglich des Hauptspeichers und der CPU-Zeit möglichst effektiv zu nutzen. Die Gesamtlast soll gleichmäßig über den Cluster verteilt werden. Erreicht wird dies entweder durch Einstellungen auf dem Server/Listener (Server-side Load Balancing) oder durch Einstellungen beim Client in der TNS-Spezifikation (Client-side Load Balancing).

Client-side Load Balancing

Das Client-side Load Balancing wird in der TNSNAMES.ORA des Clients mit dem Parameter LOAD_BALANCE eingestellt. Steht LOAD_BALANCE auf on, so wird die Liste von Adressen in einer zufälligen Reihenfolge abgearbeitet, bis eine erfolgreiche Verbindung hergestellt werden kann. Dies führt zu einer fast gleichmäßigen Verteilung neuer Verbindungen auf die Clusterknoten, allerdings ohne Berücksichtigung des aktuellen Zustands bzw. der Last der Server (siehe Abbildung 5).

Server-side Load Balancing

Neben der Möglichkeit, das Load Balancing beim Client zu realisieren, kann das Load Balancing auch auf der Server-Seite konfiguriert werden. Wird diese Funktionalität genutzt, entscheidet der Listener, mit welcher Instanz des Knotens der Client verbunden werden soll. Die Entscheidungskriterien werden bei dem Listener und der Datenbankinstanz konfiguriert. Einerseits muss die Datenbank die aktuellen Werte der verwendeten Kriterien an den eigenen Listener weitergeben. Andererseits müssen sich die Listener aller Knoten miteinander unterhalten können, um diese Kriterien zu vergleichen und entsprechend über die zu wählende Instanz entscheiden.

LOCAL_LISTENER
Der Parameter LOCAL_LISTENER definiert, wie die Datenbankinstanz den eigenen Listener erreicht. Werden für den Listener die Standardvorgaben wie Listenername = LISTENER, HOST = localhost, PORT = 1521 verwendet, kann dieser Parameter ausgelassen werden.

REMOTE_LISTENER
Hier wird eine Liste von Adressen an den lokalen Listener weitergegeben, mit der dieser seine Partner auf den anderen Knoten ansprechen und deren Informationen über Auslastung der Instanzen abfragen kann (siehe Abbildung 6 und 7).

Die Einstellung des Server-side Load Balancing erfolgt über den Aufruf der Routine dbms_service. Mittels der PL/SQL-Prozedur dbms_service.modify_service können die Eigenschaften des Load Balancing modifiziert werden. Der Parameter clb_goal gibt an, welches Kriterium als Basis für das Load Balancing genutzt werden soll (LONG, SHORT). Der Parameter goal stellt ein, ob Load Balancing verwendet und in welcher Form es auf Basis der Serverlast gestaltet wird (siehe Abbildung 8).

Wichtige Parameter des PL/SQL Packages dbms_service.modify_service werden in Abbildung 9 beschrieben.

Load Balancing aufgrund der Verbindungsanzahl

Wird für den Parameter clb_goal der Wert long gewählt, so wird das Load Balancing auf Basis der Anzahl der aktuell vorhandenen Verbindungen auf den einzelnen Knoten gemacht. Die Verbindungen werden gleichmäßig auf die Instanzen verteilt. Diese Einstellung zielt u. a. auf Applikationsserver, die einen Verbindungspool zur Datenbank mit lang bestehenden Verbindungen aufbauen und selbst die Anfragen auf diese Verbindungen verteilen.

Load Balancing aufgrund der Serverlast

Wird der Parameter auf den Wert short eingestellt, wird erwartet, dass Verbindungen zur Datenbank nur kurzfristig existieren und direkt nach der Verbindungsaufnahme Aktionen auf die Datenbank durchgeführt werden. Diese werden dann auf dem aktuell am wenigsten belasteten Knoten ausgeführt. Das Lastprofil der Datenbank wird regelmäßig durch die Datenbankinstanzen ermittelt und an die Listener weitergegeben. Abhängig vom Parameter goal entscheiden dann entweder die Antwortzeiten oder der aktuelle Durchsatz der Instanzen, welche Knoten verwendet werden.

Fazit

Erst wenn alle vorgestellten Einstellungen und Konfigurationen auf dem Client und auf Seite des Clusters beachtet werden, können die vollen Möglichkeiten der RAC-Technologie genutzt werden. Durch das Failover erreicht man eine hohe Ausfallsicherheit der Datenbankverbindung und durch das Load Balancing können die Kapazitäten des Gesamtsystems effektiver genutzt werden.

Klaus Garstecki (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen