Oracle und Hochverfügbarkeit – Verschiedene Ansätze im Vergleich

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

24

Vielen Dank für Ihre Aufmerksamkeit!

E-Mail dierk.lenz@hl-services.deTwitter @ora1578http://blog.hl-services.de