TU Wien | ZID | ZIDline 8 | Ausfallsicherheit und Redundanz im TUNET

Ausfallsicherheit und Redundanz im TUNET

Johannes Demel

    1. Einleitung
    2. Grundbegriffe
    3. Der Weg zwischen zwei Rechnern an der TU Wien
    4. Der Weg ins Internet
    5. Maßnahmen bei Servern
    6. Telefonie
    7. Management
    8. Literatur

Das Datennetz der Technischen Universität Wien versorgt derzeit ca. 9000 Endsysteme. Im Tagesschnitt werden von den Mailbastionsrechnern ca. 22000 Mails weitergeleitet, ca. 45000 Mails werden pro Tag auf den zentralen Mailservern auf Viren überprüft. Allein schon aus diesen wenigen Zahlen ist die Bedeutung des Datennetzes für den Betrieb unserer Universität ersichtlich. Die Datenkommunikation und der Zugriff auf Ressourcen im Internet bzw. das Anbieten von Ressourcen im Internet ist aus dem heutigen Leben nicht mehr wegzudenken.

1. Einleitung

Damit die Arbeitsplätze an den Instituten und für Studierende entsprechend versorgt werden, sind derzeit ca. 800 km Kupferkabel (Kabel direkt zum Arbeitsplatz) und ca. 40 km Glasfaserstrecken (im Gebäude und zwischen Gebäuden) erforderlich. Alle diese Kabel werden mit ca. 800 Geräten (von einfachen Repeatern über Switche bis zu komplexen Routern) verbunden. Diese Zahlen lassen schon erahnen, dass das Datennetz der TU Wien bereits ein hochkomplexes Gebilde geworden ist, das es nicht nur gilt, in Betrieb zu halten, sondern auch laufend an neue Anforderungen anzupassen.

Seit einigen Jahren ist daher die Verbesserung der Betriebssicherheit ein wesentlicher Schwerpunkt bei den Erweiterungen im TUNET inklusive der zum TUNET dazugehörigen Server. Anzumerken ist, dass schon alleine die Aufrechterhaltung der gleichen subjektiven Betriebssicherheit große Anstrengungen und Investitionen erfordert.

Alle hier diskutierten Maßnahmen beziehen sich nur auf das IP-Protokoll. Bei eventuell verwendeten anderen Protokollen können ein Teil der Maßnahmen auch greifen, von der Struktur des TUNET wird jedoch die Ausfallsicherheit nur für IP (v4) unterstützt.

2. Grundbegriffe

Bevor wir uns konkret dem TUNET zuwenden, sollen einige Grundbegriffe in Erinnerung gerufen werden:

Ausfallwahrscheinlichkeit

Zur Beurteilung der Wahrscheinlichkeit, dass ein Gesamtsystem funktioniert, sagt uns die Theorie der Wahrscheinlichkeitsrechnung, dass dies das Produkt der Funktionswahrscheinlichkeiten der einzelnen Komponenten ist. Leider sind die Wahrscheinlichkeiten (hoffentlich nur minimal) kleiner als 1, damit ist aber das Produkt dann deutlich kleiner als 1.

Wenn man bedenkt, dass im günstigen Fall und vereinfacht zur Kommunikation von zwei Rechnern in zwei verschiedenen Standorten der TU Wien 4 Glasfaser- strecken, 2 Kupferstrecken, 12 Patchkabel, 2 Switches, 3 Backbone Switche/Router, ein Nameserver (der in einem anderen Gebäude steht und damit wieder 1 Kupfer- strecke, 2 Glasfaserstrecken und 6 Patchkabel sowie 2 Switche benötigt) sowie insgesamt 8 230V Stromanschlüsse erforderlich sind, so kommt man unter Vernachlässigung von Komponenten wie Klima auf insgesamt 43 Komponenten.

Wenn nun vereinfacht jede Komponente eine Ausfallwahrscheinlichkeit von 0,1% hätte, so ergibt dies für den gesamten Kommunikationsweg eine Ausfallwahrscheinlichkeit von 4,2%, dies wäre im Schnitt an einem Tag im Monat eine Störung (wie lange dann immer die Fehlerbehebung dauert). Zum Glück sind die Ausfallwahrscheinlichkeiten deutlich geringer, aber bei einem derart großen und komplexen System wie dem TUNET fragt man sich trotzdem manchmal, wieso alles funktioniert (die meiste Zeit sind aber eh irgendwelche Störungen zu beheben und wir kommen auf diese Gedanken gar nicht).

Wichtige Größen zur Beurteilung der Betriebssicherheit sind auch MTBF (Mean Time Between Failure) und MTTR (Mean Time to Repair).

Betriebsfehler

Unter Betriebsfehlern versteht man ganz einfach Fehler, die im laufenden Betrieb eines Systems auftreten, egal ob sie vorhersehbar sind oder nicht, egal ob sie aufgrund äußerer Einwirkung entstehen oder aufgrund von Verschleiß. Folgende Tabelle soll einen anschaulichen Überblick bieten:

zufällige, physikalische Fehler
Verschleißfehler, z.B. durch alterung elektrischer Bauteile
Störungsbedingte Fehler aufgrund äußerer physikalischer Einflüsse, z.B. Stromausfall, Wassereinbruch
Bedienungsfehler
Wartungsfehler: fehlerhafte Systemeingriffe während Wartungsintervall
Sabotage, Vandalismus
Umbaumaßnahmen

Neben den eigentlichen Betriebsfehlern gibt es noch die geplanten Unterbrechungen, z.B. infolge von Erweiterungen und Umbauten, Überprüfungen (z.B. der Stromversorgung, Test der Redundanzmaßnahmen, Reproduzieren von Fehlern).

Fehlertoleranz

Fehlertoleranz ist die Fähigkeit eines Systems, auch mit einer begrenzten Zahl fehlerhafter Subsysteme seine spezifizierte Funktion zu erfüllen. Das Verhalten des Systems nach Auftreten von Fehlern kann folgendermaßen klassifiziert werden:

Typ Verhalten des Systems
(go) System arbeitet sicher und korrekt
(fail-operational) System fehlertolerant ohne Leistungsverminderung
(fail-soft) Systembetrieb sicher, aber Leistung vermindert
(fail-safe) Nur Systemsicherheit gewährleistet
(fail-unsafe) unvorhersehbares Systemverhalten

Bei der Korrektur von Fehlern unterscheidet man die zwei Prinzipien der Vorwärts- und der Rückwärtsfehlerkorrektur. Bei der Vorwärtsfehlerkorrektur versucht das System, so weiterzumachen als ob kein Fehler aufgetreten wäre, indem es z. B. im Moment des Auftretens eines Fehlers sofort mit korrekt funktionierenden Ersatz- systemen weiterarbeitet. Fehler bleiben bei der Vorwärtsfehlerkorrektur normalerweise unsichtbar für Anwender. Bei der Rückwärtsfehlerkorrektur versucht das System bei Auftreten eines Fehlers in einen Zustand vor diesem Auftreten zurückzukehren, z. B. in den Zustand direkt vor einer fehlerhaften Berechnung, um diese Berechnung erneut auszuführen. Genauso ist aber auch ein Zustandswechsel in einen Notbetrieb oder z. B. ein Reboot des Systems möglich. Kann eine fehlerhafte Berechnung erfolgreich wiederholt werden, bleibt auch bei der Rück- wärtsfehlerkorrektur der Fehler für den Anwender unsichtbar. Oft ist aber nur ein Weiterbetrieb mit Leistungseinbußen oder eingeschränkter Funktionalität möglich und der Fehler somit sichtbar.

Fehlerredundanz

Das häufigste Konzept, um Systeme gegenüber Betriebsfehlern tolerant zu machen, ist die Fehlerredundanz, das ist das Vorhandensein von mehr als für die Ausführung der vorgesehenen Aufgaben an sich notwendigen Mittel (nach DIN 40041, Teil 4).

Man unterscheidet dabei verschiedene Stufen der Redundanz.

Aktive-Redundanz (funktionsbeteiligte, heiße Redundanz) Mehrere Komponenten eines Systems führen dieselbe Funktion simultan aus. Fällt eine Komponente aus, wird dieser Fehler durch die verbleibenden Komponenten direkt kompensiert und führt daher nicht unmittelbar zu einer von außen erkennbaren Reaktion. Normalerweise erfolgt dann zwischen allen aktiven  Systemen eine Lastaufteilung.
Standby-Redundanz (passive Redundanz) Zusätzliche Mittel sind eingeschaltet/bereitgestellt, werden aber erst bei Ausfall/Störung an der Ausführung der vorgesehenen Aufgabe beteiligt.
Kalte Redundanz Zusätzliche Mittel werden erst bei Ausfall/Störung eingeschaltet/bereitgestellt.

Im Bereich der Vernetzung können die getroffenen Maßnahmen zusätzlich wie folgt klassifiziert werden:

Geräteredundanz Für eine Funktion gibt es mindestens zwei voneinander unabhängige (wie genau das erreichbar ist, hängt von der jeweiligen Funktion ab) Systeme, die diese Funktion erbringen.
Wegeredundanz Für eine Verbindung zwischen zwei Systemen gibt es mindestens zwei voneinander unabhängige Wege.
Raumredundanz Die Funktion kann in zwei verschiedenen Räumen eines Gebäudes erbracht werden.
Gebäuderedundanz Die Funktion kann in zwei verschiedenen Gebäuden der TU Wien erbracht werden.

3. Der Weg zwischen zwei Rechnern an der TU Wien

Zur Darstellung der Maßnahmen zur Verbesserung der Ausfallsicherheit bei der Kommunikation zwischen zwei Rechnern soll in diesem Abschnitt der Weg eines Pakets von einem Rechner in einem Gebäude der TU Wien (z.B. Favoritenstraße) und dem POP-Server am ZID dargestellt werden. Es wird dabei davon ausgegangen, dass die beiden Systeme in unterschiedlichen IP-Subnetzen sind und dass damit ein Routing erforderlich ist. Es wird der Einfachheit halber davon ausgegangen, dass die Endrechner schon die Mac-Adresse zur jeweils benötigten IP-Adresse des Default-Gateways wissen und dass daher das ARP Protokoll nicht mehr erforderlich ist. Weiters wird davon ausgegangen, dass der Rechnername bereits auf eine IP-Adresse aufgelöst wurde (d.h. der Nameserver kontaktiert wurde).

von nach via Maßnahme
PC/Ethernetkarte Etagen Switch Port TP-Kabel Keine Ausfallsicherheit durch TUNET möglich. Siehe 3.1
Etagen Switch Gebäude Switch Glasstrecke Pro Gebäude 2 Backbone Switche. Je ein Weg zu jedem Gebäude Switch. Siehe 3.2
Gebäude Switch Gebäude Router Intern oder Glasstrecke Pro Gebäude 2 Backbone Router. Siehe 3.3
Gebäude Router/Switch Core-Router Glasstrecke 2 Core Router auf der TU Wien. Je ein Weg zu jedem Gebäude-Switch. Siehe 3.3
Core Router Gebäude Router/Switch Glasstrecke Pro Gebäude 2 Backbone Router + Switche. Siehe 3.3
Gebäude Router/Switch Etagen Switch Glasstrecke 2 Wege zum Etagen Switch. Siehe 3.2
Etagen Switch POP-Server TP-Kabel Keine Ausfallsicherheit durch TUNET möglich. Siehe 3.1. Server siehe 5.
Nachdem der POP-Server das Paket verarbeitet hat, muss natürlich ein Antwortpaket (zumindest mit der Information, dass das Paket angekommen ist) zurück zum PC geschickt werden. Dies erfolgt logisch gesehen nach obiger Tabelle von unten nach oben. In Wirklichkeit kann das aber über andere Geräte und Kabelwege laufen, da bei - aus Redundanzgründen vorhandenen - mehreren Wegen die Auswahl des konkreten Weges in jede Richtung eine andere sein kann.

