Nach wie vor prognostiziert Dataquest ein verhaltenes Stückzahlenwachstum im PC-Markt: 1997 mit 14 Millionen, 1998 mit 16 Millionen, 1999 mit 18 Millionen auszuliefernder Systeme in Westeuropa. Das bedeutet eine weiterhin steigende Anzahl Clients, die von verschiedenen Servern zu bedienen sind. Jüngsten Diebold-Erhebungen zufolge geht der Umsatzanteil von PC-Servern im deutschen Markt kontinuierlich nach oben, während der Umsatz mit Mainframes abnimmt und der mit Unix-Mehrplatzsystemen und -Servern völlig wegbricht. Gleichzeitig verschiebt sich die Invest-Relation zwischen Clients und Servern mehr und mehr in Richtung Clients: Während sich die Neuinvestitionen für Hosts und Server im Jahr 2000 nur noch auf elf bis zwölf Milliarden Mark belaufen sollen, werden die Ausgaben für Arbeitsplatz-PCs, PC-Erweiterungen (Platten, Hauptspeicher, CD-ROM etc.) und Drucker auf 28 bis 29 Milliarden Mark geschätzt.

Immer leistungsstärkere PCs, die jedoch nur wenig bis keine Peer-to-Peer-Kommunikation mehr betreiben, stellen eine Herausforderung für die Leistungsfähigkeit der Server dar, die sie bedienen. Mittel- bis langfristig stellt sich die Frage, ob das Server-Konzept auch neuen Arbeitsplatzsystemen wie Network Computern (NCs) oder Network Terminals gewachsen sein wird.

Für einerseits kosteneffiziente, andererseits performante und zuverlässige Server-Konzepte sind bei der Planung eine Reihe von Infrastruktur- und Betriebsaspekten zu berücksichtigen:

- Standort der Server (Positionierung),

- Anzahl eingesetzter Server,

- eingesetzte Server-Typen,

- Netzzugang der Server,

- Einfluß vorhandener Netzstrukturen auf die Server-Anbindung,

- Fehlertoleranz,

- Redundanz sowie

- Server-Betreuung und -Management.

Der aktuelle Trend geht stark in Richtung Server-Pool im Rechenzentrum. Hier sind günstige Betriebsbedingungen vorzufinden, wie zum Beispiel gesicherter Zugang durch Überwachungssysteme, Klimatisierung, Brandschutz und zentraler Betreuungspunkt beziehungsweise Präsenz der Betriebsmannschaft. Nicht zuletzt wandern mehr und mehr Server auch deshalb ins Rechenzentrum, weil sowohl die RZ-Leitung als auch das Management in den Unternehmen erkannt haben, daß Server-Betrieb analog zum Host-Betrieb RZ-Geschäft ist.

Hiermit sind beste Voraussetzungen gegeben, um zu etablierten Host-Strukturen zurückzukehren. Die gesamte Server-Leistung wird im RZ erbracht, jeder Lade- und Speichervorgang wird von einem Client über den Backbone ins RZ und von dort an den Server übertragen. Zwischen einer hochmodernen vermaschten ATM-Backbone-Struktur sowie Punkt-zu-Punkt-Anbindung der Endgeräte und einem SNA-Netzwerk der 80er Jahre bestehen starke strukturelle Ähnlichkeiten. Allerdings sind die Übertragungskapazitäten deutlich höher, und anstelle der Hostsysteme wird ein Server-Pool oder Server-Cluster mit Hochkapazitäts-Netzzugang je Server betrieben (siehe Bild 1).

Erfahrungsgemäß wird in zwei bis drei Jahren ein gegenläufiger Trend einsetzen, der wieder dezentrale Server favorisiert. Ein Anstoß hierfür kann die Einrichtung von Intranets mit verteilten Intranet-Servern sein. Bei sehr großen Netzen (6000 Anschlüsse und mehr) läßt sich ein rein zentrales Server-Konzept vielfach nicht mehr umsetzen. Im Regelfall gibt es dann eigenverantwortliche Unternehmensbereiche (Business Units) oder eigene Firmen unter einem Holding-Dach, die zusätzlich zum zentralen RZ eigene Server-Pools betreiben. Die dezentralen Teilnetzbereiche und zugehörigen Server-Pools lassen sich über Router und Switches vom gemeinsamen Standort-Backbone abkoppeln, um eine entsprechende Lasttrennung zu erreichen.

