Oracle Real Application Cluster (RAC) Ralf Mueller Server Technologies Oracle Corporation Ralf.Mueller@oracle.com

Agenda Motivation Clusterumgebungen Oracle Real Application Clusters Oracle RAC Konfigurationsvarianten Q&A

Warum Cluster ? Technische Gründe Nicht-technische Gründe Skalierbarkeit Hochverfügbarkeit Neue Rechnerarchitekturen (Blades) Nicht-technische Gründe Kosten Hardware Strom Platzbedarf

Oracle 10gR2 Grid Enable, Manageability Parallel Server / RAC Historie Verfügbar auf VMS Oracle 6.2 Erster UNIX Parallel Server Oracle 8 Parallel Server iDLM Oracle 8i Parallel Server Cache Fusion I Oracle 9i RAC Cache Fusion II 1989 1991 1992 1997 1999 2001 Oracle 10gR1 RAC ASM Projekt MegaGrid, CERN Oracle 10gR2 Grid Enable, Manageability ? 2003 2004 2005 ?

Cluster Jeder Hersteller, Jede Architektur Real Application Clusters Jeder Hersteller: Sun, HP, IBM, Linux, Win2000, OS/390 Knoten können beliebig hinzugefügt werden NUMA SMP Mainframe Cluster 1 CPU Real Application Clusters

Oracle ist Oracle ist Oracle... Real Application Clusters ist eine Option für Oracle10g eine Codebasis auf allen Plattformen alle Oracle10g Funktionalitäten Identische Schnittstellen Identische Tools Infrastruktur Oracle Universal Installer (OUI) Enterprise Manager (EM) Database Configuration Assistant (DBCA) Recovery Manager (RMAN)

Clusterkomponenten Knoten (Nodes) Interconnect Shared Disk System Cluster Manager Cluster Ready Services Manageability

Knoten (Nodes) Jeder Knoten ist ein eigenständiger Rechner (mit CPU, Memory, etc.) Ein Knoten kann ein Einzel-CPU oder Mehrfach-CPU System sein (SMP, NUMA) Für einen Cluster werden zwei oder mehr Knoten benötigt

Interconnect Verbindung zwischen den Knoten eines Clusters Kann Ethernet basierend sein Bessere Resultate durch Verwendung von “HighSpeed Interconnects” GigaBit Ethernet (alle) VIA (Intel) Memory Channel (HP) High Performance Switch (IBM)

Shared Disk System Alle Knoten haben Zugriff auf die Disk Resourcen des Clusters Unterstützung von SAN und Hersteller spezifischen Lösungen Gemeinsamer Zugriff über Oracle Cluster File System (OCFS) - Oracle Automatic Storage Management (ASM) Volume Manager des OS Herstellers

Cluster Manager Software zum verwalten aller Komponenten in einem Cluster Überwachung des Zustandes eines Knoten Automatisches hinzufügen bzw. herausnehmen eines Knotens im Cluster

Cluster Ready Services Framework fuer 3rd party Applikationen Applikationen werden clusterfähig Unabhängig von Hardware und OS Verwaltung über EM Unabhängig von RAC Offenlegung von Cluster Manager Funktionalität

Manageability (9i vs. 10g) Enterprise Manager Rolling Upgrade Cluster Enable Single Node Backup/Recovery Monitoring Rolling Upgrade Load Balancing Storage Management

Agenda Motivation Clusterumgebungen Oracle Real Application Clusters Oracle RAC Konfigurationsvarianten Q&A

Clusterumgebungen Clustertypen: Failover Cluster Shared Nothing Shared Disk

Clustertypen – Failover Cluster Data A-Z Typischerweise 2 Rechner im Verbund Nur der aktive Rechner hat Zugriff auf die Daten Adressiert Hochverfügbarkeit, keine Skalierbarkeit

Ausfall eines Knotens – Failover Cluster Data A-Z Ausfallrechner übernimmt Platten Applikationen werden hochgefahren Umschaltzeit 10-30 Minuten Nur der aktive Knoten kann genutzt werde (keine Skalierbarkeit)

Clustertypen – Shared Nothing Data A-F G-K L-S T-Z Typischerweise mehrere Rechner im Verbund Alle Knoten sind gleichzeitig aktiv Jedem Knoten ist ein Plattenstapel dediziert zugewiesen Adressiert Skalierbarkeit, aber nur für lesende Applikationen z.B. bei IBM DB2 UNIX & Windows, Microsoft SQL Server

Ausfall eines Knotens – Shared Nothing Data A-E G-K L-S T-Z X A-F Die Platten des ausgefallenen Knotens sind nicht mehr verfügbar Jeweils zwei Knoten sind wechselweise Ausfallknoten zueinander: Ausfallzeit ca. 10 – 30 Minuten Extrem limitierte Skalierbarkeit

