3.3 Netzwerk

Damit Clients mit Servern und auch Server untereinander kommunizieren können, braucht man leistungsfähige und ausfallsichere Netze. Alle Investitionen in Servertechnologie haben nur einen begrenzten Wert, wenn das Netzwerk »qualitativ nicht passt«.

Obwohl dies ein Buch über ein Serverbetriebssystem ist, halte ich es für sinnvoll, den Themenbereich »Netzwerk« zumindest kurz zu beleuchten.

3.3.1 Netzwerkstrukturen und Verfügbarkeit

Wenn eine Gesamtumgebung ausfallsicher sein soll, reicht es natürlich nicht, wenn Sie viel Geld im Bereich der Server investieren und das Netzwerk auf eher bedenklichem Niveau belassen. Eine Netzwerkinfrastruktur, die in heutiger Zeit sicherlich nicht mehr ausreichend ist, sehen Sie in Abbildung 3.16:

Abbildung 3.16 Dieses Netz ist bezüglich Ausfallsicherheit eher bescheiden. Der Ausfall des Core-Switches, eines GBICs/SFPs oder ein »Knick« in einer Leitung legt mehr oder weniger große Bereiche lahm.

• Fällt der Core-Switch aus, steht das gesamte Netz.
• Fällt eine Netzwerkkarte im Server aus, kann auf diesen Server nicht mehr zugegriffen werden – schlecht, wenn es beispielsweise der einzige Domänencontroller ist.
• Wenn ein Kabel oder ein GBIC/SFP (Anschlussmodul im Switch) der Serveranbindung ausfällt, steht der Server natürlich ebenfalls nicht mehr zur Verfügung.
• Fällt ein Kabel oder ein GBIC/SFP aus, das zu einem Etagenverteiler führt, ist die gesamte Etage von der Unternehmens-IT abgeschnitten.

Die Aufgabe ist nun, das Netz redundant auszulegen. In diesem Zusammenhang geht es natürlich auch um die redundante Anbindung der Geräte an das Netz. Für Server wird man im Allgemeinen immer eine redundante Anbindung schaffen. Bei Clients ist das nicht üblich, und ebendies gilt auch für Drucker.

Wenn Sie Ethernet einsetzen, werden Sie vermutlich eine Struktur implementieren, wie sie in Abbildung 3.17 gezeigt ist:

Abbildung 3.17 Ein redundant aufgebautes modernes Netz

• Das Rückgrat der Infrastruktur sind die redundanten untereinander vernetzten Core-Switches.
• Server werden redundant an die Core-Switches angebunden.
• Die Etagenverteiler werden redundant angebunden.

Sie können nun gedanklich alle Varianten durchspielen: den Ausfall einer Netzwerkkarte im Server, den Ausfall eines Core-Switches, den Ausfall einer Leitung zum Etagenverteiler u. v. a. m. Durch die redundante Auslegung ist das Netz immer relativ schnell wieder arbeitsfähig.

Nicht redundant ausgelegt, sondern nur redundant angebunden sind die Etagenverteiler. Der primäre Grund ist, dass es zu viel Umstand wäre, jeden PC und jeden Drucker mit zwei Netzwerkkarten auszurüsten. Wenn die anzuschließenden Geräte nur einen Netzwerkanschluss haben, machen redundante Switches natürlich nur sehr begrenzt Sinn.

Außerdem ist ein Etagenverteiler relativ problemlos zu ersetzen. Die meisten Unternehmen haben einen oder mehrere vorkonfigurierte Ersatzetagenverteiler, die im Bedarfsfall schnell an der benötigten Position eingebaut werden können.

Im Ethernet-Umfeld sollten Sie für die Verbindungen zwischen Core-Switch und Etagenverteiler Glasfaserverbindungen wählen. Für die Anbindung der Endgeräte wird man in den meisten Fällen zu einer Kupferverbindung greifen, wobei 100-BaseT völlig genügt – PCs und Drucker sind ohnehin nicht in der Lage, eine Gigabit-Verbindung auch nur ansatzweise auszulasten; Ausnahmen sind beispielsweise Grafik-Workstations oder Geräte im Bereich Scientic-Computing, Videoschnitt und Ähnliches.

