Exchange Sizing Überlegungen

Ich erlebe immer wieder, dass jemand Exchange einfach einführt ohne vorher geplant zu haben oder Tagelang plant und letztlich das Sizing nur einige Minuten dauern müsste. Hier möchte ich mir einfachen Worten die Überlegungen für ein Exchange Sizing beschreiben.

Der Benutzer als Ausgangspunkt

Wer heute Server dimensioniert, hat vier Faktoren im Hinterkopf:

  • CPU
    Befehle müssen ja verarbeitet werden
  • RAM
    Hier liegen der Programmcode aber vor allem auch der Cache um wiederholte Anfragen
  • DISK
    Da liegen die Mails und warten darauf gelesen zu werden.
  • LAN
    Die Daten müssen ja zwischen den Servern und den Clients übertragen werden

Für alle Bereiche gilt aber, dass eigentlich nur eine "Veränderung" zu betrachten ist. Ob das Postfach eines Benutzers nun 10 Megabyte oder 10 Gigabyte groß ist, ist für die CPU; den RAM und die Disks eher sekundär, solange sich nichts bewegt. Ausgangspunkt für das Sizing ist immer der Anwender, das unbekannte Wesen. Wir müssen daher Informationen sammeln wie:

  • Anzahl/Umschlag
    Wie viele Mails sendet und empfängt der Anwender pro Tag?
  • Größe
    Wie groß sind diese Mails, die hier übertragen werden?
  • Wachstum
    Wie viele der Mails werden auch wieder gelöscht, bzw. dürfen entfernt werden oder werden in ein Archiv verschoben, um das Wachstum zu kontrollieren.
  • Zugriff
    Greift der Anwender mit Outlook im Cached Mode, Outlook Online, OWA oder gar per IMAP/POP darauf zu ?

Ich nehme zur Vereinfachung an, dass ein Anwender im Mittel pro Tag 200 Mails mit einer Größe von 75 Kilobyte pro Mail "bewegt". Die meisten Firmen schätzen insbesondere die Anzahl sehr viel geringer ein. Aber hier zählt "jede" Mail, d.h. auch eine Termineinladung und selbst Quittungen und Unzustellbarkeiten. Wer einen Exchange Server hat, sollte die eigene Anzahl und Größe ja einfach über das Messagetracking ermitteln.

IOPS und Größe

Allein mit der Information über die Anzahl und Größen der Mails können wir eine IOPS-Rate pro Postfach ermitteln. Wir nutzen dazu einfach den Exchange Calculator.

Exchange Server Role Requirements Calculator v8.5
http://aka.ms/exchangecalc
https://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8a61780

Auf der ersten Seiten werden die Daten direkt eingegeben:

Auf der zweiten Karteikarte sehen Sie dann die IOPS pro Mailbox:

Mit der Zahl alleine muss man natürlich vorsichtig sein, da auch andere Prozesse (IISLogs schreiben, Transportqueue aktualisieren, Replikation von Transactionlogs, Volltextindex, etc.) für weitere IOPS sorgen. Zudem steht hier ja noch nichts, die die Mailboxen in Datenbanken und Datenbanken auf die Disks verteilt verteilt werden. Der Exchange Sizer kann natürlich noch mehr, wenn Sie die anderen Kennzahlen noch mit hinterlegen. Es ist aber ein erster Anhaltspunkt.

Stillstand in Massen

Ich führe die IOPS-Berechnung hier nicht detaillierter auf aber nutzte diese Basiszahl mit meinem 5000 Beispielanwenders und komme so auf 5000x0,13 = 650 IOPS. Jetzt nehme ich eine ideale Festplatte mit 10ms Zugriffszeit (Random IO). Diese schafft alleine schon 100 IOPS  (1 Sek/10ms = 100). Ich muss also mehrere Festplatten verbauen. Hier kommt nun aber sowohl die Kapazität als auch die Redundanz zum Tragen.

Mit 5000 Benutzern, denen ich bis zu 10 GB Postfächer zugestehe, muss ich für die Datenbanken 50 TB vorsehen. Da kommt natürlich ein Zuschlag drauf, da neben der Datenbank noch der Volltextindex und die Transaktionsprotokolle ihren Platz brauchen. Für die weitere Erläuterung belasse ich es aber mal bei 50 TB mit 650 IOPS. Hierfür müssen wir nun ein Sizing und überlegen. Mehrere Optionen gibt es hier um die 50 TB und geforderten IOPS rechnerisch zu erreichen.

Disks RAID IOPS Kosten Anmerkung

10x5TB

RAID0

1000

$

Mit größeren Disks bräuchte man weniger aber 5x 10 TB Disks sind nicht nur teuer sondern erreichen die geforderten IOPS nicht.

25x2TB

RAID0

2500

$$

Die Disks sind pro TB natürlich teurer als 5TB und mehr Einbauplätze kosten auch Geld und Strom

20x5TB

RAID1

1000

$$

Wer mit RAID1 die Redundanz haben möchte, bezahlt mehr für Controller, Einbauplätzen und Disks