Clustertypen – Shared Disk Data A-Z Typischerweise 2 oder mehr Rechner im Clusterverbund Alle Knoten sind gleichzeitig aktiv Alle Knoten haben gleichzeitigen Zugriff auf die Daten Adressiert Skalierbarkeit & Ausfallsicherheit z.B. bei Oracle RAC, IBM DB2 auf OS390

Ausfall eines Knoten – Shared Disk Data A-Z X Fällt ein Rechner aus, wird die Last auf die übrigen Knoten verteilt Alle Knoten haben zu jeder Zeit Zugriff auf alle Daten Adressiert Skalierbarkeit & Ausfallsicherheit: Ausfallzeit < 1 Minute Alle noch verfügbaren Ressourcen nutzbar (hier 75%)

Clustertypen - Zusammenfassung SD = Shared Data SN = Shared Nothing FC = Failover Cluster

Agenda Einführung Clusterumgebungen Oracle Real Application Clusters Oracle RAC Konfigurationsvarianten Q&A

Oracle10g Real Application Clusters basierend auf dem Shared Disk System XXX User XXX User Knoten 1 Knoten v2 DB-Cache1 DB-Cache2 Hintergrund der RAC Technologie und Basis dafür, dass der RAC mit allen Anwendungen problemlos eingesetzt werden kann, ist die quasi Zusammenlegung aller Datenbank-Caches auf allen Knoten durch die sogenannte und patentierte Cache Fusion Technologie. Durcjh Cache Fusion erscheinen alle Datenbank Caches auf allen Knoten als eine „globale SGA“, was die Skalierbarkeit erheblich erhöht. Ein typischer Abfrageverlauf sieht daher wie folgt aus: 1.) Anfrage an den lokalen Cache 2.) Kann dieser die Anfrage nicht befriedigen, weiterleiten der Anfrage an die anderen Caches 2.1) Kann die Anfrage befriedigt werden – Abbruch 2.2) Kann die Anfrage nicht befriedigt werden – Durchgriff auf Disk Subsystem Da eine Anfrage an einen Speicher-Cache nur ca. 5ms dauert, eine Anfrage an das Disk System allerdings ca. 60-80ms, die Wahrscheinlichkeit der Anfragenbefriedigung aus dem Cache aber – gerade bei großen Systemen – sehr groß ist, bietet der Cache in den meisten Fällen einen Performancevorteil und eine bessere Hochverfügbarkeit im Ausfallfalle, da viele häufig benutze Objekte noch im Cache vorhanden sind.

Oracle10g Real Application Clusters Basistechnologie (patentiert) : DB-Cache Fusion XXX User XXX User Knoten 1 Knoten v2 Cache Fusion DB-Cache1 DB-Cache2

OPS Cache Coherence Implementierung früher: Inst 1 Inst 2 Inst 3 DBA: 4711 G.Stürner L.Ellison R.Lane …. G.Bloom J.Henley DBA: 4711 G.Stürner L.Ellison R.Lane …. G.Bloom J.Henley DBA: 4711 G.Stürner L.Ellison R.Lane …. G.Bloom J.Henley Block Shipping Block Shipping Inst 1 DBA: 4711 G.Stürner L.Ellison R.Lane …. G.Bloom J.Henley Inst 2 Inst 3 früher: OPS DBA: 4711 G.Stürner L.Ellison R.Lane …. G.Bloom J.Henley DBA: 4711 G.Stürner L.Ellison R.Lane …. G.Bloom J.Henley Block Ping Block Ping Block Ping Block Ping L.Ellison R.Lane …. DBA: 4711 G.Stürner J.Henley

Cache Fusion Komponenten Global Resource Directory (GRD) Verwaltet Resourcen im Cluster In-Memory Struktur (in SGA) Repliziert auf allen Instanzen Für jede Resource gibt es genau einen Resource Master (siehe GCS, GES) Resourcen: Informationen über Datenblöcke Lokal/global Null Lock, Shared, Exclusive Welche Instanz hat aktuelle Version

Cache Fusion Komponenten Global Cache & Enqueue Service (GCS, GES) - Verantwortlich für Integrität des GRD - Nominieren eines Resource Masters (dynamisch, kann wechseln) - Läuft auf jeder Instanz, Kommunikation über Interconnect - Beteiligt am Instance Recovery bei Ausfall einer Instanz

Oracle10g Real Application Clusters - Beispiel DB-Cache1 DB-Cache2 XXX User Zwei (oder mehr) Knoten Eine Datenbank

Oracle10g Real Application Clusters Die Arbeitsweise der Oracle10g Real Application Clusters anhand von drei typischen Zugriffsszenarien: 1. Read-Read 2. Write-Read 3. Write-Write