Die meisten Unternehmen binden Server ebenfalls über Kupfer an und nutzen also 1000 BaseT. Eine Anbindung mit Gigabit-Ethernet über Glasfaser ist sicherlich ganz schick. Wenn Sie keine dedizierte Anforderung haben, verursacht dies aber eher mehr Kosten, als es tatsächlichen Nutzen bringt. Denken Sie allein an die zusätzlich benötigen PCI-Steckplätze.

Interessant ist die Frage, wie das Netzwerk (sprich die Switches) mit den redundanten Pfaden umgeht. Schließlich ist Ethernet ursprünglich für eine sternförmige Topologie vorgesehen gewesen – und Sterne zeichnen sich nun einmal dadurch aus, dass die Strahlen nicht mehrfach zu einem Punkt führen.

In der Welt des Layer-2-Switchings (MAC-Adresse) wird ein Verfahren namens Spanning Tree verwendet. Es funktioniert vereinfacht gesagt so:

• Existieren redundante Netzwerkpfade, ist nur ein Pfad aktiv. Der andere ist passiv – um nicht zu sagen »abgeschaltet«.
• Die Switches legen übrigens selbstständig fest, welche Wege aktiv und welche passiv sind. Eine manuelle Konfiguration ist nicht erforderlich.
• Fällt ein aktiver Netzwerkpfad aus, erfolgt eine Neuberechnung sämtlicher Netzwerkpfade.

Layer-2-Switching mit Spanning Tree hat zwei wesentliche Nachteile:

• Die Hälfte der vorhandenen Netzwerkpfade wird nicht verwendet – es gibt also keine Lastverteilung.
• Die Errechnung der Netzwerkpfade im Fall eines Ausfalls kann bei einem großen und sehr komplexen Netz durchaus einige Minuten in Anspruch nehmen. In dieser Zeit funktioniert das Netz nur sehr eingeschränkt.

Als Lösung für das zweite genannte Problem ist das Rapid Spanning Tree-Protokoll entworfen worden, dass seit Längerem auch standardisiert ist. Grundidee ist, dass beim Ausfall eines Netzwerkpfads nicht die komplette Kommunikation angehalten wird, sondern dass bis zur Neuerrechnung mit der alten Konfiguration weitergearbeitet wird – und daher einige Verbindungen nicht funktionieren. So wird zwar nicht sofort das Problem behoben, allerdings gibt es bei einem eher »unbedeutenden« Ausfall (z. B. beim Ausfall eines Pfades zu einem Etagenverteiler) nicht sofort einen Totalstillstand.

Der elegantere Weg ist das Layer-3-Switching (IP-Adresse), das streng genommen eher ein Routing als ein klassisches Switching ist. Im Layer-3-Umfeld kommen Routing-Protokolle wie beispielsweise OSPF zur Anwendung, weshalb sowohl die abgeschalteten Netzwerkpfade als auch die relativ umfangreichen Neuberechnungen beim Ausfall eines aktiven Pfads entfallen.

Layer-3-Switching erfordert eine sehr sorgfältige Planung der IP-Adressbereiche, schließlich muss für jeden Layer-3-Switch ein eigenes Segment implementiert werden. Nebenbei bemerkt hat das natürlich auch Auswirkungen auf die Implementation von DHCP.

In der Praxis findet man häufig eine Konstellation, in der im Core-Bereich mit Layer-3-Switching und im Etagenbereich mit Layer-2-Switching gearbeitet wird.

