Hochverfügbarkeit von Datenbanken aus wirtschaftlicher und technologischer Perspektive am Beispiel von Oracle Data Guard


Thèse de Master, 2010

56 Pages, Note: 2.0


Extrait


Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

Tabellenverzeichnis

Glossar

Vorbemerkung

Einleitung

1 Rechtliche Vorgaben

2 Wirtschaftlicher/Organisatorischer Bedarf an Hochverfügbarkeit

3 Technologische Grundlagen

4 Wahl des angemessenen Schutzmodus
4.1 Maximum Protection
4.2 Maximum Availability
4.3 Maximum Performance
4.4 Zusammenfassung zu den Schutzmodi

5 Minimierung Ungeplanter Ausfallzeit: Failover
5.1 Manuelles Failover
5.2 Fast-Start Failover
5.3 Zeitbedarf für das Failover (RTO)

6 Minimierung geplanter Ausfallzeit: Switchover
6.1 Upgrade
6.2 Migration auf andere Plattform / anderes Storage

7 Zusätzlicher wirtschaftlicher Nutzen - Steigerung des ROI
7.1 Nutzung von Standby Datenbanken für Abfragen
7.1.1 Zugriff auf Physical Standby Datenbanken
7.1.2 Zugriff auf Logical Standby Datenbanken
7.2 Verlagerung des Backups zur Standby Datenbank
7.3 Nutzung der Standby Datenbank als Testsystem

8 Alternative Hochverfügbarkeitslösungen
8.1 Real Application Clusters
8.2 Maximum Availability Architecture
8.3 Extended RAC
8.4 Remote Mirroring
8.5 Zusammenfassung zu den Alternativen

Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1 Arten von Ausfallzeit und typische Ursachen (Eigene Darstellung)

Abb. 2 Data Guard Architektur (Rich 2009, S. 29)

Abb. 3 Performance-Verlust bei Maximum Protection/Availability (Smith 2007, S. 27)

Abb. 4 RPO bei Maximum Performance (Smith 2007, S. 26)

Abb. 5 Fast-Start Failover Konfiguration (Eigene Darstellung)

Abb. 6 Minimale Ausfallzeit bei Upgrade (Eigene Darstellung)

Abb. 7 Lesender Zugriff auf Standby Datenbank (Eigene Darstellung)

Abb. 8 Logical Standby als Replikationslösung (Lilly 2006, S. 15)

Abb. 9 Backup an Physical Standby bei Real-Time Query (Eigene Darstellung)

Abb. 10 Snapshot Standby mit fortdauernder Redo-Übertragung (Eigene Darstellung)

Abb. 11"Gewöhnliche" Oracle-Datenbanken (Eigene Darstellung)

Abb. 12 RAC mit zwei Knoten (Eigene Darstellung)

Abb. 13 Maximum Availability Architecture (SCHUPMAN & To 2009, S. 108)

Abb. 14 Extended RAC (Eigene Darstellung)

Abb. 15 Remote Mirroring (Eigene Darstellung)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Tabellenverzeichnis

Tab. 1 Schutzmodi in der Zusammenfassung (Eigene Darstellung)

Tab. 2 Hochverfügbarkeitslösungen im Überblick (Eigene Darstellung)

Glossar

Automatic Storage Management: Von Oracle bereitgestellte Infrastruktur zur Verwaltung von Storage; bündelt mehrere physische Laufwerke (Devices) zu übergeordneten logischen Einheiten (Diskgroups), wobei Dateien über diese logischen Einheiten verstreut (striped) und optional gespiegelt werden können.

Active-Active-Cluster: Verbund von Rechnern, die je produktiv im Einsatz sind.

Active-Passive-Cluster: Verbund von Rechnern, bei dem mindestens ein Rechner nicht produktiv arbeitet, sondern nur bei Ausfall eines anderen Rechners als Ersatz aktiviert wird.

Asynchrone Übertragung: Änderungsinformationen, die zur Aktualisierung eines sekundären Datenbestands verwendet werden, der bei Ausfall des primären Datenbestands aktiviert wird, werden in diesem Fall nicht unmittelbar bei Änderung des Originals übertragen - insbesondere kann die Änderung des Originals bereits geschehen, bevor die Übertragung abgeschlossen wurde.

Ausfallzeit: Zeit, in der ein produktives System - im vorliegenden Fall eine Oracle-Datenbank - nicht zur Verfügung steht.

Bandbreite: Bezeichnet im Netzwerkumfeld das Datenvolumen, das pro Zeiteinheit übertragen werden kann. Häufig in Megabit/Sekunde angegeben.

Cache Fusion: Begriff aus dem → RAC - Umfeld. Bezeichnet die Möglichkeit, Daten aus einer → Instanz, die auf einem Rechner im Cluster läuft, über den → Private Interconnect in die - auf einem anderen Rechner im Cluster laufende - Instanz zu übertragen, wo die Daten ebenfalls angefordert werden, ohne dass dazu mittels I/O auf Dateien zugegriffen werden müsste.

