Failover und Loadbalancing - RAC optimal nutzen

Einer der wichtigsten Gründe für den Einsatz eines RAC-Systems besteht in der Möglichkeit von Failover und Load Balancing. Diese Funktionalitäten müssen auf den jeweiligen Anwendungsfall und die jeweils eingesetzte Applikationssoftware abgestimmt sein.

Load Balancing

Oracle unterscheidet zwischen 2 Arten von Loadbalancing:

Client-side Load Balancing

Das Client-side Load Balancing ist kein echtes Loadbalancing und wird in der TNSNAMES.ORA des Clients mit dem Parameter LOAD_BALANCE=on eingestellt. Der Client verbindet sich hierbei mit einer der in der Konfiguration angegebenen Instanz nach dem Zufallsprinzip. 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. Die Konfiguration sollte ausschließlich auf Basis von Servicenamen (SERVICE_NAME) erfolgen und keine SID verwenden. Durch die Verwendung von Service-Namen wird ebenfalls eine Reconnect-Möglichkeit bei Ausfall eines Clusterknotens geschaffen. Beispielkonfiguration:

			sample.world =(DESCRIPTION=
			(LOAD_BALANCE=OFF)
			(ADDRESS_LIST=
			(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
			(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
			)
			(CONNECT_DATA=(service_name=sample_service)))

Hier erfolgt die Verbindung zu den RAC-Instanzen immer in angegebenen Reihenfolge. Wird LOAD_BALANCE=ON gesetzt erfolgt die Wahl der Serverinstanz für die Verbindung zufällig. Beispielkonfiguration:

			sample.world =(DESCRIPTION=
			(LOAD_BALANCE=ON)
			(ADDRESS_LIST=
			(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
			(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
			)
			(CONNECT_DATA=(service_name=sample_service)))

Connection Load Balancing

Neben der Möglichkeit, das Load Balancing beim Client zu realisieren, kann das Load Balancing auch auf der Server-Seite konfiguriert werden. Der Verbindungsaubau läuft dann in folgender Reihenfolge ab:

• der am wenigsten belastete Knoten
• die am wenigsten belastete Instanz
• der am wenigsten belastete Dispatcher bei einer Sharde Server Installation

Hierfür muss für jede Instanz des Clusters der Parameter *.remote_listener='SAMPLE_REMOTE_LSNR' gesetzt sein. Die TNS-Konfiguration muss ebenfalls entsprechend angepasst werden. Beispielkonfiguration:

		SAMPLE_REMOTE_LSNR=
		(ADDRESS_LIST=
		(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
		(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
		)

Wichtiger Hinweis für den Betrieb: Bei einer Konfiguration des Loadbalancings auf mehrere Instanzen eines Rac-System muss immer die Arbeitsweise der Applikation berücksichtigt werden. Unter Umständen kann es zu einer hohen Belastung des Interconnect sowie zu einer Häufung von GC-Wait-Events kommen. Hierdurch kann die Gesamtperformance des Systems wesentich reduziert werden. Der Einsatz eines Loadbalancing sollte immer unter Berücksichtigung dieser Punkte erfolgen.

Failover

Durch den Einsatz einer Failover-Konfiguration kann die Verfügbarkeit der Applikation auch bei Ausfall eines oder mehrerer RAC-Knoten sichergerstellt werden. Hierbei werden 2 Failover-Szenarien unterschieden:

Connect Time Failover

Dies ist relativ unkritisch und sollte bei der Konfiguration der Applikation bei Nutzung einer RAC-Datenbank eingesetzt werden. Hier versucht Oracle Net sich mit einer der in der Konfiguration angegebenen Instanz zu verbinden. Beispielkonfiguration:

		sample.world =(DESCRIPTION=
(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
)
(CONNECT_DATA=(service_name=sample_service)))

Eine bei Ausfall einer Instanz mit dieser verbundenen Session wir im Failover Fall abgebrochen und muss eine neue Vervbindung aufbauen. Dies erfolgt aber nicht automatisch.

Transparant Application Failover

Bricht eine Instanz im laufenden Betrieb die Verbindung ab wird die Session auf eine verfügbare Instanz neu Verbunden. 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, zum anderen werden Einstellungen zur aktuellen Session (alter session ...) in der Datenbankinstanz gehalten und gehen bei dem Übergang verloren . Beispielkonfiguration:

sample.world=(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = viprac1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = viprac2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = sample_service )
(FAILOVER_MODE = ( TYPE=SELECT)
( METHOD=BASIC)
( RETRIES=20)
( DELAY=30))))

TYPE

SESSION Aktuelle Abfragen werden abgebrochen.
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.
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

NS_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.