Der Mythos der vielen Neunen und die Anwendungsrealität

Wie viel Hochverfügbarkeit braucht es wofür?

| Autor / Redakteur: Kevin Dominik Korte / Ludger Schmitz

Neunen sind die magischen Zahlen in Sachen Ausfallsicherheit
Neunen sind die magischen Zahlen in Sachen Ausfallsicherheit (Bild: Harald Lapp / www.pixelio.de)

Ausfallsicherheit heißt mehr als viele Neunen; es sind mehr Faktoren relevant. Im technischen Detail sind einzelne, spezielle Services für die permanente Leistung der IT relevant, hier erläutert am Beispiel der Linux-Umgebung Univention Corporate Server.

Betrachtet man die Angebote verschiedener Cloud Service Provider, bewegt sich die Verfügbarkeitsrate ihrer Dienste zwischen 95 und 99,9 Prozent. Gleichzeitig betiteln alle Provider ihr Angebot als „hochverfügbar“. Für eine Skala von 0 bis 100 Prozent schaut das doch ganz gut aus, doch das kann ein Trugschluss sein. Es lohnt sich, die Zahlen in den richtigen Kontext einzuordnen und sich die eigenen Ansprüche an die notwendige Verfügbarkeit in unterschiedlichen IT-Anforderungen klar zu machen.

Viele Neunen sind gut - für's Marketing

Die Prozentangaben, die sich oft finden, sind eine der gängigsten Methoden, die Verfügbarkeit von Systemen zu klassifizieren. Normalerweise stehen diese dafür, zu wie viel Prozent der Zeit, über ein komplettes Jahr gesehen, ein System verfügbar ist. Typisch ist bei vielen Providern die Werbeaussage „double nine“ oder „triple nine“, was für 99 beziehungsweise 99,9 Prozent Verfügbarkeit steht. Einige Server-Hersteller werben mit „fünf Neunen“.

Unter der Annahme, dass die meisten Verträge von möglichen Ausfallzeiten über die komplette Jahresspanne ausgehen, ergeben sich für die Verfügbarkeits-Prozentzahlen folgende Ausfallzeiten:

90 % = 36 Tage und 12 Stunden,

95 % = 18 Tage und 6 Stunden,

99 % = 3 Tage, 15 Stunden und 36 Minuten,

99,9 % = 8 Stunden, 45 Minuten und 36 Sekunden,

99,99 % = 52 Minuten und 33 Sekunden,

99,999 % = 5 Minuten und 15 Sekunden,

99,9999 % = 31.5 Sekunden.

Das Optimum liegt nicht nahe an 100 Prozent

Zugegeben, solche Zahlen zeigen die Verfügbarkeit eher aus der Sicht des Vertragsmanagements. Sie können aber dabei helfen, einzuschätzen, wie zuverlässig ein Dienst ist: Je höher die Prozentzahl, desto besser der Service. Jedoch muss man dabei beachten, dass diese Zahlen immer nur die Gesamtsicht auf ein komplettes Jahr wiedergeben und eine hohe Prozentzahl an Verfügbarkeit in bestimmten Situationen nicht die beste Option darstellen muss.

Schauen wir uns dazu folgendes Beispiel an: In einem Krankenhaus stehen zwei lebenserhaltende Geräte. Eines von beiden fällt alle 30 Minuten für eine Viertelsekunde aus, was insgesamt 73 Minuten pro Jahr ausmachen würde. Die meisten Personen würden dennoch dieses System mit 99,9 Prozent Verfügbarkeit gegenüber einem System bevorzugen, das zwar eine 99,999-prozentige Verfügbarkeit garantiert, dabei aber fünf Minuten am Stück ausfallen könnte. Denn so ein Ausfall hätte fatale Folgen. Obwohl System Nummer Zwei auf dem Papier zuverlässiger ist, ist die Überlebenschance für den Patienten bei Gerät Eins deutlich besser. Es ist also nicht nur die reine Verfügbarkeit zu beachten.

Time to Recovery ist nicht weniger wichtig

Das Beispiel zeigt, dass das eigentlich weniger zuverlässige System in manchen Fällen das bessere ist, da es nach einem Ausfall schneller wieder in den normalen Betriebszustand geht. Das wird als „time to recovery“ bezeichnet. In den meisten Fällen kann man sagen, dass ein Ausfall, den der Nutzer nicht bemerkt, wesentlich unproblematischer ist als einer, der eine große Zahl von Mitarbeitern vom Arbeiten abhält.