Connect Time Failover: Technik, mit der die Verbindungsaufnahme von Clients zur produktiven Datenbank auch dann gelingt, wenn die ursprüngliche → primäre Datenbank im Rahmen eines → Failover oder → Switchover durch die → Standby Datenbank ersetzt wurde.

Database Replay: Technik, mit der die Belastung einer produktiven Oracle- Datenbank aufgezeichnet und auf einer Test-Datenbank wieder abgespielt werden kann.

Data Guard: Bezeichnung von Oracle für die Hochverfügbarkeitslösung, bei der eine → primäre Datenbank durch mindestens eine → Standby Datenbank abgesichert wird.

Datenbank: Aus Dateien bestehende Komponente eines Oracle-RDBMS.

Delay: Zeitraum, um den die Aktualisierung einer → Standby Datenbank absichtlich verzögert wird.

Failover: Der Wechsel auf eine → Standby Datenbank, wenn die → primäre Datenbank nicht verfügbar ist.

Fast-Start Failover: Automatisches → Failover, das durch einen → Observer ausgelöst wird.

Flashback: Technik, mit der ein logischer Fehler ohne großen Aufwand rückgängig gemacht werden kann.

Geplante Ausfallzeit: Beabsichtigte → Ausfallzeit, die i.d.R. zur

Durchführung von Wartungsarbeit erforderlich ist.

Heterogene Konfiguration: → primäre Datenbank und → Standby Datenbank befinden sich auf Rechnern mit unterschiedlichem Betriebssystem.

Hochverfügbarkeit: Ein System, das selbst bei Ausfall einer (wesentlichen) Komponente weiterhin benutzbar bleibt, wird als hochverfügbar bezeichnet.

Instanz: Komponente eines Oracle-RDBMS, die aus Hauptspeicherstrukturen und Hintergrundprozessen besteht. Erforderlich, um auf die → Datenbank produktiv zugreifen zu können.

Latenz: Begriff aus dem Netzwerkumfeld. Bezeichnet die Zeit, die für die Signalübertragung aufgewendet wird. Häufig in Millisekunden (ms) angegeben.

Local Area Network: Rechnernetzwerk innerhalb eines Gebäudes; i.d.R. mit Distanzen nicht über 2km.

Logical Standby: → Standby Datenbank, die mit → SQL Apply aktualisiert wird.

Metropolitan Area Network: Rechnernetzwerk innerhalb einer Stadt; i.d.R. mit Distanzen nicht über 50km.

Maximum Availability: Zweithöchster Schutzmodus bei → Data Guard. Ermöglich → Zero-Data-Loss bei Ausfall einer Komponente.

Maximum Availability Architecture: Von Oracle empfohlene High-End- Architektur, die die Vorteile von → RAC und → Data Guard kombiniert.

Maximum Performance: Niedrigster Schutzmodus bei → Data Guard. Führt zu keiner Beeinträchtigung der Performance der → primären Datenbank, selbst bei sehr großen Distanzen. Bei → Failover kann Datenverlust auftreten.

Maximum Protection: Höchster Schutzmodus bei → Data Guard. Ermöglich → Zero-Data-Loss, selbst wenn zwei Komponenten ausfallen.

Observer: Prozess, der im Schadensfall ein → Fast-Start Failover auslösen kann.

Physical Standby: → Standby Datenbank, die mit → Redo Apply aktualisiert wird.

Plattform-Migration: Wechsel von einer Betriebssystem-Plattform zu einer anderen, z.B. von Windows zu Linux.

Primäre Datenbank: Produktive Datenbank, zu deren Absicherung im Falle einer → Ausfallzeit eine → Standby Datenbank betrieben wird.

Private Interconnect: Dedizierte Netzwerkverbindung der Server innerhalb eines → Real Application Clusters zum Zwecke des Austausch von Koordinierungsinformation und produktiv genutzter Daten.

RAC on Extended Distance Clusters: → Real Application Clusters, bei dem das → Shared Storage über eine größere Entfernung gespiegelt wird.

Real Application Cluster: → Datenbank, mit der mehrere → Instanzen verbunden sind, wobei die Datenbank auf einem → Shared Storage liegt und die Instanzen auf unterschiedlichen Servern laufen, die daran angeschlossen sind.

Real-Time Query: Technik, mittels derer eine → Physical Standby auch dann jederzeit produktiv lesend verwendet werden kann, während das → Redo Apply durchgeführt wird.

Recovery: Aktualisierung einer zuvor durchgeführten Sicherung mit → Redo- Protokoll.

Recovery-Point-Objective: Datenverlust, der bei einem → Failover maximal hingenommen werden kann, gemessen in Zeiteinheiten.

Recovery-Time-Objective: Zeitdauer, die nach einem Ausfall der → primären Datenbank maximal verstreichen darf, bis wieder produktiv mit den (ursprünglich in der primären Datenbank vorhandenen) Daten gearbeitet werden kann.

Redo-Apply: Aktualisierungsform einer → Physical Standby, die nach dem Prinzip des → Recovery arbeitet.

