RAC

Mission Mid Market
Matthias Weiß
Business Unit Database
Oracle Deutschland GmbH
RAC
Technisches Training
Agenda




Überblick und Architekturen von HA-Systemen
Hardware – Die Basis
Oracle RAC – Die Lösung für HA-Anforderungen
Praxisteil
–
–
–
Konfiguration
Installation
Test
Was kostet Sie die Ausfallzeit?
“keine Ahnung”
60%
“genaue Analyse
zu aufwendig”
19%
“diese Kosten wurden
bereits ermittelt”
21%
Quelle: Gartner Group & Contingency Planning Research, Inc.
Verfügbarkeit von EDV-Systemen
Anwendung
Middleware
& Utilities
Datenbank
Software
Netzwerk
Software
Betriebssystem
Hardware


Hochverfügbarkeit einer Anwendung
bedeutet Hochverfügbarkeit ALLER
Komponenten
Suche nach der schwächsten Komponente
Hochverfügbare Anwendungen
Multitier = Multirisiko
Clients
Load Balancer
Web Cache
Application
Server Schicht
OC4J Cluster
Cluster
Datenbank
Schicht
Hochverfügbarkeit
- Ausfallzeiten versus Kosten
Downtime pro Jahr (7x24x365)
Prozentsatz
Verfügbarkeit
Tage
Stunden
Minuten
95%
18
6
0
99%
3
15
36
99.9%
0
8
46
99.99%
0
0
53
99.999%
0
0
5
99.9999%
0
0
1
“…even 99.9% data availability can cost a company nearly $5m
a year”
- The Standish Group 2001
Ausfallzeiten – Unterschiede
Ungeplante
Ausfallzeit
Geplante
Ausfallzeit
Systemfehler
Stromausfall
Systemabsturz
Datenfehler
& Desaster
Datenkorruption
Flut, Feuer, usw.
Menschliche
Fehler
Löschen von
(System-) Daten
Routine
Operationen
Schema
Anpassungen
SystemWartung
Hardware &
O/S Upgrades
Verfügbarkeitslösungen und mehr




Failover Lösungen
Stand By Systeme
Cluster
sonstiges




Ungenutzte HW / SW-Kosten
Ungenutzte HW / SW-Kosten
Kosten der SW (Cluster, Files.)
Wachstum/Skalierung
Failover-Lösungen
Ungenutzte HW / SW-Kosten
Standby Systeme
Produktion
Standby
Ungenutzte HW / SW-Kosten
Cluster Systeme
Database
A
Database
B
Microsoft
Federated
Database
Partition A
Partition B
Database A
IBM (Unix, Windows) IBM (Mainframe)
Shared Nothing
Oracle
Cluster
SW-Kosten (Cluster, Filesystem)
Shared Disk
Wachstum/
Skalierung
Vertikal
Einstieg
Horizontal
HA Architekturen/Systeme
Verfügbarkeit
Applikationstyp
Standardapplikationen
Transaktionsverarbeitung
Data Warehouse
Failover Cluster
Shared Nothing Architektur
Oracle RAC Architektur
Skalierbarkeit
Agenda




Überblick und Architekturen von HA-Systemen
Hardware – Die Basis
Oracle RAC – Die Lösung für HA-Anforderungen
Praxisteil
–
–
–
Konfiguration
Installation
Test
Agenda




Überblick und Architekturen von HA-Systemen
Hardware – Die Basis
Oracle RAC – Die Lösung für HA-Anforderungen
Praxisteil
–
–
–
Konfiguration
Installation
Test
Real Application Cluster
Cluster Systeme
Cache
Fusion
Db A
Db B
Partition A Partition B
Microsoft
IBM
Federated
Database
Shared Nothing
Cluster
Database A
Database A
IBM (Mainframe)
Oracle
Shared Disk
Real Application
Cluster
Oracle Real Application Cluster
Transparente
Shared Cache
Architektur
(Cache Fusion)
RAC – Das Einzigartige für Vieles




RAC für Ausfallsicherheit
RAC für optimale HW-Ausnutzung
RAC für Skalierung
RAC zur Kostenoptimierung
RAC als Standard für kritische Anwendungen
RAC – Das Einzigartige für Vieles




RAC für Ausfallsicherheit
RAC für optimale HW-Ausnutzung
RAC für Skalierung
RAC zur Kostenoptimierung
RAC als Standard für kritische Anwendungen
Real Application Cluster
Mehr Computer = höhere Zuverlässigkeit + Skalierbarkeit
A–E
Oracle
F–K
L–P
Andere Anbieter
Q-Z
RAC – Das Einzigartige für Vieles