Die Anzahl eingesetzter Server nimmt seit Jahren erkennbar zu, den Single-Server-Betrieb (für Datei- und Druckdienste) haben die meisten Unternehmen weit hinter sich gelassen. Der erste Erweiterungsschritt ging hin zu Abteilungs-Servern oder zur Funktionstrennung nach Applikations-Servern, Datenbank-Servern (Transaktions-Server), Datei- und Druckservern, Kommunikations-Servern, Intranet- und Management-Servern, um einige etablierte Beispiele anzuführen. Der nächste Schritt ging dahin, die Funktions-Server wiederum zu vervielfachen.

Abteilungs- oder Funktions-Server?

Für die Zukunft sind massive Erweiterungen des Server-Einsatzes für Intranet-Dienste zu erwarten, etwa Dokumentenverwaltung, Infobörsen, Corporate Identitiy Medien etc. 30 bis 100 Server sind in mittleren bis großen Standortnetzwerken durchaus üblich. Zwei alternative Konzepte kommen hier zum Tragen: Zuordnung von Abteilungen zu dedizierten Servern (Abteilungs-Server-Konzept), die jeweils mehrere Funktionen anbieten; in diesem Fall werden unter Umständen weniger aber dafür performantere Server eingesetzt.

Die Alternative ist der Zugriff aller Benutzer oder maximaler Benutzerzahlen auf völlig zentrale Server, die entsprechend weniger Funktionen zur Verfügung stellen. Hier können mehrere niedriger dimensionierte Server zum Einsatz kommen. Das erste Konzept erleichtert die Subnetzstrukturierung, wenn der geroutete Zugriff auf Server möglichst vermieden werden soll. Die zweite Methode bietet Vorteile bei der Betreuung von Servern und der Schaffung von Backup-Lösungen (mehrere kleinere gleichartig ausgelegte Systeme können gegenseitig Backup-Funktionen realisieren).

Homogener Pool ist weniger störanfällig

Bei dieser Größenordnung macht es Sinn, die Server-Vielfalt hinsichtlich Hardware und Maschinentyp (PC, Power-PC, Unix etc.) zu reduzieren. Je einheitlicher der Server-Pool, desto geringer fällt der Aufwand für den Betrieb und für die Störfallbeseitigung aus. Einheitliche Server-Konfigurationen, einheitliche Software-Releases, gemeinsame Update-Zyklen, leichte Austauschbarkeit, gute Redundanzmöglichkeiten und geringe Ersatzteilhaltung sind Vorteile, die sofort ins Auge fallen.

Eine zentrale Server-Positionierung erfordert Hochgeschwindigkeits-Backbones und Hochgeschwindigkeits-Interfaces für Server. Bei sehr großen Geländen mit mehrfach kaskadierter Netzwerkstruktur (Koppelgerät auf der Etage, am Gebäudeausgang, im Backbone-Zentrum und im RZ-Zugang) kann dies zwar zu dem erforderlichen hohen Durchsatz führen, das Antwortzeitverhalten wird jedoch nicht verbessert. Remote Boot der Arbeitsplatzsysteme sollte in diesem Fall unterbleiben, das heißt, das Betriebssystem ist auf eine lokale Platte zu legen. Bei NT als Arbeitsplatz-Betriebssystem ist dies ohnehin nicht anders möglich.

Die Anforderungen an die Netz-Infrastruktur hinsichtlich Kapazität und Ausfallsicherheit werden durch zentrale Server-Konzepte deutlich erhöht. Fällt der Backbone oder RZ-Zugang beziehungsweise der zentrale Switch aus, an den die Server angebunden sind, läuft gar nichts mehr. Dies erfordert zwingend den Aufbau redundanter Strukturen - mit weiter steigenden Kosten: redundante Gebäudeanbindung an den Backbone und Einsatz redundanter Switches zur Server-Anbindung (siehe Bild 2).