Die Planung eines leistungsfähigen und ausfallsicheren Netzes innerhalb eines Gebäudes oder Gebäudekomplexes (Campus) ist nicht trivial. Noch komplexer ist der Aufbau eines Netzes, das mehrere Standorte innerhalb einer Stadt umschließt. Man spricht in diesem Fall von einem MAN, einem Metropolitan Area Network.

Im Gegensatz zu einer WAN-Implementation wird man bei einem MAN sämtliche Standorte mit sehr hoher Geschwindigkeit anbinden, heute zumeist mit Gigabit-Verbindungen. Ohne jetzt auf Details eingehen zu wollen, ist in Abbildung 3.18 die prinzipielle Vorgehensweise eines MANs gezeigt (andere Varianten sind möglich; dies ist ein häufig verwendetes Prinzip):

• Das Kernstück des MANs ist ein Ring, beispielsweise auf Gigabit-Ethernet-Basis. Der Ring wird übrigens durch Punkt-zu-Punkt-Verbindungen zwischen den Switches an den einzelnen Standorten gebildet. Durch geeignete Verfahren wird sichergestellt, dass beim Ausfall einer Verbindung zwischen zwei Standorten ein Alternativweg gewählt wird. Im Allgemeinen wird das durch Layer-3-Switching realisiert.
• Der Hauptstandort, der im Allgemeinen auch Serverstandort ist, wird mit redundanten Core-Switches ausgestattet, die beide am Ring angeschlossen sind. Am Hauptstandort werden Server und Etagenverteiler redundant angebunden (siehe auch Abbildung 3.18).
• An den anderen Standorten können die Geräte (PCs, Drucker) entweder direkt am »Hauptswitch« oder über Etagenverteiler angebunden werden.

  

  Abbildung 3.18 MANs basieren häufig auf einem Ring.

3.3.2 Anbindung von entfernten Nutzern

Nachdem im vorherigen Abschnitt der Schwerpunkt auf lokalen Netzen lag, werden wir uns in diesem Abschnitt mit der Anbindung von entfernten Benutzern beschäftigen. Diese lassen sich grob in zwei Kategorien unterteilen, nämlich in diejenigen, die an einem entfernten Firmenstandort sitzen, und in diejenigen, die mobil oder vom Homeoffice aus zugreifen. Für die Kopplung zwischen zwei Unternehmensteilen wird man im Allgemeinen ein Virtual Private Network (VPN) verwenden, man spricht dann von einem Site-to-Site-Szenario. Zwischen einzelnen Benutzern und der Firmenzentrale kann ebenfalls eine Verbindung aufgebaut werden, dies ist dann ein Site-to-End-Szenario.

Für den Zugriff eines einzelnen Benutzers ist unter Umständen kein VPN erforderlich, sondern es genügt eine SSL-verschlüsselte Verbindung.

VPN-Verbindungen

Bei Verbindungen zwischen zwei Unternehmensstandorten kommen heute im Allgemeinen VPN-Verbindungen zum Einsatz, bei denen die Daten verschlüsselt durch einen »Tunnel« durch das Internet geleitet werden.

Ein wesentliches Problem bei VPN-Verbindungen kann die Latenzzeit sein. Dauert die Übertragung eines Pakets durch das Internet von einem Punkt zum anderen zu lange, werden die Anwender das Arbeiten mit einem zentralen System als irgendwo zwischen »nicht angenehm« bis »völlig nervenaufreibend« einstufen.

Ein VPN kann grundsätzlich zwischen zwei völlig beliebigen Internetanschlüssen aufgebaut werden. Theoretisch (!) könnten Sie für jeden Ihrer Standorte eine Billig-DSL-Flatrate buchen, Geräte anschließen, die einen VPN-Tunnel aufbauen können – und loslegen. Wenn Sie VPNs professionell nutzen, wird man auf ein Angebot eines Providers zugreifen, der den kompletten Verkehr zwischen Ihren Standorten über seinen eigenen Backbone leiten kann und für die Verbindungsqualität garantiert. Die Anforderungen sind insbesondere Verfügbarkeit, Bandbreite und Latenzzeit. Die Provider vermarkten im Allgemeinen ein spezielles Paket für die VPN-Nutzung, im Rahmen dessen Mindestwerte für die zuvor genannten Eigenschaften vertraglich zugesichert werden. Dies ist teurer, als wenn Sie einfach mehrere Internet-Zugänge ohne Zusatzleistungen kaufen würden – eine höhere zugesicherte Qualität hat aber ihren Preis.

