Exchange Sizing 2010

Auch wenn ich hier etwas detaillierter auf die Aspekte eines Exchange Server Sizing eingehe, so sollten Sie immer überlegen, wie groß ihre Umgebung ist. Ein aktueller Server mit 16 GB Ram sollte auch mit 500 Postfächern nicht wirklich ein Problem haben. Sie müssen also vielleicht nicht jede Nuance ermitteln und ausrechnen. Es gibt von Microsoft "Exchange Tested Solutions", die ich gleich am Anfang verlinkt habe. Anders sieht es natürlich aus, wenn Sie 1.000, 5.000, 10.000 oder mehr Postfächer mit großen Datenmengen und hohen Mailtransferlasten planen. Da lohnt es sich dann schon, ein paar Stunden die Quellen genauer zu erheben, und ein Sizing zu erstellen. Es geht da ja schon um viel mehr Geld und Zeit.
Wenn ein kleiner Server aber nach 1-2 Jahren "zu klein" ist, dann ist es oft einfacher und billiger dann den Server zu tauschen als schon Monate im Voraus für alle Eventualitäten zu planen.
Sie dürfen natürlich trotzdem neugierig sein, welche Bedeutung welche Faktoren haben und was hinter den verschiedenen Werkzeugen für Formeln ablaufen.

Mit Exchange 2010 haben sich die Sizing-Grundlagen erneut geändert. Zwar ist Exchange 2010 wie schon 2007 eine echte 64bit Anwendung und kann damit mit großen Speichermengen (auch 64GB) umgehen und dabei die Festplatten durch den Cache entlasten. Zudem gibt es immer mehr Windows 64bit Domain-Controller die auch in größeren Umgebungen weiterhin alles im Hauptspeicher halten können. Aber wenn Sie mal realistisch eine Exchange Umgebung anschauen, dann ist das doch wieder mehr eine Sache für "ganz große" Firmen. Denn selbst ein 32bit DC kann problemlos 500 MB Ram für das Caching des AD bereit stellen und wenn ein Benutzer selbst mit Zertifikaten und Bild im Extremfall vielleicht 100k belegen würde, passen immer noch 5000 Benutzer in ein solches Active Directory. Selbst wenn Sie noch ein paar MB für Verteiler, Gruppen, Computerkonten und andere AD-Objekte ansetzen, sind es immer deutlich mehr als Benutzer. Schauen Sie doch einfach mal, wie groß ihre NTDS.DIT ist oder werden sie mit DSASTAT ihr Active Directory einmal aus.

Aber was nimmt man denn nun als "Exchange Server" her ?. Es gibt so viele unterschiedliche Hinweise, Excel-Tabellen, Sizer von HP, DELL und anderen Firmen und noch mehr Blog-Einträge die sich letztlich bis auf die Tiefen der RAIDs herunter begeben. Das ist in den meisten Fällen überzogen, zumindest wenn Sie sich mit einem Exchange Server für eine kleine oder mittlere Firma beschäftigen. Großunternehmen mit vielen Server, Sites und Cluster oder SAN/iSCSI sollten schon ein paar Minuten mehr aufwenden oder sich ihr Konzept vielleicht sogar testieren lassen. Vielleicht finden Sie sich aber auch in einer der drei "Samples" wieder und ersparen sich jede weitere Analyse

Gerade das kleine Muster von 500 Mailboxen auf einem 2-Server System mit Hyper-V könnte für viele MSXFAQ-Leser sehr aufschlussreich sein.

Diese Samples sind aber auch ein guter Ausgangspunkt für eine eigene Planung. Wer die drei Dokumente nebeneinander legt, wird viele Übereinstimmungen erkennen und dass nur ein paar Kennzahlen und die Hersteller sich verändern. Und darum geht es:

Diese Kurzeinweisung geht nicht auf mehrere Server, Datenreplikation (DAG), WAN-Anbindungen, Snapshots etc. ein, sondern soll ihnen helfen ihren eigenen "Single Server" zu dimensionieren. Diese Zahlen sind aber die Basis um später auch größere Umgebungen zu entwerfen.

Zu ermittelnde Werte

