Dem Performance-Verlust auf der Spur

12.06.2006
Von Veiko Graeveling 
Die Deutsche Post AG kann die verschlungenen Wege einer Transaktion verfolgen und charakterisieren - sowohl bei akuten Problemen als auch prophylaktisch vor der Einführung einer Anwendung.

Wie in immer mehr Unternehmen richtet sich auch bei der Deutschen Post das Service-Management nach dem Itil-Regelwerk (IT Infrastructure Library). Das bedeutet im Kern: Aus System- und Netz-Management wird Business-Service-Management. Der oberste Maßstab für das Überwachen, Analysieren und Gestalten der Systeme und Netze ist also der, ob ein Softwaredienst so bereitgestellt wird, dass die Anwender ihre Arbeit ungehindert erledigen können.

Projektsteckbrief

Mehr zum Thema

www.computerwoche.de/

566746: Raus aus der Kostenfalle;

576443: Die meisten Server sind schlecht ausgelastet;

565455: Serviceanbieter sezieren Websites.

Phänomen des Flaschendrehens

Dieses Prinzip umzusetzen ist jedoch leichter gesagt als getan. Denn die erforderliche Herangehensweise steht quer zu den Blickwinkeln der einzelnen IT-Abteilungen. So die Erfahrung der Abteilung IT-Service-Management bei der Deutsche-Post-Division IT Brief in Dresden. Werden die IT-Abteilungen etwa mit dem Symptom "schlechte Antwortzeiten" konfrontiert, so nehmen sie sofort ihre Mess- und Analysewerkzeuge für Netze, Server, Anwendungen und Datenbanken in die Hand, lassen dabei aber gern die ganzheitliche Analyse des Problems außer Acht. Typisch ist dabei das Phänomen des Flaschendrehens: Jede Abteilung stellt fest, dass ihre Messwerte in Ordnung sind, und gibt das Problem zurück in die Runde. Es hilft also wenig, die einzelnen Komponenten isoliert zu untersuchen.

Das Netz allein ist selten schuld

Performance-Probleme beruhen häufig auf schwer zu durchschauenden Interaktionen von mehreren Komponenten. Deshalb muss der Weg einer Transaktion horizontal über alle Schichten und Komponenten hinweg betrachtet werden. Nur ein Bruchteil der Probleme ist zum Beispiel allein auf das Netzwerk zurückzuführen, bis zu 90 Prozent beruhen auf dem Kommunikationsverhalten der Anwendungen oder auf Kombinationen aus mehreren Faktoren.

Der Unternehmensbereich Brief der Deutschen Post betreibt zirka 120 Client-Server-Anwendungen, die an rund 3500 Standorten genutzt werden, wobei der Datenverkehr über annähernd 5000 Router und Switches läuft. Zur Performance-Analyse von Applikationen nutzte das IT-Service-Management bislang eine Reihe von Monitoring-Werkzeugen, beispielsweise das quelloffene Netz-Monitoring-Tool Ethereal und Bordmittel der Server wie TCPdump, Sun Snoop sowie Testgeräte von Acterna. Aber wenn es sich um umfangreiche Datenströme und komplexe Transaktionen handelt, reichen diese Werkzeuge nicht aus.

Zwei Probleme

Eine Schwierigkeit liegt darin, die problemrelevanten Informationen überhaupt zu finden, denn die Aufzeichnungen enthalten in der Regel zigtausende von Datenpaketen. Ein zweites Problem ist die Korrelation der Informationen: Um eine komplette Transaktion zu analysieren, muss der Anwender die Datenpakete von verschiedenen Messpunkten zusammenführen und analysieren. Schließlich gilt es ja, herauszufinden, wann welche Server-Aktionen von welcher Client-Transaktion angestoßen wurden.

Doch genau das war bei der Post wegen der Masse der Informationen teils unmöglich, teils nur mit erheblichem Zeitaufwand zu bewerkstelligen. Eine präzise Performance-Prognose bei anstehenden Veränderungen der IT-Infrastruktur war folglich nicht zu bewerkstelligen.

Deshalb suchte der Logistikkonzern eine Lösung, mit der sich umfangreiche Datenströme schnell analysieren ließen. Er entschied sich für die Software "IT Guru" von Opnet Technologies, die er von dem in Rüsselsheim ansässigen Opnet-Vertriebspartner Dakoserv erwarb.

Im ersten Schritt kam das Modul ACE (Application Characterization Environment) zum Einsatz. Auf der Basis hinterlegter Algorithmen analysiert es die aus verschiedenen Quellen erhobenen Netzdaten, wobei es das zeitliche und logische Verhalten einer Transaktion über alle Schichten und Komponenten hinweg transparent macht. Die Software wird sowohl beim Incident- und Problem-Management wie auch bei der prophylaktischen Qualitätssicherung verwendet.

Ein konkretes Beispiel

Wie sich das konkret abspielt, lässt sich anhand eines Beispiels nachvollziehen: Die Nutzer einer bestimmten Anwendung an mehreren Post-Standorten beklagten sich über unregelmäßig auftretende Performance-Probleme. Um die Transaktionen aller betroffenen Clients zu erfassen, wurden die Acterna-Geräte in Kombination mit Ethereal auf den Applikations- und den Datenbank-Server angesetzt.

