Redundanter Ausfall, oder warum zweifach redundante Systeme versagen

Bei T-Mobile gab es am 20.4.2009 (übrigens dem 120sten Jahrestags der Geburt Hitlers, die Nazis sind aber nicht an allem Schuld was hierzulande schiefgeht) einen spektakulären Ausfall, denn das gesamte T-Mobil-Netz brach zusammen:

• www.heise.de/mobil/Panne-im-T-Mobile-Netz-wird-untersucht-Update--/newsticker/meldung/136531

Das gesamte Mobiltelefonnetzwerk brach zusammen, weil das zentrale Directory (HLR) abstürzte, und dadurch drei Dinge ausfielen:

• Handys konnten sich nicht neu ins Netz einbuchen, brereits eingebuchte funktionierten aber weiterhin
• Die Rufnummernzuordnung wurde unterbrochen, so dass die Handys nicht mehr angerufen werden konnten.
• Eine Zuordung zu Abrechnungskonten (z. B. Prepaied) war nicht mehr möglich, so dass man auch nicht mehr wegtelefonieren konnte.

Bereits bestehende Verbindungen oder Einbuchungen waren von dem Problem nicht betroffen so lange sie nicht telfonieren wollten. Mobiles Internet lief deshalb weiter. Ebenso sollte der Notruf ebenfalls weiterfunktioniert haben (da dieser das Directory nicht benötigt).

Jetzt stellt sich die Frage, wie es kommen kann, dass ein zweifach redundantes System (das also aus 3 unabhängig funktionierenden Komponenten besteht, die jede den Dienst für sich gestellt aufrecht erhalten kann) abstürzen konnte.

Der Denkfehler bei der doppelten Redundanz

Jeder normale Mensch wird meinen, eine doppelte Redundanz ist bereits mehr als notwendig, eine einfache Redundanz reicht aus. Das erklärt die Doppelstreifen, also warum Polizisten z. B. immer zu zweit unterwegs sind.

Aber das funktioniert nur so bei Menschen. Der eine dreht ab, der andere bringt ihn wieder zurück auf den Boden. Der eine wird krank, der andere kann übernehmen. Irgendwie wurschtelt man sich durch. Bei Menschen geht das. Bei Systemen nicht.

Der gemeinsame Ausfall von einfach-redundanten-Systemen ist Legion. Meistens funktioniert es ja super, aber immer mal wieder klemmt es eben dann doch. Und dann ist eben alles unten.

Das HLR ist ein Dienst, den man eigentlich kurzfristig offline nehmen könnte, wäre es nicht strukturell zu eng in das Netz gebunden. Fällt dieses HLR aus oder ist nicht verfügbar, bekommt der Anrufer wohlmöglich zu hören, dass ein Teilnehmer nicht existiert, oder ein Teilnehmer bekommt die Meldung, seine Karte wäre gesperrt. Das kann man so nicht hinnehmen, weshalb dieser Dienst also 24/7 ohne Wartungsfenster zu 99,9% und mehr verfügbar sein muss.

Eine Verfügbarkeit von 99,9% im Dauerbetrieb, so meinen die meisten Experten wohl, sei mit einer doppel-Redundanz möglich. D. h. man hat 3 voneinander unabhängige Systeme, von denen jedes den Dienst übernehmen kann. Dadurch wird auch Wartung unterstützt, da man jederzeit eines der Systeme offline nehmen kann, und somit weiterhin ein redundantes System hat auf dem alles läuft.

Das ist aber leider eine Milchmädchenrechnung. Ein wirklich wartbares System das 24/7 mit einer hohen Verfügbarkeit durchlaufen kann, besteht aus mindestens 5(!) Systemen. Sinnvoller sind 7(!) solcher Systeme notwendig, also eine Verteilung auf 7 voneinander unabhängige Rechenzentren in verschiedenen Regionen, mit disjunkten kritischen Pfaden. Hand man diese Infrastruktur, lässt sich die Verfügbarkeit durch Maßnahmen des Cloud-Computing noch weiter steigern.

Der Ausfall steckt in der Struktur

Es gibt verschiedene Ausfallszenarien, die ich hier kurz durchsprechen will:

Ausfall von Hardware

Das ist eigentlich der typischste Fall, meint man, irgendeine Komponente fackelt ab und einer der Server fällt runter. Das kommt gar nicht so selten vor, ist aber trotzdem heute angesichts der schon in die Hardware verbauten Möglichkeiten eher die Ausnahme.

Ein modernes AIX-System überlebt im laufenden Betrieb den Ausfall einer Netzwerkkarte oder eines RAM-Moduls ohne irgendwelchen Schaden zu nehmen. Chipkill, Parity und redundanter Systemaufbau machen das möglich. Im Fall der Netzwerkkarte übernimmt eine andere deren Funktion, es gehen lediglich einige Netzwerkpakete verloren, was heutzutage eigentlich jede auf IP basierende Software überhaupt nicht mehr richtig mitbekommt.

Selbst wenn eine CPU durchbrennt kann das ein heutiges System überleben! Im schlimmsten Fall trifft es den Thread der gerade auf der CPU läuft. Moderne Software kann auch gegen so etwas gewappnet sein, DB2 startet z. B. seine Prozesse neu, es muss nicht zwangsläufig zu einem Crash mit Desaster-Recovery kommen. Die Cluster-Software erkennt evtl. die gecrashte Datenbank und fährt sie neu hoch, etc.

Die Unterbrechung ist oft so kurz, dass das Operating den Fehler überhaupt nicht wahrnimmt. Nur eine Notiz im Monitoring weist darauf hin, dass gerade etwas seltsames passiert ist, und eine andere Notiz meldet den Hardwareausfall, so dass der Techniker die Hardware tauscht - ohne dass dabei die Maschine überhaupt offline genommen werden muss.

Selbst wenn die Hardware stromlos werden muss, kann man mit modernen VM-Strukturen die laufende Partition einfach auf eine Gast-Hardware verschieben, die Wartung vornehmen, und dann wieder zurückschieben. Die laufende Applikation bekommt davon ger nichts mit.

Hardwareausfälle kann man beim Einsatz aktueller Technik somit als gemeistert ansehen. Dafür braucht es nicht einmal eine doppel-Redundanz (außer auf SAN-Seite usw. aber das ist etwas anderes).

Ausfall vom Netzwerk

Schwerer wiegt da, wenn eine der Netzwerkstrecken (Stichwort: Kreative Baggerpiloten) ausfällt. Viele Software ist auch heute nicht darauf vorbereitet, eine derartige Störung vollkommen automatisch zu verkraften und fällt runter. Oft dauert es bis zu einem Timeout, bis die Störung überhaupt erkannt wird.

Hier hilft modernes Leitungsmanagement und redundante Netzwerkstrukturen. Jedes SAN arbeitet OSPF-artig (Open Shortest Path First) um die Latenzen zu vermindern. Arbeitet ein SAN-Adapter mit verringerter Leistung (gelegentliche Bitfehler) übernimmt der andere SAN-Adapter dessen Arbeit. Die Störung ist dabei so miminal, dass sie nur dann auffällt, wenn massiv Write-Barriers auftreten, also bei OLAP eher gar nicht während bei OLTP die Maschine bei Lastspitzen "träge" wird. So richtig ein Problem wird es sommit nicht, und es lässt sich meistens sogar durch momentanes Abschalten des SAN-Adapters (Inbetriebnahme eines Backup-Pfades oder verschieben der VM etc.) beseitigen.

In der Regel sollten die Netzwerkverbindunge so gestaltet sein, dass ein 50% Ausfall überhaupt nicht ins Gewicht fällt. Die Netzwerkabstützung muss ebenfalls dual ausgelegt sein und ohne SPF (Single Point of Failure). Damit hat man die Netzwerkseite eigentlich auch im Griff.

Fällt dann das Netzwerk doch aus oder wird unzuverlässig, muss das (implizite oder explizte) Monitoring eben die Maschine isolieren und die Last auf die anderen - redundanten - Systeme lenken.

Somit sind Netzwerkausfälle zentraler Komponenten heutzutage ebenfalls gemeistert. Hierfür reicht eine doppel-Redundanz also aus.

Stromausfall