Wer einen Exchange Server plant den interessieren folgende Werte:

  • Festplattenkapazität
    Schließlich müssen die Mails und andere Inhalte ja irgendwo "liegen
  • Festplatten Performance
    Hierfür sind weniger die "Bestandsdaten" sondern eher die Veränderungen pro Zeiteinheit erforderlich
  • CPU
    Auch hierfür zählen eher die Zugriffe der Anwender und weniger die Größe der Postfächer
  • Hauptspeicher
    Neben einem Basisbereich für Windows und Exchange Dienste ist die Bereitstellung von Speicher als Cache für die Leistung essentiell.

Ausgangsdaten

Interessanterweise sind die zur Bestimmung relevante Fakturen nur ganz wenige Quelldaten erforderlich

Es ist für mich immer wieder erschreckend und ein Rätsel, wie wenige Kunde diese Zahlen können oder ermitteln. Fahren Sie etwa ein Auto ohne auf Kühlwassertemperatur, Tankanzeige, Kilometerstand, Inspektionsintervalle etc. zu achten ?. Diese wenigen Kennzahlen sollten Sie vielleicht einmal pro Monat ermitteln um frühzeitig eingreifen zu können.

Faktor Beschreibung Ermittlung Ihr Wert

Anzahl an Mailboxen

Auch wenn die Anzahl selbst nicht wirklich relevant ist, ist es eine Zahl, die immer wieder zum Einsatz kommt, wenn man mit "Belastung/User" arbeitet und die Zahlen dann auf einen Gesamtwert hochrechnen muss

Eine Suche im Active Directory nach Benutzern mit Postfach oder ein "(get-mailbox).count" reichen hier schon

mm Postfächer

Mail/Tag
KB/Mail

Dies ist mit Abstand die wichtigste Zahl für ein Sizing, weil dies echte "Last" für die Übertragung, Abspeicherung, Replikation, Zugriff der User, Virenscan, Whitespace, Cache, Logfiles bedeutet.

Manchmal unterscheiden Firmen noch "Profile", d.h. Werte wie
Userprofil1 = 20 Mail/Tag a 75kb
Userprofil1 = 50 Mail/Tag a 75kb
Userprofil1 = 100 Mail/Tag a 75kb

Die Trennung nach Profilen ist hilfreich, wenn Sie "neu" Planen und die Tätigkeiten der Benutzer kenn. für ein Sizing ist die Trennung nur wichtig, wenn Sie diese Benutzer auch in verschiedene Datenbanken/Standorte verteilen. Ansonsten reicht auch einfach der Mittelwert über alle Benutzer

Auswertung des Message Tracking

xx Mails/Tag a yy kb

Postfachgrößen

Diese Zahlen bestimmen die erforderliche (netto) Gesamtkapazität, die natürlich durch Replikation, Raid etc.

Aktuelle Größe der EDB/STM-Dateien aufaddieren oder Postfachgrößen per MMC ermitteln.

Quota in GB

Dumpsterzeit

Dieser Wert ist erforderlich, auch wenn er in der Regel nur wenig Einfluss hat. Er beschreibt wie lange "gelöschte Objekte" vorgehalten werden

 

Dumpster Tage, z.B. 14

Das sind zumindest die ersten großen Zahlen, die Sie für eine Dimensionierung ermitteln sollten.

Berechnung der Postfachgröße

Fangen wir erst mal an mit der Berechnung des Datenbankplatzbedarfs Dazu kommen drei Werte:

Wert Beschreibung Formel

Quotagröße

Dies ist die Größe, die sie administrativ für das Postfach zulassen.

 

Whitespace

Selbst wenn der Benutzer aber sein Postfach voll hat, gibt es "Änderungen ", z.B. weil Termine verschoben werden, oder der User einfach eine Mail löscht um eine neue zu Empfangen.

Anzahl der Mails pro Tag * Mailgröße / Quota

Dumpster

Nun wissen Sie, dass gelöschte Mails nicht sofort "weg" sind. Abhängig von der "Haltezeit" benötigen diese auch noch Platz.

Dumpstertage * Whitespace

Die effektive Postfachgröße errechnet sich dann aus der Formel

