Exchange Sizing - 2007
Analog zu den Dimensionierungen im Jahr 2003 (MSXFAQ.DE - kleine Firma) und Jahr 2003 (großer Server) hat sich im Jahr 2007 mit Exchange 2007 einiges geändert, was bei dem Sizing berücksichtigt werden muss. Exchange 2007 nutzt nun Windows mit 64bit Architektur und kann weit mehr als die bislang bekannten 2 GB RAM ansprechen, die Datenbank besteht aus einer EDB-Datei mit 8k-Blöcken ohne STM-Ergänzung und die Transaktionsprotokolle sind nun 1 Megabyte groß.
Damit ist natürlich ein Administrator heute in der guten Situation, dass fast alle aktuelle Server für Exchange 2007 geeignet sind. Wer also weniger als 200 GB Datenbankgröße erwartet, wird daher fast jeden Server nehmen können. Aber Microsoft hat auch hier mit einer Excel-Datei eine Hilfe geschaffen, um einen Exchange Server korrekt zu dimensionieren. Der Sizer beschäftigt sich aber fast nur mit Festplatten für den Mailboxserver. Das können Sie durchaus als Wink verstehen, dass heute wie früher der Massenspeicher für die Performance eines großen und größeren Servers relevant ist und die Komponenten CPU und Netzwerkkarte eher untergeordnet sind bzw. einfach ohne große Berechnung festgelegt werden können. Einzig der Hauptspeicher ist die Komponenten, bei der eine kritische Grenze nicht unterschritten werden darf, da dann die Performance extrem einbricht, während ein übergroßer Hauptspeicher ein Kostenfaktor ist.
Manuelle Dimensionierung
Ich nutze mit Vorliebe die Microsoft Excel Formeln (http://blogs.technet.com/b/exchange/archive/2008/06/12/449007.aspx), um Kunden die Auswirkung von Änderungen zu zeigen. Aber ehe Sie nun blind einer Berechnungsformel vertrauen, sind schon etwas Sachverstand und belastbare Ausgangsdaten erforderlich. Der Sizer benötigt einige Angaben, um überhaupt erst ein Datenbankdesign erstellen zu können.
Zuerst sollten Sie ein paar Ausgangsdaten erfassen
- Anzahl der Benutzer
Das klingt einfach aber viele Administratoren können gar nicht direkt sagen, wie viele Benutzer - Absolute Größe der Datenbanken
Im einfachsten Fall addieren Sie einfach die aktuell vorhandenen EDB und STM-Datenbanken zusammen. Die ungenauigkeit durch Single Instance Store und leere Seiten sind meist zu vernachlässigen. Es wäre gut, wenn Sie für eine Wachstumsschätzung auch die Größen der vergangenen Monate z.B. aus Backupprotokollen ermitteln könnten. Vergessen Sie die Public Folder nicht. - Volumen der Veränderungen
Anhand der Anzahl und der Größe der Mails, die jeder Benutzer sendet und empfängt, resultiert das zu erwartende Volumen für die Transaktionsprotokolle als auch die zu erwartende IO-Belastung. Sie können diese Daten z.B. aus dem Messagetracking mit Excel oder anderen Tools ermitteln.. - Eckdaten für die Größe je Datenbank
Microsoft empfiehlt Datenbanken von max. 100 GB bzw. 200 GB beim Einsatz von CCR/LCR. Die Grenze erlaubt bei den meisten Firmen auch eine zügige Wiederherstellung im Fehlerfall, was beim Einsatz von CCR/LCR seltener der Fall sein dürfte. Sie müssen aber selbst ermitteln, bis zu welcher Größe Sie sich "wohl" fühlen und welche SLAs ihnen im Desasterfall vorgegeben wurden.
Mit diesen Daten können wir schon einmal eine große Planung angehen:
Ausgangssituation:
|
Ergibt:
|
Bewegung:
|
Ergibt:
|
Wenn Sie nun noch etwas "Platz" für das erwartete Wachstum, für die eventuell gewünschte Recovery Storage Group und Sicherheit addieren, dann haben sie schon mal die erforderliche Kapazität und die IO-Last des müssenspeichers. Jeder ordentliche Händler sollte ihnen damit eine passende Hardware anbieten können. RAID5 ist kostengünstig aber nicht schnell. Überlegen Sie, ob nicht mehrere größere Festplatten als RAID1 oder RAID10 unter Strich effektiver sind. Auch auf die Trennung von Datenbank und Transaktionsprotokollen wird oft aus Kostengründen leider verzichtet, obwohl dies Performance und Sicherheit bringt.
Da heute jeder Server schon ein oder mehrere Netzwerkkarten hat, sind Sie hier fast immer auf der richtigen Seite.
Dann bleibt noch die Ausstattung mit Hauptspeicher und CPU. Wenn Sie nicht gerade als Hoster tausende von Benutzern auf einem Server betreiben, dann können Sie von 5- 10 Megabyte pro aktivem Benutzer für Caching ausgehen. Ein normaler Mittelstandsserver für 50-100 Personen kommt genau genommen mit 1 GB für den Store-Cache aus. Mehr Postfächer eben mehr. Aber sie sollten zumindest noch ein paar GB für das Betriebssystem, den Virenscanner, das Backup und eventuell noch andere zusätzlich installierte Komponenten. Ich würde heute (Sommer 2008) keine Server mit weniger als 4-8 GB Ram mehr installieren und es sollte noch eine Ausbaureserve vorhanden sein.
Erfahrung und und das Risiko der Verallgemeinerung
Nicht für jeden ist der Exchange Sizer und die Betrachtung der IOs
wirklich wichtig. Gerade Server bis zu vielleicht 250 Postfächern kann
heutige Hardware ohne viel Planung betreiben. Auch wenn der Absatz hier
locker geschrieben ist, ist eine Serverdimensionierung ein kritischer
Punkt, da Fehlentscheidungen zusätzliche Kosten und Zeitverzug bedeuten.
Lassen Sie sich von ihrem Dienstleister beraten.
Planung mit dem Excel Sheet
Die manuelle Dimensionierung kann bei entsprechender Erfahrung zu dem "passenden" Server führen. Bei größeren Umgebungen oder auch einfach nur zur Validierung bietet sich die Microsoft Kalkulationshilfe in Form einer Excel-Datei an
- Exchange 2007 Mailbox Server Role Storage Requirements Calculator
http://blogs.technet.com/b/exchange/archive/2007/07/05/445802.aspx
http://blogs.technet.com/b/exchange/archive/2007/01/15/432207.aspx
http://msexchangeteam.com/files/12/attachments/entry438481.aspx
Auf der ersten Seite sollten Sie versuchen, ihre Umgebung passend zu beschreiben. Dazu können Sie drei Gruppen von Benutzern mit deren Last vorgeben. Die meisten Firmen haben leider keine aussagekräftigen Daten ihrer Exchange Benutzer, so dass eine Gruppe mit Schätzwerten meist genügen muss. Die Eckdaten zur Datenbankgröße, die Art des Servers (CCR, Single, LCR etc.) und Angaben zum Backup machen die Eingaben schon fast perfekt.
Anhand der Anzahl der Mails, deren Größe, die Anzahl der Mailbox Moves und die Benutzeranzahl ermittelt die Excel Formel zum einen die Größe der Datenbanken aber auch deren Veränderungen , was direkt in die zu erwartende Größe der Transaktionsprotokolle und vor allem der IO-Belastung eingeht.
Excel versucht dann die Datenbanken entsprechend der Größengrenzen und IO/s auf mehrere Speichergruppen zu verteilen und entsprechende Partitionen für die Protokolldateien vorzusehen.
Weitere Links
- http://blogs.technet.com/b/exchange/archive/2008/06/12/449007.aspx
- Planning Storage Configurations
http://technet.microsoft.com/en-us/library/bb124518.aspx - Planning Memory Configurations
http://technet.microsoft.com/en-us/library/bb738124.aspx - Understanding Exchange Server 2007 I/O improvements from 64 bit
http://blogs.technet.com/b/exchange/archive/2006/09/08/428860.aspx - Windows Speichergrenzwerte
http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_limits - SQL Grenzen
http://technet.microsoft.com/en-us/library/ms143685.aspx - Exchange Server 2003 Best Practices für mehrere Architekturen
http://technet.microsoft.com/de-de/library/bb124875.aspx