Der Ablauf ist auch in folgender Grafik dargestellt:

red-abb1

3.1 Maßnahmen zwischen Rechner und Etagenswitch

Auf dem Weg zwischen Rechner und Etagenswitch können von TUNET aus keine (aktiven) Redundanzmaßnahmen gesetzt werden. Es wären entsprechende Vorkehrungen im Rechner selber bzw. bei der Verbindung zwischen Rechner und TUNET-Steckdose im Raum notwendig. Konkrete Maßnahmen wären daher vom Institut in Absprache mit dem ZID zu treffen. Solche Maßnahmen könnten sein:

Unabhängig von diesem Maßnahmen sieht der TCP/IP Protokoll Stack in der TCP Transportschicht, deren Aufgabe die Sicherstellung einer fehlerfreien Kommunika- tion ist, ein nochmaliges Schicken des Pakets vor, wenn die Bestätigung, dass ein abgeschicktes Paket beim Zielrechner angekommen ist, nicht innerhalb einer gewissen Zeit eintrifft. Dies ist beim UDP-Protokoll (z. B. für Nameserverabfragen) nicht gegeben.

Bei den Etagenswitchen handelt es sich normalerweise um nichtmodulare Geräte mit 24, 48 oder 80 Ports, die nur ein Netzteil haben. Es ist daher eine Stromversorgung mit zwei unabhängigen Stromkreisen nicht möglich. Es wird jedoch (zumindest bei Neuerrichtungen) sichergestellt, dass die Stromversorgung durch eine eigene Absicherung mit FI/LS (kombinierter FI Schutzschalter mit Leistungsschalter) erfolgt und nicht mit Licht, Klima, Staubsaugersteckdosen etc. zusammenhängt. Bei größeren Etagenverteilern wird auch eine eigene USV eingesetzt. Normalerweise ist die Aufrechterhaltung des Betriebes bei Ausfall des Stromes im Etagenverteiler nicht so wichtig, da es sich meistens um Stromausfälle handelt, die auch die Rechner am Institut betreffen (können auf Grund der maximalen TP-Kabellänge von 90 Metern nicht weit entfernt sein).

3.2 Maßnahmen zwischen Etagenswitch und Gebäudeswitch/Router

3.2.1 Physische Maßnahmen

Grundsätzlich sollen an einem Standort bzw. Gebäudekomplex zwei Gebäudeswitche und zwei Gebäuderouter existieren. Dies ist derzeit für die Standorte Freihaus, Favoritenstraße, ZID, Karlsplatz + Resselgasse / Wiedner Hauptstraße 7-9, Getreidemarkt, Gußhausstraße 27-29 der Fall. Die Redundanz für Treitlstraße wird im Zuge der Adaptierung des Perlmooserhauses, die Argentinierstraße im Zuge deren Adaptierung und der Adaptierung Karlsgasse realisiert.

Die Gebäudeswitche / Router sollten in zwei getrennten Räumen aufgestellt sein. Dies ist bei allen Standorten außer Favoritenstraße und ZID der Fall.

In allen Fällen ist der Router im gleichen Gehäuse wie der Switch untergebracht. Je nach verwendetem Modell handelt es sich dabei um eine gemeinsame Switching/Router Engine (ZID, Treitlstraße, Argentinierstraße, Gußhaus, Getreidemarkt) oder im Switch befindet sich ein zusätzliches Routing-Modul. In Falle des eigenen Moduls erfolgt geräteintern dann die Kommunikation über einen Gigabit-Bus. Dies stellt natürlich Kapazitätseinschränkungen dar, gleichzeitig gibt es dadurch aber auch zusätzliche Komponenten, die ausfallen können, und das Management und die Softwareoberfläche (unterschiedliche Betriebssysteme !) wird deutlich komplizierter. Bei manchen Standorten (maximal bei einem Gebäudeswitch pro Standort) gibt es aus Kapazitätsgründen (Anzahl der Ports) für den Switch noch eine Erweiterung mit einem externen Gigabit-Switch.

Die beiden Backboneswitche sind mit einem Gigabit Link verbunden. Damit kann z.B. bei den Geräten mit einem eigenen Routing-Modul bei dessen Ausfall das Routing vom zweiten Router übernommen werden. Ein wichtiges Kriterium ist auch, dass Module im Betrieb getauscht bzw. ein-/ausgebaut werden können.

Ein Etagenswitch soll nun mit beiden Gebäudeswitchen über Gigabit verbunden sein, wobei mindestens eine Verbindung direkt erfolgen soll, die zweite kann auch über einen weiteren Etagenswitch erfolgen.

Die typische Struktur im Gebäude hat daher folgendes Aussehen:

red-abb2

Je nach der notwendigen Portanzahl wird die Realisierung aber unterschiedlich kompliziert, wie einige Musterkonfigurationen für den Standort Gußhaus zeigen:

topologie-1-sw.gif topologie-2-sw.gif topologie-3-sw.gif

3.2.2 Maßnahmen auf Ebene des ISO Link Layer (2)

Der Link Layer hat im Wesentlichen die Aufgabe, Pakete über eine direkte Kabelverbindung von einem Gerät zum anderen zu schicken. Es muss auch sichergestellt werden, dass das Übertragungsmedium nicht belegt ist (Collision Detection). Wenn das Medium nicht frei ist, wird versucht, das Paket verzögert wegzuschicken (Back-off Algorithmus). Die Redundanz bei der Verbindung der Etagenswitche mit dem Gebäudeswitch basiert auf folgenden Techniken: 

Bis auf wenige Ausnahmen sind an den Gebäudeswitchen keine Endgeräte angeschlossen (neben strukturellen Überlegungen wäre dann keine Redundanz auf Routing-Ebene etc. möglich).

Durch den Spanning Tree Algorithmus gibt es aber Einschränkungen, wie viele Switche maximal zwischen zwei Endgeräten verwendet werden dürfen. Dadurch ist die Flexibilität der Zusammenschaltung von Etagen- switchen eingeschränkt.

