Photo of a hospital resuscitation icon

Vor Kurzem unterstützte ich einen Kunden bei der Auswahl eines Cloud Service Providers. Die Verfügbarkeitsrate der Angebote bewegte sich zwischen 95 und 99,9 Prozent. Dabei betitelten alle Provider ihr Angebot als „hochverfügbar“. Für die meisten klingen solche Zahlen im Hinblick auf eine Skala von 0 bis 100 Prozent wirklich gut und sie gehen davon aus, dass diese Dienste quasi nie versagen. Doch das kann ein Trugschluss sein. Es lohnt sich, einen genaueren Blick auf dieses Thema zu werfen, die Zahlen in den richtigen Kontext einzuordnen und sich die eigenen Ansprüche an die notwendige Verfügbarkeit der geplanten IT-Umgebung klar zu machen.

Ich hoffe, Ihnen im Folgenden einige wichtige Anregungen dazu geben zu können, indem ich unterschiedliche Szenarien skizziere. Am Ende des Artikels finden Sie außerdem eine Übersicht, welche technischen Komponenten von UCS für das Thema Hochverfügbarkeit eine Rolle spielen.

Verfügbarkeit und Ausfallzeiten

Die Prozentangaben, die sich oft finden, sind eine der gängigsten Methoden, die Verfügbarkeit von Systemen zu klassifizieren. Normalerweise stehen diese dafür, welchen Teil des Jahres das System verfügbar ist. Typisch ist auch die Werbeaussage „double nine“ oder „triple nine“, die in der IT für 99 oder 99.9 Prozent Verfügbarkeit stehen.

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

Verfügbarkeit 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

 

Zugegeben zeigen diese Zahlen 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% 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.

UCS ist zwar nicht dafür gedacht, medizinisches Gerät zu betreiben, aber das Beispiel zeigt, dass es noch weitere Faktoren gibt, die beachtet werden müssen.

Hochverfügbarkeit: Time to Recovery

Das Beispiel oben zeigt eindeutig, 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. In der technischen Dokumentation wird das als „time to recovery“ bezeichnet. Wenn man sich UCS ansieht, zeigt sich schnell, dass auch hier die Ausfalllänge der bessere Planungsfaktor ist. 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.

UCS with small business server functionsWenn man sich die Features von UCS ansieht, wird schnell deutlich, dass die Authentifizierung von Nutzern zu dessen Kernfeatures zählt. 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. Das Design von UCS und das zugehörige Domain-Konzept aus mindestens einem DC-Master und einem DC-Backup können dieses Problem bereits lösen.

Geplante Ausfallzeiten und Hochverfügbarkeit

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, 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 meine Systeme ausfallen?
  • Wie lange werden diese nicht verfügbar sein?
  • Kann ich meine Umgebung für geplante Updates abschalten?

Diese Fragen müssen für jeden benötigten Dienst beantwortet werden. Besonders bei Systemen mit hohen Anforderungen muss überprüft werden, 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.

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 Personal-Software 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 Personal-Software hochverfügbar zu machen. Entsprechend wird beiden Services eine andere Priorität zugewiesen.

Techniken zur Erstellung eines hochverfügbaren Systems

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

Redundante Systeme

Icon UCS Authentication servicesAls Erstes besteht die Möglichkeit, redundante Systeme aufzubauen. Dabei stehen mehrere Systeme bereit, die die Aufgaben erledigen können. Die Benutzerauthentifizierung von UCS ist ein gutes Beispiel für die 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. UCS macht dabei das Setup und den 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 plus 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. Die Benutzer-Profile sind ein Beispiel, bei dem UCS Caching-Prozesse nutzt. 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.

UCS und Hochverfügbarkeit

Nachdem wir die Kriterien für Hochverfügbarkeit analysiert haben, ist es jetzt an der Zeit, dass wir uns die Services in UCS ansehen und wie Hochverfügbarkeit in diesen umgesetzt wird.

Kategorie Service Strategie für Hochverfügbarkeit
Directory LDAP 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 muss man jedoch beachten, dass der DNS Eintrag zu beiden Servern zeigt.
Directory Samba AD 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 funktioniert. Wie auch beim LDAP muss man dabei beachten, dass die Dienste vom DNS abhängen.
Directory Univention Management Console (UMC) 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 Kerberos Wie auch das LDAP steht der Kerberos-Server auf jedem Master, Backup und Slave Systems zur Verfügung.
Authentication SAML UCS hat einen SAML Cluster bereits konfiguriert. Dies bedeutet, dass jeder DC-Master und DC-Backup SAML zur Authentifizierung bereitstellt. Entsprechend können diese intern per DNS Round Robin oder extern über einen Loadbalancer verfügbar gemacht werden.
File Services 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 wir keine Replikation im Standardumfang haben.

Der einfachste Weg, Probleme mit einem Fileserver zu umgehen, ist Caching auf dem Client. Unter Windows bieten sich hierzu Folder Redirection an.

File Services NFS Die Aussage für den Samba Fileserver gilt auch für NFS und wie bei Samba sollte man sich hier mit Caching beschäftigen. CacheFS ist hier die Option für Linux.
Network Services DNS 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.
Network Services DHCP 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.

 

Dies stellt natürlich nur einen Einstieg in das Thema Hochverfügbarkeit mit UCS dar. Viele weitere Dienste wie z. B. Virtualisierung und die meisten Partnerprodukte benötigen eine tiefgreifende Analyse. Unser Professional Services Team steht Ihnen dabei gerne zur Verfügung und erstellt mit Ihnen einen Projektplan.

Fazit zur Hochverfügbarkeit im IT-Umfeld

Hochverfügbarkeit ist eines der Hot Topics in der IT. Wenn es richtig gemacht wird, kann Hochverfügbarkeit viele Vorteile bieten. Wenn die Planung aber nicht stimmt, kann Hochverfügbarkeit viele Ressourcen verschlingen, ohne Probleme zu lösen.


 

Lust auf mehr? Dieser Blogartikel könnte Sie auch interessieren:

Sync und Kontrolle aller Änderungen im OpenLDAP über Listener-Module – Gewusst wie!

Bei weiteren Fragen helfen wir Ihnen gern über unser Forum weiter oder nutzen Sie einfach unsere Kommentarfunktion auf dieser Seite.

Ihr Kommentar

 

UCS Core Edition jetzt kostenfrei einsetzen!

Zum Downloadbereich
Kevin Dominik Korte

Kevin Dominik Korte studierte Informatik an der Jacobs University Bremen und schloss 2011 mit einem Master of Science ab. Anschließend arbeitete er zwei Jahre im Professional Services Team von Univention. Seit Oktober 2013 ist er President of Univention North America Inc. und für die Geschäftsentwicklung in den USA verantwortlich.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert