Die Datenautobahn transportiert längst nicht mehr nur wissen- schaftliche Texte und Daten, wie in der Frühzeit des Internet, oder die Fülle mehr oder weniger unverbindlicher Bilder und Texte, die man im World Wide Web (WWW) vorfindet. Mehr und mehr Unternehmen, vom Computerhersteller bis zum Verlag, gewinnen an Zeit und Produktivität, indem sie kommerziell bedeutende oder zeitkritische Informationen über das Netz übertragen – häufig mit denselben oder ähnlichen Protokollen, wie sie auch im WWW gängig sind.

Doch je abhängiger die Gesellschaft dadurch von der neuen Technologie wird, desto mehr bekommt sie auch ihre Schwächen zu spüren. Das gilt insbesondere für Systeme, in denen nicht nur schlichte Daten ausgetauscht werden, sondern Ein- und Ausgabe, ausführende Programme und Daten auf verschiedene Computer und Terminals in einem ausgedehnten Netz verteilt sind.

Jeder Computernutzer weiß, daß über das Netz arbeitende Programme noch fehleranfälliger sind als ohnehin. Leslie B. Lamport, ein Pionier auf diesem Gebiet beim Computerhersteller Digital Equipment Corporation, definierte gar ein solches Netz als "ein System, in dem der Ausfall eines Computers, von dessen Existenz man nicht einmal wußte, den eigenen unbrauchbar machen kann". Das gilt auch für das World Wide Web (Kasten Seite 81): Immer wieder kommt es zu Beinahe-Ausfällen, während deren die Kommunikation über das Internet fast unmöglich ist. Eine Vielzahl möglicher Ursachen wird genannt: fehlerhafte Programme, überlastete Datenleitungen sowie Überlastung oder Ausfall von Web-Servern, jenen Rechnern, welche die Web-Dokumente zum Abruf bereithalten.

Höchstwahrscheinlich müssen mehrere dieser Faktoren zusammenkommen, um einen weitreichenden Ausfall herbeizuführen. Nur werden sich derartige Ereignisse häufen, wenn nicht nur das World Wide Web, sondern auch begrenzte Netze für Banken, Schulen und eine Vielzahl von Firmen, die sogenannten Intranets, immer größere Dimensionen annehmen.

In günstigen Fällen kostet ein Computerausfall nicht mehr als die Zeit und die Nerven der Benutzer. Wenn ein Geldautomat defekt ist, findet man meistens in der Nähe einen anderen, der funktioniert. Der Zusammenbruch eines hochkomplizierten Computersystems jedoch kann schlimme Folgen haben. Am 15. Juli 1994 eröffnete die amerikanische Computerbörse NASDAQ mit zwei Stunden Verspätung, weil ein mysteriöser Fehler das ganze System lahmlegte. Man vermutete zunächst einen Programmfehler; später stellte sich heraus, daß eine defekte Festplatte die Ursache war. Wegen der kurzen Ausfallzeit hielten sich die Folgen in erträglichen Grenzen; aber eine langfristige Unterbrechung des Handels hätte katastrophale Verluste verursacht. Eine Störung im Netzrechner verursachte am 21. Juli dieses Jahres eine ähnliche Verzögerung an der Frankfurter Computerbörse.

Im Januar 1990 fiel bei der amerikanischen Telephongesellschaft AT&T eine elektronische Vermittlungsstelle aus. Alle Gespräche wurden zunächst automatisch über eine Reservestelle geleitet, jedoch versagte auch diese aufgrund eines Softwarefehlers. Der Fehler löste eine Lawine im gesamten Telephonnetz aus; neun Stunden lang konnten keine Ferngespräche geführt werden, und 60000 Anschlüsse waren gänzlich ohne Telephonverbindung. Wer je ein Netzwerk verwaltet hat, und seien es ein paar Computer in einer kleinen Firma, wird sich über solche Ausfälle nicht wundern – viel eher darüber, daß sie nicht häufiger vorkommen.


Die Konstruktion zuverlässiger elektronischer Brücken