RAC für Ausfallsicherheit
RAC für optimale HW-Ausnutzung
RAC für Skalierung
RAC zur Kostenoptimierung
RAC als Standard für kritische Anwendungen
Beispiel: Dezember
 Order Entry überschreitet Kapazität
 Financials weit unter möglicher Kapazität
Order Entry
Financials
Beispiel: Januar
 Order Entry – Weihnachtsgeschäft beendet
 Financials – Jahresende u. Abschluß
Order Entry
Financials
Grid Computing mit RAC
 Load Balance basiert auf einer
“Optimierungs-Policy”
Order Entry & Financials
Oracle Real Application Cluster
Investitionsschutz
Windows
Linux
Apple
Unix
Mainframe
RAC – Das Einzigartige für Vieles




RAC für Ausfallsicherheit
RAC für optimale HW-Ausnutzung
RAC für Skalierung
RAC zur Kostenoptimierung
RAC als Standard für kritische Anwendungen
Skaliert eine Applikation auf
einem SMP System,
skaliert sie auch auf einem
RAC Cluster, ist aber überdies
hochverfügbar!
Skalierung
Vertikal
Einstieg
Horizontal
Oracle Real Application Cluster
Skalierbarkeit mit SAP R/3
83 – 90 %
Skalierbarkeit
Standard SAP SD Light Benchmark
1.200
1,200
1.000
800
868
# Benutzer
600
400
480
200
0
1 Rechner
2 Rechner
3 Rechner
SAP 2-Tier Testergebnisse
Konfiguration
Benutzer
Durchsatz
(Dsteps/Hour)
Skalierfaktor
Phase 1: Skalierbarkeit
1 node
100 SD
35,364
2 nodes
200 SD
70,320
1.99
3 nodes
300 SD
103,482
2.93
4 nodes
400 SD
133,840
3.78
Phase 2: Hochverfügbarkeit
3 nodes
400 SD
124,812
RAC – Das Einzigartige für Vieles




RAC für Ausfallsicherheit
RAC für optimale HW-Ausnutzung
RAC für Skalierung
RAC zur Kostenoptimierung
RAC als Standard für kritische Anwendungen
Beispiel Automobilzulieferer
Modellunternehmen – Teil 1





Zeitpunkt: 2003
Produktionsbetrieb aus dem Bereich Zulieferindustrie
Mitarbeiterzahl ca. 500
Jahresumsatz ca. 75 Mio €
Produktion läuft derzeit im Zwei-Schichtbetrieb
(Mo - Fr, 06:00 - 14:00 Uhr und 14:00 - 22:00 Uhr)
 ERP System mit RDBMS
 weitere Insellösungen
Modellunternehmen – Teil 2 Status 2003
Verwaltung: 34 Mitarbeiter
ERP: 29 User
Tägliche manuelle
Datenübergabe
Tägliche manuelle
Datenübergabe
ERP mit RDBMS
Lesender Zugriff
Wareneingang:15 MA
ERP: 4 User
Lagerwaltung: Access
Lesender Zugriff
Lesender Zugriff
Versand: 10 MA
ERP: 3 User
Produktion: 409 MA
ERP: 10 User
Zwischenlagerwaltung: Access
Lesender Zugriff
Lesender Zugriff
Filetransfer
QS: 12 MA
ERP: 4 User
Anwendung mit Filesystem (PC)
F&E: 20 MA
ERP: 2 User
CAD auf Workstation
Modellunternehmen – Teil 3
 2005
–
–
–
3-Schichtbetrieb (So 22:00 - Sa 06:00)
Steuerung der Produktion über ERP
Reduzierung Zwischenlager (Ausfallzeit 5 min)
 2006
–
–
Integration F&E
Warehouse Implementierung
 2007
–
–
Integration QS
Unternehmensweite Business Intelligence Nutzung
 2008
–
Fertigstellung der zentralen unternehmensweiten IT
Modellunternehmen
Versand: 10 MA; ERP: 3 User
Zwischenlagerwaltung: JAVA
Ausfallzeit max. 5 Minuten
Wareneingang: 15 MA
ERP: 4 User
Lagerwaltung: JAVA
- 2005 -2008
2006 - 2007
Endausbau
2003
Verwaltung: 34 Mitarbeiter
ERP: 29 User
QS: 12 MA
ERP: 4 User
Anwendung mit OFO (RDBMS)
Produktion: 409 MA
ERP: 10 User
Dreischichtbetrieb
F&E: 20 MA
ERP: 2 User
CAD auf RDBMS Basis
Integration
Lesender/schreibender
Zugriff
Apps. Server
Apps. Server
Real Application
Cluster
RDBMS (Single
Instance)
Data Warehouse:
Oracle - BI: 10 User
HW-Nutzung / Sicherheit
Application Server
Data Guard
RAC zur Kostenoptimierung
 Praxisbeispiel Modellunternehmen