Redo Compression: Technik, bei der das → Redo-Protokoll, das bei → asynchroner Übertragung übertragen wird, zum Zwecke des geringeren Bedarfs an → Bandbreite komprimiert wird.

Redo Stream: Bezeichnung für das fortwährende Übertragen des → Redo- Protokolls von einer → primären Datenbank zu einer → Standby Datenbank.

Redo-Protokoll: Information, die bei der Änderung von Daten aufgezeichnet wird, um diese Änderung bei Bedarf - z.B. im Rahmen eines → Recovery - erneut durchführen zu können.

Remote Mirroring: Technik, mittels derer die Änderung von Dateien auf einem Storage-System auf einem - weiter entfernten - zweiten Storage-System gespiegelt wird.

Restore: Bezeichnung für das Wieder-Einspielen einer zuvor durchgeführten Sicherung.

Return on Investment: Bezeichnung für das Verhältnis aus dem erwarteten Mehrwert und den Kosten einer Investition.

Rolling Upgrade: Wechsel auf eine höhere Version der Datenbank-Software, der mithilfe von → Logical Standby mit sehr geringer → geplanter Ausfallzeit durchführbar ist.

Schema: Bezeichnung für einen Benutzer innerhalb einer Oracle-Datenbank inkl. aller Objekte (Tabellen, Indizes etc.), die dieser Benutzer besitzt.

Shared Storage: Storage-System, an das mehrere Rechner angeschlossen sind, die es gleichzeitig verwenden.

Single Point of Failure: Bezeichnung für eine Komponente, deren Ausfall die Verfügbarkeit des gesamten Systems beeinträchtigt.

Snapshot Standby: → Standby Datenbank, die zu Testzwecken eingesetzt wird.

Split-Brain: Effekt der bei einem Multikomponenten­ Datenverarbeitungssystem eintreten kann, wenn aufgrund von Koordinierungsproblemen mehrere Komponenten einen autarken Status beanspruchen, so dass mehrere Systeme entstehen, die nicht länger eine konsistente Darstellung der Daten gewährleisten.

Split-Mirror-Backup: Verfahren zur Datensicherung, bei dem die Performance-Beeinträchtigung der zu sichernden Datenbank minimiert wird. Der primäre Datenbestand wird dabei (kostenaufwendig) auf zwei Storage-Systemen gespiegelt, von denen eines zum Zwecke der Sicherung vorübergehend von der Spiegelung des primären Datenbestandes abgekoppelt wird.

SQL Apply: Aktualisierungsform einer → Logical Standby, bei der aus dem von der → primären Datenbank stammenden → Redo-Protokoll das dort erfolgte SQL regeneriert und an der Logical Standby ausgeführt wird.

Standby Datenbank: Datenbank, die einen Datenbestand aufweist, der mit einer → primären Datenbank weitgehend identisch ist, so dass auf der Standby Datenbank bei Ausfall der primären Datenbank produktiv weitergearbeitet werden kann.

Standby Logs: Dateien, die bei einer → Standby Datenbank verwendet werden, um das von der → primären Datenbank empfangene → Redo-Protokoll zwischenzuspeichern, bevor es zur Aktualisierung verwendet wird.

Storage Area Network: An ein Netzwerk angeschlossene Datenspeicher­systeme, die Rechnern zur Verfügung stehen, die ebenfalls mit dem Netzwerk verbunden sind.

Storage-Migration: Bezeichnung für die Verlagerung der Daten eines Daten­verarbeitungssystems von einem Storage zu einem anderen.

Switchover: Bezeichnung für den Rollentausch zwischen → primärer Datenbank und → Standby Datenbank.

Synchrone Übertragung: Änderungsinformationen, die zur Aktualisierung eines sekundären Datenbestands verwendet werden, der bei Ausfall des primären Datenbestands aktiviert wird, werden in diesem Fall unmittelbar bei Änderung des Originals übertragen - insbesondere kann die Änderung des Originals nicht geschehen, bevor die Übertragung abgeschlossen wurde.

Transaktion: Eine Folge von verändernden SQL-Befehlen, die bei vollständiger Ausführung einen logisch konsistenten Datenbestand hinterlassen. Total Cost of Ownership: Die gesamten Kosten, die durch Anschaffung, Betrieb und Wartung eines Produktes entstehen.

Ungeplante Ausfallzeit: → Ausfallzeit, die unversehens aufgrund eines technischen Problems oder eines menschlichen Fehlers eintritt.

Wavelength Division Multiplexing: Frequenzmultiplexverfahren, das bei der Netzwerk-Übertragung von Daten eine hohe Dichte der zu übertragenden Wellenlängen verwendet.

Zero-Data-Loss: Ausdruck der Fähigkeit einer Sicherungslösung, bei einer Beschädigung des zu sichernden Systems eine vollständige Wiederherstellung des Datenbestandes - ohne jeglichen Verlust einer festgeschriebenen → Transaktion - zu ermöglichen.

Vorbemerkung