Stromausfall sollte eigentlich heutzutage nicht passieren. Gute Rechenzentren verfügen deshalb über eine 4-fach-redundante Stromversorgung (d. h. sie haben 5 unabhängige Systeme die das gesammte Rechenzentrum mit Strom beliefern können) mit einer nachgeschalteten 3-fach redundanten USV-Linie. Das sieht so aus, dass ständig 4 Systeme "online" sind, wobei je 2 Systeme über eine Kreuzschaltung einen Strompfad bedienen, und in jedem Rack zwei Strompfade ankommen. Dazwischen liegen noch kleinere 3-fach redundante USV-Strecken für jeden Bereich des Rechenzentrums, die nur für den Fall notwendig sind, wenn im Haus eine der 4 Übertragungswege "abbrennt" oder Schütze auslösen. Idealerweise bedeutet das, dass man selbst im Falle dass ein Bereich des Hauses brennt die Stromversorgung für den Rest aufrechterhalten kann, da man nur die durch das feuer betroffenen Stromlinien vom Netz nehmen muss, bzw. EDV-Räume so lange komplett abgekoppelt werden können bis eine Notversorgungslinie geschaltet wurde (was ein manueller Vorgang ist der ein paar Minuten braucht). Das 5. System der Anfangs-Redundanz ist "Cold Standby" und kann eingreifen, wenn eines der "Hot"-Systeme versagt. In diesem Fall wird das kaputte System offline genommen, und das Standy-System übernimmt dessen Funktion. Anschließend wird das kaputte System gewartet.

Jedes dieser Systeme ist Hot und Online, d. h. stellt den Strom aus einem Schwungrad her, welches durch einen Elektromotor aus dem Versorgernetz gespeist wird. Daran angeschlossen ist über eine Kupplung ein über Explosivladung zündender Diesel, der idealerweise binnen weniger Sekunden die Synchronisierunggeschwindigkeit erreicht und einkuppeln kann, so ergibt sich in der Phase des Ausfalls lediglich eine kurze Abweichung der Nennfrequenz des Wechselstroms. Die Funktion jedes Aggregats wird außerdem ständig gewartet, d. h. einmal alle paar Monate prüft man die korrekte Funktionsweise. Dies geht wegen dem einfach definierbaren Wartungszyklus, indem man das "Cold"-System hochfährt, sich mit dem zu wartenden System synchronisiert, und dann - ohne Umschaltverluste - dessen Funktion übernimmt, so dass man das zu wartende System in den "Cold"-Zustand versetzen kann. Auf diese Weise kann man die Stromversorgung - ohne Verluste befürchten zu müssen - ständig vollständig(!) aufrechterhalten, warten und ggf. deren Kapazität erhöhen.

"Normale" Rechenzentren begnügen sich mit einer doppelten Redundanz mit einem einfach-redundanten Diesel, verfügen also über 3 USV-Linien, von denen jede Dual ausgeführt ist (also die doppelten Strompfade bedienen kann), sowie zwei Diesel-Aggregaten. Der Nachteil dieser Systeme ist meistens, dass sie längere Stromausfälle (über 30 Minuten) nicht ohne diese Diesel unterstützen können.

Derartige nur dreifach ausgelegten Rechenzentren müssen bei Stromausfällen auf Netzebene meiste heruntergefahren werden, denn just die Diesel springen natürlich nicht an, wenn es mal dazu kommt. Der eine Diesel ist gerade in Wartung (seit 2 Jahren, Cost-Cut, ging ja bisher gut) und der andere will just da nicht (evtl. weil ein Steuerungsmodul die auf Netzebene entstandene Überlast nicht verkraftet hat).

Softwareprobleme

Es ist gar nicht so selten, dass ein Softwareproblem, das man vorher nicht hatte, die Übernahme des Dienstes "verklemmt", so dass eines der Systeme nicht anspringen kann. Bei einer doppel-Redundanz sollte in solch einem Fall das Dritte System übernehmen.

Die Natur von Standy aber ist, dass alles eben nicht läuft, sondern übernommen wird. Dieses Problem gilt heute als noch-nicht gemeistert.