Der komplette Datenstrom wurde eine Woche lang mittels Port-Spiegelung an den jeweiligen Switches abgezweigt und erfasst. Die Anwender zeichneten währenddessen auf, wann die Störungen auftraten, damit sich die Analyse später auf die relevanten Zeitabschnitte konzentrieren konnte.

Ein Problem der Datenbank

Selbst erstellte Scripts filterten anhand der IP-Adressen die Client-Datenströme sowie die Konversationen zwischen Applikations- und Datenbank-Server heraus. Denn ab einer gewissen Datenmenge bietet sich - statt des ACE-Einsatzes - ein stapelorientiertes Verfahren auf Kommandozeilen-Ebene an. Die Filterergebnisse wurden dann aber in das Tool importiert, das die Daten in das interne Format konvertierte, um sie anschließend zu analysieren.

Die grafische Darstellung der TCP-Sitzungsdauer offenbarte einige auffällig lange Sitzungen. Hier wurde auf ein "Time-Sequence-Diagramm" verzweigt, das die Konversationen zwischen den verschiedenen Anwendungsschichten im Zeitverlauf zeigt. Die Decodierung ergab, dass ein und dieselbe Datenbankabfrage unterschiedlich lang dauern konnte. Mit Hilfe der ACE-Analyse ließ sich nachweisen, woran das lag: Es handelte sich um ein Datenbankproblem.

Die Ursache für das Performance-Problem bestand in einem "Table Locking": Datenbanktabellen wurden von bestimmten Anwendungen im Rahmen von Batch-Läufen für einen längeren Zeitraum genutzt und so für den Zugriff durch andere Anwendungen gesperrt. Durch eine zeitliche Verlegung dieser Batch-Prozesse ließ sich das Problem beheben.

Vorausschauende Analyse

Aber nicht nur beim Troubleshooting ist eine ganzheitliche Performance-Analyse sinnvoll. Sie spielt auch eine Rolle bei der prophylaktischen Analyse von Veränderungen der IT-Infrastruktur. Hier wie dort ist die Anwenderperspektive der Dreh- und Angelpunkt. In die vorausschauende Analyse geht sie in Form von "Transaktionsprofilen" ein. Dabei wird zunächst dokumentiert, welche Handgriffe der Anwender wann wie oft ausübt und welche Antwortzeiten dabei gefordert sind.

Handelt es sich bei der betrachteten Anwendung um eine Auftragsentwicklung, so werden die Transaktionsprofile in Zukunft bereits zur Entwicklungszeit definiert. Sie dienen dann als Basis für andere qualitätssichernde Maßnahmen wie Last- und Performance-Tests. Bei der Abnahme durch das IT-Service-Management wird im lokalen Netz eine Testinstallation der Applikation installiert, und der Anwender führt die Transaktionen gemäß dem Profil aus.

Wie beim Troubleshooting werden die Datenströme gemessen, anschließend in ACE importiert und charakterisiert. Auf dieser Grundlage lässt sich berechnen, wie sich eine Anwendung unter veränderten Rahmenbedingungen im Netzwerk verhalten würde.

Bei dieser prophylaktischen Applikationsanalyse handelt es sich um eine Hochrechnung auf der Basis einzelner Parameter. Grundlage der Analyse sind also idealtypische Szenarien. Das reale Verkehrsaufkommen in einem Netz mit seinen unregelmäßig auftretenden Spitzenbelastungen bleibt dagegen unberücksichtigt.

Simulation schlägt Algorithmen

Diesem Problem ist algorithmisch nicht beizukommen, es lässt sich nur noch durch Simulation darstellen. Der Unternehmensbereich Brief wird deshalb seine Anwendungen künftig schon vor der Einführung in einer Simulationsumgebung testen. Sie bildet die eigentliche Grundlage der IT-Guru-Produktfamilie.

Mit dieser Umgebung ist ein virtuelles Modell der vorhandenen IT-Infrastruktur generierbar - inklusive Topologie, Leitungsdaten sowie bei Bedarf auch einzelner Clients und Server. Werden in dieses Modell die empirischen Auslastungswerte auf den Datenleitungen importiert, so lassen sich Veränderungen der Infrastruktur simulieren.

Bandbreite steht im Vordergrund

Bei der Deutschen Post steht die für einen Rollout benötigte Bandbreite im Vordergrund. In der Vergangenheit wurde diese Kapazitätsplanung mehr nach Gefühl und Erfahrung und außerdem häufig reaktiv betrieben, mit Hilfe der Simulation strebt das IT-Service-Management verlässlichere Prognosen an.

Dazu sollen die im Test erfassten Lastwerte einer neuen Anwendung, das typische Nutzerverhalten sowie die Anzahl der Nutzer pro Standort im Modell abgebildet werden. Das Ergebnis ist eine quasi-empirische Analyse, die im Hinblick auf einzelne Auslastungsspitzen auswertbar ist. Damit lassen sich sowohl Unter- als auch Überdimensionierung vermeiden. (qua)