Exchange Sizing - Wie dimensioniere ich die Hardware ?

Seite 1/5

Diese Informationen repräsentieren nicht immer die aktuelle Hardware und Anforderungen. Sie sollten aber die Grundlagen und Faktoren für ihre eigene Abschätzung sehr wohl erkennen und verstehen können. Speziell bei größeren Installationen oder bei der Migration lohnt sich aber ein Fachgespräch oder auch eine Analyse der vorhandenen Server.

Immer wieder kommt die Frage:

Welche Hardware brauche ich für Exchange ?

Kurze Antwort: Es gibt keine allgemeingültige Aussage hierzu. Man muss schon das Nutzungsverhalten der Anwender können um basierend darauf ein passendes System zu entwickeln. Aber es gibt einige Grundwerte, die man können sollte. Im dem Text wird sowohl Exchange 5.5 als auch Exchange 2000 behandelt. Wenn ihr Server nun aufgebaut ist, dann sollten Sie die Funktion und die Leistungsfähigkeit testen. Siehe Exchange Leistungstest.

Exchange 2007 Mailbox Server Role Storage Requirements Calculator http://blogs.technet.com/b/exchange/archive/2007/01/15/432207.aspx

Achtung bei mittleren Firmen
Exchange 2010 hat veränderten Anforderungen an den Storage. Der Storage Kalkulator ist für große (5000 und mehr ) Umgebungen ausgelegt.

Kleines Rechenbeispiel

Ich versuche mal, ein paar Zahlen in Relation zu setzen, anhand derer Sie ein paar Werte für ein Exchange Sizing ermitteln können. Es gibt mit EPA übrigens ein sehr gutes Tool, um Kenzahlen aus einem Server auszulesen. Wichtige Parameter sind:

  • MaxDBSize
    Was ist die maximale Datenbankgröße, die Sie vernünftig sichern und innerhalb der gewünschten Zeit restaurieren können ?. Bedenken Sie, dass beim Einsatz von LCR oder CCR ein Restore oft nicht erforderlich ist und daher die Datei größer sein kann. Aber über 100/200 GB sollten Sie die Datenbank nicht dimensionieren.
  • MB pro Mailbox
    Ermitteln Sie den Durchschnittswert der Postfachgrößen. Sie können dies mit EPA tun, mit dem Exchange 2003 System Manager einfach die Postfachgrößen als CSV-Datei ausgeben und mit Excel aufaddieren oder die Größe der Datenbank ihres aktuellen Servers durch die Anzahl der Postfächer darin teilen.
    Addieren Sie dann noch das voraussichtliche Wachstum hinzu
  • Mail-Out/Sek, Mail-In/Sek, Mailsize
    Anhand dieser drei Werte können die den Nachrichtenumschlag ihres Servers abschätzen, diese Zahlen sind wichtig für die Dimensionierung der Transaktionsprotokolle und ein Hinweis auf die erwarteten I/Os pro Sekunde auf den Massenspeichern.
  • Kritischer Pfad: Disk-I/O
    Versuchen Sie von ihrem Lieferanten ein paar Kennzahlen für den Massenspeicher zu erhalten. Ohne diese Daten können Sie nur Raten, Hoffen oder ihren bisherigen Server müssen. Gute Hersteller veröffentlichen entsprechende Empfehlungen und Messergebnisse.
  • Kritischer Pfad: Backup/Recovery-Zeit
    Bestimmen Sie anhand ihrer aktuellen Backuplösung bzw. der zukünftigen Lösung die Restorezeit. Seit Exchange 2003 können Sie ja Problemlos eine Datensicherung als Recovery Storage Group auf den Server (Platz vorausgesetzt) restaurieren und die Zeit müssen.

Mit diesen Zahlen können Sie nun eine Größenordnung ermitteln. Wenn sie aber nun eine Rechenformel erwarten, dann muss ich sie enttäuschen. Das Exchange Team hat extra eine umfangreiche Excel-Tabelle (Exchange 2007 Mailbox Server Role Storage Requirements Calculator Spreadsheet http://msexchangeteam.com/files/12/attachments/entry438481.aspx) hierfür gestrickt. Wenn Sie aber "nur" einen Server für eine überschaubare Firma einrichten wollen, dann können Sie auch so einfach mal ein paar Abschätzungen vornehmen.

  • Anzahl der Datenbanken
    Aus der durchschnittlichen Mailboxgröße und der maximalen Datenbankgröße können Sie ermitteln, wie viele Postfächer sie pro Datenbank betreiben können. Anhand der bekannten Zahl der Postfächer wissen Sie nun, wie viele Datenbanken sie benötigen
  • Datenbank zu Protokolldatei = 4:1
    Als Faustregel kann man sagen, dass z.B.: vier Datenbanken auf einem RAID10-Stapel durch ein weiteres RAID10 für die Protokolldateien unterstützt werden.

In den meisten Fällen reicht das für kleine Firmen schon aus. Ein RAID für das Betriebssystem, auf dem auch die Protokolldateien mit landen und ein großes RAID für die Datenbanken ist für die meisten Single Server Installationen eine gute Basis.

Letzte MMB Benchmarks

Microsoft hat einen "Benchmark" für Exchange Server,  an dem sich natürlich nun die Hersteller gegenseitig hochschaukeln. Wer immer gerade Zeit und Lust hat, baut einen Server zusammen, der bezogen auf den Benchmark sehr gute Werte erreicht.


Quelle: primärGY BX620 S3 13500 MMB3 May 2006: occupies first two MMB3 positions
http://extranet.fujitsu-siemens.com/vil/pc/vil/primergy/performance/primergy_bx620s3_13500_mmb3_fdr.pdf

Natürlich ist ein Benchmark nicht mit einer produktiven Installation vergleichbar. Niemand würde z.B. auf einem FSC primärgy BX620 S3 Blade wirklich 13500 Benutzer fahren. Wenn Sie das White Paper dazu lesen, dann steht dort auch klar und deutlich drin, dass die Konfiguration ohne Virenschutz, Spamschutz, Backup o.ä. betrieben wurde.

Interessant ist aber schon die Konfiguration des Benchmark Systems:

  • System: primärGY Server BX620 S3 (Blade)
    CPU: zwei Intel Xeon 5160 Dual-Core 3.0 GHz und 4 MB SLC (Woodcrest)
    RAM: 4 GB Arbeitsspeicher
    Disk: 2x36 GB Festplatten für Betriebssystem und Active Directory
    Disk: 8!!!! FibreCAT CX500 mit insgesamt 570!!! Festplatten zu je 36 GB in RAID-0!!! Verbänden

Niemand wird einen Server mit 8 externen großen Speicherunits und 20 TERABYTE konfigurieren und ohne Redundanz (Raid0) betreiben. Ein Rennwagen ist aber auch nicht das passende Fahrzeug für den täglichen Berufsverkehr..

Wichtige Aussage:
Anscheinend braucht man sehr viele Festplatten, um die Performance zu maximieren. Im Umkehrschluss heißt das, dass die heutigen CPUs schon lange nicht mehr der Engpass sind, sondern das A und O sind die Massenspeicher und da gilt. Viele kleine Platten.
In der Realität wird man aber wohl auch hier Kompromisse schließen müssen

Durch die Partnerschaft mit Fujitsu-Siemens bin ich natürlich eher über neue Dokumente informiert. Aber auch HP, DELL und andere namhafte Hersteller veröffentlichen entsprechende Informationen.

Sonstige Sizer

Es gibt natürlich auch für SQL, Dateiserver etc. vergleichbare Ansätze:

Weitere Links