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 |
---|---|
Anzahl der Postfächer und anderer Empfänger Das geht per PowerShell mit Exchange 2007 und neuer recht einfach. Hier ein Beispiel. Für das Sizing interessieren nur UserMailboxen Get-Recipient -ResultSize unlimited | group RecipientTypeDetails -noelement Count Name ----- ---- 427 UserMailbox 19 MailUniversalDistribut... 2 DynamicDistributionGroup 2 MailNonUniversalGroup 4 MailContact 314 PublicFolder 1 DiscoveryMailbox 15 RoomMailbox 2 MailUser
|
|
Größe aller Mailboxen bzw. Datenbanken auf dem fraglichen Server Das geht per PowerShell mit Exchange 2007 und neuer recht einfach. Sie können die Daten durch Addition der Postfachgrößen oder der Datenbanken ermitteln. Die Werte werden immer etwas abweichen aber für das Sizing kommt es auch nicht auf das letzte Byte an. get-mailbox -resultsize unlimited ` | get-mailboxstatistics ` | %{write-host "." -nonewline; $_.TotalItemSize.value.tomb() } ` | measure-object -minimum -maximum -average -sum Count : 426 Average : 85,115002918856 Sum : 299624 Maximum : 42991 Minimum : 0 Property : Get-mailboxdatabase -status ` | %{$_.DatabaseSize - $_.AvailableNewMailboxSpace} ` | measure-object -minimum -maximum -average -sum Count : 15 Average : 215020675618,133 Sum : 3225310134272 Maximum : 473050742784 Minimum : 173497810944 Property : |
|
Anzahl der Transaktionsprotokolle pro Tag, die vom Backup in der Nacht hoffentlich entfernt werden |
|
Anzahl und Größen der pro Tag gesendeten und empfangenen Mails Dieser Wert ist wichtig da er die "Veränderungen" widerspiegelt, die ein Maß für die IOPS sind # Beispiel eines Einzeilers um die Anzahl der Mails pro Tag # und die Durchschnittsgroesse zu erhalten Get-TransportService ` | Get-MessageTrackingLog -ResultSize unlimited -start (get-date).addhours(-2) ` | 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 Count : 1628 Average : 257081,078025478 Sum : 17750917 Maximum : 1249727 Minimum : 194 Property : TotalBytes |
|
Wachstum der letzten 2 Jahre |
|
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.
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.
-
MsgTrackSum
Aufsummieren von Message Tracking Logs zur Analyse des Volumens -
WizBang Exchange 2007 Message Tracking PowerShell Gui Version 1
http://gsexdev.blogspot.com/2008/09/wizbang-exchange-2007-message-tracking.html
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:
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.
Zuerst sollten Sie im IIS aktivieren, dass er die übertragenen Datenmengen mit protokolliert
Im IISLog landet dann auch die Datenmenge und über die ClientIP-Adressen, Zeiträume, URLs etc. können Sie sehr gut die Nutzung durch Anwender über RPC/HTTP oder MAPI/HTTP auswerten.
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
-
IOPS - Input Output Operations
Eine wichtige Kennzahl bei der Dimensionierung von Servern - Get224Log
- MsgTrackSum
- End2End Mailbox
- Webalizer
- MBReport
- MBQuotaReport
- MTRACK
- Reporttools
- Forensik
-
Process Tracking Log tool für Exchange Server 2007
http://blogs.technet.com/b/exchange/archive/2008/02/07/448082.aspx -
WizBang Exchange 2007 Message Tracking PowerShell Gui Version 1
http://gsexdev.blogspot.com/2008/09/wizbang-exchange-2007-message-tracking.html