Oracle10g Real Application Clusters-Beispiel 1 DB-Cache1 DB-Cache2 1. select A from … 10 20

Oracle10g Real Application Clusters-Beispiel 1 1. select A from … 2. select B from … DB-Cache1 DB-Cache2 20 10 10 20

Oracle10g Real Application Clusters-Beispiel 1 1. select A from … 2. select B from … 2. select B from … DB-Cache1 DB-Cache2 20 20 10 10 20

Oracle10g Real Application Clusters Die Arbeitsweise der Oracle10g Real Application Clusters anhand von drei typischen Zugriffsszenarien: 1. Read-Read 2. Write-Read 3. Write-Write

Oracle10g Real Application Clusters-Beispiel 2 1. update T set B=22 where ... DB-Cache1 DB-Cache2 ??? 20

Oracle10g Real Application Clusters-Beispiel 2 1. update T set B=22 where ... DB-Cache1 DB-Cache2 20 20

Oracle10g Real Application Clusters-Beispiel 2 1. update T set B=22 where ... DB-Cache1 DB-Cache2 20 22 20

Oracle10g Real Application Clusters-Beispiel 2 2. select B from ... 1. update T set B=22 where ... DB-Cache1 DB-Cache2 20 ??? 22 20

Oracle10g Real Application Clusters-Beispiel 2 2. select B from ... 1. update T set B=22 where ... DB-Cache1 DB-Cache2 20 20 22 20

Oracle10g Real Application Clusters-Beispiel 2 2. select B from ... 1. update T set B=22 where ... 3. commit DB-Cache1 DB-Cache2 20 20 22 20

Oracle10g Real Application Clusters Die Arbeitsweise der Oracle10g Real Application Clusters anhand von drei typischen Zugriffsszenarien: 1. Read-Read 2. Write-Read 3. Write-Write

Oracle10g Real Application Clusters-Beispiel 3 1. update T set B1=22 where B1=20... DB-Cache1 DB-Cache2 20 40 x22 40 20 40

Oracle10g Real Application Clusters-Beispiel 3 1. update T set B1=22 where B1=20... 1. update T set B2=44 where B2=40... DB-Cache1 DB-Cache2 20 40 x22 40 ??? 20 40

Oracle10g Real Application Clusters-Beispiel 3 1. update T set B1=22 where B1=20... 1. update T set B2=44 where B2=40... DB-Cache1 DB-Cache2 20 40 x22 40 x22 40 20 40

Oracle10g Real Application Clusters-Beispiel 3 1. update T set B1=22 where B1=20... 1. update T set B2=44 where B2=40... DB-Cache1 DB-Cache2 20 40 x22 x44 x22 40 x22 40 20 40

Agenda Motivation Clusterumgebungen Oracle Real Application Clusters Oracle RAC Konfigurationsvarianten F&A

Oracle10g Real Application Clusters Diese Technologie ist einzigartig und kombiniert Skalierbarkeit und Hochverfügbarkeit für alle Anwendungen: OLTP DWH Internet/Intranet-Auftritte

Oracle10g RAC: Out-of-the-box Scalability 89% Scalability SAP(R) R/3 4.6C SD-Scalability Scale Factor 1,8 (Basis: 2 Node) 1,8 (Basis: 1 Node) 1,0

Oracle10g RAC: Performance mit HMP Protokoll 95% Scalability # Users Oracle E-Business Suite 11i Scalability 4,368 2,296

Skalierbarkeit: Shared Disk / Shared Data User User Nutzung aller Ressourcen Geeignet für jede Applikation OLTP DWH ODS Hybrid, etc. Transparentes Load Balancing User User User User User (Standard-) Applikation CPU 50% 100% CPU 50% 100% CPU 50% 100% CPU 50% 100% Data A-Z

Client & Serverseitiges Loadbalancing Verbindungsaufbau nach einem Zufallsprinzip verwendet die Adressliste der tnsnames.ora Listener verteilen Anfragen basierend auf CPU-Last PMON Prozess meldet den Listenern die Knotenauslastung rac1 Instanz Knoten 1 lsnr1 rac2 lsnr2 Rac Datenbank Client 3 Netzwerk Client 1 Client 2 Client 4 Client n The TNS Listener establishes connections between client programs and service handlers. The goal is to use the listener to perform intelligent load balancing over distributed services which span multiple nodes. Connection time load balancing will also be provided by the Listener. The service registration will be extended to directly support registration of all three tiers of the service hierarchy. The middle tier (INSTANCE) will also be able to report its load, enabling the listener to balance clients over multiple nodes. The Oracle RDBMS will continue to register and report load for MTS dispatchers, and dedicated server handlers. It will register instance information separate for service handler information. The main service registration function, must be modified to interpret the registration data. Client input in the form of CONNECT_DATA contains the specification of how the client wishes to connect to the service. Valid parameters that are supported: SERVICE_NAME INSTANCE_NAME SID Knoten 2