Kann ein Nutzer sich nicht anmelden, nützt es auch nichts, wenn der Mailserver und das ERP-System, auf die er eigentlich zugreifen möchte, hochverfügbar sind. Ein System-Design und das zugehörige Domain-Konzept aus mindestens einem DC-Master und einem DC-Backup können dieses Problem bereits lösen.

Was ist mit geplante Ausfallzeiten?

Geplante Ausfallzeiten sind ein weiterer Faktor, den man einplanen sollte, der aber nicht immer richtig verstanden wird. Auch hier hängt es immer von dem jeweiligen System ab, ob geplante Ausfallzeiten mit eingeplant werden müssen.

Zwei Beispiele machen diese Unterscheidung deutlich. Das erste ist eine Eisenhütte mit 50 Angestellten. Im Regelfall ist die Schmelze am Wochenende geschlossen, eine Downtime der Computer am Wochenende ist daher kein Problem. Ein Ausfall während der Arbeitszeit hätte jedoch tausende Euro an Schaden zur Folge.

Am anderen Ende der Skala befindet sich das Beispiel der Fluglinien. In diesem Segment spielt es keine Rolle, ob eine Downtime geplant oder ungeplant ist. Wenn das System ausfällt, wird es teuer. Denn jede zusätzliche Minute, in der Buchungen nicht möglich sind oder die ein Flugzeug am Boden verbringt, führt zu erheblichen Mehrkosten.

Anforderung an die Verfügbarkeit

Die drei wichtigsten Fragen, wenn es um die Verfügbarkeit von IT-Systemen geht, sind deshalb:

* Wie oft können Systeme ausfallen?

* Wie lange werden diese nicht verfügbar sein?

* Lässt sich eine Umgebung für geplante Updates abschalten?

Diese Fragen müssen für jeden benötigten Dienst beantwortet werden. Besonders bei Systemen mit hohen Anforderungen ist zu überprüfen, welche Systeme das betrifft. Dabei darf man nicht außer Acht lassen, dass es unpraktisch und zu teuer sein kann, alle Systeme auf dem höchsten Niveau zu betreiben.

Was ist wirklich wichtig?

Ein weiteres Beispiel: Stellen Sie sich ein Call Center vor. In diesem arbeiten 10.000 Telefonisten und vier Mitarbeiter in der Personalabteilung. Fällt die Personalsoftware aus, können vier Personen nicht arbeiten, aber dies betrifft „nur“ interne Prozesse. Können sich hingegen die 10.000 Telefonisten nicht am System anmelden, ist das eine existentielle Gefahr für das Unternehmen. Gleichzeitig ist es vermutlich um ein Vielfaches komplizierter, die Personalsoftware hochverfügbar zu machen. Entsprechend wird beiden Services eine andere Priorität zugewiesen.

Technische Ansätze

Es gibt mehrere Techniken, um IT-Systeme hochverfügbar zu machen. Hier die zwei populärsten:

Redundante Systeme

