Oracle und Hochverfügbarkeit – Verschiedene Ansätze im Vergleich Dierk Lenz Herrmann & Lenz Services GmbH DOAG Regio München/Südbayern 14. April 2014
Oracle und Hochverfügbarkeit –Verschiedene Ansätze im Vergleich
Dierk LenzHerrmann & Lenz Services GmbHDOAG Regio München/Südbayern
14. April 2014
Herrmann & Lenz Services GmbHHerrmann & Lenz Solutions GmbH
• Erfolgreich seit 1996 am Markt
• Firmensitz: Burscheid (bei Leverkusen)
• Beratung, Schulung und Betrieb/Fernwartung rund um das Thema Oracle Datenbanken
• Schwerpunktthemen: Hochverfügbarkeit, Tuning, Migrationen und Troubleshooting
• Herrmann & Lenz Solutions GmbH
– Produkt: Monitoring Module
22
Inhalt
• Anforderungen
• Hochverfügbarkeit der Infrastruktur
• Hochverfügbarkeit der Datenbank
• Betrieb mit mehreren RZs
3
Anforderungen
4
Je höher die Management-Ebene…
• Es darf nichts ausfallen!
• Fehler dürfen nicht beim Anwender bemerkt werden!
• Ohne Administrationsaufwand!
• Keine Zusatzkosten!
5
Realistisch…
• Durch Compliance-Anforderungen u.ä.bekommt das Thema Hochverfügbarkeit mehr Aufmerksamkeit
• Begriffe und Bedeutung nach wie vor oft unklar
– „Bei Oracle ist RAC doch Hochverfügbarkeit!“
6
Aspekte
• Hochverfügbarkeit auf einer Ebene nützt gar nichts…
– „RAC-in-a-Box“
– DB hochverfügbar; aber Zugriff über einen zentralen Switch
– Standby DB; aber Clients ohne TNS-Informationen hierzu
7
Wichtige Zutaten
• Anforderungsanalyse
• Konzept zur Hochverfügbarkeit auf allen Infrastrukturebenen
• Checklisten für den Notfall („Betriebshandbuch“)
• Regelmäßige Übungen
• Hochverfügbarkeit kostet Geld!– Hardware
– Software
– Know How (!!!)
8
Hochverfügbarkeit der Infrastruktur
9
Was ist gemeint?
• Verlust von „Kisten“
• Kein Datenverlust
– Annahme: hier greift ein redundantes Speicherverfahren
10
Zwei Standards im Markt
RAC
• Oracle-Architektur
• Aktiv/Aktiv-Technologie
• Skalierbarkeit UND
• Hochverfügbarkeit
Virtualisierung (VMWare)
• Virtualisierungs-Cluster
• Storage für virtuelle Maschinen nicht lokal
• Virtuelle Maschinen können „geschwenkt“ werden
11
RAC
Vorteile
• Bewährte Oracle-Technologie
• Bei Standard Edition kostenlos
Nachteile
• Nicht jede Anwendung skaliert
• Spezial Know-Howerforderlich
12
VMWare
Vorteile
• In vielen Unternehmen vorhanden
• Bewährte Technologie
Nachteile
• Komplett „extern“: Oracle hat keine Kenntnis von VMWare
• Lizenzierung: Oracle „sieht“ VMWare nicht
• Support: keine direkte Unterstützung von Oracle
• Performance-Einfluss
13
Weitere Alternativen
• Oracle VM
– Nicht oft eingesetzt
– Hardware Partitioning möglich: „Teile“ der Maschine lizenzierbar
• Kombinationen
– RAC mit Virtualisierung
– Sehr komplex, insbesondere in der Betrachtung möglicher Störungen
14
Hochverfügbarkeit der Datenbank
15
Was fehlt denn noch?
• Annahme aller besprochenen Konzepte
Die Datenbank ist und bleibt unbeschädigt!
• Wenn dieser Fall doch eintritt:– Rücksicherung/Wiederherstellung notwendig
– Je nach Infrastruktur, DB Größe, Wiederherstellungsaufwand:
Zeitaufwändig!
16
Konzept: Physische Standby-Datenbank
• Physische Kopie der primären Datenbank
• Versorgung mit Redolog-Strom der primären Datenbank
• Durch permanente Widerherstellung „auf dem aktuellen Stand“
17
Und die Logische Standby-Datenbank?
• Unterschied zur physischen Standby-DB:– Generierung von SQL aus dem Redolog-Strom
– Anwendung des SQL stat Wiederherstellung
• Erfahrung: Kann bzgl. Robustheit und Vollständigkeit nicht mit physischer Standby-DB mithalten
• Besser geeignet für Migrationen oder Spezialaufgaben (Warehouse-Versorgung usw.)
18
Einsatz von Standby-Datenbanken
• Erforderlich, wenn Rücksicherung zu lange dauert (meist ab ca. TB-Größe)
• Diverse Produkte
– Oracle Data Guard (Enterprise Edition)
– Dbvisit Standby
– …
• Spezial Know-How erforderlich
19
Betrieb mit mehreren RZs
20
Absicherung von „Komplettes RZ fällt aus“
• Generell extrem komplex, z.B. aufgrund von Netzwerkproblematiken
• Anforderungen von „Vorhandene Sicherung im zweiten RZ reicht“…
• bis „Automatische Übernahme aller Funktionen“
21
Eigentlich kein Problem, aber…
• Geteiltes RAC („Stretched Cluster“) ggfs. problematisch aufgrund der Netzwerkanbindung
– Latenz problematisch für Interconnect
• Standby-DB möglich, aber Eingriff für Failover notwendig
– Auch Fast-Start Failover bei Data Guard…
22
Hier insbesondere
• Anforderungen genau klären
• Mechanismen so gut es geht testen
• Ggfs. weitere Komponenten in Erwägung ziehen, Z.B. RAC One Node
23