Das Umschalten auf einen anderen verfügbaren Weg nach einem Ausfall der aktiven Verbindung dauert ca. 60 Sekunden.

3.2.3 Maßnahmen auf Ebene des ISO Network Layers (3)

Zur Kommunikation mit anderen Subnetzen oder dem Internet muss ein Paket an das "Default Gateway", das ist die IP-Adresse des Routers im eigenen Subnetz, geschickt werden (an der TU Wien sind das IP-Adressen, die normalerweise 1 oder 129 im letzten Oktett stehen haben). Nun haben wir aber für jedes Gebäude zwei Router, die jeweils eine eigene IP-Adresse benötigen. Die Schwierigkeit besteht nun darin, dass die Endgeräte (Arbeitsplatzrechner, Server) wissen, an welchen der beiden Router das Paket zu schicken ist. Es gibt zwar ein eigenes Protokoll, ICMP Router Discovery Protocol (IRDP) nach RFC 1256, mit dem Endsysteme feststellen können, welche Router gerade arbeiten. Dies erfordert bei jedem Endsystem eine zusätzliche Software, die für das jeweilige Betriebssystem verfügbar sein muss. Diese Software (üblicherweise ein eigener Dämon) muss dann installiert und gestartet sein, damit alles funktioniert. Weiters müssen alle Router das IRDP Protokoll unterstützen und es muss entsprechend konfiguriert sein. Also relativ viel Aufwand auf allen Seiten. Außerdem dauert die Erkennung, dass ein Router down ist, relativ lange (10-30 Minuten !).

Bei uns wird daher das Cisco-proprietäre Protokoll HSRP (Hot Standby Routing Protocol, RFC 2281) eingesetzt. Das Prinzip ist im Wesentlichen, dass jeder Router auf seinem Interface eine eigene IP-Adresse hat (bei uns in der Regel endend mit 125/126 bzw. 253/254). Diese Adresse wird vom Router beim Abschicken von Paketen verwendet. Zusätzlich wird von einem der beiden Router die "HSRP-Adresse" (z.B. 128.130.x.1) mit einer definierten Mac-Adresse (0000.0c07.ac**) emuliert. Welcher Router der aktive ist, machen sich die beiden Router untereinander auf Basis von Prioritäten in der Konfiguration aus. Wenn ein Router den anderen nicht mehr erreichen kann, so aktiviert er sich selber. Dies geschieht innerhalb ca. 10 Sekunden. Natürlich müssen dann die Etagen- Switche lernen, dass die Mac-Adresse des Default-Gateways jetzt über einen anderen Port erreichbar ist.

Ob das HSRP Protokoll für ein konkretes Subnetz eingesetzt wird, ist für den Benutzer nicht sofort ersichtlich. An Hand der Mac-Adresse des Default Gateways und z.B. durch auf den ersten Blick seltsam anmutende Ergebnisse beim Traceroute Befehl ist es erkennbar.

Es gibt in der Zwischenzeit auch ein Standard Protokoll, das Virtual Router Redundancy Protocol (VRRP) nach RFC 2338, das nach ähnlichen Prinzipien funktioniert, derzeit an der TU Wien im Backbone aber nicht eingesetzt wird.

Durch diese Maßnahmen stellen wir sicher, dass das Default Gateway immer (d.h. zumindest bei einem einfachen Fehler) erreichbar ist. Wenn ein Institut aber hinter einem institutseigenen Firewall liegt, der nicht ebenso redundant ausgeführt ist, bietet diese Redundanz leider nur eine beschränkte Hilfe.

3.3 Maßnahmen im TUNET Backbone

Zum TUNET Backbone im weiteren Sinne gehören alle Gebäude-Switche/Router und die beiden Core Switche/Router. Alle Gebäude-Switche sind mit mindestens einem der beiden Core Switche verbunden.

3.3.1 Physische Maßnahmen

Die Maßnahmen für die Gebäude-Switche/Router wurden bereits unter 3.2.1 besprochen und brauchen daher hier nicht wiederholt werden.

Die beiden Core Switche mit integriertem Routing sind in zwei unterschiedlichen Gebäuden (Freihaus, Gußhaus) aufgestellt. Jeder der beiden Switche verfügt über zwei Netzteile, wobei eines davon über eine USV (Überbrückungszeit je nach Gebäude 30 Minuten bis 8 Stunden) versorgt wird (die im Freihaus im Notfall durch das Notstromaggregat des Hauses versorgt wird). Ein wichtiges Kriterium ist auch, dass Module im Betrieb getauscht bzw. ein-/ausgebaut werden können. Die Räume sind entsprechend klimatisiert und werden auch fernüberwacht (Strom, Temperatur, Feuchte, ...). Die beiden Core Switche sind untereinander mit derzeit einer Glasfaserstrecke verbunden.

Jeder Gebäudeswitch ist mit mindestens einem Core Switch verbunden, wobei jedes Gebäude mit jedem der beiden Core Switche mit einer direkten Glasfaserverbindung verbunden sein muss. Ob ein Gebäude mit 2, 3 oder 4 Verbindungen mit dem Core verfügt, hängt von der jeweiligen geografischen Lage und den verfügbaren Glasfaserwegen zwischen den Gebäuden ab. Für die Glasfaserstrecken werden, je nach Möglichkeit der Trassenführung und der Wegerechte, neben selbst verlegten Kabeln Strecken der Telekom Austria sowie der Memorex Telex Communications AG (MTCAG) eingesetzt. Dabei wird darauf geachtet, dass ein Gebäude möglichst über unterschiedliche Trassen zu den beiden Core Switchen geführt wird.

3.3.2 Maßnahmen auf Ebene des ISO Link Layer (2)

Im Gegensatz zu den Jahren 2001/2002 wurde Anfang 2003 der Backbone dahingehend umgebaut, dass keine Layer 2 Techniken, wie der Spanning Tree Algorithmus, erforderlich sind. Die Glasfaserstrecke zwischen Gebäude-Switch und Core Switch stellt also ein eigenes VLAN dar, das nur zwischen diesen beiden Punkten existiert. Damit fallen die relativ langen Umschaltzeiten des Spanning Tree Protocols (ca. 1-2 Minuten) weg.