Wobei Sie hier natürlich schon sehen, dass es sich dabei um die "Vollauslastung" handelt, also den "Worst Case" wenn alle Mailboxen bis an ihre Grenze betrieben werden. Das stimmt so natürlich nur bedingt. Auch wenn alle Mitarbeiter die gleiche Grenze haben, ist der Füllgrad natürlich sehr wichtig. Leider kann man den halt nicht genau vorhersagen und wenn Sie eine Funktion "garantieren", dann muss der Platz auch da sein. Wer aber sein System überwacht und flexibel Storage addieren kann (z.B. SAN, iSCSI etc.) kann auch mit dem Füllgrad arbeiten und den Quota-Grenzwert eher als "Schutz" gegen missbrauch und plötzliches Wachstum ansehen.

Berechnung der Festplattenkapazität für die Datenbank

Die erforderliche Nettokapazität errechnet sich nun nicht einfach nach der Anzahl der Postfächer multipliziert mit der Größe. Dann hätten Sie nämlich Logdateien, Volltextindex und das Wachstum etc. vergessen

Diese Zahl müssen Sie natürlich mit der Anzahl der Kopien in der DAG multiplizieren und den Anteil des Parity des RAID-Level dazu schlagen, damit sie die Brutto-Kapazität für die Datenbankdisk haben.

Berechnung der Festplattenkapazität für die Logfiles

Bleiben noch die Berechnungen für die Transaktionsprotokolle. Mittlerweile werden diese Logdateien nicht mehr zwingend auf eigenen LUNs abgelegt. DAs war früher vor dem Einsatz der DAG ganz nützlich um, nach einem Festplattendefekt den Datenverlust zu minimieren. Würden Log und Datenbank auf der gleichen Disk liegen und diese ausfallen, dann wäre nur ein Restore vom letzten Backup (meist den Abend zuvor) möglich. Mit getrennten Pools ist die Wahrscheinlichkeit höher, dass nur ein Bereich verloren ist, d.h. man hat entweder die aktuelle Datenbank (ohne Logfiles) oder die Logfiles und kann ein Rollforward fahren. Diese Trennung ist natürlich nicht mehr erforderlich, wenn die Datenbestände mit einer DAG repliziert werden.

Direkt maßgeblich für die Menge der Logdateien sind die Änderungen , die Anwender an ihrer Mailbox vornehmen. Der Großteil generiert sich auf den Mails, die der Anwender sendet und empfängt. Daher ist das Nachrichtentracking des alten Servers hier sehr interessant.

  • MsgTrackSum - Anzahl und Größe der übertragenen Mails extrahieren

Nur ein wenigen Fällen sind sonstige Änderungen , z.B. Pflege von Terminen und Kontakten, signifikant, die nicht im Messagetracking repräsentiert sind. Hier kann eine Auswertung der Logs in der Vergangenheit nützlich sein, z.B. anhand früherer Datensicherungen oder des Eventlogs.

  • Get224Log - Historische Analyse der Logdateien in der Vergangenheit

Zwei Faktoren wirken noch auf den Platzbedarf ein, die für die Größenabschätzung relevant sind:

  • Backup
    Transaktionsprotokolle können durch eine inkrementelle oder Vollsicherung abgeschnitten werden. Wer also alle 4h ein inkrementelles Backup macht, wird nie die Logs eines Tages komplett vorhalten müssen, es sei denn das Backup hat einen "Ausfall". Auch das muss berücksichtigt werden.
  • Circular Logging
    Wer keine inkrementellen Backups braucht und die Datenbank z.B.: per DAG auf eine "ausreichende Anzahl" (was immer individuell festzulegen ist) Server repliziert, kann die Logfiles sogar per "Circular Logging" sogar sehr klein halten.

Betrachten Sie dann einmal das Volumen, welches sie nun für ihren Server pro Zeiteinheit erwarten und wie viel "Durchsatz" Sie auf ihrem Server erwarten. Nehmen wir mal an, ihre Datenbank produziert 60 GB Logfiles/Tag und wir nehmen weiter an, dass zwischen 08:00 und 18:00 die Hauptarbeitszeit ist, dann sprechen wir von 10h mit 60GB oder 6 GB/Stunde oder durchschnittliche 100MB/Minute.