Falls Sie europäische oder weltweite Standorte vernetzen wollen, gilt natürlich ebenfalls, dass alle Internet-Anbindungen von einem Provider kommen sollten, damit die Leitungsqualität garantiert werden kann. Falls ein Provider nicht sämtliche Länder bedienen kann, in denen Sie Niederlassungen unterhalten, sollte er zumindest über dortige Partner-Carrier verfügen, sodass die benötigte Qualität gewährleistet ist.

Sie sollten übrigens vor Abschluss eines Vertrags ruhig genau hinterfragen, über welche Wege Ihre Daten laufen werden. Insbesondere Unternehmen mit Niederlassungen im asiatisch-pazifischen Raum haben häufig Probleme mit den WAN-Verbindungen – nicht wegen der Bandbreite, sondern wegen hoher Latenzzeiten.

Die Ursache klärt sich recht schnell, wenn Sie einen Blick auf Abbildung 3.19 werfen. Wenn der Hauptknotenpunkt eines Providers in den USA liegt, ist es durchaus möglich, dass Ihre Pakete zunächst in die USA und von dort nach Asien übertragen werden. Wenn man für den Übertragungsweg zu einem Satelliten 40.000 km annimmt, sind die Daten allein 160.000 km ins All und zurück unterwegs. Da eine Kommunikation zwischen Client und Server zumeist aus Frage und Antwort besteht, sind in dem Vorgang schon 320.000 km enthalten. Mit den Latenzzeiten, die durch IP-Stacks und Geräte hinzukommen, überschreiten wir insgesamt problemlos die 1.000 ms – es werden in diesem Szenario eher 2.000 ms werden!

In »guten Szenarien« wird es übrigens auch Verbindungen zwischen zwei Satelliten geben, was dann ein deutlich besseres Zeitverhalten zur Folge hat. In Abbildung 3.19 ist das Supersparmodell dargestellt – und das ist nicht gut.

Abbildung 3.19 Verbindungen nach Fernost werden häufig über zwei Satellitenstrecken geroutet.

Achten Sie also darauf, dass Ihr VPN-Anbieter zu allen Standorten ein Routing implementiert, das nur eine Satellitenverbindung enthält. Bei Transaktionen, die nur ein bis zwei Roundtrips zwischen Client und Server benötigen, ist ein akzeptables Arbeiten im Allgemeinen möglich. Da »Arbeitsgeschwindigkeit« etwas sehr Individuelles ist, sollten Sie nach Referenzinstallationen fragen, in denen ähnliche Szenarien implementiert sind.

Über die VPN-Verbindungen wird im Allgemeinen Traffic aller Art laufen, also beispielsweise SAP-GUI-Verkehr, Terminaldienste-Sitzungen, Mails, Druckdaten, Filetransfer und sonstiger Datenaustausch. Damit die Anwender maximal schnell auf die wichtigsten Systeme zugreifen können, müssen die entsprechenden Pakete gegenüber dem sonstigen Verkehr priorisiert werden. Höherwertige Router können diese Anforderung erfüllen, und außerdem gibt es Hersteller, die Spezialprodukte für solche Anwendungszwecke produzieren; suchen Sie in Google beispielsweise nach »WAN Optimization«.

Sicherheit

Ich gehe davon aus, dass Ihre Anbindung an das Internet sorgfältig geplant, akribisch implementiert und ständig überwacht wird. Wenn Sie jetzt nicht heftig mit dem Kopf nicken, dann sollten Sie für diese Akribie sorgen – ganz schnell.