Cloud-Computing ändert diese Situation. In diesem Fall hat man mehrere Systeme die alle zusammen den Dienst erbringen. Fällt ein System aus ist das nicht tragisch, die anderen machen weiter wie zuvor. Siehe das Beispiel der USVs weiter oben, auf der technischen Hardware-Ebene nutzt man das Prinzip schon seit Jahrzehnten. Nur bei der Software gilt heute meist Master-Slave bzw. Aktiv-Passiv.

Aber Cloud-Computing steckt gerade noch in den Kinderschuhen. So lange eine VM nicht gleichzeitig auf zwei Rechnern laufen kann, die durch den Durchmesser der Erde getrennt voneinander aufgebaut wurden, so lange kann man nicht davon ausgehen, dass Cloud-Computing schon perfektioniert wurde. Denn nur solch ein Prinzip würde es heute schon erlauben, gewisse Dinge, die noch monolithisch und singulär arbeiten, mit Redundanzen zu versehen.

Deshalb läuft eigentlich jede Software - mal von Datenbanken abgesehen - heute eigentlich immer nur aktiv auf einem Knoten und passiv auf den anderen mit. Man weiß also gar nicht, wie sich die passiven Knoten verhalten werden, wenn sie aktiv werden müssen. Im besten Fall funktioniert es wie es soll. Aber nicht selten klemmt etwas.

Man denkt vielleicht, bei 3 Systemen und einem Ausfalls wäre es trotzdem selten, dass die beiden anderen Systeme nicht übernehmen können. Aber das ist schon alleine wegen des Geburtstagsphänomens falsch.

Geburtstagsphänomen

Ich nenne es auch "aus Sympathie mitstreiken". Das Geburtstagsphänomen beschreibt, dass es unerwartet wahrscheinlich ist, dass zwei Leute am gleichen Tag Geburtstag haben, wenn es zu größeren Gruppen kommt.

Anders betrachtet bedeutet das, es ist gar nicht so unwahrscheinlich, dass sich zwei Bugs zur gleichen Zeit treffen, und somit verhindern, dass die beiden verbliebenen Systeme den ausgefallenen Dienst ersetzen. Die Bugs müssen dafür nicht einmal identisch sein! Das Geburtstags-Phänomen betrifft somit Homogene Systeme (auf denen dieselbe Software läuft) genauso wie heterogene Systeme (auf denen verschiedene Software läuft die aber dasselbe leisten soll).

Besonders deutlich wird das Geburtstagsphänomen dann, wenn eine Maschine auf keinen Fall übernehmen kann, aber die letzte Maschine (bei 3) genau deshalb nicht übernimmt, weil die zweite Maschine das durch ihren Fehler verhindert.

Wartungsarbeiten

Eine der häufigsten Ausfallursachen aber sind schlicht Wartungsarbeiten bei denen etwas schiefgeht. Nach Murphy also genau dann, wenn etwas schiefgehen kann, also ständig.

Wartung kann mehrere Ursachen haben:

• Ein System ist ausgefallen und braucht Wartung. Hier kommt es meist zur Störung, wenn das kaputte System wieder angefahren wird und irgendetwas schiefgeht (z. B. in den Anweisungen noch etwas fehlt, da der Fall nie vorher aufgetreten ist).
• Ein System funktioniert perfekt, soll aber in den Wartungszyklus, z. B. für Softwareupdate. Bei der manuell ausgelösten Übernahme kommt es zu Störungen. Dies ist meistens dann der Fall, wenn man nicht zuerst ein System hochnehmen kann bevor das andere runtergenommen wird. Wenn es also eine Phase der Nichtverfügbarkeit gibt, kann sich diese bis zur Unendlichkeit ausweiten.
• Es wird das falsche System abgeschaltet. Das passiert öfters als man denkt. Beispielsweise ein Techniker stolpert über ein Kabel - es war just das des noch laufenden Dual-Clusters. Oder das RAID5 mit 3 Platten meldet die ausgefallene Platte durch LED-Signal. Stehst Du vor dem RAID-Rahmen siehst Du einen bei dem die LED aus ist, einem, bei dem sie permanent an ist, und einer bei dem sie blinkt - welche Platte ist ausgefallen (die nicht leuchtende LED ist ja offensichtlich kaputt, aber wie markieren die Controller-Designer wohl die ausgefallene Platte. Einige tun dies über "diejenige die bei Zugriff nicht mehr blinkt" die anderen "die, die regelmäßig blinkt")?

