Sizing 2016

Mit jeder Version stellen Kunden und Interessenten immer wieder die Frage, wie man einen Exchange Server denn dimensionieren soll. Und es hat sich seit Jahren nicht viel daran geändert, das Microsoft seine Software an die geänderten Anforderungen anpasst, z.B. weniger IOPS, bessere Nutzung von RAM und CPUs, und die Anwender durch ihr verändertes Verhalten die Gewinne gleich wieder aufbrauchen, so dass aktuelle schnellere Server gerade wieder die Leistung bereit stellen können, die erforderlich ist. Der "Preis pro Postfach" scheint mir über die letzten Jahre immer gleich gebliebene zu sein

IST-Aufnahme

Wie in den vergangenen Jahren gibt es von Microsoft natürlich wieder ein Excel-Chart zum dimensionieren von Exchange Servern. Ehe Sie aber diese große Keule rausholen, müssen Sie erst einmal wieder ihre Hausaufgaben machen. Es ist immer wieder erschreckend, wie viele Firmen und Administratoren heute schon Exchange betreiben aber nicht mal die essentiellen Kennzahlen haben. Und die sollten Sie schon ermitteln, z.B.

Kennzahl Ermittlung Beispiel Ergebnis

Anzahl der Postfächer

Seit Exchange 2007 ist das per Powershell sehr einfach möglich.

(get-mailbox -resultsize unlimited).count

Wer noch Exchange 2003 hat, kann über Active Directory Benutzer und Computer einfach nach Postfächern suchen und die Anzahl ablesen

1000

 

Größe der Datenbanken

Ich halte mich nicht sonderlich mit "White-Space" oder "Deleted Objects" auf, wenn dieser Overhead wird beim nächsten Server sicher auch nicht anders sein, wenn Sie nicht in großem Stiele über Archiv und Retention Policies nachdenken. Ich zähle einfach die Summe der EDB-Dateien per Powershell oder stumpf über den Windows Explorer. Bei Exchange 2007 und höher sollten sie Replikate durch CCR, SCR, DAG natürlich nur einmal zählen. Per Powershell ist auch das recht einfach:

(get-mailboxdatabase -status) | measure-object DatabaseSize -sum

 

 

Größe einer Mailbox

Ausgehend von der Größe aller Datenbanken und der Anzahl der Postfächer können Sie nun die durchschnittliche Größe eines Postfachs errechnen: Einfach die Summer aller Datenbanken durch die Anzahl der Postfächer teilen.

 

 

Wachstumsaussichten

Nun kommt der Blick in die Glaskugel. Versuchen Sie zu erahnen, wohin es in den nächsten paar Jahren gehen könnte, denn in diesem Rahmen planen sie die Kapazität ihres nächsten Servers.

 

 

Mailumschlag

Am wichtigsten sind aber die Änderungen, da diese ein Maß für die Disk-IO-Leistung und CPU-Leistung sind. "Ruhende" Daten sind deutlich weniger relevant hier. Also gilt es zu ermitteln. wie viele Mails ein Anwender durchschnittlich sendet und empfängt und wie große diese Mails sind. Die primäre Quelle hierzu ist das Messagetracking. Da im Messagetracking aber ganz viele Events sind, muss man schon die relevanten Einträge filtern. Store/Submit und Store/Deliver sind hier eine Möglichkeit. Wer Exchange als SMTP-Relay verwendet, muss noch mal genauer nachschauen.

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

Wer etwas mehr Zeit hat, sollte natürlich mehr als nur einen Tag auswerten.

  • PRTG:ExTracking
    Statistiken mit PRTG sammeln. Wer mag kann dieses Skript auch anpassen, um einen längeren Zeitpunkt auszuwerten.

 

 