Eine gleichbleibende bis wachsende Anzahl von Benutzern greift auf einen Server zu. Sie sind jedoch meist nicht mehr an einem Shared-10- oder 16-Mbit/s-LAN angebunden. Erforderlich ist eine Interface-Kapazität von 100 Mbit/s oder mehr (zum Beispiel 155-Mbit/s-ATM, zukünftig Gigabit Ethernet), mittelfristig sind auch Anforderungen für mehrere 100-Mbit/s-Adapter in einem Server zu erwarten. Die Hoffnung, daß ein 100-Mbit/s-Adapter auch 100 Mbit/s durchsetzt, trügt allerdings. Gängige Werte für NT-Server liegen zum Beispiel aufgrund der Treibersoftware zwischen 20 und 40 Mbit/s. Ein Durchsatz von mehreren hundert Mbit/s ist sicher erst zukünftig von Servern mit massivem Multiprozessor-Einsatz zu erwarten.

Nicht immer läßt sich eine Hochrüstung der Interface-Kapazität am Server ohne Probleme vornehmen: In Token-Ring-Umgebungen steht kein 100-Mbit/sStandard zur Verfügung, selbst proprietäre Implementierungen gibt es noch nicht. Wie ernst die jüngsten Ankündigungen der IBM und der High-Speed-Token-Ring-Alliance hinsichtlich einer Verfügbarkeit Ende 1998 zu nehmen sind, bleibt abzuwarten. Wird entgegen früherer Erfahrungen der gesteckte Zeitrahmen tatsächlich eingehalten, stellt sich die Frage nach den Pro-Port-Preisen für 100-Mbit/s-Token-Ring-Switches.

Sollen Server heute mit Hochkapazität betrieben werden, stehen drei Alternativen zur Wahl: Erstens eine Verbindung von Token-Ring-Segmenten mit 100-Mbit/s-Ethernet-Servern über LAN-Switches, die Translation-Brückenfunktion unterstützen. Dies ist mit einer Reihe technischer Probleme behaftet und sollte ausschließlich dann in Erwägung gezogen werden, wenn keine kaskadierte Netzsegmentierung vorliegt.

Es ist zweitens eine Verbindung von Token-Ring-Segmenten mit 100-Mbit/s-Ethernet-Servern über LAN-Switches und Router möglich. Dies ist eine technisch saubere Variante, erfordert aber getrennte Subnetzbildung für Token-Ring-Geräte und Server und bedeutet höheres Delay durch den zwingend erforderlichen gerouteten Server-Zugriff. Bei Anbindung der Server über 155-Mbit/s-ATM als dritte Variante, Anbindung der Token-Ring-Segmente an Token-Ring-LAN-Switches mit ATM Uplink und Einsatz von Token-Ring-LAN-Emulation kann eine flache Subnetzstruktur aufrechterhalten bleiben. Clients und Server gehören zum selben logischen Subnetz.

Fällt die Netzkarte eines Servers aus, so ist dieser für alle Benutzer nicht mehr erreichbar. Bei hoher Verfügbarkeitsanforderung ist daher ein redundanter Netzzugang einzurichten. Hier gibt es verschiedene Spielarten, einzelne oder redundante Netz-Interfaces mit oder ohne Hub/s an redundante LAN-Switches anzubinden - mit jeweils steigender Fehlertoleranz beim Ausfall eines Switchports, einer Switchkarte, eines kompletten Switch oder eines Server-Adapters (siehe Bild 3 bis Bild 5).

In IP-Umgebungen kann das den Anwender vor die Aufgabe stellen, Backup-Konfigurationen für die Endgeräte zu erstellen, die im Fehlerfall den Server über eine zweite IP-Adresse ansprechen. Denn verschiedene Netz-Interfaces lassen sich nicht mit derselben IP-Adresse ansprechen (IPv6 plant das zwar, gibt jedoch noch keine Implementierungshinweise für die Umsetzung).

Nicht immer sollen die Netzwerker als die Schuldigen ausgemacht werden. Zwischen 20 und 50 Prozent der Server-Ausfälle sind IDC zufolge auf Hardwaredefekte zurückzuführen. Den Löwenanteil beanspruchen hier Festplattenausfälle (55 Prozent), gefolgt von defekten Stromversorgungen (28 Prozent). Versagt ein Server seinen Dienst, so hilft nur ein Spiegel-Server, ein Standby-Server oder Cluster-Bildung (zukünftig mit NT-Servern möglich). Die Sparvariante ist hier ein vorkonfigurierter Server, der für mehrere Produktions-Server als Backup dienen kann, falls nötig in Kombination mit extern angeschlossenen RAID-Systemen, die vom Produktiv-Server an den Backup-Server umgehängt werden können. Ein Tip noch an Stromsparer: Ohne unterbrechungsfreie Stromversorgung (USV) nutzt der schönste Backup-Server nichts, wenn er über denselben Stromkreis wie der Produktiv-Server läuft!

