Architektur- und Realisierungsaspekte von Oracle Real Application Cluster (RAC)

Präsentation zum Thema: "Architektur- und Realisierungsaspekte von Oracle Real Application Cluster (RAC)"—  Präsentation transkript:

1

2 Architektur- und Realisierungsaspekte von 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

5 Frühe Entscheidung für OPS Technologieführerschaft
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 Benchmark Weltrekord (1073 tpsB) Production Sites Frühe Entscheidung für OPS Technologieführerschaft

6 Cluster Jeder Hersteller, Jede Architektur Real Application Clusters
Jeder Hersteller: Sun, HP, Compaq, 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 Oracle9i eine Codebasis auf allen Plattformen alle Oracle9i 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

9 Knoten (Nodes) Jeder Knoten ist ein eigenstaendiger 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 (Compaq) 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 (CFS) 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 Agenda Motivation Clusterumgebungen Oracle Real Application Clusters
Oracle RAC Konfigurationsvarianten Q&A

14 Clusterumgebungen Clustertypen: Failover Cluster Shared Nothing
Shared Disk

15 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

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

17 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

18 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

19 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

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

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

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

23 Oracle9i 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.

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

25 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

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

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

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

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

30 Oracle9i 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

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

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

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

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

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

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

37 Oracle9i 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

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

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

40 Oracle9i 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

41 Oracle9i 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

42 Oracle9i 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

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

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

45 Oracle9i 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

46 Oracle9i RAC: Performance (Version 9.02) mit HMP Protokoll
95% Scalability # Users Oracle E-Business Suite 11i Scalability 4,368 2,296

47 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

48 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

49 Oracle9i 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

50 Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit bis 30 Minuten
Oracle9i RAC Konfigurationsvarianten Oracle Single Instance & klassischer Failover Cluster Aktiver Oracle9i DB 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.

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

52 Oracle9i RAC Konfigurationsvarianten Oracle9i (aktiv/aktiv) RAC
Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit < 1 Minuten Skaliert bis zur Anzahl der CPUs der Knoten Crash betrifft 50% der User Leistung nach Ausfall 50% Aktiver Oracle9i DB Knoten / RAC Aktiver Oracle9i DB 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.

53 Oracle9i RAC Konfigurationsvarianten Oracle9i RAC - Mehrknotenkonfiguration
Lokale Ausfallsicherheit auf Rechnerebene Umschaltzeit < 1 Minuten Skaliert bis zur Anzahl der CPUs der Knoten Crash betrifft 25% der User Leistung nach Ausfall 75% Aktiver Oracle9i DB Knoten Aktiver Oracle9i DB Knoten Aktiver Oracle9i DB Knoten Aktiver Oracle9i DB 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.

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

55 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

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