Wenn im vorliegenden Text die männliche Form eines Wortes in einem Kontext auftaucht, in dem ebensogut bzw. zusätzlich die weibliche Form verwendet werden könnte, so geschieht dies ausschließlich der besseren Lesbarkeit wegen. Beispielsweise wird „Administrator“ verwendet werden und nicht „Administrator und Administratorinnen“ bzw. „AdministratorInnen“. Eine wie auch immer geartete Diskriminierung ist damit nicht beabsichtigt.

Einleitung

In der vermutlich überwiegenden Zahl der Unternehmen gehören heutzutage Datenbanken zum Kern der IT-Infrastruktur, und ein Ausfall dieser wesentlichen Ressource würde ernsthafte Folgen zeitigen, u.U. gar die Unternehmensexistenz gefährden. Die vorliegende Arbeit soll Wege aufzeigen, wie ein solcher Verlust der Datenbank-Verfügbarkeit vermieden werden kann, wobei neben technologischen Aspekten auch wirtschaftliche und orga­nisatorische Gesichtspunkte betrachtet werden.

Auf diese Weise soll die Entscheidungsfindung bzgl. der diskutierten Varianten nach ökonomischen Kriterien ermöglicht werden. Der technologische Aspekt wird dabei in einer Tiefe behandelt, die für eine auch technisch fundierte Entscheidung ausreicht, jedoch nicht als Anleitung zur Implementierung dienen kann.

Der Fokus auf Datenbanken und Hochverfügbarkeits-Lösungen des Herstellers Oracle erscheint dabei insofern gerechtfertigt, als unternehmenskritische Datenbanken mehrheitlich Oracle-Datenbanken sein dürften, hat doch dieser Hersteller laut einer aktuellen Studie der Gartner Group (Graham et al. 2009) einen Marktanteil von 48,9 Prozent - mehr als die nachfolgenden sechs Hersteller zusammen.

Hochverfügbarkeit bedeutet grundsätzlich, dass selbst bei Ausfall einer Kern­komponente der Betrieb des (Datenbank-)Systems weiterhin möglich ist, ohne dass Anwender mehr als eine kurze Unterbrechung wahrnehmen (s. IEEE 2009).

In einem strengeren Sinne ist der Begriff „Hochverfügbarkeit“ von der Harvard Research Group so definiert, dass ein hochverfügbares System nur eine Ausfallzeit von 52,2 Min pro Jahr gestattet (vgl. Held 2005, S. 45).

Beiden Auslegungen kann mit den in dieser Arbeit diskutierten Techniken entsprochen werden.

Data Guard ist die Bezeichnung, die Oracle für die Hochverfügbarkeitslösung verwendet, bei der eine primäre Datenbank durch mindestens eine Standby Datenbank abgesichert wird. Technologische und wirtschaftliche Aspekte dieser Architektur bilden den Schwerpunkt der vorliegenden Arbeit.

Im ersten Kapitel werden zunächst die rechtlichen Vorgaben angesprochen, die neben wirtschaftlichen Erwägungen ein Anlaß sein können, die Umsetzung einer Hochverfügbarkeitslösung zu erwägen. Im zweiten Kapitel werden dann wirtschaftliche und organisatorische Gesichtspunkte von Hochverfügbarkeit thematisiert, wobei insbesondere auf die Notwendigkeit einer angemessenen Balance zwischen Anforderungen hinsichtlich Dauer eines möglichen Ausfalls, potenziell eintretenden Datenverlusts und aufzuwendender Kosten hingewiesen wird. Das dritte Kapitel führt in grundlegende Konzepte der hier diskutierten Hochverfügbarkeitslösung ein, ohne allerdings eine detaillierte technische Darstellung anzustreben. Kapitel Vier erläutert die drei unterschiedlichen Schutzmodi, die Data Guard anbietet. Wiederum ist das technische Niveau der Darstellung hinreichend, um eine fundierte Einschätzung zu ermöglichen, die jedoch von wirtschaftlichen und organisatorischen Erfordernissen geleitet ist. Das fünfte Kapitel befaßt sich mit einem Hauptgrund zur Implementierung einer Hochverfügbarkeitslösung: Tritt der Schadensfall ein, kann mittels Einsatz der zu diesem Zwecke vorgehaltenen Redundanz weitergearbeitet werden. Methoden, Zeitbedarf und der - abhängig von der Methode - möglicherweise eintretende Datenverlust werden dort besprochen.

Das Kapitel Sechs behandelt dagegen den Umgang mit Situationen, bei denen die Datenbank nicht aufgrund technischen oder menschlichen Versagens ausfällt, sondern aufgrund beabsichtigter Wartungsarbeiten nicht verfügbar ist. Auch solche Zeiten sind mit der hier erörterten Technologie minimierbar. Im siebten Kapitel werden diverse zusätzliche Nutzungsmöglichkeiten von Data Guard angesprochen, die neben dem eigentlichen Hauptzweck, Hochverfügbarkeit herbeizuführen, die aufzuwendenden Kosten zu relativieren geeignet sind. Das achte Kapitel schließlich vergleicht Data Guard mit anderen Alternativen, die ebenfalls mit dem Ziel, Hochverfügbarkeit für Oracle-Datenbanken zu ermöglichen, eingesetzt werden könnten.

