Probes in konvergenten Netzen
Applikations- leistung sichern
Wenn heute ein einziges Wort Netzwerke und Applikationen charakterisieren könnte, dann lautet es: Komplexität. Applikationen sind komplexer denn je. Sie kommunizieren über eine Reihe von TCP-/UDP-Ports, arbeiten in einer Multi-Tier-Umgebung und wandern zunehmend von verteilten auf zentralisierte Server. Das führt zu hoher Komplexität beim Management wichtiger Business-Services. Abhilfe schafft hier nur eine tief reichende Kenntnis der Vorgänge im Netzwerk.
Die Konvergenz von Daten- und Sprachverkehr erhöht die Komplexität im Unternehmensnetz um einen
weiteren Grad. Früher waren die Netzwerke für Sprache, Video und Daten getrennt, heute stehen sie
immer öfter über ein konvergentes Netzwerk bereit. Mit dem Aufkommen der IP-Telefonie versuchen
IT-Abteilungen zu beurteilen, wie sich IP-Telefonie, Bilddatenverkehr und das QoS-Management
(Quality of Service) auf die bestehenden Business-Applikationen im Netzwerk auswirken.
Die Übertragungstechnik im Netzwerk wurde ebenfalls komplexer. IT-Manager haben die
Implementierung von 10 Gigabit Ethernet, MPLS, VPNs sowie QoS-Mechanismen in der Regel für die
nächsten zwei Jahre geplant. Gigabit Ethernet, Frame Relay und ATM kommen aber weiterhin zum
Einsatz. Ob Bandbreitenbedarf, Netzwerkmissbrauch oder neue Applikationen eine Umstrukturierung des
Netzwerks erfordern, ist ohne konkrete und detaillierte Kennzahlen zur Nutzung mehr Kunst als
Wissenschaft.
Eine besondere Herausforderung besteht darin, dass die meisten Anwender die Helpdesk-Mitarbeiter
anhand der Beschreibung von Geschäftsaktivitäten über ihr Problem informieren, wie zum Beispiel "
Das E-Mail ist langsam" oder "Es dauert ewig, bis die CRM-Applikation reagiert". Beispiele wie
diese belegen, wie wichtig ein systematischer, ganzheitlicher Einblick in alle Applikationen ist,
um Probleme zu erkennen und zu beheben, Kapazitätsänderungen zu planen und Reaktionszeiten zu
minimieren.
Absolut notwendig sind Informationen zu TCP- und UDP-Aktivitäten, aber auch zu Fällen, in denen
zum Beispiel HTTP im Vergleich zu DNS oder FTP den größten Teil der Netzbandbreite in Anspruch
nimmt (siehe Kasten auf Seite 41). Diese Informationen geben Netzwerkmanagern und
Applikationsentwicklern Einblick darin, wie Mitarbeiter das Netz nutzen und inwieweit
netzwerkbasierte Dienste wie etwa DNS-Lookups den Erwartungen entsprechen.
Eine Managementlösung für die Netzwerk- und Applikationsleistung sollte bestimmte Kernfunktionen
aufweisen. Sehr wichtig ist, dass die Lösung für konvergente Netze ausgelegt ist. Auch die
Flugsicherung nutzt nicht jeweils ein eigenes Tracking-System pro Fluggesellschaft, da alle den
gleichen Luftraum nutzen. Dieses Prinzip sollte auch für Sprach-, Video- und Datenapplikationen im
selben Netzwerk Anwendung finden. Der IT-Verantwortliche muss alle Applikationen gleichzeitig
analysieren und anzeigen sowie die entsprechenden Daten sammeln können. Weitere Anforderungen
lauten wie folgt:
Identifizieren und Entdecken sämtlicher Applikationen, ob weit verbreitet,
komplex, intern entwickelt oder webbasiert, wie etwa SAP, Citrix, IP Multicast, HTTP und
Peer-to-Peer,
Aufzeigen aller Quell- und Zieladressen der Applikationsanwender,
Sicht auf Applikationen gemäß QoS-Klassen (unterschieden nach Differentiated
Services Code Point, DSCP),
Aufzeigen der Applikationen nach Segment wie zum Beispiel
Gigabit-Ethernet-Verbindung, nach Virtual Circuit wie etwa VLAN und zugleich nach QoS,
Echtzeitsichten und historische Reports bei einfacher Navigation zwischen den
Zeitrahmen,
Überwachung der Sprachapplikationen und -protokolle wie RTP (Real-Time
Transport Protocol) und SIP (Session Initiation Protocol) ebenso wie proprietärer Protokolle von
Herstellern wie Avaya und Cisco,
Bereitstellen vielfältiger kostengünstiger Instrumentierungsoptionen zur
Abdeckung der verschiedenen Netzwerkteile,
Analysieren und Zusammenstellen der gesammelten Daten hinsichtlich häufigster
und geringster Applikationsnutzung, unabhängig von Instrumentierung und Topologie,
Alarme zur Applikationsnutzung, beispielsweise bei Übersteigen der
50-Prozent-Marke der Segmentbandbreite durch den HTTP-Verkehr oder einer Drei-Prozent-Marke bei
einer Peer-to-Peer-Applikation wie Kazaa,
Analysieren der Reaktionszeiten einer Applikation vor und nach der
Implementierung von Sprachdiensten, um die Business-Services und SLAs (Service Level Agreements)
der Abteilungen im Fall der Migration auf konvergierte Dienste zu gewährleisten.
Eine einheitliche Lösung umfasst die passive, applikationserkennende Instrumentierung mit
aktiven Agenten und eine anspruchsvolle Performance-Analyse. Nur dies gewährt den bestmöglichen
Einblick und die Analyse der Aktivitäten von Layer 2 bis 7. So lassen sich interne SLAs mit
Abteilungen und Niederlassungen erstellen, konfigurieren und verwalten. Als Kennzahlen dienen die
Bereitstellung über das Netzwerk gemäß QoS-Priorität, die zugesicherte Bandbreite und die
geschäftliche Nutzung des Unternehmensnetzes. Zudem erfordert dieser Ansatz weniger Werkzeuge für
die unternehmensweite Verwaltung der Applikationen. Dies steigert die Produktivität der
IT-Mitarbeiter, Instandhaltungs- und Gesamtbetriebskosten (TCO) lassen sich senken.
Ein weiterer positiver Effekt ist der breite, aber kontrollierte Zugang zu Berichten. So können
das IT-Team und sein Gegenpart auf der Business-Seite Probleme gemeinsam lösen. Beispiele:
Finanzmanager, die Budgetanfragen genehmigen, oder Niederlassungsleiter, die die
Netzwerkaktivitäten an ihrem Standort besser verstehen möchten.
Vom Alltagsproblem zur Erkenntnis
Vor der Entscheidung über die Bereitstellung von Business-Services über das Netzwerk müssen
bestimmte, mehr oder weniger detaillierte Informationen vorliegen. Noch früher sollte ein
Unternehmen klären, welcher Art diese Entscheidungen sind: Die Einführung neuer
Business-Applikationen wirft die Frage auf, ob die Bandbreite im Netz oder für den WAN-Zugang in
der Zentrale, im Rechenzentrum und an den entfernten Standorten ausreicht. Ein Beispiel: Die für
Applikationen zuständige Gruppe einer Bank fügte regelmäßig neue Services hinzu, ohne andere
IT-Abteilungen vorab zu informieren. Daraufhin implementierte ein betroffener Administrator eine
Probe vor seiner Serverfarm. Sie überwacht alle Anwendungen und erkennt eine neue Applikation
sofort.
Ein weiterer Problemkreis ist die Unterscheidung, ob die Ursache für das Absinken der
Antwortzeiten beim Netzwerk oder beim Applikationsserver liegt. So war zum Beispiel eine große
Gesundheitsorganisation, die eine anspruchsvolle Software zur Verwaltung elektronischer
medizinischer Daten einsetzt, mit Reaktionszeiten von über zehn Sekunden konfrontiert. Es war eine
Herausforderung festzustellen, ob der Server oder die Applikation die Verzögerung verursachte. Eine
Layer-7-Probe mit eingebetteter passiver und aktiver Reaktionszeitanalyse konnte die Applikation
als Ursache der Verzögerung ermitteln. Auf dieser Grundlage konnte die Organisation den
Applikationshersteller zwingen, einen Patch zu entwickeln, um das Problem zu beheben.
Die Einführung von IP-Telefonie führt zur Entwicklung interner SLAs zwischen der IT-Abteilung
und den Geschäftsbereichen, um die hochwertige Bereitstellung von Sprach- und Datenapplikationen zu
gewährleisten.QoS-Management dient häufig dazu, SLAs einzuhalten – reicht aber mitunter nicht aus.
Zum Beispiel hatte eine Finanzapplikation trotz QoS-Regelung deutliche Probleme. Der Probe-Einsatz
machte sichtbar, dass beinahe alle Anwendungen eine hohe QoS-Klasse erhalten hatten, sodass
Qualitätseinbußen auftraten. Aus der Praxis sind dies nur einige Ansätze, um Probleme anhand von
mehr Einblick in alle sieben OSI-Schichten zu lösen.
Lesen Sie mehr zum Thema