Anhand der aufgezeigten Redundanzmöglichkeiten ist leicht erkennbar, daß zwischen einer Minimalausstattung und Vollredundanz für jeden Einfachfehler sowie Halbredundanz für Zweifachfehler gut ein Kostenfaktor von zwei bis drei liegt. Wieviel diese Sicherheit dem jeweiligen Netzbetreiber wert ist, muß jedes Unternehmen in einem oft schwierigen und rekursiven Prozeß erarbeiten (Kostenvoranschlag wird vom Controlling abgelehnt, Minimallösung wird installiert, Störfall führt zu Produktionseinbußen, Redundanz-Budget wird erhöht etc.). Ein solcher Prozeß läßt sich letztlich nur durch eine Spezifizierung und Festschreibung der geforderten Dienstgüte-Parameter für den Server- und Netzwerkbetrieb nachvollziehbar machen.

Um zunehmende Server-Zahlen mit gleichbleibender Personalstärke zu betreiben, wird der Einsatz entsprechender System-Management-Tools erforderlich. Weitere Effizienzsteigerungen lassen sich erreichen, wenn ein integriertes System- und Netz-Management-Konzept aufgesetzt wird, um Netzwerk- und Server-Überwachung zu korrelieren und gemeinsam auszuwerten. Einige Server-Management-Tools, etwa SMS oder ManageWise, lassen sich auch in Netz-Management-Plattformen integrieren.

Ein weiterer Trend im Zusammenhang mit steigender Server-Zahl und zunehmenden Datenmengen ist der Aufbau separater RZ-Netze für Backup-Zwecke. So lassen sich Benutzer-Server- und Server-Server-Kommunika- tion nutzen, so daß für Sicherungsläufe längere Zeitintervalle zur Verfügung stehen. Ob das Backup auf ein Großrechnersystem oder weitere PC- und Unix-Server erfolgt, ist abhängig von der jeweiligen Einschätzung der Plattenplatzkosten. Möglich ist - insbesondere mit den neuen OSA/390 Netzwerk-Interface-Boxen für IBM-Hosts - beides.

Um den gestiegenen Anforderungen an den Server-Einsatz in modernen vernetzten Systemumgebungen Rechnung zu tragen, sind die erforderliche Netzkapazität und Dienstgüte sorgfältig zu planen und zu spezifizieren. Grundregeln hierfür sind:

- konsistentes Netzdesign: Netzzugangskapazität der Server entspricht der Summenkapazität der Arbeitsplatzsysteme,

- angemessene Redundanzauslegung der Server: mindestens USV und redundante Anbindung an zentrale Server-Switches,

- Kontrolle der Server auf Ressourcen- oder Performance-Engpässe durch System-Management-Tools,

- Überwachung des Netzwerks auf Performance-Engpässe durch Netz-Management-Tools sowie

- Zusammenführung der Planungsprozesse für Server-Einsatz und Netzweiterentwicklung.

Angeklickt

Das Wachstum im PC-Markt führt zu immer mehr Clients. Auch deren steigende Leistungsfähigkeit stellt an die Server zunehmend höhere Anforderungen, die sich allerdings durch gute Planung in den Griff bekommen lassen. Insgesamt ist ein Trend zu Server-Pools in Rechenzentren zu beobachten. Server sind als Abteilungs-Server im Einsatz oder übernehmen bestimmte Funktionen. Allgemein gilt: Je einheitlicher der Server-Pool, desto geringer der Betriebsaufwand. Gerade zentrale Server erfordern einen High-speed-Backbone sowie redundante Strukturen. Bei der Server-Anbindung ist darauf zu achten, daß die Interface-Kapazität groß genug ist. Um eine steigende Server-Zahl mit dem gleichen Personal betreuen zu können, empfiehlt sich der Einsatz von System-Management-Tools. Nur so läßt sich die Effizienz steigern.

*Dipl.-Inform. Petra Borowka, Unternehmensberatung Netzwerke UBN in Aachen.