Exchange Sizing - Die Grundlagen
Was müssen wir beim dimensionieren denn überhaupt alles berücksichtigen ?
Die Datenbereiche
Also hier die genaueren Informationen für die Eigenplanung. Exchange hat im wesentlichen diese zu unterscheidende Lasten:
- Betriebssystem
Das eigentliche NT-System, welche überwiegend beim Start gelesen werden und danach bei ausrechendem Speicher kaum mehr Festplattenlast verursachen. Meist sind 4-8 GB heute ausreichend. Das Überschreiten der 8 GB Grenze kann bei einigen Systemen beim Booten problematisch sein, so dass ich selbst gerne darunter bleibe. Allerdings sollte sichergestellt werden, dass keine "ungeplanten" Daten diesen Bereich auffüllen, z.B.: Logfiles etc. - Pagefile
Je nach Speicherausbau verursacht das Paging mehr oder weniger Last mit hoher Priorität (d.h. alles andere muss warten). Ziel ist ausreichender Speicherausbau, dass Paging nicht der Performanceengpass wird. Zudem kann Windows je Partition nur ein Swapfile mit maximal 4 GB anlegen, so dass größere Pagefilebereiche nur über weitere Partitionen realisiert werden können. Wenn NT auslagern muss UND die Platte mit dem Pagefile langsam ist, dann ist das Gesamtsystem lahm. Es lohnt sich aber die Größe des Pagefiles festzulegen um Fragmentierung zu reduzieren. - Programme
Auf dem Server kommen Programme zum Einsatz, z.B. die Binaries für Exchange, Virenscanner oder die Agenten für die Datensicherung. Diese Daten sind meist gering im Vergleich zur Datenbank und werden überwiegend beim Start gelesen. - Exchange Datenbank
Die Datenbank ist nicht zeitkritisch, da Exchange vieles im Cache hält, schließlich hat Exchange ja seine Protokolldateien. Aber Plattenplatz ist hier erst mal wichtig. (16 Gigabyte Limit bzw. 75 GB bei Standard, sonst mehr). - Exchange Logfiles
Die Transaktionsdateien von Exchange sind essentiell für die Performance, da diese synchron sequentiell geschrieben werden. Ideal ist eine eigene schnelle fehlertolerante Festplatte mit ausreichen Platz. Wenn ihre Backup einige tage nicht funktioniert, dann kann hier der Platz schnell eng werden. Ohne Umlaufprotokollierung (Datenbankgrundlagen) kommen hier schnell auch Gigabytes pro Tag zusammen. - Windows AD Files
Mit Exchange 2000 kommt das Active Directory dazu. Dazu muss man wissen, dass Windows 2000 auf der Festplatte, auf der das AD liegt, den Schreibcache abschaltet und auch hier Protokolldateien nutzt.
Wenn der Server aber nicht alleine dediziert für Exchange vorgesehen ist, sondern auch etwas DNS, WINS, Datei und Druckdienste oder als SBS-Server auch SQL fahren soll, dann sind weitere "Lasten" zu beachten.
Speichergruppen und Datenbanken
Wenn Sie einen Exchange 2000/2003 Enterprise Server installieren, dann können Sie nicht nur eine Datenbank für Postfach, eine Datenbank für öffentliche Ordner und einen Satz Protokolldateien verteilen, sondern mehrere Speichergruppen und Datenbanken nutzen.
Aber bei der Planung eines Exchange Clusters steht nicht nur die erwünschte Nettokapazität der Datenbank im Vordergrund, sondern auch die sinnvolle Aufteilung der Daten in Speichergruppen, Datenbanken und deren Ablage auf verschiedene Festplatten und die Gruppierung dieser Festplatten in Clustergruppen. Dabei gilt bzw. ist zu beachten:
- Grundlagen zur Anzahl
Exchange 2003 unterstützt bis zu 4 Speichergruppen mit jeweils eigenständigen Transaktionsprotokolldateien. Jede Speichergruppe erlaubt bis zu 5 Datenbanken aus jeweils zwei Dateien (EDB/STM) - Online/Offline
Datenbanken können individuelle Online und offline geschaltet werden. Dies kann z.B. erforderlich sein, wenn eine Datenbank auf einen anderen Datenträger verschoben werden soll oder offline defragmentiert, gesichert oder sonst wie bearbeitet werden muss. - Backup und Restore
Datenbanken können einzeln zurückgesichert werden. Aber während der Rücksicherung sind alle anderen Datenbank in der gleichen Speichergruppe ebenfalls „down“. Nur bei einer Sicherung der gesamten Speichergruppen werden die Protokolldateien zurückgesetzt. ACHTUNG: ist eine Datenbank in einer Speichergruppe offline, dann werden die Transaktionsdateien weder beim Backup noch beim Circular Logging abgeschnitten (-> Platzbedarf). Auf der anderen Seite kann immer nur ein Backupprozess pro Speichergruppe aktiv sein. Sie müssen daher mehrere Speichergruppen nutzen, um mehrere Backups parallel zu betreiben. - Single Instance Store
Der „Single Instance Store“ bleibt nur innerhalb einer Datenbank gewahrt. Eine Mail an mehrer Personen, deren Postfächer auf dem gleichen Server in unterschiedlichen Datenbanken liegen, wird die Information mehrfach gespeichert. Die Summe der Datenbanken ist größer. - Festplattenperformance
Jede Datenbank nutzt eigene Dateien und jede Speichergruppen nutzt eigenständige Protokolldateien. Durch die geschickte Aufteilung kann sowohl erreicht werden, dass alle Festplatten gleichmäßig belastet werden und das Gesamtsystem die maximale Performance bietet. Ebenso können bestimmte Datenbanken und Protokolldateien auf besonders schnelle und exklusiv genutzte Datenträger separiert werden, um eine bestimmte Leistung zu gewährleisten. - Postfachlimit
Begrenzungen auf Mailboxen können pro Benutzer aber auch pro Datenbank gesetzt werden. Dies kann ein Grund sein, mehrere Datenbanken für bestimmte Postfachtypen anzulegen und sich damit den Aufwand einzusparen, pro Postfach individuelle Beschränkungen zu pflegen. - Recovery SG
Eine Datenbank ist die kleinste Einheit, die bei Exchange 2003 in einer Wiederherstellungsspeichergruppe restauriert werden kann. Je kleiner die einzelne Datenbank ist, desto schnell und Platz sparender ist so eine Wiederherstellung um z.B. den Inhalt einer einzelnen Mailbox wieder zu erlangen. Dies ist eher ein Argument für mehrere kleine Datenbanken - VIP-User
Besondere Benutzer haben besondere Ansprüche. Eine eigene Datenbank hierfür kann in mehrfacher Hinsicht hierbei helfen: So können eigene Postfachgrenzen, bessere Performance durch eigene Festplatte, häufigere Backups und schnellere Wiederherstellungen gewährleistet werden. - Desaster Recovery Optionen
Durch die Trennung von Datenbanken und Transaktionsprotokollen auf unabhängigen Speichermedien kann bei einem Ausfall der Datenbank diese bis zum Moment des Ausfalls wieder hergestellt werden. Nach der erfolgreichen Wiederherstellung der Datenbank vom letzten Backup wird Exchange die Änderungen seit dieser Zeit anhand der Transaktionsprotokolle nachziehen. - Restorezeit/ Service Level Agreements SLA
Das wichtigste Kriterium für die Aufteilung in mehrere Datenbanken ist jedoch die maximal vernünftig handhabbare Größe einer einzelnen Datei. Dies gilt im Hinblick auf die Sicherung, Wiederherstellung, Defragmentierung, Verlagerung etc. Exchange Datenbanken können bis in den Terabyte Bereich wachsen, aber sind meist schon mit mehr als 200 GByte nicht mehr vernünftig zu handhaben, so dass eine Unterteilung in mehrere Datenbanken oder sogar die Verteilung auf mehrere Server erforderlich wird. - Hauptspeichernutzung
Ein weiteres Kriterium ist die Nutzung des Hauptspeichers. Jede Speichergruppe belegt je nach Server ca. 150 Megabyte. Das war lange Zeit ein Kriterium, mit einer Speichergruppe anzufangen und diese erste mit Datenbanken bis zur projektierten Maximalgröße aufzufüllen. Heute ist Speicher weniger der Engpass, sondern eher Festplattendurchsatz, so dass heute auch mehrere Speichergruppen mit nicht voll ausgebauten Datenbanken zum Einsatz kommen. - Cluster
Für den Betrieb als Cluster haben die Speichergruppen eine besondere Bewandtnis. In der Regel wird eine Speichergruppe mit den dazugehörigen Datenbanken auch gleich als virtueller Server genutzt und in einer Clustergruppe zusammen gefasst. Es kann dabei immer nur eine komplette Speichergruppe mit allen enthaltenen Datenbank von einem Knoten auf den anderen Knoten umschwenken.
Damit stellt sich die Frage, wie die zu erwartenden Datenmenge sinnvoll verteilt werden können um im Hinblick auf handhabbare Datenbankgrößen, Performance und Verfügbarkeit das Maximum zu erreichen.
Design-Regeln und Hinweise zur Partitionierung
Nun geht es an die Verteilung dieser Daten. Natürlich wären sechs eigene RAID-System ideal aber kaum zu bezahlen. Daher gilt es zu überlegen, was wie geschickt kombiniert werden kann. Leider gibt es da keine immer gültigen Wege, sondern Exchange Sizing ist eben Beratungsaufwändig. Einige Ideen:
- Das Betriebssystem und die Programme sind im laufenden Betrieb nicht sonderlich intensiv im gebraucht und könnten zusammen mit dem Pagefile auf einem Festplattensystem abgelegt werden. Natürlich kann man diese eine logische Festplatte mit Partitionen so abtrennen, dass das Betriebssystem seinen reservierten Platz frei hat.
- Wenn der Server genug Speicher hat und daher kaum auslagert, wäre es sogar denkbar, die Transaktionsdateien mit auf die Festplatte (aber nicht die gleiche Partition !!) wie das System und die Programme zu legen.
- Auf der andere Seite bedeuten Partitionen natürlich eine weitgehend feste Verteilung des Festplattenplatz, so dass später kaum noch ab und zu gegeben werden kann, es sei den man arbeitet mit dynamischen Festplatten und unbenutzten Bereichen.
- Die Datenbanken benötigen natürlich erst mal viel Platz. Allerdings ist die Zeit der teuren 9 GB Festplatten im RAID-5 schon lange vorbei, so dass auch ein Paar 72 GB Festplatten als RAID-1 erschwinglich sind.
- Achten Sie speziell beim Design der Datenbankenspeicherplätze auf die Anforderungen der Datenbank, wie diese die Speichermedien belastet. Trennen Sie, wenn möglich die sequentiellen Zugriffe auf Protokolldateien von den wahlfreien Zugriffen der Datenbanken.
- Mit Exchange 2000 können sie dazu mehrere Speichergruppen (SG) nur nutzen, wenn sie ausreichend unabhängige Speichermedien bereitstellen können und die Planung auch dies berücksichtigt. Besser eine Speichergruppe mit mehreren Datenbanken, da viele Speichergruppen die Performance bremsen.
Insofern sollten sie bei einem kleinen Server mit einer Festplatte oder einen RAID, das aussieht wie eine Festplatte z.B.: mit zwei Partitionen arbeiten. Eine Für Betriebssystem und Exchange Programme und die Zweite für die Nutzdaten von Exchange, Dateiserver etc. Damit ist zumindest sichergestellt, dass bei einem Defekt des Betriebssystems oder dieses Dateisystems nur diese Partition zurückgesichert werden muss und ein unbemerktes "Vollaufen" des Servers nicht gleich das ganze System außer kraft setzt. Eventuell reservieren Sie sich sogar noch etwas Platz in einer eigenen Partition für ein Imagebackup dieses Betriebssystems.
Ist der Server größer, so können Sie dann die Exchange Datenbanken und Transaktionsprotokolle angemessen verteilen.
Mit Exchange 2007 empfiehlt Microsoft übrigens die
Formatierung der Festplatten mit NTFS und 64k Blocksize.
Diskpar
Design-Regeln für CPU und Speicher (Exchange 2000/2003)
Daniel Melanchthon hat vor einiger Zeit in einer Newsgroup mal ein paar Erfahrungswerte zum Besten gegeben und dabei auch die Bedeutung von MAPI bzw. IMAP4 aufgestellt. Besonders interessant ist hierbei die Reduzierung der Last durch den Outlook 2003 Cached Mode.
Scale Up & Scale Out: Postfachserver (MAPI)
- Backend-Server skaliert bis acht CPUs
- Pro 1.000 Benutzer je ein Prozessor planen.
- 25% bessere Prozessor-Skalierbarkeit mit Hyperthreadingtechnologie.
- 100 Mbit/s Duplex völlig ausreichend.
- 50% Verringerung der Netzwerkbandbreite bei Verwendung von Exchange 2003/Outlook 2003.
Scale Up & Scale Out: IMAP4-Server
- IMAP4 Frontend skaliert gut bis zwei CPUs
- Ein IMAP4 Frontend für acht Backend-Server
- 15.000 gleichzeitig aktive Benutzer nur 25% CPU-Zeit)
- 256 MB - 512 MB RAM für Frontend-Server
- 100 Megabit/s Duplex für bis zu zwei Prozessoren (ab 800MHz auch 1 Gigabit/s Duplex sinnvoll)
- SSL erhöht die Prozessorauslastung um 100% und den Hauptspeicherbedarf um 10%
Netzwerk ?
Klar dass ein Exchange Server ohne Netzwerk nicht funktionieren kann. Schließlich müssen sowohl die Anwender an die Datenbank kommen, als auch der Austausch von Nachrichten mit anderen Systemen möglich sein. Aber auch die Kommunikation zu den Domaincontrollern und vielleicht eine Datensicherung über das Netzwerk sind Aspekte die sowohl den Tagesbetrieb als auch die notwendige Spitzenleistung vorgeben. Heute Server können aber selbst im reinen IP-Betrieb kaum eine Gigabit-Karte auslasten. Selbst die Leistung einer 100 Megabit Karte ist für den normalen Betrieb durchaus seriös nutzbar. Interessant sind hier die Aspekte, mehrere Karten als Team zu schalten um neben mehr Bandbreite auch eine Redundanz bei Ausfällen zu haben.
Weitere Links
- IOPS - Input Output Operations
Eine wichtige Kennzahl bei der Dimensionierung von Servern - 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 - Optimizing Storage for Microsoft Exchange Server 2003
http://www.microsoft.com/downloads/details.aspx?FamilyID=c6084d20-9730-4ffc-805d-b957327604c6&DisplayLang=en - Robert’s Rules of Exchange: Multi-Role Servers
http://blogs.technet.com/b/exchange/archive/2011/04/08/robert-s-rules-of-exchange-multi-role-servers.aspx
