Suche
Close this search box.

Was ist Hochverfügbarkeit und High Availability?

Lesen Sie in diesem Artikel:

Definition der Hochverfügbarkeit

Hochverfügbarkeit (engl. High Availability) umfasst ein Set an Technologien, Verfahren und Entwurfsprinzipien, die das Ziel der Business Continuity unterstützen. Für Systeme oder Services bedeutet das Ziel der Hochverfügbarkeit eine definierte, maximal tolerierte Ausfallzeit im Allgemeinen von 0,01%. Anders ausgedrückt: 99,99% Verfügbarkeit gelten z.B. lauf BSI als hochverfügbar.

Optimalerweise sind Systeme und Services zu 100% verfügbar, also während der vereinbarten Betriebszeit jederzeit zugreifbar. Dies ist jedoch selten realistisch und nur mit enorm hohem Aufwand abbildbar. Aus diesem Grund akzeptieren Unternehmen in vielen Bereichen definierte, maximale Ausfallszeiten, um die Kosten für Services in realistischen Bereichen zu halten.

Im betrieblichen Umfeld werden Verfügbarkeitsanforderungen häufig in Form von Service Level Agreements vereinbart. Dabei wird üblicherweise die Betriebszeit als Basis definiert (z.B. 7×24, also rund um die Uhr, oder Mo-Fr. Werktags von 08:00 bis 16:00 Uhr, also 5×8), wobei geplante Downtimes (z.B. Wartungsfenster) davon ausgenommen sind. Zusätzlich zur Betriebszeit ist der Mindestprozentanteil der Zeit definiert, den das System oder der Service mindestens zugreifbar sein soll (Uptime), z.B. eben diese 99,99% als Hochverfügbarkeit.

Mit solchen Vorgaben soll sichergestellt werden, dass alle für den Geschäftsbetrieb notwendigen Komponenten mit ausreichend großer Wahrscheinlichkeit zur Geschäftszeit genutzt werden können.

Verfügbarkeitsklassen

In der Praxis haben sich neben prozentualen Vorgaben bzw. Messungen vor allem die Verfügbarkeitsklassen der Harvard Research Group durchgesetzt, die Availability Environment Classification (AEC)

AEC-Klasse
Erklärung
AEC-0 / Conventional
Service kann unterbrochen werden, Datenintegrität nicht essenziell
z.B.: Systeme, die keine produktiven Daten speichern, unkritisch für den Geschäftsbetrieb sind. In vielen SAP-Umgebungen z.B. Sandbox-Systeme
AEC-1 / Highly Reliable
Service kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein Service kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein
z.B. Systeme, die nicht in produktiven Prozessen involviert sind, aber deren Funktion indirekt/mittelfristig Auswirkung auf diese haben kann. Im SAP-Umfeld häufig die regulären Entwicklungs- und QA-Systeme, da in diesen abhängige Datenstrukturen und Testfälle abgebildet sind, oder BW/BI-Systeme.
AEC-2 / High Availability
Service darf während vereinbarter Zeiten oder zur Hauptbetriebszeit lediglich minimal unterbrochen werden
z.B. Systeme, die während der Produktivzeiten eines Geschäftsprozesses kritisch sind. In SAP-Umgebungen sind dies häufig die Produktivsysteme
AEC-3 / Fault Resilient
Service muss während vereinbarter Zeiten oder während der Hauptbetriebszeit ununterbrochen aufrechterhalten werden
z.B. Systeme, deren Prozesse und Daten absolut kritisch für den Geschäftsprozess sind. In SAP-Umgebungen sind dies beispielsweise häufig die Systeme im Umfeld der Lagerverwaltung, vor allem für chaotische Lager, da ein Ausfall hier oft zu einer Vollinventur führen würde
AEC-4 / Fault Tolerant
Service muss ununterbrochen aufrechterhalten werden, 24/7-Betrieb (24 Stunden, 7 Tage die Woche) muss gewährleistet sein Wie oben, aber ohne Einschränkung der Betriebszeit. Dies umfasst häufig Systeme für Online-Services, bei denen Kunden schnell auf Alternativen umsteigen können, oder KRITIS-Umgebungen.
AEC-5 / Disaster Tolerant
Service muss unter allen Umständen verfügbar sein Systeme, bei denen es dauerhaft um Leib und Leben geht, häufig im KRITIS-Umfeld
z.B. in Kernkraftwerkumgebungen u.ä..

Tabelle 1: Verfügbarkeitsklassen nach AEC

Quelle: Harvard Research Group, https://hrgresearch.com/High%20Availability.html

Daneben gibt es weitere Klasseneinteilungen, wie die in Deutschland gängigen Verfügbarkeitsklassen des BSI:

Verfügbarkeitsklassen nach BSI

Abbildung 1: Verfügbarkeitsklassen nach BSI

Quelle: Bundesamt für Sicherheit in der Informaionstechnologie, HV-Kompendium, Band G, Kapitel 2: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Hochverfuegbarkeit/BandG/G2_Definitionen.html

Berechnung der Hochverfügbarkeit

Verfügbarkeit wird üblicherweise in Prozent angegeben. Generell berechnet sich die Verfügbarkeit – und somit auch die Hochverfügbarkeit – indem die unterbrechungsfreie Leistungszeit eines Service durch die gesamte (vereinbarte) Betriebszeit geteilt wird.

Nicht zur Leistungszeit zählen dabei reguläre Wartungsfenster, die als geplante Downtimes in SLAs ebenfalls explizit geregelt werden.

100% Verfügbarkeit bedeutet ununterbrochener Betrieb während der vereinbarten Leistungszeit. Bei einem 7×24-Betrieb bedeuten die typischen “9er-Angaben” die folgenden maximalen Ausfallzeiten:

  • 99 % ≡ 438 Minuten/Monat, also 7:18:18 Stunden/Monat = 87,7 Stunden/Jahr, d. h. 3 Tage und 15:39:36 h
  • 99,9 % ≡ 43:48 Minuten/Monat, also 8:45:58 Stunden/Jahr
  • 99,99 % ≡ 4:23 Minuten/Monat, also 52:36 Minuten/Jahr
  • 99,999 % ≡ 26,3 Sekunden/Monat, also 5:16 Minuten/Jahr
  • 99,9999 % ≡ 2,63 Sekunden/Monat, also 31,6 Sekunden/Jahr

 

99,9% Verfügbarkeit für ein einzelnes System herzustellen ist eine Herausforderung. Die gleiche Verfügbarkeit für einen Prozess mit z.B. drei Komponenten macht die Aufgabe jedoch ungleich größer: Verfügbarkeitsanforderungen multiplizieren sich.

So haben drei Komponenten mit jeweils 99,9% Verfügbarkeit eine Gesamtverfügbarkeit von lediglich 99,9% x 99,9% x 99,9% = 99,7%. Anstatt neun Stunden pro Jahr ist dies bereits deutlich über einen Tag. Hat eine der Komponenten eine Verfügbarkeit von nur 99%, erhöht sich die maximale Ausfallzeit bei 98,8% Verfügbarkeit sogar auf knapp viereinhalb Tage.

Somit muss bei komplexen Services die Einzelverfügbarkeit jeder kritischen Komponente beachtet und entsprechend hoch angesetzt werden.

Anwendungsbereiche der Hochverfügbarkeit

Je höher die vorgegebene Verfügbarkeit, desto mehr Aufwand und Kosten stecken in der aufzubauenden Infrastruktur. Das rechnet sich vor allem in solchen Branchen und Anwendungsfällen, in denen

  • Ausfallzeiten hohe finanzielle Kosten nach sich ziehen (z.B. im Börsenhandel bzw. in der Finanzbranche allgemein, oder aber im Anwendungsfall chaotisch organisierter Großlager),
  • Leib und Leben von der Verfügbarkeit der Infrastruktur abhängen (z.B. im Healthcare- oder auch im Flughafenumfeld) oder
  • großflächige Folgen bei Ausfällen zu erwarten sind (typischerweise in den KRITIS-Umgebungen, oder bei Anbietern für große Infrastrukturumgebungen, z.B.im Cloudbereich, in Elektrizitätswerken).

 

Neben Umgebungen, in denen generelle Hochverfügbarkeit gefordert wird, gibt es auch Einsatzfelder, bei denen zeitpunktbezogen spezifische Anforderungen definiert sind. Dies gilt beispielweise für Berichtssysteme, die vielleicht nur quartalsweise ihren großen Auftritt haben, dann aber innerhalb eines bestimmten Zeitfensters verfügbar sein müssen. Andernfalls mit Strafen oder, noch schlimmer, schlechter Presse zu rechnen ist. Auch hier gilt es abzuwägen, wie welche Anforderungen konkret abgedeckt werden.

Hochverfügbarkeit SAP Hana

Besonderer Fall ist der Einsatz der HANA-Datenbanken im SAP-Umfeld. Bei Hochverfügbarkeitsanforderungen an S/4, BW/4 HANA o.ä. funktionieren viele klassische Methoden nur bedingt: Als In Memory-Datenbank schreibt die HANA-DB nicht alle Daten sofort auf physikalische Speichermedien, sondern hält sie lediglich im Arbeitsspeicher, ist also per se flüchtig. Deswegen bietet die HANA-Datenbanktechnologie eigene Mechanismen in Form einer synchronen Spiegelung mit der HANA System Replication an, ergänzt durch Cluster-Technologien der darunter liegenden Linux-Distributionen.