1 Rechtliche Vorgaben

Vielfach bestehen neben organisatorischen auch rechtliche Anforderungen, die die Verfügbarkeit von Datenbanken verlangen. Relativ konkret fassbar ist dies insbesondere bei Banken, Telekommunikations-Dienstleistern und Energie­versorgern:

AT 7.2 Technisch-organisatorische Ausstattung

[..] Die IT-Systeme (Hardware- und Software-Komponenten) und die zugehörigen IT- Prozesse müssen die Integrität, die Verfügbarkeit, die Authentizität sowie die Vertraulichkeit der Daten sicherstellen.

AT 7.3 Notfallkonzept

[..] Die Geschäftsfortführungspläne müssen gewährleisten, dass im Notfall zeitnah Ersatzlösungen zur Verfügung stehen. Die Wiederanlaufpläne müssen innerhalb eines angemessenen Zeitraums die Rückkehr zum Normalbetrieb ermöglichen.

(BaFin, 2009, Hervorh. durch den Verf.)

§ 109 Technische Schutzmaßnahmen

[...] Wer Telekommunikationsanlagen betreibt, die dem Erbringen von Telekommunikationsdiensten für die Öffentlichkeit dienen, hat [...] angemessene technische Vorkehrungen [...] zum Schutze gegen Störungen, die zu erheblichen Beeinträchtigungen von Telekommunikationsnetzen führen, und gegen äußere Angriffe und Einwirkungen von Katastrophen zu treffen.

(TKG, 2004)

§ 13 Systemverantwortung der Betreiber von Übertragungsnetzen Zur Vermeidung schwerwiegender Versorgungsstörungen haben Betreiber von Übertragungsnetzen jährlich eine Schwachstellenanalyse zu erarbeiten und auf dieser Grundlage notwendige Maßnahmen zu treffen.

(EnWG, 2005)

In anderen Branchen sind die gesetzlichen Vorgaben bzgl. der Sicherstellung der Verfügbarkeit von Unternehmensdaten weniger konkret beschrieben aber gleichwohl vorhanden bzw. ableitbar, etwa:

§ 91 Organisation. Buchführung (Abs. 2)

Der Vorstand hat geeignete Maßnahmen zu treffen, insbesondere ein Überwachungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende Entwicklungen früh erkannt werden.

(AktG, 2009, Hervorh. durch den Verf.)

Des weiteren leitet sich aus dem US-amerikanischen Sarbanes-Oxley Act von 2002 nach Knolmayer & Wermelinger auch für Unternehmen außerhalb der USA, sofern sie börsennotiert oder Tochtergesellschaften börsennotierter US- Unternehmen sind, u.a. die Pflicht ab, für die „permanente“ Verfügbarkeit von für die Geschäftstätigkeit relevanten Daten zu sorgen (2006, S. 12 ff.).

Es handelt sich also nicht allein um technische Fragen, die ausschließlich in den Bereich und die Verantwortung der IT-Abteilung eines Unternehmens fallen; vielmehr ist die Unternehmensleitung im Zweifelsfall verantwortlich und sollte daher auch bei der Planung und Umsetzung von Maßnahmen zur Ge­währleistung von Hochverfügbarkeit involviert sein (vgl. Hiatt 2000, S. 13 ff). Zu dieser Schlußfolgerung kommt ebenso Humphrey (2005):

It is becoming increasingly apparent that the nature of the business continuity plan development process and regulatory requirements demand a more integrated participation level by those responsible for leading an organization.

2 Wirtschaftlicher/Organisatorischer Bedarf an Hochverfügbarkeit

In diesem Abschnitt sollen zum einen die wirtschaftlichen Konsequenzen eines (vorübergehenden) Verlusts der Datenbankverfügbarkeit betrachtet werden, zum anderen soll dargestellt werden, inwiefern die jeweilige Lösung mit unterschiedlich hohem Kostenaufwand verbunden ist, entsprechend den unterschiedlich hohen Unternehmensanforderungen. Leitend sind hierbei die drei Grundregeln des Risikomanagements nach Rosenkranz & Missler- Behr (2006, S. 277):

1 Don't risk more than you can afford to lose
2 Consider the odds
3 Don’t risk a lot for a little

Mit anderen Worten muß erkannt werden, ob ein (vorübergehender) Verlust der Datenbankverfügbarkeit unternehmensbedrohend ist (1), die gewählte Lösung muß vom Aufwand her den Anforderungen entsprechen (2), und es darf nicht an der falschen Stelle gespart werden (3). Hierzu eine prägnante Aussage:

60% of companies affected by a major disaster go out of business within two years.

(Hiatt 2000, S. 7)

Die Kosten, die der Ausfall der IT-Infrastruktur pro Stunde verursacht, wurden in verschiedenen Studien beziffert und sind naturgemäß insbesondere von der Unternehmensgröße und der IT-Affinität des Unternehmens abhängig. So reichen die genannten Werte von 50.000 Dollar pro Stunde (lt. Eagle Rock Alliance, 2001), bis zu über 800.000 Dollar pro Stunde (lt. Patterson, 2002)

