Über unsMediaKontaktImpressum
Andrea Held 06. Oktober 2015

Hochverfügbarkeit und Downtime: Eine Einführung

Der erste Teil dieser Artikelserie zeigt eine Begriffsbestimmung und eine Übersicht grundsätzlicher Anforderungen an die Fehlertoleranz von IT-Systemen. In den folgenden Teilen werden Ausfallursachen und -kategorien ebenso behandelt wie Metriken zur Berechnung von Kosten durch Ausfallzeiten sowie Grundlagen der Bedarfsanalyse und der Bestimmung einer Verfügbarkeitsstrategie.

Verfügbarkeit und Hochverfügbarkeit, Fehlertoleranz und SPOFs (Single Point of Failure) sind Begriffe, die im Umfeld hochverfügbarer Systeme eine grundlegende Rolle spielen. Doch wie sind diese definiert?

Verfügbarkeit und Hochverfügbarkeit

Es ist trivial: Ein Service wird als verfügbar bezeichnet, wenn er in der Lage ist, die Aufgaben zu erfüllen, für die er vorgesehen ist. Als Verfügbarkeit wird aber auch die Wahrscheinlichkeit bezeichnet, dass ein System innerhalb eines spezifizierten Zeitraums funktionstüchtig (verfügbar) ist. Die Verfügbarkeit wird als Verhältnis aus Downtime und Uptime eines Systems bemessen:

Verfügbarkeit = Uptime / (Downtime + Uptime)

Ein System gilt als hochverfügbar, wenn eine Anwendung auch im Fehlerfall weiterhin verfügbar ist und ohne unmittelbaren menschlichen Eingriff weiter genutzt werden kann. Anwender/innen sollte keine oder nur eine kurze Unterbrechung wahrnehmen. Hochverfügbarkeit (abgekürzt auch HA, abgeleitet von engl. High Availability) bezeichnet also die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten einen uneingeschränkten Betrieb zu gewährleisten.

Die Definition des Begriffes High Availability durch das Institute of Electrical and Electronics Engineers (IEEE) lautet:

“Availability of resources in a computer system, in the wake of component failures in the system.” [1]

Die Harvard Research Group (HRG) bezieht den Begriff Hochverfügbarkeit auf den prozentualen Wert der Verfügbarkeit. Sie unterteilt in Verfügbarkeitsklassen [2]. Nach dieser Klassifizierung wird ab einer Verfügbarkeit von mindestens 99,99 Prozent ein System als hochverfügbar bezeichnet.

Es ist naheliegend, dass die Erhöhung der Verfügbarkeit bis hin zur Hochverfügbarkeit durch die Verringerung von Downtimes realisiert wird. Hier unterscheidet man wiederum geplante von den ungeplanten Downtimes: Geplant sind beispielsweise Wartungsfenster für Hardware- und Software-Upgrades, ungeplante Downtimes dagegen resultieren meist aus Fehlern.

Hochverfügbare Architekturen

Hochverfügbare Architekturen verfügen meist über folgende Eigenschaften:

  • Toleranz und Transparenz gegenüber Fehlern
  • Präventive Build-In-Funktionalitäten
  • Proaktives Monitoring und schnelle Fehlererkennung
  • Schnelle Wiederherstellungsmöglichkeiten
  • Automatisierte Wiederherstellung ohne administrative Eingriffe
  • Kein oder geringer Datenverlust

Um geeignete Maßnahmen treffen zu können, sollte man vorab mögliche Systemausfälle und deren Gründe kategorisieren. Denn: Je nach Typ sind unter Umständen grundlegend andere Verfahren zur Vermeidung eines Ausfalls geeignet.

Fehlertolerante Systeme

Fehlertolerante Systeme müssen auf nahezu alle erdenklichen Fehlerursachen reagieren können. Erreicht wird dies durch den Einsatz intelligenter Software in Kombination mit einer Eliminierung von Single Points of Failure (SPOF). Ein SPOF ist eine Komponente, die im System nur einmal vorhanden und für die korrekte, sichere und zuverlässige Funktionsfähigkeit des Gesamtsystems zwingend erforderlich ist. Nicht nur Speicher- und Rechnerkomponenten, auch das Design des Netzwerkes und der Speichertechnik können einen SPOF darstellen: Oft ist der Backend-Server zwar durch einen Cluster aus miteinander vernetzten Rechnerknoten abgesichert, so dass bei einem Ausfall eines Rechners ein anderer dessen Aufgabe übernehmen kann. Allerdings hängen die Clusterknoten manchmal am selben Netzwerkswitch. Fällt dieser aus, nützt auch der Cluster als Schutzmaßnahme nichts: Der Service ist nicht verfügbar.

Redundanz ist hier die Lösung: Korrekt konfigurierte redundante - also mehrfach ausgelegte - Komponenten stellen sicher, dass bei einem Ausfall einer einzelnen Komponente andere des gleichen Typs die Aufgaben übernehmen können. Jede Hardwarekomponente in einem Computersystem - wie beispielsweise Storage-Adapter, Netzwerkkarten, interner Festspeicher oder auch das Netzteil des Rechners - sollte deshalb mindestens zweimal vorhanden sein. Doch kann der Rechner als Ganzes ausfallen. Bei erhöhten Verfügbarkeitsanforderungen muss daher auch die gesamte Rechnerhardware redundant – z. B. in Form eines Standby Systems – gehalten werden. Fällt ein Rechner aus, übernimmt der andere.