Diese Regel gilt naturgemäß nicht für "gebäudeübergreifende" VLANs, die für Institute benötigt werden, die das gleiche IP-Subnetz in mehreren Gebäuden nutzen wollen. Auch für Appletalk, Novell und DECnet trifft dies zu. In diesen Fällen ist also bei einer Störung mit längeren Auswirkungen zu rechnen.

Übrigens konnte die Umstellung von Layer 2 Core auf ein Layer 3 Core infolge der zu diesem Zeitpunkt existierenden redundanten Gebäuderouter ohne Betriebsunterbrechung durchgeführt werden.

An den Core Switches sind keine Endgeräte und auch keine Etagenswitche angeschlossen.

3.3.3 Maßnahmen auf Ebene des ISO Network Layers (3)

Eine wesentliche Voraussetzung zur Nutzung einer redundanten Konfiguration ist die Verwendung eines geeigneten "Routingprotocols". Es nützt ja schließlich nichts, wenn ein redundanter Weg zur Verfügung steht, aber niemand aktiviert ihn. Die primäre Aufgabe eines Routingprotocols ist die Versorgung aller Router mit der Information, über welchen Weg (d.h. Nachbarrouter) ein anderes Subnetz (oder ein IP-Netz im Internet) erreicht werden kann. Jeder Router führt eine eigene Routingtabelle, in der die Subnetze des eigenes Intranets (dem TUNET) enthalten sind, sowie der Weg zu allen anderen Netzen (dem Internet/Extranet) in Form eines "Default-Netzes". Das Halten sämtlicher Netze des Internet in jedem Router des Intranets macht keinen Sinn, da dies eine viel zu große Menge wäre (die Router des ACOnet Backbones haben derzeit ca. 125.000 Netze mit ca. 260.000 verschiedenen Wegen im Speicher !), die nur sehr leistungsstarke (und damit teure) Router bewältigen können.

Das Routingprotocol hat nun einerseits die Aufgabe, mit den Nachbarroutern die vom eigenen Router direkt (connected) oder indirekt erreichbaren Subnetze auszutauschen, als auch, die Routingtabellen aufzubauen bzw. zu aktualisieren. Dabei müssen auch mehrere Wege unter Beachtung von Gewichten und Prioritäten berücksichtigt werden. An der TU Wien wird im Backbone das OSPF Protokoll (Open Shortest Path First) eingesetzt. Dies ist ein Routingprotocol, das hierarchisch basierend auf "Link States" mittels graphentheoretischer Algorithmen in jedem Router eine Sicht des kompletten Intranets errechnet und damit die Routingtabellen aktualisiert.

Wenn zu einem Ziel zwei Wege mit der gleichen Bewertung existieren, so wird automatisch eine Lastaufteilung erzielt. Gleichzeitig steht bei Ausfall eines der beiden Wege sofort ein zweiter Weg zur Verfügung und damit kann die Unterbrechung minimal gehalten werden. Dies ist auch einer der Gründe, warum die Gebäuderouter mit jeweils einem dedizierten Subnetz mit den Core-Routern verbunden sind. Sobald z.B. ein Interface ausgeschaltet wird (geplant oder wegen einer Störung), werden sofort alle Wege, die über dieses Interface gehen, im Router mit diesem Interface aus der Routingtabelle entfernt. Wenn noch eine zweite Route zu einem Ziel existiert hat, kann diese sofort (und jetzt alleinig) verwendet werden, und es findet praktisch keine Unterbrechung statt.

4. Der Weg ins Internet

Zur Darstellung der Maßnahmen zur Verbesserung der Ausfallsicherheit bei der Kommunikation zwischen einem Rechner an der TU Wien und dem Internet soll in diesem Abschnitt der Weg eines Pakets von einem Rechner in einem Gebäude der TU Wien (z. B. Favoritenstraße) bis in das Internet dargestellt werden.

von nach via Maßnahme
PC/Ethernetkarte Etagen Switch Port TP-Kabel Keine Ausfallsicherheit durch TUNET möglich. Siehe 3.1
Etagen Switch Gebäude Switch Glasstrecke Pro Gebäude 2 Backbone Switche. Je ein Weg zu jedem Gebäude Switch. Siehe 3.2
Gebäude Switch Gebäuderouter Intern od. Glasstrecke Pro Gebäude 2 Backbone Router. Siehe 3.3
Gebäude Router/Switch Core-Router Glasstrecke 2 Core Router auf der TU Wien. Je ein Weg zu jedem Gebäude Switch. Siehe 3.3
Core Router Gebäude Router/Switch ZID oder Karlsplatz Glasstrecke Pro Gebäude 2 Backbone Router + Switche. Siehe 3.3
Gebäude Router/Switch Etagen Switch Glasstrecke Nur bei Weg über ZID
Gebäude Switch oder Etagenswitch Firewall Kupfer Zum inneren Interface des Firewalls. Jeweils ein Firewall im ZID und am Karlsplatz in einer Active/Standby Konfiguration
Firewall Anbindungsswitch Kupfer, 100 MBit/s Je ein Anbindungsswitch pro Gebäude, untereinander verbunden. Kann Verkehr, wenn z.B. gebäudeeigener Firewall ausgefallen ist, zum anderen Gebäude leiten.
Anbindungsswitch Anbindungsrouter Glaspatchung

Je ein Anbindungsrouter am ZID und am Karlsplatz. Hier wird entschieden, wohin das Paket geschickt werden soll (ACOnet, Internet, Teleweb, Inode) 

Anbindungsrouter 

Anbindungsswitch Glaspatchung  
Anbindungsswitch AConet / Teleweb Glasstrecke  
ACOnet Router Internet Glasstrecke  

Wie schon innerhalb der TU Wien dargestellt, kann der Rückweg infolge der alternativwege ein anderer sein. Der vereinfachte Ablauf ist auch in folgender Grafik dargestellt:

red-abb3

Redundante Server, wie externe Nameserver, Mail- Bastionsrechner sind in einer DMZ, die redundant an beide Firewalls angeschlossen sind, platziert (in der Grafik nicht dargestellt).

Wenn verfügbar, sind die Geräte der externen Anbindung mit zwei Stromversorgungen ausgestattet. Überall sind entsprechende USVs vorhanden (mindestens 4 Stunden Überbrückungszeit). Die Geräte sind alle gebäude- redundant (Freihaus / Karlsplatz) ausgeführt. Die Verbindungswege führen soweit wie möglich über unterschiedliche Trassen und sind zum Teil doppelt (zumindest logisch gesehen) ausgelegt.

Die Firewalls verwenden eine ähnliche Technik, wie bereits beim HSRP-Protokoll beschrieben, um dem aktiven Firewall immer die gleiche Mac-Adresse und IP-Adresse zu geben. Bei den externen Routern wird das BGP Protokoll (border Gateway Protocol) verwendet, das umfangreiche Möglichkeiten der Steuerung von redundanten Wegen zu Destinationen im Internet vorsieht.

Internet-Räume, Wählleitungszugänge, TU-ADSL, xDSL@student, Demonetz und WLAN werden über eine ähnliche Konstruktion mit einem eigenen Firewall-Paar zu den externen Routern geführt.

5. Maßnahmen bei Servern

In Abschnitt 3 sind die Methoden zur ausfallsicheren Übertragung von Paketen von Punkt A nach B, dem "TUNET Transport Dienst", dargestellt worden. Man hat aber nichts davon, wenn ein Paket erfolgreich zum Server transportiert wurde, der Server ist aber nicht betriebsbereit. Es müssen daher auch eine Reihe von Maßnahmen bei den Servern getroffen werden.

Bei Servern gibt es grundsätzlich 3 Ebenen, auf denen die Betriebssicherheit angegangen werden kann: 

5.1 Redundanz bei Kommunikationsprotokollen

Wenn bereits beim Design der Kommunikationsprotokolle die Nutzung von redundanten Servern vorgesehen wurde, ist dies natürlich die angenehmste Variante. Man braucht einfach nur zwei oder mehr Server aufstellen und sowohl Server und meistens auch Clients müssen richtig konfiguriert werden. Leider ist dies nur bei wenigen Protokollen wirklich der Fall. So gibt es etwas Derartiges bei den wichtigen Protokollen HTTP und FTP leider nicht.

5.1.1 Nameservice
http://nic.tuwien.ac.at/services/name/

Eines der grundlegenden Protokolle für den Betrieb des Internet ist das Nameservice. Dessen Aufgabe ist die Umsetzung von Namen auf Adressen (und umgekehrt) und das Liefern von einigen wenigen Zusatzinformationen (wie den richtigen Mailserver).

Vom Design des Nameservice handelt es sich um eine weltweit verteilte Datenbank (vermutlich die größte überhaupt) mit lokaler Cache Funktion. Pro Domain (z.B. tuwien.ac.at) müssen mindestens zwei Nameserver existieren, die möglichst auf Servern, die in unterschiedlichen Gebäuden, wenn möglich sogar Netzen bzw. Providern bzw. Kontinenten aufgestellt sind.  Ein Client (Arbeitsplatzrechner) konfiguriert die lokalen Nameserver der jeweiligen Organisation (tunamea und tunameb an der TU Wien) mit deren IP-Adressen (der Name kann ja nicht ohne das Nameservice selber auf eine Adresse umgesetzt werden). Die Anfragen eines Client gehen daher immer zum lokalen Nameserver mittels des DOMAIN Protokolls (in der Regel wird die UDP-Variante verwendet). Dieser kann die Antwort auf Grund der Daten im Cache geben oder fragt einen anderen Nameserver (normalerweise bereits den richtigen Nameserver für die Domain) und gibt dann die Antwort.

Wenn ein Client in einer gewissen Zeit keine Antwort vom Nameserver bekommt, fragt er den nächsten konfigurierten Nameserver. Leider dauert dieser Umschaltvorgang relativ lange (und ist auch vom jeweiligen Betriebssystem am Client abhängig), sodass das Umschalten meistens vom Anwender bemerkt wird. Verzögerungen treten auch an Stellen auf, wo man es nicht ad hoc erwartet. So erfragen viele Server beim Login-Vorgang den Namen, der zu einer IP-Adresse gehört, um diesen Namen bei Security-Überprüfungen und für das Logging zu verwenden. Da dies auch über den Nameserver abgewickelt wird, treten damit hier Verzögerungen auf.

Für die Domain tuwien.ac.at gibt es innerhalb der TU Wien zwei Server (tunamea und tunameb), die im Freihaus und in der Favoritenstraße aufgestellt sind. Die Generierung der Konfigurationsfiles für den Nameserver aus der TUNET Datenbank erfolgt einmal am Tag auf einem anderen Server, auf dessen lokalen Nameserver die neuen Daten auch aktiviert werden. Von dort holen sich dann obige Nameserver die neuen Daten, Subdomain für Subdomain, über einen längeren Zeitraum. Ein direktes Aktivieren aller Nameserverdaten (da jede Domain ein eigenes File ist, sind diese Daten auf etwa 250 Files verteilt) würde eine Störung von 1-2 Minuten des Nameservice bewirken !

Für die Abfrage nach Daten der TU Wien von Nameservern in der weiten Welt stehen zwei eigene Nameserver (tunamec und tunamed) an den Standorten Freihaus und Karlsplatz (in der DMZ des Firewalls der TU Wien möglichst nahe am Anschluss zum Internet Provider). Auch hier werden die Daten am TUNET Datenbank Server generiert und lokal aktiviert.

