Überwachung von Datendiensten

von Dr. Thomas Sinnwell

Die Bedeutung von Datendiensten wird schnell deutlich, wenn man sich die von der BITKOM prognostizierte Umsatzsteigerung von 7,1% auf 5,1 Milliarden Euro bei mobilen Datendiensten im Jahr 2008 vor Augen führt. 
Aber nicht nur im Rahmen der Mobil- und Festnetzkommunikation spielen Datendienste eine Rolle. Auch im Bereich von IT-Organisation sind Tendenzen zu dienstorientierten Architekturen zu beobachten. Ziel dieser Architekturen ist die Bereitstellung von Datendiensten, die von einer Vielzahl von Anwendungen in Anspruch genommen werden können.

Im Rahmen dieses Artikels werden einige Grundlagen und technische Gegebenheiten erläutert, die bei der Überwachung von Datendiensten zu beachten sind.

In der Nachrichtentechnik ist der Begriff Dienst im Kontext des Nachrichtenaustausches zwischen zwei Zugangsknoten eines Telekommunikationsnetzes definiert. Das Telekommunikationsnetz stellt dazu Dienste mit bestimmten Dienstmerkmalen zur Verfügung.

Bei einem Datendienst bezieht sich der Nachrichtenaustausch nicht auf den Austausch von analogen Sprachnachrichten, sondern auf den Austausch von Daten.

Datendienste werden unabhängig davon, ob es sich um Dienste handelt, die Dritten zur Verfügung gestellt werden, oder um Dienste, die unternehmensintern benötigt werden, durch eine Kette oder einen Verbund von unterschiedlichen Servern (Applikationsserver, Authentifizierungssysteme, Registrierungssysteme usw.), Netzwerk-Infrastrukturkomponenten (Switche, Router usw.) sowie ggf. separaten Datenbanken erbracht.
Je nach Datendienst können derartige Infrastrukturen über verschiedene Bereiche in einem Unternehmen oder auch über mehrere Standorte hinweg verteilt sein.

Die Überwachung von Rechnernetzen und Rechnern ist kein neues Thema. Um das korrekte Funktionieren von Rechnern zu sichern, kann man die Belastung der CPU auswerten, man kann den aktuellen Speicherbedarf ermitteln, die Größe von Auslagerungsdateien überprüfen usw. Neben diesen grundlegenden Möglichkeiten kann darüber hinaus auch der Status von Prozessen, die auf dem Rechner laufen, überwacht werden.
Die Überprüfung der Kommunikation zwischen den verschiedenen Komponenten in einer Datendienst-Infrastruktur erfolgt normalerweise durch die Überprüfung der sogenannten Transportschicht des Netzwerkes. Dafür gibt es schon seit langem geeignete Tools und Lösungen.

Derartige Überwachungsmethoden können aber nicht sicherstellen, dass ein Datendienst korrekt funktioniert!

Kommunikation in Netzwerken

Um diese Aussage untermauern zu können, ist es hilfreich, einen Blick auf die Schichtenmodelle für die Kommunikation in Netzwerken zu werfen. Die Funktionen in einer Netzwerkarchitektur sind typischerweise in Schichten organisiert. Dabei sind die unteren Schichten für die eigentliche Datenübertragung (Signale auf dem Übertragungsmedium, Sicherung der Kommunikation, Verbindung innerhalb der Netzwerke) verantwortlich, während die höheren Schichten anwendungsbezogene Aufgaben (Zugriff auf entfernte Dateien, E-Mail-Kommunikation usw.) bearbeiten.

Schichtenmodelle funktionieren derart, dass eine Schicht die Funktionalität der darunterliegenden Schicht nutzt, um eine eigene, erweiterte Funktionalität zu erbringen, die sie dann der darüberliegenden Schicht zur Verfügung stellt. Zu diesem Zweck muss sie mit anderen Instanzen derselben Schicht, aber auf einem anderen System kommunizieren.