Redundant ausgelegte Rechnersysteme nutzen jedoch wenig, wenn eine andere Komponente einen SPOF bildet. So ist die Stromversorgung ein wichtiger Punkt, der gerne vergessen wird. Das Datacenter von IXEurope zum Beispiel verfügte im Jahr 2004 über mehrfach redundante Anbindungen von bis zu einem Dutzend unabhängigen Carrier und gewährleistete damit eine 99,999-prozentige Stromversorgung. Im Falle eines partiellen Netzausfalles kann der Kunde in solchen Konfigurationen innerhalb kurzer Zeit auf einen alternativen Carrier umgeschaltet werden.

Hardware Fehlertoleranz

Fehlertoleranz kann durch Hardware unterstützt werden. Ein gutes Beispiel ist die Fehlertoleranz eines RAID 1 Storage. Hier werden Daten über Plattenspiegelung redundant, also "mehrfach" auf physisch unterschiedlichen Platten gespeichert. Fällt eine Festplatte aus, so hat dies zunächst keinen Einfluss auf die Verfügbarkeit des Gesamtsystems. Der Festplattenspiegel fängt diesen Fehler auf. Der Ausfall bleibt für den Benutzer in der Regel transparent, er wird für ihn also nicht sichtbar.

Software Fehlertoleranz

Software Fehlertoleranz wird häufig mit den bereits genannten Methoden der Hardware-Redundanz kombiniert. Damit eine Anwendung auch nach einem Failover korrekt weiterverarbeiten kann, muss diese in der Regel auf eine Fehlersituation reagieren können. So entsteht bei einem Failover in einem Cluster ein zumindest vorübergehender Verbindungsverlust. In der Regel geht dies mit einem Verlust offener Transaktionen einher. Eine Anwendung muss also in der Lage sein, dies zu erkennen und gegebenenfalls zurückgerollte Verarbeitungsschritte nach einem Wechsel der Verbindung auf dem Ersatzsystem nachzuholen.

Hybride Verfahren

Im Rahmen von Clustersystemen, bei denen ein ganzes Rechnersystem redundant vorgehalten wird, wird Fehlertoleranz in einer Kombination aus Hardware und intelligenter Software bereitgestellt. Hier wird zum einen die hardwareseitige, redundante Auslegung eines Gesamtsystems genutzt, andererseits spielen aber auch Softwarekomponenten eine herausragende Rolle. So ist die Clustersoftware für die Erkennung eines Systemausfalls, die nachfolgende Fehlerbehandlung und erneute Bereitstellung der Dienste verantwortlich. Durch eine automatische Wiederherstellung der Betriebsfähigkeit eines Systems wird hier die Systemverfügbarkeit ohne menschlichen Eingriff wiederhergestellt. Idealerweise sollten hierbei kein Daten- oder Verbindungsverluste entstehen.

Anwendungsarchitekturen und Verfügbarkeit

Die "Nicht-Verfügbarkeit" einer Anwendung für den Benutzer wird als Systemausfall bezeichnet. Ursachen können in jedem an einer Anwendung beteiligten Layer liegen. Dazu zählen die Datenhaltung (Storage, Datenmanagementserver), die Kommunikation zwischen den Komponenten (IPC, RPC, Netzwerk), die Applikationsserver und so weiter.

Im Drei-Schichten-Modell beispielsweise gibt es Client-komponenten, Anwendungslogik und Datenressourcen. Dreischichtige Architekturen ermöglichen Programmiermodelle, die die Verteilung von Anwendungsfunktionalitäten über drei unabhängige Schichten ermöglichen:

  • Layer 1: Clientkomponenten auf lokalen Workstations
  • Layer 2: Applikationslogik
  • Layer 3: Eine eigenständige Sammlung von Datenbanken, Ressourcenmanagern und Mainframe-Anwendungen

Sie werden unter Umständen nicht auf demselben physischen Server ausgeführt.

Alle drei Schichten müssen miteinander kommunizieren können. Offene Protokolle und APIs vereinfachen die Kommunikation. Clientkomponenten können in diversen Programmiersprachen geschrieben werden. Die Kommunikation der Clients mit der Anwendungslogik im Middle Tier ist zudem unabhängig vom Betriebssystem. Das Design der Datenbanken in der dritten Schicht ist beliebig, sofern die Anwendungsschicht sie abfragen und ändern kann. Der Schlüssel zu dieser Architektur ist die Schicht der Anwendungslogik.

Mehrschichtigkeit bietet viele Vorteile, erhöht aber die Komplexität. Steht eine der in einem Layer angebotenen Funktionalitäten nicht zur Verfügung, so ist das Gesamtsystem für den Anwender nicht verfügbar. Gleich welches Architekturmodell gewählt wurde: Zur Sicherung der Verfügbarkeit gilt es, alle Schichten innerhalb der Architektur näher zu betrachten.