Es hat sich bewährt, VPN-Nutzern nicht den Zugriff auf das ganze Netz in der Zentrale zu geben, sondern für sie nur den Zugriff auf die benötigten Ressourcen freizuschalten. Es hat sich gezeigt, dass die Sorgfalt im Umgang mit dem Thema »Sicherheit« mit zunehmender Entfernung von der Firmenzentrale abnimmt. Über die Ursachen möchte ich nicht spekulieren, mir sind aber genügend Fälle von mittleren und größeren Unternehmen bekannt, in denen sich gerade die VPN-Anbindungen als Einfallstor für Dinge wie Trojaner, SQL Slammer und vergleichbares Ungetier erwiesen haben.

Ausfallsicherheit

Der nächste Aspekt ist die Ausfallsicherheit der WAN-Verbindungen. Optimalerweise würde man natürlich auch diese Verbindungen redundant auslegen. Es ist natürlich ein erheblicher Kostenblock, Verträge mit mehreren Carriern zu schließen, und weiterhin besteht natürlich die »Gefahr«, dass zumindest die »letzte Meile« ohnehin über dieselbe Trasse läuft. Gegen den Bagger, der die Leitung 500 m neben Ihrer Firmenzentrale durchhackt, sind Sie dann ohnehin nicht gewappnet.

Professionell arbeitende Carrier unternehmen recht viel, um die in den Verträgen zugesicherten Servicelevel auch wirklich halten zu können. Insofern ist es häufig fragwürdig, ob wirklich eine eigene Parallelinfrastruktur aufgebaut werden muss. Über Minimalmaßnahmen, wie eine ISDN-Backup-Verbindung, sollten Sie trotzdem nachdenken, um zumindest einen Notfallbetrieb gewährleisten zu können.

Falls Sie auch für ein oder zwei Stunden nicht auf eine einigermaßen performante Anbindung von Außenstellen verzichten können, ist die Konzeption von Backup-Verbindungen notwendig. Vielleicht können für die »letzte Meile« Richtfunkstrecken eingesetzt oder direkte Satellitenverbindungen geplant werden – es gibt Unternehmen, die auf die Realisierung solcher Anforderungen spezialisiert sind.

3.3.3 Netzwerkmanagement

Genauso wie Serversysteme müssen (oder zumindest: sollten) die Netzwerkkomponenten überwacht werden. Hier sind verschiedene Produktfamilien verfügbar:

• Alle wesentlichen Hersteller liefern, teils gegen Aufpreis, eine hauseigene Management-Software. Diese Werkzeuge sind sehr gut, allerdings auch recht komplex in der Anwendung. In großen Umgebungen, in denen sich ein Mitarbeiter ausschließlich mit dem Netzwerkmanagement mittels eines solchen Systems beschäftigt, machen sie Sinn. »Mal eben« ein Netzwerkmanagement-System dieser Komplexität einzuführen, wird nicht zum Erfolg führen.
• Eines der bekanntesten herstellerübergreifenden Netzwerkmanagement-Werkzeuge ist OpenView von Hewlett Packard. Auch bei dieser Software gilt, dass für ihre Einführung und Anwendung erhebliches Know-how erforderlich ist. Es handelt sich eben um ein komplexes System mit entsprechenden Möglichkeiten.
• Wenn – insbesondere in mittleren Umgebungen – ein relativ einfaches Monitoring des Netzwerks implementiert werden soll, können Werkzeuge wie beispielsweise Orion Network Performance Monitor von SolarWinds (http://www.solarwinds.net) zum Einsatz kommen. Werkzeuge dieser Kategorie bieten zwar weder die Ganzheitlichkeit eines OpenView noch die produktspezifischen Möglichkeiten von Herstellerwerkzeugen, geben aber einen recht unkomplizierten Überblick über Performance und Verfügbarkeit der aktiven Netzwerkkomponenten.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.