Bei drei Systemen ist es zwar unwahrscheinlich, dass man gleichzeitig alle drei killt, aber das ist auch gar nicht notwendig. Wenn nur noch ein einziges lauffähiges System existiert ist man ohne Redundanz. Und just da muss nur ein kleiner Fehler auf diesem System auftreten und schon ist die Applikation nicht mehr verfügbar. Das passiert - nach Murphy - natürlich just dann, wenn man die Wartungsarbeiten durchführt.

Aber dazu ist es nicht einmal notwendig, einen Fehler zu begehen. Software-Updates sind eine Fehlerquelle die gar nicht selten zuschlägt.

Man nimmt ein System - das bisher passiv war - offline um es zu patchen. Anschließend fährt man es hoch, belässt es aber passiv. Schon dabei kann es zu Problemen kommen, beispielsweise weil die Cluster-Software sich nach dem Update mit den anderen zwei Systemen streitet. Im günstigsten Fall erzwingt sie eine Übernahme, da sie die aktuellste Version ist (so passiert wenn man W2003 in eine W2000 Domäne gesteckt hat), und alles läuft trotzdem weiter.

Im dummen Fall (der leider oft vorkommt) geschieht diese Übernahme zum falschen Zeitpunkt, d. h. das gepatchte System ist noch gar nicht bereit, die Applikation zu übernehmen, weil man diese auch noch patchen muss (nur musste man den Cluster vorher patchen, oder tat es unüberlegterweise). Dann kommt es zum Crash.

Aber selbst wenn so weit alles glatt geht, hat man nun zwei lauffähige System und eines, von dem man nicht weiß, ob der Patch funktionierte. Sicherheitshalber patcht man also das zweite System, belässt das letzte aber noch im alten Zustand.

Dann fährt man den Cluster auf den beiden gepatchten Systemen hoch und muss hoffen. Klappt alles nicht, schaltet man zurück auf das noch alte System und alles läuft wieder. So die Theorie. Nur was, wenn jetzt das Altsystem auch nicht mehr anläuft (oder noch schlimmer: Störungen zeigt) weil der neue Patch irgendwelche Parameter nachgezogen hat, die die frühere Software überfordert?

All das ist gar nicht unwahrscheinlich. Und auch wahrscheinlich ist, dass man solche Fehler im Testsystem gar nicht simulieren konnte, da dieses nicht mir Produktivdaten läuft und nicht im produktiven Wirkbetrieb steht.

Wartungsarbeiten - so harmlos sie klingen wollen - sind heutzutage eine Hauptquelle von Problemen.

Softwarefehler

Und dann kommen noch Softwarefehler hinzu. Wie oft irgendein Bug in meinem Leben eine ordentliche Übernahme verhindert hat kann ich gar nicht mehr zählen. Nicht selten liegt der Fehler beim Sysop, weil er irgendeine Einstellung nicht nachgezogen hat etc.

Übernahmetests können das verhindern. Aber wann kann man die bei einem System gefahrlos machen, das immer 24/7 ohne Unterbrechung in Betrieb sein muss? Da helfen auch nicht weitere Redundanzen, da hilft nur "Augen zu und durch". Man muss also eigentlich bei jeder Kleinigkeit hinterher eine Übernahme provozieren, reihum bei den Systemen.

Da dies aber zu Beeinträchtigungen des Wirkbetriebs führt, wird dies oft unterlassen - was eine der Hauptfehlerquellen darstellt.

Warum 5 Systeme notwendig sind

Hat man eine 4-fach-Redundanz (also 5 Systeme), und eine geeignet implementierte Möglichkeit, kann man wie folgt vorgehen:

• Man nimmt 2 Systeme heraus
  
• Man patcht diese 2 Systeme
  
• Man schaltet sie in einen Testbetrieb und sieht nach, ob Übernahme etc. funktionieren
• Man schaltet sie in den Wirkbetrieb
  

