Das Dokument beschreibt die Architektur und Optionen für Hochverfügbarkeit in Cloud Control, einschließlich der Verwendung von Load Balancern, gemeinsamen Speicherlösungen und Multi-OMS-Installationen. Es umfasst die relevanten Komponenten, Wartungsarbeiten und die Überwachung von Systemen, um Ausfallzeiten zu minimieren. Ein Fazit vergleicht die Vor- und Nachteile von Failover und Multi-OMS-Setups.

1. Cloud Control -
hochverfügbar von Kopf bis Fuß
Klaus Eckstein, Daniel Hillinger
Page 0 of 20

2. Dr. Klaus Eckstein
DBA seit 2000
Schwerpunkte:
• OEM
• RAC mit Grid Infrastructure
• Exadata
klaus-eckstein
Page 1 of 20

3. Daniel Hillinger
DBA seit 2013
Schwerpunkte:
• RAC mit Grid Infrastructure
• Exadata
• Dataguard
daniel8192.wordpress.com
daniel8192
daniel-hillinger
Page 2 of 20

4. “High Availability refers to the availability of resources in
a computer system, in the wake of component failures
in the system.”
Page 3 of 20
Institute of Electrical and Electronics Engineers (IEEE)

5. Agenda
• Architekturübersicht
• Mögliche Optionen für Hochverfügbarkeit
• Erweiterte Architekturübersicht
• Komponenten im Detail
• Wartungsarbeiten
• Überwachung und Sicherung
Page 4 of 20

6. OMS
Web-, Applikationsserver und BI
Publisher müssen auf demselben
Server laufen
Datenbank kann auf separatem
Server laufen
Architekturübersicht
Page 5 of 20
DB
AgentsClients
Webserver
Application
server
OMS
BI
Publisher
emcli

7. Mögliche Optionen für Hochverfügbarkeit
• Failover
• Multi-OMS
– zentraler Einstiegspunkt (loadbalancer)
– gemeinsamer Storage
– gemeinsame Datenbank
Page 6 of 20

8. Erweiterte Architekturübersicht
Page 7 of 20
Clients
Loadbalancer
mehrere OMS-Instanzen
gemeinsame Filesysteme für
BI Publisher und Software
Bibliothek
gemeinsame DatenbankDB
AgentsClients
Loadbalancer
emcli
Webserver
Application
server
BI
Publisher
BIP
share
SW
lib
Webserver
BI
Publisher
Application
server

9. Agenda
• Architekturübersicht
• Mögliche Optionen für Hochverfügbarkeit
• Erweiterte Architekturübersicht
• Komponenten im Detail
 Agenten
 Loadbalancer
 Multi-OMS
 Shared Storage
 Datenbank
• Wartungsarbeiten
• Überwachung und Sicherung
Page 8 of 20

10. Agenten
Oracle Lösung:
• Automatischer Start beim Reboot durch
/etc/init.d/gcstartup und Eintrag in /etc/oragchomelist
Bessere Lösung:
• Automatisches Wiederanstarten durch Cluster-
Integration als lokale Resource
Page 9 of 20

11. Agenten
Backup Agenten:
Verfügbar für gewisse Plug-ins
z.B.: Oracle Exadata Storage Server, Oracle Infiniband
Switch
Page 10 of 20
cel01 db01 db02

12. Loadbalancer
• zentraler Einstiegspunkt für Clients
und Agenten
• SSL-Terminierung nicht am LB
möglich
• Aktiv-Aktiv Konfiguration für das
Backend
• Verbindung von der Applikation zum
Agenten verläuft nicht über den LB
Page 11 of 20
Agents
Loadbalancer
OMS1 OMS2
Protokoll Port Quelle Ziel Kommentar
tcp 4889, 4903 Agent Loadbalancer
tcp 22, 3872 OMS1, OMS2 Agent
tcp 1521 OMS1, OMS2 Agent Mögliche Ports für Plugins

13. Loadbalancer
Page 12 of 20
IP stickiness
Verfügbarkeitsprüfung der Ports:
• des Webservers (4889, 4903, 7799,
9851)
• und des Weblogic-Servers (7301)
bzw. des BI-Publisher (9803)
Loadbalancer
Webserver
Application
server
Webserver
Application
server

14. Multi-OMS
2 oder mehr OMS-Instanzen
Jede OMS-Instanz
• läuft auf einem eigenen Server
• muss Loadbalancer-Adresse kennen
• besteht aus vorkonfigurierten Komponenten, nur
durch emctl oder Webinterface zu ändern
– Webserver
– Applikationsserver
– BI Publisher
Page 13 of 20

15. Shared Storage
Gemeinsame Software Bibliothek beinhaltet Sourcen
für „ausrollbare“ Komponenten, bspw. Agenten, Plug-
Ins, Patches
BI Publisher: BI Report Definitionen und Ergebnisse
gemeinsame Filesysteme für alle OMS-Instanzen
bspw.: NFS oder (SAN und ClusterFS)
Page 14 of 20

16. Datenbank
Anforderungen an die Datenbank:
– SYSMAN Schema
– ein Service
– keine Konfiguration für FAN, TAF, Application Continuity
Mögliche Implementierung:
• RAC-Datenbank mit Grid Infrastructure
– mit 2 Instanzen
– vom OMS getrennte Server
• Storage
– gespiegelter SAN storage
Page 15 of 20

17. Wartungsarbeiten
Aktionen Online Rolling Offline Kommentare
Agenten patching/upgrade X für Ziele dieses Agenten
Loadbalancer Wartungsarbeiten X
OMS – OS patching X
OMS – Base Platform patching X
OMS – upgrade X
OMS – Plug-in ausrollen X X abhängig vom Plug-in
Shared Storage nicht verfügbar X einige Funktionen nicht verfügbar
DB – OS patching X
DB – Cluster patching X
DB – DB patching – rolling X
DB – DB patching – offline X
Page 16 of 20

18. Wartungsarbeiten
manueller OMS-Neustart
• notwendig, wenn Repository-Datenbank abgestürzt
• nicht notwendig, wenn Datenbank sauber
runtergefahren
# emctl status oms
Oracle Enterprise Manager Cloud Control
WebTier is Up
Oracle Management Server is not functioning because of the
following reason:
Failed to connect to repository database. OMS will be
automatically restarted once it identifies that database and
listener are up.
Page 17 of 20

19. Überwachung und Sicherung
Überwachung von Cloud Control
• Einzelkomponenten möglich
• End-to-End Überwachung notwendig z.B. durch emcli
Sicherung
• Agenten: Neuinstallation
• OMS: emctl exportconfig oms
• Software: Filesystem-Sicherung
• Shared Storage: Filesystem-Sicherung
• Repository: normale Datenbanksicherung
Page 18 of 20

20. Fazit
Failover
+ einfachere
Konfiguration
+ einfacherer Restore
- Serviceunterbrechung
bei Failover
- Ungenutzte Resourcen
Multi-OMS
+ weniger Downtime für
Wartungsarbeiten
- Zusätzliche
Komponenten
(Loadbalancer, Shared
Storage)
Page 19 of 20