Oracle Real Application Cluster (RAC)

Präsentation zum Thema: "Oracle Real Application Cluster (RAC)"—  Präsentation transkript:

1

2 Oracle Real Application Cluster (RAC)
Ralf Mueller Server Technologies Oracle Corporation

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

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

5 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 ?

6 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

7 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)

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

9 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

10 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)

11 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

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

13 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

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

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

16 Clusterumgebungen Clustertypen: Failover Cluster Shared Nothing
Shared Disk

17 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

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

19 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

20 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

21 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

22 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%)

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

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

25 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 ms, 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.

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

27 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

28 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

29 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

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

31 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

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

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

34 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

35 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

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

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

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

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

40 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

41 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

42 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

43 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

44 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

45 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

46 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

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

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

49 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

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

51 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

52 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

53 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

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

55 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

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

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

58 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 Smith Allen Ward Jones Martin 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.

59 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

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