Kritisch werden Ausfälle – selbst kurze – in Systemen, wo es auf sekundenaktuelle, korrekte und zuverlässig verfügbare Information ankommt (Bild 1). Veraltete Positionsdaten in einem System zur Luftverkehrskontrolle können einen Flugzeugabsturz verursachen, der Ausfall eines Netzcomputers für den internationalen Handel immerhin – unter ungünstigen Umständen – eine Bank ruinieren. Aber die jüngsten Veränderungen in Lebens- und Arbeitsstil der Menschen laufen darauf hinaus, daß die Sicherheit und Stabilität ihrer Geldanlagen, ihres Eigentums, ja selbst ihrer Gesundheit zunehmend von verteilten Computersystemen abhängen. Bei allem Lobpreis über die Segnungen der Datenautobahn ist es deshalb dringend geboten, die Autobahnbrücken sorgfältig zu inspizieren. Seit dem Ende der siebziger Jahre arbeiten zahlreiche Informatiker – darunter wir – an der Entwicklung robuster, das heißt sicherer und zuverlässiger nichtlokaler Computersysteme.

Warum stürzt ein solches System ab? Wenn wir von schlichten Konstruktions- oder Instandhaltungsfehlern absehen, stellt sich heraus, daß in den meisten Fällen ein einzelner, isolierter Defekt in einem Knotenrechner eine Kettenreaktion auslöst, in deren Verlauf ein Netzwerkprogramm nach dem anderen den Dienst versagt. Eine mögliche Lösung wäre, die einzelnen Komponenten robuster zu machen, etwa durch verstärkte Verwendung fehlertoleranter Computer und Speichermedien. Aber gewisse Fehlerquellen bleiben unbeherrschbar: Wasser tropft durch die Decke und verursacht einen Kurzschluß, die Spannung im Elektrizitätsnetz schwankt, ein Systembediener schaltet aus Versehen oder auch aus Rache für erlittenes Unrecht ein entscheidendes Gerät aus, ein krimineller Hacker oder ein Spaßvogel manipuliert von außen die Software. Der vollkommen zuverlässige Computer bleibt ein unerreichbares Ziel.

Aber selbst wenn man ihn hätte, wäre ein verteiltes System aus solchen Komponenten immer noch nicht robust, sondern würde allenfalls unter den meisten Bedingungen gut funktionieren. Die Hard- und Software-Komponenten, aus denen das Internet besteht, sind für sich genommen schon sehr zuverlässig. Gleichwohl verfallen die Programme für elektronische Post, Schwarze Bretter (bulletin boards) und das World Wide Web häufig in einen Starrezustand, wenn eine einzelne Systemkomponente in eine unvorhergesehene Situation wie beispielsweise eine Überlastung gerät. Also sind ergänzende Schutzmaßnahmen geboten.

Seit ungefähr zwanzig Jahren arbeiten die Software-Entwickler zu diesem Zweck an fehlertoleranter Software. Derartige Programme bewältigen auch Probleme wie den Ausfall eines Kommunikationspartners. Die Kette versagt also nicht mehr dadurch, daß ein einzelnes Glied reißt. Vielmehr nutzt das Programm die Tatsache, daß es sich in einem Netz mit vielen Maschen befindet: Anstatt seinerseits den Dienst aufzugeben, sucht es einen neuen Kommunikationsweg an dem ausgefallenen Gerät vorbei. Dadurch bleibt das Gesamtsystem funktionsbereit.

Rettung durch das Reservesystem

Systeme dieser Art werden als hochverfügbar bezeichnet. In der Regel kopiert in einem solchen System jeder beteiligte Computer kritische Daten jedesmal, wenn sie sich ändern, und verteilt die Kopien an seinesgleichen im Netz. Damit kann das Gesamtsystem auf einen Ausfall reagieren, indem es die entscheidenden Daten oder Programme einfach durch eine Sicherheitskopie von anderer Stelle ersetzt – zumindest solange ihm genug Zeit bis zur nächsten Störung bleibt. Im Idealfall bedient es alle zugeschalteten Nutzer ohne merkliche Verzögerung weiter.