Die Kommunikation zwischen zwei Schichten in der gleichen Ebene auf unterschiedlichen Systemen basiert auf festgesetzten Regeln. Diese Regeln werden als Protokoll bezeichnet. Das Angebot einer Schicht (n-1), das einer Schicht n zur Verfügung steht, wird als Dienst bezeichnet. Die Schnittstelle zwischen zwei Schichten wird folglich Dienstschnittstelle genannt (Bild 1). Ein wichtiges Schichtenmodell ist das ISO/OSI-Referenzmodell, das sich mit der Verbindung offener Systeme beschäftigt. In Bild 2 werden das ISO/OSI-Referenzmodell, das Internet-Modell, das auch als TCP/IP-Modell bezeichnet wird, und ein von Andrew S. Tanenbaum bevorzugtes Hybrid-Modell (1, Seite 62) dargestellt. Das ISO/OSI-Referenzmodell hat einen hohen theoretischen Stellenwert und eignet sich hervorragend zur Diskussion von Rechnernetzen. Die damit korrespondierenden OSI-Proto-kolle konnten sich allerdings in der Praxis nicht etablieren. Beim Internet-Modell trifft das Gegenteil zu. Das Modell im engen theoretischen Sinne existiert eigentlich nicht, die entsprechenden Protokolle werden aber zahlreich angewendet (1, Seite 62). TCP/IP ist u.a. deshalb so populär, weil es auf verschiedenen Netzwerkarchitekturen für WAN, MAN oder LAN eingesetzt werden kann.

Die Protokollkommunikation findet nicht direkt, sondern über die jeweiligen Dienste statt. Auf der untersten Ebene werden die Informationen in Form von elektrischen oder optischen Signalen in einem physikalischen Medium ausgetauscht. Der Vorteil der Kommunikation über Dienstschnittstellen besteht darin, dass die Schichten nur die zur Verfügung stehenden Dienste und ihre Parametrisierung kennen müssen (2, Seite 11). Ein von einer Anwendung abgeschicktes Datenpaket durchläuft immer sämtliche Schichten des eigenen Rechners von oben nach unten, gelangt dann auf das physikalische Medium, durchläuft gegebenenfalls andere Systeme innerhalb der Netzwerktopologie und trifft dann auf dem Rechner des Kommunikationspartners ein. Dort durchläuft es ebenfalls sämtliche Schichten, allerdings von unten nach oben, bis es bei der entsprechenden Anwendung ankommt. Jede einzelne Schicht fügt während des Weiterleitens weitere Daten zum Datenpaket hinzu. Dabei handelt es sich um Protokollinformationen, die von der Partnerinstanz auf der Gegenstelle wieder entfernt und ausgewertet werden. Ein derart erweitertes Paket wird an die nächste Schicht übergeben. In dieser Schicht werden die kompletten Inhalte einfach als zu übertragende Daten behandelt, die wiederum mit Protokollinformationen erweitert werden (Bild 3).

Überwachung von Datendiensten

Zur Überprüfung der Kommunikation zwischen den verschiedenen Komponenten in einer Datendienst-Infrastruktur wird, wie bereits zuvor erwähnt, in der Regel die Transportschicht überwacht. Datendienste können auch durch Fehler in der Verarbeitungsschicht negativ beeinflusst werden. Derartige Fehler können sogar zu einem Ausfall des Datendienstes führen.

Das Funktionieren der Transportschicht ist aber lediglich eine notwendige und keineswegs eine hinreichende Bedingung für das korrekte Funktionieren eines Datendienstes.

Die Ursachen für Fehler in der Verarbeitungsschicht können vielfältig sein, z. B.:

• Fehler im Session-Handling
• Requests mit fehlerhafter Syntax
• Übertragung fehlerhafter Credentials
• Fehler beim Realisieren von Windowing
• unterschiedlicher Datenbestand zwischen Systemen eines Datendienstes

Außer durch diese Fehlerursachen können Datendienste auch in Abhängigkeit der Auslastung der Systeme beeinträchtigt werden.