Kommt es zu Problemen, schaltet man auf die alten 3 Systeme zurück. Dabei gehen aber Daten verloren, da die Altsysteme mit dem Datenbestand VOR ihrer Übernahme arbeiten müssen.

Da man aber ausführlich testen konnte sollte das eher selten passieren. Voraussetzung dafür ist aber der mögliche Testbetrieb.

Danach patcht man die anderen 3 Systeme und kann immer gegenseitig eine Übernahme im Testbetrieb durchführen lassen. So ist sichergestellt, dass sie den Betrieb ggf. übernehmen können.

Eigentlich braucht man also nur 4 Systeme. Aber wo bleibt bei dem Prozess dann die Redundanz? "Alt"- und "Neu"-System sind ja zueinander evtl. nicht kompatibel. Habe ich nur 4 Systeme und passiert einem davon etwas während ich patche, wäre evtl. die Redundanz perdü.

Dass es niemals an Redundanz mangeln darf kennen wir aus dem großen Stromausfall vor einigen Jahren. Das Netz war kurzfristig in einer Überlastsituation, d. h. die Redundanz war nicht mehr gewährleistet. Just da brach eine Umformerstation zusammen. Das Resultat war ein fast europaweiter Stromausfall. Wäre das Redundanzkriterium nicht schon durch die Überlast verletzt worden, hätte das Stromnetz das eigentlich aushalten müssen. Da die Betreiber das Netz aber über gebühr beansprucht hatten, haben sie die Redundanzbedingung verletzt, und somit den Stromausfall kassiert.

Das ganze löst aber nicht das Problem, wenn die Übernahme klemmt weil etwas nicht funktioniert. Allerdings kann man mit 5 Systemen "eine kleine Übernahmesituation" proben, was man eben bei 3 Systemen im Wirkbetrieb nicht kann - ohne den Wirkbetrieb zu gefährden.

Warum 7 Systeme besser sind

Nicht selten in der EDV muss man durch Scheiße waten. Alles liest sich toll auf Hochglanzprospekten und in der Theorie ist alles super. Aber so liegt die Realität einfach nicht.

Fakt ist, dass nicht selten ein System abgeschaltet werden muss. Ich spreche hier nicht von einem Computer, sondern von einer ganzen Plattform. Weil dort irgendetwas klemmt. Weil man nicht weiß, was los ist, usw.

Und aufgrund des Geburtstagsphänomens trifft das nicht selten gleichzeitig zwei Systeme auf einmal. In der EDV geht es einfach mit dem Teufel zu.

Um also ganz sicher zu sein, dass man wirklich niemals in irgendeine Bredouille kommt, benötigt man die oben angeführten 5 Systeme plus 2 Systeme, die "hopps" gehen können.

Das hat außerdem den Vorteil, wenn man 2 Systeme patcht, und dabei etwas schrecklich schiefgeht, hat man immer noch seine 5 Systeme. Danach kann man nochmals 2 Systeme offline nehmen (hat also noch 3 im Wirkbetrieb) um einen zweiten Patch zu versuchen.

Klappt es dann wieder nicht, geht es an den Neuaufbau von 2 Systemen. Während also 3 Systeme den Wirkbetrieb aufrecht erhalten, hat man 4 Systeme mit denen man so lange in der Scheiße herumpopeln kann, bis endlich alles wieder funktioniert.

Und nein, ich spreche hier nicht von "Hobbyisten", sondern von hochbezahlten Superexperten die ratlos vor dem einen oder anderen Phänomen aufgeben, und erst einmal ein paar Tage lang rumsuchen müssen bis überhaupt die Ursache ermittelt wurde.

Verschwörungstheoretiker (aka: Heisianer) machen daraus natürlich einen Komplott der Totalüberwachung der Bevölkerung. In Wirklichkeit scheint die T einige Probleme zu haben, nach den Ausfall die Systeme wieder anzufahren. So etwas ist nämlich oft komplizierter als man denkt und nicht selten ein Henne-Ei-Problem.