Die einfachste und beliebteste Form des hochverfügbaren Netzes enthält ein Paar aus Primär- und Reserveserver. Wenn der eine Computer ausfällt, übernimmt der andere seine Arbeit. Dieser Übergang wäre einfach, wenn sich die Daten nie verändern würden. In einem ausgedehnten Netz von Servern, Dateien und Programmen kann jedoch gerade das permanente Kopieren die Störungen verursachen, die es vermeiden soll. Es ist nämlich zuweilen schwierig, zwischen einem ausgefallenen und einem nur sehr beschäftigten System zu unterscheiden.

Nehmen wir an, ein Computer im Netz versucht, Informationen sowohl im Primär- als auch im Reserveserver zu aktualisieren, bekommt aber von einem der beiden keine Empfangsbestätigung. Soll er warten oder weitermachen? Ist nur die Leitung überlastet, wird die Nachricht früher oder später ankommen. Ist der Server aber wirklich ausgefallen, so wartet der datenliefernde Computer vergeblich, und das System ist nicht verfügbar – auf unbestimmte Zeit. Wenn er aber nicht auf vollständiger Datenübertragung besteht, sind die beiden Server nicht mehr auf dem gleichen Stand, und wer den falschen fragt, bekommt veraltete Informationen.

Eine mögliche Lösung wird von der NASDAQ praktiziert. Das Netz enthält zwei zentrale Server, über die der gesamte Handel abläuft. Um Verwirrung zu vermeiden, ist stets nur einer von ihnen aktiv, und die Systemverwalter entscheiden selbst, wann sie auf den anderen umschalten. Leider können nur wenige Netze sich die permanente Überwachung durch einen menschlichen Bediener leisten; deswegen gilt es, diesen Prozeß zu automatisieren – mit dem Ziel eines nahtlosen Übergangs.

Hochverfügbare Netze enthalten oftmals eine große Anzahl von Servern und Programmen. Deswegen führen sie gewöhnlich eine Art Mitgliederliste, die zu jedem Programm verzeichnet, ob es aktiv ist oder nicht. Wenn eines von ihnen aus irgendeinem Grund nicht reagiert, wird es als fehlerhaft markiert. Daraufhin verteilt das System die Arbeit auf die verbleibenden, funktionierenden Teile des Netzes.

Der NASDAQ-Störfall zeigt ein weiteres Problem auf. Die zweistündige Verzögerung im Jahre 1994 hätte vermieden werden können, wenn die Systemverwalter sofort auf das Reservesystem umgeschaltet hätten. Diese fürchteten jedoch einen Softwarefehler und beschlossen zu warten, damit nicht derselbe Fehler – wie damals bei AT&T – auch das Ersatzsystem lahmlegte. Weil es keinerlei Garantie für vollkommen fehlerfreie Software gibt, braucht man einen Schutzmechanismus gegen solche Kettenreaktionen.

Eine Lösung ist die aktive Replikation. Dabei faßt die Systemsoftware eines Netzes die Kopien eines funktionsentscheidenden Programms oder Datenvorrats, die sie auf den einzelnen Rechnern ablegt, zu einer Art Unterabteilung (process group) zusammen, deren Mitglieder besonders eng zusammenarbeiten. Ein verteiltes System kann zahlreiche Abteilungen enthalten, und ein Programm darf mehreren Abteilungen zugleich angehören. Wie eine Datei bekommt jede Abteilung einen Namen; sie führt eine eigene Liste ihrer aktiven Mitglieder.

Der entscheidende Punkt jedoch ist die Verwaltung von außen eingehender Nachrichten. Ein spezielles Übermittlungsprogramm stellt sicher, daß jedes Mitglied der Abteilung alle Nachrichten in der gleichen Reihenfolge erhält, selbst wenn ein Absender während der Übertragung ausfällt.