Kosten der Hochverfügbarkeit

Kosten der Hochverfügbarkeit steigen mit den Anforderungen. Die maximal tolerierten Ausfallzeiten, aber auch die Komplexität der Services spielen dabei eine zentrale Rolle.

Um Kosten zu reduzieren, bleiben nur wenige Möglichkeiten:

  • Verfügbarkeitsanforderungen prüfen und ggf. Reduzieren – ggf. Auf Kosten der Servicequalität, wenn erlaubte Ausfallzeiten tatsächlich ausgenutzt werden (müssen)
  • Geschäftsprozesse und Services vereinfachen, um die Anzahl der beteiligten kritischen Komponenten und somit der Verfügbarkeitsfaktoren zu reduzieren
  • Kosteneffizientere Technologien einsetzen
  • Kosteneffizientere Komponenten einsetzen
  • Kosteneffizientere Verträge für externe Dienstleister abschließen

Umsetzung der Hochverfügbarkeit

Die technische Umsetzung einer Hochverfügbarkeitsumgebung hat in vielen Fällen etwas mit der Redundanz (also Doppelung) kritischer Systemkomponenten zu tun, um Single Points of Failure (SPOF) zu vermeiden, deren Ausfall zum Ausfall des Gesamtservices führen würde.

Hier sind im on-premises Betrieb – also bei eigenbetriebenen Umgebungen – vor allem zu nennen:

  • Ausfallrechenzentren zur Doppelung der Systemstandorte bei großflächigen Vorkommnissen (Desastern)
  • Clustertechnologien zur Doppelung von Servern bei Hardware-, Software- oder Netzwerkproblemen
  • SAN- oder RAID-Technologien zur Doppelung von Storagekomponenten bei Hardwareproblemen
  • USV (unterbrechungsfreie Stromversorgung) zur Doppelung der Stromversorgung
  • Redundante Netzzugangspunkte zur Doppelung der Internetverbindung

 

Neben redundanten Komponenten gibt es auch noch die Klasse der ausfallsicheren Systeme, die in sich so strukturiert sind, dass sie 100%-Verfügbarkeit garantieren, aber dementsprechende Kosten mit sich bringen.

Bei Einsatz von Cloud-Strukturen bieten alle Hypervisor Technologien unterschiedlicher Verfügbarkeitsklassen an, mitsamt lokaler und/oder globaler Redundanzen.

Ebenso haben sich hybride Verfügbarkeitsszenarien im Markt etabliert, in denen Unternehmen beispielsweise on-premises- durch Cloud-Umgebungen absichern.

Zentrale Herausforderung für den technischen Aufbau hochverfügbarer Services ist jedoch deren Planung auf Basis der tatsächlichen Anforderungen. Hierfür gilt es die realen Prozesse und deren Anforderungen zu analysieren und daraus Vorgaben für die Einzelkomponenten einer Prozesskette abzuleiten. Dies hat sowohl technische wie auch wirtschaftliche Dimensionen – vor dem Hintergrund der Bepreisung eigener, marktkonformer Serviceangebote lautet das Motto üblicherweise “So viel wie nötig, so wenig wie möglich”.

In der Praxis existieren jedoch oftmals Service Level Agreements, die den tatsächlichen Anforderungen der High Availability nicht gerecht werden:

  • unnötig hohe Vorgaben, was entsprechendes Kostenpotenzial in sich trägt,
  • nicht ausreichende Verfügbarkeitsanforderungen für kritische Komponenten – was ein (zu) hohes Gesamtrisiko für den eigenen Service bedeutet.  
  • nicht definierte, “gefühlte” Service Level Anforderungen, die beliebig in beiden Dimensionen ausschlagen können.

 

Hier kommen oftmals externe Berater ins Spiel, die Prozesse sowohl technisch wie auch organisatorisch analysieren und mit Expertise beraten. Solche Anbieter und Dienstleister gewährleisten in der Regel eine objektive Unterstützung .Die Berater aus dem Hause Firnkorn und Stortz können Sie bei Einführung und Betrieb der Hochverfügbarkeit mit Fachwissen, Know-how und viel Praxiserfahrung unterstützen. Damit Sie Hochverfügbarkeit auch nur dort bezahlen, wo sie diese tatsächlich benötigen.

Ihr Ansprechpartner bei Firnkorn & Stortz zum Thema Hochverfügbarkeit

Treten Sie mit uns in Kontakt

Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.

Mehr Informationen

Stellen Sie uns Ihre Fragen!