Es gibt noch einige Zusatzprodukte, die natürlich in die Kalkulation mit einfließen müssen. Wer z.B. Blackberry-Server, ArchivServer oder auch Index-Tools auf dem Client einsetzt, muss sich den Einfluss auf den Server überlegen oder ermitteln. Das ist gar nicht immer einfach, denn die Auswirkungen kann durch „geschickt Programmierung“ deutlich reduziert werden. Wenn z.B. ein ClientIndextool den Offline Mode richtig nutzt, dann sieht der Server davon nicht mehr viel. Sollte der Client tatsächlich „online“ lesen, dann kostet es Bandbreite aber wenig IOPS, da primär gelesen wird und die Mail vermutlich immer noch im Cache des Servers ist (genug RAM vorausgesetzt). Früher mag das anders gewesen sein. Da hatte Exchange 2003 als 32bit Applikation aber auch mit der 2/3 GB Schranke zu kämpfen. Selbst wenn heute 1000 Mitarbeiter im Mittel 100 Mails/Postfach a 100kByte senden und empfangen, ist das eine Änderungsdate von 10GB. die ein Server quasi immer noch im Cache halten könnte, wenn nicht andere Dienste auch noch etwas Speicher brauchen. Wie genau aber eine Anwendung den Server belastet, kann ihnen nur der Hersteller sagen.

Es ist übrigens keine schlechte Ideen, wenn Sie ihren aktuellen Server untersuchen. Der hat ja in der Regel eine bekannte Last und über Perfmon können Sie z.B. die IOPS heute schon ablesen. Wenn Sie dann die aktuellen Daten in den damaligen Exchange Sizer einstellen, können Sie ja in etwa prüfen, ob die Zahlen stimmen

Excel Sizer

Das von Microsoft als XLSM-Datei bereitgestellte Werkzeug ist durchaus nützlich für die Dimensionierung von größeren Servern und Umgebungen. Allerdings sollten Sie ihren gesunden Menschenverstand nicht abschalten- Je kleiner eine Umgebung ist, desto eher verzerren sich die Werte oder führen zu schwer umsetzbaren Ergebnissen. Der Sizer berücksichtigt nämlich nur die Exchange Komponenten. Zusatzprodukte wie Monitoring, Antivirus etc. müssen Sie schon alleine dazu rechnen. Wenn Sie dann einen Server für 100 Postfächern a 10 GB planen, dann können sie mit 2x1TB RAID problemlos hinkommen aber der ermittelte Hauptspeicher wird sicher zu gering sein.

Umgekehrt wird die Aktivierung einer "3rd Party Index-Software" die Rate für "DB Read IOPS" sehr stark ansteigen lassen:

So eine Angabe kann ein Sizing sprengen und es gibt durchaus noch andere Werte, die größere Auswirkungen haben, als sie auf den ersten Blick erwarten. Daher werde ich hier den Excel-Sizer nicht weiter beschreiben.

Wenn ihre Umgebung "Groß genug" ist, dass eine Dimensionierung mit dem Sizer sinnvoll ist, dann geht mehr Zeit in die Ermittlung der Eingangsdaten drauf als auf die reine Eingabe im Sizer. Wenn ihre Umgebung aber "kleiner" ist, dann könnten ein paar Muster-Systeme unterm Strich besser sein.

Sie sollten vor allem Wert auf Stabilität und ausgereifte Komponenten legen. Natürlich gibt es heute schon RAID-Controller, die mit SSDs als Cache auch größere Datenmengen schnell aufnehmen können. Aber wenn ein RAID-Controller schon 4 GB RAM als Cache hat und der oben beschriebene Server (1000 User, 100 Mails a 100k) gerade mal 10 GB pro Tag an neuen Mails schreibt, dann bringt sie eine 500 GB Enterprise-SSD weiter aber zu welchem Preis?

Eckwerte für ein Sizing