Wenn also die Daten, die von einem bestimmten Programm verwaltet werden, zu aktualisieren sind, schickt das System eine Nachricht nicht an das Programm, sondern an die Abteilung, die aus allen Kopien dieses Programms besteht. Jedes Mitglied bringt daraufhin seine eigenen Daten auf den neuesten Stand. Da alle Programme die gleichen Aktualisierungen in der gleichen Reihenfolge durchführen, stimmen ihre Daten stets überein.

Durch aktive Replikation ist also jedes Mitglied in der Lage, jedes andere im Falle einer Störung zu vertreten. Wenn eine Anforderung – beispielsweise eine schlichte Anfrage – alle Daten unverändert läßt, kann ein Rechner sie sogar bedienen, ohne mit den anderen zu kommunizieren – eine Form der Parallelverarbeitung mit dem entsprechenden Leistungszuwachs.

Wenn allerdings alle Mitglieder einer Abteilung auf eine eingehende Nachricht in der gleichen fehlerhaften Weise reagieren, brechen sie auch alle zugleich zusammen. Es stellt sich jedoch heraus, daß dieses theoretisch zweifellos mögliche Totalversagen in der Praxis nicht vorkommt. Fehler dieser Art fallen offensichtlich bereits im frühen Teststadium auf. Heimtückischer sind dagegen solche, die nur dann auftreten, wenn externe Signale zu ungünstigen Zeitpunkten oder in extrem ungewöhnlicher Reihenfolge eintreffen. Dagegen hilft die aktive Replikation durch das Erzwingen der jeweils gleichen Reihenfolge.

Andererseits ist dieses aufwendige Verfahren nur für die relativ wenigen Anforderungen erforderlich, die das Verändern programmeigener Daten verlangen. Den größten Teil der Zeit arbeiten die verschiedenen Exemplare eines Programms unabhängig voneinander, und bei jedem ist die Reihenfolge der Anfragen eine andere. Selbst wenn also beim Testen des Programms einer der genannten reihenfolgeabhängigen Fehler unbemerkt geblieben sein sollte, ist es sehr unwahrscheinlich, daß er alle Mitglieder einer bestimmten Abteilung auf einmal trifft.

Die Idee der aktiven Replikation ist einfach, die zugehörige Software jedoch keineswegs. Es ist schwierig, Mitgliederlisten ständig aktuell zu halten und überall sozusagen die Rednerliste einzuhalten, wenn man immer damit rechnen muß, daß ein Gesprächspartner plötzlich verstummt oder nicht mehr zuhört. Verteilte Rechnernetze sind in den letzten zehn Jahren allgegenwärtig geworden; aber die aktive Replikation ist erst seit kurzem über das Laborstadium hinaus.


Werkzeugkästen für robuste Netze

In den letzten Jahren sind mehr als ein Dutzend Programmpakete für robuste Netze entwickelt worden. Alle bieten hohe Verfügbarkeit durch aktive Replikation; manche sind mehr auf Geschwindigkeit, andere auf Sicherheit optimiert.

Aus unserer Forschungsarbeit an der Cornell-Universität in Ithaca (New York) sind zwei solcher Pakete entstanden. Eine Gruppe unter Leitung eines von uns (Birman) stellte 1987 Isis vor; wir beide haben gemeinsam an Horus gearbeitet, das 1994 eingeführt wurde. Die Namen spielen auf die ägyptische Mythologie an: Die Göttin Isis erweckte den Gott Osiris wieder zum Leben, nachdem der Kriegsgott Seth ihn in einer Schlacht in Stücke gehauen hatte; Horus, der Sohn der Isis, errang schließlich den Sieg über Seth. So wie die antike Göttin ihren Gemahl kann das Programm Isis durch sorgfältiges Aufsammeln der Einzelteile ein gestörtes Computernetz wieder zum Leben erwecken.