So wie ich es sehe sind momentan einiges an Notmaßnahmen im Netzwerk der T in Kraft getreten. Sprich, die Techniker haben so lange "wild" rumkonfiguriert bis endlich wieder etwas lief. Vermutlich war "denen oben" nämlich ziemlich wurscht, wie das Netz wieder hochkommt, Hauptsache dass es hochkommt.

In solchen Situationen tut man oft Dinge, die an sich nicht notwendig sind. So schaltet man verschlüsselte Leitungen ab, um sicherzustellen, dass es daran nicht liegen kann. Oder um tracen zu können um bestimmten Phänomenen nachzustellen. Auch wenn sich hinterher rausstellt, dass das nicht notwendig war, wie soll man das vorher wissen?

Man parametrisiert auch durchaus auf "sichere Werte" zurück, besonders dann wenn - wie nach dem Wiedernafahren des HLR - eine Netzüberlast (ausgelöst durch die sich einbuchenden Handys) vorfindet. Verschlüsselung zieht dabei einiges an Resourcen, so dass man diese zur Entlastung deaktiviert - ggf. ist das sogar der automatische Fallback, der momentan eben dauerhaft greift.

Ich weiß nicht, was genau bei der T vorgefallen ist. Aber ich weiß, was alles schiefgeht und in hektischen Situationen auftritt, welche Maßnahmen man als Admin durchführt und was passiert, wenn jemand vom Management, noch mit dem Golfschläger bewaffnet, hinter einem steht und ständig wissen will, wie lange es noch dauert, damit er zurück zum Golfen kann.

Die mit dem Golfschläger die sind es auch, die einem Techniker wie mir die notwendigen Dinge vorenthalten, so dass man nicht das bekommt, was an sich notwendig ist, sondern nur das, was minimal notwendig ist.

Eben z. B. nur 3 Systeme statt 5 Systemen (oder gar 7, was auch darstellbar wäre). Und dadurch kommt es eben zu solchen Ausfällen.

Nicht dass die 5 oder 7 Systeme das wirklich garantiert verhindern. Aber sie nehmen Stress weg. Und Stress ist eine, wenn nicht die Hauptquelle für das Entstehen von Fehlern.

Warum Cloud-Computing dagegen schützt

So, und nun noch ein paar Worte zu Cloud-Computing.

Das HLR ist offensichtlich in Aktiv-Passiv organisiert. Ein Aktiv-Aktiv-System ist auch nicht so einfach, da dieses Register sich ständig ändert (während DNS relativ gutmütig ist, wenn die Server mal nicht ganz synchronisiert sind, darf es dort keine falschen Informationen geben).

Die Software muß außerdem ziemlich viel leisten und mit sehr vielen anderen Diensten zusammenarbeiten. Z. B. für Roaming, Rufnummernportierung, Cell-Tracking, Prepaied, Twin-Cards, uvm. Einiges davon dürfte eher neueren Datums sein.

Dazu kommt, dass dieses Register eine zentrale Rolle spielt, also wie die Spinne im Netz dauernd alles im Auge behalten muss. Die Funktürme buchen das Handy ständig um, die Leute schalten ihre Handys aus und ein oder kommen aus Funklöchern heraus. Das HLR ist also ständig in Bewegung, und bei über 30 Mio Handykunden bewegt sich da ziemlich viel.

Sprich: Was das HLR macht ist alles andere als trivial und dürfte "normale" Datenbankanwendungen weit in den Schatten stellen. Selbst gut ausgestattete OLTP-Datenbanken bekommen bei mehr als 4000 Transaktionen pro Minute so ihre Probleme. Ich schätze, das HLR sieht pro Minute mindestens 100000 Transaktionen, eher mehr.

Hat man nun 3 Rechenzentren auf die das HLR in Form von Cloud-Computing verteilt wären, dann wäre es fast unmöglich, diese Standorte miteinander zu synchronisieren, denn so schnell können die Leitungen gar nicht sein. Somit gehe ich von folgendem aus:

• Das HLR läuft nur in jeweils einem Rechenzentrum. Die anderen sind Passiv.
• Die anderen Rechenzentren werden über Replikation auf dem (fast aktuellen) Stand gehalten.
• Das HLR selber läuft auf einigen Blade-Centern die ziemlich viel Dampf haben. Evtl. wird die Datenbank weitgehend im RAM gehalten, die Platten dienen also nur als "Backup-Cache".
• 90% der eigentlichen Information die das HLR hält sind temporäre Verkehrsdaten, die Stammdaten machen unter 10% aus.
• Die Daten sind extrem volatil.
  