Oracle10g Real Application Clusters - Hybrid Konfigurationen Complex Query Gleichzeitiger OLTP und DSS Betrieb Dedizierter OLTP Knoten für schnelle Antwortzeiten DSS Nutzer sehen aktuellste Daten Query OLTP OLTP Node Node Node Node Node OLTP DSS

Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit bis 30 Minuten Oracle10g RAC Konfigurationsvarianten Oracle Single Instance & klassischer Failover Cluster Aktiver Oracle10g Knoten Standby Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit bis 30 Minuten Skaliert bis max. Anzahl der CPUs des akt. Knotens Crash betrifft 100% der User Einfache Standby Lösungen sehen, vor einen zweiten – völlig selbständigen – Knoten als Absicherung des ersten zu verwenden. Während er bereits mit der notwendigen Software vorkonfiguriert ist, muss im Ausfallfalle die Anbindung an die Disk Systeme sowie das Starten der Instanz manuell eingerichtet werden. Dies führt zu Umschaltzeiten von mehrere Minuten. Die Skalierbarkeit ist auf einen Knoten = n CPUs begrenzt.

Oracle10g RAC Konfigurationsvarianten Oracle9i aktiv/passiv RAC Aktiver Oracle10g Knoten Passiver Oracle10g DB Knoten Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit < 1 Minute Skaliert bis max. Anzahl der CPUs des akt. Knotens Crash betrifft 100% der User

Oracle10g RAC Konfigurationsvarianten Oracle10g (aktiv/aktiv) RAC Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit < 1 Minute Skaliert bis zur Anzahl der CPUs der Knoten Crash betrifft 50% der User Leistung nach Ausfall 50% Aktiver Oracle10g Knoten / RAC Aktiver Oracle10g Knoten / RAC Eigentliche RAC – Grundidee: Zwei oder mehr Knoten, die auf ein gemeinsames Shared Disk System zugreifen. Verbindet alle Vorteile des Systems: lokale Ausfallsicherheit, schnelle Verfügbarkeit im Ausfallfall und Skalierbarkeit über mehrere Knoten mit mehreren CPUs.

Oracle10g RAC Konfigurationsvarianten Oracle10g RAC - Mehrknotenkonfiguration Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit < 1 Minute Skaliert bis zur Anzahl der CPUs der Knoten Crash betrifft 25% der User Leistung nach Ausfall 75% Aktiver Oracle10g Knoten Aktiver Oracle10g Knoten Aktiver Oracle10g Knoten Aktiver Oracle10g Knoten Eigentliche RAC – Grundidee: Zwei oder mehr Knoten, die auf ein gemeinsames Shared Disk System zugreifen. Verbindet alle Vorteile des Systems: lokale Ausfallsicherheit, schnelle Verfügbarkeit im Ausfallfall und Skalierbarkeit über mehrere Knoten mit mehreren CPUs.

Oracle10g RAC Konfigurationsvarianten Oracle Transparent Application Failover Benutzer werden automatisch auf einem intakten Knoten übernommen und lesende Zugriffe fortgesetzt Beide Knoten aktiv Zugriff auf eine Datenbank Aktiver Oracle9i DB Knoten / RAC Aktiver Oracle10g Knoten / RAC empno name 7369 Smith 7499 Allen 7521 Ward 7566 Jones 7654 Martin 7698 Blake Ein Hauptmerkmaler aller Hochverfügbarkeitslösungen aus dem Hause Oracle ist, dass der Anwender in den meisten Fällen nichts von dem Ausfall mitbekommt. Ein Grund hierfür ist Oracle Transparent Application Failover, was im Ausfallfalle dafür sorgt, dass sich Anwender nicht noch einmal auf dem neuen Knoten anmelden müssen (Übernahme des Anmeldekontext) und lesende Zugriffe fortgesetzt werden. Einzig schreibende Zugriff müssen neu aufgesetzt werden.

TAF erneuter Verbindungsaufbau Automatischer, erneuter Verbindungsaufbau nächster Eintrag in der Address-Liste in tnsnames.ora Node 1 Client rac1 instance RAC Database lsnr1 TNS rac1 rac2 RAC = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = rac1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = rac2)(PORT = 1521)) (LOAD_BALANCE = off) (FAILOVER = ON) (CONNECT_DATA = (SERVICE_NAME = rac) (failover_mode = (type=select)(method=basic)) ) rac2 instance lsnr2 Node 2

F & F R A G E N A N T W O R T E N A