Dazu verwenden dieses und andere Programmpakete sogenannte Werkzeuge, Unterprogramme, die auf einzelne Aufgaben spezialisiert sind: Daten kopieren und aktualisieren sowie über Unterabteilungen und Mitgliederlisten Buch führen. Außerdem kann Isis die Arbeit unter den Servern umverteilen (load sharing). Ohne spezielle Hardware zu benötigen, bietet das System damit einige Vorzüge der parallelen Datenverarbeitung: Umfangreiche Aufgaben werden durch Verteilung auf mehrere Server schneller bewältigt, und wenn man bei sehr hoher Belastung einen weiteren Server zuschaltet, bemerkt Isis das quasi von selbst und beschäftigt die neue Kraft ohne weiteren Programmieraufwand gleich mit. Das erregt häufig Erstaunen unter den Fachleuten, weil es der verbreiteten Vorstellung widerspricht, man müsse für die größere Robustheit stets mit einer Einbuße an Leistung bezahlen.

Aktive Replikation wird unter anderem in mehreren Telekommunikationsnetzen, Aktienbörsen, Banken und Maklerbüros eingesetzt. In Norwegen ist ein Umweltüberwachungssystem mit dieser Technologie entwickelt worden (Bild 2). Die französische Flugsicherungsbehörde erkundet den Einsatz der Technik in einer neuen Generation ihrer Software. Schließlich nutzen industrielle Hersteller das load sharing, um die Maschinenbelegung umzuorganisieren, während einzelne Maschinen gewartet werden.

Allerdings hat die aktive Replikation ihre Grenzen. Load sharing ist nicht immer möglich oder sinnvoll; vor allem Systeme, deren Daten sich rasch und häufig verändern, werden durch das viele Kopieren merklich langsamer. Bei einer Videokonferenz mit vielen Beteiligten kann die aktive Replikation die Veranstaltung gegen den Ausfall eines Teilnehmers absichern; wenn es dagegen um die Übermittlung von Videodaten an einen einzigen fernen Empfänger geht, kostet die Methode nur Zeit, ohne Zuverlässigkeit zu bringen.

Der Bedarf an höherer Flexibilität motivierte die Entwicklung von Horus. Dieses Programmpaket arbeitet wie Isis mit aktiver Replikation, ist aber weitaus vielseitiger. Es ist modular – nach dem Baukastenprinzip – aufgebaut. Beispielsweise schützt ein Bauklotz durch Datenverschlüsselung das System vor Hackern; ein anderer wird immer dann aktiv, wenn eine Nachricht verlorengeht oder verstümmelt wird. Alle Bauklötze sind miteinander kombinierbar, so daß der Benutzer das System für seine Zwecke maßschneidern kann. Außerdem ist das System offen für neue Komponenten, für die in der Zukunft ein Bedarf auftreten mag.

Mittlerweile ist Horus weltweit im Einsatz, mit zunehmender Tendenz. Brian C. Smith von der Cornell-Universität hat auf seiner Grundlage ein Videokonferenzsystem zur firmeninternen Kommunikation entwickelt. Eine Weiterentwicklung von Horus namens Ensemble befindet sich in der Testphase. Weitere Informationen sind über http://www. cs.cornell.edu/Info/Projects/HORUS/ abrufbar.

Können wir nicht oder wollen wir nicht?

Unsere Arbeit an Isis und Horus hat uns überzeugt, daß Zuverlässigkeit von Computernetzen kein unerreichbares Ziel ist. Es ist nur unklar, ob Computerhersteller und Nutzer bereit sind, dafür ausreichend Zeit und Geld zu investieren. Netzsoftware wird typischerweise mit den bestehenden Verfahren entwickelt, die nicht in erster Linie auf Verläßlichkeit ausgelegt sind.

Ein weiteres Problem ist die Übertragung auf viel größere Systeme. Ein Netz, das 50 Nutzer extrem robust und einwandfrei bedient, könnte sich bei 5000 Nutzern als kläglich langsam und deswegen mangelhaft verfügbar herausstellen.

Schlagzeilen macht nicht das Funktionieren erfolgreich installierter robuster Systeme, sondern das Versagen der anderen. So wurde während der letzten Jahre dutzendfach über die gegenwärtigen Mängel der amerikanischen Flugsicherung berichtet. Als im Herbst 1995 das System in Los Angeles ausfiel und die Kommunikation zwischen Fluglotsen und Piloten abbrach, entgingen zwei Flugzeuge nur um Sekunden einem Zusammenstoß in der Luft.