Das gibt pro Sekunde eine lächerliche Durchsatzrate 1,6 Megabyte/Sekunde.

Wie teuer und schnell müssen die Disks nun sein, um diese Last aufnehmen zu können ?. Wobei RAID-Controller mit Batteriecache auch Spitzen abmildern und damit die "Latenzzeit" reduzieren. Lassen wir die Kirche im Dorf: Ein "1 fach DVD-Brenner" schafft schon 4,7 GB/h. Selbst USB 2.0 Fullspeed mit 1,5MByte/Sek ist da schon nahe dran. Moderne Festplatten sollten also gar kein Problem damit haben. Dedizierte Disks für Transaktionsprotokolle sind daher allenfalls mit der Datentrennung für einen Desasterfall ohne DAG zu rechtfertigen.

Berechnung der Festplatten Leistung in IOPS

Eine wichtige Größe ist die "Belastung" der Festplatten mit IOPS. IOPS ermitteln sich alleine aus den "Änderungen " in der Datenbank und nicht an der Größe. Und kritisch für die meisten Systeme sind hier sowieso die "Random-Write"-Zugriffe, die bei Exchange meist 40% ausmachen und so manchen "schnellen RAID-Controller zur Schnecke werden lassen. Besonders wenn Exchange 64k Blöcke schreibt und das Raid ein vielfaches davon als "Stripesize" hat. Dann muss der Raid Controller nur partiell geänderte Stripes komplett zurück schreiben. Aber das ist eine andere Geschichte.

Da die meisten Sizer erst mal die IOPS pro Mailbox ermitteln kann man die Gesamt IOPS wie folgt errechnen

Gesamt IOPS = IOPS/Mailbox * Anzahl Mailbox + 20% Overhead

Die Ermittelten IOPS müssen nun natürlich noch mit einem Faktor multipliziert werden, der sich aus dem verwendeten RAID-Level ergibt. Dazu gibt Microsoft folgende Werte vor:

Raidlevel Raid 10 Raid 5 Raid 6

Penalty-Faktor

2

4

6

