Teil II: Messung und Monitoring
Radioteleskop Raisting
Inhalt von Teil II Inhalt von Teil IIInhalt von Teil II Inhalt von Teil II
KAPITEL 01 DAS MESS- UND AUSWERTESYSTEM PERMEV ... 4
01.01 EINFÜHRUNG... 4
01.02 DAS MESS- UND AUSWERTESYSTEM... 5
KAPITEL 02 PROAKTIVES KAPAZITÄTSMANAGEMENT ... 10
02.01 EINFÜHRUNG UND MOTIVATION... 10
02.02 IM BRENNPUNKT: GESAMTSYSTEMVERHALTEN AUS ENDBENUTZERSICHT... 10
02.03 AUTOMATISIERTE MESSUNGEN MITTELS PERMEV ... 12
02.04 PROAKTIVES KAPAZITÄTSMANAGEMENT... 13
02.05 ONLINE-AUSWERTUNG DER SERVERRESSOURCEN... 15
02.06 ANWENDUNGSGEBIETE... 15
KAPITEL 03 APPLICATION EXPERT ... 17
03.01 ÜBERSICHT... 17
03.02 INSTRUMENTIERUNG UND ANALYSEMETHODEN... 18
03.03 BEISPIEL:MEHRSTUFIGE CLIENT/SERVER-KOMMUNIKATION... 18
03.04 ABGRENZUNG ZU ANDEREN MESSVERFAHREN... 19
KAPITEL 04 SERVICE LEVEL MANAGEMENT ... 21
04.01 EINLEITUNG... 21
04.02 FAZIT... 21
04.03 AMDAHL ENVIEW... 22
04.04 BMC SITEANGEL... 23
04.05 CANDLE EBA*SERVICEMONITOR... 25
04.06 HP OPENVIEW VANTAGE POINTS INTERNET SERVICES... 26
04.07 KEYNOTE PERSPECTIVE... 28
04.08 MERCURY INTERACTIVE TOPAZ... 28
04.09 SERVICE METRICS WEBPOINT... 29
04.10 TIVOLI WEB SERVICE MANAGER UND WEB SERVICE ANALYSER... 30
04.11 ABKÜRZUNGEN... 31
04.12 LINKS... 32
KAPITEL 05 UNIVERSELLER LASTGENERATOR SYLAGEN... 33
05.01 EINFÜHRUNG... 33
05.02 LÖSUNGSKONZEPT SYLAGEN... 33
05.03 SYLAGEN FRAMEWORK... 34
KAPITEL 06 ANFORDERUNGEN AN MESSWERKZEUGE...37
06.01 EINFÜHRUNG...37
06.02 ALLGEMEINE ANFORDERUNGEN...37
06.03 WEITERE ASPEKTE...39
06.04 SPEZIELLE ANFORDERUNGEN HINSICHTLICH ÜBERWACHUNG...40
06.05 SPEZIELLE ANFORDERUNGEN HINSICHTLICH ANALYSE UND TUNING...41
06.06 SPEZIELLE ANFORDERUNGEN HINSICHTLICH PROGNOSE...42
KAPITEL 01 DAS MESS- UND AUSWERTESYSTEM PERMEV
BÄRBEL SCHWÄRMER
01.01 Einführung
UNIX-basierte Server-Betriebssysteme bieten von Haus aus eine Reihe von Monitoring- Werkzeugen, die es erlauben, dem Server-Verhalten auf die Spur zu kommen. Der bekann- teste Vertreter ist der sar (System Activity Reporter), der eine breite und vielfältige Perfor- mance-Analyse der wichtigsten Systemkomponenten (CPU, RAM, Festplatten) und Sys- temfunktionen (z.B. Systemaufrufe, Paging, Swapping) ermöglicht. Das Kommando mpstat dient zusätzlich zur Aufnahme von Multi-Prozessor-Statistiken. Weiterhin wird sehr häufig ps (process state) und acct (accounting) zur Ermittlung Prozess-spezifischer Daten eingesetzt. Anhand der Kommandos ipcs und df können Daten über die Ressourcen der Interprozesskommunikation (z.B. Semaphore) und die Belegung der Filesysteme ermittelt werden. Das Kommando netstat protokolliert die erhaltenen und gesendeten Netz-Pakete und unterstützt die Performance-Analyse des Netzwerks. Darüber hinaus ermöglicht bei einigen UNIX-Betriebssystemen (z.B. LINUX) das virtuelle /proc-Filesystem den Zugriff auf eine Menge von Systemdaten einschließlich prozessspezifischer Daten. Der Nachteil all dieser Monitoring-Werkzeuge besteht darin, dass sie nur unabhängig voneinander zum Zuge kommen können.
Wünschenswert ist eine automatisierte Mess- und Auswertungsumgebung, welche die Handhabung dieser Werkzeuge vereinfacht, die Aufrufe standardisiert und synchronisiert, die erhobenen Performance-Rohdaten über alle Erfassungsquellen korreliert und auswertet sowie insgesamt den Aufwand für Messung und Auswertung in Grenzen hält. Für den Ein- satz auf unterschiedlichen UNIX-Server-Plattformen hat Siemens Business Services (SBS) das System PERMEV entwickelt. PERMEV (PERformance Monitoring and Evaluation EnVironment) ist eine Mess- und Auswerteumgebung für Systeme mit UNIX-basiertem Betriebssystem, wie Reliant UNIX, SOLARIS und LINUX.
PERMEV besteht aus den Komponenten
@ Messsystem ‚monitor‘
@ Auswertesystem ‚evaluation‘
@ Präsentationssystem ‚statistics‘
Das Messsystem ‚monitor‘ sammelt Performance-Daten auf dem zu vermessenden System.
Es handelt sich dabei um Daten über die Belegung der Systemressourcen wie CPU, Haupt- speicher, Festplatten und Netzzugang. Diese Daten werden innerhalb der Auswerteumge- bung durch die Komponente ‚evaluation‘ verdichtet und tabellarisch zusammengefasst, wobei das Auswertesystem hinsichtlich der auszuwertenden Performance-Daten variabel konfigurierbar ist. Die durch das Auswertesystem erzeugten Ergebnisdaten werden nach- folgend durch die Komponente ‚statistics‘ statistisch weiter ausgewertet und aufbereitet.
Hierzu gehört die Ermittlung von Mittel- und Maximalwerten, die Berechnung von Korre- lationskoeffizienten sowie die grafische Präsentation.
Im Folgenden werden das Messsystem ‚monitor‘, das Auswertesystem ‚evaluation‘ und das Präsentationssystem ‚statistics‘ beschrieben.
01.02 Das Mess- und Auswertesystem
(a) Übersicht Gesamtsystem PERMEV
Die nachfolgende Abbildung 01-1 gibt einen groben Überblick über die einzelnen PER- MEV-Komponenten und deren Schnittstellen.
Im Messsystem ‚monitor‘ werden mithilfe des SHELL-Skripts permon und der - je nach Betriebssystem - verfügbaren Standardmesstools die Performance-Daten gesammelt und als Rohdaten in einzelnen Dateien abgelegt. Die Konfigurationsdatei permon.cfg definiert, welche Tools aufgerufen werden. Eine Messung erfolgt über einen in Messintervalle ge- gliederten Messzeitraum. Am Schluss einer Messung werden diese Daten in der Archivda- tei komprimiert verpackt.
Im Auswertesystem ‚evaluation‘ werden mithilfe des PERL-Skripts eval.pl und weiterer PERL-Moduln aus den Rohdaten über eine Vorauswertung erste Ergebnistabellen erzeugt.
Anschließend können diese Ergebnistabellen durch eine Datenverknüpfung zu weiteren Ergebnistabellen kombiniert werden. Die Vorauswertung wird gesteuert durch die Konfigu- rationsdatei preeval.cfg. Auf Basis aller Ergebnistabellen wird abschließend eine tabellari- sche Ergebnisübersicht generiert, deren Umfang über die Konfigurationsdatei eval.cfg vari- abel spezifizierbar ist. In den Ergebnistabellen und der Ergebnisübersicht sind die einzelnen Performance-Daten zeitlich den jeweiligen Messintervallen zugeordnet.
Im Präsentationssystem ‚statistics‘ erfolgt mithilfe eines MS-Excel-Makros eine weitere u.a. grafische Aufbereitung der Ergebnisübersicht. Die Konfigurationsdatei statcfg.txt legt
Abbildung 01-1: PERMEV-Ablauf- und -Schnittstellenstruktur (Darstellung für eine Einzelmessung)
(b) Das Messsystem
Aufgabe
Das Messsystem ‚monitor‘ dient zur mittel- und langfristigen Erfassung system- und an- wendungsbezogener Performance-Daten. Die Messdatensätze werden in definierbaren Abständen, d.h. den Messintervallen, mittels Standardmesstools gesammelt und in einem Ausgabefile komprimiert abgelegt. In einer Einzelmessung werden Daten von maximal einem Tag (24 Stunden, ohne Datumsüberschreitung) erfasst. Eine Langzeitmessung be- steht aus einer Folge von Einzelmessungen. Die Auswertung erfolgt ausschließlich offline.
(c) Das Auswertesystem
Aufgabe
Das Auswertesystem ‚evaluation’ kann - mit einigen Einschränkungen (s.u.) - unabhängig vom Betriebssystem des Messobjekts, d.h. des Systems, auf welchem die Messungen durchgeführt worden sind, unter Reliant UNIX, SOLARIS oder LINUX eingesetzt werden.
Voraussetzung ist eine PERL-Installation.
Das Auswertesystem nimmt an der Schnittstelle zur Komponente ‚monitor‘ Rohdaten in Form einer verpackten und komprimierten Datei entgegen und verarbeitet diese zu Ergeb- nistabellen. In diesen Ergebnistabellen werden die verschiedenen Performance-Daten den jeweiligen Messintervallen zugeordnet. Durch eine entsprechend dem Analyseziel paramet- risierbare Datenreduktion werden aus den Ergebnistabellen Performance-Daten selektiert und in einer Ergebnisübersicht abgespeichert. Die Ergebnisübersicht bildet die Grundlage für die Ergebnisdarstellung und für weitere statistische Auswertungen.
Eine Auswertung von LINUX-Messdaten unter Reliant UNIX oder SOLARIS bedarf je- doch einiger vorheriger Anpassungen. Diese betreffen das Messdaten-Archivierungs- verfahren unter LINUX (s.o.), welches Reliant UNIX- bzw. SOLARIS-kompatibel im permon-Skript zu ändern ist, sowie das C-Konvertierungsprogramm für LINUX- accounting-Daten (s.u.), welches auf dem Reliant UNIX- bzw. SOLARIS-System anzupas- sen und neu zu übersetzen ist.
(d) Das Präsentationssystem
Das Präsentationssystem ‚statistics’ dient dazu, auf Basis von MS-Excel die tabellarische Ergebnisübersicht grafisch aufzubereiten. Zudem können Korrelationen vorgegebener Per-
cpu
(meas0222, 1data.tar.Z)
0%
10%
20%
30%
40%
50%
60%
70%
80%
15:31:41 15:36:00 15:41:00 15:46:01 15:51:00 15:56:00 16:01:00 16:06:01 16:11:00 16:16:00 16:21:00 16:26:00 16:31:01 16:36:00 16:41:00 16:46:00 16:51:00
[%]
sar.%usr sar.%sys sar.%wio
Abbildung 01-2: CPU-Auslastung, Anteile von User-Prozessen, Systemoverhead und wait-I/O
memory (meas0222, 1data.tar.Z)
0 1000000 2000000 3000000 4000000 5000000 6000000
15:31:41 15:36:00 15:41:00 15:46:01 15:51:00 15:56:00 16:01:00 16:06:01 16:11:00 16:16:00 16:21:00 16:26:00 16:31:01 16:36:00 16:41:00 16:46:00 16:51:00
[kb]
sar.memused_kb sar.memfree_kb
disks (meas0222, 1data.tar.Z)
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
20%
15:31:41 15:36:00 15:41:00 15:46:01 15:51:00 15:56:00 16:01:00 16:06:01 16:11:00 16:16:00 16:21:00 16:26:00 16:31:01 16:36:00 16:41:00 16:46:00 16:51:00
[%]
sar.%dev.sd96 sar.%dev.sd32 sar.%dev.sd95 sar.%dev.sd90 sar.%dev.sd91 sar.%dev.sd92 sar.%dev.sd93 sar.%dev.sd94 sar.%dev.sd1 sar.%dev.sd16
Abbildung 01-4: Plattenauslastung
nets
(meas0222, 1data.tar.Z)
0 100 200 300 400 500 600 700
15:31:41 15:36:00 15:41:00 15:46:01 15:51:00 15:56:00 16:01:00 16:06:01 16:11:00 16:16:00 16:21:00 16:26:00 16:31:01 16:36:00 16:41:00 16:46:00 16:51:00
[1/s]
KAPITEL 02 PROAKTIVES KAPAZITÄTSMANAGEMENT
REINHARD BORDEWISCH, KURT JÜRGEN WARLIES
02.01 Einführung und Motivation
Die Hinwendung zur New Economy stellt die Unternehmen vor eine hohe Herausforde- rung. Die Geschäftsprozessketten müssen dazu durchgehend, das heißt vollständig IT- gestützt ablaufen. In dieser Form konzipiert, kommen die Geschäftsprozesse auch der Old Economy zugute. Das funktioniert allerdings nur dann, wenn alle Systeme – Netzwerk, Server, Anwendungen – im Sinne „eines“ Geschäftssystems nahtlos zusammenwirken.
Nur wie dieses nahtlose Zusammenspiel effizient und sicher auf den Weg bringen, ohne schnurstracks in Design-, Integrations-, Verfügbarkeits- und Ablaufprobleme hinein zu laufen? Zumal mit der Entwicklung eines umfassenden Geschäftssystems die Systeme, Schnittstellen und Ereignisse sich gegenseitig beeinflussen. Die Folge: Anvisierte Größen wie Skalierfähigkeit, Flexibilität, Verfügbarkeit, Performance und Dienstgüte sind nicht mehr vorhersehbar und damit nicht konkret planbar.
02.02 Im Brennpunkt: Gesamtsystemverhalten aus Endbenutzersicht
Hochverfügbarkeit, Zuverlässigkeit und Dienstgüte sind wichtige Kriterien einer modernen IT-Landschaft. Wie werden diese Kriterien messbar und damit überprüfbar und abrechen- bar? Wie können diese Anforderungen sichergestellt werden?Ein bereits früher verfolgter Ansatz ist die Überwachung der Server-Ressourcen mittels der von Siemens Business Services (SBS) Paderborn entwickelten automatisierten Mess- und Auswerteumgebung PERMEV zur Server-Langzeitüberwachung. Ein inzwischen immer mehr ins Blickfeld gerückter Aspekt ist das Systemverhalten am Client, wie es sich dem Benutzer gegenüber präsentiert. Das schließt auch die Verweilzeiten im Netzwerk und im Client ein. Subjektiven Äußerungen der Anwender über ihr langsames System können IT- Betreiber nur selten etwas entgegensetzen. Heutige Netzwerkmanagement-Tools basieren auf der Ermittlung der Auslastungsgrade der System- und Netzwerk-Komponenten. Über- wachungsmechanismen innerhalb der Anwendungen sind selten oder fehlen ganz. Konkret bemängelten die Endanwender einer Bundesbehörde die unbefriedigende Dienstgüte (das schlechte Antwortzeitverhalten) der Bearbeitung ihrer Geschäftsprozesse, so dass der Leiter
Dies war für Siemens Business Services (SBS) Paderborn die Motivation für die Entwick- lung des Referenz-PC unter MS-Windows. In der realen Infrastruktur werden auf einem exklusiv verfügbaren Client-PC business-kritische Applikationen zyklisch zum Ablauf gebracht, wobei der Endbenutzer durch einen automatischen Testtreiber simuliert wird. Der Referenz-PC beinhaltet einen solchen „Testautomat“, der einen realen Benutzer an der grafischen Oberfläche simuliert. Business-kritische Transaktionen werden in festgelegten Abständen durchgeführt und deren Antwortzeit angelehnt an die DIN 66273 ermittelt und protokolliert. Die realen Eingaben (Tastatureingaben, Mausklicks) werden erfasst und mit konfigurierbaren Wartezeiten an die Anwendung übergeben. Während der Ausführung werden die relevanten Antwortzeiten ohne Modifikation der zu überwachenden Applikati- on und ohne Rückkoppelungseffekte auf das Gesamtsystem ermittelt.
Abbildung 02-1: Gesamtsystemsicht des proaktiven Kapazitätsmanagements
Mit dem Einsatz des Referenz-PC werden die folgenden Zielsetzungen verfolgt:
@ Das Antwortzeitverhalten beliebiger Applikationen in Client-/Server-Umgebungen aus Benutzersicht wird messbar und objektiv qualifizierbar.
@ Nach Kalibrierung der Schwellwerte erkennt der Referenz-PC einen (drohenden) Leis- tungsengpass früher als der Anwender und stellt dem Administrator diese Information mittels Alerting zur Verfügung.
Trendanalysen über die vermessenen Transaktionen ermöglichen eine planerische Reaktion auf Leistungseinschränkungen.
02.03 Automatisierte Messungen mittels PERMEV
Es treten wiederkehrende Fragestellungen der IT-Betreiber auf wie:@ Das Antwortzeitverhalten ist unbefriedigend, der Transaktionsdurchsatz liegt weit unter dem tatsächlichen Lastaufkommen. Man vermutet einen CPU-Engpass, aber wie steht es mit I/O-Peripherie, Hauptspeicher und Netz?
@ Reicht die Hardware-Kapazität der System-Ressourcen und Netzbandbreiten für die nächste Ausbaustufe der Anwendungsumgebung aus?
PERMEV ist eine automatisierte Mess- und Auswertungsumgebung für den Einsatz auf unterschiedlichen Unix-Server-Plattformen - Linux, Solaris, Reliant UNIX - welche die Aufrufe von Kommandos wie z.B. mpstat, ps, acct und netstat standardisiert, synchronisiert und die erhobenen Performance-Rohdaten über alle Erfassungsquellen auswertet. Das im PERMEV-Messsystem enthaltene Monitoring-Skript ’permon’ wird zur mittel- und lang- fristigen Performance-Messung auf UNIX-Systemen eingesetzt. Für die Durchführung der automatisierten Messungen wird das komplette Messsystem wirtschaftlich von zentraler Stelle aus auf dem (den) zu vermessenden Server(n) kopiert, konfiguriert und aktiviert. Das Skript erlaubt den konfigurierbaren Einsatz der o.g. Werkzeuge und die Aufnahme von relevanten System-HW-/SW-Informationen. Es handelt sich bei den aufgenommenen Per- formance-Daten vor allem um Informationen über die Belegung der Systemressourcen wie CPU, Hauptspeicher, Festplatten und Netzzugang.
Darüber hinaus ist das Monitoring-Skript schnell und einfach um zusätzliche Messwerk- zeuge (Traces oder Statistiken) des Betriebssystems oder auch einer speziellen Anwendung erweiterbar. So ist z.B. in PERMEV ein Mess-Skript integriert worden, mit dem Perfor- mance-relevante Daten über eine ggf. installierte ORACLE-Datenbank erhoben werden können.
Neben einer Standardauswertung mit den wesentlichen Performance-Kenngrößen des ver- messenen Systems kann die Zusammensetzung dieser Ergebnisübersicht vielfältig indivi- duell konfiguriert werden. U.a. erlaubt PERMEV die Verknüpfung verschiedener Rohda- ten, so z.B. der prozessspezifischen Daten, die einerseits aus dem ps-Kommando resultieren und andererseits durch das Accounting erzeugt werden. Zusätzlich ist es möglich, Prozesse anwendungsspezifisch und damit verursachergerecht zusammenzufassen und diese Pro- zessgruppen hinsichtlich ihres Ressourcenverbrauchs auszuwerten.
Die so gewonnene Ergebnisübersicht ermöglicht die schnelle Performance-Analyse des Systems und die Lokalisierung möglicher Performance-Engpässe, so dass hieraus Ansatz- punkte für Tuning-Maßnahmen und/oder die Notwendigkeit für tiefergreifende Analysen abgeleitet werden können. Weiterhin können diese Performancedaten eine Basis zur Ablei- tung des zukünftigen Performance-Verhaltens bevorstehender Ausbaustufen oder Konfigu- rationsänderungen in der IT-Landschaft bilden.
Mit Hilfe des auf Basis von MS-Excel implementierten PERMEV-Präsentationssystems ist es außerdem möglich, die tabellarische Ergebnisübersicht grafisch aufzubereiten. Durch diese Visualisierung sind Performance-Engpässe sowie Spitzenbelastungszeiträume sofort erkennbar. So analysiert und in Übersicht gebracht, werden frühzeitig Performance- Engpässe und potenzielle Fehlerzustände im Server-Bereich deutlich. Das wiederum er- möglicht, Server und Verbindungen richtig zu dimensionieren, Tuning-Maßnahmen gezielt aufzusetzen, Verarbeitungstrends im Server-Bereich frühzeitig zu erkennen und Server- Farmen angemessen zu formieren.
02.04 Proaktives Kapazitätsmanagement
Heutige Netzwerkmanagement-Tools basieren i.d.R. auf der Überwachung der Auslas- tungsgrade der System- und Netzwerk-Komponenten und ermöglichen nur sehr einge- schränkt Detail- und Ursachenanalysen des Systemverhaltens. Ein bereits früher seitens SBS verfolgter Ansatz ist die Überwachung und Analyse der Server-Ressourcen mittels PERMEV. Ziel des Proaktiven Kapazitätsmanagements ist es, bei Verletzung der Dienstgü- te gezielt Detail- und Ursachenanalysen hinsichtlich des Verhaltens der Systemkomponen- ten zu erstellen, um den IT- und Applikationsbetreiber in die Lage zu versetzen, frühzeitig Maßnahmen einzuleiten, bevor sich ein Anwender beschwert.
Das Proaktive Kapazitätsmanagement auf Basis der Koppelung des Referenz-PC mit der bewährten PERMEV-Langzeitüberwachung bietet zusätzliche Vorteile: Die PERMEV- Langzeitüberwachung ermittelt die Ressourcenauslastung am Server und stellt eine Trend- analyse über einen vorzugebenden Zeitraum bereit. Die Messintervalle sind dabei relativ groß gewählt, um das System nicht unnötig zu belasten.
Proaktives Kapazitätsmanagement
Netz
Überwachung Alert-DaemonServer
Server-Systeme -Schwellwerte -Performance
Referenz-PCs -Antwortzeiten
...
Server Alert-Daemon
Online-Überwachung
Abbildung 02-2: Online-Überwachung von Serversystemen
Bei Schwellwertüberschreitungen am Client wird neben einem Alert an den Administrator auch zusätzlich das PERMEV-Messintervall verkürzt. Man erhält so eine höhere Granulari- tät der Messdaten. Durch die Korrelation der Messdaten mit den Antwortzeiten wird eine gezielte Ursachenanalyse des Server-Systems ermöglicht. Gleichzeitig werden für einen kurzen Zeitraum die Client-Transaktionen in verkürztem Abstand durchgeführt, um das Antwortzeitverhalten bis zu einer „Normalisierung“ detailliert zu verfolgen.
Der Nutzen für den IT- und Applikationsbetreiber liegt in der Option, frühzeitig Maßnah- men einleiten zu können, bevor sich ein Anwender beschwert. Mögliche schnelle Aktionen sind die Zuschaltung von Leistungsressourcen (Server, Netz, Applikation, verteilte Res- sourcen, ...) oder Abschalten nicht zeitkritischer Hintergrundlasten.
Bei Einsatz mehrerer Referenz-PCs, z.B. in unterschiedlichen Netzsegmenten, sind Aussa- gen zur jeweiligen Providerleistung möglich. Die gemessenen Antwortzeiten können als Basisdaten für die Überwachung von Service-Level-Agreements herangezogen werden.
02.05 Online-Auswertung der Serverressourcen
Die Statusmeldungen des Referenz-PC werden an einer eigenen grafischen Oberfläche zentral im Operating angezeigt. Um nun jedoch parallel die Auslastungsgrade der beteilig- ten Server beobachten zu können, ist eine Erweiterung der PERMEV-Funktionalität not- wendig. Analog zu den Daten des Referenz-PC werden Schwellwerte für die Auslastung der Serverressourcen CPU, Speicher, Platte und Netz definiert und in einer „Miniauswer- tung“ online erhoben und geprüft. Die Statusmeldungen werden zusammen mit denen des Referenz-PC angezeigt und ermöglichen so eine Gesamtbetrachtung der Applikationskomponenten.
02.06 Anwendungsgebiete
Außer in der beschriebenen Client-/Server-Applikation wurde das Proaktive Kapazitätsma- nagement für eine R/3-Anwendung eines großen Halbleiterherstellers adaptiert. Der Einsatz im ASP-Umfeld wird gerade vorbereitet.
P ro ak tiv e s K a p a z itä tsm a n ag e m e n t
F ire w a ll
In te rn e t D M Z F ire w a ll In tra n e t
Z u g a n g s s e rv e r fü r W e b -C lie n ts
D a te n b a n k s e r v e r A n w e n d u n g s s e rv e r ...
Ü b e rw a c h u n g s - m o n ito r
R e fe re n z -P C
S t a t u sin f o rm a t io n e n u n d M e s sd a te n
S ta tu sin f o rm a t io n e n S ta tu sin f o rm a t io n e n
S ta t u sin f o rm a t io n e n
S t a t u sin f o rm a t io n e n
W e b -C lie n ts (3 tie r-) A n w e n d u n g s d a te n
K o m m u n ik atio n
Abbildung 02-3: Kommunikation über drei Sicherheitsebenen
stellt werden. Eine Besonderheit bedeutet dabei die Kommunikation der einzelnen Kompo- nenten über die drei Sicherheitsebenen Internet, DMZ, Intranet des RZ-Betreibers.
Somit ermöglicht das Proaktive Kapazitätsmanagement ein Agieren statt Reagieren: Von der Problemerkennung zur Problemerkennung und -vermeidung!
KAPITEL 03 APPLICATION EXPERT
KLAUS HIRSCH
03.01 Übersicht
Das Tool Application Expert eignet sich gut zur Performance-Optimierung beim Betrieb von mehrstufig vernetzten Client/Server-Anwendungen. Application Expert ist ein Produkt der Firma Compuware (früher Optimal Networks). Haupteinsatzfeld ist die Analyse von verteilten Anwendungen in Bezug auf deren Laufzeitverhalten bei gleichzeitigem Aufzei- gen von konkreten Tuningansätzen.
Unmittelbarer Nutzen und Erkenntnisse beim Einsatz von Application Expert lassen sich wie folgt kategorisieren:
@ Nachweis der Gesamtlaufzeit eines konkreten Geschäftsprozesses aus Sicht des End- Users
@ Exakte Zuordnung der Zeitanteile zu den involvierten HW-Komponenten (Client, Netz, Applikationsserver, Datenbankserver) und Erkennen zeitlicher Synchronisati- onsmuster bei verteilt ablaufenden Transaktionen
@ Nachweis des Datenverkehrsaufkommens zwischen den beteiligten Komponenten
@ Gezieltes Erkennen von Tuningbedarf und -möglichkeiten bereits vor einem produkti- ven Einsatz von C/S-Anwendungen aufgrund komfortabler Facilities zur Top-down- Analyse
@ Prognose zum Laufzeitverhalten von Geschäftsprozessen bei variierender Netzbandbreite
@ Automatisierte, grafische und tabellarische Aufbereitung von Ergebnissen
Application Expert ist auf allen Windows-Plattformen einsetzbar. Die überwachten HW- Objekte können von beliebiger Art sein. Die Erfassung der Messdaten erfolgt über das Netzwerk-Interface eines PCs oder Notebooks oder durch den Import von Trace-Files von Protokolltestern oder Netzwerkmanagement-Tools. Soweit grundlegende Kenntnisse im Bereich Performance und Network-Monitoring vorliegen, ist der effiziente Umgang mit
03.02 Instrumentierung und Analysemethoden
Die Instrumentierung des Application Expert kann man für konkrete Untersuchungszwecke unterschiedlich anpassen. Durch entsprechendes Setzen von Filtern lässt sich gezielt der Datenverkehr zwischen zwei einzelnen IP-Adressen, mehreren Paaren von IP-Adressen oder auch zwischen einer IP-Adresse und allen anderen Adressen, die mit dieser Daten austauschen, mitschneiden. Es ist aber auch möglich, den gesamten Datenverkehr zu erfas- sen. Je nach Art der im Monitorsystem eingebauten Netzwerkkarte ist es so möglich im Ethernet, Fast-Ethernet, FDDI oder Token Ring zu messen.
Durch spezielle Importfeatures ist es möglich Messungen von Protokolltestern (z.B. Wan- del und Goltermann) oder Netzwerkmanagementsystemen (z.B. HP Openview) zu analy- sieren.
Neben den umgehend verfügbaren Standardergebnissen erlauben es die oben dargestellten Diagnosemöglichkeiten somit, das Laufzeitverhalten von Geschäftsprozessen Top-down zu untersuchen und ggf. einzelne Aufrufe auf Applikationsebene als besonders ressourcen- und zeitintensiv zu identifizieren.
Darüber hinaus ist es möglich, mit den Funktionen
@ Response Time Predictor das Laufzeitverhalten einer untersuchten Transaktion bei verschiedenen Netzbandbreiten analytisch zu berechnen.
@ Bandwidth Estimator die zwischen 2 IP-Adressen verfügbare Netzbandbreite experimentell zu ermitteln.
@ Latency Finder die Signallaufzeit zwischen 2 IP-Adressen zu bestimmen.
@ Comparison Report identische untersuchte Abläufe/Transaktionen automatisch zu vergleichen.
03.03 Beispiel: Mehrstufige Client/Server-Kommunikation
Nachfolgendes Beispiel zeigt die für einen Geschäftsprozess anfallenden Kommunikati- onsvorgänge zwischen einem Client, Applikationserver und Datenbankserver im zeitlichen Verlauf. Im Kasten rechts erkennt man den Inhalt eines einzelnen Datenpakets, während im Kasten unten der Inhalt dieses Datenpakets auf das HTTP-Protokoll reduziert wird. Neben dem HTTP-Protokoll können noch eine Reihe weiterer Protokolle, wie z.B SQL, FTP, SMTP u.a. analog decodiert werden.
Frame 22 at 3,49400: (434 Bytes)
potd0018.mch.sni.de:1207-->proxy.mch.sni.de:81 HTTP:
GET http://www.optimal.com/images/button1.gif TCP: Sequence Number = 6802574
|/www.optimal .com
|/images/butt on1.
|gif
HTTP/1.0..If
|-Modified- Since:
| Tuesday, 25-Aug
|-98 10:18:52 GMT
|;
Abbildung 03-1: Application Expert im Einsatz
03.04 Abgrenzung zu anderen Messverfahren
Der Einsatzschwerpunkt des Application Expert ist weniger das Aufzeichnen des gesamten im Multiuser-Betrieb von C/S-Applikationen erzeugten Netzverkehrs, sondern vielmehr der Mitschnitt und die Analyse in Bezug auf einzelne, definierte Geschäftsprozesse.
Idealerweise sollten die mit Application Expert in einer C/S-Umgebung überwachten Ob- jekte innerhalb eines Netzsegmentes liegen. Application Expert protokolliert den Datenver- kehr zwischen den beim Ablauf eines Geschäftsprozesses beteiligten Komponenten. An den überwachten Objekten - Hardware und Software - sind aufgrund dieser Art der Mess- datenerfassung keinerlei Anpassungen vorzunehmen. Es ergeben sich somit auch keine durch Mess-Overhead verursachten Rückkoppelungseffekte auf das beobachtete Ablauf- verhalten.
die direkte Auswirkung der auf diesen Komponenten verfügbaren Systemleistung auf das Laufzeitverhalten fest. Je nach Untersuchungsziel ist es dann auch möglich, die Ergebnisse mit Messdaten zu korrellieren, die zeitgleich über andere Schnittstellen (z.B. in einem Ser- ver) erfasst wurden.
Application Expert hat sich praktischen Anwendungen bestens bewährt.
KAPITEL 04 SERVICE LEVEL MANAGEMENT
STEFAN SCHMUTZ, NORBERT SCHERNER
04.01 Einleitung
Es wurden die Service Level Management Software Produkte folgender Firmen untersucht, verglichen und bewertet. Zu diesem Zweck wurden Erfahrungen beim praktischen Einsatz sowie Herstellerangaben herangezogen.
@ AMDAHL EnView
@ BMC SiteAngel
@ Candle eBA*ServiceMonitor
@ HP OpenView Vantage Points Internet Services
@ Keynote Perspective
@ Mercury Interactive Topaz
@ Service Metrics WebPoint
@ Tivoli Web Service Manager und Web Service Analyser
04.02 Fazit
Betreiber von Online-Anwendungen, die schon seit jeher ihr Geschäft mit dem Testen von Client/Server-Anwendungen machen, haben mit einer Fülle an Lösungen und Dienstleis- tungen reagiert. Da die Handhabung der Produkte wegen ihrer teils komplexen Technik einen hohen Einarbeitungsaufwand erfordert, wird Service Level Management häufig als Service angeboten. Daher gehen die Firmen vermehrt dazu über, ihre Programme nicht zu verkaufen, sondern deren Einsatz und das zugehörige Consulting zu vermieten, um auch kleineren Unternehmen ohne große Personalressourcen diese komplizierte Aufgabe abzu- nehmen. Die als Online-Service angebotenen Performance-Messungen liefern oft nur gene- relle Hinweise auf Schwachstellen. Erst die detaillierte Analyse der gesamten Infrastruktur gibt Auskunft darüber, wo genau nachgebessert werden muss. Wirklich neu ist von den
04.03 AMDAHL EnView
EnView ist eine aus mehreren Komponenten bestehende Service Level Management Lö- sung. Sie ist skript-gestützt, d.h. die Simulation relevanter Transaktionen wird über Skripte gesteuert. Dazu setzt EnView auf dem Tool PerformanceStudio der Firma Rational auf.
EnView überwacht sowohl die Verfügbarkeit als auch die Antwortzeiten beliebiger Cli- ent/Server-Anwendungen. Die Skripte können Abläufe sowohl an der Oberfläche als auch auf der Ebene des Netzwerk-Protokolls wiedergeben.
Das Produkt EnView besteht aus den Komponenten Robot, Collector, Monitor und Repor- ter. Die Robots werden an den Benutzerstandorten installiert und deren Ergebnisse in Echt- zeit an den Collector übertragen. Der Collector sammelt die Ergebnisdaten, fasst sie zu- sammen und übergibt sie zur Statusanzeige an eine oder mehrere Monitor Stationen, vgl.
Abbildung 04-1. Jeder Monitor liefert den Echtzeit-Status aller überwachten Anwendungen bzw. Prozesse. Zur Performance-Analyse und zur Prognose für Planungszwecke werden die Daten in einem Service Level Repository – einer MS SQL Server Datenbank gespei- chert.
Mit EnView Commerce bietet AMDAHL auch einen Level Management Service an, so dass sich der Kunde nicht in die komplexe Technik der Anwendung des Produktes Perfor- manceStudio einarbeiten muss.
Abbildung 04-1: Komponenten von EnView Stärken & Schwächen von EnView:
++ Unterstützung beliebiger Client/Server-Applikationen + Antwortzeiten und Verfügbarkeit aus End-User-Sicht + Reporting GUI-unterstützt
- komplexe Technik unter Einbeziehung von Fremdprodukten
- simulierte Transaktionen spiegeln nur bedingt reales Benutzerverhalten wider - - nur generelle Hinweise über mögliche Schwachstellen
04.04 BMC SiteAngel
SiteAngel verfolgt einen Ansatz, bei dem den Kunden ein Service zur Verfügung gestellt
an den Ziel-Web-Server weiter, vgl. Abbildung 04-2. Die Anfragen und Antworten werden aufgezeichnet (sog. Teaching). Diese Aufzeichnung, Critical Path genannt, kann dann von SiteAngel zu gewünschten Zeitpunkten zum Ablauf gebracht werden (Playback). Vor dem Playback besteht die Möglichkeit, die Aufzeichnung zu prüfen (Critical Path Review) und gewünschte Verfikationen, also den Service Level, sowie Reaktionen auf Unterschreitun- gen und Fehler zu definieren. Neben den Antwortzeiten wird auch das Browserverhalten des Benutzers protokolliert. Die gesammelten Daten werden in einer Datenbank abgelegt, auf die mit den unterschiedlichsten Reporting Tools browser-unterstützt zugegriffen wer- den kann.
Abbildung 04-2: Schematischer Ablauf beim Einsatz von SiteAngel Stärken & Schwächen von SiteAngel:
++ keine Client Installation + keine Programmierung + Web-gestütztes Reporting - nur für Web Applikationen
- simulierte Transaktionen spiegeln nur bedingt reales Benutzerverhalten wider
04.05 Candle eBA*ServiceMonitor
Der Ansatz bei der Service Level Überwachung beim eBA*ServiceMonitor unterscheidet sich vollständig von dem der anderen Hersteller. Die Daten werden mit Hilfe eines Applets gesammelt, das zum Client übertragen wird und sämtliche Messwerte aufzeichnet. Auf Client Seite ist keinerlei Software Installation erforderlich. Der eBA*ServiceMonitor läuft auf dem Web-Server und misst End-to-End-Antwortzeiten aus der Sicht des Anwenders, vgl. Abbildung 04-3. Auf diese Weise wird, anders als bei den weiteren hier betrachteten Werkzeugen, beim eBA*ServiceMonitor reales und nicht simuliertes Benutzerverhalten beobachtet.
Die Antwortzeit wird vom Mausklick bis zum vollständigen Aufbau des Bildes gemessen.
Neben den Antwortzeiten wird auch das Browserverhalten des Benutzers protokolliert. Die gesammelten Daten werden in Dateien oder ODBC-Datenbanken abgelegt, auf die mit den unterschiedlichsten Reporting Tools zugegriffen werden kann.
Stärken & Schwächen von eBA*ServiceMonitor:
++ keine Client Installation + keine Programmierung
- ausgefeiltes Reporting nur über third party tools (Fa. SAS)
- nur bei Web Applikationen entfällt die Beschreibung von „Transaktions“
- - Transfer eines Applets, das Daten auf Kundenrechnern sammelt, ist problematisch
04.06 HP OpenView Vantage Points Internet Services
HP OpenView Vantage Points Internet Services ist ein Produkt aus der HP OpenView Suite zur Überwachung von Service Levels. Zum Messen der Performance werden an ver- schiedenen Standorten Agenten installiert. So ist es möglich die Performance aus der Sicht des Endanwenders zu messen, ohne auf dem Client des Endanwenders spezielle Software oder ein Java Applet zu laden. An Protokollen werden die wichtigsten Internet-Services unterstützt: HTTP, Secure HTTP, DNS, FTP, SMTP, POP3, IMAP, NNTP, WAP, RADI- US, LDAP und NTP (siehe Abschnitt 04.11 ‚Abkürzungen‘). Darüber hinaus kann über- prüft werden, ob Rechner über ICMP erreichbar sind, Verbindungsaufbau zu TCP Ports möglich ist und Rechner über einen Dial-Up Service angesprochen werden können. Trans- aktionen mit mehreren HTTP-Requests sind möglich, allerdings sind die Eingaben statisch und alle Requests werden nacheinander ohne Verzögerung durchgeführt. Der Inhalt der zurückgelieferten Seiten kann automatisch verifiziert werden. Dieses Produkt ermöglicht für das HTTP Protokoll eine Kontrolle, ob der Dienst korrekt arbeitet, eine reale Nachbil- dung von Benutzerverhalten ist nicht möglich.
HP OpenView Vantage Points Internet Services definiert auf oberster Ebene Kunden (Customer), für die bestimmte Services überprüft werden. Für jeden Service (wie zum Bei- spiel HTTP, FTP etc.) können mehrere Targets angegeben werden. In der Auswertung der Messergebnisse wird Folgendes aufgeführt:
@ Targets: Jede einzelne zu überwachende Webseite oder Verbindung.
@ Services: Die Zusammenfassung mehrerer einzelner Webseiten oder Verbindungen zu einer Aussage über die Verfügbarkeit und Performance des gesamten Services. Hier kann zum Beispiel überprüft werden, wie bei mehreren überwachten Mailservern die Verfügbarkeit und Performance insgesamt war.
@ Kunden: Übersicht über die Situation für alle überwachten Services eines bestimmten Kunden.
Die Konfiguration von HP OpenView Vantage Points Internet Services erfolgt über ein übersichtliches Tool unter Windows, vgl. Abbildung 04-4:
Abbildung 04-4: Oberfläche von HP OpenView Vantage Points Internet Services Die Daten werden zentral gesammelt und gespeichert. Die Auswertung der Messdaten wird über einen Webbrowser abgefragt, hierfür ist HP OpenView Vantage Points Internet Servi- ces auf einen Internet Information Server angewiesen.
Die Daten werden in Access-Dateien gehalten, können aber auch in einer Oracle Daten- bank gespeichert werden. Der Export zu anderen Tools sollte sich somit relativ einfach realisieren lassen, zumal die ODBC-Schnittstelle für den Zugriff auf die Access-Dateien
Stärken & Schwächen von HP OpenView Vantage Points Internet Services:
++ Unterstützt alle gängigen Internet-Dienste und kann auch beliebige TCP/IP-Ports überwachen
++ Antwortzeiten und Verfügbarkeit aus End-User-Sicht + Reporting Web Browser unterstützt
+ Datenaustausch über ODBC
+ keine spezielle Software oder Applets auf dem Client des End-Users
- simulierte Transaktionen spiegeln kaum reales Benutzerverhalten sondern prüfen einzig die Verfügbarkeit des Dienstes
04.07 Keynote Perspective
Keynote’s Perspective ist ausschließlich mit einem Service für das Service Level Manage- ment vertreten. Es stellt dem Kunden einen eigenen browser-gestützten Recorder zur Ver- fügung, der nicht auf einer Skript-Sprache basiert. Die Aufnahme des Recorders muss dann an Keynote geliefert werden, welche die Aufzeichnung von sogenannten Agenten Rech- nern an Keynote Standorten in gewünschter Häufigkeit abspielen. Dort werden auch Messwerte wie Antwortzeiten, DNS-Lookup-Zeiten und weitere gesammelt und archiviert.
Ferner umfasst der Service Pager Alarme, Email und ein Diagnose Zentrum.
Stärken & Schwächen von Keynote Perspective:
+ außer der Aufzeichnung keine Aufwände des Kunden - schmales Spektrum an Performance Informationen
- simulierte Transaktionen spiegeln nur bedingt reales Benutzerverhalten wider - - für Applikationen mit variablen Seiteninhalten und Requests praktisch ungeeignet
04.08 Mercury Interactive Topaz
Topaz ist wie EnView eine skript-gestützte Service Level Management Lösung. Dazu setzt Topaz auf dem Tool LoadRunner auf, das selbst zum Produktspektrum von Mercury Inte- ractive gehört, vgl. Abbildung 04-5. Topaz überwacht sowohl die Verfügbarkeit als auch die Antwortzeiten beliebiger Client/Server-Anwendungen. Zum Sammeln der Performan- cedaten werden sogenannte Agenten eingesetzt, die programmierbar sind und auf dem Host laufen. Der Zugriff auf die ermittelten Daten ist über einen Web Browser möglich. Dabei kann über verschiedene Detailierungslevel die Ursache für vorhandene Probleme einge- grenzt werden.
Mit ActiveWatch und ActiveTest bietet Mercury Interactive auch einen Level Management Service und einen Test Service an, so dass sich der Kunde auch hier nicht in die komplexe Technik der Anwendung der Produkte Load-/WinRunner einarbeiten muss.
Abbildung 04-5: Produkt-/Service-Spektrum von Mercury Interactive Stärken & Schwächen von Mercury Interactive Topaz:
++ Unterstützung beliebiger Client/Server-Applikationen + Antwortzeiten und Verfügbarkeit aus End-User-Sicht + Reporting Web Browser unterstützt
- komplexe Technik
- simulierte Transaktionen spiegeln nur bedingt reales Benutzerverhalten wider
04.09 Service Metrics WebPoint
Service Metrics WebPoint bietet sowohl Stand-Alone-Software als auch einen Service zum Service Level Management an. Die Software besteht aus einem Agenten auf dem Kunden PC, der nach dem Start für jeden Mausklick auf dem PC Performancedaten zum vollständi- gen Aufbau der gewählten Seite in graphischer Form darstellt, vgl. Abbildung 04-6. Dabei gliedert die Auswertung die Zeiten nach Übertragungs-, DNS-Auflösungs-, Server- und
Als Besonderheit wird ein detailliert konfigurierbares Service Level Agreement Konzept mit Alarmstufen und Eskalations- bzw. De-Eskalations-Listen geboten. Gemäß den defi- nierten SL werden unterschiedliche Gruppen benachrichtigt, wenn sich die Performance verschlechtert oder verbessert.
Der Miet-Service von Service Metrics umfasst neben der Administration und der Beobach- tung der Web-Performance ein Consulting Angebot für die Analyse und Diagnose der er- mittelten Antwortzeiten.
Abbildung 04-6: Darstellung der Performance Daten in WebPoint Stärken & Schwächen von Service Metrics WebPoint:
++ differenzierte konfigurierbare und anpassbare Komponenten + ausgefeiltes graphisches Reporting
- überwacht nur Web Applikationen
04.10 Tivoli Web Service Manager und Web Service Analyser
Der Tivoli Web Server Manager misst die Response-Zeiten aus der Sicht des End-Users, ohne dass auf dem Client Software installiert oder ein Applet geladen wird. Für die Mes-
gezeichnete Transaktionen verwendet. Bei Überschreitung vorher festgelegter Grenzwerte kann eine e-Mail verschickt, ein SNMP-Trap generiert oder eine Meldung an die Tivoli Enterprise Konsole geschickt werden. Dabei ist es möglich, die vom Server ausgelieferten Seiten nach fehlerhaften Links und Inhalt (zum Beispiel Copyright, veraltete Produktbe- zeichnungen, Firmenlogo etc.) zu überprüfen.
Mit dem Tivoli Web Service Analyser können die mit dem Web Service Manager ermittel- ten Daten mit den Logfiles der Web- und Applikation-Server zusammengefasst werden.
Alle Daten werden zentral gesammelt und können mit dem Tivoli Decision Support aus- gewertet werden. Die Übertragung der Messdaten und Logfiles erfolgt über die Protokolle HTTP oder HTTPS. Dies ist wichtig, falls zwischen den verschiedenen Standorten Fire- walls und Proxy-Server im Einsatz sind. Durch die Kombination der Logfiles mit den Per- formance-Daten ist es möglich, das Verhalten der Kunden im Verhältnis zur Verfügbarkeit und Performance der Application zu betrachten. Die Messdaten werden in einer relationa- len Datenbank (Oracle oder DB2) gespeichert, so dass eine Übernahme der Daten in andere Applicationen relativ einfach implementiert werden kann. Eine Trendanalyse zur Kapazi- tätsplanung ist in dem Tool verfügbar.
Sollten die Produkte von Tivoli zum Einsatz kommen ist es ratsam, sowohl den Web Servi- ce Manager als auch den Web Service Analyser einzusetzen, da diese eng voneinander abhängen und sich in der Funktionalität gut ergänzen. Einen Service, die Verfügbarkeit von Websites online zu prüfen, bietet Tivoli derzeit nicht an.
Stärken & Schwächen von Tivoli Web Service Manager & Web Service Analy- ser:
++ Antwortzeiten und Verfügbarkeit aus End-User-Sicht + Reporting Web Browser unterstützt
+ Verwendung einer Standard-Datenbank und HTTP/JDBC zum Datenaustausch - simulierte Transaktionen spiegeln nur bedingt reales Benutzerverhalten wider -- zwei Produkte, die eigentlich nur zusammen einsetzbar sind
04.11
Abkürzungen
DNS Domain Name System FTP File Transfer Protokoll HTTP Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure
NTP Network Time Protocol POP3 Post Office Protocol Version 3
RADIUS Remote Authentication Dial-In User Service SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol WAP Wireless Application Protocol
04.12 Links
http://www.amdahl.com/de/press/2000/120900.html http://www.keynote.com/services/html/product_lib.html
http://www.exodus.net/managed_services/metrics/performance/sm_webpoint/
http://www.candle.com/solutions_t/enduser_solutions/site_performance_analysis_external/i ndex.html
http://www-svca.mercuryinteractive.com/products/topaz/
http://www.tivoli.com/products/solutions/web/
http://www.bmc.com/siteangel/index.html http://www.openview.hp.com/products/vpis/
KAPITEL 05 UNIVERSELLER LASTGENERATOR SYLAGEN
REINHARD BORDEWISCH, BÄRBEL SCHWÄRMER
05.01 Einführung
Die Komplexität vernetzter Systeme nimmt ständig zu. Es treten hier immer wiederkehren- de Fragestellungen der IT-Betreiber und -Anwender auf wie:
@ Welche Auswirkungen haben Hardware- oder Software-Umstellungen auf die Funkti- onalität, die Verfügbarkeit und die Performance des Gesamtsystems?
@ Reicht die Hardware-Kapazität der System-Ressourcen und Netzbandbreiten für die nächste Ausbaustufe der Anwendungsumgebung aus?
05.02 Lösungskonzept SyLaGen
SyLaGen (Synthetischer Lastgenerator) bietet eine voll automatisierte Steuerungs- und Lastgenerierungsumgebung für die oben genannten Anforderungen. Das Werkzeug erlaubt die Spezifizierung heterogener Lastprofile über eine einheitliche Schnittstelle für alle An- wendungsfälle. Die Erzeugung verschieden gearteter Anwenderlasten, wie z.B. File-I/O, TCP/IP-Kommunikation, HTTP-Kommunikation oder auch eine aufgezeichnete reale Kundenanwendung, wird über entsprechende Module realisiert.
SyLaGen besteht aus einer beliebigen Anzahl von Client-Agenten als Lastgeneratoren, einem oder mehreren Server-Agenten und einem Master. Die Lastgeneratoren laufen im Rahmen einer bereits installierten und konfigurierten Systemumgebung auf den Client- Systemen ab und bringen so eine definierte, reproduzierbare Last auf das Netz und die in- volvierten Server-Systeme.
Dabei können auch Konfigurationen simuliert werden, deren Hardware nicht in vollem Umfang zur Verfügung steht. Alle Testläufe bzw. Messungen werden zentral vom Master gestartet und anschließend von diesem bedienerlos gesteuert, synchronisiert, überwacht und ausgewertet. Ein Server-Agent sammelt Server-spezifische Performance-Daten.
S i em e ns B u sin e ss Se rvic es
A rc h ite k tu r A rc h ite k tu r
N e tz
C lie nt s 1 bis n S e rv e r
C lie nt A g e nt
- L as t g en e r ie r u n g - M e s s da t en -A u fn a hm e
M a s t e r
- S t eu e r u n g
- M e s s da t en -I n t e gr a t io n
S e r ve r A g e n t
- V o r -/N a c ha r b ei t en - Me s s da t en -A u fn a hm e
S y n th e ti s c h e r L a s tg e n e ra to r S y L a G e n
Abbildung 05-1: Architektur von SyLaGen
Der synthetische Lastgenerator besteht aus dem SyLaGen Framework und verschiedenen Lastadaptoren.
05.03 SyLaGen Framework
Die Aufgaben des SyLaGen Framework sind:
@ Steuerung mit der Zustandsüberwachung des Gesamtsystems und Exploration des Lastraums
@ Synchronisation der Systemuhren und der Phasen Vorbereitung und Durchführung der Messung sowie das Reporting
@ Nutzung von Adaptoren, Kommunikationsadaptern für Steuerungsaufgaben und die Lastadaptoren zur Lastgenerierung
@ Restart- und Error-Handling
@ Reporting, wie das Fortschreiben von Log-Dateien und die Dokumentation der Mess- umgebung
Dokumentation und Präsentation der Ergebnisse: Generierung der Ergebnisreports und
S ie m e n s B u s ine s s S e rvic e s
D e ta il
D e ta il--A rc h ite k tu rA rc h ite k tu r
K o n fig u ra to r M a ste r
F ile &
F ile &
P rin t P rin t A d a p to r A d a p to r
N e tz
C lie n t H T T P H T T P A d a p to r A d a p to r S e rv e r
S y L a G en F ra m e w o rk
H T T P H T T P A d a p to r A d a p to r K o m m u n iK o m m u n i--
k a tio n s k a tio n s A d a p to r A d a p to r
F ile &
F ile &
P rin t P rin t A d a p to r A d a p to r
M e s s- e r ge b n is se L a stp ro fil D e fin itio n
S y L a G e n F ra m e w o rk
K o m m u n i K o m m u n i--
k a tio n s k a tio n s A d a p to r A d a p to r A d a p to r-In te rfa c e
C lie n t C lie n t
S y n th e tis c h e r L a s tg e n e r a to r S y L a G e n
Abbildung 05-2: Detail-Architektur
05.04 SyLaGen Lastadaptor
Der SyLaGen Lastadaptor
@ ist die Realisierung der konkreten Ausprägung eines Lastgenerators,
@ dient zur Lastgenerierung durch Ausführen von Elementaroperationen, wie z.B. open (), chdir (), unlink (), read () bei File-I/O oder send (), recv () bei TCP/IP,
@ existiert in verschiedenen Realisierungen und bietet zur Lastgenerierung einen (mög- lichst) kompletten Satz von Elementaroperationen an,
@ bildet auf dem Server das Gegenstück zum die Last generierenden Client und setzt die Requests des Clients in server-lokale Ressourcenverbräuche um.
Mit SyLaGen können Tests bzw. Messungen sowohl mit fest vorgegebener Anzahl von Clients (Lastgeneratoren) als auch - in Form eines Benchmarklaufs - mit einer automatisch variierenden Anzahl von Clients durchgeführt werden. Bei einem solchen Benchmarklauf wird automatisch in der vorliegenden Systemumgebung mit dem kundenspezifisch festge- legten Lastprofil und vorgegebenem Transaktionsdurchsatz die maximale Anzahl perfor-
SyLaGen liefert umfangreiche Ergebnisdaten in Form von
@ Konfigurationsreports aller beteiligten Systeme,
@ Reports über die Ressourcen-Verbräuche aller Server-Systeme sowie
@ Statistiken über die erzeugten Lastprofile und die Bearbeitungszeiten der aktiven Cli- ents.
SyLaGen ermöglicht es, ein gegenwärtiges oder geplantes Belastungsprofil in Form einer Lastsimulation nachzubilden. So wird die Anwendung im Gesamtsystem hinsichtlich des zu erwartenden Systemverhaltens getestet. Auf der Basis des spezifizierten Belastungspro- fils können unterschiedliche Hardware- und Software-Umgebungen hinsichtlich Funktiona- litäts-, Verfügbarkeits- und Performanceveränderungen im Systemverhalten untersucht und verglichen werden. Darüber hinaus zeigen Stresstests das Systemverhalten während maxi- maler Belastung auf. Ist die konkrete Nachbildung des kundenspezifischen Belas- tungsprofils zu aufwändig, können vordefinierte Lastprofile für unterschiedliche Applikati- onen verwendet werden.
KAPITEL 06 ANFORDERUNGEN AN MESSWERKZEUGE
REINHARD BORDEWISCH, JÖRG HINTELMANN
06.01 Einführung
Ein typischer Einstieg in das Kapazitätsmanagement geschieht über die Überwachung des existierenden IT-Systems, in dem oft bereits Performance-Probleme auftreten. Hierbei wird das IT-System des Kunden zunächst vermessen und analysiert. Die Erkenntnisse münden i.d.R. in einem Tuning des existierenden Systems, um die Performance-Probleme zunächst kurz- bzw. mittelfristig zu lösen. Anschließend sollte eine Planungs- und Prognosephase folgen, um die Systemkapazitäten langfristig bedarfsgerecht zu planen. Die daraus gewon- nenen Erkenntnisse sollten wenn nötig zu einer Modifikation des Systems führen, damit Performance-Probleme im laufenden Betrieb möglichst gar nicht erst auftreten.
Die Umsetzung dieses Vorgehensmodells erfordert Methoden und Werkzeuge, die die Aktivitäten in den einzelnen Phasen unterstützen bzw. überhaupt erst ermöglichen. Hier beschreiben wir die Eigenschaften, welche sinnvoll einsetzbare Messwerkzeuge haben sollten.
06.02 Allgemeine Anforderungen
(a) Bedienbarkeit
Zur leichteren Bedienbarkeit sind folgende Funktionen wünschenswert:
@ Bedienbarkeit über Netze (remote usage, vgl. RMON-Standards)
@ weitestgehend automatisierte Mess- und Auswerteumgebungen
@ eindeutige Schnittstellen für nachgeordnete Weiterbearbeitung (z.B. Grafik, Modell- erstellung)
(b) Experimentsteuerung
Abhängig von Zielsetzung und Zielgruppe muss Folgendes gewährleistet sein:
@ Detail-/Ursachenanalyse und Ermittlung des transaktionsspezifischen Ressourcenbe- darfs: ist sowohl automatisiert als auch individuell steuerbar
Problematisch ist, dass unterschiedliche Software-Monitore z.B. unter UNIX unterschied- lich gestartet werden, unsynchronisiert ablaufen und unterschiedliche, unkorrelierte Mess- daten liefern. Eine umfassende Systemanalyse ist daher nahezu unmöglich.
Das Ziel besteht darin, automatisierte Performance-Messungen mit automatischer Auf- zeichnung und Auswertung systemspezifischer Performance-, Last- und Konfigurationsda- ten sowie Korrelation der Messergebnisse zu ermöglichen.
(c) Skalierbarkeit (u.a. Mess-Overhead) Maßgeblich hierfür ist die Zielsetzung der Messung:
@ Für die Überwachung und Globalanalyse ist es wichtig, dass der Mess-Overhead und vor allem die Menge der erhobenen Messdaten nicht zu groß werden, d.h. es müssen relativ große Messintervalle und nur wenige Messindizes festgelegt werden können.
@ Dagegen verlangen Ursachenanalysen und die Ermittlung von Last- und Performance- Daten für die Prognose gezielte und detaillierte Messungen, was i.d.R. die Erhebung von vielen und exakten Messwerten über relativ kleine Zeiträume beinhaltet.
In beiden Fällen ist es erstrebenswert, die gleichen Messwerkzeuge parametrisierbar und skalierbar einzusetzen.
(d) Konsistente Globalsicht (globaler Zeitgeber)
Plattformübergreifende Sicht
Ein umfassendes Kapazitätsmanagement beinhaltet die Analyse und Bewertung des Ge- samtsystemverhaltens aus Endbenutzersicht. Zur Durchführung von Messungen ist ein globaler Zeitgeber erstrebenswert, was allerdings in (weiträumig) vernetzten, heterogenen IT-Systemen schnell an Grenzen stößt. Für die weiterverarbeitenden Analyse- und Model- lierungwerkzeuge müssen die Messwerkzeuge die Messdaten in einem plattformneutralen Format liefern.
Zeitliche Zuordnung
Für die Verfolgung von mehrstufigen Vorgängen ist eine eindeutige zeitliche Zuordnung der einzelnen Teilschritte notwendig (globaler systemweiter Zeitgeber). Dazu sind entspre- chende Uhrensynchronisationen zu entwickeln und einzusetzen. Erst damit ist es möglich, Vorgangsdauern (Antwortzeiten) aus Teilschritten zusammenzusetzen, die auf unterschied-
06.03 Weitere Aspekte
(a) Unterschiedliche Messebenen (u.a. Netz: ISO-Ebenen;
Gesamtsystem: Applikationen und Geschäftsprozesse)
Wünschenswert ist die Analyse des Gesamtsystems aus Endbenutzersicht. Dazu sind Mes- sungen und Analysen des Systemverhaltens auf unterschiedlichen Systemebenen erforder- lich. Im Netzwerk werden häufig Analysen auf den unteren ISO-Ebenen aber auch auf Ebene 7 durchgeführt. Bei den Server-Systemen und vor allem im Gesamtsystem sind Messungen auf unterschiedlichen physikalischen Levels und auch auf logischer Ebene von Interesse.
(b) Zuordnung von logischen Elementen zu physikalischen Ressouren Ziel ist es, die Zuordnung von Geschäftsprozessen und den zu deren Abarbeitung erforder- lichen IT-Prozessen/Transaktionen zu den physikalischen Ressourcenverbräuchen herzu- stellen. Dazu sind Transaktionsverfolgung und -analyse erforderlich: Die Messungen müs- sen transaktionsorientiert erfolgen. Eine Messung von Ressourcen-Verbräuchen unterhalb der Ebene von Transaktionen (Datenpakete, Prozesse, I/O-Operationen) ist nicht ausrei- chend.
Weiter muss eine verursachergerechte Zuordnung von Ressourcenverbräuchen möglich sein: Messungen müssen applikationsorientiert erfolgen, d.h. Ressourcenverbräuche müs- sen den Applikationen und Transaktionen zugeordnet werden können. Für die Kapazitäts- planung ist z.B. eine pauschale Aussage über die gesamte Bandbreitennutzung in den Net- zen (LAN-Segment, Backbone, WAN) nicht ausreichend.
(c) Instrumentierbare Software
In vernetzten heterogenen Systemen gibt es nicht mehr den von der propriätären Welt be- kannnten klassischen ”Transaktionsbegriff”. Damit ist auch die oben aufgeführte Zuord- nung äußerst schwierig. Ein möglicher Lösungsweg ist neben der Nutzung von prozessspe- zifischen Messdaten (z.B. unter UNIX ps und acct) die Instrumentierung von Applikations- Software. Ansätze dazu werden u.a. mit ARM (Application Response Time Measurement) verfolgt, wo ein Standard API für messbare Software spezifiziert wird. Eine andere Mög- lichkeit wird mittels Hybrid-Monitoring angegangen.
(d) Sampling vs. Tracing (statistische Unabhängigkeit)
ware-Monitore liefern Übersichten darüber, wo was in welchem Zeitraum geschieht. Dabei müssen die Systembedingungen und Last relativ konstant sein, und es darf keine Abhän- gigkeit zwischen Stichprobe und Ereignis bestehen.
Tracing (event driven monitoring) bedeutet eine kontinuierliche Aufzeichnung von ausge- wählten Ereignissen mit Angabe von Ort, Zeitpunkt, Spezifikation des Ereignisses: Tracing liefert Einsichten: Was geschieht wo, wann und warum.
Je nach Zielsetzung und Aufgabenstellung müssen die unterschiedlichen Monitore sowohl im Sampling Mode als auch im Tracing Mode arbeiten.
(e) Automatisierung der Auswertung und Aufbereitung – kriterienge- steuerte Auswertung (Filterfunktionen)
Es gibt eine Vielzahl von Mess- und Analyse-Werkzeugen, die auf unterschiedlichen Ebe- nen ansetzen und häufig Insellösungen darstellen. Universell einsetzbare und automatisierte Mess- und Auswerteumgebungen sind kaum vorhanden (s.o. Experimentsteuerung).
Besonders aufwändig und arbeitsintensiv sind die Auswertung der Messdaten und deren statistische Aufbereitung. Da es sich häufig um etliche GigaBytes Messdaten handelt, müs- sen Auswertung und die statistische Aufbereitung, aber auch die Erstellung von Präsentati- onstabellen und -diagrammen voll automatisiert ablaufen. Dabei muss einerseits die auto- matische Erstellung von Standarddiagrammen möglich sein, andererseits muss die automa- tische Erstellung von individuellen Diagrammen nach vorgebbaren Konfigurations-/Filter- kriterien, wie Auswertezeitraum, Mittelwert- und Extremwertberechnungen oder automati- sche bzw. vorgebbare Korrelationsberechnungen, gegeben sein.
(f) Verlässlichkeit und Konsistenz der Messdaten
Dazu müssen alle Fehlersituationen und Ausfälle protokolliert werden, um über die Güte und Gültigkeit der Messung entscheiden zu können.
06.04 Spezielle Anforderungen hinsichtlich Überwachung
(a) Dienstgüte (Ampel-Semantik)
Für alle zu überwachenden Komponenten und Dienstgütemerkmale müssen Schwellwerte für Warnungen (gelb) und Alarme (rot) definierbar sein. Bei Erreichung der Schwellwerte sind entsprechende PopUp-Fenster zu öffnen, die den Ort und die Art der Verletzung an- zeigen.
(b) Steuerung: zentral vs. verteilt
Überwachungskomponenten sollten durch eine zentrale Konsole oder durch eine Menge von Konsolen z.B. per SNMP-Nachrichten oder entsprechend RMON-Standard ein- und ausschaltbar sein. Gleiches gilt für die Abrufung von aggregierten Ergebnissen. Die Über- tragung von einzelnen Ergebnissen zur Zentrale ist zu vermeiden, da sonst der Messverkehr zu groß wird.
(c) Aggregierung
Hier müssen Regel-Editoren vorhanden sein, mit denen es möglich ist, elementare Mess- größen zusammenzufassen und zu abgeleiteten bzw zu aggregierten Größen zusammenzu- stellen.
(d) Ergebnisdarstellung
Ergebnisse müssen sowohl in ihrer elementaren Form als auch in aggregierter Form dar- stellbar sein. Online-Visualisierung von Grafiken sollte ebenso möglich und wählbar sein wie die rein textuelle Darstellung der aktuellen Werte.
(e) Discovering (Suche nach aktiven Komponenten (IP-Adresse, MAC- Adressen, ....)
Überwachungswerkzeuge sollten in der Lage sein, aktive Netzkomponenten zu erkennen und in einer Liste darzustellen. Anschließend sollte es in einem Auswahlmenü möglich sein, die Überwachung einer Komponente ein/auszuschalten und die Größen zu definieren, die überwacht werden sollen. Darüber hinaus sollten Schranken definierbar sein, bei deren Überschreitung Warnungen/Alarme angezeigt werden, siehe auch Überwachung Dienstgü- te (Ampelsemantik).
06.05 Spezielle Anforderungen hinsichtlich Analyse und Tuning
Neben der Sicherstellung der Betriebsbereitschaft werden Werkzeuge für ein proaktives Management benötig, die das Auftreten von Engpässen so frühzeitig erkennen, dass es zu keiner Beeinträchtigung der Leistungsfähigkeit kommt. Dabei sind die folgenden Aktivitä- ten durchzuführen.
(a) Ermittlung der Auslastungsgrade