Für das Nameservice für Domains der TU Wien ungleich tuwien.ac.at ("Fremddomains") werden zwei eigene Server (tunamee, tunamef) im Freihaus und am Karlsplatz eingesetzt. Hier erfolgt die Generierung nicht aus der TUNET Datenbank sondern wird per Hand in den Text-Files eingetragen. Bei Änderungen erfolgt dann ein Reload des jeweiligen Nameservers, da hier wegen der geringen Datenmengen nur eine minimale Unterbrechung auftritt. (Eine Zusammenlegung mit den externen Nameservern würde bei diesen aber eine lange Unterbrechung erfordern.)

Die Nameserver für die Domain ac.at sind neben Wien (mehrere Standorte) auch in Deutschland und den Niederlanden aufgestellt. Für das Nameservice von at kommen noch Standorte in USA und UK dazu.

5.1.2 Timeservice

Die Timeserver werden untereinander mit dem NTP Protokoll synchronisiert. Das Konzept sieht einerseits eine Hierarchie der Server vor, die durch den Abstand, dem Stratum (Anzahl der Timeserver), zu einem Referenzserver (einer Atomuhr) bestimmt wird. Ein Server synchronisiert sich normalerweise mit mehreren Servern einer besseren Hierarchie und auch mit Servern der gleichen Hierarchie. Wenn alle Verbindungen zu anderen Servern ausfallen, steht immer noch die lokale Uhr des Rechners im "Freilauf" zur Überbrückung zur Verfügung.

Auf der TU Wien sind drei Timeserver aufgestellt, zwei im Freihaus, einer in der Favoritenstraße. Einer der Timeserver im Freihaus erhält über eine Funkverbindung (Langwelle) Zeitsignale vom DCF77 Sender in Mainflingen bei Frankfurt, die auf Basis einer Atomuhr erzeugt werden.