Bei einem RAID10 muss der Massenspeicher ja jeden Schreibzugriff zweimal ausführen (daher braucht das Subsystem quasi auch die doppelte IOPS-Leistung. Bei einem RAID5 sind noch mehr Disks betroffen. Allerdings wird hier nicht mehr unterschieden, ob das Raid 5 nun aus 3,5,7 oder mehr Disks aufgebaut wurde. Ein RAID6 (zwei Parity Disks) kostet noch mal mehr. Sie reduzieren das Risiko eines Ausfalls zweier Platten gegenüber RAID5 und können daher den "Rebuild" mit niedrigerer Priorität mitlaufen lassen. Das kostet aber zusätzlich IOPS. Wobei es hier "Sonderfälle" gibt wie z.B. die NETAPP Systeme, die RAID6 durch ihre besondere Schreibtechnik angeblich auf RAID10-Level reduzieren. Das sind dann Fragen, mit denen Sie ihren Storageanbieter besser konfrontieren.

Berechnung des Datenbank Cache Bedarf

Für die Ermittlung des für die Datenbank erforderlichen Cache schlägt Microsoft folgende Tabelle vor.

Achtung: Dies entspricht NICHT dem Speicherbedarf für das spätere System. Das ist NUR der Cache der Datenbank.

Mails MS Empfehlung MSXFAQ Multiplikation

50 Mails/Tag a. 75k

3

3,75

100 Mails/Tag a. 75k

6

7,5

150 Mails/Tag a. 75k

9

11,25

200 Mails/Tag a. 75k

12

15

Wenn Sie nun mal den Bleistift hernehmen, und die Anzahl der Mails mit der Größe multiplizieren, dann sehen kommen Sie auf nur einen gering höheren Wert. Ich würde da immer die Größe der Mails heranziehen, die sie in ihrem System aus dem Message Tracking ermittelt haben. Ob Sie dies nun auf die Mailbox herunter brechen und am Ende wieder mit der Anzahl der Mailboxen multiplizieren ist eigentlich egal.

Nehmen Sie einfach die Summe der an einem Tag von den Anwendern "umgeschlagenen" Mails als Größe die den Hauptspeicher zum Exchange Cache.

Natürlich müssen Sie dann noch etwas Speicher für das Betriebssystem, Antivirus, Backup, Monitoring, Disclaimer etc. addieren, damit sie den realen Speicherbedarf ihres Servers haben

Berechnung der CPU

Hier wird es nun etwas "unangenehm", da Microsoft die Aktivität der Benutzer auf "Megacycles" umrechnet, zusatzlast für Replikation etc. drauf geschlagen wird und letztlich eine Zahl raus kommt, zu der man nun in den CPU-Listen die ausreichend schnellen Prozessoren suchen muss. Und selbst da schreibt Microsoft, dass es keine "exakte Wissenschaft" ist.

Eine Tabelle gibt die Megacycles pro Postfach je nach Profil vor

Mails Megacycles lokale aktive DB Megacycles für remote Passive DB Megacycles für lokal passive DB

50 Mails/Tag a. 75k

1

0,1

0,15

100 Mails/Tag a. 75k

2

0,2

0,3

150 Mails/Tag a. 75k

3

0,3

0,45

200 Mails/Tag a. 75k

4

0,4

0,6

Für einen einzelnen Server ist die Rechnung einfach: Sie nehmen die Anzahl der Mailboxen zu den Profilen und erhalten die Megacycles. Wer eine DAG verwendet, kann sich nun in feinen Rechnungen ergehen aber die meisten MSXFAQ-Leser werden bei einer DAG doch nicht mehr als zwei Server installieren, bei denen jeder so "gut" sein muss, dass er die gesamte Last tragen kann. Insofern müssen wir nicht groß zwischen Passiv und aktiv unterscheiden, da die passiven Lasten weit unter den aktiven Werten sind. Wer die aktiven Werte eines Single Servers nimmt und 10% draufschlägt, hat alle abgedeckt.

Dann bleibt nur die Frage, welche CPU wie viele Megacycles denn nun liefert. Microsoft nutzt die Werte des SpecINT 2006 ( http://www.spec.org/cgi-bin/osgresults?conf=cint2006), für den verschiedene Hersteller ihre Systeme bei http://www.spec.org/ veröffentlicht haben. Es kann durchaus sein, dass die gleiche CPU in unterschiedlichen Server leicht abweichende Werte hat. Hier eine Liste mit ein paar willkürlich ausgewählten CPUs, dass sie einmal die Spannweite der Leistung sehen

CPU Takt Cores Megacycles

Intel Xeon X5470

3,33 GHz

4

75

Intel Xeon X3450

2.66 GHz

4

111

Intel Xeon X5670

2.93GHz

6

180

Intel Xeon X5355

2.66GHz

4

45

Intel Xeon X7560

2,26HGz

8

376

AMD Opteron 4184

2.80 GHz

6

123

AMD Opteron 6174

2,2 GHz

12

190

AMD Opteron 8389

2,9 GHz

4

65

Die Werte gelten pro CPU. Systeme mit mehreren CPUs (also 2x QuadCore) müssen dann natürlich addiert werden. Microsoft hat eine Excel-Tabelle bereit gestellt, welche online bei Spec.org anhand einer eingegebenen CPU-Typkennzeichnung die veröffentlichten Werte abruft und aufbereitet.

Und auch hier dürfen Sie sonstige "Lasten" des Servers (Backup, Verwaltung, Antivirus, Monitoring etc.) nicht vergessen. Wer die Server virtuell betreibt, muss nicht nur die Last der anderen "Gäste" mit einrechnen sondern auch den Overhead für die Virtualisierung selbst. Microsoft nimmt da selbst konservativ 10% an.

Dabei wird gerne vergessen, dass jede Dimensionierung mit der IST-Aufnahme der aktuellen Situation und der Abschätzung für die nächsten Monate oder, wenn möglich, Jahre

Weitere Details zu Disk, CPU etc.

Disk und Sizing

Interessanter ist eher das Thema "Disks". Zwar nehmen CPU-Geschwindigkeit und HauptspeicherAusbau zu und auch die Festplatten wachsen in die Terabytes aber die Zugriffszeiten sind nicht viel weiter zu reduzieren. Das sind schon seit Jahren Millisekunden und vielleicht bringen hybride Festplatten noch etwas mehr, wenn Festplatte mit Speicher oder gleich der Wechsel zu SSD erfolgt. Dagegen sprechen aber immer noch die Kosten und Kapazitäten.

Interessanter für Exchange 2010 ist aber die Überlegung, große Datenbanken zu verwenden und Protokolldateien nicht mehr von Datenbanken trennen zu müssen. Bei früheren Exchange Versionen war es quasi ein Gesetz, das ein seriöser Planer die Datenbanken auf eine LUN und die Transaktionsprotokolle auf einen anderen Server ablegen. Da Exchange Server oft nur einmal in der Nacht gesichert werden, konnte so auch beim Ausfall einer Disk ein Datenverlust minimiert werden. Das ist natürlich noch deutlich unwahrscheinlicher, wenn die Datenbank innerhalb einer DAG auf einen zweiten oder vielleicht noch einen dritten Server repliziert wird. Zusammen mit der weiterhin reduzierten IO-Last durch Veränderungen der Datenbank können die beiden Datenpools nun kombiniert werden. Mal ehrlich: prüfen Sie mal die Anzahl der Logdateien pro Tag und rechnen sie diese Datenmenge auf die 10h Arbeitszeit auf die Sekunde um. Die LOG-Platten hatten doch bei mittleren und kleinen Servern nie was zu tun.

Die Größe der Datenbank war ebenfalls durch das Backup in Verbindung mit dem gewünschten SLA vorgegeben. Wenn ihr Backup eben nur 50-80GB/Stunde restaurieren konnte und sie nur 2-für ein Restore zur Verfügung hatten, dann durfte die Datenbank eben nicht größer 100-180 GB werden. Auch hier entspannt sich die Lage durch die Replikation auf weitere Server, die nebenbei auch noch eine bessere Verfügbarkeit bietet.

Auch der Einsatz der Recovery Storage Group begrenzt die Datenbankgröße, da für die Wiederherstellung natürlich auch Platz vorhanden sein muss. Nicht jeder kann seinem Exchange Server mal temporär eine weitere Disk per iSCSI o.ä. anbinden. Mit dem Exchange 2010 Dumpster bzw. "Legal Hold"-Funktion können Wiederherstellungen weiter reduziert werden, da die Anwender Elemente zwar "löschen" aber doch nicht endgültig entfernen kann. Und gegen allzu große Postfächer hilft auch die Archivmailbox, um bestimmte Daten einfach auf einen anderen Storage zu verlagern, für den andere SLAs gelten.

Fakt ist aber auch, dass die Postfachgrößen immer weiter anwachsen und damit natürlich auch die Server wie die vergangenen Jahre immer größere Festplatten bekommen bzw. mehr Festplatten.

CPU und Speicher Raten

In größeren Umgebungen mit mehreren Servern ist aber doch eine Betrachtung der erforderlichen CPU-Leistung erforderlich.

  1. CPU für MailboxServer
    Anhängig von der Last durch die Clients können die die CPU Anforderungen für die Mailboxrolle definiert werden
    Dabei ist eine CPU-Last bis zu 60% ok aber wenn die Last längere Zeit über 75% geht, dann ist das System zu knapp ausgelegt.
    Quellen:
    Grundlegendes zur Exchange-Leistung
    http://technet.microsoft.com/de-de/library/dd351192%28EXCHG.140%29.aspx und
    Mailbox Server Processor Capacity Planning
    http://technet.microsoft.com/en-us/library/ee712771.aspx
  2. Cores und Hauptspeicher der Rollen festlegen
    Dabei gibt Microsoft selbst folgende Empfehlungen:
    CAS zu Mailbox Rate: 3 : 4 Prozessorkerne, 8 Kerne ratsam mit 2 GB Ram/Kern
    Hub zu Mailbox Rate: 1 : 7 (ohne Antivirus auf dem Hub) bzw. 1 : 5 (mit A/V Hub) Kerne, 4 Kerne mit 1GBRam/Kern ratsam
    Mailbox 4-8 Kerne und 4GB RAM Basis zzgl. 2-8MB pro Mailbox (Profilabhängig)
    UM: 4 Kerne und 4-8GB RAM total
    Edge: 2 bis 4 Kerne
    Global Catalog zu Mailbox Rate: 1:4 (32–bit GC) bzw. 1:8 (64-bit GC) Kerne
    Auch >64MB möglich
    Understanding the Mailbox Database Cache
    http://technet.microsoft.com/en-us/library/ee832793.aspx
  3. Netzwerkbandbreite planen
    Zugriffe der Clients, Übertragung von Mails aber auch die Replikation von Transaktionen in der DAG bestimmen die erforderliche Bandbreite im LAN und die Anzahl der Netzwerkkarten
  4. Storage planen
    Ausgehend von den erforderlichen IOs und dem erforderlichen Platzbedarf können Sie das Festplatten-Layout definieren. Dabei gilt es dennoch SLAs und Backup zu berücksichtigen. Ohne die Replikation einer DAG sollten sie auch weitern regelmäßig und oft sichern und Transaktionsprotokolle und Datenbank auf getrennten müssenspeichern ablegen

Paging file size
The page file size minimum and maximum must be set to physical RAM plus 10  MB The recommended page file size also accounts für the memory that's needed to collect information if the operating system stops unexpectedly. On 64-bit operating systems, memory can be written as a dump file to the paging file. This file must reside on the boot volume of the server.
Quelle: http://technet.microsoft.com/en-gb/library/aa996719.aspx.

Sizer: Excel oder OEM Tools

Von Microsoft gibt es natürlich die berühmte bzw. berüchtigte Excel-Tabelle, in die Sie die Daten eingeben können, die sie ermittelt haben und bekommen danach diverse Aussagen zum Sizing der Mailboxserver. für die meisten Server aber auch Administratoren ist diese Excel-Datei aber einfach nur unverständlich, weil die Menge der KonfigurationsMöglichkeiten hoch und die Ergebnisse trotzdem einer Interpretation bedürfen.

Dabei gibt es durchaus Alternativen: Diverse Hersteller wie Dell oder Hewlett-Packard haben entsprechende Hilfsmittel, mit denen einfacher entsprechende Server dimensioniert werden können. Natürlich sind diese Sizer auf die entsprechenden Produkte aufgerichtet. Aber da die Server doch irgendwie vergleichbar sind, kann so ein Sizing eine gute Vorlage für die Konfiguration des eigenen Servers sein. Hier mal zwei Beispiele

Mit dem HP-Sizer habe ich mal 600 Benutzer angenommen, welche 1/40 Mails a 85kB übertragen und ca. 1 GB Postfächer im Mittel haben. Dazu gibt es zwei Lösungen:

  • Lösung 1: Single Server, alles Auf einer Box

    Da hier keine Replikation auf andere Festplatten möglich ist, (LCR gibt es bei Exchange 2010 nicht mehr) plant der HP-Sizer hier natürlich zurecht getrennte LUNs für Datenbank und Transaktionsprotokolle.
  • Lösung 2: 2 Server als DAG mit 2 Server für kombinierte HT/CAS
    Für 600 Benutzer mit der Datenmenge ist "Hochverfügbarkeit" schon ein Thema. Als DAG mit zwei Knoten und zwei CAS-Servern kommt folgendes Bild heraus.

    Beachten Sie, dass die Disks auf beide Server aufgeteilt werden. Es ist gut zu sehen, dass nun die Datenbanken und Transaktionsprotokolle auf einer Disk liegen. Der Speicher des DAG bleibt bei 12 GB aber die beiden HT/CAS-Server sind mit 8 GB ausgestattet.

Diese Werte sind nur ein "Muster" und sind nicht als Empfehlung oder Vorgabe zu verstehen.

Sie sollten daher ihre eigenen Anforderungen selbst erfassen.

Unterstützung durch Net at Work:
Wir helfen ihnen gerne bei der individuellen Ermittlung ihrer aktuellen Last

Weitere Links