So stellen verschiedene Hersteller entsprechende Mustersysteme bereit. Der erste Hersteller ist natürlich Microsoft, der gar keine klaren "Sizing-Vorgaben" wie früher mehr macht, sondern nur noch von einer "Preferred Architecture" (https://aka.ms/preferred) spricht. Es gehört nicht viel Phantasie dazu, in diesen Server genau die Kisten zu sehen, die Microsoft in der Cloud betreibt und einfach quasi in 1000er Stückzahlen pro Monat nachsteckt. Dabei sind die Eckpunkte für das Microsoft Sizing schnell aufgezählt:

  • RAM: maximal 192 GB Ram (Nur Ex2016) (früher 96GB)
    Angeblich kann Exchange viel mehr nicht mehr effektiv nutzen. Ein Grund dürfte aber auch sein, dass mehr Speicher einfach andere teurere Motherboards erforderlich macht, und damit einfach die Kosten/Nutzen-Rechnung schlechter wird.
  • CPU: zwei Sockets, Maximum 24 CPU-Cores, kein Hyperthreading
    Der Sizer liefert nur "Megacycles" und überlässt es ihnen über die SpecINT2006-Seite ihren geplanten Prozessor und die Anzahl der Codes zu finden. Genau das ist aber das richtige Herangehen, denn allein die Taktrate in GHz ist kein guter Indikator für die Leistung eines Prozessors.
  • DAG und JBOD
    Microsoft und viele größere Umgebungen arbeiten gerne mit DAGs und replizieren die Datenbanken auf zwei oder mehr Server. Wenn eine Datenbank aber schon mittels Exchange auf mehrere Disks kopiert wird, dann muss die Frage erlaubt sein, ob eine lokale Redundanz noch erforderlich ist. Wer allerdings nicht mit 4 Servern starten kann, wird vieleicht eine DAG mit zwei Servern oder sogar einen Single-Server nutzen und hier natürlich ein RAID-System als Unterbau nutzen. In der Regel geht es da ja dann auch nicht gleich um Peta-Bytes. Ein Controller kann aber gerne mit einem Wirte-Cache (Battery Backup) beschleunigt sein. Die "Preferred Architecture" geht von 12 oder mehr großen SAS-Festplatten aus.
  • Multi-Role Server
    Früher wurden gerne "Postfachserver" und "CAS/HUB"-Server auf verschiedenen Systemen aufgebaut und "passend" konfiguriert. Ein Postfachserver bekam viele große Disks und viel RAM, während ein Transport Server z.B. mit SSDs für die Queue-Datenbank optimiert werden konnte. Exchange 2016 Teile aber Aufgaben nicht mehr auf, wie Exchange 2013 dies gemacht hat (Siehe MOMT). Gerade kleine Firmen sind mit einer DAG mit Multirole besser dran als mit nach Funktionen getrennten Servern.

Allgemein sollten sie als Firma als auch als Dienstleister natürlich schauen, ob nicht doch Office 365 eine interessante Option ist.

Beispiele

Es macht nur bedingt Sinn, eine Menge an Beispielen zu liefern, wenn es zu viele Variablen auf der Eingangsseite gibt. Insofern ist jedes Beispiel immer auch eine Beschränkung auf eine Vorauswahl. Bei Microsoft gibt es einige Aussagen zu Exchange 2013, die näherungsweise auch für Exchange 2016 genutzt werden können.

Ich würde erst einmal die Augen offen halten, welche Hersteller in ihren "Case Studies" mit Musterkonfigurationen rausrücken. Es wird sicher noch einige Monate dauern, bis ich verschiedene Exchange 2016 Installationen auch bewerten kann. Ich werde diese dann hier nach und nach addieren. Sie können mir gerne ihre Installationen auch anonym mitteilen:

  • Benutzer
    Die Anzahl der Benutzer ist ein erster Indikator für die Größe
  • Postfachgröße
    Beschreibt die durchschnittliche Postfachgröße und ermittelt sich aus der Summe der Datenbanken / Anzahl der Benutzer
  • Mail-I/O
    Beschreibt, wie viele Mails je Anwender pro Tag im Mittel gesendet und empfangen werden und wie groß diese sind
  • Serveranzahl
    Ich würde erst mal keine Server nach Rollen unterscheiden und davon ausgehen, dass alle Server identisch sind. Dann ist hier die Anzahl interessant und natürlich wie viele Datenbankenkopien genutzt werden.
  • CPU
    Wer den Sizer nutzt, kann hier gerne die Megacycles mitteilen. Interessanter ist aber die CPUs pro Server und der Speicher pro Server
  • Disk
    Ein par Daten zur Anzahl der Disks und deren Organisation hilft sicher weiter
#Benutzer Postfach Mail-I/O Serveranzahl CPU Disk

100

5GB

100x100kB

1x SingleServer

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ich hoffe bei Gelegenheit ein paar Exchange 2016 Installationen hier aufführen zu dürfen.

Weitere Links