Unabhängig von den konkreten Kosten der Ausfallzeit, die je Unternehmen variieren, bleibt festzuhalten, dass solche Ausfallzeiten mit (ev. extrem hohen) Kosten verbunden sind, die es zu minimieren gilt. Ausfallzeit kann wiederum unterschieden werden in geplante Ausfallzeit und ungeplante Ausfallzeit. Die folgende Übersicht stellt eine - unvollständige - Aufzählung typischer Ursachen von Ausfallzeit dar.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 Arten von Ausfallzeit und typische Ursachen (Eigene Darstellung)

In allen oben angeführten Fällen kann Oracle Data Guard eingesetzt werden, um die entstehende Ausfallzeit zu minimieren, wie nachfolgend noch näher ausgeführt werden wird.

Die für die Standby Datenbank aufgewandten Investitionskosten sowie die Kosten für den Betrieb - hauptsächlich die Personalkosten der Datenbankadministratoren, die allerdings nur einen geringen Arbeitsaufwand mit der Verwaltung von Data Guard haben werden (vgl. Ray 2005) - stehen dann den eingesparten Kosten, die die Ausfallzeiten ansonsten verursacht hätten, gegenüber. Vermutlich werden in vielen Fällen bereits die durch die Minimierung der geplanten Ausfallzeit eingesparten Kosten die Kosten für die hier diskutierte Hochverfügbarkeitslösung überwiegen.

Nun ist allerdings nicht allein die zeitliche Dauer der Nicht-Verfügbarkeit der IT-Infrastruktur bzw. der Datenbank von Bedeutung, sondern ebenso der Umfang des durch einen Schaden u.U. eingetretenen Datenverlustes. In der englischsprachigen Fachliteratur finden sich hierzu die beiden Metriken Recovery-Time-Objective (RTO) und Recovery-Point-Objective (RPO):

The RTO defines how quickly information systems, services and processes must be operational following some kind of incident, including recovery of applications and data and end-user access to those applications.

The RPO is the point in time that marks the end of the period during which data can still be recovered [...] It defines what is an acceptable loss of data.

(Claunch, 2004, S. 4)

Um die Metrik RPO mit zwei Beispielen aus den Extrema des vorhandenen Spektrums zu verdeutlichen: Eine Firma mit einer relativ wenig unternehmens­kritischen Datenbank wird u.U. nur wöchentlich eine Sicherung vornehmen und diese im Schadensfall wiederherstellen. Alle Änderungen am Datenbestand seit der Sicherung sind damit verloren (RPO maximal sieben Tage). Ein Unternehmen mit hochkritischer Datenbank wird eine „Zero-Data- Loss“-Lösung (s.u.) implementieren (RPO null Sekunden). Ebenso wie eine kurze Ausfallzeit bzw. ein kleines RTO ist ein kleines RPO tendenziell mit höheren Kosten verbunden. Das zweite Unternehmen hat also aufgrund seiner Anforderungen einen höheren Investitionsaufwand für seine Sicherungslösung als das erste.

Theoretisch sind RTO und RPO voneinander unabhängig - das erste Unternehmen kann ev. sehr schnell die Sicherung der letzten Woche verfügbar machen. Meist ist jedoch mit der Forderung nach einem minimalen RPO auch die Forderung nach einem sehr niedrigen RTO verbunden und umgekehrt. Das zweite Unternehmen will also im Schadensfall nicht nur keinen Datenverlust erleiden, sondern darüber hinaus auch schnell wieder auf diese Daten produktiv zugreifen können.

3 Technologische Grundlagen

Dieser Abschnitt soll technologische Konzepte erläutern, die Oracle Data Guard zugrunde liegen, um ein Verständnis eingesetzten Architektur und der später betrachteten verschiedenen Schutzmodi und Optionen zu ermöglichen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2 zeigt eine (grob vereinfachte) typische Data Guard Architektur: Die primäre Datenbank befindet sich an einem anderen Standort als die Standby Datenbank. Die beiden Standorte sind über ein Netzwerk (gestrichelte Linie) verbunden. Die Standby Datenbank ist als eine - ohne Ausfallzeit der primären Datenbank erzeugbare - Kopie der primären Datenbank entstanden. Nun muß sie bei nachfolgenden Änderungen der primären Datenbank jeweils aktualisiert werden. Träger der Änderungsinformation ist der Redo Stream, der über die Netzwerkverbindung von primärer Datenbank zur Standby Datenbank übertragen wird.

Grundsätzlich wird bei Oracle-Datenbanken (auch wenn keine Data Guard Konfiguration vorliegt) jede Transaktion bzw. Datenänderung durch Redo- Protokoll abgesichert:

Oracle Database writes every transaction synchronously to the redo log buffer, which is then written to the online redo logs.

(Ashdown & Kyte, 2009, S. 230)