11x5TB

RAID5

275

$

Eine Disks + Controller mehr macht aus dem RAID0 ein RAID5. Kaum Mehrkosten aber die IOPS zerstören den Traum (1100 IOPS/4)

215x2TB

RAID5

650

$$$

Um mit einem RAID 5 überhaupt in die Region von 650 IOPS zu kommen, müsste man 2600 IOPS verbauen, also 26 Festplatten. Und wehe dann fällt eine aus und ein Rebuild kommt noch oben drauf. Erst mit 40 Disks erreicht man die 1000 IOPS des RAID0. Natürlich hat man dann 80 TB brutto verbaut, von denen Netto auch ein paar mehr TB nutzbar sind als beim ersten Modell mit 10x5TB

Die Rechnung ist sehr vereinfacht da bei vielen Disks auch noch Kosten für zusätzliche Einbauplätze (Chassis etc.) dazu kommen.

DAG statt RAID

Nun wird natürlich niemand einen Single Exchange Server mit einem RAID0 für die Datenbanken betreiben. Der Trick bei Exchange ist die Redundanz über eine DAG bereit zu stellen. Rechnen Sie doch selbst einfach mal durch. Natürlich sind zwei Server teurer als ein Server. Die Windows Lizenz und Exchange Lizenz kommt dazu und natürlich brauchen wir doppelte CPU und RAM. Schließlich soll ein Server im Notfall die komplette Last alleine tragen können.

Auf der anderen Seite können wie aber vielleicht das kleinere Gehäuse nutzen oder auf externe Festplattengehäuse verzichten, wenn weniger Festplatten pro Server eingebaut werden. Die Anzahl der Festplatten für die Datenbanken bleibt unverändert, wenn wir von einem RAID1 in einem Server auf ein RAID0 in zwei Servern mit Exchange DAG-Replikation wechseln.

Die Rechnung wird noch interessanter, wenn sie neben dem RAID1 auf einem Server noch das Backup dazu rechnen. Rechnen Sie auf jeden Fall auch mal eine DAG mit vier Servern (ohne Backup). Das hat noch einmal Auswirklungen auf ein "Reseeding/Rebuild", da dieses dann von einer passiven Instanz erfolgen kann, was natürlich auch IOPS auf Disks verlagert, die eh weniger zu tun haben.

Sind 96 GB Ram genug?

Wenn Sie den Microsoft Sizer anschauen, dann werden Sie erkennen, dass er maximal 96 GB Ram empfiehlt. Kann ein Windows Server und Exchange Server etwas nicht mehr? Viele hilft viel ist doch nicht nur in der KFZ-Tuning-Branche ein gern genutztes Zitat. Natürlich kann ein Exchange Server auch mit 128 GB oder 265 GB arbeiten. Aber rechnen Sie doch einfach mal nach.

Wenn 5.000 Benutzer auf einem Server jeden Tag 200 Mails a 75 Kilobyte senden oder empfangen, dann sind das 15 Megabyte/User oder 75GB/Tag. Selbst wenn Sie Speicher für die Exchange Dienste (Zugriff der Anwender per Outlook, OWA oder ActiveSync, Mailrouting etc.) abziehen, bleibt immer noch sehr viel RAM für Caching. In der Regel replizieren Anwender kurz nach dem Empfang die Elemente per Outlook Cached Mode schon in eine lokale OST-Datei oder per ActiveSync auf das Mobiltelefon und nutzen den Cache auf dem Server nicht mehr. Aber selbst wenn ein Client erst ein paar Stunden später "online" geht, ist die Wahrscheinlichkeit schon hoch, dass auch mit 96 GB Ram die Daten immer noch im Cache sind und keine IOPS generieren.

Wer aber mehr als 128 GB Ram in einem Server bereitstellen will, kommt damit quasi automatisch zu größeren Servermodellen mit mehr DIMM-Slots und teureren RAM-Modulen. Die Kosten steigen also stärker an ohne dass ein Vorteil zu sehen würde. Ehe Sie aber nun 50.000 User auf einem Server platzieren, ist es vielleicht besser mehrere kleinere Server nebeneinander zu stellen. Scale-Out statt Scale-Up ist das Schlagwort dazu. Viel mehr Benutzer bedeutet ja auch viel größere Datenmengen (Terabyte), die im Fehlerfall auch wieder zu replizieren sind. Investieren Sie das Geld lieber in mehrere Server und bauen sie eine DAG.

Wie geht es weiter?

Jedes Sizing ist eine individuelle Aufgabe aber folgt doch immer dem gleichen Pfad. Der Sinn dieser Seite ist ihre Gedanken für den Ansatz von Exchange 2013/2016 und DAGs mit mehreren Servern und RAID 0 zu öffnen. Lösen Sie sich von eingefahrenen Bahnen. Nicht jeder Server muss heute automatisch ein RAID für die Exchange Datenbanken haben. Ausgangspunkt ist aber die erwartete Belastung durch die Anwender. Diese sollten Sie nun erst einmal erfassen.

Weitere Links