Damit ein Client die Redundanz ausnutzen kann, müssen natürlich am Arbeitsplatzrechner mindestens zwei Server konfiguriert werden (siehe http://nic.tuwien.ac.at/services/time/).

Anbei eine Darstellung der derzeitigen Vernetzung unserer Timeserver.

Timeserver

5.1.3 Mailrouting

Beim Weiterleiten von Mails auf Basis des Domainnamens nach dem @ (also nicht des Mailboxnamens !) gibt es die Möglichkeit, mehrere Zielrechner, an die die Mail zugestellt werden soll, mit unterschiedlichen Prioritäten zu definieren. Dies erfolgt mit eigenen Einträgen im Name- server, den MX-Records. Hierbei werden z.B. für Mail- adressen der Form mailbox@tuwien.ac.at mehrere MX- Records eingetragen. In diesem konkreten Fall werden als Zielrechner die beiden Systeme mri1.tuwien.ac.at und mri2.tuwien.ac.at definiert, wobei mri1 die bessere (numerisch niedrigere Priorität) hat, und damit der Verkehr normalerweise über diesen Rechner geführt wird. Erst bei Ausfall (Nichterreichbarkeit des SMTP-Ports) wird versucht, die Mail an mri2 zuzustellen. Um eine Lastaufteilung zu bewirken, werden Mails an mailbox@student. tuwien.ac.at primär an mri2 zugestellt, bei Ausfall an mri1, d.h. für ankommende Mails an die Adressen @tuwien. ac.at und @student.tuwien.ac.at stehen zwei Rechner bereit, einer im Freihaus und einer in der Favoritenstraße.

Ähnlich wird bei den Mailbastionsrechnern, über die alle ankommende Mail (außer @tuwien.ac.at und @student. tuwien.ac.at) der TU Wien geführt wird, gearbeitet. Auf den externen (und nur dort) Nameservern ist für Mailrechner auf Basis der Eintragung in der TUNET Datenbank (Attribute MAIL/BASTION) eine Umleitung der Mails auf die beiden Bastionssysteme tuvok.kom.tuwien. ac.at und neelix.kom.tuwien.ac.at mittels MX-Records definiert. Diese Eintragungen haben beide die beste Priorität (0). Damit erfolgt automatisch eine Lastaufteilung (je nachdem, welchen der beiden Einträge der abschickende Rechner verwendet). Als dritter Eintrag sind der/die Rechner innerhalb der TU Wien mit einer schlechteren Priorität eingetragen. Für den Fall, dass beide Bastionsserver über längere Zeit gestört sind, kann daher per Hand auf den Firewalls die Sperre des SMTP-Port aufgehoben werden, und die Mails werden direkt an die Zielrechner an der TU Wien zugestellt. Dadurch entfallen naturgemäß die Schutzmaßnahmen gegen Mail-Relaying und Viren. Die beiden Bastionsrechner stehen im Freihaus und am Karlsplatz und sind in der DMZ der TU Wien angesiedelt.

Neben diesen Möglichkeiten verwenden die Mail Transfer Agents (das sind jene Programme, die für die Weiterleitung von Mails im Internet zuständig sind) den Mechanismus, dass eine Mail, die nicht sofort zugestellt werden kann, in einer Queue gehalten wird. Diese Queue wird dann z.B. in regelmäßigen Abständen abgearbeitet. Üblicherweise wird nach 4 Stunden Nichtzustellbarkeit der Absender darüber informiert (Warnung), es wird aber weiter versucht, die Mail zuzustellen. Erst nach 3-5 Tagen (je nach Konfiguration des MTA, an der TU Wien 5 Tage) wird aufgegeben, und die Mail wird als unzustellbar an den Absender zurückgewiesen.

Die Überprüfung auf Viren der Mails erfolgt über insgesamt 4 eigene Virenscanner, die auf drei Standorte der TU Wien verteilt sind. Einem Mailrouter bzw. Bastionsrechner sind ein bis zwei Virenscanner zugeordnet. Wenn keiner dieser Scanner erreichbar ist, wird der Absender mittels eines temporären Fehlercodes darüber informiert, sodass er einen anderen Mailrouter versuchen kann.

Anzumerken ist, dass bei von der TU Wien abgehender Mail (z. B. über die Server mr.tuwien.ac.at, pop. tuwien.ac.at, stud3.tuwien.ac.at) der Mechanismus der MX-Records nicht zur Anwendung kommen kann, da der "Outgoing SMTP Server" fix im Client (z. B. Eudora, Outlook Express, Netscape, ...) konfiguriert werden muss. Hier müssen dann Methoden, wie in 5.2 dargestellt, zur Verbesserung der Betriebssicherheit eingesetzt werden.

5.1.4 Validierung Wählleitungen / VPN / ADSL / ...

Die Terminalserver, der VPN-Konzentrator, die Router für die Tunnelendpunkte für das TU-ADSL Service und xDSL@student sowie die Gateways zwischen Demo-Netz bzw. WLAN und dem TUNET verwenden zur Abwicklung der Validierung das RADIUS-Protokoll nach RFC2138. Alle Geräte bieten die Möglichkeit zwei (oder mehr) Radius-Server zu konfigurieren, die in einer definierten Reihenfolge versucht werden. An der TU Wien sind zwei Radius-Server installiert, die alle im Freihaus stehen (auch alle Services, die die Validierung benötigen, stehen im Freihaus), jedoch in unterschiedlichen Räumen und Netzbereichen angesiedelt sind.

5.2 Ausfallsicherheit durch Content Switch

Für Protokolle, die ein Umschalten auf Backupsysteme nicht so wie in 5.1 vorsehen, müssen andere Verfahren eingesetzt werden. Erste Voraussetzung ist, dass das Service auf mehr als einem System angeboten wird. Nun geht es darum, bei einem Ausfall des Hauptsystems innerhalb möglichst kurzer Zeit umzuschalten. Im Wesentlichen gibt es drei Verfahren:


Im Frühjahr vorigen Jahres wurden mehrere Firmen zu einer Teststellung für einen Content Switch eingeladen. Dabei wurde an Hand einiger typischer Services (Protokolle) am ZID die Funktionalität der Testsysteme  überprüft und entsprechend gegenübergestellt. Im Ergebnis fiel dann, nicht zuletzt auch wegen der Preisrelationen, die Entscheidung zu Gunsten der Content Switche der Firma Cisco Systems, konkret das Modell CSS 11503. Die Geräte wurden Ende 2002 geliefert und dann unterschiedliche Konfigurationen im Detail untersucht. Schrittweise werden nun alle Services der Abteilung Kommunikation mittels dieser Geräte redundant angeboten. Content Switche werden auch als ISO Layer 4-7 Switche bezeichnet.

In der folgenden Abbildung ist die logische Konfiguration des Content Switch dargestellt:

red-abb5

Ein Content Switch bietet eine Reihe von Möglichkeiten, die eine große Flexibilität ermöglichen: 

Die beiden Content Switche werden gebäuderedundant im Freihaus und in der Gußhausstraße (oder Favoritenstraße) aufgestellt und direkt an einen Backbone Switch angeschlossen. Untereinander sind die beiden Content Switche über einen dedizierten Gigabit Link verbunden, um "Adaptive Session Redundancy" zu erlauben. Damit kann der Backup Switch auch aktive Verbindungen bei einem Ausfall des primären Switches übernehmen. In der Regel wird eine gleichmäßige Lastverteilung (Round Robin) konfiguriert. Mittels des Content Switches werden insbesondere die Services der White Pages (neue Ver- sion), Mailrouting, Abteilungsservices unter nic.tuwien.ac.at redundant angeboten.

Die Grenzen der Redundanz durch einen Content Switch und Verdopplung der Server sind bei Services, die Datenbestände im Hintergrund haben, wie z. B. die Web-Seiten beim Info-Server, die Mailboxen beim POP-Server und die TUNET-Datenbank. Hier sind dann wesentlich aufwändigere Konstruktionen zur gemeinsamen (redundanten) Datenhaltung erforderlich.

5.3 Maßnahmen beim Server

Auf den Servern selber werden die üblichen Maßnahmen getroffen:

6. Telefonie

Auch wenn sich dieser Artikel hauptsächlich mit der Datenkommunikation beschäftigt, sollen hier kurz die Maßnahmen bei der Telefonie zusammengestellt werden:

Nicht redundant möglich ist der Sprachspeicher (gespiegelte Platten sind aber im Einsatz).

Auch die Chipkarten-Überprüfung ist wegen der komplexen verteilten Konfiguration der Anlage nicht redundant.

7. Management

Ein wesentlicher Aspekt der Betriebssicherheit ist die Überwachung der Komponenten im Netzwerk. Hiezu werden eine Reihe von Tools eingesetzt und bei den Mitarbeitern angezeigt. Folgende Aspekte werden überwacht:

8. Literatur

Betriebsfehler: Fehlertoleranz und Redundanz. Dirk Spöri

RFC 2281. Cisco Hot Standby Router Protocol (HSRP).  T. Li, B. Cole, P. Morton, D. Li. (March 1998)

RFC 2338. Virtual Router Redundancy Protocol. S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem (April 1998)

RFC 2328. OSPF Version 2. J. Moy (April 1998)

DNS Resources Directory: http://www.dns.net/dnsrd

NTP: The Network Time Protocol: http://www.ntp.org/

RFC 2138, Remote Authentication Dial In User Service (RADIUS). C. Rigney, A. Rubens, W. Simpson, S. Willens (April 1997)

Ergänzung zum Entwurf aktive TUNET-Komponenten in den Institutsgebäuden der Technischen Universität Wien, Gußhausstraße 25 und 27-29. Manfred R. Siegl (August 2002).

Cisco LAN Switching. Kennedy Clark, Kevin Hamilton, Cisco Press (1999)

Building Cisco Multilayer Switched Networks. Karen Webb, Cisco Press (2000)

Interconnections: Bridges and Routers. Radia Perlman, Addison Wesley (1993)

Cisco TCP/IP Routing Professional Reference. Chris Lewis, McGraw-Hill (1998)

Routing in the Internet. Christian Huitema, Prentice Hall PTR (1995)

Online-Dokumentationsseiten des Herstellers
Cisco System, CCO : http://www.cisco.com/



topSeitenanfang | ZIDline 8 - Juni 2003 | ZID | TU Wien