Zu Abschnitt

Was ist Hochverfügbarkeit?

URL kopieren

Unter Hochverfügbarkeit versteht man die Fähigkeit eines IT-Systems, zu fast 100 % verfügbar und zuverlässig zur Verfügung zu stehen, wodurch Ausfallzeiten vermieden oder minimiert werden. Dabei werden zwei Konzepte kombiniert, um festzustellen, ob ein IT-System sein operatives Performance-Niveau erreicht: dass ein bestimmter Service oder Server fast 100 % der Zeit ohne Ausfallzeiten zugänglich – oder verfügbar – ist, und dass der Service oder Server über einen festgelegten Zeitraum die angemessenen Erwartungen erfüllt. Hochverfügbarkeit ist mehr als die Einhaltung eines Uptime SLAs (Service Level Agreements) oder der zwischen einem Serviceanbieter und einem Kunden festgelegten Erwartungen. Es geht um wirklich resiliente, zuverlässige und gut funktionierende Systeme.

 

Eine Hochverfügbarkeitsinfrastruktur hängt von der Erkennung und Beseitigung von Single Points of Failure ab, die zu längeren Ausfallzeiten des Systems führen und Unternehmen daran hindern könnten, ihre Performance-Ziele zu erreichen. Ein Single Point of Failure ist ein Aspekt der Infrastruktur, der das gesamte System außer Betrieb setzen kann. In komplexen Systemen können auch mehrere Single Points of Failure vorkommen.

Die Unternehmen müssen auch verschiedene Formen von Ausfällen berücksichtigen, die in einer modernen, komplexen IT-Infrastruktur auftreten können. Dazu gehören Hardwarefehler, Softwarefehler (sowohl für das Betriebssystem als auch für die aktiven Anwendungen), Servicefehler (wie unzugängliche Netzwerke und Latenzzeiten oder Cloud-Services oder eine Verschlechterung der Performance) und externe Fehler, beispielsweise Stromausfälle.

Der erste Schritt, den Unternehmen im Hinblick auf Hochverfügbarkeit machen können, besteht in der Bestimmung der spezifischen, wichtigsten Ergebnisse, die sie auf der Basis ihrer zentralen Services, Anforderungen hinsichtlich Workload sowie gesetzlichen oder Compliance-Auflagen, Performance-Benchmarks, kritischen Anwendungen und operativen Prioritäten erreichen möchten:

 

  • Wie hoch sind die Anforderungen an die Verfügbarkeit, sei es in Bezug auf die Compliance oder das Benutzererlebnis?
  • Wie stark ist die Umgebung verteilt? Was sind die zentralen Points of Failure?
  • Wie sieht die erforderliche Performance für die Anwendung aus? Welche Risiken bestehen für die Performance dieser App (beispielsweise hoher Benutzerverkehr oder hohe Write Loads)?
  • Welche Storage-Formate sind im Einsatz?
  • Welche Anforderungen gibt es in Bezug auf Datenverlust oder Datenzugriff?
  • Welche SLAs sind bei den derzeitigen IT-Ressourcen im Falle eines Ausfalls realisierbar? Wie sehen die aktuellen Wartungspläne aus, und wie wirkt sich das auf die Verfügbarkeit aus?
  • Gibt es Pläne für verschiedene Disaster Recovery-Szenarien oder Änderungen im Geschäftsablauf?

Bei Hochverfügbarkeitsumgebungen gibt es außerdem mehrere gängige Metriken, mit denen IT-Teams feststellen können, ob die Hochverfügbarkeitsarchitektur ihre Ziele erreicht. Einige sind möglicherweise für Ihre Architektur relevanter als andere, aber es lohnt sich, sie zu evaluieren, um die grundlegenden Performance-Erwartungen festzulegen:

  • Mean Time Between Failures (MTBF): Mittlere Betriebszeit der Umgebung zwischen Systemausfällen.
  • Mean Down Time (MDT): Mittlere Störungsdauer, d. h. wie lange das System ausfällt, bevor es wiederhergestellt oder in der Topologie ersetzt wird.
  • Recovery Time Objective (RTO): Die erforderliche Gesamtzeit, um eine Instandsetzung abzuschließen und ein System wieder online zu bringen.
  • Recovery Point Objective (RPO): Der Zeitraum, in dem Sie in der Lage sein müssen, Daten wiederherzustellen. Das ist das Zeitfenster für verlorene Daten. Wenn ein System beispielsweise auf Backups eines anderen Systems basiert, und diese Backups täglich erstellt werden, dann kann der Datenverlust im wiederhergestellten System bis zu 24 Stunden betragen. Bei repliziertem oder gemeinsam genutztem Storage kann der Datenverlust jedoch nur Minuten oder sogar weniger betragen.

