Institut für Informatik Universität Augsburg

Institut für Informatik
Universität Augsburg
Diplomarbeit
Systemüberwachung eines Exchange
Mail-Servers
Armin Thrä
Gutachter:
Zweitgutachter:
Betreuer:
Datum:
Prof. Dr. Theo Ungerer
Prof. Dr. Bernhard Bauer
Dipl.-Inform. Wolfgang Trumler
25. Februar 2006
c
Copyright Lehrstuhl für Systemnahe Informatik und Kommunikationssysteme
Prof. Dr. Theo Ungerer
Institut für Informatik
Universität Augsburg
D–86135 Augsburg, Germany
http://www.Informatik.Uni-Augsburg.DE
— all rights reserved —
Inhaltsverzeichnis
1 Einleitung
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Zielabgrenzung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Exchange Server
3
2.1
Einführung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Architektur
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
2.4
2.2.1
Überblick
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.2
Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.3
Interprozesskommunikation
. . . . . . . . . . . . . . . . . . .
6
Exchange Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.1
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.2
Funktionsweise
. . . . . . . . . . . . . . . . . . . . . . . . . .
8
Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3 Systemüberwachung
3.1
3.2
3.3
Überblick
11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.1
Prozessor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.2
Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.3
Cache
14
3.1.4
Festplatte
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.5
Netzwerk
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.6
Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.7
Exchange
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.1
Erkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.2
Ursachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.3
Gegenmaÿnahmen
21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Leistungsprobleme
. . . . . . . . . . . . . . . . . . . . . . . .
Test eines Exchange Servers
. . . . . . . . . . . . . . . . . . . . . . .
21
i
ii
Inhaltsverzeichnis
3.3.1
Allgemeines Vorgehen
. . . . . . . . . . . . . . . . . . . . . .
22
3.3.2
Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3.3
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3.4
Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4 Konzept einer proaktiven Systemüberwachung
4.1
Überlegungen
4.2
Grundlagen
4.3
4.4
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.1
Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.2
Klassikation
. . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2.3
Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Konzepttest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.1
Verwendete Tools . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.2
Vorgehen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.3
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5 Prototyp
46
5.1
Anforderungen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.2
Implementierung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.3
Überblick
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.3.1
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.3.2
Funktionsweise
. . . . . . . . . . . . . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.4
Leistungstest
5.5
Benutzeroberäche
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.6
Schwächen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.7
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6 Erkenntnisse
59
6.1
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.2
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.3
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
1 Einleitung
1.1 Motivation
Wenn das Arbeiten mit Outlook mal wieder ewig dauert und die E-Mail Nachricht
in einer halben Stunde noch immer nicht beim Empfänger im Gebäude nebenan
angekommen ist, dann ist womöglich der Exchange Server in der Firma schuld, weil er
überlastet ist. Exchange ist ein Nachrichtenübertragungssystem der Firma Microsoft,
welches für zuverlässiges Senden, Empfangen, Speichern und Weiterleiten von E-Mail
Nachrichten zuständig ist. Des Weiteren bietet es dem Benutzer Zugrismöglichkeiten
auf Adressbücher und globale Adresslisten, sowie auf Kontakte und Termine.
Somit bildet der Exchange Server oft die Basis der elektronischen Unternehmenskommunikation. In Organisationen sind seine Leistungswerte und Verfügbarkeiten meist
in Service Level Agreements (SLA) festgeschrieben. SLAs sind Verträge zwischen dem
Management einer Organisation und z.B. einer externen Firma (Outsourcing), welche für die Einhaltung der SLAs sorgt. Bei diesen denierten Leistungswerten handelt
es sich oft um eine handhabbare Gröÿe wie z.B. Antwortzeit oder die Zeit, die zur
Auslieferung von E-Mail Nachrichten benötigt wird. Service Level Agreements geben
dem Management Planungssicherheit für deren Geschäftsprozesse und eine Diskussionsgrundlage mit dem Vertragspartner.
Verletzungen von SLAs und somit Ausfälle kosten viel Geld, da sie die Geschäftsprozesse im Unternehmen stören. Deshalb ist eine proaktive Systemüberwachung des Exchange Servers wünschenswert, welche Leistungsprobleme schon im Ansatz erkennt.
Dann kann rechtzeitig gegengesteuert werden, bevor Benutzer des Systems Ausfälle
bemerken.
Die heutzutage verfügbaren Systemüberwachungen arbeiten jedoch meistens reaktiv,
d.h. erst nach Überschreitung eines vorher festgelegten Grenzwertes. Dadurch können
Leistungsspitzen nicht mehr in die Überwachung miteinbezogen werden. Wird der
Grenzwert zu niedrig angesetzt, so kann es z.B. bei Leistungsspitzen, welche durchaus
normal sein können, zu häugen Fehlalarmen kommen. Ist er zu hoch angesetzt, so
können Probleme erst dann erkannt werden, wenn es vielleicht schon zu spät ist.
1
2
Einleitung
1.2 Zielabgrenzung
Ziel dieser Diplomarbeit ist die Entwicklung eines Konzeptes zur proaktiven Systemüberwachung eines Exchange Mail-Servers der Firma KUKA. Dieses Konzept soll in
einem Cockpit implementiert werden, welches möglichst intuitiv Auskunft über den
aktuellen Zustand des Systems gibt und bei kritischen Zuständen frühzeitig Alarm
schlägt. Es soll den Administrator des Exchange Servers dabei unterstützen, um möglichst früh Leistungsprobleme des Systems zu erkennen.
1.3 Aufbau
Zunächst wird in Kapitel 2 ein Überblick über die Komponenten eines Exchange
Servers gegeben. Anschlieÿend wird auf deren Funktionsweise eingegangen. Der Abschluss dieses Kapitels bildet die Ableitung von Konsequenzen für den reibungslosen
Betrieb eines Exchange Servers, die sich aus der Funktionsweise der einzelnen Komponenten ergeben.
Kapitel 3 beschäftigt sich mit dem Thema Systemüberwachung. Zuerst wird auf wichtige Leistungssensoren eines Exchange Servers eingegangen und was damit gemessen
werden kann. Danach erfolgt eine Beschreibung, anhand welcher Sensoren Leistungsprobleme identiziert werden können und wie deren Ursachen ausndig gemacht werden. Anschlieÿend wird ein Exchange Server mit unterschiedlichen Benutzerzahlen
und Kongurationen getestet und die dabei gewonnenen Ergebnisse bewertet.
In Kapitel 4 wird ein Konzept einer proaktiven Systemüberwachung entwickelt. Zunächst werden Überlegungen angestellt, wie ein solches Konzept aussehen könnte.
Danach werden die für seine Durchführung benötigten Techniken beschrieben. Abschlieÿend wird das Konzept an Realdaten eines Produktivservers der Firma KUKA
getestet und die Ergebnisse ausgewertet.
Der Prototyp eines Cockpits, der das in Kapitel 5 entwickelte Konzept implementiert,
wird in Kapitel 5 vorgestellt. Den Anfang bildet eine Beschreibung der Vorgaben,
die an den Prototypen gestellt werden. Danach wird beschrieben, was das Cockpit
leistet und aus welchen Komponenten es aufgebaut ist. Zum Abschluss wird auf die
Funktionsweise des Prototypen eingegangen.
2 Exchange Server
In den folgenden Kapiteln wird zunächst ein Überblick über den Aufbau und die
Funktionsweise eines Exchange Servers gegeben. Den Schluÿ bildet die Erörterung
von Konsequenzen, die sich daraus ergeben. Die in diesem Kapitel verwendeten Informationen stammen hauptsächlich aus [Tea04].
2.1 Einführung
Der Exchange Server 2003 ist ein Nachrichtenübertragungs- und Groupware-System
der Firma Microsoft in der aktuellen Version. Es bietet diejenigen Leistungsmerkmale,
welche ein modernes Nachrichtenübertragungssystem braucht:
•
Die zuverlässige Übertragung von E-Mails an Empfänger auf dem lokalen Server
und die Weiterleitung an Empfänger, welche ihr Postfach auf einem anderen
Server haben.
•
Die Bereitstellung eines Adressbuches für Benutzer über die Empfänger einer
Organisation.
•
Eine zuverlässige Speicherung von E-Mails.
•
Es bietet für verschiedene Clients Zugri auf Nachrichten, etwa durch POP3
oder IMAP4.
Als Frontend-Applikation kommt meist Outlook 2003 zum Einsatz, ein weiteres Produkt der Firma Microsoft. Outlook kommuniziert mit dem Exchange Server über
MAPI, ein proprietäres Remote Procedure Call (RPC) Protokoll. Der Exchange Server kann aber auch über das Internet über die Outlook WebAccess Schnittstelle
oder jedem SMTP oder IMAP fähigen Client benützt werden, dann allerdings mit
eingeschränktem Funktionsumfang.
Zu Microsoft Exchange Server existieren viele Konkurrenzprodukte, wie z.B. Lotus
Notes/Domino, Novell Groupwise oder die Open Source Alternative Open-Xchange
(vgl. [de.06b]).
3
4
Exchange Server
2.2 Architektur
2.2.1 Überblick
Um die Anforderungen eines modernen Nachrichtenübertragungssystems zu erfüllen,
bietet der Exchange Server eine Verzeichniszugris Komponente, eine Nachrichtentransport Komponente und einen Informationsspeicher (siehe Abbildung 2.1). Es wird
beschrieben, welche Aufgaben diese drei erfüllen, wie sie aufgebaut sind, wie sie funktionieren und von welchen Windows Komponenten sie abhängen.
Abbildung 2.1: Exchange Server Architektur Quelle : [Tea04]
2.2.2 Komponenten
• Verzeichniszugri Komponente: Die Verzeichniszugris Komponente bietet
für Exchange Komponenten Zugri auf den Verzeichnisdienst eines Microsoft
2003 Servers, das Active Directory (AD). Dort sind Benutzer- und Kontaktdaten, Adresslisten, Routing - und Sicherheitsinformationen, sowie Kongurationsdaten des Exchange Servers gespeichert. Sie besteht aus zwei Komponenten:
DSAccess:
Steuert den Zugri anderer Exchange Komponenten auf das
Active Directory
DSProxy: Stellt einen Adressbuchdienst für MAPI Clients bereit
2.2 Architektur
5
Diese beiden Komponenten sind in der Exchange Systemaufsicht, welche unter
dem Prozess mad.exe läuft, implementiert.
• Transportmodul:
Zuständig für die Übertragung von E-Mail Nachrichten an
die richtigen Empfänger ist das Transportmodul. Es besteht aus mehreren Komponenten:
SMTP Modul: Zuständig für die SMTP Kommunikation
Informationsspeichertreiber:
Zuständig für die Kommunikation mit
der Exchange Datenbank und die lokale Auslieferung von E-Mail Nachrichten
Kategorisierungsmodul:
Zuständig für die Auösung von Empfänger-
listen
Routingmodul: Zuständig für die korrekte Auslieferung von ausgehenden
E-Mails an andere Server
Erweitertes Warteschlangen Modul:
Zuständig für korrekte Über-
mittlung, Weiterleitung und Weitergabe von E-Mail Nachrichten. Es benützt dabei die oben genannten Module.
Alle eingehenden Nachrichten gelangen zuerst in das erweiterte Warteschlangen
Modul. Dort durchlaufen sie eine Reihe von Ereignissenken, wodurch verschiedene Aktionen ausgelöst werden. Diese veranlassen z.B. das Kategorisierungsmodul, Empfängerlisten aufzulösen. Hat nun der Empfänger einer Nachricht
sein Postfach auf dem selben Exchange Server, wie der Absender, so liefert der
Informationsspeichertreiber die Nachricht lokal aus. Andernfalls wird sie per
SMTP an den entsprechenden Server gesendet.
Auf einem Exchange Server 2003 ist das Transportmodul im SMTP Dienst implementiert und wird durch diesen gesteuert. Der SMTP Dienst läuft in der
Arbeitsumgebung des Prozesses inetinfo.exe, des so genannten Internet Informations Dienstes (IIS), und ist von diesem abhängig. IIS stellt ProtokollUnterstützung für Protokolldienste, wie z.B. SMTP, POP3 oder IMAP4 bereit,
d.h. ein Exchange Server kann durch IIS über diverse Protokolle mit anderen
Servern kommunizieren.
• Informationsspeicher:
Der Informationsspeicher ist zuständig für die zuver-
lässige Speicherung von E-Mail Nachrichten und die Entgegennahme von Nachrichten im MAPI Format. E-Mails im MIME Format werden dabei in einer
Streaming Datenbank (STM Datei), E-Mails im MAPI Format und Eigenschaften von MIME Nachrichten in einer MAPI Datenbank (EDB Datei) gespeichert.
Das bedeutet, dass die STM Datei den Inhalt von Nachrichten im MIME Format
6
Exchange Server
enthält, auf den durch EDB Einträge verwiesen wird. Diese beiden Datenbanken
müssen synchronisiert gespeichert sein und können auch nicht getrennt werden.
Zur Verwaltung der MAPI Datenbank, sowie den Zugri darauf, benützt der
Informationsspeicher die ESE Technologie.
Der Zugri auf die Streaming Datenbank erfolgt durch ExIFS (Exchange Installable File System). Es stellt die dort gespeicherten Nachrichten als Dateien
dar und bietet die Möglichkeit, sie einfach auszulesen, zu ändern, neu anzulegen oder zu löschen. ExIFS wird vom Informationsspeicher und IIS verwendet,
um Objekte in die Streaming Datenbank zu schreiben, oder Objekte aus der
Streaming Datenbank zu lesen (vgl. [Coc02]). Dabei muss ExIFS mit dem Informationsspeicher kommunizieren, damit die EDB und STM Dateien synchron
bleiben. Um die Anforderungen zu erfüllen, die ESE und IIS an ExIFS stellen,
verwendet ExIFS den Windows Dateisystemcache.
Der Informationsspeicherdienst wird im Prozess store.exe ausgeführt und ist
von ExIFS abhängig.
2.2.3 Interprozesskommunikation
Beim Exchange Server ist die Datenbank von den Protokollen getrennt (siehe Abbildung 2.2), d.h. die Exchange Datenbank und IIS stellen unterschiedliche Prozesse dar,
die in verschiedenen Arbeitsumgebungen laufen. Dies erhöht die Stabilität und die
Flexibilität des Exchange Servers. Ein Prozess darf aber nicht auf den Speicherbereich
eines anderen zugreifen.
Die Interprozesskommunikation (IPC) zwischen Informationsspeicher und IIS muss
deshalb durch einen gemeinsamen Speicherbereich, die EPOXY-Schicht, erfolgen.
Über diese kann der Informationsspeichertreiber (DrvIIS.dll), welcher im Kontext des
IIS ausgeführt wird und für die lokale Auslieferung von E-Mails zuständig ist, mit dem
Informationsspeicher kommunizieren. Auf dessen Seite übernimmt ExSMTP.dll die
Kommunikation mit Drviis.dll und der Exchange Datenbank.
Möchte der Informationsspeichertreiber nun eine Nachricht speichern, dann schreibt
er sie durch ExIFS direkt in die Streaming Datenbank und erhält von ExIFS den
Speicherort der Nachricht zurück. Diesen platziert er in EPOXY und informiert damit
den Informationsspeicher über die neue Nachricht. Der Informationsspeicher kann
nun die Nachricht mitsamt ihrem Speicherort z.B. im Ordner Gesendete Objekte
eintragen.
2.3 Exchange Datenbank
7
Abbildung 2.2: Interprozesskommunikation Quelle : [Tea04]
2.3 Exchange Datenbank
2.3.1 Aufbau
Die Exchange Datenbank besteht aus einer oder mehreren Speichergruppe(n) (siehe
Abbildung 2.3). Jede Speichergruppe besteht aus einer oder mehreren EDB und STM
Datei(en), sowie einem Satz Log Dateien. Exchange erlaubt bis zu 4 Speichergruppen
und 5 Datenbanken pro Speichergruppe.
Abbildung 2.3: Exchange Datenbank Aufbau Quelle : [Tea04]
Die Aufteilung in mehrere Speichergruppen und Datenbanken sollte auch genutzt
8
Exchange Server
werden. Dies hat folgende Gründe:
•
Die Gröÿe der Datenbanken kann verringert werden, wodurch der Backup- und
Wiederherstellungsprozess optimiert wird.
•
Beim Backup geht die ganze Speichergruppe mitsamt seinen Datenbanken oline. Das bedeutet, dass Benutzer, die ihr Postfach in einer dieser Datenbanken
haben, ihre E-Mails nicht mehr lesen können. Bei mehreren Speichergruppen
kann ein Teil der Benutzer weiterarbeiten.
•
Die Last kann auf mehrere Festplatten verteilt werden, was der Gesamtleistung
zu Gute kommt.
•
Die E-Mails der Geschäftsführung können z.B. separat verwaltet werden.
Nachrichten werden pro Speichergruppe einmal gespeichert (single instance store).
Bei ungünstiger Verteilung der Benutzer auf die Speichergruppen wird mehr Speicher
verbraucht.
Die EDB Datei enthält Tabellen, die aus Ezienzgründen in einer speziellen Datenstruktur, einem B* Baum gespeichert sind. Der Zugri auf die EDB erfolgt wahlweise,
d.h. nicht in Reihenfolge und damit langsam. Die STM Datei enthält Nachrichten im
MIME Format, der Zugri erfolgt sequenziell, d.h. in Reihenfolge und somit schnell.
2.3.2 Funktionsweise
Die Exchange Datenbank arbeitet transaktionsorientiert. Eine Transaktion ist eine
Folge von Operationen, welche den ACID Prinzipien folgen:
• Atomar: Die Transaktion wird entweder vollständig oder gar nicht ausgeführt.
• Konsistent:
Nach Ausführung der Transaktion muss die Datenbank weiter-
hin konsistent sein, d.h. Daten, die an verschiedenen Stellen gespeichert sind,
müssen den gleichen Inhalt haben.
• Isoliert:
Bei gleichzeitiger Ausführung von Transaktionen dürfen sich diese
nicht gegenseitig beeinussen.
• Dauerhaft: Die Auswirkungen einer Transaktion müssen dauerhaft gespeichert
sein.
2.3 Exchange Datenbank
9
Die Punkte Atomar und Dauerhaft werden durch undo-redo logging in Kombination
mit write-ahead logging erreicht. Das bedeutet, dass Änderungen einer Transaktion,
bevor sie im Speicher ausgeführt und in die Datenbank übernommen werden, zuerst
in einer Log-Datei, dem Undo-Redo Log, vermerkt werden. Durch den Undo-Log können bei abgebrochenen Transaktionen oder Fehlern Änderungen wieder rückgängig
gemacht werden, d.h. die Transaktion erfolgt ganz oder gar nicht. Bei der Wiederherstellung von Datenbanken können durch den Redo-Log korrekt abgeschlossene
Transaktionen bis zum Sicherungszeitpunkt noch einmal ausgeführt werden. Das sichert die Vorgabe, dass Transaktionen dauerhaft gespeichert werden müssen.
Der Undo-Redo Log bringt einen weiteren Vorteil mit sich: er erlaubt es dem Datenbankmanager Seiten im Datenbankcache mehrmals zu überschreiben und Änderungen
in die Datenbank auf der Festplatte erst dann zu übernehmen, wenn es für nötig gehalten wird. Dieses Prinzip ist als steal, no force bekannt. Es wird dem System ein
viel schnelleres Arbeiten ermöglicht. Das Schreiben in eine Log Datei beansprucht im
Allgemeinen wenig Zeit und dadurch wird kostspieliges Arbeiten auf der Datenbank
und der Festplatte auf einen günstigeren Zeitpunkt verzögert (vgl. [Bjo97]).
So gesehen besteht die Datenbank aus den Log Dateien und dem Teil, der auf der
Festplatte gespeichert ist (siehe Abbildung 2.4), da nicht alle Änderungen im Datenbankcache sofort persistent gemacht werden. Dies bringt auch einen groÿen Nachteil
mit sich: stürzt z.B. ein Server ab und die Log Dateien werden dabei gelöscht, dann
gehen alle Änderungen verloren und die Exchange Datenbank ist inkonsistent, weil
mit fehlenden Log Dateien die Konsistenz der Datenbank nicht mehr überprüft werden kann. Hier hilft nur noch ein Backup.
Abbildung 2.4: Exchange Datenbank Funktionsweise Quelle : [Tea04]
Konsistenz und Isolation werden durch einen Versionsspeicher implementiert. Dieser
sorgt dafür, dass wenn in zwei verschiedenen Sitzungen der gleiche Datensatz geändert werden soll, die zweite Änderung abgelehnt wird, was die Konsistenz bewahrt.
Isolation wird dadurch gewährleistet, dass beim Lesen eines Datensatzes jeweils nur
die letzte Version angezeigt wird. Änderungen, die in einer anderen Sitzung danach
passieren, werden nicht angezeigt. Benutzer können jeweils nur die aktuellste Version
10
Exchange Server
eines Datensatzes ändern.
2.4 Konsequenzen
Beim Betrieb eines Exchange Servers gibt es einige Dinge zu beachten:
•
Damit ein Exchange Server seine Funktion als Nachrichtenübertragungssystem
überhaupt erfüllen kann, müssen System-Attendant (mad.exe), IIS (inetinfo),
Informationsspeicher (store.exe) und ExIFS ausgeführt werden.
•
Die Log-, Datenbank-, Auslagerungs- und Systemdateien sollten sich jeweils
auf einem extra Laufwerk benden, da für jeden Typ andere Anforderungen
an das Datenträgersystem gestellt werden. Auf Log Dateien wird beispielsweise
sequenziell und auf die MAPI Datenbank wahlweise zugegrien.
•
Die Log Dateien sind besonders zu sichern, weil aus Ihnen die Exchange Datenbanken wiederhergestellt werden können und nicht umgekehrt. Dabei ist darauf
zu achten, dass Circullar Logging, das Überschreiben der Log Dateien im laufenden Betrieb, ausgeschaltet ist. Circullar Logging spart zwar Speicherplatz,
bei einem Absturz können daraus keine Datenbank mehr hergestellt werden.
•
Auf einem Exchange Server sollten möglichst keine anderen Anwendungen ausgeführt werden, die den Windows Dateisystem Cache verwenden. Dessen Leistungsfähigkeit ist für ExIFS essentiell.
•
Die Aufteilung der Exchange Datenbank in Speichergruppen und Datenbanken
ist nicht nur für das Backup wichtig. In Umgebungen, in denen der Exchange
Server mit SMTP Clients benützt wird, wächst die Streaming Datenbank eher
an, da dort Nachrichten im MIME Format gespeichert werden. In Umgebungen mit Outlook Clients wächst eher die MAPI Datenbank an, da dort MAPI
Nachrichten gespeichert werden.
Die Hardware und Konguration eines Exchange Servers sollte daher möglichst vor
seinem Einsatz im Unternehmen geplant werden. Zur Unterstützung dieser Aufgabe
stellt Microsoft ein Tool namens LoadSim zur Verfügung, welches eine beliebige
Anzahl von Benutzern auf einem Exchange Server simulieren kann. Mehr dazu in
einem späteren Kapitel.
3 Systemüberwachung
In diesem Kapitel wird zunächst ein Überblick über die Komponenten eines Servers
gegeben und wie diese funktionieren. Anschlieÿend wird auf die Erkennung und Ursachen von Leistungsproblemen eingegangen, sowie Gegenmaÿnahmen beschrieben. Am
Schluÿ dieses Kapitels wird ein Exchange Server getestet und die dabei gewonnenen
Ergebnisse ausgewertet. Die Bedeutung der in den folgenden Kapiteln vorgestellten
Leistungssensoren kann im Windows Performance Monitor nachgelesen werden.
3.1 Überblick
In diesem Abschnitt soll ein Überblick über wichtige Komponenten eines Systems
gegeben werden und anhand welcher Indikatoren deren Leistung gemessen wird.
3.1.1 Prozessor
Der Prozessor ist die zentrale Recheneinheit eines Computers. Seine Auslastung wird
in Prozessorzeit (%) gemessen.
3.1.2 Speicher
In diesem Unterkapitel wird die Funktionsweise des Speichers beschrieben und wie
seine Leistung gemessen wird. Diese Informationen stammen aus [Fri].
Moderne Betriebssysteme wie z.B, Windows oder Linux benützen eine virtuelle Speicherverwaltung (siehe Abbildung 3.1). Dabei werden die logischen Adressräume der
ausgeführten Programme in feste Blöcke eingeteilt, welche Seiten genannt werden.
Diese Seiten werden mit Hilfe von Seitentabellen auf gleich groÿe Blöcke im physikalischen Speicher abgebildet. Der virtuelle Adressraum kann somit wesentlich gröÿer
ausfallen, als physikalisch an Speicher vorhanden ist. Seiten eines Prozesses, die sich
gerade im physikalischen Speicher benden, werden Arbeitsseiten genannt. Es müssen
immer nur die aktiven Seiten im Arbeitsspeicher gehalten werden, also diejenigen Seiten, auf die oft zugegrien wird. Bei Speicherplatzmangel können inaktive Seiten in
11
12
Systemüberwachung
eine Auslagerungsdatei auf der Festplatte verschoben werden. Greift nun ein Prozess
auf eine Seite zu, die sich gerade nicht in seinen Arbeitsseiten oder im Speicher bendet, so wird dadurch ein Seitenfehler ausgelöst und die entsprechende Seite geladen
(on demand paging).
Abbildung 3.1: Virtuelle Speicherverwaltung (vgl. [Fri])
Aufgabe des Betriebssystems ist die eziente Verwaltung des Speicherplatzes. Dazu muss das Betriebssystem eine eektive Seitenersetzungsstrategie verwenden, die
wie folgt funktioniert: Der freie Speicherplatz ist in drei Listen aufgeteilt: Standby-,
Frei- und Nullliste (siehe Abbildung 3.2). Im laufenden Betrieb werden den aktiven
Prozessen Seiten gestohlen, welche sich über einer bestimmten minimalen Arbeitsseitengröÿe benden, und auf die Standby Liste gesetzt. Von dort können sie wieder
in den Prozess zurückgelangen, von dem sie gestohlen wurden, oder sie altern dort
und werden nach Ablauf einer bestimmten Zeitspanne auf die Frei Liste gesetzt.
Enthielten diese Seiten noch Daten oder wurden diese geändert, so müssen sie in
eine Auslagerungsdatei geschrieben werden. Von der Frei Liste gelangen sie in die
Null Liste, wo sie mit Nullen überschrieben werden. Von einem Prozess neu angeforderte Seiten dürfen aus Sicherheitsgründen nur genullte von der Null Liste sein.
Ansonsten könnte z.B. ein schadhafter Prozess Daten von einem anderen einsehen.
Eine weitere Aufgabe des Betriebssystems ist die Behandlung von Seitenfehlern. Davon gibt es drei verschiedene Typen:
• Hardwareseitenfehler:
Die betroene Seite bendet sich auf der Festplatte.
Da die Festplatte um Gröÿenordnungen langsamer ist als der Speicher, dauert diese Operation recht lange und kostet somit Systemleistung. Eine hohe
Hardwareseitenfehlerrate beeinträchtigt die Systemleistung wesentlich.
3.1 Überblick
13
Abbildung 3.2: Standby-, Frei- und Nullliste (vgl. [Fri])
• Wechselfehler:
Die betroene Seite bendet sich auf der Standby Liste und
kann so ohne groÿe Verluste von dort geladen werden. Eine hohe Wechselfehlerrate beeinträchtigt die Systemleistung kaum.
• Cachefehler: Dies betrit Seitenfehler, die im Windows Dateisystemcache (siehe Kapitel 3.1.3) auftreten (z.B. beim Exchange Server durch Verwendung des
Dateisystemcaches durch ExIFS). Sie veranlassen das Betriebssystem von Prozessen angeforderte Dateien zu laden. Cachefehler treten auf, wenn sich die
angeforderte Seite im Cache entweder an einer anderen Position bendet, als
an der, auf die zugegrien wird, oder wenn sich die betroene Seite auf der Festplatte bendet und von dort geladen werden muss. Eine hohe Cachefehlerrate
gibt nur einen Hinweis darauf, dass viele Dateisystemzugrie stattnden, macht
aber keine Aussagen darüber, von woher betroene Seiten geladen werden. Dies
erlaubt keine Rückschlüsse auf Beeinträchtigungen der Systemleistung.
Das Betriebssystem verwendet für sich sechs Speicherbereiche: den freien Speicher,
nichtauslagerungsfähigen Speicher, auslagerungsfähigen residenten Speicher, residenter Systemcode, residenter Systemcache und residente Systemtreiber. Resident bezeichnet hierbei einen Speicher, der sich gerade im physikalischen Arbeitsspeicher
bendet. Die Gröÿe des physikalischen RAM minus dieser sechs Speicherbereiche
steht den Prozessen als Speicherplatz zur Verfügung.
Kritisch wird die Situation, wenn weniger als 4 MB freier Speicherplatz zur Verfügung
steht. Dann fängt Windows an, Seiten auf Festplatte auszulagern. Die Systemleistung
sinkt daraufhin wesentlich.
Die virtuelle Speicherverwaltung bietet also viele Vorteile:
14
Systemüberwachung
•
Der Speicher muss nicht mehr am Stück frei sein. So kann er optimal ausgelastet
werden.
•
Anwendungen können ohne Rücksicht auf Speicheranforderungen entwickelt
werden. Mit Hilfe von Auslagerungsdateien auf der Festplatte kann mehr Speicher simuliert werden.
•
Speicherbereiche können gekapselt werden, so dass Prozesse nicht auf Speicherbereiche anderer Prozesse zugreifen können.
Der Nachteil ist derjenige, dass Prozesse durch on demand paging beliebig in ihrer
Gröÿe wachsen und andere Prozesse aus dem Speicher verdrängen können. Der Kampf
um Speicherplatz wird somit auf Kosten der Systemleistung ausgetragen.
• Leistungssensoren zur Messung des verwendeten Speicherplatzes:
Verfügbare MB, Nicht - Auslagerungsseiten (Bytes), Cachebytes, Zugesicherte verwendete Bytes
• Leistungssensoren zur Messung der Aktivität:
Seitenfehler /s, Cache-
fehler /s, Wechselfehler /s, Seiteneingabe /s, Geänderte Seiten /s, Seitenlesevorgänge /s (Hardwareseitenfehler), Seiten - Schreibvorgänge /s
3.1.3 Cache
Dieses Unterkapitel gibt zunächst einen Überblick über die Funktionsweise des Windows Dateisystemcaches und beschreibt anschlieÿend, wie seine Leistung gemessen
wird. Diese Informationen stammen aus [MF02].
Mit Cache ist hier der Windows Dateisystemcache gemeint. Dieser ist ein Speicherbereich, der sich im Arbeitsspeicher bendet. Er dient dazu, Lese- und Schreibzugrie
auf die Festplatte zu minimieren, indem häug verwendete Dateien zwischengespeichert werden. Dies geschieht für Anwendungen transparent, d.h. sie bekommen davon
nichts mit.
Der Dateisystemtreiber leitet Lesezugrie standardmäÿig an das so genannte Copy
Interface des Cache Managers weiter (siehe Abbildung 3.3). Dieser schaut zuerst im
Dateisystemcache nach, ob sich darin die gewünschte Datei bendet. Falls sich die gewünschte Datei im Cache bendet (Cachetreer), wird sie sofort vom Cache Manager
in den Speicherbereich der anfragenden Anwendung kopiert. Falls nicht (Cachemiss),
wird die Datei von der Festplatte gelesen, im Cache abgelegt und anschlieÿend vom
Cache Manager in den Speicherbereich der Anwendung kopiert. Die Anwendung kann
nun weiterarbeiten.
3.1 Überblick
15
Abbildung 3.3: Copy Interface (vgl. [MF02])
Bei mehreren hintereinander folgenden Schreibzugrien auf eine Datei, die sich im
Dateisystemcache bendet, können diese Zugrie gepuert und verzögert werden. Geänderte Seiten können anschlieÿend später zusammen auf den Datenträger übertragen
werden. Dieses Verfahren ist wesentlich ezienter, als jedes Mal auf die Festplatte zuzugreifen. Lese- und Schreibzugrie von Anwendungen sind also logische Zugrie, die
nicht 1:1 mit physikalischen Zugrien auf die Festplatte vergleichen werden können.
Im Dateisystemcache werden jedoch nicht nur Dateien zwischengespeichert, sondern
auch Daten, so genannte NTFS Metadaten, die das NTFS Dateisystem für den Betrieb benötigt. Darin sind z.B. Namen und Gröÿe von Dateien gespeichert. Da diese
Daten sehr wichtig sind, werden diese direkt von NTFS verwaltet. Zu diesem Zweck
stellt der Cache Manager eine zweite Schnittstelle zur Verfügung, das sogenannte
Mapping Interface. Durch diese Schnittstelle bekommt NTFS über einen Zeiger
direkten Zugang zu den Metadaten und der Cache Manager verliert die Kontrolle
darüber. Das ist sehr wichtig, um die Metadaten konsistent zu halten und um die
Reihenfolge zu bestimmen, in der die Metadaten zurück auf die Festplatte geschrieben werden.
Um auf die Metadaten zugreifen zu können, müssen die entsprechenden Seiten im
Cache festgesetzt werden, d.h. sie dürfen nicht aus dem Speicher verdrängt werden
und ihre virtuelle Adresse muss gleich bleiben. Würden die Seiten nicht festgesetzt
werden, so könnten sie während einer kritischen Operation verändert werden, was zu
unkalkulierbaren Ergebnissen führen würde. Da der Cache Manager keine Kontrolle
über die Metadaten hat, weis er nicht, wann sie auf die Festplatte zurückzuschreiben
sind. Dies wird ihm durch die Aufhebung der Festsetzung signalisiert.
Der Dateisystemcache kann, je nach den Anforderungen, die an ihn gestellt werden,
wachsen und schrumpfen. Dabei sollte das Verhältnis zwischen Cachetreerrate und
16
Systemüberwachung
Cachegröÿe ausgewogen sein. Er sollte nicht zu klein sein, da sonst die Cachetreerrate
zu niedrig ist. Mit zunehmender Cachegröÿe steigt zwar die Cachetreerrate an, ab
einer bestimmten Gröÿe aber nur mehr gering, so daÿ ein zu groÿer Cache die Ezienz
nicht mehr deutlich steigern kann.
• Leistungssensoren für das Copy Interface:
Kopieren-Lesevorgänge /s,
Kopieren-Lesetreer (%)
• Leistungssensoren für das Mapping Interface:
Datenzuordnungen /s, Datenzuordnung - Festsetzungen /s, Datenzuordnungstreer (%), Festsetzung-Lesevorgänge /s, Festsetzung-Lesetreer (%)
• Weitere Leistungssensoren: Datenleerungen /s, Datenleerung - Seiten /s
3.1.4 Festplatte
Die Festplatte bildet den Sekundärspeicher eines Computers. Auf ihr können groÿe
Mengen an Daten billig und dauerhaft gespeichert werden.
• Leistungssensoren für physikalischen Datenträger:
Aktuelle / Durchschnittliche Warteschlangenlänge, Mittlere Bytes /Lesevorgang, Mittlere Bytes /Schreibvorgang, Mittlere Sek. /Lesevorgang, Lesevorgänge /s, Schreibvorgänge /s
• Leistungssensoren für logischen Datenträger: MB frei, Freier Speicherplatz (%)
3.1.5 Netzwerk
Durch Bytes gesendet /s und Bytes empfangen /s läÿt sich die Netzwerkaktivität
feststellen.
3.1.6 Prozesse
Bei Prozessen sollten die Leistungssensoren Arbeitsseiten, Private Bytes, Seitenfehler /s und Prozessorzeit (%) überwacht werden.
3.2 Leistungsprobleme
17
3.1.7 Exchange
In Kapitel 2 wurde der Aufbau und die Funktionsweise von Exchange beschrieben.
• Leistungssensoren des Informationsspeichers:
RPC Anfragen, RPC Operationen, Anzahl Benutzer
• Leistungssensoren des Informationsspeicher-Postfachs:
Gröÿe der Sen-
dewarteschlange, Nachrichtenönungen /s, Ordnerönungen /s
• Leistungssensoren des SMTP-Servers:
Länge der Kategorisierungswarte-
schlange, Länge der Remotewarteschlange, Lokale Warteschlange
• Leistungssensoren der Datenbank:
Datenbankcache: % Treer, Proto-
kollschreiboperationen /s, Protokolldatensatzverzögerungen /s, Tabelle: Önungen /s, Tabelle: % Cachetreer
• Leistungssensoren der Verzeichniszugriskomponente: Cachetreer /s
• Leistungssensoren der Epoxy Schicht:
Warteschlangenlänge ab Client,
Warteschlangenlänge ab Informationsspeicher
3.2 Leistungsprobleme
Nachdem im vorhergegangen Abschnitt ein Überblick über wesentliche Komponenten
eines Systems gegeben wurde und wie deren Leistung bemessen wird, beschäftigt sich
dieser Abschnitt mit der Erkennung von Leistungsproblemen, deren Ursachen und wie
sie behandelt werden können. Ziel hierbei ist es, Leistungsprobleme möglichst früh
zu erkennen, am Besten bevor sie ernsthafte Auswirkungen auf die Systemleistung
haben. Dadurch bleibt mehr Zeit zum Beheben des Problems. Die in diesem Kapitel
vorgestellten Techniken stammen aus [Mar04].
3.2.1 Erkennung
Um Leistungsprobleme eines Systems erkennen zu können, muss zuerst einmal seine
durchschnittliche Leistung bekannt sein. Dabei sind folgende Fragen zu klären:
•
Zu welcher Tageszeit oder an welchem Wochentag werden Spitzenlasten erreicht?
•
Gibt es monatliche Spitzenlasten?
18
Systemüberwachung
•
Wie viele Benutzer kann das System bedienen?
Durch den Vergleich der aktuellen mit den durchschnittlichen Leistungsdaten kann
beurteilt werden, ob ein System ordnungsgemäÿ funktioniert oder nicht. Ist bekannt,
dass z.B. viele Mitarbeiter um die Mittagszeit herum ihre E-Mail Nachrichten abrufen
und dadurch Spitzenlasten auf dem betreenden Exchange Server verursachen, kann
dies als normal eingestuft und in der Beurteilung des aktuellen Systemzustandes
berücksichtigt werden.
Ist ein Leistungsproblem erkannt worden, dann ist der nächste Schritt die Eingrenzung der Problemquelle. Dabei ist es wichtig festzustellen, ob das Problem vor, während oder nach der Bearbeitung durch Exchange auftritt. Typische Symptome für
Leistungsprobleme eines Exchange Server sind:
• Anwachsen von Nachrichtenwarteschlangen:
Das Anwachsen der Lokalen Sendewarteschlange des SMTP Servers deutet darauf hin, dass eingehende Nachrichten nicht mehr in angemessener
Zeit lokal ausgeliefert werden können. Meistens sind dafür Probleme mit
dem Informationsspeicher verantwortlich. Es kann aber auch an Problemen beim Kategorisieren von Nachrichten liegen, was durch die Kategorisierungswarteschlange angezeigt wird. Hier dauert das Nachschlagen von
Empfängerdaten auf einem Active Directory Server zu lange.
Wächst die Remotewarteschlange an, dann gibt es Probleme mit dem Netzwerk oder mit anderen Servern, da die Nachrichten an diese nicht ausgeliefert werden können.
Eine groÿe Sendewarteschlange des Informationsspeichers deutet auf Probleme mit dem SMTP Dienst hin, da alle eingehenden MAPI Nachrichten
vom Informationsspeicher an diesen weitergeleitet werden, wo sie nicht
angenommen oder bearbeitet werden können.
• Langsame RPC Bearbeitung:
Die beiden Leistungssensoren RPC Anfra-
gen und RPC Operationen des Informationsspeichers messen, wie gut RPC
Anfragen abgearbeitet werden können. Dabei gibt es vier Fälle zu unterscheiden:
Fall 1:
Die Anzahl der RPC Anfragen ist niedrig und die der RPC Ope-
rationen gleich null. Dies deutet auf Probleme mit dem Netzwerk hin, da
die Anfragen den Exchange Server nicht erreichen.
3.2 Leistungsprobleme
19
Fall 2: Die Anzahl der RPC Anfragen ist hoch und die der RPC Operationen niedrig. Dies deutet auf Leistungsprobleme des Exchange Servers hin,
da dieser die Clientanfragen nicht in angemessener Zeit bearbeiten kann.
Fall 3:
Die Anzahl der RPC Anfragen ist hoch und die der RPC Opera-
tionen steigt. Dies deutet auf ein Clientproblem hin, worauf immer mehr
Anfragen an den Exchange Server gestellt werden. Dieser versucht nun die
Anfragen abzuarbeiten, schat es aber nur teilweise. Der verursachende
Client kann über das Netzwerk ausndig gemacht werden.
Fall 4:
Die Anzahl der RPC Anfragen ist niedrig und die der RPC Ope-
rationen hoch. Dies ist der Normalfall.
• Anwachsen der EPOXY Warteschlangen:
EPOXY ist der gemeinsame
Speicherbereich des Informationsspeichers und IIS. Bilden sich dort Warteschlangen, dann arbeitet einer von beiden schneller als der andere.
3.2.2 Ursachen
Ist der Exchange Server selbst als Problemquelle identiziert worden, dann muss nach
der Ursache für seine schlechte Leistung gesucht werden. Dazu müssen Prozessor,
Speicher, Cache und Festplatten auf Leistungsprobleme untersucht werden. Wie dies
im Einzelnen geschieht, wird im Folgenden beschrieben.
• Prozessor: Um Probleme mit dem Prozessor festzustellen, muss der Leistungssensor Prozessorzeit (%) beobachtet werden. Dieser Wert sollte sich nie auf
konstant hohem Niveau benden und auch nicht über die Marke von 90% steigen. Wird eine eine hohe Prozessorauslastung beobachtet, dann sollte nachgeschaut werden, welcher Prozess dafür verantwortlich ist. Meistens ist es store.exe.
• Speicher: Probleme mit dem Speicher treten auf, wenn der Wert des Leistungssensors Verfügbare MB unter 4MB fällt. Dann fängt Windows an, Seiten vom
Speicher in die Auslagerungsdatei zu schreiben und von dort wieder einzulesen
(paging). Paging wird durch die Leistungssensoren Seitenlesevorgänge /s und
Seiten-Schreibvorgänge /s, die Menge an ein- und ausgelagerten Seiten durch
Seiteneingaben /s und Geänderte Seiten/s angezeigt. Wenn zu viele Seiten
ein- und ausgelagert werden, dann kann daraus ein Leistungsproblem der Festplatte entstehen, aber auch die Prozessorlast ansteigen.
Es ist auch interessant, an welcher Stelle soviel Speicherplatz benötigt wird.
20
Systemüberwachung
Dazu sollte die Gröÿe der Arbeitsseiten der laufenden Prozesse beobachtet werden. Oft verbraucht store.exe am meisten Speicherplatz. Auÿerdem sollte die
Gröÿe des nichtauslagerungsfähigen Speichers im Blick behalten werden. Dieser
belegt den Speicher dauerhaft und kann nicht ersetzt werden.
Auch der Leistungssensor Zugesicherte verwendete Bytes sollte beobachtet
werden. Steigt dieser auf 100%, dann müssen die Auslagerungsdateien vergröÿert werden, was zusätzlich Systemleistung kostet.
• Cache:
Probleme mit dem Dateisystemcache können über die entsprechenden
Cachetreerraten festgestellt werden. Diese sollten möglichst hoch sein, da bei
Cachemisses Zugrie auf den Datenträger stattnden. Die Gröÿe des Caches
kann mit dem Leistungssensor Cachebytes, seine Aktivität mit Cachefehler
/s, Kopieren - Lesevorgänge /s, Datenzuordnunegn /s, Datenzuordnung Festsetzungen /s, Festsetzungen - Lesevorgänge /s, Datenleerungen /s und
Datenleerung - Seiten /s gemessen werden. Letzterer Leistungssensor ist dabei
der wichtigere, da er Festplattenzugrie verursacht.
• Festplatte:
Ist die Festplatte mit den Anforderungen überlastet, dann bilden
sich Warteschlangen (Aktuelle / Durchschnittliche Warteschlangenlänge) und
die Zugriszeiten steigen (Mittlere Sek. /Lesevorgang, Mittlere Sek. /Schreibvorgang).
Um herauszunden, wie viele Zugrie auf die Festplatte durch Paging verursacht werden, sollten die beiden Leistungssensoren Lesevorgänge /s mit Seitenlesevorgänge /s und Schreibvorgänge /s mit Seiten - Schreibvorgänge /s
verglichen werden. Den Anteil der Bandbreite, der durch Einlesen von Seiten
verbraucht wird, errechnet sich durch
(Seiteneingabe /s)*4096
(Mittlere Bytes /Lesevorgang*Lesevorgänge /s)
den Anteil der Bandbreite, der durch Schreiben von Seiten in die Auslagerungsdatei verbraucht wird, durch
(Geänderte Seiten /s)*4096
(Mittlere Bytes /Schreibvorgang)*(Schreibvorgänge /s)
und den Anteil der Bandbreite, der durch das Leeren des Dateisystemcaches
verbraucht wird, durch
(Datenleerung-Seiten /s)*4096
(Mittlere Bytes /Schreibvorgang)*(Schreibvorgänge /s)
Dieser Prozentsatz sollte nicht zu hoch sein.
Weiterhin ist eine Überprüfung des freien Speicherplatzes derjenigen Laufwerke
nötig, die das Mailroot Verzeichnis, die Log- und Auslagerungsdateien, sowie
Datenbankdateien beherbergen.
3.3 Test eines Exchange Servers
21
3.2.3 Gegenmaÿnahmen
Bei Leistungsproblemen sollten zuerst folgende Fragen gestellt werden:
•
Mit welcher Häugkeit treten Leistungsprobleme auf ?
•
Verursacht immer dieselbe Komponente Leistungsprobleme?
Treten Leistungsprobleme oft auf, womöglich durch mehrere Komponenten zusammen, dann sollte geprüft werden, ob der Exchange Server die an ihn gestellten Anforderungen langfristig erfüllen kann und ob nicht doch besser ein anderer, leistungsfähiger Server eingesetzt werden sollte. Verursacht meistens die gleiche Komponente
Leistungsprobleme, so kann diese ausgetauscht werden, z.B. der Prozessor oder der
Arbeitsspeicher durch jeweils einen gröÿeren. Dies ist aber im laufenden Betrieb eines
Servers meist unmöglich.
Hier können folgende Gegenmaÿnahmen getroen werden:
•
Kann das Leistungsproblem auf einen ressourcenhungrigen Prozess zurückgeführt werden, z.B. einen Virenscanner, dann kann dieser einfach beendet werden. Dadurch werden belegte Ressourcen wieder für Exchange freigegeben.
•
Wird eine schlechte Leistungsfähigkeit des Sekundärspeichers festgestellt, so
kann diese durch Hinzufügen zusätzlicher Festplatten erhöht werden, da die
Last damit auf weitere Festplatten verteilt wird und die vorhandenen entlastet
werden.
•
Bei Leistungsproblemen, die durch Paging verursacht werden, können zusätzliche Auslagerungsdateien angelegt werden oder vorhandene auf einen leistungsfähigeren Sekundärspeicher verlagern. Die Zugriszeiten auf ausgelagerte Seiten
können dadurch verringert und das Leistungsproblem somit abgeschwächt werden.
3.3 Test eines Exchange Servers
Dieses Kapitel beschäftigt sich damit, wie die Leistungsfähigkeit eines Exchange Servers getestet werden kann. Zunächst folgt ein Überblick über das allgemeine Vorgehen
beim Testen eines Exchange Servers und danach verschiedene Versuche. Zum Schluÿ
erfolgt die Auswertung der Testergebnisse anhand der in Kapitel 3 vorgestellten Techniken. Die in diesem Kapitel vorgestellte Technik stammt aus [DK02].
22
Systemüberwachung
3.3.1 Allgemeines Vorgehen
Bevor einen Exchange Server im Unternehmen eingesetzt werden soll, sollte geprüft
werden, wie viele Benutzer dieses System bedienen kann. Einerseits wäre es fatal,
wenn sich im laufenden Betrieb herausstellt, dass es den Anforderungen nicht nachkommen kann. Andererseits sollte es auch nicht viel leistungsfähiger als nötig sein,
denn brach liegende Leistung kostet unnötig Geld.
Mit LoadSim, einem Tool der Firma Microsoft, kann auf einem Exchange Server eine
beliebige Anzahl an Nutzern simulieret werden. Diese lesen und schreiben Nachrichten, vereinbaren Termine usw. und verhalten sich so, wie es von einem Mitarbeiter
in einem Unternehmen praktiziert wird. Durch verschiedene Prole läÿt sich z.B.
einstellen, wie viele Nachrichten versendet werden. So kann die zu erwartende Last
simuliert werden.
LoadSim zeichnet die dabei aufgetretenen Antwortzeiten auf, z.B. wie lange es dauert, bis eine E-Mail Nachricht versendet wurde. Die Gesamtantwortzeit des Systems
wird durch Gewichtung der Antwortzeiten der einzelnen Aktionen gebildet, z.B. wird
die Antwortzeit beim Lesen von E-Mails höher gewichtet, als die beim Versenden.
Damit ndet der subjektive Eindruck eines Benutzers stärkeren Einuss in das Gesamtergebnis. Die Verzögerungen beim Lesen von E-Mails werden von Nutzern eher
weniger toleriert.
Beim Testen eines Exchange Servers können mehrere Clients verwendet werden, die
die Last simulieren. Dabei ist darauf zu achten, dass ein Client der Kontrollclient ist.
Dieser simuliert eine geringere Anzahl an Benutzern als die anderen. Dadurch können
Leistungsprobleme des Kontrollclienten, welche die Antwortzeiten verfälschen könnten, ausgeschlossen werden. Die Gesamtantwortzeit des Systems wird deshalb an ihm
abgelesen. Diese Technik bietet einen weiteren Vorteil: mit den anderen Clients können wesentlich mehr Benutzer simuliert werden, als sie eigentlich verarbeiten können,
da ihre Antwortzeiten keine Bedeutung haben. So kann aus der vorhandenen Hardware noch ein biÿchen mehr an Leistung herausgeholt werden.
Die Systemüberwachung des Exchange Servers sollte beim Testen von einem eigenständigen Client vorgenommen werden, damit die Messergebnisse nicht verfälscht
werden.
3.3.2 Versuchsaufbau
Für den Test standen folgende Komponenten zur Verfügung:
•
1 Exchange Server (Pentium 3 1Ghz, 768 MB RAM, 4x18 GB SCSI, Windows
2000, Exchange 2000 SP3)
3.3 Test eines Exchange Servers
23
Abbildung 3.4: Testaufbau
•
2 Clients (jeweils Windows 2000)
•
1 Domänencontroller (Windows 2003)
Beim folgenden Test sollen auf dem Exchange Server insgesamt 800 Benutzer simuliert werden. Client 1 simuliert 100 Benutzer und ist somit der Kontrollclient, Client
2 simuliert 700 Benutzer. Der Domänencontroller misst die Leistungswerte. Die Exchange Datenbank ist in 2 Speichergruppen aufgeteilt, welche jeweils 2 Datenbanken
enthalten (siehe Abbildung 3.4).
Vor dem eigentlichen Test muss von LoadSim im Active Directory des Domänencontrollers die erforderliche Anzahl an Benutzern angelegt und für diese Benutzer auf
dem Exchange Server entsprechende Postfächer initialisiert werden. Diese Prozedur
dauerte je nach Benutzerzahl bis zu 5 Stunden. Erst danach konnte der Exchange
Server getestet werden, was noch einmal 8 Stunden an Zeit beanspruchte.
3.3.3 Ergebnisse
Prozessor
Prozessorzeit (%)
33
Speicher
Seitenlesevorgänge /s
3
Seiten-Schreibvorgänge /s
0
Verfügbare MB
22
24
Systemüberwachung
Cachefehler /s
261
Seitenfehler /s
394
Cache
Datenleerung-Seiten /s
156
% an geschriebenen Seiten
64,46
Kopieren-Lesetreer (%)
92
Kopieren-Lesevorgänge
122
Festplatten
Seiten auf Platten geschrieben
242
Seiten von Platten gelesen
66
Prozess store.exe
Arbeitsseiten (MB)
586,48
Prozessorzeit (%)
28
(%) Gesamtprozessorzeit
85
Informationsspeicher Postfach
Übergebene Nachrichten
16167
Übermittelte Nachrichten
30241
Übermittelte / Übergebene
1,87
Gröÿe der Sendewarteschlange
4481
Datenbank
DB Cachegröÿe (MB)
479,47
% an Store Arbeitsseiten
81,75
Datenbankcache (%) Treer
99
Tabelle 3.1: Ergebnistabelle
3.3.4 Auswertung
In diesem Versuch zeigten sich massive Leistungsprobleme des Exchange Servers. Eine
vom Client übergebene Nachricht konnte nur an 1,87 Empfänger (vgl. Übermittelte/Übergebene Nachrichten) ausgeliefert werden. Das Testprol sah aber einen Faktor
von 3,67 vor. Das hatte zur Folge, dass ein groÿer Teil der von den Clients gesendeten Nachrichten nicht ausgeliefert werden konnte. Dies kann auch an der Länge der
Sendewarteschlange abgelesen werden, worin sich am Ende des Tests 4481 Nachrichten befanden. Da die Warteschlange während des Tests kontinuierlich anwuchs, liegt
die Vermutung nahe, dass hier ein Kongurationsproblem vorlag. Diese These wird
auch durch die Tatsache gestützt, dass nach Ende des Tests, als die Clients aufgehört
hatten, Nachrichten zu senden, der Exchange Server weiter Leistung verbrauchte und
die Warteschlangenlänge dabei nicht abnahm.
3.3 Test eines Exchange Servers
25
Die Leistungsprobleme entstehen dadurch, dass der Exchange Server periodisch versucht, die Nachrichten in der Sendewarteschlange auszuliefern; je mehr Nachrichten
sich darin anstauen, desto mehr Leistung muss für deren Auslieferung aufgewendet
werden. Wie an der hohen Anzahl an Cachefehler /s gesehen werden kann, wird der
Dateisystemcache stark beansprucht. Dieser hohe Wert liegt an häugen Operationen
von ExIFS auf der STM Datenbank, welche durch die wiederholte Bearbeitung der
Nachrichten in der Sendewarteschlange verursacht werden. Dabei werden die Festplatten stark belastet. Auf sie werden durchschnittlich 242 Seiten pro Sekunde geschrieben. Davon stammen ganze 64%, genauer 156 Seiten (vgl. Datenleerung - Seiten
/s), aus dem Dateisystemcache, was eindeutig zu hoch ist. Die restlichen 36% müssen
sich Log-, Auslagerungs- und Datenbankdateien teilen. Die hohe Beanspruchung des
Dateisystemcaches führt auÿerdem zu einer Verringerung der Kopieren-Lesetreer
(%) auf 92%.
An der Tabelle können auch noch andere interessante Ergebnisse abgelesen werden.
So verbraucht der Prozess store.exe mit 28% die höchste Prozessorzeit. Das sind
84% der Gesamtprozessorzeit. Mit einer durchschnittlichen Arbeitsseitengröÿe von
586,48 MB ist er der gröÿte Speicherkonsument.
4 Konzept einer proaktiven
Systemüberwachung
Eingehend wird zunächst ein Konzept einer proaktiven Systemüberwachung erörtert.
Danach werden die zur Umsetzung benötigten Technikem im Detail beschrieben.
Anschlieÿend wird das Konzept getestet und die Ergebnisse ausgewertet.
4.1 Überlegungen
Wie in Kapitel 3.3.1 schon beschrieben wurde, muss bei einer Systemüberwachung
die durchschnittliche Systemleistung mit der aktuellen verglichen werden. Dies geschieht am besten automatisch, damit etwaige auftretende Leistungsprobleme des
überwachten Systems möglichst früh erkannt werden und zu einem frühen Zeitpunkt
Gegenmaÿnahmen eingeleitet werden können (Proaktivität). Den Ist-Zustand eines
Systems kann durch Messen von geeigneten Leistungssensoren herausgefunden werden
(vgl. Kapitel 3). Die entscheidende Frage ist jedoch, wie der Soll-Zustand abgebildet
werden soll.
Es reicht nicht, einfach niedrige Grenzwerte für verschiedene Leistungssensoren anzunehmen und bei Überschreitung Alarm zu geben. Durch diesen Ansatz können keine
Leistungsspitzen mehr in die Diagnose miteinbezogen werden. Diese entstehen beispielsweise, wenn viele Benutzer ihre E-Mail Nachrichten zur Mittagszeit abrufen.
Die Problematik besteht darin, dass die Gefahr von Fehlalarmen groÿ ist, falls diese Grenzen zu niedrig gewählt werden. Werden diese andererseits zu hoch gewählt,
können Leistungsprobleme vielleicht erst zu spät erkannt werden.
Um periodische Eekte, wie regelmäÿig auftretende Leistungsspitzen in die Betrachtung des Systemzustandes einieÿen zu lassen, müsste bekannt sein, welche Werte des
betroenen Leistungssensors zum Meÿzeitpunkt normal sind. Ausgehend von diesen
könnte die durchschnittliche Systemleistung zu jedem Zeitpunkt abgebildet und die
aktuell gemessenen Leistungsdaten damit verglichen werden, um Abweichungen festzustellen.
26
4.2 Grundlagen
27
Wie aber kann festgestellt werden, welche Werte zum Meÿzeitpunkt normal sind? Es
wäre eine Historie der gemessenen Werte des Leistungssensors und ein Modell, welches
diese abbildet, notwendig. Für solch einen Zweck eignen sich sehr gut Vorhersagemodelle aus dem Bereich Data Mining. Mit ihnen können Sachverhalte mathematisch
erfasst und ihre Qualität anhand diverser Techniken beurteilt werden.
4.2 Grundlagen
In diesem Kapitel werden die Grundlagen des Data Mining vorgestellt und anhand
von Beispielen veranschaulicht. Die verwendeten Techniken und Beispiele stammen
aus [IHW05].
4.2.1 Data Mining
Heutzutage entstehen in Unternehmen, in der Verwaltung oder in Forschungsprojekten riesige Datenmengen. Dabei ist es wichtig, Regeln oder Muster in den Daten zu
erkennen. Data Mining ermöglicht das automatische Finden von Strukturen in solchen Datenbeständen durch diverse Techniken, z.B. statistische Verfahren. Mit ihnen
lassen sich neue Situationen beurteilen oder Abweichungen feststellen (vgl. [de.06a]).
Ein Unternehmen, welches z.B. Abweichungen im Verhalten ihrer Kunden feststellt,
kann seine Geschäftsstrategie dementsprechend anpassen. Die gefundenen Strukturen
helfen dabei, Zusammenhänge in vorher unbekannten Datenbeständen zu erkennen,
um diese dann in einem Modell zu repräsentieren.
Begrisdenitionen:
• Instanzen:
Instanzen bezeichnet die Eingabe, also der auszuwertende Daten-
bestand.
• Instanz:
Dies ist eine Zeile aus einer Tabelle, welche den auszuwertenden Da-
tenbestand repräsentiert.
• Attribut:
Ein Attribut ist eine Spalte aus einer Tabelle, die den auszuwerten-
den Datenbestand repräsentiert. Diese kann nominale, z.B. ja oder nein, oder
numerische Werte enthalten.
Das Lernen von Strukturen kann im Wesentlichen in vier Bereiche unterteilt werden:
• Klassikation:
Die gelernte Struktur repräsentiert mehrere nach einem be-
stimmten Attribut (Klassenattribut) klassizierte Instanzen. Dadurch sollen
28
Konzept einer proaktiven Systemüberwachung
neue Instanzen der richtigen Klasse zugeordnet werden. Das Klassenattribut
muss nominal sein.
• Assoziation: Hier werden Zusammenhänge unter Attributen gesucht, nicht nur
solche, die das Klassenattribut vorhersagen. Die dazu verwendeten Attribute
können nominal oder numerisch sein.
• Clustering:
Hier wird versucht, zusammengehörige Instanzen zu gruppieren.
Die verwendeten Attribute können nominal oder numerisch sein.
• Numerische Vorhersage:
Ziel ist es, den numerischen Wert eines Klasse-
nattributes vorherzusagen. Die dazu verwendeten Attribute müssen numerisch
sein.
Die Punkte Klassikation und Numerische Vorhersage werden dem so genannten
supervised (überwachten) Lernen zugerechnet. Dabei soll eine Eigenschaft gelernt
bzw. geschätzt werden. Clustering wird dem unsupervised Lernen zugeordnet,
wobei eine Datenmenge lediglich in Gruppen unterteilt wird.
Der Data Mining Prozess besteht aus mehreren Teilschritten (siehe Abbildung 4.1):
• Daten sammeln:
Der erste Schritt besteht aus dem Sammeln von Daten.
Diese sind oft über mehrere Datenbanken verstreut und müssen konsistent in
einer Tabelle zusammen gebracht werden. Idealerweise sind die relevanten Daten
konsistent in einem sogenannten Data Warehouse abgebildet.
• Filtern:
Das Filtern der Daten ist der zeitaufwändigste Schritt. Er kann aus
folgenden Teilschritten bestehen:
Diskretisierung numerischer Daten
Selektion relevanter Merkmale
Ableitung neuer Merkmale
Korrigierung von Falsch -und Fehlwerten
Entfernung von Redundanzen
• Data Mining:
Wenn die Daten im richtigen Format vorliegen, kann mit der
Mustererkennung begonnen werden.
• Evaluierung:
Im letzten Schritt wird das gefundene Muster auf dessen In-
teressantheit überprüft. Dies geschieht z.B. anhand der richtig klassizierten
Instanzen.
4.2 Grundlagen
29
Abbildung 4.1: Data Mining Prozess
Im Folgenden wird näher auf Lernschemata eingegangen, die der Klassikation von
Instanzen dienen, und wie deren Vorhersagequalität bezüglich neuer Instanzen evaluiert werden kann.
4.2.2 Klassikation
Instanzen können mit Hilfe folgender Techniken klassiziert werden:
• Entscheidungsbaum:
Neue Instanzen werden hier mit Hilfe eines Baumes
klassiziert. Dieser bildet so genannte Klassizierungsregeln ab (siehe Abbildung 4.2). In diesem Beispiel (siehe [IHW05]) gilt: wenn die Sonne scheint
und es heiÿ ist, dann kann ich drauÿen spielen. Eine Instanz mit den Werten
Wetter=Sonne,Temp=heiÿ wird also als JA klassiziert.
• Stochastisch: Die Vorhersage der Klasse einer neuen Instanz basiert auf Wahrscheinlichkeiten. Dies kann z.B. mit Hilfe eines Bayes'schen Netzes geschehen
(siehe Abbildung 4.3). Ein Bayes'sches Netz bildet bedingte Wahrscheinlichkeiten ab. Es besteht aus Knoten und Kanten. Dabei führt eine Kante von einem
Knoten zum anderen, wenn eine Abhängigkeit zwischen diesen besteht. In diesem Beispiel (siehe [IHW05]) hängt die Wahrscheinlichkeit von Spielen, von
den Werten Wetter und Temperatur ab. Diese beiden wiederum sind voneinander unabhängig. In den Knoten selbst ist eine Wahrscheinlichkeitstabelle gespeichert. Die dort gespeicherten Wahrscheinlichkeiten werden durch einfaches
Abzählen berechnet. Bei Wetter z.B. werden die Anzahl der Instanzen gezählt,
bei denen Spielen=ja,Wetter=Sonne auftritt und teilt diesen Wert durch die
Anzahl der Spielen=Ja Instanzen. Analog wird mit dem Rest verfahren. Wie
wird eine Instanz Wetter=Sonne,Temperatur=heiÿ klassiziert? Um zu entscheiden, ob diese Instanz als ja oder nein klassiziert wird, müssen zuerst
30
Konzept einer proaktiven Systemüberwachung
Abbildung 4.2: Entscheidungsbaum
die Wahrschenlichkeiten Wetter=Sonne, Temperatur=heiÿ, Spielen=Ja und
Wetter=Sonne, Temperatur=heiÿ, Spielen=Nein berechnet werden. Es wird
dann gerechnet:
P(Wetter=Sonne | Spielen=ja) * P(Temperatur=heiÿ | Spielen=ja) *
* P(ja) = 0,6 *0,7 *0,7 = 0,294
P(Wetter=Sonne | Spielen=nein) * P(Temperatur=heiÿ | Spielen=nein) *
* P(nein) = 0,5 * 0,6 * 0,3 = 0,09
Die Werte müssen noch normalisiert werden, damit sich die Wahrscheinlichkeiten zu 1 addieren.
P(Spielen=ja | Wetter=Sonne,Temperatur=heiÿ) =
0,294
0,294+0,09
=
= 76,56%
P(Spielen=nein | Wetter=Sonne,Temperatur=heiÿ) =
0,09
0,294+0,09
=
= 23,44%
Obige Instanz wird zu ja klassiziert, da die Wahrscheinlichkeit für ja mit
76,56% höher ist als die für nein mit 23,44%.
• Instanzbasiert:
Beim instanzbasierten Lernen wird die zu klassizierende In-
stanz mit den anderen durch eine Distanzfunktion verglichen. Es wird die Klasse
derjenigen Instanz vorhergesagt, welche den minimalsten Abstand hat.
4.2 Grundlagen
31
Abbildung 4.3: Bayes'sches Netzwerk
4.2.3 Evaluierung
Wurde eine Struktur gefunden, dann muss diese auf deren Qualität hin überprüft
werden. Dabei ist es wichtig zu wissen, ob die gefundenen Abhängigkeiten relevant
sind und wie gut damit Vorhersagen gemacht werden können.
Dazu muss zunächst die Struktur mit einer Menge von Instanzen trainiert werden.
Hierbei füllen sich z.B. die Wahrscheinlichkeitstabellen des Bayes'schen Netzes. Anschlieÿend werden mit der trainierten Struktur eine Reihe weiterer Instanzen getestet.
Da in vielen Fällen kein allzu groÿer repräsentativer Datensatz mit hoher Qualität
verfügbar ist, mit dem gearbeitet werden kann, wird dieser bei der Evaluierung per
Zufall in eine Trainings- und Testmenge aufgeteilt (siehe Abbildung 4.4). Geschieht
dies nur einmal, so ist die Gefahr von overtting groÿ, d.h. die gefundene Struktur
passt anscheinend perfekt, allerdings nur auf der verwendeten Trainingsmenge. Damit
lassen sich keine Aussagen über ihre zukünftige Vorhersageleistung machen.
Abbildung 4.4: Evaluierung
Für die Evaluierung der tatsächlichen Leistung eines Lernschemas hat sich die 10fache Crossvalidierung etabliert. Dabei wird der vorhandene Datensatz 10 mal in
32
Konzept einer proaktiven Systemüberwachung
Trainings- und Testmenge geteilt und die Struktur darauf trainiert bzw. getestet.
Dadurch kann overtting vermieden werden. Das Gesamtergebnis wird über die 10
Versuche ermittelt.
Bei der Beurteilung des Ergebnisses spielt nicht nur die Zahl der korrekt klassizierten Instanzen eine Rolle. Je nachdem kann auch wichtig sein, dass die vorhergesagten
nicht weit von den tatsächlichen Werten abweichen und dass das Ergebnis nicht auf
Zufall beruht. Oft ist auch der Wert der false positives (eine Instanz wird fälschlicherweise als ja klassiziert, ist aber nein) und true negatives (eine Instanz wird
fälschlicherweise als nein klassiziert, ist aber ja) von Bedeutung. So kann es z.B.
teurer sein, ein Problem mit einer Maschine zu übersehen, welche tatsächlich einen
Defekt hat, als falschen Alarm bei einer oensichtlich immer korrekt funktionierenden
Maschine zu geben.
4.3 Konzepttest
Im folgenden Abschnitt soll das in Kapitel 4.1 eruierte Konzept mit Hilfe von Data
Mining Techniken getestet werden. Dazu werden zunächst die verwendeten Tools
vorgestellt und anschlieÿend das Vorgehen beim Test beschrieben; danach folgen die
Ergebnisse und ihre Auswertung.
4.3.1 Verwendete Tools
Der Konzepttest erfolgt mit einem in der Programmiersprache JAVA geschriebenen
Data Mining Tool namens WEKA (vgl. [IHW05]). Es bietet eine Reihe von Methoden zur Filterung, Klassizierung, Assoziationsanalyse und zum Clustern von Daten.
WEKA kann über eine graphische Oberäche bedient werden. Für das Sammeln der
benötigten Daten ist ein selbstgeschriebenes JAVA Programm zuständig. Es liest
die auszuwertenden Daten aus einer SQL Datenbank und aggregiert sie. Dabei werden Durchschnittswerte über Intervalle gleicher Länge gebildet. Die Daten werden
anschlieÿend in das ARFF Format umgewandelt, damit sie mit WEKA verarbeitet
werden können.
4.3.2 Vorgehen
Die auszuwertenden Daten werden zunächst in WEKA eingelesen. Anschlieÿend wird
das zu testende Attribut diskretisiert, zusammen mit den gewünschten Zeitpunkten
(Monat, Wochentag, Tageszeit) ausgewählt und der Rest entfernt. Danach wird
4.3 Konzepttest
33
z.B. mit einem Bayes'schen Netz das zu testende Attribut mit Hilfe dieser Zeitpunkte
klassiziert, wobei immer die 10-fache Crossvalidierung benutzt wird.
Eingangs soll untersucht werden, ob unterschiedliche Diskretisierungsmethoden das
Ergebnis bei der Klassikation beeinussen, wobei dafür ein Bayes'sches Netz zum
Einsatz kommt und welche Methode das beste Ergebnis liefert. Anschlieÿend wird
für jedes Attribut die beste Diskretisierungsmethode ausgewählt und untersucht, ob
das Ergebnis durch verschiedene Aggregationsintervalle der Daten verbessert werden kann. Dabei wird die Leistung eines Bayes'schen Netzes mit der eines Entscheidungsbaumes verglichen. Abschlieÿend wird noch untersucht, in wieweit Ausreiÿer
das Ergebnis beeinussen.
4.3.3 Ergebnisse
Denitionen:
• MM:
• dd:
Monat
Wochentag
• HH:
Tageszeit
MMddHH bedeutet, dass für die Vorhersage des Leistungssensors der Monat, der
Wochentag und die Tageszeit genommen wurde. Analog MMdd, MMHH, ddHH, MM,
dd und HH.
• supervised HH:
Es wird die supervised Diskretisierung genommen, welche
unter Einbezug der Tageszeit die numerischen Daten in Intervalle zerlegt. Analog supervised dd und supervised MM.
• unsupervised:
Es wird die unsupervised Diskretisierung genommen, die die
numerischen Daten in Intervalle zerlegt.
• correct (%):
Das ist derjenige Prozentteil, der richtig vorhergesagt wurde.
• incorrect (%):
Das ist entsprechend der falsch vorhergesagte Prozentteil.
• kappa: Gibt an, in wieweit der correct Wert
durch Zufall entstanden ist. Kap-
pa misst also, inwieweit die vorhergesagten mit den tatsächlich beobachteten
Werten übereinstimmen und korrigiert dies um den Zufallsanteil. Kappa kann
einen Maximalwert von 100% haben, was bedeutet, dass der Zufallsanteil 0 ist.
Werte zwischen 60% und 80% sind hervorragend, über 80% ausgezeichnet.
34
Konzept einer proaktiven Systemüberwachung
• Rel. abs. err.:
Das ist der Relative absolute error und gibt an, wie weit die
vorhergesagten von den tatsächlich gemessenen Werten abweichen.
• Root rel. squ. err.: Der Root relative squared error
misst im Prinzip dassel-
be wie der Relative absolute error, Ausreiÿer werden aber stärker gewichtet.
In den folgenden Versuchsreihen wird für jeden getesteten Leistungssensor das beste
Modell ermittelt. Das dabei verwendete Intervall beträgt 10 Minuten.
% Committed Bytes
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
correct (%)
90
79
69
85
60
72
66
incorrect (%)
10
21
31
15
40
28
34
kappa
0,79
0,56
0,37
0,69
0
0,46
0,29
Rel. abs. err. (%)
48
65
79
53
95
70
84
Root rel. squ. err. (%)
62
79
88
69
97
84
92
correct (%)
25
28
12
19
12
21
9
incorrect (%)
75
72
88
81
88
78
91
kappa
0,20
0,23
0,05
0,14
0,05
0,16
0,02
Rel. abs. err. (%)
90
90
98
93
99
93
100
Root rel. squ. err. (%)
95
95
100
97
100
96
100
correct (%)
33
29
22
26
18
20
18
incorrect (%)
66
71
78
74
82
80
82
kappa
0,27
0,23
0,13
0,19
0,06
0,10
0,08
Rel. abs. err. (%)
87
90
95
92
97
95
98
Root rel. squ. err. (%)
93
94
98
96
99
97
100
correct (%)
99
99
99
99
99
99
99
incorrect (%)
1
1
1
1
1
1
1
kappa
0
0
0
0
0
0
0
Rel. abs. err. (%)
73
90
90
78
91
97
98
Root rel. squ. err. (%)
84
99
98
82
100
99
97
supervised HH
supervised dd
supervised MM
unsupervised
Tabelle 4.1: % Committed Bytes
Die beste Diskretisierungsmethode bei % Committes Bytes (auf Deutsch: Zugesicherte verwendete Bytes) ist supervised HH . Unter Verwendung von MMddHH
4.3 Konzepttest
35
werden hier 90% aller Instanzen korrekt klassiziert, mit einem kappa Wert von 0,79
und einer relativ geringen Fehlerrate. Dies ist der unsupervised Diskretisierung vorzuziehen. Bei dieser Methode werden zwar 99% korrekt klassiziert, der kappa Wert
von 0 deutet aber auf ein eher zufälliges Ergebnis hin.
Available Bytes
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
correct (%)
100
100
100
100
100
100
100
incorrect (%)
0
0
0
0
0
0
0
kappa
1
1
1
1
1
1
1
Rel. abs. err. (%)
N
N
N
N
N
N
N
Root rel. squ. err. (%)
N
N
N
N
N
N
N
correct (%)
28
26
12
24
13
23
10
incorrect (%)
72
74
88
76
87
77
90
kappa
0,23
0,20
0,03
0,17
0,02
0,15
0
Rel. abs. err. (%)
88
89
98
92
99
92
100
Root rel. squ. err. (%)
94
95
100
96
99
96
100
correct (%)
30
27
16
26
15
21
11
incorrect (%)
70
73
84
74
85
79
89
kappa
0,24
0,21
0,13
0,07
0,05
0,13
0,01
Rel. abs. err. (%)
90
91
95
97
98
95
99
Root rel. squ. err. (%)
95
95
98
99
99
97
100
correct (%)
80
78
67
78
65
77
64
incorrect (%)
20
22
33
22
35
23
36
kappa
0,51
0,46
0,17
0,47
0
0,42
0,04
Rel. abs. err. (%)
64
67
94
66
97
69
97
Root rel. squ. err. (%)
78
81
98
81
99
83
99
supervised HH
supervised dd
supervised MM
unsupervised
Tabelle 4.2: Available Bytes
Hier ist die beste Diskretisierungsmethode unsupervised. Mit MMddHH werden 80%
der Instanzen korrekt klassiziert. supervised HH scheidet dabei im Vergleich aus,
da eine Erkennungsrate von 100% darauf hindeutet, dass nach der Diskretisierung
nur ein Intervall vorlag. Damit sind keine Vorhersagen möglich.
36
Konzept einer proaktiven Systemüberwachung
Pages /s
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
correct (%)
79
59
79
80
59
59
79
incorrect (%)
21
41
21
20
41
41
21
kappa
0,57
0
0,57
0,58
0
0
0,57
Rel. abs. err. (%)
61
100
61
61
100
100
61
Root rel. squ. err. (%)
78
100
78
78
100
100
78
correct (%)
100
100
100
100
100
100
100
incorrect (%)
0
0
0
0
0
0
0
kappa
1
1
1
1
1
1
1
Rel. abs. err. (%)
N
N
N
N
N
N
N
Root rel. squ. err. (%)
N
N
N
N
N
N
N
correct (%)
58
47
58
58
45
45
58
incorrect (%)
42
53
42
42
55
55
42
kappa
0,31
0,05
0,31
0,32
0
0
0,31
Rel. abs. err. (%)
80
99
80
81
99
100
82
Root rel. squ. err. (%)
90
100
90
90
100
100
90
correct (%)
97
96
97
97
96
96
97
incorrect (%)
3
4
3
3
4
4
3
kappa
0,21
0
0,22
0,22
0
0
0,22
Rel. abs. err. (%)
83
95
84
86
95
99
88
Root rel. squ. err. (%)
89
100
90
89
100
100
89
supervised HH
supervised dd
supervised MM
unsupervised
Tabelle 4.3: Pages /s
Bei Pages /s ist supervised HH die beste Methode. Hier liegt die Erkennungsrate
mit ddHH bei 80%. Dies liegt zwar unter dem Wert bei der unsupervised Diskretisierung, dafür ist der kappa Wert besser. Das gibt den entscheidenden Ausschlag.
supervised dd scheidet aus (vgl. % Committed Bytes).
Pool Nonpaged Bytes
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
correct (%)
100
100
100
100
100
100
100
incorrect (%)
0
0
0
0
0
0
0
kappa
1
1
1
1
1
1
1
supervised HH
4.3 Konzepttest
37
Pool Nonpaged Bytes
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
Rel. abs. err. (%)
N
N
N
N
N
N
N
Root rel. squ. err. (%)
N
N
N
N
N
N
N
correct (%)
13
23
2
11
7
14
2
incorrect (%)
87
77
98
89
93
86
98
kappa
0,12
0,22
0
0,09
0,04
0,12
0
Rel. abs. err. (%)
92
90
100
97
99
96
100
Root rel. squ. err. (%)
97
95
100
100
100
98
100
correct (%)
26
31
7
13
12
17
6
incorrect (%)
74
69
93
87
88
83
94
kappa
0,24
0,28
0,03
0,1
0,07
0,14
0
Rel. abs. err. (%)
88
86
98
96
98
95
100
Root rel. squ. err. (%)
95
92
100
99
99
97
100
correct (%)
54
57
33
44
36
48
29
incorrect (%)
46
43
67
56
64
52
71
kappa
0,38
0,43
0,06
0,25
0,09
0,31
0
Rel. abs. err. (%)
78
76
97
85
96
84
100
Root rel. squ. err. (%)
87
85
100
93
98
92
100
supervised dd
supervised MM
unsupervised
Tabelle 4.4: Pool Nonpaged Bytes
Nur unsupervised unter Verwendung von MMdd liefert hier halbwegs akzeptable
Ergebnisse und ist etwas besser als MMddHH; supervised HH scheidet aus (vgl. %
Committed Bytes).
Processortime (%)
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
correct (%)
84
54
76
84
45
54
76
incorrect (%)
16
46
24
16
55
46
24
kappa
0,75
0,22
0,63
0,75
0
0,22
0,62
Rel. abs. err. (%)
45
93
53
46
100
93
53
Root rel. squ. err. (%)
64
97
72
65
100
97
72
supervised HH
supervised HH supervised dd
correct (%)
67
44
65
67
40
43
65
incorrect (%)
33
56
35
33
60
57
35
38
Konzept einer proaktiven Systemüberwachung
Processortime (%)
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
kappa
0,53
0,15
0,48
0,53
0
0,16
0,48
Rel. abs. err. (%)
61
95
66
62
100
95
66
Root rel. squ. err. (%)
77
98
81
67
100
98
81
correct (%)
65
35
56
64
27
33
55
incorrect (%)
35
65
44
36
73
67
45
kappa
0,55
0,17
0,43
0,53
0,04
0,12
0,42
Rel. abs. err. (%)
63
95
67
64
99
96
68
Root rel. squ. err. (%)
78
98
81
79
100
98
82
correct (%)
88
72
88
88
72
72
88
incorrect (%)
12
27
12
12
27
27
12
kappa
0,70
0
0,71
0,71
0
0
0,71
Rel. abs. err. (%)
43
99
43
43
100
100
43
Root rel. squ. err. (%)
64
100
64
64
100
100
64
supervised MM
unsupervised
Tabelle 4.5: Processortime (%)
Bei Processortime (%) kann die unsupervised Diskretisierung mit Verwendung von
HH favorisiert werden. Der entscheidende Punkt ist hier die bessere Erkennungsrate
als bei supervised HH mit leicht geringeren Fehlerraten.
Interrupts /s
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
correct (%)
69
47
69
69
43
47
69
incorrect (%)
31
53
31
31
57
53
31
kappa
0,51
0,13
0,49
0,50
0
0,13
0,50
Rel. abs. err. (%)
65
97
67
65
100
97
68
Root rel. squ. err. (%)
80
98
82
80
100
99
83
correct (%)
83
76
81
83
75
75
81
incorrect (%)
17
24
19
17
25
25
19
kappa
0,48
0,14
0,39
0,47
0
0
0,40
Rel. abs. err. (%)
66
89
77
67
100
89
77
Root rel. squ. err. (%)
79
94
88
79
100
94
88
75
69
76
75
69
69
76
supervised HH
supervised dd
supervised MM
correct (%)
4.3 Konzepttest
39
Interrupts /s
Zeitpunkte
MMddHH
MMdd
MMHH
ddHH
MM
dd
HH
incorrect (%)
25
31
24
25
31
31
24
kappa
0,32
0
0,34
0,33
0
0
0,34
Rel. abs. err. (%)
80
98
81
80
100
99
82
Root rel. squ. err. (%)
90
99
91
90
100
99
91
correct (%)
85
84
85
85
84
84
86
incorrect (%)
15
16
15
15
16
16
14
kappa
0,31
0
0,33
0,33
0
0
0,35
Rel. abs. err. (%)
80
98
80
80
99
99
81
Root rel. squ. err. (%)
89
100
89
89
100
100
89
unsupervised
Tabelle 4.6: Interrupts /s
In diesem Test zeigt sich, dass bei Interrupts /s vorrangig die supervised dd Diskretisierungsmethode genommen werden sollte. Die Erkennungsrate liegt unter Verwendung von MMddHH mit 83% knapp unter unsupervised, dafür ist der kappa
Wert höher und die Fehlerrate geringer.
In den nachfolgenden Testreihen wird das für jeden einzelnen Leistungssensor beste
Modell, welches in den vorangegangenen Tests gefunden worden ist, mit unterschiedlichen Intervallen getestet.
% Committed Bytes superv. HH MMddHH
Intervall
10
15
20
30
60
correct (%)
90
90
90
88
88
incorrect (%)
10
10
10
12
12
kappa
0,79
0,78
0,78
0,76
0,76
Rel. abs. err. (%)
48
46
45
50
51
Root rel. squ. err. (%)
62
61
61
65
65
Bayes Net
Entscheidungsbaum J48
correct (%)
86
83
83
84
86
incorrect (%)
14
17
17
16
14
kappa
0,70
0,63
0,64
0,68
0,71
Rel. abs. err. (%)
45
52
53
47
41
Root rel. squ. err. (%)
71
77
77
73
69
Tabelle 4.7: % Committed Bytes Intervall
40
Konzept einer proaktiven Systemüberwachung
Hier zeigt sich, dass im Falle % Committed Bytes die Erkennungsrate durch Aggregierung der Daten in längere Intervalle leicht abnimmt, aber immer noch akzeptabel
ist. Dabei sinkt der kappa Wert und die Fehlerraten steigen. Der Erkennungsbaum
liefert schlechtere Ergebnisse als das Bayes'sche Netz.
Available Bytes unsuperv. MMddHH
Intervall
10
15
20
30
60
correct (%)
80
83
84
88
93
incorrect (%)
20
17
16
12
7
kappa
0,51
0,56
0,57
0,62
0,75
Rel. abs. err. (%)
64
59
59
52
42
Root rel. squ. err. (%)
78
75
75
72
64
Bayes Net
Entscheidungsbaum J48
correct (%)
80
83
84
88
93
incorrect (%)
20
17
16
12
7
kappa
0,53
0,55
0,58
0,62
0,75
Rel. abs. err. (%)
64
61
58
53
42
Root rel. squ. err. (%)
80
78
76
73
65
Tabelle 4.8: Available Bytes Intervall
Hier nehmen die Erkennungsrate und der kappa Wert mit steigender Intervalllänge
signikant zu, die Fehlerraten sinken. Dabei liefern das Bayes'sche Netz und der
Entscheidungsbaum fast identische Ergebnisse.
Pages /s superv. HH ddHH
Intervall
10
15
20
30
60
correct (%)
80
83
84
87
90
incorrect (%)
20
17
16
13
10
kappa
0,58
0,62
0,67
0,73
0,8
Rel. abs. err. (%)
61
56
51
45
36
Root rel. squ. err. (%)
78
74
70
65
58
Bayes Net
Entscheidungsbaum J48
correct (%)
80
83
85
88
91
incorrect (%)
20
17
15
12
9
kappa
0,59
0,64
0,68
0,75
0,82
Rel. abs. err. (%)
58
52
47
39
31
Root rel. squ. err. (%)
77
73
69
64
56
4.3 Konzepttest
41
Pages /s superv. HH ddHH
Intervall
10
15
20
30
60
Tabelle 4.9: Pages /s Intervall
In diesem Test zeigt sich dasselbe Bild wie bei Available MB. Die Erkennungsrate
und der kappa Wert nehmen mit steigender Intervalllänge signikant zu und dies bei
fallenden Fehlerraten. Das Bayes'sche Netz und der Entscheidungsbaum liefern fast
identische Ergebnisse, wobei der Entscheidungsbaum etwas besser ist.
Pool Non. Bytes unsuperv. MMdd
Intervall
10
15
20
30
60
correct (%)
57
47
50
47
43
incorrect (%)
43
53
50
53
57
kappa
0,43
0,32
0,34
0,34
0,29
Rel. abs. err. (%)
76
83
83
81
84
Root rel. squ. err. (%)
85
89
90
89
91
Bayes Net
Entscheidungsbaum J48
correct (%)
62
51
56
53
53
incorrect (%)
38
49
44
47
47
kappa
0,49
0,39
0,44
0,42
0,43
Rel. abs. err. (%)
64
73
69
73
72
Root rel. squ. err. (%)
80
86
83
86
85
Tabelle 4.10: Pool Nonpaged Bytes Intervall
In diesem Test sinken die Erkennungsrate und der kappa Wert mit steigender Intervalllänge. Dabei nehmen die Fehlerquoten leicht zu. Das Bayes'sche Netz schneidet
hier wesentlich schlechter ab als der Entscheidungsbaum.
Processortime unsuperv. HH
Intervall
10
15
20
30
60
correct (%)
88
87
87
91
93
incorrect (%)
12
13
13
9
7
kappa
0,71
0,70
0,72
0,79
0,83
Rel. abs. err. (%)
43
44
43
36
29
Root rel. squ. err. (%)
64
65
64
58
53
Bayes Net
Entscheidungsbaum J48
42
Konzept einer proaktiven Systemüberwachung
Processortime unsuperv. HH
Intervall
10
15
20
30
60
correct (%)
88
87
87
91
93
incorrect (%)
12
13
13
9
7
kappa
0,71
0,70
0,72
0,79
0,83
Rel. abs. err. (%)
40
42
41
33
28
Root rel. squ. err. (%)
64
65
64
58
53
Tabelle 4.11: Processortime (%) Intervall
Bei Processortime (%) steigt die Erkennungsrate und der kappa Wert bei steigender Intervalllänge. Dies hat eine sinkende Fehlerquote zur Folge. Die Ergebnisse des
Bayes'schen Netzes sind mit denen des Entscheidungsbaumes fast identisch. Der Entscheidungsbaum zeigt aber leicht niedrigere Fehlerquoten.
Interrupts /s superv. dd MMddHH
Intervall
10
15
20
30
60
correct (%)
83
86
87
89
94
incorrect (%)
17
14
13
11
6
kappa
0,48
0,62
0,63
0,71
0,83
Rel. abs. err. (%)
66
60
60
57
49
Root rel. squ. err. (%)
79
74
73
70
63
Bayes Net
Entscheidungsbaum J48
correct (%)
85
89
90
91
94
incorrect (%)
15
11
10
9
6
kappa
0,71
0,70
0,75
0,76
0,84
Rel. abs. err. (%)
40
42
40
37
26
Root rel. squ. err. (%)
64
67
66
65
54
Tabelle 4.12: Interrupts /s Intervall
Hier dasselbe Bild wie bei Processortime (%). Die Erkennungsrate und der kappa
Wert steigen, die Fehlerquoten fallen. Der Entscheidungsbaum liefert die besseren
Ergebnisse.
Die abschlieÿenden Versuche befassen sich mit dem Einuss von Ausreiÿern auf die
Vorhersagegenauigkeit. Dabei wird für jeden Leistungssensor wieder das beste Modell
verwendet.
4.3 Konzepttest
43
% Committed Bytes superv. HH MMddHH
normal
mit Ausreiÿer
correct (%)
90
90
incorrect (%)
10
10
kappa
0,79
0,79
Rel. abs. err. (%)
48
48
Root rel. squ. err. (%)
62
52
Tabelle 4.13: % Committed Bytes Ausreiÿer
Wie aus der Tabelle ersichtlich ist, haben Ausreiÿer bei der supervised Diskretisierung keinen groÿen Einuss. Das liegt daran, dass die Intervalle unter Einbezug eines
anderen Wertes gebildet werden.
Available Bytes unsuperv. MMddHH
normal
mit Ausreiÿer
correct (%)
90
100
incorrect (%)
10
0
kappa
0,79
0
Rel. abs. err. (%)
48
50
Root rel. squ. err. (%)
62
100
Tabelle 4.14: Available Bytes Ausreiÿer
Ein Ausreiÿer genügt hier, um das vormals hervorragende Ergebnis ins Gegenteil
umzukehren. Er sorgt dafür, dass bei der unsupervised Diskretisierung die Instanzen
nicht mehr gleichmäÿig in den Intervallen abgebildet werden, was für das schlechte
Ergebnis verantwortlich ist.
Pages /s superv. HH ddHH
correct (%)
normal
mit Ausreiÿer
80
79
incorrect (%)
20
21
kappa
0,58
0,57
Rel. abs. err. (%)
61
61
Root rel. squ. err. (%)
78
78
Tabelle 4.15: Pages /s Ausreiÿer
44
Konzept einer proaktiven Systemüberwachung
Der Ausreiÿer hat hier, wie unter % Committed bytes, fast keine Auswirkungen auf
das Ergebnis. Er taucht im Ergebnis nur als falsch klassiziert auf.
Pool Non. Bytes unsuperv. MMdd
normal
mit Ausreiÿer
correct (%)
57
100
incorrect (%)
43
0
kappa
0,43
1
Rel. abs. err. (%)
76
N
Root rel. squ. err. (%)
85
N
Tabelle 4.16: Pool Nonpaged Bytes Ausreiÿer
Wie bei Available Bytes, ist durch einen Ausreiÿer eine korrekte Klassizierung nicht
mehr möglich.
Processortime unsuperv. HH
normal
mit Ausreiÿer
correct (%)
88
95
incorrect (%)
12
5
kappa
0,71
0,87
Rel. abs. err. (%)
43
24
Root rel. squ. err. (%)
64
46
Tabelle 4.17: Processortime Ausreiÿer
Ein einzelner Ausreiÿer hat hier eine signikante Steigerung der Erkennungsrate und
des kappa Wertes zur Folge, die Fehlerquoten sinken stark. Hier hat der Ausreiÿer eine
bessere Abbildung der Instanzen in Intervallen zur Folge, was das bessere Ergebnis
erklärt.
Interrupts /s superv. dd MMddHH
normal
mit Ausreiÿer
correct (%)
83
83
incorrect (%)
17
17
kappa
0,48
0,48
Rel. abs. err. (%)
66
66
Root rel. squ. err. (%)
79
79
Tabelle 4.18: Interrupts /s Ausreiÿer
4.4 Zusammenfassung
45
Wie in den vorherigen Tests hat auch hier bei der supervised Diskretisierung ein
Ausreiÿer keinen Einuss auf das Ergebnis.
4.4 Zusammenfassung
Abschlieÿend kann festgestellt werden, dass die Klassikation von Leistungssensorinstanzen nach Zeitpunkten sehr gut funktioniert. Dabei sind durchschnittliche Erkennungsraten von 80-90% möglich. Dies funktioniert allerdings nur, wenn die richtige
Diskretisierungsmethode ausgewählt und die richtigen Zeitpunkte verwendet wurden. Die unsupervised Diskretisierung hat den groÿen Nachteil, dass Ausreiÿer eine
gleichmäÿige Aufteilung der Instanzen in Intervalle verhindert, was schlechtere Ergebnisse bei der Klassizierung nach sich ziehen kann. Die Erkennungsrate läÿt sich
oft noch steigern und die Fehlerraten minimieren, wenn die Daten in längeren Intervallen aggregiert sind. Das Bayes'sche Netz und der Entscheidungsbaum liefern
vergleichbare Ergebnisse.
5 Prototyp
5.1 Anforderungen
An den Prototyp werden folgende Anforderungen gestellt:
•
Der Prototyp soll eine proaktive Systemüberwachung implementieren.
•
Der Systemzustand soll in einem Cockpit angezeigt werden.
•
Die Leistungswerte des zu überwachenden Systems müssen nicht selbst gemessen werden.
5.2 Implementierung
Der Prototyp implementiert das in Kapitel 4.1 vorgestellte Konzept einer proaktiven
Systemüberwachung. Dabei gibt es allerdings zwei Probleme:
1. Wie die Ergebnisse des Konzepttests in Kapitel 4.3 zeigen, haben Ausreiÿer je
nach verwendeter Diskretisierungsmethode mehr oder weniger starken Einuss
auf das Vorhersageergebnis.
Wenn das Tool, basierend auf den gemessenen Daten, nach einem Neustart
erneut einen Entscheidungsbaum oder ein Bayes'sches Netz berechnet und dabei
Ausreiÿer berücksichtigt, bekommt der Benutzer hiervon keine Information und
kann dadurch die Qualität der gefundenen Lernstruktur nicht beurteilen. Der
Benutzer wundert sich anschlieÿend nur, warum das Tool schlechte Vorhersagen
macht.
2. Nach der Diskretisierung von numerischen Werten liegt die untere Intervallgrenze bei
−∞
und die obere bei
∞.
Dadurch können kritische Werte im nied-
rigsten und höchsten Intervall nicht mehr festgestellt werden. Beispiel: Wird
bei Available MB das erste Intervall vorhergesagt, welches z.B.
] − ∞, 200] ist,
dann kann ein kritischer Wert von 5 MB nicht mehr erkannt werden.
46
5.3 Überblick
47
Diese Probleme führen zu folgenden Implementierungsentscheidungen:
1. Lernstrukturen werden nicht automatisch neu berechnet. Dies muss vom Benutzer übernommen werden, wobei dafür das in Kapitel 4.3.1 kurz vorgestellte
WEKA Tool am Besten geeignet ist. Danach muss er entscheiden, ob die Ergebnisse brauchbar sind und die gefundene Lernstruktur abspeichern. Vernünftig
geht das allerdings nur mit Bayes'schen Netzen, da sich diese als XML Datei abspeichern lassen. Sinkt nun die Vorhersagequalität auf ein unakzeptables Maÿ,
so muss dieser Prozess wiederholt werden.
2. Für einzelne Leistungssensoren muss
−∞
bzw.
∞
durch einen Grenzwert er-
setzt werden. Dabei genügt es entweder einen oberen oder unteren Grenzwert
anzugeben. Bei der Vorhersage eines Leistungswertes zu einem gewünschten
Zeitpunkt genügt es, nur eine obere oder untere Grenze anzugeben. Um noch
einmal obiges Beispiel aufzugreifen: bei Available MB ist nur die Abweichung
nach unten interessant. Eine Abweichung nach oben ist in Ordnung, da plötzlich frei werdender Speicher nicht kritisch ist. Im Intervall
] − ∞, 200] kann −∞
z.B. durch 50 ersetzt werden. 50 bildet nun die absolute untere Grenze; damit
kann ein Wert von 5 als kritisch erkannt werden.
3. Das Abspeichern von Bayes'schen Netzen und die Denition von Grenzwerten
macht eine Kongurationsdatei nötig, in welcher diese dann einem Leistungssensor zugeordnet werden können.
5.3 Überblick
5.3.1 Aufbau
Der Prototyp ist in drei Teile gegliedert (siehe Abbildung 5.1):
• System:
Das System stellt die Logik für die Benutzeroberäche bereit. Es be-
steht aus:
Klassizierer:
Er berechnet die Vorhersagen für den gewünschten Zeit-
punkt.
Datenbankzugri : Diese Komponente ist für den Zugri auf die Datenbank zuständig, in der die aktuellen Leistungsdaten des zu überwachenden
Systems gespeichert sind. Sie implementiert auÿerdem einen Datenbankcache.
48
Prototyp
Statusauswertung:
Hier wird der aktuelle Systemstatus berechnet, ba-
sierend auf den gemessenen und vorhergesagten Werten.
Kongurationsmanager:
Er lädt und speichert die Konguration des
Systems.
• Controller:
• GUI:
Er bietet für die GUI Zugri auf das System.
Dies ist die Benutzeroberäche. Sie besteht aus:
Cockpit: Hier werden die aktuellen und die vorhergesagten Werte, sowie
der Systemstatus angezeigt. Der Status zeigt dabei Normal mit Grün,
Warnung mit Orange und Kritisch mit Rot an.
Historie: Hier werden die vorhergesagten und gemessenen Werte der letzten Tage angezeigt.
Konguration: Mit dieser Komponente kann die Konguration des Systems bearbeitet werden.
Renderer:
Diese Komponente ist für die Abfrage und das Abbilden der
gemessenen und vorhergesagten Werte zuständig.
Abbildung 5.1: Aufbau des Prototyps
Die Konguration des Systems besteht aus folgenden Teilen:
5.3 Überblick
49
• Server:
Der zu dem Leistungssensor gehörige Server.
• Object:
Das zu dem Leistungssensor gehörige Object, z.B. Speicher.
• Counter:
• Instanz:
Der Name des Leistungssensors selbst, z.B. Verfügbare MB.
Die Instanz des Leistungssensors, z.B. 0, 1, 2 bei mehreren Prozesso-
ren. Sie enthält die weitere Konguration des Leistungssensors:
Datei:
Die Datei, worin das zugehörige Bayes'sche Netzwerk gespeichert
ist.
Intervall:
Das Intervall in Minuten, das für die Aggregation der Daten
verwendet wurde. Achtung: Dieses muss mit dem bei der Berechnung des
Bayes'schen Netzwerkes verwendeten Intervall übereinstimmen, da sonst
keine Vorhersagen gemacht werden können. Beispiel: Ist ein Intervall von
20 Minuten eingegeben, so können Vorhersagen für z.B. 10:00 Uhr, 10:20
Uhr, 10:40 Uhr gemacht werden, aber nicht für 10:10 Uhr.
Lookahead:
Hier sind die vorherzusagenden Zeitschritte angegeben. Bei
z.B. einem Wert von 3 und einem Intervall von 20 Minuten werden die
nächsten 60 Minuten vorausgesagt.
Grenzwert:
Das ist der Grenzwert des Leistungssensors, ab dem sein
Zustand als kritisch eingestuft wird.
Abweichung:
Die Abweichung wird in Prozent angegeben. Dies dient
bei stark schwankenden Leistungssensoren dazu, die Vorhersagegrenzen
um einen gewissen Prozentsatz nach oben bzw. nach unten zu verändern,
damit nicht jedes Mal ein Fehler angezeigt wird.
Richtung: Die Richtung kann entweder oben
oder unten sein. Sie be-
stimmt, ob der Grenzwert ein unterer oder oberer Grenzwert ist und ob
ein aktuell gemessener Wert nach oben oder unten von der vorhergesagten
Grenze abweichen darf.
5.3.2 Funktionsweise
Beim Systemstart wird zunächst die Konguration des Systems aus einer XML Datei
eingelesen (siehe Abbildung 5.2). Für jeden dort gespeicherten Leistungssensor wird
ein eigener Klassizierer angelegt. Dieser liest anschlieÿend das zu dem Leistungssensor gehörige Bayes'sche Netzwerk aus der in der Konguration angegebenen Datei
ein. Der Klassizierer kann damit zu einem gewünschten Zeitpunkt eine Vorhersage
treen.
50
Prototyp
Die Vorhersage für den aktuellen Zeitpunkt wird mit dem gerade gemessenen Wert
verglichen und daraus der Status des Leistungssensors gewonnen. Dieser wird folgendermaÿen bewertet:
•
Wurde in der Konguration des betreenden Leistungssensors als Abweichung
unten angegeben, so sind alle Werte, die über der Vorhersagegrenze + Abweichung liegen, als Normal einzustufen. Liegen sie darunter, dann wird der
Systemzustand Warnung ausgegeben; liegen sie unter dem in der Konguration angegebenen Grenzwert, so ist der Systemzustand Kritisch.
•
Wurde in der Konguration des betreenden Leistungssensors als Abweichung
oben angegeben, so sind alle Werte, die unter der Vorhersagegrenze + Abweichung liegen, als Normal einzustufen. Liegen sie darüber, dann wird als
Systemzustand Warnung ausgegeben; liegen sie über dem in der Konguration angegebenen Grenzwert, so ist der Systemzustand Kritisch.
Der im Cockpit angezeigte Gesamtstatus des zu überwachenden Systems richtet sich
nach den Stati der einzeln überwachten Leistungssensoren. Tritt nur bei einem Sensor der Status Warnung auf, so ist auch der Gesamtstatus Warnung. Analog beim
Status Kritisch. Der Gesamtstatus ist also Normal, wenn der Status aller Leistungssensoren Normal ist.
Abbildung 5.2: Funktionsweise des Prototyps
5.4 Leistungstest
51
5.4 Leistungstest
In diesem Kapitel wird die Leistung des Prototypen getestet. Dazu wurden die Leistungssensoren aus Kapitel 4.3 genommen. Das verwendete Intervall beträgt 20 Minuten. Für jeden Sensor wurde entsprechend der Ergebnisse aus Kapitel 4.3 das beste
Modell ausgewählt und damit ein Bayes'sches Netz trainiert. Es wurden genommen:
• % Committed Bytes:
• Available MB:
• Pages /s:
supervised HH MMddHH
unsupervised MMddHH
supervised HH ddHH
• Pool Nonpaged Bytes:
• Processortime (%):
• Interrupts /s:
sunupervised MMdd
unsupervised HH
supervised dd MMddHH
Der Startzeitpunkt des Tests ist der 15. November 2005 um 00:00 Uhr. Die Ergebnisse
werden über einen 7 Tage zurückliegenden Zeitraum erhoben.
Leistungssensor
Werte
Normal
Warnung
Kritisch
% Committed Bytes
505
505 (100%)
0 (0%)
0 (0%)
Available MB
505
505 (100%)
0 (0%)
0 (0%)
Pages /s
505
440 (87%)
65 (13%)
0 (0%)
Pool Nonpaged Bytes
505
505 (100%)
0 (0%)
0 (0%)
Processortime (%)
505
446 (88%)
59 (12%)
0 (0%)
Interrupts /s
505
486 (96%)
18 (4%)
1 (0%)
Tabelle 5.1: Prototyptest
Der Test ist noch einmal graphisch in den Abbildungen 5.3, 5.4, 5.5, 5.6, 5.7 und
5.8 aufbereitet. Die rote Linie bildet die vorhergesagten Werte, die blaue Linie die
tatsächlich gemessenen Werte ab. Nur bei Available MB wird die Abweichung nach
unten berücksichtigt, beim Rest die Abweichung nach oben. Wie vor allem bei Pages
/s, Processortime (%) und Pool Nonpaged Bytes zu ersehen ist, passt sich die
rote der blauen Linie sehr gut an. Das bei der Vorhersage verwendete Bayes'sche Netz
bildet die Systemlast sehr gut ab. Die Ausreiÿer der roten Linie z.B. bei % Committed
Bytes liegen daran, dass das höchste bzw. niedrigste Intervall vorhergesagt wird.
Dort ist die Ober- bzw. Untergrenze derjenige Grenzwert, der in der Konguration
festgelegt wurde und dieser Wert kann weit vom aktuellen abweichen.
52
Prototyp
Abbildung 5.3: % Committed Bytes
Abbildung 5.4: Available MB
5.4 Leistungstest
53
Abbildung 5.5: Pages /s
Abbildung 5.6: Pool Nonpaged Bytes
54
Prototyp
Abbildung 5.7: Processortime (%)
Abbildung 5.8: Interrupts /s
5.5 Benutzeroberäche
55
Wie in Abbildung 5.7 und 5.5 zu ersehen ist, war die Systemlast tagsüber eher gering.
Hier werden die Werte am genauesten vorhergesagt. Würde hier ein Leistungsproblem
auftreten, ist sicher gestellt, dass der Prototyp es erkennt und anzeigt. Abends nden
diverse Backupprozesse statt, was die Systemlast nach oben schnellen läÿt und die
Vorhersage ungenauer macht.
5.5 Benutzeroberäche
Das Cockpit (siehe Abbildung 5.9) gliedert sich in drei Teile. Links oben bendet
sich ein Baum mit Leistungssensoren. Die aktuell gemessenen und die vorhergesagten
Werte eines gewünschten Leistungssensors können im Monitor in der Mitte angezeigt
werden. Die blaue Linie bildet die vorhergesagten Werte ab, die andere Linie die gemessenen Werte. Diese färbt sich je nach Zustand des Leistungssensors bei Normal
Grün (siehe Abbildung 5.9 Pages /s), bei Warnung Orange (siehe Abbildung 5.9
Interrupts /s) und bei Kritisch Rot. Die gestrichelte Linie zeigt den aktuell gemessenen Wert an. Links unten wird der Systemstatus angezeigt. Hier gilt dasselbe
wie im Monitor: Grün bedeutet Normal, Warnung Orange und Kritisch Rot.
Abbildung 5.9: Cockpit
Für einen Leistungssensor kann auch die Historie angezeigt werden (siehe Abbildung
5.10), wozu ein neues Fenster Historie erscheint. Dieses ist in drei Teile gegliedert.
Links oben wird eine Statistik angezeigt, woran abgelesen werden kann, wie viele
56
Prototyp
Abbildung 5.10: Historie
Normal-, Warnung- und Kritisch- Zustände es während des Anzeigezeitraumes
gegeben hat. In der Mitte wird die Historie des Leistungssensors dargestellt. Die rote
Linie bildet die zu einem Zeitpunkt vorhergesagten, die blaue Linie die gemessenen
Werte ab. Links unten kann der Anzeigezeitraum abgelesen und die Anzahl der anzuzeigenden Tage eingestellt werden.
Wie in Abbildung 5.10 zu ersehen ist, arbeitet die Vorhersage genau.
Über einen Kongurationsdialog (siehe Abbildung 5.11) können Leistungssensoren
neu angelegt, bearbeitet oder gelöscht werden. Dabei ist darauf zu achten, dass der angegebene Pfad derjenigen Datei, in der das zum Leistungssensor gehörige Bayes'sche
Netz gespeichert ist, stimmt und dass das angegebene Intervall zum Bayes'schen Netz
passt.
5.6 Schwächen
Dieser Prototyp hat Schwächen. Durch den Umstand, dass er die Leistungswerte des
zu überwachenden Exchange Servers nicht selbst miÿt, sondern aus einer Datenbank
ausliest, treten folgende Probleme auf:
•
Das Cockpit kennt die Bedeutung des gemessenen Leistungssensors nicht. Es
nimmt die Leistungswerte nur als Zahlen wahr und erkennt nicht, wie er mit
5.7 Zusammenfassung
57
Abbildung 5.11: Konguration
anderen zusammenhängt.
•
Ein ausgefeilteres Konzept, bei dem Leistungssensoren untereinander abhängig
sind, ist nur bedingt möglich. Dieses Konzept wäre davon abhängig, welche
Leistungswerte des Exchange Servers in die Datenbank geschrieben werden.
•
Die Leistungswerte in der Datenbank sind leicht zu manipulieren. Das Cockpit
würde dies nicht erkennen.
Eine weitere Schwäche ist, dass der aktuell angezeigte Gesamtzustand des zu überwachenden Systems von jedem einzelnen Leistungssensor abhängig ist (siehe Kapitel
5.3.2). Wenn z.B. bei der Prozessorzeit ein Wert von 6 gemessen und ein Wert von 5
vorhergesagt wird, dann wird als Gesamtstatus Warnung ausgegeben, obwohl dies
in der Gesamtheit nicht korrekt ist.
5.7 Zusammenfassung
Es hat sich gezeigt, dass das in Kapitel 4.1 vorgestellte Konzept einer proaktiven
Systemüberwachung, bis auf wenige Probleme, sehr gut umzusetzen ist. Durch die
58
Prototyp
Erweiterung, dass nur noch eine Abweichung des gemessenen vom vorhergesagten
Wert nach oben oder unten berücksichtigt wird und nicht beide, können die in Kapitel 4.3 gewonnenen Ergebnisse noch gesteigert werden. Wie auf den verschiedenen
Abbildungen in Kapitel 5.4 zu ersehen ist, werden die gemessenen durch die vorhergesagten Werte sehr gut abgebildet. Tagsüber ist die Last auf dem überwachten
Exchange Server eher gering, so dass hier die Vorhersage am besten ausfällt. Abends
hingegen, steigt die Last durch Backupprozesse. Dies hat zur Folge, dass in dieser
Zeit die Vorhersage ungenauer ist.
6 Erkenntnisse
6.1 Related Work
Proaktive Systemüberwachung ist ein aktuelles Thema. Es wurde nicht nur in dieser
Arbeit aufgegrien, auch die Firma HP forscht daran. In [RP05] wurden verschiedene
Konzepte entwickelt, um die Anzahl an Service Level Objectives (SLO) Verletzungen bei bestimmten Leistungssensoren eine Stunde vorherzusagen. Ein SLO deniert
beispielsweise bei Processorzeit (%) einen maximalen Grenzwert. Diese Konzepte
wurden an einer groÿen Webapplikation bestehend aus mehreren Servern getestet. Es
hat sich gezeigt, dass mit Hilfe von Bayes'schen Netzen die besten Ergebnisse erreicht
wurden. Allerdings war die Vorhersagegenauigkeit, wie in dieser Arbeit in Kapitel 4.3
erörtert, sehr von der Modellauswahl abhängig. Dies betrit die Auswahl der Attribute für die Vorhersage, sowie die Art der angewandten Transformationen auf die
Daten.
6.2 Zusammenfassung
Die vorliegende Arbeit hat sich mit der Systemüberwachung eines Exchange MailServers beschäftigt. Ziel war die Entwicklung eines Konzepts zur proaktiven Systemüberwachung und dessen Umsetzung in ein Cockpit. Dieses soll dem Anwender
den Zustand des zu überwachenden Systems möglichst einfach zugänglich machen. In
Kapitel 4.1 wurden dazu zunächst Überlegungen angestellt, wie eine proaktive Systemüberwachung aussehen könnte, und darauf aufbauend ein Monitoring Konzept
vorgestellt. Dieses wurde anschlieÿend in Kapitel 5 in einem Prototypen implementiert.
Kapitel 4.3 hat gezeigt, dass die Leistungswerte eines Exchange Servers sehr gut vorhergesagt werden können. Es wurden Vorhersagegenauigkeiten von durchschnittlich
80-90% erreicht. Allerdings können einzelne Ausreiÿer in den Leistungswerten dazu führen, dass sich die vormals sehr gute Genauigkeit ins Gegenteil umkehrt und
plötzlich keine guten Vorhersagen mehr möglich sind. Dieses Verhalten führt bei der
Implementierung des Konzepts zu Problemen, was in Kapitel 5.2 aufgegrien wird.
59
60
Erkenntnisse
Die Systemüberwachung kann daher nicht vollautomatisch ablaufen, da es nicht über
das Wissen verfügt, Ausreiÿer zu erkennen und diese aus dem Konzept zu eliminieren.
Trotzdem läÿt sich das Konzept aus Kapitel 4.1 sehr gut in einen Prototypen implementieren. Wie Kapitel 5.4 zeigt, können die Ergebnisse aus Kapitel 4.3 sogar noch
übertroen werden. Die vorhergesagten bilden die tatsächlich gemessenen Werte sehr
gut ab. Bei der Systemüberwachung können somit Leistungsspitzen, die im normalen
Betrieb eines Exchange Servers durchaus normal sind, miteinbezogen werden.
6.3 Ausblick
In dieser Arbeit wurde ein Konzept für eine proaktive Systemüberwachung entwickelt
und dieses in einem Prototypen implementiert. Der Prototyp hat allerdings einige
Schwächen, wie in Kapitel 5.6 beschrieben wurde. Für weiterführende Arbeiten an
diesem Thema wären folgende Aufgabenstellungen interessant:
• Implementierung einer Meÿfunktion: Der Prototyp sollte eine eigene Meÿfunktion implementieren, damit er die Leistungswerte des zu überwachenden
Exchange Servers direkt messen kann. Damit können die in Kapitel 5.6 beschriebenen Schwächen des Prototyps umgangen werden.
• Einführung eines Meta Modells:
Mit diesem Modell wird dem einzelnen
Leistungssensor eine Bedeutung gegeben. Damit können Abhängigkeiten unter
den Leistungssensoren abgebildet werden. Dies wäre wichtig, um bei Problemen
eines Leistungssensors die mit ihm korrelierten Leistungssensoren abzufragen.
• Einführung eines Gesamtstatuskonzepts:
Durch dieses Konzept soll der
Gesamtstatus (vgl. Kapitel 5.4) des zu überwachenden Exchange Servers, aufbauend auf den Einzelstati der Leistungssensoren, besser abgebildet werden.
Damit wird die Bewertung des Systemstatus auf der Gesamtheit der Leistungssensoren möglich sein.
Abbildungsverzeichnis
2.1
Exchange Server Architektur Quelle : [Tea04] . . . . . . . . . . . . . .
4
2.2
Interprozesskommunikation Quelle : [Tea04] . . . . . . . . . . . . . . .
7
2.3
Exchange Datenbank Aufbau Quelle : [Tea04] . . . . . . . . . . . . . .
7
2.4
Exchange Datenbank Funktionsweise Quelle : [Tea04]
. . . . . . . . .
9
3.1
Virtuelle Speicherverwaltung (vgl. [Fri]) . . . . . . . . . . . . . . . . .
12
3.2
Standby-, Frei- und Nullliste (vgl. [Fri]) . . . . . . . . . . . . . . . . .
13
3.3
Copy Interface (vgl. [MF02]) . . . . . . . . . . . . . . . . . . . . . . .
15
3.4
Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.1
Data Mining Prozess
. . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2
Entscheidungsbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3
Bayes'sches Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.4
Evaluierung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.1
Aufbau des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.2
Funktionsweise des Prototyps
. . . . . . . . . . . . . . . . . . . . . .
50
5.3
% Committed Bytes
. . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.4
Available MB
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.5
Pages /s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.6
Pool Nonpaged Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.7
Processortime (%)
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.8
Interrupts /s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.9
Cockpit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.10 Historie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.11 Konguration
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
61
Tabellenverzeichnis
3.1
Ergebnistabelle
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
% Committed Bytes
4.2
Available Bytes
. . . . . . . . . . . . . . . . . . . . . . . . . . .
34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3
Pages /s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.4
Pool Nonpaged Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.5
Processortime (%)
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.6
Interrupts /s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.7
% Committed Bytes Intervall
. . . . . . . . . . . . . . . . . . . . . .
39
4.8
Available Bytes Intervall
. . . . . . . . . . . . . . . . . . . . . . . . .
40
4.9
Pages /s Intervall . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.10 Pool Nonpaged Bytes Intervall . . . . . . . . . . . . . . . . . . . . . .
41
4.11 Processortime (%) Intervall
. . . . . . . . . . . . . . . . . . . . . . .
42
4.12 Interrupts /s Intervall . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.13 % Committed Bytes Ausreiÿer . . . . . . . . . . . . . . . . . . . . . .
43
4.14 Available Bytes Ausreiÿer
. . . . . . . . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.16 Pool Nonpaged Bytes Ausreiÿer . . . . . . . . . . . . . . . . . . . . .
44
4.17 Processortime Ausreiÿer
. . . . . . . . . . . . . . . . . . . . . . . . .
44
4.18 Interrupts /s Ausreiÿer . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.1
51
4.15 Pages /s Ausreiÿer
62
24
Prototyptest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Literaturverzeichnis
[Bjo97]
Bjorklund, Gus: Transaction logging concepts, Juli 1997.
[Coc02]
Cochran, Jerry: Exploring exchange 2000's exifs, Juli 2002.
[de.06a]
de.wikipedia.org: Data-Mining, Februar 2006.
[de.06b]
de.wikipedia.org: Microsoft Exchange Server, Februar 2006.
[DK02]
Dale Koetke, Patricia Anderson: Using microsoft exchange server
load simulator 2000, Dezember 2002.
[Fri]
Friedman, Mark B.: Windows nt page replacement policies.
[IHW05] Ian H. Witten, Eibe Frank:
Data Mining.
Morgan Kaufmann, 2
edition, 2005.
[Mar04]
Markiewicz,
Marcus:
Troubleshooting exchange server 2003 perfor-
mance, April 2004.
[MF02]
Mark Friedman, Odysseas Pentakalos: Windows 2000 performance
guide, Januar 2002.
[RP05]
Rob Powers, Moises Goldszmidt, Ira Cohen:
Short term perfor-
mance forecasting in enterprise systems, März 2005.
[Tea04]
Team, Exchange Documentation: Technisches Referenzhandbuch für
Exchange Server 2003, Juli 2004.
63