Schlimmer noch: Die amerikanische Bundesluftfahrtbehörde FAA hatte zwar schon 1982 eine verbesserte Flugsicherungs-Software bestellt; aber es gelang dem Anbieter nicht, die Anforderungen zu erfüllen, so daß die FAA die Vorgaben mehrfach zurücknehmen mußte und trotzdem nicht fristgerecht beliefert wurde. Sie hatte sich für das ursprüngliche Angebot entschieden, weil es die Probleme verteilter Rechnersysteme in innovativer Weise zu bewältigen versprach. Inzwischen scheinen fast alle Eigenschaften, die auf hohe Verfügbarkeit hinauslaufen, aus dem Forderungskatalog verschwunden zu sein. Derweil kritisieren die Fluglotsen immer heftiger das bestehende System als gefährlich ungeeignet, vor allem weil es nicht für den Netzbetrieb taugt und mit dem Alter unzuverlässig geworden ist.

Die hohe Publizität solcher und ähnlicher großer Pannen hat in der Öffentlichkeit die Vorstellung entstehen lassen, es sei quasi schicksalhaft eine große Software-Krise hereingebrochen (Spektrum der Wissenschaft, Dezember 1994, Seite 54). Aber wenn es wirklich eine Krise ist, dann liegt sie mindestens so sehr am Nicht-Wollen wie am Nicht-Können. Nicht alle Entwickler kümmern sich darum, ob ihre Netzwerksoftware robust ist, und der öffentliche Druck erstreckt sich anscheinend nur auf einige besonders sensible Anwendungsbereiche. Hersteller von Netzwerksoftware weisen in den Lizenzverträgen gar darauf hin, daß ihr Produkt für kritische Anwendungen möglicherweise nicht zuverlässig genug ist, und behaupten damit stillschweigend, daß dieses Ziel ohnehin nicht mit angemessenem Aufwand erreichbar sei. Das ist ungefähr so, als würde ein Autohersteller in den Verkaufsprospekt schreiben, seine Fahrzeuge seien für den Verkehr auf Landstraßen nicht sicher genug. Software wird quasi nur ausnahmsweise mit Sicherheitsgurten und Airbags geliefert, und sowohl für die Entwickler als auch für die Nutzer scheinen höhere Leistung und eine benutzerfreundliche Oberfläche viel wichtiger zu sein.

Bei dem Begriff Zuverlässigkeit denken viele an zeitraubende, schwerfällige Kontrollen – unvereinbar mit der Vorstellung von der freien Fahrt auf der Datenautobahn. Aber Robustheit und Leistungsfähigkeit sind keine Widersprüche; die Golden Gate Bridge ist auch schlank und stabil zugleich.

Von Stunde zu Stunde finden sich mehr Nutzer für die Autobahnbrücken des Internet. Unsere Begeisterung für die Konstruktion eleganter elektronischer Brücken muß jedoch einer gewissen Besorgnis Raum lassen, ob diese den wachsenden Datenverkehr auch tragen können. Wir sind überzeugt von den Segnungen robuster verteilter Rechnersysteme. Aber wir sind auch überzeugt, daß man ein Computernetz, das man nicht mit der erforderlichen Zuverlässigkeit auszustatten vermag, besser gar nicht erst bauen sollte.

Literaturhinweise

- Fault Tolerance in Tandem Computer Systems. Von Jim Gray, Joel Bartlett und Robert W. Horst in: The Evolution of Fault-Tolerant Computing. Herausgegeben von A. Avizienis, H. Kopetz und J. C. Laprie. Springer, 1987.

– Fatal Defect: Chasing Killer Computer Bugs. Von Ivars Peterson. Random House, 1995.

– Group Communication. Sonderteil von Communications of the ACM, Band 39, Heft 4, Seiten 50 bis 97, April 1996