Die Anlagen zur Bereitstellung von Datendiensten können sehr komplex sein und aus vielen Netzelementen ggf. von unterschiedlichen Herstellern bestehen. Die Ursachen für auftretende Probleme und Beeinträchtigungen in der Dienstqualität sind aufgrund der Komplexität solcher Anlagen nur schwer zu detektieren. Der consistec load injector and network analyzer (colina) wurde zur Überwachung von Datendiensten und zur Performance-Analyse entwickelt.

COLINA

Der Funktionsumfang bzw. das Anwendungsspektrum von colina umfasst:

• Online-Analyse des Netzwerkverkehrs der gesamten Dienstkette bzw. des gesamten Dienstverbundes
• Generierung von Alarmen bei Abweichung vom Baseline-Traffic
• Detektierung von Performance-Bottlenecks
• Ermittlung der oberen Lastgrenze eines Datendienstes
• automatische Auswertung vom Lasttests
• Offline-Analyse
• aktive Lasterzeugung zur Analyse und Optimierung der Dienstkette bzw. einzelner Komponenten der Kette

Funktionsprinzip

Alle für die Auswertung und Analyse des Datendienstes relevanten Netzwerkdaten werden durch eine colina-Trace-Komponente mitgeschnitten.
Dabei muss zwischen physikalischen und logischen Trace-Punkten unterschieden werden. Je nach Aufbau der Datendienst-Infra-
struktur können mehrere logische Trace-Punkte durch einen physikalischen Trace-Punkt (in der Regel ein Tap + colina-Trace-Komponente) abgebildet werden. In der colina-Trace-Komponente werden die zur Analyse benötigten Kenndaten (z. B. Timestamps, IP-Adressen, MSISDNs, Session-IDs)extrahiert. Dies ist insbesondere bei Datendiensten mit hohem Datenaufkommen wichtig, damit eine Überwachung in Quasi-Echtzeit möglich ist und die Daten mit vertretbarem Aufwand langfristig archiviert werden können. Die Records mit den extrahierten Kenndaten werden von den verschiedenen Trace-Punkten zu der zentralen Einheit, dem colina-Core-Server, transferiert. Der colina-
Core-Server schreibt die Kenndaten in eine Datenbank und setzt die verschiedenen Daten in Beziehung zueinander, um unterschiedliche Analysen zu ermöglichen. Die Analysen können das Aufspüren von Anomalien, die Detektion von Bottlenecks, die Ermittlung der Systemperformance oder auch die Session-Verfolgung über alle Komponenten einer Dienstkette beinhalten (Bild 4).

Mit colina können auch Interaktionsprobleme zwischen Server-Systemen gefunden werden, die nicht im Transport-Layer, sondern im Application-Layer ihre Ursache haben.

Core-Server-Struktur

Zur Durchführung der jeweiligen Analysen muss colina mit dem notwendigen Expertenwissen bzgl. der entsprechenden Datendienste „gefüttert“ werden. Dies geschieht in Form von individueller Modul-Programmierung durch Experten von consistec. colina ist modular konzipiert, so dass die Anpassung an „neue“ Datendienste mit relativ wenig Aufwand möglich ist (Bild 5).

Offline-Analyse

Die von den Trace-Komponenten gewonnenen Dump-Files können gespeichert werden, so dass eine Auswertung der Daten auch noch nach Tagen

möglich ist. Mittels des colina-GUI-Managers lassen sich die Daten, die detaillierter untersucht werden sollen, exakt für den relevanten Zeitraum bequem herunterladen. Dies spart eine Menge Zeit und damit Kosten.

Statistiken

Der colina-GUI-Manager bietet darüber hinaus die Möglichkeit, Reports zu generieren und Überwachungsdiagramme individuell zu konfigurieren. Die Festlegung von Schwellenwerten und die Konfiguration von Trace-Punkten oder der zu liefernden Last durch das Lasterzeugungsmodul können ebenfalls komfortabel mit dem GUI-Manager erfolgen (Bild 6). 

von Dr. Thomas Sinnwell

zurück zur Artikel-Übersicht