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:

  • ExBPA
    Hiermit können Sie nicht nur Fehler und Abweichungen vom Standard erkennen, sondern auch z.B. die Anzahl der Postfächer und Größe der Datenbanken ermitteln lassen.
  • MBReport und EPA
    Diese beiden Tools schauen in die Postfachinhalte hinein und erlauben Einblicke in die Nutzung durch die Anwender. MBReport kann noch viel tiefer Einblick nehmen, wenn ich das Skript kundenspezifisch anpasse. So kann man über die Anlagen und deren Größe und Alter auch das Potential einer Archivlösung ermitteln.
  • Nachrichtentracking mit MsgTrackSum
    Die Nachrichtenverfolgung hilft nicht nur dem Administrator beim Suchen von vermissten Mails, sondern erlaubt auch qualifizierte Aussagen über die Anzahl und Größe von Mails auf dem gleichen Server, innerhalb der Organisation und nach externen Systemen. Mit diesen Zahlen kann man dann sowohl die Bandbreite als auch die Anforderungen an Virenscanner etc. abschätzen. Wer die Daten konsolidiert kann sogar Aussagen über die Optionen einer Standortkonsolidierung machen, z.B. wenn in einem Standorte nur wenige Nachrichten "lokal" zugestellt werden.
# Beispiel eines Einzeilers um die Anzahl der Mails pro Tag und die Durchschnitsgroesse zu erhalten

Get-TransportServer `
| Get-MessageTrackingLog -ResultSize unlimited -start (get-date).adddays(-1) `
| where {($_.source -eq "Storedriver" -and $_.eventid -eq "deliver") `
     -or ($_.source -eq "SMTP"        -and $_.eventid -eq "SEND" -and $_.connectorid -ne "Intra-Organization SMTP Send Connector")} `
| measure-object -property totalbytes -sum -average -min -max
  • TransactionLogs und Eventlog mit Get224Log
    Bei jedem vollen Backup werden die Transaktionsprotokolle abgeschnitten und im Eventlog vermerkt (Event 224). Dies ist meist eine sehr einfache Möglichkeit, Daten über das Volumen der Änderungen auch über Wochen und Monate zurück zu erhalten. Nebenbei fallen Aussetzer im Backup selbst natürlich auf.
    Wenn wir die Analyse kurz vor dem nächsten Vollbackup starten, dann können wir auch anhand der zeitlichen Verteilung der LOG-Dateien die Belastung über den Tag ermitteln. Dies ist aber meist mit den Ergebnissen des Messagetracking in Einklang und weicht nur bei Migrationen und intensiver Arbeit über Ablagen in Kalendern und öffentlichen Ordnern ab.
  • IISLogsZugriff
    Hilft bei der Einschätzung der Belastung durch OWA/Activesync/RPCoverHTTP. Optional können noch IMAP4 und POP3-Logs hergenommen werden.

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 können 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.:

  • AD-Größe
  • Gesamtgröße aller Mailbox Datenbanken
  • Gesamtgröße der öffentliche Ordner Datenbanken
  • Größe der Einzeldatenbanken

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.

  • Get224Log
    Auswerten der Eventlogs 224 um das Volumen der abgeschnittenen Transaktionsprotokolle zu erhalten

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