–
Ist-Situation
 Zwischenlager für „Just in Time Delivery“
 Bisher 24 Std. Produktvorhaltung für Lieferung (1200 Paletten)
–
Soll
 Ausfallzeitreduzierung auf 5 min
 Maximum Vorhaltung für 2 Std. (180 Paletten = 3 LKW)
–
Ersparnis




Geringere Lagerhaltung
Flächengewinn
Reduzierung Facilitykosten
Evtl. Beibehaltung des 2-Schichtbetrieb
Kostenberechnung: 276.000 € Ersparnis p.a.
Real Application Cluster
Komponenten und Funktionsweise
SW-Kosten sparen
Integrated Clusterware
Vollständige Oracle Cluster Software Lösung
Cluster Control/Recovery APIs
Automatic Storage Management
Messaging and Locking
Membership
Connectivity
Hardware/OS Kernel
Management APIs
g
10
Services Framework
Event Services
 Höhe Qualität und Funktionalität
auf allen Plattformen
 Ermöglicht größere Cluster für
Grid-Einsatz
 Gleiche Event und Management
APIs
RAC
Ausflug: Das Platten Dilemma
„Damals und Heute“ - am Beispiel einer 180 GB Datenbank
1993
Einzelne Platte
1 GB Platte
2 MB/sek
50 IO/sek
20 ms Zugriff
3.600 upm
Gesamtsystem
180 Platten
360 MB/sek
9000 IO/sek
1996
4 GB Platte
6 MB/sek
70 IO/sek
14
7.200
ms Zugriff
upm
45 Platten
270 MB/sek
3150 IO/sek
2000
72 GB Platte
40 MB/sek
160 IO/sek
6
10.000
ms Zugriff
upm
3 Platten
120 MB/sek
480 IO/sek
180 GB
Beachte: adäquate Konfiguration des I/O Bussystems
2002
180 GB Platte
30 MB/sek
120 IO/sek
8
7.500
ms Zugriff
upm
1 Platte
30 MB/sek
120 IO/sek
Historie & Trends
Gefahr: Datenbanken werden mit immer weniger Platten aufgebaut
Entwicklung
[Faktor]
200
Plattenkapazität
CPU-Leistung
IO-Leistung bezogen auf
DB-Größe
Durchsatz
IO-Rate
30
Zeit
1993
1997
Heute
Kaufen Sie IO-Leistung, nicht IO-Kapazität !!!
DB-Größe
SW-Kosten sparen
Automatisches Speicher Management
Application
Application
Application
Application
Database
File System
ASM
Volume Manager
Operating System
Database
SW-Kosten sparen
Automatisches Speicher Management
ASM
Heute
Tables
Tables
Tablespace
Files
Tablespace
0010 0010 0010 0010 0010
0010 0010 0010 0010 0010
Files
File System
File System
Logical Vol
Logical Vol
Disk Group
Disk Group
 Einfache Implementierung
 Kein Mapping nötig
Oracle
ASM
SW-Kosten sparen
Automatisches Speicher Management
 Verwaltet sämtlichen Speicher für
die Datenbank
–
Dateien, Tabellen, etc.
 Kein Volume oder File System nötig
–
Automatic Storage
Management
Nur “Pool of storage”
 Ermöglicht effizientes Online
Management (add/remove disk)
 Automatisches Spiegeln, Striping
und Rebalancing
 Vermeidet permanentes manuelles