Im Falle einer Beschädigung kann dieses Redo-Protokoll im Rahmen eines Recovery verwendet werden, um alle (mit dem SQL-Befehl commit) festgeschriebenen Transaktionen zurück zu gewinnen (vgl. Preston 2007, S. 451 ff.).

Die Erzeugung von Redo-Protokoll bewirkt also keinen zusätzlichen Aufwand für die primäre Datenbank, da es ohnehin bei jeder Datenänderung hervorgerufen wird.

Am Standby-Standort wird es zunächst in Standby Logs zwischengespeichert und dann für das Redo Apply verwendet, welches dieselbe Änderung, die auf der primären Datenbank das Redo-Protokoll hervorgerufen hat, nun auf der Standby Datenbank durchführt und sie so aktualisiert.

Hervorzuheben ist hierbei, dass das Redo-Protokoll ein im Verhältnis zu den veränderten Daten geringes Volumen hat, wodurch sich moderate Anforderungen an die Netzwerkverbindung ergeben. Dies ist bei alternativen Hochverfügbarkeitslösungen (s.u.) anders; sie stellen durchweg hohe An­forderungen (bzgl. Bandbreite und Latenz) an die Netzwerkverbindung.

Für die auf der Standby Seite eingesetzte Hardware ergeben sich keine außer­gewöhnlichen Anforderungen; insbesondere muß sie nicht mit der für die primäre Seite verwandten identisch sein. Allerdings sind ähnliche Kapazitäten empfehlenswert, da die Standby Seite im Schadensfall die produktive Last der primären Seite übernehmen soll.

Die jeweils pro Standort eingesetzte Betriebssystem-Plattform kann unterschiedlich sein. Derzeit ist eine solche sogenannte Heterogene Konfiguration für die Plattform-Kombination Windows-Linux unterstützt.

4 Wahl des angemessenen Schutzmodus

Es gibt bei Data Guard drei unterschiedliche Schutzmodi, die sich hinsichtlich der aufzuwendenden Kosten und des erzielbaren RPO unterscheiden. Es gilt nun also, die angemessene Balance zwischen Schutzanforderung und Investition zu finden. Die beiden wichtigsten vor Auswahl des Schutzmodus zu klärenden Fragen sind:

1. Kann im Schadensfall ein Datenverlust hingenommen werden?
2. Wie weit entfernt soll die Standby Datenbank vom primären Standort sein?

Die beiden Fragen sind nicht voneinander unabhängig zu beantworten:

Wird die erste mit „Nein“ beantwortet, sind der maximal möglichen Entfernung gewisse Grenzen (s.u.) gesetzt, die ev. dem Ziel, einen Schutz vor (Natur-)Katastrophen zu erreichen, entgegenstehen. Der unterschiedlich hohe Kostenaufwand, der mit den jeweiligen Schutzmodi verbunden ist, ergibt sich aus den jeweils unterschiedlich hohen Anforderungen an die Übertragung des Redo Streams:

Er kann synchron oder asynchron übertragen werden. Synchrone Übertragung bedeutet hier, dass eine Transaktion auf der primären Datenbank erst dann festgeschrieben wird, wenn das damit einhergehende Redo-Protokoll von der Standby Datenbank empfangen und in die Standby Logs geschrieben worden ist. Auf diese Weise kann im Schadensfall keine festgeschriebene Transaktion verloren gehen („Zero-Data-Loss“), da sich ja das zur Wiederherstellung der Transaktion erforderliche Redo-Protokoll bereits auf der Standby Seite befinden muss.

Diese Art der Übertragung kann allerdings das Festschreiben der Transaktion auf der primären Datenbank (und damit deren Performance) verlangsamen, insbesondere wenn die Netzwerkverbindung langsam ist und/oder sehr hohe Distanzen zu überbrücken sind.

Die Latenz der Netzwerkverbindung ist daher bei synchroner Übertragung von entscheidender Bedeutung, da eine hohe Latenz zu entsprechend langer Wartezeit auf die Empfangsbestätigung seitens der Standby Datenbank führt, bevor das Festschreiben der Transaktion auf der primären Seite erfolgen kann. Bei asynchroner Übertragung ist dies nicht der Fall, da ein Festschreiben der Transaktionen auf der primären Datenbank erfolgen kann, ohne zuvor auf die Bestätigung des Empfangs seitens der Standby Datenbank warten zu müssen.

4.1 Maximum Protection

Dies ist der höchste mit Oracle Data Guard erreichbare Schutzmodus, der einen Datenverlust auch dann ausschließt (RPO = 0), wenn mehrere Komponenten der eingesetzten Infrastruktur zugleich ausfallen. Er erfordert allerdings auch den Einsatz von zwei (oder mehr) Standby Datenbanken. Dieser Schutzmodus ist nur möglich mit synchroner Übertragung des Redo Streams. Bei einer Entfernung von ca. 300 km und einer damit einhergehenden Netzwerklatenz von ca. 20ms beeinträchtigt dies die Performance der primären Datenbank um ca. 10 Prozent (vgl. Carpenter et al, 2009, S. 39).