Eine Hochverfügbarkeitsarchitektur umfasst Prinzipien aus sämtlichen Schichten der Kontinuitätsplanung, wie etwa Überwachung und Automatisierung. Dies ermöglicht eine Resilienz des Gesamtsystems gegenüber verschiedensten möglichen Ausfällen, von spezifischen lokalen Ausfällen bis hin zu einem Gesamtausfall. Sie ermöglicht es sogar, dass das Gesamtsystem auch bei geplanten Wartungsfenstern und anderen Serviceunterbrechungen funktionsfähig bleibt.

Ein Plan für Disaster Recovery oder Kontinuität beinhaltet Ansätze für die verschiedenen möglichen Ausfälle:

  • Erwartung spezifischer Ausfälle: Für diese Bereiche stellen die IT Architects zunächst jeweils sicher, dass die Systeme redundant sind und dass im Falle eines Ausfalls Backup-Systeme zur Verfügung stehen. Der nächste Schritt ist die Automatisierung von Prozessen für Failover und Fehlererkennung, sodass ausgefallene Systeme automatisch erkannt und ein Switchover der Services auf das Backup-System erfolgt.
  • Proaktives Management der Performance: Fehlertoleranz kann einen Ausfall adressieren, aber nicht unbedingt eine Verschlechterung der Performance handhaben. Hier werden Load Balancing und Skalierbarkeit zu nützlichen Tools. In diesem Fall überwachen die IT Architects die Performance des Systems und nutzen mehrere Systeme, um Benutzeranfragen und -vorgänge zu verwalten. Load Balancing und Traffic Management können den Datenverkehr in Echtzeit auf der Basis von Bandbreite und System-Performance, des Benutzertyps oder des Typs der Anfrage intelligent weiterleiten.
  • Umgang mit Katastrophen: Großflächige Infrastrukturausfälle – wie der Ausfall eines Cloud-Anbieters oder eine Naturkatastrophe am Standort eines Rechenzentrums – sind zwar selten, erfordern aber einen umfassenderen Ansatz als Hardware-/Softwareausfälle. Neben der Wiederherstellung der Infrastruktur ist es notwendig, dass aktuelle Daten zur Verfügung stehen. Dies kann synchron durch Replikation (allerdings mit Performance-Risiken) oder asynchron durch Daten-Backups (mit einem gewissen Risiko des Datenverlusts) erfolgen.

Hochverfügbarkeitsarchitekturen betreiben aktive Failover-Cluster, sodass Redundanz und Failover eingebaut sind und es hoffentlich keine Ausfallzeiten gibt. Innerhalb des Clusters werden die Nodes nicht nur auf ihre Verfügbarkeit, sondern auch auf ihre gesamte Performance von Anwendungen, Services und Netzwerk überwacht. Da es sich um gemeinsam genutzten Storage handelt, kommt es beim Ausfall eines Nodes nicht zu Datenverlusten, da sämtliche Clusterknoten mit der gleichen Datenquelle arbeiten. Mithilfe von Load Balancing lässt sich der Datenverkehr für eine optimale Performance verwalten.

Abgesehen von diesen allgemeinen Merkmalen können Hochverfügbarkeitscluster je nach den Prioritäten und Aktivitäten innerhalb der IT-Infrastruktur für speziellere Aktivitäten konzipiert werden. Das Red Hat Enterprise Linux High Availability Add-On verfügt beispielsweise über 4 Standardkonfigurationen:

  • Hochverfügbarkeit: Fokus auf Verfügbarkeit
  • Hohe Performance: für hohe Geschwindigkeit, gleichzeitige Abläufe 
  • Load Balancing: für kostengünstige Skalierbarkeit
  • Storage: für resilientes Datenmanagement

In realen Umgebungen enthalten die Hochverfügbarkeitssysteme Aspekte aus diesen Schwerpunktelementen.

Hochverfügbarkeit erstreckt sich über die gesamte Infrastruktur und berücksichtigt Daten- und Storage-Management in separaten Umgebungen – sowohl in der Cloud als auch physisch – sowie verschiedene Standorte für Services und Anwendungen. Daher sind eine gemeinsame Plattform und eine standardisierte Betriebsumgebung so wirkungsvoll: Sie schaffen Konsistenz unabhängig von der Bereitstellungsumgebung.

Red Hat Enterprise Linux verfügt über zusätzliche Funktionen und Services, die über Add-On-Pakete integriert werden können. Das Red Hat Enterprise Linux High Availability Add-On adressiert die Aspekte von Netzwerk, Clustering und Storage der Topologie.

Da Hochverfügbarkeit sehr eng mit Datenmanagement verbunden ist, enthalten die Deployments von Red Hat Enterprise Linux für Microsoft SQL Server und SAP auch das Red Hat Enterprise Linux High Availability Add-On.