Netzwerke sind dynamische Gebilde, die sich bisweilen anders als geplant verhalten. Aus Sicht der Anwender steht und fällt die Qualität eines Netzwerkes mit den Antwortzeiten, innerhalb derer die Endgeräte auf die angeforderten Aktionen reagieren. Die Suche nach Gründen für lange Antwortzeiten und das Beseitigen von Engpässen kann sich zu einer langwierigen Daueraufgabe entwickeln.
Neben der Bandbreite ist die Latenz eine aussagekräftige Maßeinheit für die Performance eines Netzwerkes. Die Latenz beschreibt die Übertragungszeit zwischen Quell- und Zieladresse im Netzwerk. Normalerweise hat jeder Datenpfad eine charakteristische Latenz, die sich während eines Arbeitstages ändert oder von Teilnehmer zu Teilnehmer variiert. Dabei können zunehmende Übertragungszeiten verschiedene Ursachen im Netz haben. Häufig sind Netzwerkelemente, wie Router, Switches oder Kabel, überlastet oder schlecht konfiguriert. Ein Router mit ungenügendem Speicher oder ein Kabel ohne ausreichende Bandbreite machen sich erst dann als Flaschenhals bemerkbar, wenn die Netzlast die jeweilige Leistungsfähigkeit übersteigt. Ab diesem Wert steigt die Latenz mit zunehmendem Netzverkehr stark an.
Ist ein lokales Netz oder das Netz eines Providers mangelhaft konfiguriert, durchlaufen die übertragenen Pakete mehr Übergänge als erforderlich, wodurch sich ebenfalls ihre Laufzeit verlängert. Muß ein Netzbetreiber beispielsweise wegen eines Switch-Problems den Verkehr eines Teilnehmers umleiten, erhöht sich die Latenz aufgrund der längeren Datenpfade. Innerhalb eines Unternehmens können unzureichend konfigurierte Router die gleichen Auswirkungen haben.
Die Antwortzeit (Response) beschreibt das Zeitintervall, das zwischen dem Ende eines Ereignisses und dem Beginn der Reaktion auf dieses Ereignis liegt und reicht vom Betätigen einer Taste oder einem anderen Ereignis auf Applikationsebene bis zum Empfang der Antwort über das Netzwerk. Ein Aspekt, von der die Antwortzeit erheblich abhängt, ist somit die Latenz des Netzes. Weitere Faktoren, die die Response beeinflussen, sind das vom Anwender eingesetzte Endgerät sowie die Kapazität der Server, welche die Anfragen der Anwender bearbeiten.
Analyse der Antwortzeiten
Damit sie ihre vorhandenen Ressourcen optimal ausnutzen können, sind IT-Manager auf unternehmensweite Reports und Analysen angewiesen. Veränderte Antwortzeiten machen sich beim Anwender unmittelbar bemerkbar. Für ihn oder sie ist es die Wartezeit vom Drücken der "Enter"-Taste bis zum Erscheinen der Ergebnisse auf dem Bildschirm. So gewonnene Meßergebnisse, die auf subjektivem Empfinden beruhen, eignen sich jedoch nur bedingt für genaue Aussagen über das Netzverhalten. Sie können bei der Analyse nur als Indikator dienen. Im täglichen Betrieb sind sie trotzdem häufig der Gradmesser für den Netzwerkverwalter, der bei guter Performance weniger Anrufe von Benutzern bekommt. Da die Response-Zeiten von einer Reihe von Variablen abhängen, darunter Latenz, Verarbeitungszeit von Server und Endgerät sowie der Applikation selbst, ist sie in der Praxis nur schwer zu erfassen.
Einzelne Produkte messen jedoch Latenzen innerhalb der Server und die Antwortzeiten auf vielen unterschiedlichen Levels, wobei drei Kategorien zu unterscheiden sind.
- Die "Application Protocol Response" gibt die Transaktionszeiten des Applikations-Protokolls (beispielsweise SQL) an. Latenz oder Netzwerk-Response lassen sich durch Ping-Pakete messen, das Protokoll mit dem kleinsten gemeinsamen Nenner. Latenzmessungen mit Ping führen Probes (etwa CiscoPING oder RMON2), Router oder Server durch. Diese Ergebnisse geben dem Anwender zwar eine gute Grundlage, liefern ihm jedoch keine Angaben über das Verhalten bestimmter Applikationen oder Higher-Level-Protokolle im Netzwerk.
- Die "TCP Acknowledgement Response" beschreibt die Zeitspanne, innerhalb der eine Maschine TCP-Pakete für eine bestimmte Byte-Sequenz erkennt. Sie beinhaltet das Messen der Antwort auf künstliche Transaktionen von Protokollen einer höheren Ebene, zum Beispiel UDP, DNS oder HTML, die ein Router oder eine Probe erzeugen. Diese Technik unterstützt auch Geschäftsanwendungen wie von SAP oder Oracle. Der Anwender erhält eine Messung, die er jederzeit wiederholen kann, um Veränderungen auf Dauer zu verfolgen. Diese Lösung - etwa Cisco PTR Agent - ist jedoch auf bestimmte Applikationen und Protokolle implementierter Probes beschränkt und gibt keine direkte Beobachtung des Anwenderverhaltens. Zudem hängt die Aussagekraft des Verfahrens von der Plazierung der Probes ab, mit denen der Administrator die Antwortzeiten ermittelt.
- "Embedded Applications" sind Softwarelösungen, die vom System des Endanwenders aus die Transaktionen über das Netzwerk messen, also vom einzelnen Endgerät aus. Beispiel hierfür sind Lösungen von First Sense. Dieser neue Ansatz ist vielversprechend, da er die Ereignisse aus der Sicht des Endanwenders mißt. Er liefert eine Metrik, die fast genau mit dem übereinstimmt, was der User sieht. Es kann jedoch schwierig sein, herauszufiltern, welcher Teil der Infrastruktur genau Probleme verursacht: Hat der Anwender einfach mehr gearbeitet oder hat ein Netzwerk-Reroute den Prozeß verlangsamt? Allerdings müßten die erforderlichen Software-Probes an jedem Endgerät installiert sein, was zu erheblichem Aufwand bei Installation und Administration führen würde.
Bestätigung vom Anwender
In der Praxis sollte der Endanwender die Qualität der beschriebenen Verfahren verifizieren, beispielsweise anhand einer Langzeitaufzeichnung des gemessenen Reaktionsverhaltens am Endgerät. Diese Maßnahme ist anzuraten, da es sich bei den Tools zur Messung der Response-Zeit um relativ neue Hilfsmittel handelt. IT-Manager können so der Geschäftsleitung und den einzelnen Geschäftsbereichen beweisen, daß sie dauerhaft hohe Servicequalität liefern. Gleiches gilt für Serviceprovider hinsichtlich ihrer Kunden.
Da sich die Response-Zeiten von Applikationen nur unzureichend erfassen oder gar voraussagen lassen, arbeitet die Application MIB Working Group der Internet Engineering Task Force (IETF) (www.ietf.org/html. charters/applmib-charter.html) an einer Applikation-MIB, die von den Applikationen zur Aufzeichnung von Response-Zeiten genutzt werden kann. Damit sollen auch Router und andere Netzwerkelemente in die Lage versetzt werden, Daten über den Nutzer zu sammeln und historisch zu speichern. Zu den nutzerspezifischen Daten gehört, wann und wie lange er im Netz gearbeitet hat, dokumentiert etwa über eine Woche, einen Monat oder täglich von 8 bis 18 Uhr. Ein bereits marktreifes Beispiel hierfür liefert Net Flow von Cisco. Zwar entsprechen die Aufzeichnungen nicht exakt dem RMON2-Format, doch lassen sich verbrauchsbezogene Daten protokollieren.
Netzwerkparameter, die sich eindeutiger bestimmen lassen als die Response, darunter Latenz, Auslastung und Überlastung, eignen sich als Grundlage für Service-LevelAgreements (SLAs). In einem SLA vereinbaren Provider und Client definierte und meßbare Qualitätsmerkmale eines Dienstes, die der Provider bereitstellt. An den definierten Merkmalen muß sich der Dienstanbieter messen lassen, er hat andererseits damit auch feste Werte, mit denen er seinen Service im Streitfall objektiv belegen kann. Im Zusammenhang mit Service-Level-Agreements bedeutet Provider nicht unbedingt, daß ein externer Partner die Dienste anbietet. Auch die interne IT-Abteilung kann gegenüber den Abteilungen des eigenen Unternehmens als Provider agieren. Die wichtigsten Parameter der Service-Levels sind Verfügbarkeit, Zuverlässigkeit und Performance. SLAs stammen aus der Welt der Mainframes und erhalten in Client/Server-Umgebungen eine neue Aktualität. Allerdings sind sie in heterogenen und komplexen Architekturen deutlich schwerer zu messen und nachzuverfolgen als in einem Mainframe-Umfeld.
Bevor jedoch Provider und Client Vereinbarungen über Dienstqualitäten treffen können, muß der Administrator den aktuellen Leistungsstand des Netzwerkes ermitteln. Dazu erfassen Reporting-Lösungen unternehmensweite Profile über Auslastung, Überlastungen und Trends. Diese Analysen helfen nicht nur bei der zukünftigen Kapazitätsplanung, sondern bewahren auch vor kostspieligen Fehleinschätzungen beim Festlegen von SLAs. Arbeitet ein Netzwerk beispielsweise mit einer 40prozentigen Auslastung der Bandbreite, ließen sich Response-Zeiten, die eine 20prozentige Auslastung voraussetzen, nur mit hohen Investitionen realisieren.
SLAs über das Internet
Durch die zunehmende Internet-Nutzung für kommerzielle Anwendungen präsentieren sich Service-Level-Agreements vor einem neuen Hintergrund. Die meisten Internet-Serviceprovider (ISP) können keine Qualität ihres Dienstes über das Internet garantieren, da zu viele unkontrollierbare Faktoren eingreifen. Sie stellen ihren Teilnehmern lediglich eine Verbindung ins Internet zur Verfügung, haben aber keinen Einfluß auf die übrigen Parameter. Solange die meisten ISPs nur über Teile des Backbones verfügen, sind andere Carrier an fast jeder Interaktion über das Web beteiligt.
Diese Abhängigkeit von anderen Carriern macht es ISPs in der Regel aus technischen Gründen unmöglich, SLAs zu erteilen oder einzuhalten. Die Response-Zeit leidet bei Web-Seiten oft wegen schlechter Programmierung und begrenzter Kapazität im Zentralserver eines Content-Providers, auf den der Zugangsprovider gar keinen Zugriff hat.
Netzwerkanalyse und Report
Mitunter hängen Delays auch von der Bandbreite ab, die von anderen Carriern zur Verfügung gestellt wird. Sollte der Teilnehmer zudem ein relativ langsames Modem verwenden, liegt die niedrige Performance nicht im Verschulden eines ISPs. Trotzdem machen Teilnehmer häufig den eigenen Dienstanbieter für eine niedrige Gesamtleistung verantwortlich.
Die Folge: Sofern ein ISP nicht einen eigenen Backbone besitzt, muß er von der Garantie bestimmter Antwortzeiten absehen. Das stößt bei den Teilnehmern meist auf wenig Verständnis. Trotz der Instabilität von Services über das Internet setzen sie eine konstante Qualität und Verfügbarkeit voraus. Unternehmen, die eine Reihe von Geschäftstätigkeiten über das Internet verlagert haben, benötigen einen konstant verfügbaren Service, der sich mit dem alten monopolistischen Telekom-Modell vergleichen läßt. Maßgebliches Kriterium ist wieder das Antwortverhalten am Endgerät. Performance-Tools erleichtern dem Administrator die Arbeit, indem sie die Auslastung der Bandbreite messen und Gerätecharakeristika ermitteln. Hersteller wie Desktalk, Infovista, Micromuse, Cisco oder Concord Communications liefern die entsprechende Software.
"Network Health" von Concord ist eine komplementäre Lösung für die meisten Managementsysteme, einschließlich "Openview" von Hewlett- Packard, "Unicenter TNG" von Computer Associates und Tivolis Enterprise Software. Sie ruft aus Routern, Switches, Hubs sowie RMON- und RMON2-Agenten die Muster kritischer Leistungsprofile ab und präsentiert die Resultate in Web-basierenden grafischen Berichten über das Gesamtnetz. Die Parameter lassen sich von einzelnen Links über Switches und Router bis hin zu Anwendungen, Netzteilnehmern und Abteilungen abbilden, unabhängig vom Betriebssystem oder der Hardwareplattform.
Das Programm schreibt die statistischen Daten in eine relationale Datenbank, aus der die Daten gesichtet und in ein einheitliches Präsentationsformat gebracht werden. Neben der reaktiven Fehlererkennung erlaubt das System auch ein proaktives Management des Netzwerkes. Die Software steht in Varianten für LAN/WAN, Frame Relay, ATM, Router/Switches und Accounting zur Verfügung.
Network Health erlaubt eine Ende-zu-Ende-Sicht des Netzwerks, unabhängig von den eingesetzten Protokollen oder Betriebssystemen. Über eine benutzerfreundliche Oberfläche kann der Systemverwalter alle Komponenten im Netz des Unternehmens auf verschiedenen Ebenen überwachen, analysieren und spezifizieren. Die gewonnenen Daten lassen sich dann mit den Benutzern des Netzwerks und den eingesetzten Geschäftsanwendungen in Beziehung setzen und in Charts oder Diagrammen darstellen.
Anhand der ausgewerteten Daten lassen sich folgende Fragen beantworten:
- Wie ist der aktuelle Zustand des Netzwerks, und wie sieht dieser im Vergleich zu anderen Zeiträumen aus?
- Welche Service-Levels stehen zur Verfügung, und wie werden die Anforderungen erfüllt?
- Wer nutzt das Netzwerk, und für welche Zwecke wird es genutzt?
- Wie sieht die Performance der wichtigsten Komponenten des Netzwerks aus?
- Wo sind heute Probleme aufgetreten, und in welchen Bereichen sind in den nächsten Tagen Probleme zu erwarten?
- Wie stark werden die Ressourcen des Systems beansprucht, und wie ändern sich diese Werte?
Aussagekräftige Reports über Netzwerke und Komponenten führen zu einem besseren Verständnis der vorhandenen IT-Architektur und zeigen auf, wie sich die Ressourcen effektiver nutzen lassen. Mit Leistungsstatistiken werden die Verantwortlichen auch auf potentielle Probleme aufmerksam, die in Zukunft zu Engpässen und Beeinträchtigungen führen können.
Wird das Ziel erreicht, ganze Netzwerke statt einzelner Komponenten optimal zu beschreiben, lassen sich auch kleine, aber für die Performance relevante Änderungen im Benutzerverhalten aufspüren, die außerhalb der statistischen Regelmäßigkeiten liegen. Netzwerkanalyse- und Reporting-Tools erlauben es Administratoren, sich wieder intensiver ihren Kernaufgaben zu widmen, darunter Systemanalyse, Inbetriebnahme und Support von Geschäftsanwendungen. (hl)