Den Zusammenhang zwischen Netzwerklatenz und Performance­Beeinträchtigung, bei einem - schon recht hohen - Redo-Aufkommen von 4 Megabyte pro Sekunde, stellt das nachfolgende Diagramm dar:

Abbildung in dieser Leseprobe nicht enthalten

Neben der mit steigender Entfernung steigenden Latenzzeit ist ein weiterer wichtiger (Kosten-)Faktor die Bandbreite der Netzwerkverbindung, wobei zur Ermittlung der angemessenen Netzwerkvariante zuvor das Redo-Volumen gemessen werden sollte, das durch das produktive Transaktionsaufkommen in der primären Datenbank entsteht (s. Carpenter et al. S. 43 ff.). Eine recht gute Beschreibung, wie das Redo-Aufkommen ermittelt werden kann, gibt Held (2005, S. 128 ff.). Sie weist außerdem darauf hin, dass bei der Mehrzahl von Oracle-Datenbanken Redo-Raten von 500KB/s nicht überschritten werden (ebd.).

In Schutzmodus Maximum Protection ist die Empfangsbestätigung einer Standby Datenbank vor dem Festschreiben der Transaktion in der primären Datenbank zwingend erforderlich - bleibt die Bestätigung aus, hält die primäre Datenbank an. Daher ist es nicht sinnvoll, diesen Schutzmodus mit nur einer

Standby Datenbank zu betreiben, denn dann würde der Ausfall einer Standby Datenbank die primäre Datenbank unbenutzbar machen.

Vielmehr sind hier mindestens zwei Standby Datenbanken, zu denen synchron übertragen werden muß, empfohlen. Selbst bei Ausfall von zwei Standorten bzw. Komponenten kann „Zero-Data-Loss“ bei diesem Schutzmodus garantiert werden.

4.2 Maximum Availability

Auch der zweithöchste Schutzmodus kann „Zero-Data-Loss“ ermöglichen - allerdings darf dann nur eine Komponente der zugrundeliegenden Infrastruktur ausfallen. Die Übertragung des Redo Streams geschieht auch hier synchron, wodurch sich die gleichen Gesichtspunkte bzgl. Netzwerkverbindung, Distanz und Performance-Beeinträchtigung der primären Datenbank wie bei Maximum Protection ergeben.

Im Unterschied zum höchsten Schutzmodus kann jedoch Maximum Availability ohne weiteres mit nur einer Standby Datenbank betrieben werden.

Sollte die Standby Datenbank ausfallen, oder sollte die Netzwerkverbindung von primärer Datenbank zur Standby Datenbank ausfallen, so kommt hier die primäre Datenbank nicht zum Stillstand. Vielmehr wird in diesem Fall das Redo-Protokoll solange auf der primären Datenbank zwischengespeichert, bis die Standby Datenbank wieder erreichbar ist. Dann wird diese mit dem zwischenzeitlich angefallenen Redo-Protokoll aktualisiert, und es wird wieder mit Empfangsbestätigung (synchron) übertragen.

Den geringeren Kosten (nur eine Standby Datenbank anstatt zwei) steht allerdings ein höheres Risiko gegenüber: Sollten zwei Komponenten ausfallen, kann Datenverlust nicht ausgeschlossen werden. So könnte z.B. zunächst die Netzwerkverbindung von primärer Datenbank zur Standby Datenbank ausfallen, woraufhin Redo-Protokoll auf der primären Seite zwischengespeichert wird. Sollte anschließend ein Katastrophe die primäre Datenbank zerstören, so hat man die mit diesem Redo-Protokoll verbundenen Transaktionen verloren.

[...]

Fin de l'extrait de 56 pages

Résumé des informations

Titre
Hochverfügbarkeit von Datenbanken aus wirtschaftlicher und technologischer Perspektive am Beispiel von Oracle Data Guard
Université
University of Hagen
Note
2.0
Auteur
Année
2010
Pages
56
N° de catalogue
V147240
ISBN (ebook)
9783640641277
ISBN (Livre)
9783640641390
Taille d'un fichier
1116 KB
Langue
allemand
Mots clés
Hochverfügbarkeit, Datenbanken, Oracle, Data Guard, RAC, Extended RAC, Real Application Clusters, Desaster Recovery, Disaster Recovery, High Availability
Citation du texte
Uwe Hesse (Auteur), 2010, Hochverfügbarkeit von Datenbanken aus wirtschaftlicher und technologischer Perspektive am Beispiel von Oracle Data Guard, Munich, GRIN Verlag, https://www.grin.com/document/147240

Commentaires

  • Pas encore de commentaires.
Lire l'ebook
Titre: Hochverfügbarkeit von Datenbanken aus wirtschaftlicher und technologischer Perspektive am Beispiel von Oracle Data Guard



Télécharger textes

Votre devoir / mémoire:

- Publication en tant qu'eBook et livre
- Honoraires élevés sur les ventes
- Pour vous complètement gratuit - avec ISBN
- Cela dure que 5 minutes
- Chaque œuvre trouve des lecteurs

Devenir un auteur