• Das HLR selber macht keine Abrechnung und ist auch für die Abrechnung nicht unbedingt notwendig.

Bei einem Reboot des HLR müssen dann lediglich die Stammdaten geladen werden, also z. B. IMEI-Zuordnugen der Karte, Zustand des Kundenkontos (gesperrt, etc.), Portierungszuordnung der Rufnummer. Da die T davon ausgehen muss, dass die SIM-Karten aller Verträge gleichzeitig online sind, muss das HLR auch gleichzeitig alle diese Daten verwalten können.

Bei 30 Mio Kunden und ca. 10 KB pro Datensatz sind das immerhin 300 GB an Information, die man im Speicher hält. 3 Blade-Center genügen dafür.

Nicht genügen dürfte das aber für die Rechnenleistung, die notwendig wird, wenn sich 30 Mio Handys quasi gleichzeitig ins Netzwerk einzubuchen versuchen. Und zwar dann, wenn es sich um einen verschlüsselten Verbindungsaubau handelt. Das erklärt mir, warum so viele Leute einen unverschlüsselten Verbindungsaufbau sehen.

Dass es auch heute noch so zu sein scheint erkläre ich mir dadurch, dass es wohl nicht so einfach ist, wieder zurück auf Verschlüsselung zu schalten. Im dümmsten Fall ist dazu ein Reboot der Software notwendig. Was wieder das Problem ergäbe, dass die Rechenleistung nicht ausreicht, wenn man es neu anfährt. Die Methode also wird sein, das HLR neu zu starten, und die Netzwerkkomponenten rotierend wieder Online zu nehmen.

Allerdings möchte ich nicht wissen, wie viele Kunden jetzt wieder schreien, wenn sie morgens um 4:00 Uhr mal für 5 Minuten kein Netz haben, weil das HLR rebootet wird ..

Die Probleme gibt es bei Cloud-Computing nicht

Die Situation ist also grotesk: Da stehen 2 Blade-Center rum und drehen Däumchen (naja, sie halten sich zumindest auf dem aktuellen Stand), während ein drittes an Unterkapazitäten leidet und mit der Arbeit nicht fertig wird (jetzt schon, aber nicht nach einem Reboot). Leider kann man die Kapazitäten nicht nutzen.

eBusiness on Demand (von IBM) ist hier auch eher keine Lösung. Die Software ist sicher noch nicht für den dynamischen Betrieb ausgelegt, man kann also nicht einfach nur "mehr CPUs" hinzuschalten und das dann wieder zurücknehmen. Auch nicht sinnvoll ist, das HLR dann in einem "Super-Modus" weiterlaufen zu lassen, d. h. zig CPUs zu verwschwenden, nur damit das HLR den Reboot überlebt und hinterher dann - vergleichsweise - Dornrößchenschlaf zu machen.

Wäre das HLR in der Lage, verteilt zu laufen, also auf allen 3 Blade-Centern gleichzeitig, dann könnte man einfach 2 weitere Standorte hinzunehmen (um auf die von mir geforderten 5 zu kommen) und alle etwas besser ausstatten, womit das HLR dann mit der Flut der Anfragen nach einem Reboot zumindest - mit Einschränkungen - klarkommen sollte.

Mit echtem Cloud-Computing könnte man dem HLR auch kurzfristig mehr CPUs geben (sagen wir mal: Faktor 100) um hinterher wieder "back to normal" zu gehen. Genug CPUs hat die T in ihrem Netz, es müsste nur jeder Mitarbeiter einen Cloud-Computing-Client auf dem PC haben (wenn 200000 PCs in einer Nacht plötzlich jeder 150W mehr Leistung zieht sind das nur 30 MW, solch eine kleine Lastspitze juckt die Energieversorger nicht).

Nur: Dafür müsste das HLR eben Cloud-Computing sein. Das ist es mit Sicherheit nicht.

-Tino, 2009-04-24