Als Erstes besteht die Möglichkeit, redundante Systeme aufzubauen. Dabei stehen mehrere Systeme bereit, die die Aufgaben erledigen können. Die Benutzerauthentifizierung von Univention Corporate Server (UCS), dem Open-Source-basierenden Server-Betriebs- und Managementsystem des Bremer Softwareherstellers Univention, [linkhttps://www.univention.de/produkte/ucs/], ist ein Beispiel für diese Umsetzung. Dem Client stehen dabei mehrere Server zur Verfügung, an denen er sich anmelden kann. Die Software, hier Samba 4, ist dafür konzipiert, diese Funktionen bereitzustellen. So sind Setup und Betrieb einfach.

Für die Anzahl benötigter Systeme gibt es folgende Faustregel: Man nimmt die Zahl der Systeme, die man braucht, um die Arbeit zu erledigen, mal zwei. Eins, um geplante Arbeiten durchzuführen und ein weiteres System, welches ausfallen kann. Dies ist jedoch nur eine Faustregel. Die Nutzererwartungen an das System müssen im Detail analysiert werden, um die Investitionen zu rechtfertigen.

Caching

Ein weiterer Ansatz ist Caching. Dabei werden die Daten temporär auf einem anderen System zwischengespeichert, bis der Server wieder verfügbar ist. SMTP Proxy Server, die vor dem Mailserver stehen und E-Mails zwischenspeichern können, sind ein weiteres Beispiel für den Einsatz von Caching. Beim Caching muss man jedoch beachten, dass es sich immer nur um eine Überbrückung von Ausfällen handelt.

Hochverfügbarkeit am Beispiel von UCS

Es gibt Verfügbarkeits-relevante Services, die man sich aus frei verfügbaren Open-Source-Lösungen zusammenstellen könnte. In UCS stehen sie bereits integriert zur Verfügung stehen. Folgende Dienste spielen für den Aufbau einer hochverfügbaren IT-Umgebung eine wichtige Rolle:

Directory

In der Kategorie Directory sind drei Services wichtig:

* Der LDAP-Server steht auf allen Master-, Backup- und Slave-Systemen zur Verfügung. Solange mindestens ein Master und ein Backup zur Verfügung stehen, kann einer von beiden ausfallen. Dabei ist jedoch zu beachten, dass der DNS-Eintrag zu beiden Servern zeigt.

*Samba 4 ist um einen Multi-Master-Ansatz konzipiert. Entsprechend sind Group Policies, Nutzerauthentifizierung sowie ein gewisser Teil der Administration verfügbar, wenn ein Domain Controller (DC) funktioniert. Wie auch beim LDAP muss man dabei beachten, dass die Dienste vom DNS abhängen.

* Die Univention Management Console (UMC) steht nur auf dem UCS-Master zur Verfügung. Bei einem temporären Ausfall des Masters kommt es entsprechend zu Einschränkungen in der Administration. Bei einem permanenten Ausfall kann die Rolle des DC-Masters, und damit auch die UMC, permanent auf einen Backup übertragen werden.

Authentication

In Sachen Authentication geht es um zwei Dienste:

* Der Kerberos-Server steht, wie das LDAP, auf jedem Master-, Backup- und Slave-System zur Verfügung.

* UCS hat einen SAML-Cluster bereits konfiguriert. Dies bedeutet, dass jeder DC-Master und DC-Backup SAML zur Authentifizierung bereitstellt. Entsprechend lassen sich diese intern per DNS Round Robin oder extern über einen Loadbalancer verfügbar machen.

File Services

Für File Services sind ebenfalls zwei Dinge wichtig:

* Das ist erstens wieder Samba. UCS repliziert in der Standardkonfiguration keine Daten zwischen mehreren Servern. Der Hauptgrund ist der Bedarf an Speicherplatz. Die Komplexität und Anforderungen der Protokolle sind ein zweiter Grund, warum UCS im Standardumfang keine Replikation hat. Der einfachste Weg, Probleme mit einem Fileserver zu umgehen, ist Caching auf dem Client. Unter Windows bieten sich hierzu Folder Redirection an.

* Die Aussage für den Samba-Fileserver gilt auch für NFS. Wie bei Samba sollte man sich hier mit Caching beschäftigen. CacheFS ist die Option für Linux.

Network Services

Schließlich sind die Network Services zu beachten:

* Jeder UCS Domain Controller hat einen DNS-Server, der sich aus einer Datenbasis bedient. Entsprechend muss man nur sicherstellen, dass die Clients mehrere DNS-Server ansprechen.

* Hochverfügbarkeit für DHCP hängt von dem Einsatzszenario ab. Wenn jeder Client in der UMC seine eigene IP hat, reicht es bereit aus, DHCP auf mehreren Servern zu installieren. Sollen jedoch freie Adressen verwendet werden, müssen Failover Peers konfiguriert werden.

Anmerkung: Dieser Beitrag ist die gekürzte Version eines Blogbeitrags des Autors auf der Website von Univention. Den vollständigen Text mit weiteren Hinweisen finden Sie dort.

* Kevin Dominik Korte ist President of Univention North America Inc.

Was meinen Sie zu diesem Thema?
Guter Einstieg ins Thema, aber dann frühzeitig in eine Marketingnummer abgebogen. .. schade??  lesen
posted am 17.08.2017 um 09:53 von xb-consulting


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44837994 / Strategien)