DB Masters Grundlagen Webinar zu Oracle Datenbank Hochverfügbarkeit: RAC, RAC OneNode und Single Instance Failover
Dieses Webinar finden Sie auch auf unserem Youtube Webinar Channel.
DB Masters Grundlagen Webinar zu Oracle Datenbank Hochverfügbarkeit: RAC, RAC OneNode und Single Instance Failover
In diesem Webinar gehen wir Ihnen die verschiedenen Hochverfügbarkeitsimplementierungen basierende auf der Oracle Grid Infrastructure - auch Clusterware genannt - ein.
Infrastruktur Architektur für Oracle Cluster
Das Verständnis was ein Cluster ist, unterscheidet sich zwischen unterschiedlichen Softwarelösungen deutlich. Bei Oracle gibt es sehr strikte Anforderungen, die eingehalten werden müssen.
- zwei oder mehr Server - stellen die Basis dar, auf der die Services des Clusters angeboten werde.
- eine Shared Storage (SAN oder NAS) - wird für alle zur Datenbank gehörenden Files benötigt. Diese soll möglichst redundant angebunden werden.
- Interconnect Netzwerk - ist ein exklusives Netzwerk zwischen den Datenbank Server über die die Cluster Software kommuniziert und Daten austauschen kann.
- Client Netzwerk(e) - ein oder mehrere Client Netzwerke auf denen die Benutzer mit Ihren Applikationen direkt oder über Web- oder Applikationsserver zugreifen.
- Ein (oder mehrere) Datenbank(en) - die auf der Shared Storage liegen und somit von allen Servern erreichbar sind.
- Mit einer Datenbank Instanz pro Server - im Falle eines Real Application Clusters mit einer Instanz pro Server für jede Datenbank.
Oracle Grid Infrastruktur – Oracle Cluster Software
Die Oracle Grid Infrastruktur versteht sich als eine Erweiterung des Betriebsystems um Cluster Funktionalität. Oracle unterstützt neben Linux, Solaris und Windows auch noch AIX und HP-UX sowie Linux on System Z.
Bis inklusive Oracle 19c hat die Oracle Clusterware mit einer Cluster Lösung des Betriebssystemherstellers (zb: AIX, HP-UX, etc.) kooperiert. Beginnend mit Oracle 20c darf keine Betriebsystem Clusterlösung genutzt werden.
Die Oracle Clusterware stehlt viele Funktionalitäten zur Verfügung, die wichtigsten sind:
- Cluster Membership & Monitoring - Welche Server sind funktionale Teile des Clusters
- Cluster Services – Oracle und 3rd Party - Beispielsweise Real Application Cluster oder RAC oneNode, aber auch andere 3rd Party Produkte wie WebServer oder auch Single Instance Datenbanken.
- Clusterfähige Filesysteme - sofern nötig (SAN oder iSCSI). ASM steht Oracle Datenbanken zur Verfügung, ACFS - das ASM Cluster File System - für alle anderen Anwendungen.
- Virtuelle Netzwerk Adressen - damit man von den phyischen Servern unabhängige IP Adressen für die Cluster Services nutzen kann.
Oracle RAC - Real Application Cluster Database
Die Real Application Cluster Datenbank, deren Vorläufer schon auf Oracle 6 unter OpenVMS zurück gehen und damals Parallel Server genannt wurden, sind der Grund, warum Oracle begonnen hat eine Cluster Software zu entwickeln.
Die Basis bildet die Datenbank auf der Shared Storage gemeinsam mit den Datenbank Instanzen auf den Servern. Auf virtuellen SCAN-IP Adressen hören die SCAN Listener und verteilen die Anfragen der Clients auf die verschiedenen Instanzen. Fällt eine Instanz aus, wird die Client Session - sofern es die Anwendung unterstützt - auf eine andere Datenbank Instanz verbunden.
Der RAC bietet somit eine höhere Ausfallsicherheit sowie eine Skalierung mit der Anzahl der Instanzen, sofern die Applikation dies auf Grund des RAC Overheads durch die clusterweite Ressourceverwaltung zuläßt. Sehr gut skalieren großteils nur lesende Anwendungen wie Reporting und Data Warehouse.
Oracle RAC OneNode Database
Der Unterschied zum RAC besteht darin, dass beim RAC oneNode im normalen Betrieb nur eine Datenbank Instanz auf nur einem Server läuft. Lediglich im Rahmen eines manuellen RELOCATE der Instanz auf einen andern Server, gibt es für einen kurzen Zeitraum zwei Instanzen. Client Sessions werden im Zuge eines Transaktionsendes automatisch auf die andere Instanz weiter geleitet. RAC oneNode ist speziell für Applikationen, die nicht RAC tauglich entwickelt sind, aber von der höheren Verfügbarkeit profitieren sollen.
Oracle Single Instance Failover Database
Im Gegensatz zu RAC und RAC oneNode interagiert die Oracle Datenbank Software nicht mit der Cluster Software. Man spricht dann davon, dass man die Datenbank Software für Single Instance Betrieb installiert hat. Beginnend mit Oracle 10g ist dies mit Hilfe von User Defined Application Scripts möglich und ab Oracle 19.7 bietet Oracle auch direkte Unterstützung mittels Grid Infrastruktur Standalone Agents an.
Verstirbt die Datenbank Instanz oder der Server auf dem diese läuft, sorgt die Grid Infrastruktur Software dafür, dass eine neue Datenbank Instanz auf einem andern Rechner gestartet wird. Damit gibt es keinerlei RAC Overhead allerdings einige funktionale Einschränkungen. Es gibt keine Unterstütztung für FAN, Transaction Guard und Application Continuity.
Anforderung an die Applikation
Eine clusterfähige Datenbank ist nur die halbe Miete. Wenn die Applikation nicht mitspielt oder abstürzt, bringt es nichts, wenn die Datenbank hochverfügbar ist. Aus diesem Grund hat Oracle über die Zeit verschiedene Ansätze entwickelt um den Applikationen einen leichtere Hochverfügbarkeitsimplementierung zu ermöglichen:
- Seit Oracle 8 mittels TAF – Transparent Application Failover: Automatisches Erzeugen einer neuen Session, optional laufen Selects weiter
- Ab Oracle 10g zusätzlich FAN – Fast Application Notification: Client (Applikationsserver) wird notifiziert, dass Datenbank Instanz nicht verfügbar ist
- Ab Oracle 11gR2 durch den UCP – Universal Connection Pool: Oracle Connection Pool mit Unterstützung für TAF & FAN und vieles mehr, wie z.B. Connection (Transaction Based, Web Session, RAC/Sharding Data) Affinity
- Ab Oracle 12c ergänzt durch
- Application Continuity: Automatisches, transparentes Replay von Transaktionen nach Failover
- Transaction Guard: Transaktionsende (COMMIT/ROLLBACK) wird in der Datenbank dokumentiert, damit diese nicht mehrfach laufen
Zusammenfassung
RAC, RAC OneNode und Single Instance Failover setzen auf der Oracle Grid Infrastruktur auf. RAC bietet eine Skalierung mit der Anzahl der Instanzen, sofern die Applikation dies unterstützt. Alle bieten ein Applikation Failover an, sofern die Applikation das unterstützt. Lediglich bei Single Instance Failover gibt es funktionale Einschränkungen. Der Aufwand für Java Entwickler den Oracle UCP (statt anderen Connection Pools) einzubinden sind wenige Codezeilen!
Interesse an diesem Webinar geweckt?
Dann schauen Sie es sich doch direkt auf unserem Youtube Channel an: DB Masters Grundlagen Webinar zu Oracle Datenbank Hochverfügbarkeit: RAC, RAC OneNode und Single Instance Failover.
Vergessen Sie nicht unseren Youtube Channel zu abonnieren, damit Sie keines unserer Videos verpassen!