Für Datenbanken beispielsweise bieten sich je nach Anforderung verschiedene Schutzmaßnahmen an: Aktiv-Passiv-Cluster, eine Aktiv-Aktiv-Cluster oder auch eine Standby-Datenbank sowie Replikation auf Speicherebene sind nur einige Optionen. Einzelne Technologien fangen meist nur bestimmte Ausfallursachen ab. Ist man auf ein sehr hohes Maß an Verfügbarkeit angewiesen, können mehrere, komplementäre Technologien so miteinander kombiniert werden, dass sehr unterschiedliche Ausfallszenarien abgefangen werden können. Um eine geeignete Verfügbarkeitsstrategie wählen zu können, müssen potenzielle Downtime-Ursachen kategorisiert und entsprechenden Auffangtechniken gegenübergestellt werden.

Downtime: Ursachen und Kategorien

Eine geplante Downtime ist ein Zeitraum, in dem das System aufgrund geplanter Tätigkeiten nicht verfügbar ist. Geplante Tätigkeiten sind z. B. Wartungsarbeiten, Ausbau der Hardware oder auch das Einspielen von Software Upgrades und Patches. Gelegentliche Failover Tests zum Überprüfen der Übernahme im Fehlerfall fallen ebenso darunter wie die Aktualisierung von Applikationen.

Als ungeplante Downtime wird eine Zeitspanne bezeichnet, in der das System aufgrund ungeplanter Ereignisse nicht verfügbar ist. Die Ursache kann in einem Ausfall von Hardware (Festspeicher, Adapter, Netzteil, Netzwerkkomponenten usw.), fehlerhafter Software (unbehandelte Fehler/Ausnahmen) Datenkorruptionen oder auch Bedienerfehlern (Stammdaten gelöscht, Not-Aus-Schalter gedrückt) liegen. Die Anlässe für ungeplante Ausfälle sind ebenso vielfältig wie die Komponenten – gleich ob technischer oder menschlicher Natur – die an einem solchen System zusammenwirken.

Hochverfügbarkeit erfordert auf jeden Fall Vermeidung und Begrenzung ungeplanter Ausfallzeiten. Ungeplante Ausfallzeiten können durch Vorsorge wenn auch nicht vermieden, so doch zumindest erheblich reduziert werden:

  • Defekte Hardware: Einsatz redundanter Hardware
  • Fehlerhafte Software: Verwendung aktueller Patches
  • Bedienungsfehler: Aktuelles und intaktes Backup, besser noch Standby System mit Delay in der Replikation
  • Stromausfälle: Große Rechenzentren verfügen über mindestens zwei Strom-Lieferanten, getrennte Stromnetze (redundante Lieferanten nutzen schließlich nichts, wenn der Bagger ein Kabel durchtrennt) sowie eine unterbechungsfreie Stromversorgung
  • Netzwerkprobleme: Redundante Auslegung der Netzwerkkomponenten
  • Katastrophen / Desaster (Überflutung, Erdbeben, Bombenanschläge): Verwendung von Ausweichrechenzentren, Geo-Cluster, Geo-Spiegelung, Replikation

Zusätzlich gilt, dass geplante Ausfallzeiten vermieden oder zumindest begrenzt werden. Wartungsarbeiten und Upgrades sind jedoch unter bestimmten Umständen zwingend notwendig. Den erforderlichen Zeitraum kann man nur schwer verringern. Jedoch kann man auf Ausweichszenarien zurückgreifen. Nur ein paar Beispiele:

  • Hardware Upgrades: Verwendung von Hot Plug Hardware
  • Software Upgrades: Rolling Upgrades über mehrere Clusterknoten hinweg
  • Wartungsarbeiten: Switchover auf einen anderen Knoten im Cluster

Es handelt sich bei den oben genannten Maßnahmen nur um Beispiele. Tatsächlich ist die Fülle möglicher Vorkehrungen enorm. Die Kosten variieren stark.

Um eine geeignete Strategie wählen zu können, müssen Ausfallwahrscheinlichkeiten der einzelnen Downtimekategorien sowie Kosten für die Ausfallzeiten den Aufwänden zur Realisierung der Verfügbarkeitstrategie gegenübergestellt werden. In den nächsten Abschnitten geht es deshalb um Kennzahlen zur Systemverfügbarkeit sowie die Kostenseite der Nicht-Verfügbarkeit eines Systems.

Quellen
  1. Institute of Electrical and Electronics Engineers (IEEE): High Availability
  2. Harvard Research Group (HRG): High Availability

Dies ist der erste Teil einer Artikelserie zu Hochverfügbarkeit und Downtime. Der nächste Artikel befasst sich mit Metriken

Autorin

Andrea Held

Andrea Held ist technische Architektin und Autorin von Fachartikeln und Büchern, darunter "Der Oracle DBA", "Oracle New Features" und "Oracle Hochverfügbarkeit". Ihr Schwerpunkt: Hochverfügbare Datenbanksysteme.
>> Weiterlesen
Bücher der Autorin:

botMessage_toctoc_comments_9210