Sizing Daten ermitteln

Auf dieser Seite werden Hilfsskripte zur Auswertung erwähnt. Aktuell muss ich dieses noch "alltagstauglich" machen (Dokumentation, Fehlerbehandlung etc.). Haben Sie daher noch etwas Geduld.

Um den nächsten Exchange Server zu dimensionieren benötigen Sie die Daten der aktuellen Umgebung und eine Einschätzung über das zukünftige Wachstum. Nun ist es aber so, dass die meisten Administratoren überhaupt nicht wissen, was ihr Exchange Server so treibt. Wenn ich sie heute nach folgenden Daten fragen würde, könnten Sie zumindest einen Schätzwert liefern ?. Wenn ja, dann schreiben Sie ihn einfach kurz auf:

Parameter Wert
Größe aller Mailboxen bzw. Datenbanken auf dem fraglichen Server  
Anzahl der Transaktionsprotokolle pro Tag, die vom Backup in der Nacht hoffentlich entfernt werden  
Anzahl der pro Tag gesendeten und empfangenen Mails  
Volumen (Größe) der pro Tag übertragenen Mails.
(Die meisten Administratoren vergessen hier gerne die Replikationsnachrichten für mehrere öffentlichen Ordner		  
Wachstum der letzten 2 Jahre
Ich weiß, die Frage ist sehr gemein. Eventuell finden Sie noch hinweise auf die Größe aus alten Protokollen der Datensicherung.		  

Und nun wollen Sie natürlich wissen, wie man an solche Daten gelangen kann, wenn es keine Aufzeichnungen gibt oder Sie nur wenig Zeit für die Ermittlung habe. Es gibt tatsächlich eine Menge Datenquellen, die Exchange an verschiedenen Stellen bereit stellt und von denen die meisten Administratoren gar nicht wissen, welche Informationen darin stecken. Hier die Kurzfassung:

Sie sehen also, dass es auch ohne Datenbanken mit Langzeitdaten einige Werkzeuge für die Analyse eines bestehenden Servers gibt. Schauen wir uns die Programme kurz im Detail an:

ExBPA

Ich hoffe, Sie kennen ExBPA. ExBPA analysiert aber nicht nur ihre Umgebung sondern über die erweiterten Berichte kann man sehr einfach auch die aktuellen Größen ermitteln, z.B.:

Hier ein Zusammenschnitt eines Berichts.

ExBPA Daten

Das geht allemal einfacher als mühsam durch alle Server zu laufen und die Daten manuell auszulesen. Oder wüssten Sie auf anhieb, wie viele Megabyte ihr Active Directory (NTDS-DIT) groß ist. ? Ab 800 MB sollte man den Einsatz von 64bit DCs erwägen.

MBREPORT, MBQuotareport und EPA

Wenn es an die Inhalte geht, dann sind MBQuotaReport, MBReport, und EPA geeignete Programme. EPA reicht für die meisten Anforderungen schon aus, während MBQuotareport eine schöne Übersicht über alle Postfächer auf Exchange 2003 Servern liefert. Für Exchange 2007 gibt es mit "GET-MailboxStatistics" ein entsprechendes Commandlet. MBReport erlaubt einen sehr tiefen Blick in die Postfachdaten samt Alter der Mails und Anlagen. So können auch die Auswirkungen von Archivprogrammen bewertet werden

Message Tracking

Eine sehr effektive Quelle ist das Messagetracking, womit man nicht nur den Verlauf einzelner Nachrichten nachverfolgen kann, sondern sowohl die Größe also auch Anzahl von Nachrichten pro Zeiteinheit erhält. Eine wichtige Maßzahl zur Dimensionierung von Journalarchiven, IO-Last der Transportserver, Transaktionsprotokolle, Virenscanner und Bandbreiten im LAN und WAN.

Messagetracking

Auch andere Tools zur Auswertung eines Message Tracking können natürlich für solche Analysen heran gezogen werden, z.B. MTRACK oder andere Reporttools

Transaktionsprotokolle des Backup (Eventlog)

Wenn es kaum Aufzeichnungen zum Backupvolumen gibt, dann eine Suche nach Eventlogeinträgen weiter helfen. Normalerweise protokolliert Exchange dabei den Erfolg eines Backups und die Namen der Protokolldateien, die abgeschnitten werden. Anwendungseventlog Quelle: ESE, ID:224:

Backup löscht transactionfiles

Ein kleines VBScript (Get224Log) kann diese Eventlogeinträge einsammeln und entsprechend als CSV-Datei für eine weitere Auswertung aufbereiten und in Excel dargestellt werden:

Auf dem Bild ist gut zu erkennen, dass viel mehr Transaktionsprotokolle an den Wochentagen zu löschen sind als an den Wochenenden. Die Transaktionsprotokolle sind im Vergleich zur Auswertung des Message Tracking aussagekräftiger im Bezug auf die Fluktuation von Daten in der Datenbank.

Aktuelle Transaktionsprotokolle

Zuletzt kann man natürlich noch die aktuellen Trackinglogs auswerten. Diese Auswertung ist natürlich nur kurz vor einem Backup sinnvoll, da dann noch alle Logs des Tages vorhanden sind und aufgrund des Zeitpunkts auch eine zeitliche Verteilung über den Tag ermittelt werden kann. Auch hier mache ich mir das Leben durch ein VBScript einfacher, welches ein angegebenes Verzeichnis nach LOG-Dateien durchsucht und deren "LastModified"-Date nach Stunden aufsummiert

Meist ist das Bild aber überall vergleichbar: Nachts ist kaum was los und mit dem Arbeitsbeginn steigt auch die Aktivität um in der Mittagspause wieder etwas abzuflauen und zum Abend hin wieder abzusinken. Wenn auf einem Server natürlich noch Mitarbeiter aus anderen Zeitzonen aktiv sind, dann verteilt sich die Last wieder über die Zeitabschnitte. Single item Backups und ein Backup als solches sind hier nicht sichtbar.

Für das eigentliche Sizing ist diese Auswertung weniger wichtig, da die Übersicht über die beim Backup gelöschten Protokolldateien über mehrere Tage hinweg einen Status liefert, aber die zeitliche Verteilung ist zumindest von Interesse.

IISLogs / POP3 /IMAP4

Leider protokolliert Exchange keine Zugriffe von Client per MAPI/RPC. Zugriffe über Internet Protokolle sind jedoch als Protokolldateien vorhanden und können ebenfalls für eine Volumenbelastung genutzt werden. Besonders die intensiveren Zugriffe per OWA und ActiveSync sind hier bei der Dimensionierung des CAS-Servers zu berücksichtigen. Mit den passenden Tools kann man hier auch die Nutzung nach Anwendern, Protokollen und Zeit entsprechend filtern.

Da es sich um "normale" IIS-Logs handelt, können diese auch mit handelsüblichen Tools und Freeware Lösungen (z.B.: Webalizer) ausgewertet werden:

Natürlich können Sie die Daten auch durch andere Tools auswerten.

Eventlog 9826 Event

Exchange protokolliert zwar jede Menge Infos im Eventlog, aber für ein "kleines Monitoring" ist der Event 9826 sehr interessant, welcher immer wieder erscheint:

Event Type: Information
Event Source: MSExchangeIS
Event Category: Performance
Event ID: 9826
Description:
Starting from 06.04.2010 20:34:27 service 'Exchange Web Services' has performed this activity on the server:
RPC Operations: 133924.
Database Pages Read: 318049 (of which 193793 pages preread).
Database Pages Updated: 30305 (of which 30052 pages reupdated).
Database Log Records Generated: 48166.
Database Log Records Bytes Generated: 1184518.
Time in User Mode: 51532 ms.
Time in Kernel Mode: 5750 ms.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Interessant ist der Event daher, da er die Aktivität für verschiedene Quellen angibt, welche leider als Text in der Beschreibung stehen. In der ersten Zeile steht die Quelle während die anderen Zeilen identisch aufgebaut sind.

Starting from 06.04.2010 22:27:53 service 'Exchange Content Indexing' has performed this activity on the server:
Starting from 06.04.2010 20:34:27 service 'Exchange Web Services' has performed this activity on the server:
Starting from 06.04.2010 22:37:55 service 'Exchange Mailbox Assistants' has performed this activity on the server:
Starting from 06.04.2010 21:14:57 service 'Exchange Transport' has performed this activity on the server:
Starting from 06.04.2010 16:00:37 service 'Exchange Availability Service' has performed this activity on the server:

Leider bleiben die Hauptverursacher, z.B.: die Client, ActiveSync, OWA, Outlook etc. hier leider außen vor, so dass eine genauere Analyse und Aufteilung der Zugriffe weiterhin nicht möglich ist. Aber es trotzdem eine interessante Option diese Daten z.B.: per Powershell zu extrahieren und über eine Zeitachse aufzuzeichnen. Denn gerade die Hintergrundprozesse werden oft übersehen, wenn es um die Frage geht, warum ein Server zu einer bestimmten Zeit Langsam oder auf hoher CPU-Last ist.

Weitere Links

Keywords:Sizing Tools