Kasten: Das verhedderte Netz

Der größte Teil des World Wide Web ist unsichtbar. Für viele Nutzer scheint es nur aus zwei Komponenten zu bestehen, nämlich einer Benutzeroberfläche, dem sogenannten Browser, und den fernen Servern, Computern, auf denen die anzufordernden Dokumente gespeichert sind. Aber das Web und seine Kommunikationsbasis, das Internet, enthält außerdem Millionen zusätzlicher Programme und Server; an der Beschaffung eines einzelnen Dokumentes sind jeweils Dutzende von ihnen beteiligt. Damit ein Benutzer etwa die WWW-Seite dieser Zeitschrift sieht, muß der Name "www.spektrum. de" in eine Zahlenfolge umgewandelt werden, und zwar möglicherweise über mehrere Teilschritte, die jeder von einem anderen Vermittlungsprogramm erledigt werden. Dann wird die Anforderung aber immer noch nicht zum Adressaten durchgestellt; vielmehr durchläuft sie typischerweise eine Reihe von Proxies. Diese Programme laufen auf Servern in räumlicher Nähe des Anfordernden; sie halten eine Anzahl häufig angeforderter Dokumente ständig bereit, können deshalb manche gängige Anfrage aus dem eigenen Speicher bedienen und ersparen so dem Nutzer einen langwierigen Datentransfer über das Internet.



Praktisch alle verteilten Rechnersysteme sind von solchen im verborgenen arbeitenden Vermittlerprogrammen abhängig; und genau diese sind häufig Ursache von Defekten. Wenn das Adreßkonversionsprogramm nicht funktioniert, ein Proxy versagt oder ein Web-Server abstürzt, bleibt die ursprüngliche Anforderung stecken. Die geläufige Fehlermeldung (Bild), es sei der Web-Server, der außer Betrieb oder überlastet sei, ist also irreführend: Es kann ebensogut jedes Zwischenglied in der langen Kette sein.



Das Internet ist so konzipiert, daß ein Totalausfall (blackout) äußerst unwahrscheinlich ist. Wenn ein Knoten oder ein Verbindungsteilstück ausfällt, bleiben normalerweise noch genug Wege vom Sender zum Empfänger übrig. Aber so dezentral, wie es sein sollte, ist das Netz nicht. Es gibt zwar viele Adreßverzeichnisse (name servers), aber nur relativ wenige Verzeichnisse für Adreßverzeichnisse (root name servers). Wenn eines von ihnen ausfällt, gibt es Störungen (brown-outs), die einem Totalausfall zumindest nahekommen. Im Jahre 1995 wurde ein größeres Internet-Adreßverzeichnis in Atlanta wiederholt kurzzeitig überlastet. Während dieser Perioden konnte niemand in der Welt auf Web-Dokumente zugreifen, deren Server dem lokalen System noch nicht bekannt waren. Im Juli dieses Jahres setzte eine Software-Panne für einige Stunden sämtliche root name servers außer Gefecht.



Doch selbst wenn eine Verbindung zustande kommt, können Fehler auftreten. Web-Dokumente werden häufig aktualisiert, aber die von den Proxies gespeicherten Kopien werden nicht automatisch nachgebessert; dadurch bekommt ein Benutzer zuweilen veraltete Daten zu sehen. Für den größten Teil der Web-Dokumente ist das unproblematisch – aber es gibt wichtige Ausnahmen. Proxies erhöhen die Zuverlässigkeit des Internets, indem sie die Belastung durch Datenströme mildern, allerdings um den Preis, daß die Zuverlässigkeit der gelieferten Dokumente verringert ist.



Einige Projekte im Web oder anderen nichtlokalen Computersystemen erfordern bessere Garantien, daß die vom System gelieferte Information stets korrekt, aktuell und ständig verfügbar ist. Ein Weg zu diesem Ziel ist die im Text beschriebene aktive Replikation.


Aus: Spektrum der Wissenschaft 9 / 1997, Seite 76
© Spektrum der Wissenschaft Verlagsgesellschaft mbH