I/O Tuning
Automatic Storage Management
Traditionell
1. Festlegung des benötigten
Speichers
2. Installieren Volume
Manager, File System
3. Festlegung Daten Layout
zur Vermeidung von Hot
Spots
4. Erstellen Logical Volumes
5. Erstellen File System
6. Installation Oracle Software
7. “Create database”
vs
ASM – Setup
1. Festlegung des benötigten
Speichers
2. Installation Oracle
Software
3. Erstellen Disk Groups
4. “Create database”
Automatic Storage Management
Traditionell
vs
1. Tägliches Monitoren der I/O
Leistung
2. Entdecken der Hot Spots
3. Konfigurationsplanung zur
Vermeidung von Hot Spots
4. Daten zu neuen Files transferieren
5. Files in der Databank umbenennen
6. Verifizieren ob Hot Spots Probleme
behoben
ASM – I/O Tuning
Keine Aktivitäten !!!
ASM senkt SW und Management Kosten
8
7
7
8
6
6
6
7
Nbr Steps
6
5
5
4
4
3
2
2
2
1
0
0
Traditional
ASM
0
Install
Add Storage
Remove
Storage
Migrate
Storage
Tune I/O
Manage
Space
“Der beste Weg Kosten zu sparen, ist Komplexität zu reduzieren.”
Rolling Upgrades
RAC Evolution - Rolling Upgrades
Clients
Patch
B
A
1
2
A
B
RAC Konfiguration
Clients A
B
Patch  B
Patch
4
A
B
OK !!!
3
A
Patch  A
Oracle
Patches
B
Clients  B
Betriebssystem
Upgrades
Hardware
Upgrades
RAC Funktionsweise
Read / Read request
Global cache request
Inst
SGAA
SGA
1
GCS
Read Request
Lockinfo DBA: 4711
Mode Version ...
Global cache get / convert
(time)
SHRD Current
DBA: 4711
G.Stürner
L.Ellison
Inst
SGAB
SGA
2
Current-
Block Shipping
GCS
Lockinfo DBA: 4711
Mode Version ...
NULL
SHRD Current
DBA: 4711
G.Stürner
L.Ellison
R.Lane
….
R.Lane
….
Global cache current block send time
Redo
DBA: 4711
G.Stürner
L.Ellison
R.Lane
….
Redo
Write / Read -Request
Global cache request
Inst
SGAA
SGA
1
GCS
Lockinfo DBA: 4711
Mode Version
...
CR Request (SCN)
EXCL Current
DBA: 4711
G.Stürner
L.Ellison
G.Bloom
R.Lane
J.Henley
….
Global cache block build time
Redo
GCS
Lockinfo DBA: 4711
Mode Version ...
NULL
R.Lane
UNDO
Inst
SGAB
SGA
2
CR-
Block Shipping
CR
DBA: 4711
G.Stürner
L.Ellison
G.Bloom
R.Lane
….
DBA: 4711
G.Stürner
L.Ellison
R.Lane
….
Redo
Write-/Write-Request
Inst
SGAA
SGA
1
GCS
Lockinfo DBA: 4711
Mode Version ...
CR
NULL
EXCL Current
DBA: 4711
G.Stürner
L.Ellison
Write Request
Global cache convert / get
(time)
3
Current-
Block Shipping
2
LGWR
Log Force
Redo
Global cache current block flush time
GCS
Lockinfo DBA: 4711
Mode Version ...
NULL
EXCL
Current
DBA: 4711
G.Stürner
L.Ellison
S.Sanders
S.Abbasi
G.Bloom
R.Lane
J.Henley
….
J.Henley
G.Bloom
R.Lane
….
Evtl: Global cache defer
Inst
SGAB
SGA
DBA: 4711
G.Stürner
L.Ellison
R.Lane
….
Redo
RAC Argumentation
RAC Vorteile und Nutzen




Ausfallsicherheit
Automatisierung der Verfügbarkeit
Optimale HW-Auslastung
ASM (Automatic Storage Management)
–
–
–
Vereinfachte Verwaltung
Unterbrechungsfreie Erweiterbarkeit
Kostenreduzierung
 Kostenoptimierung HW & SW
 Gute Skalierung
Wirtschaftliche Gründe für RAC







Keine Mehrkosten bei ORACLE SE Lizenzen
Keine besondere Anwendungssoftware
Geringe HW Mehrkosten
Kaum größerer Administrationsaufwand
Erhöhte Ausfallsicherheit
Gute Skalierung
Zukunftssicher
Acht Türen für RAC
•
•
•
•
•
•
•
•
Vermeidung eines Geschäftsausfall
Kostensenkung durch Skalierung preisgünstiger HW
Senkung der Vorauszahlungen - “pay as you grow”
Rolling Hardware/Software Upgrade
Ausnutzung von freier HW-Kapazität
Verbesserung von SLAs
Konsolidierung der Datenbanken
Techies lieben RAC-Cluster
Agenda




Überblick und Architekturen von HA-Systemen
Hardware – Die Basis
Oracle RAC – Die Lösung für HA-Anforderungen
Praxisteil
–
–
–
Konfiguration
Installation
Test
Schneller, einfacher, intelligenter