Sizing Guide Exchange Server 2003 - Fujitsu
Sizing Guide Exchange Server 2003 - Fujitsu
Sizing Guide Exchange Server 2003 - Fujitsu
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Sizing</strong> <strong>Guide</strong><br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
Abstract<br />
Dimensionierung von PRIMERGY Systemen für<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong>.<br />
Diese technische Dokumentation richtet sich an<br />
Personen, die sich mit der Dimensionierung von<br />
PRIMERGY <strong>Server</strong>n für Microsoft <strong>Exchange</strong> <strong>Server</strong><br />
<strong>2003</strong> beschäftigen. Sie soll in der Presales-Phase<br />
helfen, für eine geforderte Benutzeranzahl / Leistungsklasse<br />
das passende <strong>Server</strong>modell zu finden.<br />
Neben der Frage wie man für eine gewünschte Benutzeranzahl zur erforderlichen Systemleistung kommt,<br />
werden insbesondere die Ressourcenanforderungen von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> und die dadurch entstehenden<br />
möglichen Engpässe aufgezeigt und diskutiert. Dabei werden die Möglichkeiten der verschiedenen<br />
PRIMERGY Modelle und deren Leistungsklassen hinsichtlich <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> beleuchtet und<br />
Musterkonfigurationen vorgestellt.<br />
Inhalt<br />
PRIMERGY .............................................................. 2<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ............................................. 3<br />
Neues in <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ........................... 4<br />
Ausblick auf <strong>Exchange</strong> 2007 ................................. 5<br />
<strong>Exchange</strong> Messmethodik ......................................... 6<br />
Benutzer Definition ................................................ 6<br />
Lastsimulation mit LoadSim <strong>2003</strong> .......................... 7<br />
Benutzerprofile ...................................................... 8<br />
Evolution der Benutzerprofile ................................ 8<br />
LoadSim 2000 vs. LoadSim <strong>2003</strong> .......................... 9<br />
Benchmark versus Realität .................................. 10<br />
Systemauslastung ............................................... 11<br />
<strong>Exchange</strong> relevante Ressourcen ........................... 13<br />
<strong>Exchange</strong> Architektur .......................................... 13<br />
Active Directory und DNS .................................... 14<br />
Betriebssystem .................................................... 15<br />
Rechenleistung .................................................... 16<br />
Arbeitsspeicher .................................................... 16<br />
Disk-Subsystem .................................................. 18<br />
Transaktionsprinzip .......................................... 19<br />
Zugriffsmuster ................................................... 20<br />
Caches ............................................................. 20<br />
RAID-Level ....................................................... 21<br />
Datendurchsatz ................................................ 23<br />
Festplatten ........................................................... 24<br />
Speicherplatz .................................................... 26<br />
Netzwerk ............................................................. 27<br />
Version 4.2<br />
Juli 2006<br />
Seiten 71<br />
Hochverfügbarkeit ................................................ 27<br />
Backup ................................................................. 28<br />
Backup-Lösungen für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ...... 32<br />
Archivierung ......................................................... 36<br />
Virenschutz .......................................................... 37<br />
System Analyse Tools ............................................ 38<br />
Performance-Analyse ........................................... 40<br />
PRIMERGY als <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> .................. 44<br />
PRIMERGY Econel 100 ....................................... 46<br />
PRIMERGY Econel 200 ....................................... 48<br />
PRIMERGY TX150 S4 ......................................... 49<br />
PRIMERGY TX200 S3 ......................................... 51<br />
PRIMERGY RX100 S3 ......................................... 53<br />
PRIMERGY RX200 S3 ......................................... 54<br />
PRIMERGY RX220 .............................................. 56<br />
PRIMERGY RX300 S3 / TX300 S3 ...................... 58<br />
PRIMERGY BX600 .............................................. 61<br />
PRIMERGY BX620 S3 ...................................... 61<br />
PRIMERGY BX630 ........................................... 61<br />
PRIMERGY RX600 S3 / TX600 S3 ...................... 65<br />
PRIMERGY RX800 S2 ......................................... 68<br />
PRIMERGY RXI300 / RXI600 .............................. 68<br />
Zusammenfassung ............................................... 69<br />
Literatur ................................................................... 70<br />
Dokument Historie .................................................. 71<br />
Kontakt .................................................................... 71
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY<br />
All den Lesern, denen der Name PRIMERGY noch kein Begriff<br />
ist, sei hier zunächst ein kleiner Überblick gegeben: PRIMERGY<br />
<strong>Server</strong> ist seit 1995 der Markenname für eine sehr erfolgreiche<br />
<strong>Server</strong>familie aus dem Hause <strong>Fujitsu</strong>. Es handelt sich dabei um<br />
eine von <strong>Fujitsu</strong> entwickelte und produzierte Produktlinie mit<br />
Systemen für kleine Arbeitsgruppen bis hin zu Lösungen für<br />
Großunternehmen.<br />
Scalability, Flexibility & Expandability<br />
Vom kleinen Mono Prozessor System bis hin zu<br />
Systemen mit 16 Prozessoren kommen in der<br />
PRIMERGY Familie die neuesten Technologien zum<br />
Einsatz. Als Herzstück werden Intel oder AMD<br />
Prozessoren der obersten Leistungsklasse verwendet.<br />
Mehrere 64-bit PCI-X-I/O- und Memory-Busse, schnelles<br />
RAM und performante Komponenten, wie SCSI-<br />
Technologie und Fibre-Channel, sorgen für hohen<br />
Datendurchsatz. Dies bedeutet Leistung satt, gleich ob für<br />
Scaling-Out oder Scaling-Up. Bei der Methode des<br />
Scaling-Out, die nach dem Ameisenstaat-Modell mehr Leistung durch eine Vielzahl von Einzelindividuen<br />
erzielt, können idealerweise Blade-<strong>Server</strong> und kompakte Compu-Node Systeme platziert werden. Für die<br />
Methode des Scale-Ups, d.h. Hochrüsten eines vorhandenen Systems, sorgen die umfangreichen<br />
Ausbaumöglichkeiten der PRIMERGY Systeme, auf bis zu 16 Prozessoren und 256 Gigabyte Arbeitsspeicher.<br />
PCI- und PCI-X-Slots sorgen für die notwendige Erweiterbarkeit von I/O-Komponenten. Eine Langzeitplanung<br />
in enger Zusammenarbeit mit namhaften Zulieferern von Komponenten, wie z.B. Intel, AMD, LSI,<br />
<strong>Server</strong>Works, sichert kontinuierliche und bestmögliche Kompatibilität von einer zur nächsten <strong>Server</strong>-<br />
Generation. Die PRIMERGY Planung reicht zwei Jahre in die Zukunft und garantiert eine möglichst frühe<br />
Einbeziehung neuester Technologien.<br />
Reliability & Availability<br />
Neben der Leistung steht die Qualität im Vordergrund. Dazu zählen nicht nur eine exzellente Verarbeitungsqualität<br />
und der Einsatz qualitativ hochwertiger Einzelkomponenten, sondern auch Vorkehrungen zur<br />
Ausfallsicherheit, frühzeitiger Fehlerdiagnose und Datenschutz. Wichtige Systemkomponenten sind<br />
redundant ausgelegt, und werden vom System auf Funktionalität überwacht. Viele Teile können problemlos<br />
im laufenden Betrieb ausgetauscht werden, so dass Ausfallzeiten minimiert werden und die Verfügbarkeit<br />
gewährleistet wird.<br />
Security<br />
Ihre Daten sind der PRIMERGY heilig. Schutz vor Datenverlusten bieten leistungsfähige Disk-Subsysteme<br />
der PRIMERGY und FibreCAT Produktlinie. Eine noch höhere, größtmögliche Verfügbarkeit bieten<br />
PRIMERGY Cluster-Konfigurationen, bei denen nicht nur die <strong>Server</strong>, sondern auch die Disk-Subsysteme<br />
sowie die gesamte Verkabelung redundant ausgelegt werden können.<br />
Manageability<br />
Umfassende Management-Software für alle Phasen des <strong>Server</strong>-Lebenszyklus sorgt für einen reibungslosen<br />
Betrieb und erleichtert Wartung und Fehlerdiagnose der PRIMERGY.<br />
<strong>Server</strong>Start, ein benutzerfreundliches, menübasiertes Software-Paket für die optimale<br />
Installation und Konfigurierung des Systems mit automatischer Hardware-Erkennung und<br />
Installation aller notwendigen Treiber.<br />
<strong>Server</strong>View zur <strong>Server</strong>überwachung mit Alarm-, Schwellen-, Berichts- und Basis-Management,<br />
Prefailure Detection and Analyzing, Alarm-Service und Versionsmanagement.<br />
RemoteView zur von der Hardware und dem Betriebssystem unabhängigen Fern-Wartung<br />
und -Diagnose via LAN oder Modem.<br />
Weitere detaillierte Informationen zu den PRIMERGY Systemen finden Sie im Internet unter<br />
http://de.ts.fujitsu.com/primergy.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 2 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
Für Leser, denen das Produkt Microsoft <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> noch nicht vertraut ist, sei dieser Abschnitt<br />
mit einem kurzen Überblick gewidmet. Dabei können leider nur die wichtigsten Funktionalitäten angerissen<br />
werden. Wollte man auf alle Eigenschaften des Microsoft <strong>Exchange</strong> <strong>Server</strong>s eingehen, würde der Rahmen<br />
dieses White Papers und dessen eigentliches Thema gesprengt werden.<br />
Der Microsoft <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> stellt eine moderne Client-<strong>Server</strong>-Lösung für Messaging und<br />
Workgroup-Computing dar. <strong>Exchange</strong> ermöglicht den sicheren Zugriff auf Postfächer, Postablage und<br />
Adressbücher. Neben der Übermittlung von elektronischer Post bietet diese Plattform komfortable Terminkalenderfunktionen<br />
innerhalb einer Organisation oder Arbeitsgruppe, Publikation von Informationen in öffentlichen<br />
Ordnern und Web-Storage, elektronische Formulare, bis hin zu benutzerdefinierten Anwendungen zur<br />
Automatisierung von Arbeitsabläufen (Workflow).<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ist vollständig in das Windows Active Directory integriert und unterstützt<br />
eine hierarchische Topologie. Dabei kann innerhalb einer Organisation eine Vielzahl von <strong>Exchange</strong> <strong>Server</strong>n,<br />
nach Standorten gruppiert, weltweit gemeinsam operieren. Die Administration kann dabei zentral und standortübergreifend<br />
geschehen. Dieses dezentrale Konzept erhöht die Leistung und Verfügbarkeit von Microsoft<br />
<strong>Exchange</strong> als Messaging-System im Unternehmen und ermöglicht eine hervorragende Skalierbarkeit.<br />
Datensicherheit garantiert <strong>Exchange</strong> zum einen durch eine vollständige Einbettung in die Sicherheitsmechanismen<br />
von Windows, zum anderen sind zusätzliche Mechanismen, wie zum Beispiel digitale Signaturen<br />
und Verschlüsselung von E-Mails verfügbar.<br />
Das hohe Maß an Zuverlässigkeit, welches bereits ein einzelner <strong>Exchange</strong> <strong>Server</strong> bietet, wird durch die<br />
Unterstützung des Microsoft Clustering Service, der in Windows <strong>Server</strong> <strong>2003</strong> Enterprise Edition und Datacenter<br />
Edition enthalten ist, noch um ein Vielfaches erhöht. Dabei können Cluster von zwei bis acht Knoten<br />
aufgebaut werden.<br />
Durch so genannte Konnektoren kann der Microsoft <strong>Exchange</strong> <strong>Server</strong> an weltweite E-Mail-Dienste, wie<br />
Internet und X.400 angekoppelt werden. Ebenso ist die Interoperabilität mit anderen Mail-Systemen, wie<br />
Lotus Notes, Professional Office System (PROFS) und SNA Distributions Services (SNADS) gegeben.<br />
Darüber hinaus gibt es mittlerweile von Drittanbietern eine Vielzahl von Gateways, welche weitere Dienste in<br />
den <strong>Exchange</strong> <strong>Server</strong> integrieren, wie z.B. FAX, Telefonanbindung für Call-Center-Lösungen, Voicemail,<br />
uvm.<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> bietet zur Kommunikation eine Vielzahl von Standardprotokollen an, wie<br />
Post Office Protocol Version 3 (POP3), Simple Mail Transfer Protocol (SMTP), Lightweight Directory Access<br />
Protocol (LDAP), Internet Message Access Protocol Version 4 (IMAP4), Network News Transfer Protocol<br />
(NNTP) und Hypertext Transfer Protocol (HTTP), mit denen sich <strong>Exchange</strong> problemlos in heterogene Netzwerk-<br />
und heterogene Client-Umgebungen integriert. Dadurch ist der ortsunabhängige Zugriff auf die vom<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> verwalteten Informationen gewährleistet, gleich ob es sich um Desktop PCs (unabhängig<br />
vom Betriebssystem), Personal Digital Assistants (PDAs) oder Mobiltelefone handelt.<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> gibt es in zwei Ausprägungen:<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
Standard Edition<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
Enterprise Edition<br />
Plattform für kleine und mittelständige<br />
Unternehmen.<br />
Plattform für mittlere bis sehr große,<br />
weltweit tätige Unternehmen mit<br />
höchsten Ansprüchen an Zuverlässigkeit<br />
und Skalierbarkeit.<br />
Max. 2 Datenbanken<br />
Max. 16 GB pro Datenbank<br />
(mit Service Pack 2 bis zu 75 GB)<br />
Max. 20 Datenbanken<br />
Max. 16 TB pro Datenbank<br />
Cluster Support<br />
X.400 Connector<br />
Die <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Standard Edition ist einer der Bestandteile des Bundles »Windows Small<br />
Business <strong>Server</strong> <strong>2003</strong>«. Windows Small Business <strong>Server</strong> (SBS) ist als Komplettpaket konzipiert, um die<br />
besonderen Anforderungen kleiner und mittlerer Unternehmen bis 75 Arbeitsplätze zu erfüllen.<br />
Im Internet finden Sie weiterführende Informationen über Microsoft <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> unter<br />
www.microsoft.com/exchange und www.microsoft.com/windowsserver<strong>2003</strong>/sbs.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 3 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Neues in <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> hat eine nunmehr 10-jährige Historie,<br />
die bis 1996 zurück reicht. Die erste Version von <strong>Exchange</strong> trug<br />
die Versionsnummer 4.0, da es das Vorgängerprodukt MS Mail 3.2<br />
ablöste. Dabei hat <strong>Exchange</strong> architektonisch jedoch nichts mit MS<br />
Mail gemein, außer dass beide Anwendungen im Wesentlichen<br />
dem Austausch von E-Mails dienen. Heute, 10 Jahre nach der<br />
Markteinführung, trägt <strong>Exchange</strong> die Produktbezeichnung<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> und die interne Versionsnummer 6.5.<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> war nach drei Jahren der Nachfolger von <strong>Exchange</strong> 2000 <strong>Server</strong>. Ausgehend von<br />
dem Produktnamen und der Zeitspanne, die zwischen den beiden Produktversionen liegt, könnte man<br />
annehmen, dass <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> revolutionäre Änderungen mitgebracht hat, aber wie die interne<br />
Versionskennung verrät, handelt es sich um ein so genanntes Punkt-Release. Die Änderungen sind weniger<br />
revolutionärer als vielmehr evolutionärer Natur, im Gegensatz zu den Änderungen von <strong>Exchange</strong> <strong>Server</strong> 5.5<br />
nach <strong>Exchange</strong> 2000 <strong>Server</strong>.<br />
<strong>Exchange</strong> 2000 <strong>Server</strong> brachte gegenüber seiner Vorgängerversion <strong>Exchange</strong> <strong>Server</strong> 5.5 ein völlig neues<br />
Konzept der Datenbanken-Organisation und Benutzerdaten-Verwaltung, das Auswirkungen bis hin zur<br />
Domain-Struktur des Windows Netzwerkes hatte, so dass anstelle eines vergleichsweise einfachen Updates<br />
eine Migration von <strong>Exchange</strong> <strong>Server</strong> 5.5 nach <strong>Exchange</strong> 2000 <strong>Server</strong> notwendig war. Dies bedingte, dass<br />
viele <strong>Exchange</strong> Anwender vor diesem Migrationsaufwand zurückschreckten, und direkt von <strong>Exchange</strong><br />
<strong>Server</strong> 5.5 nach <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> migrierten. Der Umstieg von <strong>Exchange</strong> 2000 <strong>Server</strong> nach <strong>Exchange</strong><br />
<strong>Server</strong> <strong>2003</strong> gestaltet sich hingegen wesentlich unproblematischer und entspricht einem einfachen Update.<br />
Trotz allem sind die neuen Funktionalitäten in <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> gegenüber <strong>Exchange</strong> 2000 <strong>Server</strong><br />
nicht zu verachten. Und auch mit dem Service Pack 1 (SP1) und Service Pack 2 (SP2) wurde der <strong>Exchange</strong><br />
<strong>Server</strong> <strong>2003</strong> nicht nur um Fehler bereinigt, sondern mit einer Vielzahl neuer Funktionen, wie Mobiler E-Mail-<br />
Zugriff mit Direct-Push-Technologie und verbesserte SPAM-Filter-Methoden mit »Intelligent Message Filter«<br />
(IMF), erweitert. Das White Paper What's new in <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> [L7] von Microsoft beschreibt auf<br />
mehr als 200 Seiten die neuen Features von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> inklusive SP2. Ein Großteil der neuen<br />
Funktionen beziehen sich auf Sicherheit (Security), Administrierbarkeit (Manageability), Mobile Endgeräte<br />
(Mobility), sowie Client-seitige Erweiterungen, wie sie der neue Standard Client für <strong>Exchange</strong> - Outlook <strong>2003</strong><br />
und das überarbeitete OWA (Outlook Web Access) bieten. Wir wollen uns im Folgenden an dieser Stelle auf<br />
einige herausragende Neuerungen konzentrieren, die Auswirkungen auf die Hardware-Basis eines<br />
<strong>Exchange</strong> <strong>Server</strong>s haben.<br />
Kürzere Backup- und Restore-Zeiten<br />
Der Volume Shadow Copy Service (kurz VSS genannt) ist eigentlich eine neue Funktionalität von<br />
Windows <strong>Server</strong> <strong>2003</strong> und ermöglicht die Erstellung von Snapshot-Backups. <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ist<br />
kompatibel zu dieser neuen VSS-Funktionalität. Somit ist es nun möglich, in kürzester Zeit Backups der<br />
<strong>Exchange</strong> Datenbanken zu erstellen und damit die Backup- und Restore-Zeiten, die sich als limitierender<br />
Faktor bei großen <strong>Exchange</strong> <strong>Server</strong>n ergeben, drastisch zu reduzieren. In den nachfolgenden Kapiteln<br />
Konsolidierung und Backup wird noch intensiver auf diese Funktionalität eingegangen.<br />
Erstmalig bietet <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> eine einfache Methode für den Restore einzelner Mailboxen.<br />
Hierfür gibt es eine eigene Recovery Storage-Group, die im laufenden Betrieb den Restore einzelner<br />
Mailboxen oder einzelner Datenbanken erlaubt.<br />
Erweitertes Clustering<br />
Im Gegensatz zu <strong>Exchange</strong> 2000 <strong>Server</strong>,<br />
welches ein Cluster mit zwei Knoten auf Basis<br />
von Windows 2000 Advanced <strong>Server</strong> und vier<br />
Knoten unter Windows 2000 Datacenter <strong>Server</strong><br />
unterstützte, erlaubt <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> die<br />
Realisierung eines Clusters mit bis zu acht<br />
Knoten bereits unter Windows <strong>Server</strong> <strong>2003</strong><br />
Enterprise Edition.<br />
<strong>Exchange</strong> 4.0 v 4.0 Apr. 1996<br />
<strong>Exchange</strong> 5.0 v 5.0 Mär. 1997<br />
<strong>Exchange</strong> 5.5 v 5.5 Nov. 1997<br />
<strong>Exchange</strong> 2000 v 6.0 Okt. 2000<br />
<strong>Exchange</strong> <strong>2003</strong> v 6.5 Okt. <strong>2003</strong><br />
<strong>Exchange</strong> <strong>2003</strong> SP1 v 6.5 Mai. 2004<br />
<strong>Exchange</strong> <strong>2003</strong> SP2 v 6.5 Okt. 2005<br />
<strong>Exchange</strong> 2000<br />
Enterprise <strong>Server</strong><br />
Anzahl Cluster-Knoten<br />
<strong>Exchange</strong> <strong>2003</strong><br />
Enterprise Edition<br />
Windows 2000<br />
<strong>Server</strong> - -<br />
Advanced <strong>Server</strong> 2 2<br />
Datacenter <strong>Server</strong> 4 4<br />
Windows <strong>2003</strong><br />
Standard Edition - -<br />
Enterprise Edition - 8<br />
Datacenter Edition - 8<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 4 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Reduzierte Netzwerklast<br />
Outlook <strong>2003</strong>, die aktuelle Version des Standard <strong>Exchange</strong> Clients, liefert mit der neuen Funktionalität<br />
des Client-Side-Cachings einen großen Beitrag zur Reduzierung der Netzwerklast. Insbesondere bei<br />
Clients, die über schmalbandige WAN-Verbindungen angeschlossen sind, stellt dies eine große<br />
Entlastung des Netzes, aber auch eine Entlastung des <strong>Server</strong>s dar. Stellten alle früheren Outlook-<br />
Versionen noch für jedes Objekt eine Anfrage an den <strong>Exchange</strong> <strong>Server</strong>, so wird nun nur noch beim<br />
ersten Zugriff der <strong>Exchange</strong> <strong>Server</strong> bemüht. Des Weiteren wird nun eine Datenkompression bei der<br />
Kommunikation zwischen Outlook <strong>2003</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> verwendet.<br />
Auch die Kommunikation der <strong>Exchange</strong> <strong>Server</strong> untereinander wurde optimiert. So wird z.B. für die<br />
Replizierung der Public-Folder nun immer eine least-cost Kalkulation zugrunde gelegt und die Zugriffe<br />
von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> auf das Active Directory werden durch bessere Caching-Algorithmen um bis<br />
zu 60% reduziert.<br />
Man beachte, dass viele der neuen Funktionalitäten von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> nur dann zur Verfügung<br />
stehen, wenn <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> in Verbindung mit Windows <strong>Server</strong> <strong>2003</strong> und Outlook <strong>2003</strong> eingesetzt<br />
wird. Weitere Details sind in dem White Paper What's new in <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> [L7] zu finden.<br />
Ausblick auf <strong>Exchange</strong> 2007<br />
Nach dem Rückblick auf die Historie von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> möchten wir auch einen kurzen Ausblick auf<br />
die Zukunft von <strong>Exchange</strong> <strong>Server</strong> geben. Die nächste Version von <strong>Exchange</strong> wird »<strong>Exchange</strong> <strong>Server</strong> 2007«<br />
heißen und, wie der Name bereits nahe legt, im Jahre 2007 erscheinen.<br />
Die herausragende Performance-relevante Änderung wird der Wechsel von 32-bit auf 64-bit sein. <strong>Exchange</strong><br />
<strong>Server</strong> <strong>2003</strong> ist eine 32-bit Anwendung und läuft ausschließlich auf der 32-bit-Version von Windows. Da<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> keinen aktiven Gebrauch von PAE macht, ist <strong>Exchange</strong> auf einen Adressraum von<br />
3 GB begrenzt. Ein Ausbau eines <strong>Exchange</strong> <strong>Server</strong>s mit mehr als 4 GB Arbeitsspeicher bringt keinen<br />
Performance-Gewinn. Andererseits »lebt« <strong>Exchange</strong> von dem Cache für die Datenbanken (siehe Kapitel<br />
Arbeitsspeicher). Mit <strong>Exchange</strong> <strong>Server</strong> 2007 wird diese Limitierung überwunden. <strong>Exchange</strong> <strong>Server</strong> 2007 wird<br />
ausschließlich als 64-bit-Version für x64 Architekturen (Intel CPUs mit EMT64 und AMD Opteron)<br />
erscheinen; eine Version für die IA64 Architektur (Itanium) ist nicht geplant.<br />
Wie die nebenstehende Tabelle verdeutlicht,<br />
wird mit 64-bit die Ausnutzung<br />
des physikalischen Arbeitsspeichers<br />
deutlich verbessert.<br />
<strong>Exchange</strong> <strong>Server</strong> 2007 wird bei entsprechend<br />
verfügbarem Arbeitsspeicher<br />
insbesondere durch einen<br />
größeren Datenbank-Cache profitieren.<br />
Dies reduziert die Anzahl<br />
physikalischer<br />
Speicher<br />
<strong>Exchange</strong><br />
Adressraum<br />
Windows <strong>Server</strong> <strong>2003</strong> R2 Standard Edition 4 GB 3 GB<br />
Windows <strong>Server</strong> <strong>2003</strong> R2 Enterprise Edition 64 GB 3 GB<br />
Windows <strong>Server</strong> <strong>2003</strong> R2 Datacenter Edition 128 GB 3 GB<br />
Windows <strong>Server</strong> <strong>2003</strong> R2 x64 Standard Edition 32 GB 8 TB<br />
Windows <strong>Server</strong> <strong>2003</strong> R2 x64 Enterprise Edition 1 TB 8 TB<br />
Windows <strong>Server</strong> <strong>2003</strong> R2 x64 Datacenter Edition 1 TB 8 TB<br />
Zugriffe und somit die Anforderungen an das Disk-Subsystem, das bei heutigen <strong>Exchange</strong> Konfigurationen<br />
häufig die Performance des Gesamtsystems bestimmt. Dadurch kann mit <strong>Exchange</strong> <strong>Server</strong> 2007 entweder<br />
bei konstanter Benutzeranzahl das Disk-Subsystem kostengünstiger gestaltet werden, oder aber eine<br />
größere Anzahl an Benutzern bedient werden.<br />
Hinzu kommt mit <strong>Exchange</strong> <strong>Server</strong> 2007 eine Vielzahl von neuen oder erweiterten Funktionalitäten, deren<br />
Auflistung den Rahmen dieses Papier sprengen würde. Weitere detailreiche Informationen zu <strong>Exchange</strong><br />
<strong>Server</strong> 2007 sind auf der Microsoft Web-Seite http://www.microsoft.com/exchange/preview/default.mspx zu<br />
finden.<br />
Passend zu <strong>Exchange</strong> <strong>Server</strong> 2007 wird auch client-seitig eine überarbeitet Version von Outlook kommen.<br />
Die Web-Seite http://www.microsoft.com/office/preview/programs/outlook/overview.mspx gibt einen Überblick<br />
über Microsoft Office Outlook 2007.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 5 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
<strong>Exchange</strong> Messmethodik<br />
Eine immer wiederkehrende Frage bei der Dimensionierung eines <strong>Server</strong>s ist: »Welche PRIMERGY benötige<br />
ich für N <strong>Exchange</strong> Benutzer?« oder »Wie viele <strong>Exchange</strong> Benutzer kann ein bestimmtes PRIMERGY<br />
Modell bedienen?«.<br />
Diese Frage stellen sich insbesondere Kunden und Vertriebsmitarbeiter, die natürlich das optimale System<br />
suchen. Nicht unterdimensioniert, damit die Leistung stimmt, aber auch nicht überdimensioniert, damit der<br />
Preis stimmt.<br />
Darüber hinaus stellen sich die Techniker zusätzlich die Frage: »Wie konfiguriere ich das System, damit die<br />
optimale Leistung aus der vorhandenen Hardware gezogen werden kann?« Denn so ist es beispielsweise<br />
entscheidend, wie die Festplatten in RAID-Verbänden organisiert werden.<br />
Leider lassen sich die Antworten nicht in einer übersichtlichen Tabelle mit der Anzahl Benutzer in der einen<br />
und dem idealen PRIMERGY System bzw. dessen Konfiguration in der anderen Spalte auflisten, auch wenn<br />
sich das viele wünschen und einige Mitbewerber dies sogar suggerieren. Warum die Antworten auf die doch<br />
scheinbar so simplen Fragen nicht so trivial sind und wie man dennoch auf Basis der Benutzeranzahl auf ein<br />
geeignetes PRIMERGY System schließen kann, wollen wir im Folgenden aufzeigen.<br />
Benutzer Definition<br />
Der schwierigste Punkt in der scheinbar so einfachen Frage »Welche PRIMERGY benötige ich für N<br />
Benutzer?« ist der Benutzer selbst. Auf die Frage »Was ist ein Benutzer?« könnte die Antwort sein: Ein<br />
Mensch der <strong>Exchange</strong> benutzt, also E-Mails verschickt. Ist das alles? Nein, er liest natürlich auch E-Mails ...<br />
und die Ablage, die <strong>Exchange</strong> bietet, wird genutzt ... und Adressen werden verwaltet … und der Kalender<br />
verwendet. Und wie intensiv führt der Benutzer solche Tätigkeiten aus? Abhängig von den täglichen<br />
Anforderungen …<br />
Zusätzlich zu der Frage, wie das Benutzerverhalten hinsichtlich Anzahl und Größe der Mails ist, stellt sich<br />
heute immer mehr die Frage nach der Zugriffsmethode: »Auf welchem Wege greift der Benutzer auf das<br />
Mail-System zu?« Vor einigen Jahren war es typisch, dass zumindest innerhalb einer Organisationseinheit<br />
recht homogene Infrastrukturen anzutreffen waren und meist alle Mitarbeiter einheitlich z.B. mit Outlook<br />
arbeiteten. Durch wachsende Mobilität der Endbenutzer und der wachsenden Vielfalt der Mail-fähigen<br />
Systeme steigt auch die Vielzahl der Protokolle und Zugriffsmechanismen, wie Outlook (MAPI), Internet-<br />
Protokolle (POP3, IMAP4, LDAP), Web-basiert (HTTP) oder über Mobile-Devices (WAP), um nur die<br />
wichtigsten aufzuzählen.<br />
Jetzt könnte man meinen, dies hätte nicht unmittelbar Einfluss auf die Anzahl der Benutzer, welche einen<br />
<strong>Exchange</strong> <strong>Server</strong> bedienen, denn ein Benutzer nutzt ja zu einer Zeit entweder das eine oder das andere<br />
Protokoll, ist also im Endeffekt nur ein Benutzer. Dem ist aber nicht so, denn die Mail-Protokolle sind von<br />
ihrer Kommunikationsart sehr unterschiedlich, so werden beispielsweise bei dem einen Protokoll die Mails in<br />
Gänze verarbeitet, während bei einem anderen Protokoll eine objekt-orientierte Verarbeitung (Sender,<br />
Recipient, Subject, ...) erfolgt.<br />
Dieses unterschiedliche Zugriffsmuster führt dazu, dass die Mail vom <strong>Exchange</strong> <strong>Server</strong> in das jeweils<br />
gewünschte Format konvertiert werden muss. Denn die Information wird nur in einem Format im Information<br />
Store des <strong>Exchange</strong> <strong>Server</strong>s gespeichert. Die durch die Konvertierungen entstehende <strong>Server</strong>belastung ist<br />
zum Teil nicht unerheblich. Mit <strong>Exchange</strong> 2000 <strong>Server</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> hat Microsoft im<br />
Gegensatz zu <strong>Exchange</strong> <strong>Server</strong> 5.5 hier bereits einige Vorkehrungen getroffen, um die Last durch<br />
Konvertierung von Mail-Formaten und Protokollen zu reduzieren. Es wird z.B. für den Internet-basierten<br />
Zugriff ein spezieller Streaming-Cache angelegt, welcher die für MAPI-basierte Zugriffe optimierten<br />
Datenbanken entlastet.<br />
Unser größtes Problem sehen wir bei der Frage: wie plant man den menschlichen Faktor ein? Es gibt nicht<br />
den Benutzer. Ebenso, wie es kleine, große, dicke, dünne Menschen gibt, gibt es Benutzer, die das Medium<br />
Electronic-Mail intensiver oder weniger intensiv verwenden. Dies hängt nicht zuletzt von der jeweiligen<br />
Aufgabe des Anwenders ab. Während der eine vielleicht nur einige wenige kurze Text-Mails pro Tag<br />
versendet, so versendet ein anderer E-Mails mit größeren Anlagen von einigen Megabytes. Der eine liest<br />
eine Mail und löscht sie, der andere Anwender archiviert die Mails in seiner Mailbox, was natürlich in einer<br />
ganz anderen Belastung des <strong>Exchange</strong> <strong>Server</strong>s resultiert.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 6 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Wir haben nun erkannt, dass ein Benutzer nicht gleich Benutzer ist. Aber selbst wenn wir das Benutzerprofil<br />
kennen, stellt sich die Frage, wie viele Benutzer mit einem bestimmten Mail-Verhalten ein <strong>Server</strong>-System<br />
bedienen kann. Eine exakte Antwort hierauf kann aufgrund der vielschichtigen Einflüsse nur durch einen<br />
Test in einer realen Umgebung gefunden werden. Aber dies ist natürlich unmöglich. Annähernd gute<br />
Leistungsaussagen lassen sich aber durch Simulationen gewinnen.<br />
Lastsimulation mit LoadSim <strong>2003</strong><br />
Wie ermittelt man, welche Anzahl von Benutzern ein <strong>Server</strong> bedienen kann? Man probiert es aus. Natürlich<br />
kann dies nicht mit realen Benutzern geschehen, sondern es werden die Benutzer mit Hilfe von Computern,<br />
so genannten Lastgeneratoren, und einer speziellen Software simuliert. Für Microsoft <strong>Exchange</strong> <strong>Server</strong> gibt<br />
es hierzu den Lastsimulator LoadSim.<br />
Der Microsoft <strong>Exchange</strong> <strong>Server</strong> Lastsimulator LoadSim<br />
<strong>2003</strong> (interne Versionsnummer 6.5) ist ein Werkzeug, mit<br />
dem eine Vielzahl von Mail-Benutzern simuliert werden<br />
können. LoadSim kann verwendet werden, um die Leistungsfähigkeit<br />
des Microsoft <strong>Exchange</strong> <strong>Server</strong>s unter verschiedener<br />
Last zu ermitteln. Mit Hilfe von frei definierbaren<br />
Lastprofilen kann das Verhalten des <strong>Server</strong>s<br />
studiert werden. Dabei ermittelt der Lastsimulator<br />
LoadSim einen so genannten Score. Dies ist die mittlere<br />
Antwortzeit, die der Benutzer auf die Quittierung seines<br />
Auftrags warten musste. Hier gilt eine Antwortzeit von 0.2<br />
Sekunden als exzellenter Wert, da dies der natürlichen<br />
Reaktionszeit des Menschen entspricht. Ein Wert von<br />
unter einer Sekunde gilt im Allgemeinen als akzeptabel.<br />
Die Ergebnisse können dann verwendet werden, um die<br />
optimale Anzahl Benutzer pro <strong>Server</strong> zu ermitteln, Perfor-<br />
Active<br />
Directory<br />
Netzwerk<br />
Lastgeneratoren<br />
Steuer-<br />
Konsole<br />
zu vermessender<br />
<strong>Exchange</strong> <strong>Server</strong><br />
mance-Engpässe zu analysieren, sowie die Leistungsfähigkeit einer bestimmten Hardware-Konfiguration zu<br />
bewerten. Für eine eigene Leistungsanalyse können Sie den <strong>Exchange</strong> Lastsimulator LoadSim <strong>2003</strong> auf der<br />
Microsoft Web Seite Downloads for <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> [L9] finden.<br />
Doch auch eine Lastsimulation hat ihre Tücken. Denn sie ist nur so gut wie das definierte Lastprofil. Nur<br />
wenn das Lastprofil mit der Realität übereinstimmt oder ihr sehr nahe kommt, korrelieren die Ergebnisse der<br />
Lastsimulation mit der Leistung im realen Betrieb. Kennt der Kunde sein Lastprofil, so kann in einer kundenspezifischen<br />
Simulation die Leistung einer <strong>Exchange</strong> Lösung recht genau evaluiert werden. Leider ist das<br />
Lastprofil in den seltensten Fällen genau bekannt. Ferner erhält man bei dieser Methode zwar für einen ausgewählten<br />
Kunden genaue Leistungsaussagen, kann aber keine allgemein gültigen Performance-Aussagen<br />
ableiten.<br />
Um allgemeingültige Leistungsmessungen durchführen zu können, müssen einige Vereinheitlichungen vorgenommen<br />
werden. Zum einen muss ein Standardbenutzerprofil gefunden werden, zum anderen muss die<br />
<strong>Exchange</strong> Umgebung idealisiert werden. Beide Annahmen müssen dabei eine möglichst große Bandbreite<br />
der realen Szenarien abdecken.<br />
Damit ist man in der Lage, mit Hilfe einer Lastsimulation sehr gut den Einfluss bestimmter Schlüsselkomponenten,<br />
wie z.B. CPU-Leistung, Arbeitsspeicher, Disk-Subsystem, auf die Leistung des Gesamtsystems<br />
zu ermitteln. Hieraus lässt sich ein Satz von Grundregeln ableiten, welche bei der Dimensionierung<br />
eines <strong>Exchange</strong> <strong>Server</strong>s zu beachten sind. Ferner lassen sich mit einem Standardlastprofil die verschiedenen<br />
Modelle der PRIMERGY Systemfamilie nach einer einheitlichen Methode vermessen, um so<br />
eine Einstufung in gewisse Leistungsklassen vorzunehmen.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 7 (71)<br />
•••
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Benutzerprofile<br />
Das Simulationswerkzeug LoadSim <strong>2003</strong> für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> erlaubt es, beliebige Benutzerprofile zu<br />
erstellen. LoadSim bringt aber auch bereits einige Standardprofile mit. Laut Microsoft hat man diese aus<br />
Analysen bestehender <strong>Exchange</strong> Installationen ermittelt. Da es auch hier offensichtlich schwer war, einen<br />
Standardbenutzer zu ermitteln, hat Microsoft drei Profile - Medium-, Heavy- und Cached-Mode-User -<br />
definiert, sowie ein weiteres viertes Profil MMB3 für reine Benchmarkzwecke.<br />
Alle vier vordefinierten Lastprofile<br />
von LoadSim <strong>2003</strong> verwenden<br />
den gleichen Mix von Mails mit<br />
einer durchschnittlichen Mail-<br />
Größe von 76.8 kB. Wie die<br />
nebenstehende Tabelle zeigt,<br />
unterscheiden sich die Profile in<br />
der Anzahl der Mails pro Mailbox<br />
und in der Anzahl der pro Tag<br />
gesendeten Mails.<br />
Alle weiteren Betrachtungen und<br />
<strong>Sizing</strong> Messungen in diesem White Paper basieren auf dem Medium-Profil, welches die meisten<br />
Einsatzszenarien widerspiegeln dürfte. Das Heavy-Profil mit weit über 200 Mail-Aktivitäten pro User und Tag<br />
dürfte kaum dem Durchschnittsbenutzer entsprechen. Das Cached-Mode-Profil wurde speziell zur<br />
Simulation des neuen Cache-Mode in Outlook <strong>2003</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> entwickelt. Leider ist der<br />
erzeugte Mail-Verkehr mit keinem anderen Standardprofil von LoadSim <strong>2003</strong> vergleichbar, so dass es nicht<br />
für den Vergleich zwischen Cached-Mode und klassischem Outlook herangezogen werden kann. Das Profil<br />
MMB3 ist ausschließlich für Benchmarkzwecke entwickelt worden, wie der Abschnitt Benchmark versus<br />
Realität verdeutlicht.<br />
Evolution der Benutzerprofile<br />
Das Lastsimulationstool LoadSim für MAPI-basierte<br />
Zugriffe steht seit der ersten Version von <strong>Exchange</strong> zur<br />
Verfügung. Über diesen Zeitraum von nunmehr zehn<br />
Jahren war es notwendig das Lastprofil zu ändern, um<br />
dem über die Jahre veränderten Benutzerverhalten und<br />
den wachsenden Funktionalitäten von <strong>Exchange</strong> und<br />
Outlook Rechnung zu tragen. Etwa alle drei Jahre bedurften<br />
die Lastprofile einer Neudefinition, so dass heute<br />
mit LoadSim <strong>2003</strong> die dritte Generation der Lastprofile für<br />
<strong>Exchange</strong> vorliegt.<br />
Mail Anhang Gewichtung in LoadSim<br />
Größe 5.5 2000 <strong>2003</strong><br />
4 kB - 60% 41% 15%<br />
5 kB - 13% 18% 18%<br />
6 kB - 5% 14% 16%<br />
10 kB Excel Objekt 5% - -<br />
14 kB Bitmap Objekt 2% 10% 5%<br />
14 kB Text Datei 5% - -<br />
18 kB Excel Spreadsheet 2% 7% 17%<br />
19 kB Word Dokument 8% 7% 20%<br />
107 kB PowerPoint Präsentation - 1% 5%<br />
1 MB Powerpoint Präsentation - 1% 2%<br />
2 MB Word Dokument - 1% 2%<br />
Durchschnittliche Mailgröße [kB] 5.7 39.2 76.8<br />
Aktivität Profil<br />
Medium Heavy<br />
Cached<br />
Mode<br />
Neue Mails pro Arbeitstag 10 12 7 8<br />
Die nebenstehende Tabelle zeigt, wie sich<br />
über die Jahre das Mail-Volumen zu größeren<br />
mit Anhängen behafteten Mails verschoben<br />
hat. Von 1997 bis 2000 hat sich die Größe<br />
einer Mail etwa versechsfacht. Zum Glück hält<br />
dieser Trend nicht an, und in den letzten<br />
Jahren hat sich die durchschnittliche Mail-<br />
Größe nur verdoppelt. Dies ist allerdings auch<br />
darauf zurückzuführen, dass viele Mail-<br />
<strong>Server</strong>-Betreiber die zulässige Größe von E-<br />
Mails begrenzen.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 8 (71)<br />
MMB3<br />
Reply, Reply All, Forward 20 40 37 56<br />
Durchschnittliche Empfänger pro Mail 4.8 4.0 3.7 2.4<br />
Anzahl empfangener Mails 141 208 162 152<br />
Mailverkehr in MB pro Tag 13 20 15 16<br />
Mailboxgröße in MB 60 112 93 100<br />
<strong>Exchange</strong><br />
Version<br />
Erscheinungsjahr<br />
<strong>Exchange</strong> 4.0 1996<br />
<strong>Exchange</strong> 5.0 1997<br />
<strong>Exchange</strong> 5.5 1997<br />
LoadSim<br />
Version<br />
LoadSim 4.x<br />
<strong>Exchange</strong> 2000 2000 LoadSim 2000<br />
<strong>Exchange</strong> <strong>2003</strong> <strong>2003</strong> LoadSim <strong>2003</strong>
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Nicht nur die durchschnittliche Mail-<br />
Größe ist über die Jahre gewachsen,<br />
sondern auch die Anzahl der Mails, die<br />
versandt werden. Folglich wächst auch<br />
die durchschnittliche Mailbox-Größe.<br />
Da die meisten Mailbox-Betreiber auch<br />
hier limitierend eingreifen und Mailbox-<br />
Limits von typischerweise 100 MB setzen,<br />
liegt die durchschnittliche Mailbox-Größe<br />
heute bei ca. 60 MB.<br />
Neben den wachsenden Mail-Volumina wird LoadSim<br />
auch einem geänderten Benutzerverhalten gerecht,<br />
indem verschiedene Benutzeraktionen in das Lastprofil<br />
einbezogen und simuliert werden. So kamen mit<br />
LoadSim 2000 neben der reinen Simulation von Mails<br />
die Simulation von Zugriffen auf Kalender und Kontakte<br />
hinzu. Mit LoadSim <strong>2003</strong> hält die Simulation von Smart-<br />
Folders und Regeln Einzug in das Lastprofil.<br />
LoadSim 2000 vs. LoadSim <strong>2003</strong><br />
Um dem heutigen Benutzerverhalten Rechnung zu tragen, verwenden auch wir für alle <strong>Sizing</strong>-Messungen<br />
die aktuelle Version von LoadSim <strong>2003</strong> mit dem Medium-Benutzerprofil.<br />
Zwar leidet darunter die Vergleichbarkeit zur Vorgängerversion 3.x dieses <strong>Sizing</strong> <strong>Guide</strong>s, allerdings wäre es<br />
nicht gerechtfertigt, <strong>Sizing</strong>-Aussagen zur Dimensionierung eines <strong>Exchange</strong> <strong>Server</strong>s zu treffen, die auf einem<br />
nicht mehr zeitgemäßen Lastprofil beruhen. Um dennoch einen Eindruck zu erhalten, welche Belastungsunterschiede<br />
sich auf einem <strong>Exchange</strong> <strong>Server</strong> aufgrund eines anderen Lastprofils ergeben, wurde eine<br />
identische Systemkonfiguration sowohl mit dem Lastprofil von LoadSim 2000, welches dem <strong>Sizing</strong> <strong>Guide</strong> 3.x<br />
zugrunde lag, als auch dem<br />
aktuellen LoadSim <strong>2003</strong><br />
Profil, welches diesem <strong>Sizing</strong><br />
<strong>Guide</strong> 4.1 zugrunde liegt,<br />
vermessen.<br />
Die nebenstehende Abbildung<br />
zeigt die prozentualen<br />
Änderungen signifikanter<br />
Performance-Daten. Dabei<br />
wurden die mit dem<br />
Lastprofil von LoadSim 2000<br />
erzielten Messergebnisse auf<br />
100% normiert.<br />
Aktivität Loadsim<br />
5.5 2000 <strong>2003</strong><br />
Neue Mails pro Arbeitstag 4 7 10<br />
Mails mit Anhang 22% 27% 51%<br />
Durchschnittliche Empfänger pro Mail 4.68 3.67 4.78<br />
Durchschnittliche Mail-Größe [kB] 5.72 39.16 76.81<br />
Tägliches Mail-Volumen [MB] 0.45 7.88 12.82<br />
Mailbox-Inhalt [MB] 5 26 60<br />
Aktivität LoadSim<br />
5.5 2000 <strong>2003</strong><br />
Send Mail x x x<br />
Process Inbox x x x<br />
Browse Mail x x x<br />
Free/Busy x x x<br />
Request Meetings x x<br />
Make Appointments x x<br />
Browse Calendar x x<br />
Journal Applications x<br />
Logon/off x<br />
Smart Folders x<br />
Rules x<br />
Browse Contacts x<br />
Create Contact x<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 9 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Benchmark versus Realität<br />
Führt man eine solche Lastsimulation unter normierten Bedingungen durch, so spricht man auch von einem<br />
Benchmark. Ein Benchmark hat üblicherweise den Fokus, eine möglichst große Anzahl an »User pro<br />
<strong>Server</strong>« zu ermitteln. Der Vorteil von solch normierten Bedingungen ist, dass man System- und Herstellerübergreifend<br />
vergleichen kann. Der Nachteil ist, dass jeder Hersteller versucht, das Optimum aus seinem<br />
System bezogen auf den Benchmark herauszuholen, um in Hersteller-übergreifenden Vergleichen möglichst<br />
gut abzuschneiden. Dies führt dazu, dass alle anderen Funktionalitäten, die ein System normalerweise<br />
benötigt, aber von dem Benchmarkreglement nicht zwingend gefordert werden, außer Acht gelassen, ja<br />
bewusst abgeschaltet werden. So bleiben typischerweise Funktionalitäten wie Backup, Virenschutz und<br />
andere <strong>Server</strong>funktionalitäten, wie klassische File- und Print-Funktionalität, oder Wachstumsmöglichkeiten<br />
absolut unberücksichtigt. Selbst Funktionalitäten, die der Ausfallsicherheit eines Systems dienen, wie z.B.<br />
Datenschutz durch RAID 1 oder RAID 5, bleiben unberücksichtigt.<br />
Das führte immer wieder zur Konfusion, wenn mit Benchmarkzahlen die Leistungsfähigkeit eines <strong>Exchange</strong><br />
<strong>Server</strong>s beworben wurde. <strong>Fujitsu</strong> unterscheidet daher, im Gegensatz zu manchem Mitbewerber, immer<br />
bewusst zwischen Benchmark- und <strong>Sizing</strong>-Messungen.<br />
Bei dem MAPI Messaging Benchmark MMB2 unter <strong>Exchange</strong> 2000 <strong>Server</strong> wurden so mehr als 16000<br />
Benutzer auf einem <strong>Server</strong> erreicht. In der Realität ist eine solche hohe Anzahl Benutzer jedoch nicht<br />
erzielbar, vielmehr liegen hier die Benutzerzahlen etwa um den Faktor 4 darunter. Mit dem Nachfolger<br />
MMB3 für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> hat Microsoft versucht, ein Lastprofil zu entwickeln, das niedrigere,<br />
realistischere Benutzerzahlen ermittelt. Aber auch hier werden mit moderner <strong>Server</strong>-Hardware und einem<br />
gegenüber produktiven Umgebungen überdimensionierten Disk-Subsystem bereits wieder 13500 MMB3<br />
Benutzer erreicht. Auch diese Benutzerzahlen liegen etwa um den Faktor 3 über den Benutzerzahlen, die<br />
man im realen Betrieb mit einem <strong>Server</strong> bedienen kann.<br />
Eine Hersteller-übergreifende Sammlung von Ergebnissen des MAPI Messaging Benchmark (MMB) wird von<br />
Microsoft in einer Liste mit MMB3 Ergebnissen [L8] gepflegt.<br />
Dennoch sind Benchmarks ein wichtiges Hilfsmittel zur Ermittlung der Leistungsfähigkeit von Computersystemen,<br />
vorausgesetzt, die Benchmarkergebnisse werden richtig interpretiert. Man darf insbesondere<br />
einen Benchmark nicht mit einer Performance-Messung oder dem realen Einsatz verwechseln. Daher nochmals<br />
die wichtigsten Unterschiede bzw. Merkmale in einer Übersicht:<br />
Benchmark Optimiert auf maximale Leistung, da es ein Hersteller-übergreifender Vergleich<br />
ist.<br />
Performance-Messung Vermessung mehrerer nicht zwingend auf Hochleistung getrimmter, sondern<br />
realitätsnah ausgebauter Systeme in einem simplifizierten Szenario zwecks<br />
Vergleichs untereinander.<br />
Realer Einsatz Reale Szenarien mit mehreren Diensten auf einem <strong>Server</strong> mit zu bewältigenden<br />
Spitzenlasten und Ausnahmesituationen.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 10 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Systemauslastung<br />
Wann ist ein <strong>Exchange</strong> <strong>Server</strong> ausgelastet? Mit dem Performance Monitor von Windows <strong>Server</strong> <strong>2003</strong> lässt<br />
sich mit einer Vielzahl von Zählern (Countern) das System sehr detailliert analysieren. Auch der <strong>Exchange</strong><br />
<strong>Server</strong> stellt noch zusätzliche Zähler zur Verfügung.<br />
Die wichtigsten Zähler, an denen sich das Verhalten des Systems ablesen lässt, sind:<br />
• Der Zähler »Processor / % Processor Time« beschreibt die durchschnittliche CPU-Auslastung. Die<br />
MMB3 Benchmarkregeln schreiben vor, dass der Wert nicht größer als 90% sein darf. Für ein<br />
produktives System ist dies allerdings deutlich zu hoch; je nach Quelle gibt es Empfehlungen, dass die<br />
durchschnittliche CPU-Auslastung dauerhaft nicht über 70% - 80% liegen sollte. In all unseren<br />
Simulationen zur Dimensionierung der PRIMERGY als <strong>Exchange</strong> <strong>Server</strong> haben wir uns ein Limit von<br />
30% gesetzt, so dass auch noch genügend CPU-Leistung neben <strong>Exchange</strong> für andere Aufgaben wie<br />
Viren-Prüfung, Backup o.ä. bleibt.<br />
• Der Zähler »System / Processor Queue Length« ist ein Maß dafür, wie viel Threads auf eine Bearbeitung<br />
durch die CPU warten. Dieser Wert sollte über einen längeren Zeitraum hinweg nicht größer als<br />
die Anzahl logischer CPUs sein.<br />
• Über das Disk-Subsystem gibt der Zähler »Logical Disk / Average Disk Queue Length« Auskunft.<br />
Dieser Zähler sollte nicht größer sein als die Anzahl physikalischer Platten, aus denen das logische<br />
Laufwerk besteht.<br />
• Der <strong>Exchange</strong>-spezifische Zähler »MS<strong>Exchange</strong>IS Mailbox / Send Queue Size« zählt die <strong>Exchange</strong><br />
Objekte, die auf ihre Weiterleitung warten. Das Ziel kann entweder eine lokale Datenbank sein oder ein<br />
anderer Mail-<strong>Server</strong>. Die Send Queue sollte immer unter 500 liegen, über einen längeren Zeitraum<br />
hinweg nicht kontinuierlich anwachsen, und immer mal wieder einen Wert nahe Null erreichen.<br />
• Das Simulationstool LoadSim ermittelt während des Simulationslaufs die Bearbeitungszeit aller<br />
Transaktionen in Millisekunden (ms) und berechnet daraus einen so genannten 95%-Score. Dies ist die<br />
maximale Zeit, die 95% aller Transaktionen benötigt haben. D.h. es gibt Transaktionen, die länger<br />
gedauert haben, aber 95% aller durchgeführten Transaktionen haben weniger als die vom Score<br />
angegebene Zeit benötigt.<br />
• Die MMB3-Regeln schreiben vor, dass der Score < 1000 ms sein muss. Eine Reaktionszeit von 1 s<br />
halten wir für ein produktives System für inakzeptabel. Beispielsweise beim Durchscrollen des<br />
Posteingangs (Inbox) würde dies bedeuten, für jeden neuen Eintrag eine Sekunde warten zu müssen.<br />
Wir haben für die Messungen, welche die Basis für dieses Papier bilden, daher einen maximalen Score<br />
von 200 ms angesetzt.<br />
• Der LoadSim-spezifische Zähler »Loadsim Action / Latency« ist der gewichtete Durchschnitt der<br />
Client-Antwortzeit. Dieser Zähler muss nach MMB3-Regeln ebenfalls kleiner als 1000 ms sein. Analog<br />
zum Score haben wir auch diesen Wert auf 200 ms reduziert.<br />
Darüber hinaus gibt es weitere Performance Counter, die Auskunft über die »Gesundheit« eines <strong>Exchange</strong><br />
<strong>Server</strong>s geben und während eines Simulationslaufs nicht kontinuierlich ansteigen dürfen:<br />
• SMTP <strong>Server</strong>: Categorizer Queue Length<br />
• SMTP <strong>Server</strong>: Local Queue Length<br />
• SMTP <strong>Server</strong>: Remote Queue Length<br />
• Loadsim Global: Task Queue Length<br />
Weitere Informationen zum Performance Monitor und zu anderen Werkzeugen zu Analyse und Überwachung<br />
von <strong>Exchange</strong> <strong>Server</strong>n sind im Kapitel System Analyse Tools zu finden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 11 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Fassen wir dieses Kapitel noch mal in einigen wenigen markanten Sätzen zusammen:<br />
• Eine exakte Leistungsaussage lässt sich nur durch eine kundenspezifische Lastsimulation mit kundenspezifischem<br />
Benutzerprofil realisieren.<br />
• Für die <strong>Server</strong>-Dimensionierung lässt sich durch idealisierte Lastsimulationen eine Reihe von Regeln<br />
ableiten, mit deren Hilfe eine gute Planung möglich ist. Dabei sind diese Regeln nicht als eine Formel<br />
misszuverstehen, es bedarf schon noch der Interpretation der Regeln. So ist die Grundlage, auf denen<br />
die Regeln basieren, an der Realität zu spiegeln. Für die Umsetzung in ein reales Projekt ist es z.B.<br />
erforderlich, die Bedürfnisse der realen Benutzer zu ermitteln und in Relation zu dem in diesem Papier<br />
verwendeten standardisierten Medium-User zu setzen.<br />
• Benchmarkmessungen sind nicht mit Performance-Messungen zu verwechseln oder gleichzusetzen.<br />
Bei Benchmarks wird auf maximale Leistung optimiert. Bei Performance-Messungen, wie sie diesem<br />
Papier zugrunde liegen, sind die untersuchten Systeme für den realen Einsatz konfiguriert.<br />
Die im Folgenden aufgestellten Regeln basieren auf Messungen, welche im PRIMERGY Performance Lab<br />
mit der Lastsimulation LoadSim <strong>2003</strong> und dem Medium-Lastprofil durchgeführt wurden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 12 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
<strong>Exchange</strong> relevante Ressourcen<br />
Nachdem wir in dem vorangegangenem Kapitel erläutert haben, wie ein <strong>Exchange</strong> <strong>Server</strong> vermessen<br />
werden kann, wollen wir in diesem Kapitel die leistungskritischen Komponenten eines <strong>Exchange</strong> <strong>Server</strong>s<br />
analysieren.<br />
<strong>Exchange</strong> Architektur<br />
Wir werden an dieser Stelle einige wichtige Punkte aufzeigen, welche beim Design einer <strong>Exchange</strong><br />
Umgebung berücksichtigt werden sollten. Dieser Abschnitt ist insbesondere für den Leser gedacht, der nicht<br />
mit der Architektur von <strong>Exchange</strong> Umgebungen vertraut ist.<br />
Dezentral verteilt<br />
<strong>Exchange</strong> <strong>Server</strong> ist für ein dezentral verteiltes<br />
Netz aus vielen <strong>Server</strong>n konzipiert.<br />
D.h. ein Konzern, welcher z.B. 200000<br />
Mitarbeiter beschäftigt, wird nicht einen<br />
<strong>Exchange</strong> <strong>Server</strong> für all seine Mitarbeiter<br />
installieren, sondern mehrere - 40, 50 oder gar<br />
100 - <strong>Exchange</strong> <strong>Server</strong>, welche die organisatorische<br />
und geografische Struktur des Unternehmens widerspiegeln.<br />
Dabei lässt sich <strong>Exchange</strong> durchaus weiterhin zentral<br />
und effizient administrieren. Das Ganze sollte derart strukturiert<br />
werden, dass die Zugriffe der Benutzer auf die ihnen zugeordneten<br />
<strong>Exchange</strong> <strong>Server</strong> sowie die Zugriffe aller anderen <strong>Server</strong> innerhalb eines geografischen Standorts über eine<br />
LAN-artige Verbindung erfolgen können. Zwischen den einzelnen Standorten genügen typischerweise WAN-<br />
Verbindungen.<br />
Dieses dezentrale Konzept hat durchaus in der Praxis mehrere Vorteile:<br />
• Die Rechenleistung steht an dem Standort zur Verfügung, an dem der Benutzer sie braucht.<br />
• Fällt ein System aus, so sind nicht alle Benutzer betroffen.<br />
• Daten können repliziert werden, sind also auf mehreren <strong>Server</strong>n verfügbar.<br />
• Verbindungen zu <strong>Exchange</strong> <strong>Server</strong>n an anderen Standorten des Unternehmens und zu weltweiten Mail-<br />
Systemen können redundant ausgelegt werden. Fällt ein <strong>Server</strong> oder eine Verbindung aus, so sucht<br />
sich <strong>Exchange</strong> automatisch eine andere Route, ansonsten wird die günstigste verwendet.<br />
• Das Backup-Datenvolumen beim klassischen Backup (vgl. Kapitel Backup) verteilt sich auf mehrere<br />
<strong>Server</strong>, das Backup kann parallel laufen.<br />
• Benutzergruppen mit stark unterschiedlichen Anforderungen (Mail-Volumen, Datensensibilität, etc.)<br />
können voneinander getrennt werden.<br />
Aber auch Nachteile können aufgezeigt werden:<br />
• An jedem geografischen Standort wird Administrationspersonal für Backup und Hardware-Pflege<br />
benötigt.<br />
• Je nach Grad der geografischen Verteilung ist mehr Hardware, insbesondere für Backup, notwendig.<br />
• Werden viele kleine, im Vergleich zu wenigen großen, <strong>Server</strong>-Systemen eingesetzt, so fallen höhere<br />
Kosten für Software-Lizenzen an.<br />
Konsolidierung<br />
Gerade diese die Total Cost of Ownership (TCO) betreffenden Nachteile der Dezentralisierung führen in<br />
Zeiten sinkender Unternehmensumsätze und schwieriger werdenden Marktbedingungen verstärkt zu dem<br />
Wunsch nach Konsolidierung der <strong>Exchange</strong> Umgebungen.<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> wird diesem Trend zur Konsolidierung gerecht. Dabei wird neben der klassischen<br />
Plattformkonsolidierung (Verwendung von weniger aber dafür größeren <strong>Server</strong>n) auch eine<br />
Standortkonsolidierung ermöglicht. Sinkende Kosten für WAN-Leitungen und intelligentes Client-Side-<br />
Caching, wie es Outlook <strong>2003</strong> bietet, sind Voraussetzung für diesen Konsolidierungsansatz. Wo mit<br />
<strong>Exchange</strong> <strong>Server</strong> 5.5 oder <strong>Exchange</strong> 2000 <strong>Server</strong> noch geografisch verteilte <strong>Server</strong> benötigt wurden,<br />
können nun in vielen Szenarien mit <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> die Anzahl der Standorte reduziert werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 13 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Mehrere größere <strong>Exchange</strong> <strong>Server</strong> an einem Standort bieten wiederum die Möglichkeit, die <strong>Server</strong> in einem<br />
Cluster zusammenzufassen. Somit kann im Falle eines Hardware-Ausfalls eine andere <strong>Server</strong>-Hardware<br />
einspringen. In einem stark dezentralisierten Szenario würde der hierfür notwendige Hardware-Aufwand<br />
nicht gerechtfertigt sein.<br />
Eine moderne auf <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> basierende Infrastruktur wird gegenüber einer <strong>Exchange</strong> <strong>Server</strong><br />
5.5 Umgebung aus wesentlich weniger <strong>Server</strong>n und insbesondere weniger Standorten bestehen. Auch<br />
gegenüber <strong>Exchange</strong> 2000 <strong>Server</strong> ist eine Reduzierung der Standorte denkbar, da mit Hilfe des Cached<br />
Mode von Outlook <strong>2003</strong> und Optimierung der Kommunikation zwischen Outlook <strong>2003</strong> und <strong>Exchange</strong> <strong>Server</strong><br />
<strong>2003</strong> eine wesentliche Reduzierung der benötigten Netzwerkbandbreite erreicht wird.<br />
Dedizierte <strong>Server</strong><br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> bietet neben E-Mail auch eine Menge anderer Komponenten. Daher kann es sinnvoll<br />
sein, verschiedene Aufgaben auf dedizierte <strong>Exchange</strong> <strong>Server</strong> zu verteilen. So wird zwischen folgenden<br />
<strong>Exchange</strong> <strong>Server</strong> Typen unterschieden:<br />
Der Mailbox <strong>Server</strong> – auch häufig Back-end-<strong>Server</strong> genannt - beheimatet die Postfächer der Benutzer<br />
und ist für die Zustellung der Mails zu den Clients unter Verwendung einer Reihe von unterschiedlichen<br />
Protokollen wie MAPI, HTTP, IMAP4 oder POP3 zuständig.<br />
Der Public Folder <strong>Server</strong> ist dediziert für öffentliche Ordner zuständig, welche über Protokolle wie MAPI,<br />
HTTP, HTTP-DAV oder IMAP4 zum Endanwender gebracht werden.<br />
Ein Connector <strong>Server</strong> ist für verschiedene Verbindungen zu anderen <strong>Exchange</strong> Sites oder Mail-<br />
Systemen zuständig. Dabei können Standardprotokolle, wie SMTP (Simple Mail Transfer Protocol) oder<br />
X.400 eingesetzt werden, oder properitäre Konnektoren zu Mail-Systemen, wie Lotus Notes oder Novell<br />
GroupWise. Ein solch dedizierter <strong>Server</strong> sollte dann eingesetzt werden, wenn ein Verbindungstyp sehr<br />
intensiv genutzt wird.<br />
Unter einem Front-end-<strong>Server</strong> versteht man einen <strong>Server</strong>, der mit den Clients spricht und die Anfragen<br />
des Clients an einen Back-end-<strong>Server</strong>, der typischerweise die Postfächer und öffentlichen Ordner<br />
beheimatet, durchreicht. Ein solches gestuftes Szenario aus Front-end- und Back-end-<strong>Server</strong> wird häufig<br />
für Web-basierte Client-Zugriffe -Outlook Web Access (OWA) - realisiert.<br />
Ferner unterscheidet man so genannte Real-Time Collaboration <strong>Server</strong>, sowie Data Conferencing<br />
<strong>Server</strong>, Video Conferencing <strong>Server</strong>, Instant Messaging <strong>Server</strong> und Chat <strong>Server</strong>, die dediziert einen<br />
oder mehrere dieser <strong>Exchange</strong> Komponenten beherbergen. (Hinweis: die in <strong>Exchange</strong> 2000 <strong>Server</strong><br />
enthaltenen Real-Time Collaboration Features sind aus <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> entfernt worden und in<br />
ein dediziertes Microsoft Produkt »Live Communications <strong>Server</strong> <strong>2003</strong>« für Echtzeit-Kommunikation und -<br />
Collaboration eingeflossen.)<br />
Im Folgenden richten wir unser Augenmerk auf den am häufigsten eingesetzten <strong>Exchange</strong> <strong>Server</strong> Typ, den<br />
Mailbox-<strong>Server</strong>, welcher die Postfächer der Benutzer und die öffentlichen Ordner beheimatet.<br />
Active Directory und DNS<br />
<strong>Exchange</strong> 2000 <strong>Server</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> sind komplett in das Windows Active Directory integriert.<br />
Anders als bei früheren <strong>Exchange</strong> Versionen, wie 4.0 und 5.5, sind die Informationen über Mail-User und<br />
Mail-Folder also nicht mehr in <strong>Exchange</strong> integriert, sondern von <strong>Exchange</strong> separiert und in das Active<br />
Directory integriert. Dabei macht <strong>Exchange</strong> intensiv von dem Active Directory und von DNS (Domain Name<br />
System) Gebrauch. Dies muss bei einem Gesamtdesign einer <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Infrastruktur<br />
berücksichtigt werden, d.h. neben <strong>Exchange</strong> <strong>Server</strong>n mit adäquater Leistung braucht man auch Active<br />
Directory <strong>Server</strong> mit hinreichender Leistung, da sonst die <strong>Exchange</strong> Leistung darunter leiden kann. Da Active<br />
Directory typischerweise die organisatorische Struktur eines Unternehmens widerspiegelt, sind bei dem<br />
Design auch organisatorische und geografische Gegebenheiten zu berücksichtigen. Aus Performance-<br />
Gründen sollte, abgesehen von kleinen Installationen im Small-Business-Bereich oder in Zweigstellenbüros,<br />
das Active Directory und <strong>Exchange</strong> nicht auf dem gleichen <strong>Server</strong> installiert werden, da ein Active Directory<br />
nicht unerhebliche Ressourcen benötigt. Während der benötigte Plattenspeicher für das Active Directory<br />
recht moderat ausfällt, so wird für die Verwaltung und die Bearbeitung der Zugriffe auf das Active Directory<br />
doch erhebliche Rechenleistung benötigt.<br />
In größeren <strong>Exchange</strong> Umgebungen sollte der <strong>Exchange</strong> <strong>Server</strong> nicht gleichzeitig die Rolle eines Domain<br />
Controllers übernehmen, sondern es sollten dedizierte Domain Controller verwendet werden. Die<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 14 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Dimensionierung von Domain Controllern ist dabei mindestens ebenso komplex wie die Dimensionierung<br />
von <strong>Exchange</strong> <strong>Server</strong>n. Da es den Rahmen dieses White Papers völlig sprengen würde, kann das Thema<br />
<strong>Sizing</strong> von Active Directory hier nicht weiter diskutiert werden. Unter Windows <strong>Server</strong> <strong>2003</strong> Active Directory<br />
[L17] finden Sie hilfreiche Hinweise zum Design und zur Dimensionierung.<br />
Betriebssystem<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> kann sowohl auf Basis von Windows<br />
<strong>Exchange</strong><br />
2000 <strong>Server</strong> als auch auf Windows <strong>Server</strong> <strong>2003</strong> betrieben<br />
5.5 2000 <strong>2003</strong><br />
werden. Umgekehrt kann ein <strong>Exchange</strong> 2000 <strong>Server</strong> jedoch<br />
nicht auf Windows <strong>Server</strong> <strong>2003</strong> betrieben werden. Die<br />
nebenstehende Tabelle zeigt, welche Version von <strong>Exchange</strong><br />
auf welchem Betriebssystem eingesetzt werden kann. Dabei<br />
ist zu beachten, dass <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ausschließlich<br />
Windows<br />
2000<br />
<strong>2003</strong> 32-bit<br />
<strong>2003</strong> 64-bit<br />
× × ×<br />
×<br />
auf den 32-bit Versionen von Windows läuft. Eine Installation von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> auf einer 64-bit<br />
Version von Windows <strong>Server</strong> <strong>2003</strong> ist nicht möglich. Eine 64-bit Unterstützung wird erst mit der nächsten<br />
Version <strong>Exchange</strong> <strong>Server</strong> 2007 gegeben sein.<br />
Viele neue Funktionalitäten von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> stehen jedoch nur dann zur Verfügung, wenn<br />
<strong>Exchange</strong> auf Basis von Windows <strong>Server</strong> <strong>2003</strong> betrieben wird. Dazu gehören insbesondere Performancerelevante<br />
Features, wie:<br />
• Speicher-Tuning mit /3GB<br />
Der /3GB-Switch steht unter Windows <strong>Server</strong> <strong>2003</strong> auch bereits in der Standard Edition zur Verfügung<br />
und bewirkt eine Verschiebung der Aufteilung des virtuellen Adressraums zu Gunsten der<br />
Anwendungen auf 3:1. Unter Windows 2000 <strong>Server</strong> wurde diese Option erst von dem Advanced <strong>Server</strong><br />
unterstützt.<br />
• Speicher-Tuning mit /USERVA Switch<br />
Der Schalter /USERVA dient dem Fine-Tuning der Speicheraufteilung in Verbindung mit dem /3GB-<br />
Switch. Diese Option erlaubt es dem Betriebssystem, im Kernel-Bereich größere Verwaltungstabellen<br />
anzulegen, wobei der Anwendung trotzdem fast 3 GB virtueller Adressraum bereitgestellt wird.<br />
• Datenbank-Backup mit Volume Shadow Copy Service (VSS)<br />
Diese Funktionalität von Windows <strong>Server</strong> <strong>2003</strong> erlaubt es, im laufenden Betrieb von <strong>Exchange</strong> <strong>Server</strong><br />
<strong>2003</strong> Snapshot-Backups der <strong>Exchange</strong> Datenbanken zu erstellen. Weitere Details sind im Kapitel<br />
Backup beschrieben.<br />
• Unterstützung von 8-Knoten Cluster<br />
Auf Basis von Windows <strong>Server</strong> <strong>2003</strong><br />
Enterprise Edition können Cluster mit bis<br />
zu acht Knoten realisiert werden. Im<br />
Gegensatz zu Windows 2000 <strong>Server</strong>, wo<br />
der Advanced <strong>Server</strong> nur zwei Knoten und<br />
der Datacenter <strong>Server</strong> vier Knoten<br />
unterstützte.<br />
Anzahl<br />
Cluster-Knoten<br />
Windows 2000 Advanced <strong>Server</strong> 2<br />
Windows 2000 Datacenter <strong>Server</strong> 4<br />
Windows <strong>Server</strong> <strong>2003</strong>, Enterprise Edition 8<br />
Windows <strong>Server</strong> <strong>2003</strong>, Datacenter Edition 8<br />
• Unterstützung von Mount Points<br />
Windows <strong>Server</strong> <strong>2003</strong> erlaubt es, Disk-Volumes in ein bestehendes Volume hinzuzufügen, anstelle sie<br />
jeweils mit einem eigenen Laufwerksbuchstaben zu versehen. Damit kann die Grenze, die durch<br />
maximal 26 mögliche Laufwerksbuchstaben gegeben war, überwunden werden, die insbesondere in<br />
geclusterten Umgebungen einen Engpass darstellte.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 15 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Rechenleistung<br />
Es ist klar, je leistungsfähiger der Prozessor, je mehr Prozessoren in einem System, um so schneller werden<br />
Daten verarbeitet. Allerdings ist die CPU-Leistung gerade bei <strong>Exchange</strong> nicht der einzige entscheidende<br />
Faktor. Auch mit relativ kleinem CPU-Ausbau erreicht der Microsoft <strong>Exchange</strong> <strong>Server</strong> akzeptable<br />
Leistungen. Vielmehr ist es wichtig, dass ein schnelles Disk-Subsystem zur Verfügung steht, ein<br />
ausreichender Speicherausbau vorhanden ist und natürlich auch die Netzwerkanbindung keinen<br />
Flaschenhals darstellt. Gerade bei kleinen <strong>Server</strong>-Systemen ist nicht die Prozessorleistung der begrenzende<br />
Faktor, sondern die Ausbaumöglichkeiten des Disk-Subsystems.<br />
Die nebenstehende Grafik kann als Leitfaden für die Anzahl<br />
der Prozessoren dienen. Es gibt keine harten Grenzen, die die<br />
Anzahl der Prozessoren festlegt. Alle Systeme gibt es mit<br />
4<br />
Prozessoren unterschiedlicher Leistung. So kann ein 2-<br />
Prozessor-System mit hoch getakteten dual-core Prozessoren<br />
und großem Cache durchaus in dem Leistungsbereich eines 1<br />
2<br />
schwach bestückten 4-Prozessor-Systems liegen. Welches<br />
System hinsichtlich möglicher Ausbaufähigkeit zum Einsatz<br />
500 1000 2000 3000 4000 Benutzer<br />
kommt, hängt letztendlich auch von den prognostizierten Wachstumsraten des Kunden ab. Ferner kann es<br />
sinnvoll sein, auch bereits bei kleinerer Benutzerzahl ein 2-Prozessor- oder 4-Prozessor-System<br />
einzusetzen, da solche Systeme häufig bessere Ausbaumöglichkeiten für das Disk-Subsystem bieten.<br />
Was die reine Rechenleistung anbelangt, reichen für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> im Allgemeinen 4-Prozessor-<br />
Systeme aus, da bei großen <strong>Exchange</strong> <strong>Server</strong>n nicht die Rechenleistung, sondern die <strong>Exchange</strong>-interne<br />
Speicherverwaltung Grenzen setzt. Es kann jedoch dennoch sinnvoll sein, ein 8-Prozessor-System<br />
einzusetzen, wenn zusätzlich zum reinen <strong>Exchange</strong> <strong>Server</strong> sehr CPU-intensive <strong>Exchange</strong> Erweiterungen<br />
zum Einsatz kommen oder wenn hinsichtlich höherer Verfügbarkeit der Einsatz von Windows <strong>Server</strong> <strong>2003</strong><br />
Datacenter Edition in Erwägung gezogen wird.<br />
Jenseits von ca. 5000 aktiven Benutzern auf einem <strong>Server</strong> skaliert <strong>Exchange</strong> <strong>Server</strong> nicht befriedigend<br />
(siehe Arbeitsspeicher). Es sollte bei großen Benutzerzahlen daher anstelle eines Scale-Up ein Scale-Out<br />
Szenario in Erwägung gezogen werden, bei dem mehrere <strong>Server</strong> in einem logischen Verbund gruppiert<br />
werden, welche dann eine beliebig große Anzahl von Mail-Usern bedienen können.<br />
Arbeitsspeicher<br />
Für den Arbeitsspeicher gilt zunächst eine ganz einfache Regel: je mehr desto besser. Dabei sollte der<br />
Arbeitsspeicher des <strong>Server</strong>s in jedem Fall mindestens so groß sein, dass das System nicht gezwungen ist,<br />
Programmteile aus dem physikalischen Speicher in den virtuellen Speicher auf die Festplatte auszulagern.<br />
Andernfalls würde das System hoffnungslos ausgebremst. Was den Programmcode betrifft, so würden<br />
512 MB im Allgemeinen ausreichen. Das System würde flüssig laufen und kein Programmcode müsste auf<br />
die Festplatte ausgelagert werden.<br />
Steht jedoch mehr Speicher zur Verfügung, so wird er von <strong>Exchange</strong> als Zwischenspeicher (Cache) für die<br />
Daten der <strong>Exchange</strong> Datenbanken, dem so genannten Store, verwendet. Dies bedeutet eine nicht unerhebliche<br />
Entlastung des Disk-Subsystems und somit einen Zugewinn an Performance. Immerhin sind Speicherzugriffe<br />
etwa um den Faktor 1000 schneller als Zugriffe auf die Festplatten.<br />
Doch leider gibt es auch hier Grenzen. Zum einen<br />
ist 4 GB RAM eine magische Grenze. Mehr lässt<br />
sich mit einer 32-bit Adresse nicht adressieren. Es<br />
gibt zwar in Windows 2000 <strong>Server</strong> und Windows<br />
<strong>Server</strong> <strong>2003</strong> Mechanismen, diese Grenze zu<br />
überwinden, die so genannte Physical Address<br />
Extension (PAE). Damit unterstützt Windows je<br />
nach Variante bis zu 128 GB RAM. Hardwaremäßig<br />
wäre es auch problemlos möglich, eine<br />
solche Speichermenge in der PRIMERGY<br />
RX600 S3 oder PRIMERGY RX800 S2<br />
bereitzustellen, allerdings unterstützt Microsoft<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> diese PAE-Adressierungsarten<br />
nicht und ist von der Adressierung her<br />
auf 4 GB RAM begrenzt. Weiterführende Informa-<br />
# CPU RAM<br />
[GB]<br />
/3GB<br />
Support<br />
Windows 2000 4 4 -<br />
Windows 2000 Advanced 8 8 �<br />
Windows 2000 Datacenter 32 32 �<br />
Windows <strong>2003</strong> Standard 4 4 �<br />
Windows <strong>2003</strong> Enterprise 8 32 �<br />
Windows <strong>2003</strong> Datacenter 32 64 �<br />
Windows <strong>2003</strong> Standard SP1 und R2 4 4 �<br />
Windows <strong>2003</strong> Enterprise SP1 und R2 8 64 �<br />
Windows <strong>2003</strong> Datacenter SP1 und R2 64 128 �<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 16 (71)<br />
# CPU
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
tionen zu PAE sind unter Physical Address Extension - PAE Memory and Windows [L18] zu finden.<br />
Eine weitere Reduzierung des nutzbaren Speichers ergibt sich nun aus der Systemarchitektur von Windows.<br />
So wird dieser Adressraum standardmäßig in 2 GB für das Betriebssystem und 2 GB für Anwendungen, zu<br />
denen auch <strong>Exchange</strong> zählt, unterteilt. Mit einem entsprechenden Konfigurationsparameter lässt sich diese<br />
Aufteilung zu Gunsten der Anwendungen auf 1 zu 3 GB verschieben. Es empfiehlt sich, diese so genannte<br />
/3GB Option bereits ab einem physikalischen Speicherausbau von 1 GB RAM zu verwenden. (Zum<br />
Verständnis: diese /3GB-Option bezieht sich auf die Verwaltung virtueller Speicheradressen, nicht auf den<br />
physikalischen Speicher.) Mit Windows <strong>Server</strong> <strong>2003</strong> wurde in Ergänzung zu der /3GB-Option die Option<br />
/USERVA eingeführt, mit der sich die Aufteilung im Verhältnis 3:1 des Adressraums noch detaillierter steuern<br />
lässt.<br />
Die Notwendigkeit des /3GB-Switches für <strong>Exchange</strong> wird klarer unter der Erkenntnis, dass <strong>Exchange</strong><br />
offensichtlich die ca. doppelte Menge virtuellen Adressraums im Verhältnis zum genutzten physikalischen<br />
Adressraum benötigt. Ein Sachverhalt, den Microsoft nur indirekt beschreibt. Aus programmtechnischer Sicht<br />
kann man diesen Effekt erklären und sogar wegen der zugrunde liegenden Methodik als guten oder<br />
zumindest modernen Programmierstil betrachten. Aus der Tatsache heraus, dass sich heute bei 32-bit<br />
Systemen die Grenzen von verfügbaren virtuellen Adressen und physikalisch verfügbarem Speicher<br />
annähern, ja sogar der physikalische Speicher den adressierbaren Speicher übersteigt, stellt diese<br />
Speicherverwaltungsarchitektur allerdings eine (unnötige) Limitierung dar.<br />
Man könnte also vermuten, dass ein 64-bit System das optimale System für <strong>Exchange</strong> sei. Aber die Realität<br />
ist, dass zwar für die interne Speicherverwaltung von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> eine 64-bit Architektur optimal<br />
wäre, aber nicht für die übrigen Komponenten von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong>. So gibt es heute noch keine 64bit<br />
Version von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong>, so dass trotz des aus heutiger Sicht schier unendlichen virtuellen<br />
Speicheradressraums von 8 TB (Terabyte), den ein 64-bit Windows den Anwendungen zur Verfügung stellt,<br />
<strong>Exchange</strong> in der jetzigen Version auf einem 64-bit System nicht schneller laufen würde, sondern eher<br />
langsamer.<br />
Aber zurück zu den heutigen Hardware-Möglichkeiten: Rechnen wir grob: 3 GB virtueller Adressraum für<br />
<strong>Exchange</strong>, von dem maximal die Hälfte physikalisch genutzt werden kann, dies ergibt 1.5 GB. Tatsächlich<br />
hat Microsoft die Cache-Größe für den Store auf ca. 900 MB begrenzt. Diese kann nach einer Beschreibung<br />
von Microsoft auf 1.2 GB erhöht werden. Man beachte: dieser Speicherbedarf ist nur für den Store-Cache.<br />
Natürlich benutzt <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> darüber hinaus noch weiteren Speicher für andere Daten. Mit 2 GB<br />
RAM ist ein <strong>Exchange</strong> <strong>Server</strong> also schon recht gut bestückt. Was über einem Speicherausbau von 3 GB<br />
liegt, wird von <strong>Exchange</strong> nur noch bedingt genutzt. Ein Ausbau mit weiterem Speicher bis 4 GB kann aber<br />
sehr wohl sinnvoll sein, wenn neben <strong>Exchange</strong> weitere Komponenten, wie z.B. Virenscanner oder Fax-<br />
Dienste, hinzukommen.<br />
Neben diesen Überlegungen zum maximal<br />
(sinnvoll) nutzbaren Speicher gibt es auch auf<br />
Erfahrungswerten basierende Richtlinien, welche<br />
einen Speicherausbau auf Benutzerbasis<br />
kalkulieren. Microsoft empfiehlt, pro aktivem<br />
Benutzer 512 kB RAM zu kalkulieren. Geht man<br />
von einem Sockel von 512 MB für das Betriebssystem<br />
und die Kernkomponenten aus, so ergibt<br />
sich nebenstehender linearer Verlauf (untere<br />
Kurve).<br />
RAM = 512 MB + 0.5 MB * [Anzahl Benutzer]<br />
Spiegelt man dies an den oben diskutierten Limitierungen, so kann man auch eine Obergrenze von<br />
Benutzern ablesen, die ein einzelner <strong>Exchange</strong> <strong>Server</strong> bedienen kann: ca. 5000 Benutzer. Dies ist keine<br />
feste Grenze. Es ist keineswegs so, dass der <strong>Exchange</strong> <strong>Server</strong> bei einer höheren Benutzeranzahl<br />
zusammenbricht. Der <strong>Exchange</strong> <strong>Server</strong> wird bei zu hoher Last nur nicht mehr effizient arbeiten können.<br />
Aufgrund von Speichermangel wird das Disk-Subsystem stärker belastet. Durch höhere Durchlaufzeiten wird<br />
letztendlich auch die CPU erhöht belastet. Es müssen mehr Aufträge in Warteschlangen verwaltet werden,<br />
dadurch entsteht aber wiederum ein höherer Verwaltungsaufwand und grösserer Speicherbedarf, was<br />
letztlich wieder zu Lasten des Cache-Speichers geht. So schaukelt sich ein Vorgang auf, so dass letztendlich<br />
alle Benutzer nicht mehr adäquat bedient werden können.<br />
Darüber hinaus haben praktische Erfahrungen gezeigt, dass insbesondere »kleine« Systeme von einem<br />
etwas höheren Speicherausbau (siehe obere Kurve) profitieren.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 17 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Disk-Subsystem<br />
Die praktischen Erfahrungen zeigen, dass häufig <strong>Exchange</strong> Systeme hinsichtlich CPU-Leistung überdimensioniert<br />
werden, aber bezüglich des Disk-Subsystems hoffnungslos unterdimensioniert sind. Somit ist die<br />
Gesamtleistung des Systems völlig unbefriedigend. Daher wollen wir uns intensiv mit dem Thema Disk-<br />
Subsystem beschäftigen. Wir werden in den folgenden Abschnitten sehen, dass häufig nicht die CPU-<br />
Leistung, sondern die Anschlussmöglichkeiten für ein Disk-Subsystem die Systemleistung (in Bezug auf<br />
<strong>Exchange</strong>) bestimmen.<br />
Ein <strong>Exchange</strong> <strong>Server</strong>, welcher primär als Mailbox-<strong>Server</strong> eingesetzt wird, benötigt große Mengen an Speicherplatz,<br />
um die Inhalte der Mailboxen effizient zu verwalten. Im Allgemeinen reichen die internen Festplatten<br />
eines <strong>Server</strong>s nicht aus, und es wird ein externes Disk-Subsystem benötigt. Es gibt heute vier Disk-<br />
Subsystem-Ansätze:<br />
Direct Attached Storage (DAS) bezeichnet eine Speicher-Technologie, bei der die Festplatten direkt an<br />
einen oder mehrere im <strong>Server</strong> eingebaute Festplatten-Controller angeschlossen werden. Typischerweise<br />
wird SCSI, SAS oder SATA in Verbindung mit intelligenten RAID-Controllern eingesetzt. Diese Controller<br />
sind relativ preisgünstig und bieten eine gute Performance. Die Festplatten finden entweder im <strong>Server</strong>-<br />
Gehäuse oder in externen Disk-Gehäusen Platz.<br />
DAS bietet erstklassige Performance und ist bei kleinen und mittleren <strong>Exchange</strong> Installationen eine gute<br />
Wahl. Für große <strong>Exchange</strong> Installationen hat DAS jedoch bezüglich der Skalierung einige<br />
Einschränkungen. Die physikalischen Platten müssen alle direkt an den <strong>Server</strong> per SCSI-Verkabelung<br />
angeschlossen werden. Die Anzahl Festplatten pro SCSI-Bus ist ebenso limitiert wie die Anzahl<br />
möglicher SCSI-Kanäle in einem System. Daraus ergeben sich Grenzen hinsichtlich des maximalen<br />
Ausbaus. Weitere Nachteile eines DAS sind die aufwendige und daher fehleranfällige SCSI-Verkabelung,<br />
sowie die eingeschränkte Cluster-Tauglichkeit. In einem Cluster müssen alle beteiligten <strong>Server</strong> auf einen<br />
gemeinsamen Daten-Pool zugreifen können, dem steht die dedizierte Zuordnung der Platten beim DAS<br />
entgegen.<br />
Unter dem Aspekt dieser Limitierungen erscheinen Netzwerke aus Network Attached Storage (NAS) oder<br />
ein Storage Area Network (SAN) wesentlich attraktiver. Hinter beiden Konzepten steckt die Idee, das<br />
Disk-Subsystem vom <strong>Server</strong> loszulösen und als eigenständige Einheit in einem Netz einem oder<br />
mehreren <strong>Server</strong>n zur Verfügung zu stellen. Umgekehrt kann auch ein <strong>Server</strong> auf mehrere Storage-<br />
Einheiten zugreifen.<br />
Network Attached Storage (NAS) ist im Prinzip ein klassischer File-<strong>Server</strong>. Ein solcher NAS-<strong>Server</strong> ist<br />
auf die effiziente Verwaltung großer Datenmengen spezialisiert und stellt diesen Speicher über ein LAN<br />
anderen <strong>Server</strong>n zur Verfügung. Intern verwenden NAS-<strong>Server</strong> typischerweise wieder die Platten- und<br />
Controller-Technologie des DAS. Für den Datentransport von und zu den <strong>Server</strong>n werden klassische<br />
LAN-Infrastrukturen genutzt. Dadurch können NAS-Systeme recht kostengünstig aufgebaut werden. Da<br />
der Datenspeicher nicht dediziert einem <strong>Server</strong> zugeordnet ist, lässt sich durch den Einsatz vieler NAS-<br />
<strong>Server</strong> eine hohe Skalierbarkeit erreichen.<br />
Für <strong>Exchange</strong> 2000 <strong>Server</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ist eine klassische NAS-Topologie zunächst<br />
einmal ungeeignet. <strong>Exchange</strong> verwendet ein Installable File System (IFS), welches Zugriff auf ein<br />
blockorientiertes Device benötigt. Der IFS-Treiber ist integraler Bestandteil der <strong>Exchange</strong> 200x<br />
Architektur und wird für interne <strong>Exchange</strong> Prozesse verwendet. Wenn eine <strong>Exchange</strong> Datenbank auf<br />
einem nicht blockorientierten Device abgelegt wird, kann die <strong>Exchange</strong> 200x Datenbank nicht gemountet<br />
werden (vgl. Microsoft Knowledge Base Artikel Q317173).<br />
Neben dem klassischen File Sharing via Network File System (NFS) und Common Internet File System<br />
(CIFS) bieten moderne NAS-Systeme aber auch spezielle Disk-Treiber, die das NAS über ein blockorientiertes<br />
Device für Windows 200x sichtbar machen. Ist dies der Fall, so kann auch ein NAS in<br />
Verbindung mit <strong>Exchange</strong> 200x eingesetzt werden.<br />
Storage Area Network (SAN) ist derzeit die Standardtechnologie<br />
in dem stark wachsenden Storage-Markt. Im<br />
Gegensatz zum NAS verwendet SAN nicht das LAN für<br />
den Datentransport, sondern ein eigenes Netz hoher<br />
Bandbreite auf Basis von Fibre-Channel (FC). Die bei<br />
NAS notwendige Umsetzung von LAN-Protokoll zu SCSI<br />
entfällt bei Fibre-Channel, da Fibre-Channel wie SCSI<br />
Kupfer Glasfaser<br />
MMF SMF<br />
62.5 µm 50 µm 9 µm<br />
1 GB FC 10 m 175 m 500 m 10 km<br />
2 GB FC - 90 m 300 m 2 km<br />
4 GB FC - 45 m 150 m 1 km<br />
das gleiche Datenprotokoll verwendet. Fibre-Channel unterliegt dabei jedoch nicht den physikalischen<br />
SCSI-Restriktionen. So sind im Gegensatz zu SCSI, wo die Kabellänge auf 25 Meter begrenzt ist, Kabel-<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 18 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
längen bis zu 10 Kilometer möglich, abhängig vom Kabelmedium und von der Bandbreite. Auch hinsichtlich<br />
der Device-Anzahl offeriert Fibre-Channel einen weitaus größeren Spielraum. Im Gegensatz zu<br />
maximal 15 Devices an einem SCSI-Kanal ermöglicht Fibre-Channel in einer sogenannten Arbitrated<br />
Loop (FC-AL) bis zu 126 Geräte und auch diese Grenze lässt sich durch den Einsatz von Fibre-Channel-<br />
Switches überwinden. Bei einem Storage Area Network werden alle <strong>Server</strong> und die Storage-Systeme<br />
miteinander verbunden und können so auf einen großen Daten-Pool zugreifen. Somit ist ein SAN ideal für<br />
Cluster-Lösungen, bei denen sich mehrere <strong>Server</strong> die gleichen Speicherbereiche teilen, um bei Ausfall<br />
eines <strong>Server</strong>s die Aufgabe des ausgefallenen <strong>Server</strong>s zu übernehmen. Ein SAN ist eine ideale Lösung<br />
für große bzw. geclusterte <strong>Exchange</strong> <strong>Server</strong> Installationen.<br />
Internet small computer system interface (iSCSI), durch die »Internet Engineering Task Force« (IETF)<br />
als RFC3270 beschrieben, gewinnt neben Fibre-Channel (FC) mit seiner komplett eigenen Infrastruktur<br />
immer mehr an Bedeutung. Hinter diesem Konzept steckt die Idee, das Disk-Subsystem vom <strong>Server</strong><br />
loszulösen und als eigenständige Einheit in einem Netz einem oder mehreren <strong>Server</strong>n zur Verfügung zu<br />
stellen. Umgekehrt kann auch ein <strong>Server</strong> auf mehrere Storage-Einheiten zugreifen. Im Gegensatz zu den<br />
meisten Network Attached Storage (NAS) Produkten, welche über ein LAN die aus der Microsoft Welt bekannten<br />
Protokolle <strong>Server</strong> Message Block (SMB) bzw. Common Internet File System (CIFS) oder das<br />
aus dem UNIX / Linux bekannte Network File System (NFS) zur Verfügung stellen, werden sowohl durch<br />
iSCSI als auch durch Fibre-Channel im <strong>Server</strong> blockorientierte Geräte (Block-Devices) zur Verfügung gestellt.<br />
Einige Anwendungen, z.B. <strong>Exchange</strong> <strong>Server</strong>, benötigen für ihre Datenablage Block-Device-Schnittstellen.<br />
Für diese Anwendungen ist es nicht erkennbar, ob sie auf ein direkt angeschlossenes Platten-<br />
Subsystem zugreifen oder ob sich die Daten irgendwo im Netzwerk befinden. Im Unterschied zu Fibre-<br />
Channel mit seiner aufwändigen Infrastruktur mit speziellen Controllern (Host Bus Adaptern oder HBA),<br />
eigener Verkabelung, eigenen Switches und auch eigenem Management greift iSCSI auf die von TCP/IP<br />
bekannte Infrastruktur zurück – daher auch die Bezeichnung »IP-SAN«. Durch die Nutzung vorhandener<br />
Infrastrukturen sind die Einstiegskosten bei iSCSI niedriger als im Fibre-Channel Umfeld. Siehe auch<br />
Performance Report iSCSI and iSCSI Boot [L4].<br />
Transaktionsprinzip<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> arbeitet transaktionsorientiert und legt alle Daten in Datenbanken, dem so<br />
genannten Store ab. <strong>Exchange</strong> 2000 <strong>Server</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> unterstützen bis zu 20 separate<br />
Datenbanken, die in vier so genannten Storage-Groups je maximal fünf Datenbanken strukturiert werden<br />
können. Pro Storage-Group wird ein gemeinsames Transaktions-Log-File geschrieben. Diese Architektur<br />
bringt gegenüber <strong>Exchange</strong> <strong>Server</strong> 5.5 mit nur einer Storage-Group und Datenbank einige Vorteile und<br />
überwindet somit Limitierungen. Hier einige der wichtigsten Vorteile, die für unsere Dimensionierungsbetrachtungen<br />
von Interesse sind:<br />
• Eine Datenbank kann sich nur über ein logisches Volume erstrecken. Die Volume-Größe ist durch das<br />
Disk-Subsystem begrenzt. So können bei vielen RAID-Controllern nur maximal 32 Disks zu einem<br />
Volume zusammengefasst werden. Durch den Einsatz mehrerer Datenbanken kann diese Limitierung<br />
überwunden werden.<br />
• Pro Storage-Group ist ein Backup-Prozess möglich, dadurch kann der Backup-Prozess durch die<br />
Verwendung mehrerer Storage-Groups parallelisiert und somit zeitlich optimiert werden. Voraussetzung<br />
hierfür ist natürlich eine adäquate Backup-Hardware.<br />
• Unter dem Aspekt der Verfügbarkeit, sind die Zeiten für den Restore einer Datenbank nach deren Verlust<br />
kritisch. Durch die Aufteilung in mehrere Datenbanken kann diese Restore-Zeit reduziert werden.<br />
• Sensible Daten können durch den Einsatz verschiedener Datenbanken und Storage-Groups physikalisch<br />
voneinander getrennt werden. Dies ist besonders dann von Interesse, wenn ein ASP (Application<br />
Service Provider) mehrere Kunden auf einem <strong>Exchange</strong> <strong>Server</strong> bedienen möchte.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 19 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Zugriffsmuster<br />
Bei der Verwaltung der Datenbanken entstehen zwei völlig komplementäre Zugriffsmuster auf die Daten.<br />
Zum einen die Datenbanken mit einem 100 prozentigen wahlfreien (random) Zugriff. Typischerweise sind<br />
das 2/3 lesende und 1/3 schreibende Zugriffe. Zum anderen entsteht durch die Transaktions-Log-Files ein<br />
Datenstrom, der zu 100% sequentiell geschrieben wird. Um dem gerecht zu werden, empfiehlt es sich, die<br />
Datenbanken und Log-Files auf unterschiedliche physikalische Platten zu verteilen. Und noch ein zweiter<br />
Aspekt für die räumliche Trennung von Log-Files und Datenbanken: Bei dem Transaktionskonzept werden<br />
alle Änderungen an den Datenbanken in den Log-Files protokolliert. Gehen die Datenbanken verloren, so<br />
kann unter Zuhilfenahme eines Backups und der Log-Files seit der Erstellung des Backups der<br />
Datenbestand komplett restauriert werden. Um ein Maximum an Sicherheit zu erlangen, ist es sinnvoll, die<br />
Log-Files und die Datenbanken auf unterschiedliche physikalische Festplatten abzulegen, so dass im Falle<br />
eines Platten-Crashes nicht alle Daten verloren gehen. Solange nur eine der beiden Informationen verloren<br />
geht, lässt sich die fehlende Information restaurieren. Dies gilt insbesondere für kleine <strong>Exchange</strong><br />
Installationen, wo man aufgrund einer geringen Anzahl Festplatten verleitet wird, beide Informationen auf<br />
einem Datenträger abzulegen.<br />
Caches<br />
Bei einem intelligenten SCSI-Controller mit eigenen Cache-Mechanismen gibt es Möglichkeiten, mit denen<br />
das Disk-Subsystem an die Anforderungen des <strong>Exchange</strong> <strong>Server</strong>s angepasst werden kann. So sollte für das<br />
Volume, auf dem die Log-Files liegen, der Write-Back-Cache eingeschaltet sein. Auch Read-Ahead-Caches<br />
sollten für die Log-Files eingeschaltet sein, dies bringt beim Restore, bei dem die Log-Files gelesen werden<br />
müssen, Vorteile. Gleiches gilt für das Volume, auf denen Queues (SMTP- oder MTA-Queues) abgelegt<br />
werden.<br />
Bei dem Volume, auf dem der Store abgelegt wird, ist es jedoch nicht sinnvoll, den Read-Ahead-Cache zu<br />
aktivieren. Das klingt erst mal unlogisch, dass man einen Cache, der ja der Beschleunigung der Zugriffe<br />
dient, abschaltet. Bei dem Store handelt es sich jedoch um viele Gigabyte große Datenbanken, auf die<br />
wahlfrei (random) in Häppchen von 4 kB zugegriffen wird. Die Wahrscheinlichkeit, dass dabei in einem<br />
Cache von wenigen MB Größe ein 4 kB Block aus einer ‟zig GB großen Datenmenge angetroffen wird und<br />
nicht von der Platte gelesen werden muss, ist sehr unwahrscheinlich. Bei einigen Controllern kann leider der<br />
Lese-Cache nicht unabhängig vom Schreib-Cache abgeschaltet werden und auch beim Lesen wird erst mal<br />
nachgesehen, ob die angeforderten Daten im Cache stehen. In diesem Fall erlangt man einen besseren<br />
Gesamtdurchsatz, indem man ausgenommen bei RAID 5, den Cache ganz abschaltet, da die Lesezugriffe<br />
typischerweise doppelt so häufig sind wie die Schreibzugriffe.<br />
Daneben bietet auch jede einzelne Festplatte Schreib- und Lese-Caches. Der Lese-Cache ist standardmäßig<br />
immer aktiviert. Über die Aktivierung des Schreib-Caches wird viel diskutiert, denn im Gegensatz zu<br />
den Schreib-Caches der RAID-Controller ist dieser Cache nicht Batterie-gepuffert. Unter der Vorraussetzung,<br />
dass der <strong>Server</strong> (und natürlich auch das Disk-Subsystem) USV-gesichert ist, ist es sinnvoll, die<br />
Schreib-Caches der Festplatte einzuschalten. Alle Festplatten von <strong>Fujitsu</strong> werden aus Sicherheitsgründen<br />
mit ausgeschalteten Schreib-Caches geliefert. Einige unserer Mitbewerber liefern ihre Festplatten mit<br />
eingeschalteten Schreib-Caches aus, so dass bei vergleichenden Teststellungen solche Systeme auf den<br />
ersten Blick performanter erscheinen. Ist ein System jedoch nicht gegen Stromausfälle mit einer USV<br />
gesichert, oder wird es abrupt ausgeschaltet, so kann es bei eingeschalteten Schreib-Caches der Festplatten<br />
zu Datenverlusten kommen.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 20 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
RAID-Level<br />
Eine der fehleranfälligsten Komponenten eines<br />
Computersystems ist die Festplatte. Es ist ein<br />
mechanisches Teil und wird insbesondere bei<br />
Datenbank-basierten Anwendungen, zu denen<br />
auch <strong>Exchange</strong> zählt, extensiv genutzt. Daher<br />
ist es wichtig, gegen den Ausfall einer solchen<br />
Komponente gefeit zu sein. Hierfür gibt es<br />
Methoden, mehrere Festplatten in einem<br />
Verbund derart zu arrangieren, so dass der<br />
Ausfall einer Festplatte verkraftet werden kann.<br />
Man nennt dies Redundant Array of<br />
Independent Disks oder kurz RAID.<br />
Im Folgenden zunächst einen kurzen Überblick<br />
über die wichtigsten RAID-Levels. Die jeweilige<br />
Abbildung verdeutlicht, wie die Blöcke eines<br />
Datenstroms<br />
A B C D E F ...<br />
auf den einzelnen Platten organisiert werden.<br />
RAID 0 Der RAID-Level 0 wird auch als »Non-Redundant Striped<br />
Array« bezeichnet. Bei einem RAID 0 werden zwei oder<br />
mehr Festplatten zusammengeschaltet, ausschließlich mit<br />
dem Ziel, die Schreib-Lese-Geschwindigkeit zu erhöhen.<br />
Die Daten werden in kleine Blöcke mit einer Größe von 4<br />
bis 128 kB aufgeteilt, so genannte Stripes, und abwechselnd<br />
auf den Platten gespeichert. So kann auf mehrere<br />
Platten gleichzeitig zugegriffen werden, was die Geschwindigkeit erhöht. Da bei RAID 0 keine<br />
redundanten Informationen erzeugt werden, gehen alle Daten im RAID 0-Verband verloren,<br />
wenn auch nur eine Festplatte ausfällt. RAID 0 bietet den schnellsten und effizientesten Zugriff,<br />
ist aber nur für Daten geeignet, welche sich jederzeit unproblematisch regenerieren lassen.<br />
RAID 1 Bei einem RAID 1, auch »Drive Duplexing« oder »Mirroring« genannt,<br />
werden auf zwei Festplatten identische Daten gespeichert. Es ergibt sich<br />
damit eine Redundanz von 100%. Ferner kann durch alternierendes<br />
Zugreifen die Lese-Performance erhöht werden. Fällt eine der beiden<br />
Festplatten aus, so arbeitet das System mit der verbleibenden Festplatte<br />
ungestört weiter. RAID 1 ist die erste Wahl in Performance-kritischen,<br />
fehlertoleranten Umgebungen. Außerdem gibt es zu RAID 1 keine Alter-<br />
native, wenn Fehlertoleranz gefordert, aber nicht mehr als zwei Platten gewünscht sind bzw. zur<br />
Verfügung stehen. Die hohe Ausfallsicherheit hat allerdings ihren Preis, denn es wird die doppelte<br />
Anzahl Festplatten benötigt.<br />
RAID 5 Bei einem RAID 5-Verband werden mindestens drei Festplatten<br />
benötigt. Ähnlich wie bei RAID 0 wird der Datenstrom<br />
in Blöcke unterteilt. Über die einzelnen Blöcke wird<br />
eine Parity-Information gebildet und diese zusätzlich zu den<br />
Daten auf dem RAID-Verband abgelegt, wobei die Information<br />
selbst und die Parity-Information immer auf zwei<br />
verschiedenen Festplatten geschrieben werden. Fällt eine<br />
RAID 0<br />
Festplatte aus, so kann mit Hilfe der verbleibenden Parity-Information eine Restaurierung der<br />
Daten vorgenommen werden. Der durch die zusätzliche Parity-Information entstehende<br />
Verschnitt sinkt mit der Anzahl verwendeter Festplatten und beträgt 1 /Anzahl Platten. Eine einfache<br />
Daumenregel ist »eine Platte Verschnitt« pro RAID 5-Verband. RAID 5 bietet Redundanz und<br />
haushaltet am besten mit den Plattenressourcen. Allerdings kostet die Parity-Bildung<br />
Performance. Selbst spezielle RAID-Controller können dies nicht ausgleichen.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 21 (71)<br />
A<br />
E<br />
I<br />
RAID 5<br />
A<br />
D<br />
G<br />
B<br />
F<br />
J<br />
B<br />
E<br />
P(GHI)<br />
C<br />
G<br />
K<br />
RAID 1<br />
A<br />
B<br />
C<br />
C<br />
P(DEF)<br />
H<br />
D<br />
H<br />
L<br />
A’<br />
B’<br />
C’<br />
P(ABC)<br />
F<br />
I
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
RAID 1+0 Auch gelegentlich RAID 10 genannt. Dabei handelt<br />
es sich eigentlich nicht um einen eigenen RAID-<br />
Level, sondern lediglich um die Kombination von<br />
RAID 1 mit RAID 0. Damit werden die Eigenschaften<br />
der beiden Basis-Level - Sicherheit und sequentielle<br />
Performance - vereinigt. Bei RAID 1+0 wird eine<br />
gerade Anzahl von Festplatten verwendet. Es<br />
werden jeweils zwei Platten zusammengefasst und<br />
die Daten gespiegelt (RAID 1). Über diese Platten-<br />
Pärchen werden dann die Daten verteilt (RAID 0).<br />
RAID 1+0 eignet sich insbesondere zur redundanten<br />
Speicherung von großen Dateien. Da hierbei keine Parität berechnet werden muss, sind die<br />
Schreibzugriffe mit RAID 1+0 sehr schnell.<br />
RAID 0+1 Neben der RAID-Level-Kombination 1+0 gibt es auch<br />
die Kombination 0+1. Dabei wird über die Hälfte der<br />
Festplatten ein RAID 0-Verband gebildet und die<br />
Informationen anschließend auf die andere Hälfte<br />
gespiegelt (RAID 1). Hinsichtlich der Performance ist<br />
RAID 0+1 und 1+0 identisch. Jedoch hat RAID 1+0<br />
eine höhere Verfügbarkeit als RAID 0+1. Fällt bei<br />
einem RAID 0+1 eine Platte aus, so liegt keine<br />
Redundanz mehr vor. Bei einem RAID 1+0 können<br />
jedoch weitere Platten ausfallen, solange davon nicht<br />
das gleiche RAID 1-Pärchen betroffen ist. Dabei ist<br />
RAID 1+0<br />
RAID 0<br />
die Wahrscheinlichkeit, dass bei einem RAID 1+0 aus n Platten, beide Platten eines RAID 1-<br />
Pärchen ausfallen mit 2 /(n²-n) wesentlich geringer, als die Wahrscheinlichkeit, dass zwei Platten,<br />
die nicht zu einem Pärchen gehören betroffen sind (2n-4) /(n²-n).<br />
weitere Es gibt eine Reihe weiterer RAID-Levels, die zum Teil heute nicht mehr gebräuchlich sind<br />
oder weitere Kombinationen, wie z.B. RAID 5+0.<br />
Weitere Informationen zu den verschiedenen RAID-Levels sind im White Paper Performance Report -<br />
Modular RAID [L5] zu finden.<br />
Bei allen RAID-Levels ist darauf zu achten, dass Festplatten gleicher Kapazität und gleicher Leistung verwendet<br />
werden. Ansonsten bestimmt die kleinste Festplatte die Gesamtkapazität bzw. die langsamste Festplatte<br />
die Gesamt-Performance. Die Performance des RAID-Verbands wird einerseits durch den verwendeten<br />
RAID-Level, aber auch durch die Anzahl der Platten in einem Verband bestimmt. Auch die RAID-<br />
Controller selbst zeigen<br />
insbesondere bei komplexeren<br />
RAID-Algorithmen wie<br />
RAID 5 unterschiedliche Leistungen.<br />
Letztendlich haben<br />
auch die Parameter, welche<br />
beim Anlegen des RAID-Verbandes<br />
festzulegen sind, z.B.<br />
Stripe-Size, Einfluss auf die<br />
Leistungsfähigkeit eines<br />
RAID-Verbandes. Die nebenstehende<br />
Grafik zeigt die<br />
relative Leistung verschiedener<br />
RAID-Verbände.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 22 (71)<br />
A<br />
E<br />
A’<br />
E’<br />
RAID 0+1<br />
A<br />
E<br />
A’<br />
E’<br />
B<br />
F<br />
B’<br />
F’<br />
B<br />
F<br />
B’<br />
F’<br />
RAID 0<br />
C<br />
G<br />
C’<br />
G’<br />
C<br />
G<br />
C’<br />
G’<br />
D<br />
H<br />
D’<br />
H’<br />
D<br />
H<br />
D’<br />
H’<br />
RAID 1<br />
RAID 1
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Datendurchsatz<br />
Aktuelle SCSI-RAID-Controller bieten pro SCSI-Kanal einen Datendurchsatz von 320 MB/s. Dies ist für<br />
Datenbank-orientierte Anwendungen mehr als ausreichend, auch wenn sieben oder mehr Festplatten an<br />
einem Kanal betrieben werden. Fälschlicherweise wird häufig hinsichtlich der Plattenanzahl an einem SCSI-<br />
Kanal die maximale Datentransferrate des SCSI-Busses durch die Peak-Datentransferrate der Festplatte<br />
dividiert. Diese kann bei schnellen Festplatten durchaus bei über 80 MB/s liegen, wonach ein SCSI-Bus<br />
dann mit vier Festplatten bereits ausgelastet wäre. Aber diese Rechnung ist falsch, da sie nur für eine<br />
theoretische Extremsituation gilt. Die nebenstehende Grafik zeigt die reale Situation. Dabei ist zu sehen,<br />
dass nur bei rein sequentiellem Lesen mit großen Datenblöcken, wie es bei Video-Streaming vorkommt,<br />
annähernd die theoretische<br />
Kurve erreicht werden<br />
kann. Kommen noch schreibende<br />
Anteile hinzu, so<br />
bricht der Datendurchsatz<br />
deutlich ein. Bei einem<br />
Random-Zugriff, mit Blockgrößen<br />
von 4 und 8 kB, wie<br />
er bei einem Zugriff auf die<br />
<strong>Exchange</strong> Datenbanken<br />
vorliegt, beträgt der Durchsatz<br />
gerade noch ca.<br />
10 MB/s. Dies bedeutet,<br />
dass man problemlos die<br />
maximal mögliche Anzahl<br />
von Festplatten an einem<br />
SCSI-Bus betreiben kann.<br />
SCSI-RAID-Controller bieten bis zu vier SCSI-Busse.<br />
Dadurch addiert sich im Prinzip der mögliche Datendurchsatz.<br />
Es ist daher wichtig, dass solche Controller<br />
auch in einem adäquaten PCI-Slot verwendet werden.<br />
Die nebenstehende Tabelle zeigt die verschiedenen PCI-<br />
Bus-Geschwindigkeiten und die darüber ermittelten<br />
Durchsätze. Die Datendurchsatzraten hängen dabei aber<br />
auch von dem Typ und der Anzahl der eingesetzten<br />
Controller, sowie ferner von dem Memory-Interface<br />
(Chip-Satz) des <strong>Server</strong>s ab.<br />
Um die Harmonisierung von Controller-Typ und deren<br />
Anzahl mit dem <strong>Server</strong> sicherzustellen, werden diese bei<br />
<strong>Fujitsu</strong> jeweils für die einzelnen Systeme getestet und<br />
zertifiziert. Der System-Konfigurator legt dabei fest,<br />
welche und wie viele Controller pro System sinnvoll<br />
eingesetzt werden können.<br />
PCI Bus Durchsatz in MB/s<br />
theoretisch gemessen<br />
PCI 33 MHz, 32-bit 133 82<br />
PCI 33 MHz, 64-bit 266 184<br />
PCI-X 66 MHz, 64-bit 533 330<br />
PCI-X 100 MHz, 64-bit 800 n/a<br />
PCI-X 133 MHz, 64-bit 1066 n/a<br />
PCI-E 2500 MHz, 1× 313 250<br />
PCI-E 2500 MHz, 2× 625 500<br />
PCI-E 2500 MHz, 4× 1250 1000<br />
PCI-E 2500 MHz, 8× 2500 2000<br />
PCI-E 2500 MHz, 16× 5000 4000<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 23 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Festplatten<br />
Einen großen Einfluss auf die Performance hat die Geschwindigkeit der Festplatte. Neben der mittleren<br />
Zugriffszeit ist hier insbesondere die Umdrehungsgeschwindigkeit eine wichtige Kenngröße. Je schneller die<br />
Platte rotiert, umso schneller können die Daten einer ganzen Spur transferiert werden. Aber auch die<br />
Datendichte der Platte hat hierauf Einfluss. Je dichter die Daten auf der Platte stehen, d.h. je mehr Daten in<br />
eine Spur gepackt werden können, umso mehr Daten können pro Umdrehung und ohne neue Positionierung<br />
der Köpfe transferiert werden.<br />
Im SCSI- und SAS-Umfeld werden<br />
ausschließlich Platten im oberen<br />
Leistungssegment angeboten. So<br />
werden keine Festplatten mehr mit<br />
weniger als 10000 rpm (Umdre-<br />
Typ<br />
2½" SATA<br />
3½"<br />
rpm<br />
7200<br />
7200<br />
36 60<br />
×<br />
73<br />
Kapazität [GB]<br />
80 100 146 160 250 300 500<br />
×<br />
× × × ×<br />
hungen pro Minute) und einer 2½" SAS 10000 × ×<br />
Seek-Time (Positionierzeit) größer 3½" SCSI 10000 × × × ×<br />
als 6 ms angeboten. Die nebenstehende<br />
Tabelle zeigt die derzeit<br />
3½" 15000 × × ×<br />
verfügbaren Plattentypen. Es ist zu erwarten, dass in naher Zukunft Festplatten mit noch größeren Kapazitäten<br />
kommen werden.<br />
Die Umdrehungszahl der Festplatte spiegelt sich direkt in der Anzahl Schreib-Lese-<br />
Aufträge wieder, die eine Platte pro Zeiteinheit abarbeiten kann. Kennt man die<br />
Anzahl I/O-Aufträge, die eine Anwendung pro Sekunde produziert, so kann man die<br />
Anzahl der Festplatten, die man mindestens benötigt damit kein Engpass entsteht,<br />
5400 rpm<br />
7200 rpm<br />
IO/s<br />
62<br />
75<br />
ausrechnen. Eine Festplatte mit 15 krpm zeigt im Gegensatz zu einer Platte mit 10000 rpm 120<br />
10 krpm je nach Zugriffsmuster, insbesondere bei random Zugriffen mit kleinen<br />
Blockgrößen wie sie bei <strong>Exchange</strong> Datenbanken auftreten, eine bis zu 40% höhere<br />
15000 rpm 170<br />
Leistung. Bei sequentiellen Zugriffen mit großen Blockgrößen, die bei Backup- und Restore-Prozessen<br />
auftreten, relativiert sich der Vorteil von 15 krpm Festplatten auf 10% bis 12%.<br />
Ferner spielt die Anzahl der Festplatten in einem RAID-Verband eine große Rolle. So sind beispielsweise<br />
acht 36 GB Platten in einem RAID 1+0 wesentlich schneller als zwei 146 GB Platten, obwohl sich daraus die<br />
gleiche nutzbare Kapazität ergibt. Es bedarf also der Kalkulation zwischen der Anzahl verfügbarer<br />
Einbauplätze für Festplatten, der benötigten Plattenkapazität, aber auch letztendlich der Kosten. Aus<br />
Performance-Sicht gilt die Regel: Lieber mehr kleine als wenige große Festplatten.<br />
Stresst man <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> mit<br />
dem Medium-Lastprofil von LoadSim<br />
<strong>2003</strong>, so entstehen für die <strong>Exchange</strong><br />
Datenbanken 0.6 I/Os pro Sekunde<br />
und Benutzer. Die nebenstehende<br />
Tabelle zeigt die benötigte Anzahl an<br />
Festplatten in Abhängigkeit der<br />
Benutzeranzahl, Plattenumdrehungszahl<br />
und RAID-Level. Dabei wird<br />
berücksichtigt, dass schreibende<br />
Zugriffe bei einem RAID 10 zwei und<br />
bei einem RAID 5 bis zu vier I/O-<br />
Anzahl<br />
Benutzer<br />
Operationen benötigen. Legt man ferner das für <strong>Exchange</strong> typische Datenbank-Zugriffsprofil mit 2 /3 lesenden<br />
und 1 /3 schreibenden Zugriffen zugrunde, so berechnet sich die I/O-Rate für ein RAID 10 nach der Formel<br />
und die I/O-Rate für ein RAID 5 nach der Formel<br />
IO/s RAID 10 RAID 5<br />
# IO # Disks # IO # Disks<br />
10 krpm 15 krpm 10 krpm 15 krpm<br />
50 30 40 2 2 60 3 3<br />
100 60 80 2 2 120 3 3<br />
500 300 400 4 4 600 5 4<br />
1000 600 800 8 6 1200 10 8<br />
2000 1200 1600 14 10 2400 20 15<br />
3000 1800 2400 20 16 3600 30 22<br />
4000 2400 3200 28 20 4800 40 29<br />
5000 3000 4000 34 24 6000 50 36<br />
Man beachte dabei jedoch, dass die tatsächlich benötigte Anzahl vom Benutzerverhalten abhängig ist: ein<br />
anderes Benutzerprofil kann eine andere I/O-Last initiieren.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 24 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
In punkto Datensicherheit sind die Log-Files wesentlich wichtiger als die Datenbanken selbst. Der Grund<br />
besteht darin, dass die Log-Files alle Änderungen seit dem letzten Backup festhalten. Man sollte die Log-<br />
Files also durch ein RAID 1 (Spiegelplatte) oder RAID 5 (Stripe Set mit Parity) schützen. Aus Performance-<br />
Gründen empfiehlt sich ein RAID 1 bzw. RAID 1+0. Da die Log-Files beim Backup automatisch gelöscht<br />
werden, fallen bei regelmäßigen Backups keine allzu großen Datenmengen an.<br />
Theoretisch bedürften die Datenbanken bezüglich eines Datenverlustes keines weiteren Schutzes. Man<br />
könnte hier ohne RAID oder aus Performance-Gründen mit einem RAID 0 (Stripe Set) arbeiten. Allerdings ist<br />
für die Praxis davon dringend abzuraten. Im Falle eines Festplattenausfalls würde dies den Ausfall des<br />
<strong>Exchange</strong> <strong>Server</strong>s bedeuten, bis die<br />
Platte ausgetauscht, das letzte Backup<br />
eingespielt und die zurückgespielte<br />
Datenbank mit den Log-Files synchronisiert<br />
ist. Je nach Datenbankgröße<br />
kann dies Stunden oder auch einen<br />
ganzen Arbeitstag bedeuten. Dies ist bei<br />
einem immer zentraler werdenden<br />
Medium wie E-Mail nicht praktikabel. Für<br />
die Datenbanken sollte man ein RAID 5<br />
oder RAID 1+0 einsetzen. Aus Performance-Sicht<br />
ist ein RAID 1+0 zu<br />
empfehlen. Kostendruck bzw. maximaler<br />
Plattenausbau erfordern aber häufig das<br />
Ausweichen auf RAID 5. Bei kleinen<br />
<strong>Exchange</strong> Implementierungen, bei denen<br />
Leistung nicht im Vordergrund steht, ist<br />
RAID 5 ein guter Kompromiss zwischen<br />
Leistung und Kosten.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 25 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Speicherplatz<br />
Wir haben nun intensiv über verschiedene Typen und die Leistung der einzelnen Komponenten des Disk-<br />
Subsystems gesprochen, bleibt noch die nicht unerhebliche Frage: Wie viel Speicherplatz benötigt man für<br />
welche Anzahl von Benutzern? Hier ergibt sich wieder das klassische Problem des Benutzerverhaltens.<br />
Werden von den Benutzern alle Mails zentral auf dem <strong>Exchange</strong> <strong>Server</strong> oder werden die Mails lokal unter<br />
Outlook in Privat-Stores (PST) verwaltet? Wie groß sind die einzelnen Mails typischerweise? Ja selbst der<br />
verwendete Client, Outlook, Outlook-Express, oder Web-basierter Zugriff über Web-Browser, hat Einfluss auf<br />
den vom <strong>Exchange</strong> <strong>Server</strong> benötigten Speicherplatz.<br />
Liegen hier keine Vorgaben des Kunden vor, so kann man einen nicht gerade untätigen, moderat aktiven<br />
Outlook-Benutzer zugrunde legen, der seine Mails auf dem <strong>Exchange</strong> <strong>Server</strong> verwaltet. Hierfür ist 100 MB<br />
pro Benutzer bzw. Mailbox eine recht praktikable Größe. Rechnet man dann noch mal 100% hinzu, damit<br />
noch Platz für Wachstum ist und <strong>Exchange</strong> ausreichend Freiraum zum Arbeiten hat, so ist dies ein recht<br />
guter Wert. Die folgende Tabelle zeigt den Plattenbedarf für die Datenbanken. Bei der Berechnung ist zu<br />
beachten, dass eine 36 GB Platte nur eine Netto-Kapazität von 34 GB hat. Entsprechend 68 GB netto für die<br />
73 GB, 136 GB bei der 146 GB und 286 GB bei der 300 GB Platte. Bei der RAID 5 Berechnung wurde eine<br />
Package-Größe von maximal 7 Platten zu Grunde gelegt. Aus Performance-Sicht wäre es empfehlenswert,<br />
eine Package-Größe<br />
von 4 oder 5 zu wählen.<br />
Dabei steigt jedoch<br />
der Festplattenbedarf<br />
um 6% bzw.<br />
11%. Wie bereits erwähnt,<br />
sollte man aus<br />
Performance-Sicht<br />
jedoch auf RAID 5<br />
verzichten und einen<br />
RAID 1+0-Verband<br />
vorziehen.<br />
Benutzer mit<br />
100 MB<br />
Mailbox<br />
GB<br />
Netto<br />
Neben den Festplatten für die Datenbank(en) mit den Benutzer-Mailboxen ist auch noch Plattenbedarf für<br />
Öffentliche Ordner zu berücksichtigen.<br />
Ferner werden noch Festplatten für die<br />
Log-Files benötigt. Der Umfang der Log-<br />
Files hängt einerseits von der Benutzeraktivität,<br />
andererseits von den Backup-<br />
Zyklen ab. Nach einem Backup werden<br />
die Log-Files gelöscht. Für die Log-Files<br />
sollte ein RAID 1 bzw. RAID 1+0 verwendet<br />
werden. Die nebenstehende<br />
Tabelle zeigt den Plattenbedarf für drei<br />
Tage bei einer Log-File-Größe von 6 MB<br />
pro User und Tag.<br />
Logs pro<br />
Benutzer und<br />
Tag [MB]<br />
Anzahl Disks bei RAID 1+0 Anzahl Disks bei RAID 5<br />
36 GB 73 GB 146 GB 300 GB 36 GB 73 GB 146 GB 300 GB<br />
50 10 2 2 2 2 3 3 3 3<br />
100 20 2 2 2 2 3 3 3 3<br />
500 100 6 4 2 2 4 3 3 3<br />
1000 200 12 6 4 2 7 4 3 3<br />
2000 400 24 12 6 4 14 7 4 3<br />
3000 600 36 18 10 6 20 11 6 3<br />
4000 800 48 24 12 6 28 14 7 4<br />
5000 1000 60 30 16 8 35 18 10 5<br />
Anzahl<br />
Tage<br />
6 3<br />
Anzahl<br />
Benutzer<br />
Log-File<br />
GB<br />
Netto<br />
Anzahl Disks<br />
RAID 1+0<br />
36 GB 73 GB 146 GB<br />
50 1 2 2 2<br />
100 2 2 2 2<br />
500 9 2 2 2<br />
1000 18 2 2 2<br />
2000 36 4 2 2<br />
3000 54 4 2 2<br />
4000 72 6 4 2<br />
5000 90 6 4 2<br />
Neben dem Plattenbedarf für die Datenbanken<br />
und Log-Files benötigt <strong>Exchange</strong> noch Speicherplatz für Warteschlangen (Queues). Queues können<br />
auftreten, wenn Mails nicht unmittelbar zugestellt werden können, z.B. wenn andere Mail-<strong>Server</strong> nicht<br />
erreichbar sind, oder eine Datenbank wegen eines Restores offline ist. Queues werden typischerweise<br />
sequentiell geschrieben und gelesen. Es sollte hierfür ebenfalls separater Plattenplatz bereitgestellt werden.<br />
Das Datenvolumen hier kann analog zu dem Log-File-Bedarf aus dem durchschnittlichen Mail-Volumen pro<br />
Benutzer und der voraussichtlichen maximalen Ausfallzeit der die Queue verursachenden Komponenten<br />
abgeschätzt werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 26 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Netzwerk<br />
Einen wichtigen Performance-Faktor stellt die Qualität des Netzwerkes dar. So wirkt sich z.B. ein überlastetes<br />
Ethernet-Segment, auf dem viele Kollisionen auftreten, nicht unerheblich auf die Performance aus. Es<br />
empfiehlt sich, den <strong>Exchange</strong> <strong>Server</strong> je nach Datenvolumen über ein 100 Mbit Ethernet oder ein Gigabit<br />
Ethernet an das Backbone anzuschließen.<br />
Wird das Backup nicht dediziert am <strong>Server</strong>, sondern zentral über das Netzwerk durchgeführt, so sollte die<br />
entsprechende Bandbreite berücksichtigt werden. Bei einem Online-Backup – welches die empfohlene<br />
Backup-Methode ist, siehe Kapitel Backup – liefert das <strong>Exchange</strong> Backup-API einen Datendurchsatz von ca.<br />
70 GB/h, das entspricht ungefähr 200 Mbit/s.<br />
Für einen Benutzer, wie der durch das Medium-Profil (siehe Kapitel Benutzerprofile) beschriebene, ist mit<br />
einem durchschnittlichen Datenvolumen von 5 kbit/s/User zu rechnen. Neben dem reinen Datenvolumen ist<br />
zu berücksichtigen, dass je nach verwendetem Protokoll das Netzwerk unterschiedlich belastet wird. So<br />
induziert das MAPI-Protokoll viele kleine Netzwerk-Pakete, welche das Netz stärker belasten als wenige<br />
große, wie sie beim IMAP-Protokoll auftreten.<br />
Hochverfügbarkeit<br />
Bei großen <strong>Exchange</strong> <strong>Server</strong> Installationen spielt die Verfügbarkeit eine große Rolle. Wenn mehrere 1000<br />
Benutzer von einem einzigen <strong>Server</strong> abhängig sind, so können unkontrollierte Ausfallzeiten großen Schaden<br />
verursachen. Hier empfiehlt es sich die Verfügbarkeit durch eine Cluster-Lösung, wie sie die Windows<br />
Cluster Services von Windows <strong>Server</strong> <strong>2003</strong> Enterprise Edition und Windows <strong>Server</strong> <strong>2003</strong> Datacenter Edition<br />
bieten, einzusetzen. Für solche Cluster gelten ganz andere Restriktionen hinsichtlich Disk-Subsystem und<br />
Rechenleistung.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 27 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Backup<br />
Backup ist eine der wichtigsten Komponenten zur Sicherung<br />
der Datenbestände. Man könnte geneigt sein, das Backup<br />
hinsichtlich hochverfügbarer Hardware-Ressourcen und<br />
gespiegelter Datenbestände zu vernachlässigen. Jedoch<br />
zeigen Studien, dass nur ca. 10% der Ursachen für Datenverluste<br />
auf Hardware und Umwelteinflüsse zurückzuführen<br />
sind. Die übrigen 90% teilen sich etwa zur Hälfte in Datenverluste<br />
durch Software-Probleme, wie Programmfehler,<br />
Systemabstürze und Viren, sowie Datenverluste durch sorglosen<br />
Umgang mit den Daten durch Benutzer und Administratoren.<br />
Durch präventive Maßnahmen lässt sich ein Teil der möglichen<br />
Ursachen reduzieren: Die Hardware-bedingten Ursachen für Datenverluste können durch eine<br />
exzellente Hardware-Ausstattung, wie sie <strong>Fujitsu</strong> bietet, abgefangen werden. Selbst um Naturkatastrophen<br />
begegnen zu können bietet <strong>Fujitsu</strong> eine desaster-tolerante Hardware-Plattform für <strong>Exchange</strong> <strong>Server</strong> an.<br />
Gegen Datenverluste durch Viren sollte unbedingt auf jedem <strong>Exchange</strong> <strong>Server</strong> ein guter Viren-Scanner<br />
eingesetzt werden. Datenverlust durch sorglosen Umgang lässt sich bei einem <strong>Exchange</strong> <strong>Server</strong> durch<br />
entsprechende Schulung der Administratoren reduzieren. Aber dennoch bleibt immer noch ein großes<br />
Potential an möglichen Datenverlusten durch Programmfehler, Systemabstürze oder menschliches<br />
Versagen. Hier hilft nur Vorbeugung durch zuverlässige Backup-Hardware und sorgfältige Planung der<br />
Backup-Strategie.<br />
Eine Maßnahme zur Vermeidung von Datenverlusten durch Programmfehler und Systemabstürze ist das<br />
von <strong>Exchange</strong> verwendete Transaktionsdatenbankkonzept, welches bereits im Abschnitt Transaktionsprinzip<br />
erläutert wurde. Dabei werden alle Änderungen an den Datenbanken in so genannten Log-Files protokolliert.<br />
Die Log-Files, welche ausschließlich sequentiell geschrieben werden, sind gegen logische Fehler durch<br />
Programmfehler, wie sie bei permanent random gelesenen und geschriebenen Datenbanken mit komplexen<br />
Datenstrukturen auftreten können, weitgehend gefeit. Darüber hinaus ist das Datenvolumen der Log-Files<br />
gegenüber den Datenbanken recht gering, so dass Fehler in den Log-Files statistisch wesentlich geringer<br />
sind.<br />
Dieses Transaktionsprinzip bedingt aber dennoch ein regelmäßiges Backup, da ansonsten das Fortschreiben<br />
aller Änderungen an den Datenbanken auf Dauer beliebig viel Speicherplatz beanspruchen<br />
würde. Bei einem Online-Backup von <strong>Exchange</strong> werden nach erfolgreichem Backup einer Datenbank die<br />
Log-Files automatisch von <strong>Exchange</strong> gelöscht. Sollte die Datenbank<br />
verloren gehen, kann mit Hilfe eines Backups und den<br />
Log-Files, die seit dem letzten Backup geschrieben wurden, die<br />
Datenbank mit allen Daten zum Zeitpunkt des Datenbankverlustes<br />
wiederhergestellt werden. <strong>Exchange</strong> pflegt nach dem<br />
Restore einer Datenbank die Log-Files mit allen Änderungen<br />
seit dem Backup automatisch wieder ein.<br />
Backup<br />
Quelle: Micro International<br />
+ =<br />
Aktuelle<br />
Datenbank<br />
Alle <strong>Exchange</strong> <strong>Server</strong> Versionen bieten die Möglichkeit, ein so genanntes Online-Backup im laufenden<br />
Betrieb durchzuführen. Somit kann der Datenbestand von <strong>Exchange</strong> gesichert werden während alle Dienste<br />
von <strong>Exchange</strong> uneingeschränkt – von Performance-Verlusten abgesehen – zur Verfügung stehen. Daneben<br />
ist es natürlich möglich, ein so genanntes Offline-Backup durchzuführen, allerdings ist dies keine adäquate<br />
Methode, da hierbei während der Backup-Zeit die <strong>Exchange</strong> Dienste nicht zur Verfügung stehen, die zu<br />
sichernde Datenmenge größer ist, da die Datenbank-Dateien im Ganzen und nicht logisch gesichert werden,<br />
keine Prüfung der Daten stattfindet und die Log-Files nicht automatisch bereinigt werden. Der wesentliche<br />
Nachteil eines Offline-Backups aber besteht darin, dass bei einem Restore nicht die Log-Files, die seit der<br />
Erstellung des Backups angefallen sind, zurückgespielt werden können.<br />
Die Wahl eines geeigneten Backup-Mediums und geeigneter Backup-Software hat durchaus einen nicht<br />
unerheblichen Einfluss auf die Verfügbarkeit des <strong>Exchange</strong> <strong>Server</strong>s. Während das Backup im laufenden<br />
Betrieb von <strong>Exchange</strong> durchgeführt werden kann, und somit die Dauer eines Backups nicht unmittelbar<br />
kritisch ist, so ist insbesondere die Dauer des Restores für die Verfügbarkeit entscheidend. Denn im<br />
Gegensatz zum Backup stehen während des Restores die <strong>Exchange</strong> Dienste nicht uneingeschränkt zur<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 28 (71)<br />
Logs
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Verfügung. Daher ist bei der Auswahl einer Backup-Lösung – Hardware und Software – neben der<br />
Zuverlässigkeit vor allem auf die Geschwindigkeit zu achten.<br />
<strong>Exchange</strong> <strong>Server</strong> selbst beinhaltet einige Features, die einem schnellen Backup und Restore entgegenkommen.<br />
Ab <strong>Exchange</strong> 2000 <strong>Server</strong> werden mehrere Datenbanken und Storage-Groups unterstützt.<br />
Storage-Groups können parallel gesichert und Datenbanken können einzeln restauriert werden. Im Falle<br />
eines Restores sind dann nur die Benutzer betroffen, deren Daten in der wiederherzustellenden Datenbank<br />
liegen. Alle anderen Benutzer können, abgesehen von eventuellen Performance-Einbußen, uneingeschränkt<br />
die <strong>Exchange</strong> Dienste nutzen.<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> bietet in Verbindung mit Windows <strong>Server</strong> <strong>2003</strong> eine weitere Neuerung, den so<br />
genannten Volume Shadow Copy Service (VSS), der die Zeit für ein Backup wesentlich verkürzt. Dabei ist<br />
die Storage-Technologie VSS im Wesentlichen eine Novität von Windows <strong>Server</strong> <strong>2003</strong>. Neu mit <strong>Exchange</strong><br />
<strong>Server</strong> <strong>2003</strong> ist die Unterstützung dieser von Windows <strong>Server</strong> <strong>2003</strong> bereitgestellten Funktionalität. Dies<br />
bedeutet, dass VSS für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> nur dann zur Verfügung steht, wenn <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
in Kombination mit Windows <strong>Server</strong> <strong>2003</strong> eingesetzt wird.<br />
Mit VSS bietet Microsoft eine Windows-eigene und einheitliche Schnittstelle für Shadow-Copies, häufig auch<br />
Snapshot-Backups genannt. Snapshot-Backups sind nichts Neues, viele Storage-Systeme unterstützen<br />
solche Backups seit langem und es existieren auch verschiedene Third-Party-Software-Lösungen, um mit<br />
Unterstützung solcher Storage-Systeme auch von <strong>Exchange</strong> Datenbanken Snapshot-Backups durchführen<br />
zu können. Nun gibt es aber eine von Microsoft unterstützte, vereinheitlichte und vom Disk-Subsystem<br />
unabhängige Schnittstelle. Bewusst liegt die Betonung auf Schnittstelle oder wie es Microsoft in Englisch<br />
ausdrückt: Framework.<br />
Diesem Framework müssen nun die Hersteller von intelligenten Storage-Systemen und Backup-Lösungen<br />
ihre Produkte anpassen. Auch Anwendungen müssen angepasst werden, wollen sie VSS-fähig sein und<br />
Snapshot-Backups unterstützen. <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ist bereits eine solche VSS-fähige Anwendung.<br />
Das VSS-Framework besteht im Wesentlichen aus drei Teilen:<br />
• Der Requestor ist eine Software, die ein Snapshot initiiert. Typischerweise ist das eine Backup-<br />
Software. Bezüglich des Microsoft-eigenen Backup-Tools »ntbackup.exe«, das mit Windows <strong>Server</strong><br />
<strong>2003</strong>, bzw. in einer erweiterten Variante mit <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> mitgeliefert wird, ist zu erwähnen,<br />
dass es keinen VSS-Requestor darstellt, mit dem Snapshots von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> erstellt werden<br />
können. Bezüglich <strong>Exchange</strong> sind damit lediglich die klassischen Online-Backups möglich.<br />
• Der Writer ist eine Komponente, die jede VSS-fähige Applikation bereitstellen muss. Dabei muss der<br />
Writer auf die applikationsspezifische Daten-<br />
Architektur abgestimmt sein. Im Falle von<br />
<strong>Exchange</strong> muss der Writer sicherstellen, dass<br />
gemäß dem <strong>Exchange</strong> zugrunde liegenden<br />
Transaktionsdatenbankprinzip konsistente<br />
Datenbankzustände geschaffen werden und<br />
dass in der Zeit des eigentlichen Snapshots<br />
keine Änderungen an den Daten vorgenommen<br />
werden. Darüber hinaus muss der Writer<br />
auch Metadaten über die zu sichernden<br />
Daten bereitstellen. Im Falle von <strong>Exchange</strong><br />
beispielsweise kann sich ein Satz<br />
konsistenter Daten über verschiedene<br />
Volumes erstrecken, die gemeinsam<br />
gesichert werden müssen.<br />
• Der VSS Provider führt das eigentliche<br />
Snapshot aus. Der Provider wird in der Regel<br />
von den Storage-Herstellern bereitgestellt,<br />
deren Storage-Systeme interne Mechanismen<br />
für Cloning bieten. Windows <strong>Server</strong> <strong>2003</strong><br />
beinhaltet einen Software-basierten Provider,<br />
der mit der Copy-on-Write Methode arbeitet.<br />
SQL-<strong>Server</strong><br />
VSS Writer<br />
<strong>Exchange</strong><br />
VSS Writer<br />
VSS Writer<br />
VSS<br />
Provider<br />
VSS<br />
Framework<br />
VSS<br />
Provider<br />
VSS<br />
VSS Requestor<br />
Requestor<br />
VSS<br />
Provider<br />
Es können mehrere VSS Requestoren und mehrere VSS-<br />
Provider für verschiedene Volumes nebeneinander existieren.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 29 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Der Vorteil des VSS-Frameworks besteht darin, dass Komponenten unterschiedlicher Software- und<br />
Hardware-Hersteller nun miteinander harmonieren. Insbesondere in größeren Rechenzentren, wo verschiedene<br />
Hardware und Anwendungen eingesetzt werden, kann nun beispielsweise unabhängig vom Storage-<br />
Hersteller das Backup mit einer einheitlichen Software koordiniert werden und es werden keine Sonderlösungen<br />
mehr benötigt, um den Bedürfnissen von beispielsweise datenbankbasierten Anwendungen<br />
gerecht zu werden.<br />
Backup-Hardware<br />
Bei der Wahl des Backup-Mediums ist darauf zu achten, dass die Datenbanken in adäquater Zeit gesichert<br />
werden können. Da ein Online-Backup Performance-Einbußen für die Anwender bedeutet, sollte ein Backup<br />
in den typischerweise nutzungsgeringeren Nachtstunden durchgeführt werden können. In dieser Zeit sind<br />
neben dem Backup aber auch Datenbank-Maintenance, wie Garbage-Collection und Online-Defragmentierung,<br />
angesiedelt. Dabei sollte zunächst die Garbage-Collection, dann die Online-Defragmentierung und<br />
anschließend das Backup ablaufen. Durch die Garbage-Collection wird die zu sichernde Datenmenge<br />
geringer und durch die Defragmentierung finden die anschließenden<br />
Datenbankzugriffe während des Backups<br />
schneller statt. Bei der Auswahl des Backup-Mediums<br />
spielt die Datentransferrate aber auch das Fassungsvermögen<br />
eines einzelnen Backup-Mediums eine Rolle.<br />
Es ist zwar möglich ein Backup auf Festplatte, Magneto<br />
Optical Disk (MO), CD-RW oder DVD-RW durchzuführen,<br />
wegen der Datenmenge kommen jedoch typischerweise<br />
Bänder zum Einsatz.<br />
Das Backup-Medium sollte, wenn keine anderen Prämissen,<br />
wie etwa vorhandene Backup-Strukturen vorliegen, so gewählt werden, dass ein Backup und Restore<br />
sowohl in einer akzeptablen Zeit ausführbar ist als auch auf eine überschaubare Menge von Bändern passt.<br />
In jedem Fall sollte das Backup-Device so gewählt werden, dass ein Backup ohne Operator-Eingriff<br />
durchgeführt werden kann, also ohne dass ein Administrator während des Backups oder Restore Bänder<br />
wechseln muss. Für größere Datenmengen, wo ein Medium nicht ausreichend ist, gibt es so genannte Tape-<br />
Libraries, welche automatisch die Bänder wechseln, sowie Geräte, die mit mehreren Laufwerken parallel auf<br />
mehrere Bänder schreiben, ähnlich einem von Festplatten her bekannten RAID 0 (Striping), um so den<br />
Datendurchsatz zu erhöhen. Die folgende Tabelle zeigt eine kleine Auswahl von Tape-Libraries.<br />
Library<br />
Technik<br />
Technik<br />
maximaler<br />
Datendurchsatz<br />
Kapazität/Band<br />
ohne Kompr.<br />
[MB/s] [GB/h] [GB]<br />
DDS Gen5 3 10 36<br />
VXA-2 6 21 80<br />
VXA-320 12 42 160<br />
LTO2 24(35) 105(123) 200<br />
LTO3 80 281 400<br />
Anzahl theoretischer<br />
Datendurchsatz<br />
Kapazität total<br />
ohne Kompr.<br />
Drives Bänder [GB/h] [TB]<br />
VXA-2 PackerLoader VXA-2 1 10 21 0.8<br />
FibreCAT TX10 VXA-320 1 10 42 1.6<br />
FibreCAT TX24 LTO2, LTO3 1 - 2 12 / 24 123 - 281 2.4- 9.6<br />
MBK 9084 LTO2, LTO3 1 - 2 10 - 21 123 - 281 2.0 - 8.4<br />
Scalar i500 LTO2, LTO3 1 - 18 36 - 402 123 - 5058 7.2 - 160<br />
Scalar i2000 LTO2, LTO3 1 - 96 100 - 3492 123 - 26976 20 - 1396<br />
Scalar 10k LTO2, LTO3 1 - 324 700 - 9582 123 - 91044 789 - 3832<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 30 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Backup-Dauer<br />
Die Berechnung der Backup-Dauer ist nicht ganz so trivial. Theoretisch ergibt sie sich aus Datenmenge<br />
dividiert durch die Datentransferrate. Dabei kann jedoch nicht die für die Band-Technologie angegebene<br />
maximale Datentransferrate zugrunde gelegt werden. Die effektive Datentransferrate wird durch weitere<br />
Faktoren bestimmt.<br />
Zunächst müssen die Datenmengen bereitgestellt werden. Dabei spielt die Leistung des Disk-Subsystems,<br />
auf dem die Datenbanken abgelegt sind, aber auch CPU-Leistung, Größe des Arbeitsspeichers und<br />
letztendlich sogar <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> selbst eine Rolle. Bei einem Online-Backup muss <strong>Exchange</strong> über<br />
das so genannte Backup-API alle Daten bereitstellen. Dabei werden 64 kB große Datenbankblöcke gelesen,<br />
verifiziert und an die Backup-Software übergeben. Microsoft gibt für das <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Backup-API<br />
einen Durchsatz von ca. 70 GB/h an.<br />
Eine weitere Limitierung des Datendurchsatzes ergibt sich durch eine technische Eigenschaft von Bandlaufwerken.<br />
Bänder sind schnellere Streaming-Devices als Platten, aber sie werden dramatisch langsam, wenn<br />
die Daten nicht kontinuierlich und in ausreichender Menge bereitgestellt werden. Werden die Daten langsamer<br />
oder nicht gleichmäßig bereitgestellt, so kann das Band nicht mehr im so genannten Streaming-Mode<br />
beschrieben werden, sondern geht in den Start-Stop-Betrieb über. Dabei wird das Band gestoppt, wenn<br />
keine Daten anstehen. Stehen wieder ausreichend Daten an, wird das Band wieder gestartet. Bei manchen<br />
Aufzeichnungsverfahren muss das Band sogar ein kleines Stück zurückgespult werden. Das kostet Zeit und<br />
die Schreibgeschwindigkeit sinkt. Wie stark dieser Effekt ausgeprägt ist, hängt von der verwendeten Aufzeichnungstechnik,<br />
von Cache-Fähigkeiten des Backup-Laufwerks, aber auch von der verwendeten Backup-<br />
Software ab. Je besser die Backup-Software mit den Eigenschafen des Backup-Laufswerks bekannt und<br />
darauf zugeschnitten ist, umso höher ist die effektive Datentransferrate.<br />
Einen weiteren Einfluss auf die effektive Datentransferrate hat die Komprimierung der Daten. Alle Backup-<br />
Laufwerke unterstützen eine Datenkomprimierung. Diese wird nicht von der Backup-Software oder dem<br />
Treiber für das Bandlaufwerk, sondern von der Firmware des Bandlaufwerks selbst durchgeführt. Je nach<br />
Komprimierungsfähigkeit der Daten kann dabei die Schreibgeschwindigkeit steigen. Dadurch kann der effek-<br />
tive Datendurchsatz sogar über dem maximalen<br />
Datendurchsatz des Backup-Mediums liegen.<br />
Die nebenstehende Tabelle zeigt effektive Datendurchsatzraten.<br />
Dabei wurde jeweils ein Online-<br />
Backup einer 50 GB großen <strong>Exchange</strong> Datenbank<br />
von einem hinreichend schnellen Disk-Subsystem<br />
mit dem Windows-eigenen Backup-Programm<br />
durchgeführt.<br />
Technik<br />
maximaler<br />
Datendurchsatz<br />
effektiver<br />
Datendurchsatz<br />
Gesamtdauer<br />
[MB/s] [GB/h] [MB/s] [GB/h] [h]<br />
DDS Gen5 3 10 4.8 16.8 3:10<br />
VXA-2 6 21 7.5 26.3 1:45<br />
VXA-320 12 42 15.0 52.7 1:00<br />
LTO2 30 105 47.0 165.2 0:18<br />
LTO3 80 281 105.0 369.1 0:08<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 31 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Backup-Lösungen für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
Als Backup-Software kann wahlweise das Windows-eigene Backup oder ein 3 rd -Party Produkt, welches das<br />
<strong>Exchange</strong> API unterstützt, wie z.B. BrightStor ARCserve von Computer Associates oder NetWorker von<br />
EMC Legato, eingesetzt werden. 3 rd -Party Produkte bieten gegenüber dem Windows-eigenen Backup<br />
zusätzliche Funktionen, wie die Unterstützung von Tape-Libraries, Backup einzelner Mailboxen oder gar<br />
einzelner Mails oder Folder. Beim Backup einzelner Mailboxen oder Folder ist jedoch zu beachten, dass der<br />
Datendurchsatz wesentlich<br />
geringer, nur ca. 20%<br />
im Vergleich zum Online-<br />
Backup ganzer <strong>Exchange</strong><br />
Datenbanken, ist.<br />
Mit Windows <strong>Server</strong> <strong>2003</strong><br />
und <strong>Exchange</strong> <strong>Server</strong><br />
<strong>2003</strong> dürfte VSS-basiertes<br />
Backup und Restore ein<br />
Standardverfahren für Desaster-Recovery<br />
im Enterprise-Umfeld<br />
werden. Die<br />
im vorangegangenen diskutierten<br />
Vorteile der<br />
Methodik sprechen für<br />
Feature Windows Backup BrightStor ARCserve NetWorker<br />
Offline Backup × × ×<br />
Online Backup × × ×<br />
Single Database × × ×<br />
Single Mailbox × ×<br />
Single Objects × ×<br />
VSS Snapshots × ×<br />
Backup in parallel × × ×<br />
Online Restore × × ×<br />
Restore in parallel × × ×<br />
Cluster Support × × ×<br />
Tape Library Support × ×<br />
Remote Backup × × ×<br />
Environments Small Windows Heterogeneous<br />
sich. Auch hierfür ist ein 3 rd -Party Backup-Produkt notwendig, da das Windows-eigene Backup-Tool<br />
ntbackup keine VSS-Snapshots von <strong>Exchange</strong> Datenbanken unterstützt.<br />
Der Funktionsumfang der am Markt offerierten Produkte variiert zum Teil beträchtlich, insbesondere was die<br />
unterstützten Hardware-Devices oder die Unterstützung weiterer Applikationen neben <strong>Exchange</strong> oder gar<br />
anderer Betriebssysteme als Windows betrifft. <strong>Fujitsu</strong> empfiehlt für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> die Backup-<br />
Produkte der NetWorker-Familie. Diese Backup-Lösung ist VSS-konform und ermöglicht außerdem die<br />
Sicherung und Restaurierung einzelner Mailboxen. Darüber hinaus unterstützt der NetWorker, die online<br />
Sicherung einer unvergleichbaren Fülle von Applikationen, alle marktrelevanten Backup-Devices und<br />
Betriebssystemplattformen. Dadurch ist mit dieser Backup-Lösung nicht nur eine Insellösung für <strong>Exchange</strong><br />
<strong>Server</strong> <strong>2003</strong> geschaffen, sondern das Fundament für eine unternehmensweite Enterprise Backup-Lösung<br />
gelegt.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 32 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Backup-Strategie<br />
Noch grundlegender als eine adäquate Backup-Hardware und -Software ist eine entsprechende Backup-<br />
Strategie. Die Backup-Strategie hat Einfluss auf die Anforderungen an die Backup-Hardware und -Software<br />
und legt wiederum die Restore-Strategie fest. So sind die Backup-<br />
Intervalle und Backup-Methode ausschlaggebend für die Restore-<br />
Zeiten. Aber auch die Gliederung des <strong>Exchange</strong> <strong>Server</strong>s in<br />
Storage-Groups und Datenbanken hat Einfluss auf die Backup-<br />
und Restore-Zeiten. Da insbesondere die Restore-Zeit der kritische<br />
Pfad ist, denn dies bedeutet Ausfallszeit, bestimmt gerade bei<br />
größeren <strong>Exchange</strong> <strong>Server</strong>n die geforderte Restore-Zeit das<br />
Backup- und auch das <strong>Exchange</strong> Storage-Group- und Datenbank-<br />
Konzept.<br />
<strong>Exchange</strong> 2000 <strong>Server</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> unterstützen bis zu vier Storage-Groups mit jeweils bis<br />
zu fünf Datenbanken. Jede Storage-Group wird innerhalb eines eigenen Prozesses verwaltet. Es wird für<br />
jede Storage-Group ein eigener Satz von Log-Files für alle Datenbanken innerhalb der Gruppe verwaltet. Pro<br />
Storage-Group ist ein Backup-Prozess möglich. Damit kann, entsprechende Backup-Hardware vorausgesetzt,<br />
das Backup parallelisiert werden. Andererseits soll nicht verschwiegen werden, dass die Aufsplittung<br />
in mehrere Storage-Groups im normalen Betrieb durch die Teilung in mehrere Prozesse mehr Aufwand<br />
und somit eine höhere CPU-Last und einen steigenden Speicherbedarf bedeutet.<br />
Für eine komplette Sicherung der <strong>Exchange</strong> 2000 <strong>Server</strong> oder <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Datenbestände ist es,<br />
im Gegensatz zu <strong>Exchange</strong> <strong>Server</strong> 5.5, nicht ausreichend nur die <strong>Exchange</strong> Datenbanken zu sichern.<br />
Obgleich Active Directory keine Komponente von <strong>Exchange</strong> 200x und dessen Backup ist, so basiert<br />
<strong>Exchange</strong> 200x doch stark darauf. Die gesamten <strong>Exchange</strong> 200x Konfigurationsdaten werden im Active<br />
Directory gespeichert, ebenso wie die Information über die Benutzer. Ferner basiert <strong>Exchange</strong> 200x auf dem<br />
IIS und verschiedene grundlegende <strong>Exchange</strong> Konfigurationsdaten werden in der Metadatenbank des IIS<br />
gespeichert. Beide Informationen, das Active Directory und die IIS Metadatenbank, werden bei einem<br />
System-State-Backup gesichert. Dabei ist zu beachten, dass das Active Directory nicht zwingend auf dem<br />
<strong>Exchange</strong> <strong>Server</strong> vorhanden ist. Es ist daher auch ein System-State-Backup des Domain Controllers<br />
vorzunehmen. Bei geclusterten Systemen sind weitere Komponenten beim Backup zu berücksichtigen.<br />
Die Backup-Hardware kann entweder direkt am <strong>Exchange</strong><br />
<strong>Server</strong> angeschlossen sein, oder an einem dedizierten<br />
Backup-<strong>Server</strong> im Netzwerk. Bei einem Online-Backup<br />
erfolgt in beiden Fällen der Zugriff auf die <strong>Exchange</strong> Daten<br />
über die Backup-Schnittstelle des jeweiligen <strong>Exchange</strong><br />
<strong>Server</strong>s. Entscheidet man sich für einen dedizierten<br />
Backup-<strong>Server</strong>, so ist ein Gigabit-LAN empfehlenswert, um<br />
ausreichenden Datendurchsatz zu gewährleisten.<br />
<strong>Exchange</strong><br />
<strong>Exchange</strong> <strong>Server</strong><br />
with Backup<br />
Backup Software<br />
Online Backup types<br />
save purge<br />
database log files log files<br />
Full × × ×<br />
Incremental × ×<br />
Differential ×<br />
Copy × ×<br />
<strong>Exchange</strong><br />
<strong>Exchange</strong> <strong>Server</strong><br />
Backup <strong>Server</strong><br />
Backup Agent<br />
Backup Software<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 33 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Restore<br />
Datenbanken können einzeln rekonstruiert werden. Dabei sind die übrigen Datenbanken nicht betroffen, die<br />
ihnen zugeordneten Benutzer können alle <strong>Exchange</strong> Dienste nutzen.<br />
Abhängig von der Ursache, die einen Restore der Datenbanken bedingt, kann es trotz eines sorgfältigen<br />
Backups zu Datenverlusten kommen. Man unterscheidet zwei Szenarien des Recovery:<br />
Roll-Forward Recovery<br />
In dem Szenario eines »Roll-Forward Recovery« sind eine oder mehrere Datenbanken einer Storage-<br />
Group verloren gegangen, aber die Log-Files sind intakt. In diesem Falle kann ein selektiver Restore der<br />
betroffenen Datenbanken von einem Backup vorgenommen werden. <strong>Exchange</strong> restauriert alle seit dem<br />
Zeitpunkt des Snapshots veränderten Daten auf Basis der Transaktionslogs. Dies bedeutet, dass trotz<br />
der Notwendigkeit, auf ein Backup zurückzugreifen, keinerlei Daten verloren gegangen sind.<br />
Point-in-Time Recovery<br />
Sind neben einer oder mehreren Datenbanken auch die Log-Files einer Storage-Group betroffen, so<br />
müssen alle Datenbanken und die Log-Files der Storage-Group von einem Backup zurückkopiert werden.<br />
Da in diesem Fall auch die Differenzdaten, in Form der Transaktionslogs, seit dem letzten Backup<br />
verloren sind, kann lediglich der Datenbestand zum Zeitpunkt des Backups wieder hergestellt werden.<br />
In einem solchen Desasterfall, der ein Point-in-Time Recovery bedingt und in dem Daten verloren gehen,<br />
helfen nur möglichst kurze Backup-Intervalle, um Datenverluste zu minimieren.<br />
Der Zeitbedarf für die Wiederherstellung einer Datenbank ist immer höher als die Zeit, die für das Backup<br />
benötigt wird. Zum einen ist dies Hardware-bedingt, denn Bänder sind schnellere Streaming-Devices als<br />
Platten, insbesondere wenn dabei auf einen RAID 5-Verband geschrieben wird, wobei zusätzlich Parity<br />
berechnet und geschrieben werden muss. Zum zweiten Software-bedingt, denn der Restore-Prozess ist<br />
komplexer als der Backup-Prozess. Der Restore-Prozess setzt sich zusammen aus<br />
• Einspielen des letzten Full-Backups<br />
• Einspielen von Incremental- oder Differential-Backups<br />
• Einpflegen der in den Log-Files gespeicherten Änderungen seit dem letzten Full-Backup<br />
Für die Restore-Geschwindigkeit des Backups kann man davon<br />
ausgehen, dass man typischerweise 60% - 70% der Backup-<br />
Geschwindigkeit erreicht. Die Zeit für das Einpflegen der Log-Files<br />
ist abhängig von den Backup-Intervallen und der Leistung des<br />
<strong>Exchange</strong> <strong>Server</strong>s. Je länger das letzte Backup zurückliegt, umso<br />
mehr Log-Informationen müssen eingepflegt werden. Dabei kann<br />
durchaus das Einpflegen der Log-Files länger dauern, als das<br />
Einspielen des Backups selbst (siehe Kasten).<br />
Restore-Beispiel<br />
Datenbank-Größe: 4 GB<br />
Log-Files von einer Woche: 360 × 5 MB<br />
= 1.8 GB<br />
Restore-Zeit für die Datenbank: ½ Stunde<br />
Einpflegen der Log-Files: 5 Stunden<br />
Um die Restore-Geschwindigkeit zu erhöhen empfiehlt es sich, während des Einspielens der Daten für das<br />
entsprechende Laufwerk den Viren-Scanner abzuschalten. Eine Überprüfung auf Viren dürfte überflüssig<br />
sein, da die Daten bereits vor dem Einbringen in die Datenbank geprüft wurden (siehe Kapitel Virenschutz).<br />
Restore-Zeit ist gleichbedeutend mit Ausfallzeit. Gerade bei einem heutzutage so grundlegenden Medium<br />
wie E-Mail stellen sich bestimmte Anforderungen an die Verfügbarkeit. Fordert man beispielsweise, dass ein<br />
<strong>Exchange</strong> <strong>Server</strong> maximal für eine Stunde ausfallen darf, so muss ein eventuell notwendiger Restore einer<br />
Datenbank in eben dieser Zeit durchführbar sein. Dadurch wird indirekt die maximal Größe einer <strong>Exchange</strong><br />
Datenbank bestimmt. Die sinnvolle Obergrenze eines <strong>Exchange</strong> <strong>Server</strong>s wird also letztlich nicht durch die<br />
Leistungsfähigkeit der Hardware, wie CPU, Arbeitsspeicher und Disk-Subsystem, sondern durch das<br />
Backup-Konzept bestimmt.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 34 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Best Praxis<br />
Die beste Backup-Methode ist ein regelmäßiges Online-Full-Backup. Das Full-Backup sollte die <strong>Exchange</strong><br />
Datenbanken, den System-State des <strong>Exchange</strong> <strong>Server</strong>s und des Domain Controllers, sowie alle <strong>Exchange</strong><br />
Programmdateien beinhalten.<br />
Ein Full-Backup minimiert im<br />
Gegensatz zu inkrementellen und<br />
differentiellen Backups die<br />
Restore-Zeiten. Zur Minimierung<br />
der Zeiten, die für das Einpflegen<br />
der Log-Informationen notwendig<br />
sind, empfiehlt es sich, möglichst<br />
oft ein Full-Backup durchzuführen.<br />
Bei differentiellen und inkrementellen<br />
Backups ist außerdem zu<br />
bedenken, dass während des<br />
Restores temporär zusätzlicher<br />
Plattenplatz für die Log-Dateien<br />
benötigt wird.<br />
Daily Full Backup<br />
1 Tape<br />
Weekly Full Backup<br />
with Daily Differentials<br />
2 Tapes<br />
Weekly Full Backup<br />
with Daily Incrementals<br />
n Tapes<br />
Die Backup-Hardware sollte so<br />
ausgelegt sein, dass ohne manuellen Bandwechsel ein Full-Backup durchgeführt werden kann. Somit ist die<br />
Basis für ein automatisches, benutzerloses, tägliches Backup gegeben.<br />
Für weitere Informationen bezüglich Backup-Strategien siehe <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Technical Documentation<br />
Library [L10] und <strong>Exchange</strong> 2000 <strong>Server</strong> Resource Kit [L13].<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 35 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Archivierung<br />
Obgleich <strong>Exchange</strong> theoretisch bis zu 320 TB Datenspeicher verwalten könnte, so sind doch in der Praxis<br />
Grenzen in der Größenordnung von 400 GB zu sehen. Daher findet man in fast allen größeren <strong>Exchange</strong><br />
Installationen eine Limitierung der Mailbox-Größe, um das Datenvolumen auf einem <strong>Exchange</strong> <strong>Server</strong> in den<br />
Griff zu bekommen. Aber wohin mit älteren Mails? In den meisten Fällen wird die Beantwortung dieser Frage<br />
dem Mailbox-Benutzer überlassen. Er entscheidet, ob er Informationen, die den Rahmen der ihm<br />
zugedachten Mailbox übersteigen, löscht oder Client-seitig archiviert. Dabei ist aber meist weder die Datenintegrität<br />
noch die Datensicherheit gewährleistet. In Geschäftsbereichen, in denen gesetzmäßig eine<br />
Aufbewahrung allen Schriftverkehrs gefordert ist, kann dies keine Lösung sein. Hier werden <strong>Server</strong>-seitige<br />
Lösungen benötigt.<br />
Für die automatische Archivierung von E-Mails gibt es eine Reihe von leistungsstarken 3 rd -Party-Produkten.<br />
Dabei darf der Begriff der Archivierung nicht mit Backup verwechselt werden. Ein Backup dient der Datensicherung<br />
aktueller Datenbestände und deren Wiederherstellung. Eine Archivierung dient der Aufbewahrung<br />
der gesamten Informationshistorie. Des Weiteren ist bei der Archivierung zwischen der klassischen<br />
»Langzeitarchivierung« und der »Datenauslagerung auf preiswertere Speichermedien« zu unterscheiden.<br />
Langzeitarchivierung<br />
Zur Erfüllung der Nachweispflicht gegenüber dem Gesetzgeber bzw. der Revision wird verlangt, dass<br />
bestimmte Datenbestände entsprechend der dafür festgelegten Frist aufbewahrt werden müssen. Diese<br />
Daten dürfen nach erfolgter Archivierung nicht mehr verändert werden, müssen aber auf Anforderung für<br />
Auswertungen jederzeit bereitgestellt werden können.<br />
Datenauslagerung<br />
Die Datenauslagerung eignet sich insbesondere zur Verdrängung so genannter inaktiver E-Mails. Damit<br />
bezeichnet man in der Regel E-Mails, die nach geraumer Zeit in Vergessenheit geraten sind. Diese E-<br />
Mails werden nach festen Regeln wie Alter (Empfangsdatum, Datum des letzten Zugriffs), Größe und<br />
Schwellwerte wie High- and Low-Watermarks der Mailbox, auf preiswertere Medien verlagert. Im Gegensatz<br />
zu langzeitarchivierten E-Mails bleiben diese E-Mails in den <strong>Exchange</strong> Datenbanken über so<br />
genannte Stub-Objekte sichtbar. Ein Anwenderzugriff auf eine verdrängte E-Mail löst automatisch und für<br />
den Anwender transparent eine Wiedereinlagerung der E-Mail in eine <strong>Exchange</strong> Datenbank aus.<br />
Eine Archivierungslösung für <strong>Exchange</strong> <strong>Server</strong> kann zum einen der Einhaltung gesetzlicher Vorschriften,<br />
zum andern aber auch der Performance- und Verfügbarkeitssteigerung dienen. Durch die Entlastung der<br />
<strong>Exchange</strong> Datenbanken von alten E-Mails wird ein besserer Datendurchsatz erreicht und im Falle eines<br />
Restores kürzere Ausfallzeiten.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 36 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Virenschutz<br />
Etwa ebenso viele Datenverluste wie durch Hardware-Ausfälle - 8% - sind auf den Einfluss durch Computer-<br />
Viren zurückzuführen. Dabei handelt sich nur um Fälle, die Datenverluste nach sich führen, nicht mitgerechnet<br />
sind die Ausfälle durch Blockierung der Mail-<strong>Server</strong> durch Viren und Ausfallszeiten zur Beseitigung von<br />
Viren. Daher ist es unerlässlich, ein Mail-System durch den Einsatz eines Virenscanners zu schützen, um<br />
Viren bereits abzublocken bevor sie sich ausbreiten oder gar Schaden anrichten. Dabei gilt es nicht nur ein-<br />
sondern auch ausgehende Mails auf Viren zu prüfen, um Viren nicht an Geschäftspartner zu verteilen. Der<br />
Schaden wäre hier vor allem ein Image-Verlust. Auch interner Mail-Verkehr sollte geprüft werden, denn die<br />
Wege, über die Viren eingeschleppt werden können, sind vielfältig, z.B. Datenträger (wie Floppy, CD,<br />
Removable Disks oder USB-Sticks), Internet- und Remote-Zugänge oder Portable Computer, die auch in<br />
fremden Netzen betrieben werden.<br />
Neben Viren, die sich per E-Mail verbreiten, sind heute auch SPAM-Mails – unerwünscht zugesandte<br />
Werbung - ein Ärgernis und belasten die Mail-<strong>Server</strong> nicht unerheblich. Statistiken belegen, dass zwischen<br />
5% und 40% des Mail-Aufkommens durch SPAM-Mail verursacht werden, mit steigender Tendenz.<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> bietet selbst keinen Viren-Scanner, hierfür sind 3 rd -Party-Lösungen notwendig. Seit<br />
der Version <strong>Exchange</strong> <strong>Server</strong> 5.5 Service Pack 3 besitzt <strong>Exchange</strong> jedoch zumindest ein Viren-Scanner-API,<br />
kurz AV-API genannt. Diese Schnittstelle erlaubt es Viren-Scannern, auf effiziente Weise unverschlüsselte<br />
E-Mails auf Viren zu prüfen und zu bereinigen bevor sie die Mailbox des Empfängers erreichen. Für den<br />
Virenschutz verschlüsselter E-Mails sind entsprechende Maßnahmen bei den Clients zu treffen.<br />
Es gibt eine ganze Reihe von Viren-Schutz-Produkten. Diese Produkte sind im Allgemeinen nicht nur auf<br />
den Schutz von <strong>Exchange</strong> begrenzt, sondern umfassen meist eine ganze Palette von Schutzprogrammen,<br />
mit denen sich auch Client-PCs, Web-<strong>Server</strong>, File-<strong>Server</strong> und andere Dienste gegen Viren absichern lassen.<br />
Obgleich das <strong>Exchange</strong> Viren-API bereits mit <strong>Exchange</strong> <strong>Server</strong> 5.5 SP3 eingeführt wurde, unterstützen nicht<br />
alle Viren-Schutz-Lösungen dieses Interface. Einige Produkte beschränken sich auch heute noch auf das<br />
SMTP-Gateway und das Client-Interface. Bei der Wahl einer Viren-Schutz-Lösung sollte darauf geachtet<br />
werden, dass diese mit dem Viren-Scanner-API von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> kompatibel ist. Nur so ist ein<br />
effektiver Schutz und optimale Performance gewährleistet.<br />
Eine Übersicht über existierende Anti-Viren-Lösungen für <strong>Exchange</strong> <strong>Server</strong> und eine neutrale Leistungsbeurteilung<br />
bietet die Web-Site www.av-test.org, ein Projekt der Universität Magdeburg und der AV-Test<br />
GmbH.<br />
Ein Viren-Scanner verbraucht bei seiner Arbeit nicht unerhebliche System-Ressourcen. Vor allem Prozessor-<br />
Leistung wird benötigt, insbesondere bei komprimierten Attachments, da bei solchen der zu prüfende Inhalt<br />
erst entpackt werden muss. Die Belastung für Arbeitsspeicher und Disk- oder Netzwerk-I/O ist hingegen<br />
nicht nennenswert.<br />
Messungen mit dem Medium-Profil auf<br />
einer PRIMERGY TX150 mit TrendMicro<br />
ScanMail 6.2 haben gezeigt, dass sich<br />
mit Viren-Scanner der CPU-Bedarf von<br />
<strong>Exchange</strong> etwa um den Faktor 1.6<br />
erhöht. Die Änderungen der Antwortzeiten<br />
sind hingegen fast konstant und<br />
betragen ca. 25 ms.<br />
Dabei ist es für die Prozessoren der<br />
PRIMERGY jedoch kein Problem, die benötigte<br />
Rechenleistung bereitzustellen.<br />
Bei der Dimensionierung ist lediglich darauf<br />
zu achten, diesen CPU-Bedarf einzuplanen<br />
und eine entsprechend leistungsfähige<br />
CPU bzw. die Anzahl der<br />
Prozessoren entsprechend auszuwählen.<br />
Datensicherheit spielt heute eine immer wichtigere Rolle und viele entscheiden sich, ihre Mails zu verschlüsseln.<br />
Dabei ist jedoch zu bedenken, dass solche Mails auf dem <strong>Exchange</strong> <strong>Server</strong> nicht auf Viren geprüft<br />
werden können. Hier müssen klassische Viren-Scanner auf den Client-Systemen verwendet werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 37 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
System Analyse Tools<br />
Eine unternehmenskritsche Anwendung wie E-Mail-Kommunikation bedarf vorausschauender Planung und<br />
im laufenden Betrieb einer stetigen Kontrolle der Leistungsfähigkeit. Microsoft stellt für <strong>Exchange</strong> <strong>Server</strong> eine<br />
Vielzahl von Werkzeugen zur Verfügung mit deren Hilfe die Leistungsfähigkeit eines <strong>Exchange</strong> <strong>Server</strong>s<br />
geplant, verifiziert und analysiert werden kann. Dabei können Werkzeuge für drei Phasen unterschieden<br />
werden:<br />
Planung und Design<br />
White Paper<br />
Für die Planung einer <strong>Exchange</strong> <strong>Server</strong> Umgebung und die Dimensionierung der einzelnen <strong>Exchange</strong><br />
<strong>Server</strong> gibt es eine Vielzahl von Dokumenten. Neben diesem White Paper, das sich im speziellen mit<br />
der Dimensionierung von PRIMERGY <strong>Server</strong>n beschäftigt, gibt es zahlreiche Dokumente von<br />
Microsoft, siehe <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Technical Documentation Library [L10]. Insbesondere sei hier<br />
das White Paper <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Performance and Scalability <strong>Guide</strong> [L11] genannt, das<br />
essentielle Informationen zum Thema Performance und Scaling von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
beinhaltet.<br />
System Center Capacity Planner 2006<br />
Ferner gibt es von Microsoft das leistungsfähiges Produkt System Center Capacity Planner 2006<br />
[L14], das interaktiv die Planung und Modellierung von <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Topologien und<br />
Operations Manager 2005 Umgebungen ermöglicht.<br />
Prototyping (Design verification)<br />
Zur Evaluierung der Leistung von <strong>Exchange</strong> <strong>Server</strong> und zur Verifikation, ob die geplante <strong>Server</strong>-<br />
Hardware ausreichend dimensioniert wurde, gibt es zwei Tools von Microsoft. Beide Tools eignen sich<br />
nicht für den laufenden Betrieb und dürfen ausschließlich auf nicht produktiven Systemen eingesetzt<br />
werden.<br />
JetStress<br />
Das Tool JetStress dient der Überprüfung der Disk-I/O-Leistung eines <strong>Exchange</strong> <strong>Server</strong>s. Dabei<br />
simuliert JetStress die Disk-I/O-Last von <strong>Exchange</strong> für eine definierbare Anzahl von Benutzern in<br />
Bezug auf die <strong>Exchange</strong> Datenbanken und deren Log-Files. Hierfür muss <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> nicht<br />
zwingend installiert sein. CPU, Speicher und Netzwerk-I/O werden von JetStress jedoch nicht<br />
simuliert.<br />
LoadSim<br />
Das Simulationswerkzeug LoadSim wurde bereits ausführlich im Kapitel <strong>Exchange</strong> Messmethodik<br />
vorgestellt. Es simuliert die Aktivität von <strong>Exchange</strong> Benutzern und stellt daher den <strong>Exchange</strong> <strong>Server</strong><br />
unter realitätsnahe Last. Dabei werden alle Ressourcen (CPU, Memory, Disk-Subsystem, Netzwerk),<br />
die der <strong>Exchange</strong> <strong>Server</strong> benötigt, mit einbezogen.<br />
Beide Stress-Tools können kostenfrei von der Web-Site Downloads for <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> [L9]<br />
heruntergeladen werden.<br />
Betrieb (Operate)<br />
Zur Überwachung und Performance-Analyse eines Systems zur Laufzeit beinhaltet Windows ein<br />
zentrales Konzept. Hier werden systemweit Ereignisse (Events) und Leistungsdaten (Performance<br />
Counter) gesammelt und abgelegt. Dieses einheitliche Konzept steht auch allen Anwendungen offen,<br />
sofern sie denn davon Gebrauch machen. Microsoft <strong>Exchange</strong> <strong>Server</strong> macht intensiv davon Gebrauch<br />
und stellt sowohl Ereignisse in das Eventlog als auch eine Vielzahl <strong>Exchange</strong>-spezifischer Performance<br />
Counter bereit. Zur Auswertung der Events und Performance Counter können entweder der in jedem<br />
Windows System standardmäßig enthaltene Event Viewer und Performance Monitor verwendet werden,<br />
oder aber auch spezielle Werkzeuge, die die Inhalte des Eventlogs und der Performance Counter unter<br />
bestimmten Anwendungsaspekten auswerten und bewerten.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 38 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Event Viewer<br />
Ein Standard-Tool eines jeden Windows Systems ist der Event Viewer. Er ist im Startmenü unter<br />
»Administrative Tools« unter dem Namen »Event Viewer« zu finden. Die Ereignisse werden in<br />
verschiedene Gruppen wie »Application«, »Security«, »System« oder »DNS <strong>Server</strong>« sortiert und<br />
jeweils in die Klassen »Information«, »Warning« und »Error« unterteilt. Die vom <strong>Exchange</strong> <strong>Server</strong><br />
protokollierten Ereignisse sind der Rubrik »Application« zu finden. Aber auch unter »System« können<br />
Ereignisse auftauchen, die Einfluss auf die Verfügbarkeit eines <strong>Exchange</strong> <strong>Server</strong>s haben.<br />
Performance Monitor<br />
Der Performance Monitor ist Bestandteil eines jeden Windows Systems und ist im Startmenü unter<br />
»Administrative Tools« unter dem Namen »Performance« zu finden. Er kann auch kurz mit dem<br />
Kommando »perfmon« aufgerufen werden.<br />
Eine Beschreibung der wichtigsten für die Performance eines <strong>Exchange</strong> <strong>Server</strong>s relevanten<br />
Performance Counter ist in dem folgenden Kapitel Performance Analyse zu finden.<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> Best Practices Analyzer Tool<br />
Das Tool Microsoft <strong>Exchange</strong> <strong>Server</strong> Best Practices Analyzer [L9], auch kurz ExBPA genannt,<br />
ermittelt den »Gesundheitszustand« einer gesamten <strong>Exchange</strong> <strong>Server</strong> Topologie. Hierzu sammelt der<br />
<strong>Exchange</strong> <strong>Server</strong> Best Practices Analyzer automatisch Einstellungen und Daten von den relevanten<br />
Komponenten, wie Active Directory, Registry, Metabase und Performance Counter. Diese Daten<br />
werden mit umfassenden „best practice‟-Regeln verglichen und daraus ein detaillierter Report mit<br />
Empfehlungen zur Optimierung der <strong>Exchange</strong> Umgebung erstellt.<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> Performance Troubleshooting Analyzer Tool<br />
Das Microsoft <strong>Exchange</strong> <strong>Server</strong> Performance Troubleshooting Analyzer Tool [L9] sammelt im<br />
laufenden Betrieb Konfigurationsdaten und Performance Counter eines <strong>Exchange</strong> <strong>Server</strong>s. Das Tool<br />
analysiert dabei die Daten und gibt Informationen über mögliche Ursachen von Bottlenecks.<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> Profile Analyzer<br />
Für zukünftige Kapazitätsplanungen und Performance-Analysen kann der <strong>Exchange</strong> <strong>Server</strong> Profile<br />
Analyzer [L9] hilfreich sein. Mit Hilfe dieses Tools ist es möglich, statistische Informationen über die<br />
Aktivitäten einzelner Mailboxen oder auch ganzer <strong>Exchange</strong> <strong>Server</strong> zu sammeln.<br />
Microsoft <strong>Exchange</strong> <strong>Server</strong> User Monitor<br />
Im Gegensatz zu den oben aufgelisteten Werkzeugen arbeitet der Microsoft <strong>Exchange</strong> <strong>Server</strong> User<br />
Monitor [L9] nicht <strong>Server</strong>-seitig, sondern Client-seitig. Dadurch ist es möglich, die Empfindung eines<br />
individuellen Benutzers hinsichtlich der Performance des <strong>Exchange</strong> <strong>Server</strong>s zu untersuchen. Der<br />
<strong>Exchange</strong> <strong>Server</strong> User Monitor sammelt dabei Daten wie Prozessorauslastung, Reaktionszeiten des<br />
Netzwerks und Reaktionszeiten des Outlook <strong>2003</strong> MAPI-Interfaces. Diese Daten können dann für<br />
Bottleneck-Analysen und zur Planung zukünftiger Infrastrukturen verwendet werden.<br />
Microsoft Operations Manager<br />
Microsoft stellt mit dem Produkt Microsoft Operations Manager (MOM) [L15] eine leistungsfähige<br />
Software zur Verfügung, mit der Ereignisse und Systemleistung verschiedener <strong>Server</strong>gruppen im<br />
Firmennetzwerk überwacht werden können. MOM erstellt Berichte, Trendanalysen und bietet<br />
proaktive Benachrichtigungen im Warnungs- und Fehlerfall auf Basis frei konfigurierbarer Filter und<br />
Regeln. Diese Regeln können durch zusätzliche Management Packs, die es für verschiedene<br />
Anwendungen gibt, erweitert werden. Auch für Microsoft <strong>Exchange</strong> <strong>Server</strong> steht ein solches<br />
<strong>Exchange</strong>-spezifisches Management Pack [L9] zur Verfügung.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 39 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Performance-Analyse<br />
Windows und Anwendungen wie <strong>Exchange</strong> <strong>Server</strong> stellen für alle relevanten Komponenten Performance<br />
Counter zur Verfügung. Diese Performance Counter können über eine einheitliche Schnittstelle mit dem in<br />
allen Windows Versionen enthalten Performance Monitor – in einigen Windows Versionen auch System<br />
Monitor genannt – eingesehen, überwacht und aufgezeichnet werden.<br />
Der Performance Monitor ist im Startmenü unter »Administrative<br />
Tools« unter dem Namen »Performance« zu finden. Er kann auch<br />
kurz mit dem Kommando »perfmon« aufgerufen werden.<br />
Performance Counter sind objekt-spezifisch gruppiert, teilweise<br />
gibt es sie auch in verschiedenen Instanzen, wenn ein Objekt<br />
mehrfach vorhanden ist. Beispielsweise gibt es für das Objekt<br />
»Prozessor« einen Performance Counter »%Processor Time«,<br />
wobei dann bei einem Multiprozessorsystem eine Instanz pro<br />
CPU existiert. Nicht alle Performance Counter sind in Windows<br />
bereits vorhanden, sondern viele Anwendungen wie z.B.<br />
<strong>Exchange</strong> <strong>Server</strong> bringen ihre eigenen Performance Counter mit,<br />
die sich in das Betriebssystem integrieren und über den<br />
Performance Monitor abgefragt werden können. Die Performance-Daten kann man entweder am Bildschirm<br />
verfolgen oder, besser, in eine Datei schreiben und offline analysieren. Es können nicht nur Performance<br />
Counter des lokalen Systems ausgewertet werden, sondern auch von entfernten <strong>Server</strong>n, die<br />
entsprechenden Zugriffsrechte vorausgesetzt. Die Handhabung des Performance Monitor ist in der Windows<br />
Hilfe oder in Microsoft Artikeln im Internet ausführlich beschrieben, weiterhin gibt es für jeden einzelnen<br />
Performance Counter unter »Explain« eine Erläuterung.<br />
Zu beachten ist, dass der Performance Monitor auch eine Windows Anwendung ist, die Rechenzeit benötigt.<br />
Es kann vorkommen, dass der Performance Monitor bei extremer <strong>Server</strong>-Überlastung selbst keine<br />
Performance-Daten ermitteln und anzeigen kann, dann sind die entsprechenden Werte 0 oder leer.<br />
Für einen ersten Überblick über die Leistungsfähigkeit eines <strong>Exchange</strong> Mailbox <strong>Server</strong>s ist es ausreichend,<br />
einige Performance Counter aus den Kategorien<br />
Processor<br />
Memory<br />
Logical Disk<br />
MS<strong>Exchange</strong>IS<br />
SMTP <strong>Server</strong><br />
zu betrachten. Im Detail sind dies die Performance Counter<br />
\\\Processor(_Total)\% Processor Time<br />
\\\System\Processor Queue Length<br />
\\\Memory\Available MBytes<br />
\\\Memory\Free System Page Table Entries<br />
\\\Memory\Pages/sec<br />
\\\LogicalDisk(:)\Avg. Disk Queue Length<br />
\\\LogicalDisk(:)\Avg. Disk sec/Read<br />
\\\LogicalDisk(:)\Avg. Disk sec/Write<br />
\\\LogicalDisk(:)\Disk Reads/sec<br />
\\\LogicalDisk(:)\Disk Writes//sec<br />
\\\MS<strong>Exchange</strong>IS Mailbox(_Total)\Send Queue Size<br />
\\\MS<strong>Exchange</strong>IS\RPC Averaged Latency<br />
\\\MS<strong>Exchange</strong>IS\RPC Requests<br />
\\\MS<strong>Exchange</strong>IS\VM Total Large Free Block Bytes<br />
\\\SMTP <strong>Server</strong>(_Total)\Local Queue Length<br />
\\\SMTP <strong>Server</strong>(_Total)\Remote Queue Length<br />
Dabei ist in Abhängigkeit der Konfiguration der zu überwachende <strong>Exchange</strong> <strong>Server</strong> <br />
auszuwählen (es können auch gleichzeitig mehrere <strong>Exchange</strong> <strong>Server</strong> überwacht werden). Ferner ist bei den<br />
Logical Disk Counters das bzw. die jeweils für die <strong>Exchange</strong> Datenbanken und Log-Files relevante<br />
logische(n) Laufwerk(e) : auszuwählen.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 40 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Natürlich sagen die Zahlen und Kurven, die der Performance Monitor liefert, alleine noch nichts über die<br />
Leistungsfähigkeit und Gesundheit eines <strong>Exchange</strong> <strong>Server</strong>s aus. Hierzu sind noch eine Reihe von Regeln<br />
und Schwellwerte notwendig, die der Administrator zu jedem dieser Performance Counter kennen sollte.<br />
Processor<br />
Processor(_Total)\% Processor Time<br />
Damit auch Belastungsspitzen bewältigt werden können, sollte die durchschnittliche CPU-<br />
Auslastung über einen größeren Zeitraum nicht größer als 80% sein.<br />
System\Processor Queue Length<br />
Genügend Prozessorleistung ist dann vorhanden, wenn der Counter Processor Queue Length<br />
einen Durchschnittswert besitzt, der kleiner ist als die Anzahl der logischen Prozessoren.<br />
Ist hier ein Engpass zu sehen, gibt es Lösungsmöglichkeiten: Erhöhung der Prozessorleistung durch<br />
zusätzliche oder schnellere Prozessoren, oder eine Verlagerung von Diensten oder Mailboxen auf<br />
andere <strong>Exchange</strong> <strong>Server</strong>.<br />
Memory<br />
Memory\Available MBytes<br />
Der noch verfügbare freie Speicher sollte immer größer als 50 MB sein, auf jeden Fall größer als<br />
4 MB, da Windows sonst drastische Kürzungen an den residenten Arbeitsbereichen (Working Sets)<br />
der Prozesse durchführt.<br />
Ist hier ein Engpass zu sehen, so sollte über die Aufrüstung des Arbeitsspeichers nachgedacht<br />
werden (siehe auch Kapitel Arbeitsspeicher).<br />
Memory\Free System Page Table Entries<br />
Damit das Betriebssystem ablauffähig bleibt, sollten die freien System Page Table Entries nicht<br />
unter 3500 sinken.<br />
Hier sollte überprüft werden ob bei gesetztem boot.ini-Switch /3GB auch der boot.ini-Switch<br />
/USERVA=3030 gesetzt wurde (siehe auch Kapitel Arbeitsspeicher).<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 41 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Logical Disk<br />
LogicalDisk(:)\Avg. Disk Queue Length<br />
Die durchschnittliche Länge der Warteschlange von einem logischen Laufwerk sollte die Anzahl<br />
der Festplatten, aus denen das logische Laufwerk gebildet wurde, nicht übersteigen. Längere Disk-<br />
Queues treten gemeinsam mit höheren Disk-Antwortzeiten auf und deuten auf ein überlastetes<br />
Disk-Subsystem hin.<br />
LogicalDisk(:)\Avg. Disk sec/Read<br />
LogicalDisk(:)\Avg. Disk sec/Write<br />
Die Antwortzeiten beim Read und Write sollten deutlich unter 20 ms liegen, idealerweise um 5 ms<br />
beim Read und um 10 ms beim Write. Höhere Antwortzeiten treten gemeinsam mit längeren Disk-<br />
Queues auf und deuten auf ein überlastetes Disk-Subsystem hin.<br />
Abhilfe schaffen lässt sich durch das Hinzufügen von weiteren Festplatten, den Einsatz von<br />
schnelleren Festplatten oder eines leistungsfähigeren Disk-Subsystems. Auch die Aktivierung von<br />
Lese- und Schreib-Caches der Festplatten oder die Aktivierung bzw. Erhöhung des Caches des<br />
Disk-Subsystems bzw. des RAID-Controllers kann zur Reduzierung der Antwortzeiten und somit<br />
auch zur Reduzierung der Disk Queue Länge beitragen. Eine andere Möglichkeit, das Disk-<br />
Subsystem zu entlasten, besteht in der Vergrößerung des <strong>Exchange</strong> Caches durch Aufrüsten des<br />
<strong>Server</strong>s mit zusätzlichem Arbeitsspeicher, wodurch sich die Notwendigkeit, auf die Datenbanken<br />
zuzugreifen, reduziert.<br />
LogicalDisk(:)\Disk Reads/sec<br />
LogicalDisk(:)\Disk Writes//sec<br />
Die Anzahl I/Os, die ein logisches Laufwerk pro Sekunde bewältigen kann, ist abhängig vom<br />
verwendeten RAID-Level und der Anzahl an Festplatten. Die beiden Performance Counter zeigen<br />
die Anzahl Lese- bzw. Schreibaufträge, die <strong>Server</strong>-seitig erzeugt werden. Je nach RAID-Level<br />
ergibt sich für die Festplatten eine andere Anzahl an I/O-Aufträgen, die sich für ein RAID 10 nach<br />
der Formel<br />
IO10 = IOread + 2 × IOwrite<br />
und für ein RAID 5 nach der Formel<br />
IO5 = IOread + 4 × IOwrite<br />
berechnet. Des Weiteren ist zu berücksichtigen, dass eine Festplatte in<br />
Abhängigkeit ihrer Drehzahl nur eine bestimmte Anzahl an IO/s befriedigen<br />
kann. Daraus ergibt sich beispielsweise für ein RAID 10 aus vier Festplatten<br />
mit 10 krpm eine maximale Rate von 480 IO/s.<br />
Beobachtet man hier eine zu hohe I/O-Rate, so gibt es verschiedene Möglichkeiten, hier Abhilfe zu<br />
schaffen. Man kann einerseits die Anzahl der verwendeten Festplatten erhöhen. Wird ein RAID 5<br />
verwendet, so kann man in Erwägung ziehen, an dessen Stelle ein RAID 10 einzusetzen, das eine<br />
bessere I/O-Rate bei gleicher Anzahl Festplatten aufweist (vgl. auch Kapitel Festplatten). Betrifft<br />
das I/O-Bottleneck ein logisches Laufwerk auf dem eine <strong>Exchange</strong> Datenbank liegt, so kann die<br />
Aufrüstung des Arbeitsspeichers eine weitere Lösungsmöglichkeit darstellen. <strong>Exchange</strong> <strong>Server</strong><br />
<strong>2003</strong> kann bis zu 1.2 GB RAM als Datenbank-Cache verwenden. Eine Vergrößerung des Datenbank-Caches<br />
wirkt sich natürlich in einer geringern Disk-I/O-Rate aus. Die Default-Größe des<br />
<strong>Exchange</strong> Cache liegt bei 500 MB und bei gesetztem Switch /3GB bei 900 MB. Ist genügend<br />
Memory vorhanden, können weitere 300 MB hinzugefügt werden. Dazu ist mit Hilfe des Active<br />
Directory Service Interfaces und dem Werkzeug ADSI-Edit der Wert für<br />
msESEParamMaxCacheSize auf 307200 zu setzen.<br />
Weitere Information zu Festplatten, Controllern und RAID-Levels sind im White Paper Performance<br />
Report - Modular RAID [L5] zu finden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 42 (71)<br />
IO/s<br />
5400 rpm 62<br />
7200 rpm 75<br />
10000 rpm 120<br />
15000 rpm 170
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
<strong>Exchange</strong> <strong>Server</strong><br />
MS<strong>Exchange</strong>IS Mailbox(_Total)\Send Queue Size<br />
Die Send Queue enthält die <strong>Exchange</strong> Objekte, die auf ihre Weiterleitung warten. Das Ziel kann<br />
entweder eine lokale Datenbank sein oder ein anderer Mail-<strong>Server</strong>. Diese Warteschlange sollte<br />
kleiner als 500 sein. Ein höherer Wert deutet auf ein überlastetes System hin.<br />
SMTP <strong>Server</strong>(_Total)\Local Queue Length<br />
Die lokale Warteschlange des SMTP <strong>Server</strong> enthält die <strong>Exchange</strong> Objekte, die in die lokalen<br />
Datenbanken eingearbeitet werden müssen. Sie sollte nicht größer als 100 werden. Eine größere<br />
Warteschlange, in Verbindung mit längeren Disk Queues und höheren Disk-Antwortzeiten, deutet<br />
auf ein überlastetes Disk-Subsystem hin.<br />
SMTP <strong>Server</strong>(_Total)\Remote Queue Length<br />
Die Remote Queue des SMTP <strong>Server</strong>s enthält die <strong>Exchange</strong> Objekte, die von entfernten Mail-<br />
<strong>Server</strong>n verarbeitet werden müssen. Sie sollte immer kleiner als 1000 sein. Eine größere Warteschlange<br />
deutet auf Verbindungsprobleme oder Probleme der entfernten Mail-<strong>Server</strong> hin.<br />
MS<strong>Exchange</strong>IS\RPC Averaged Latency<br />
Dieser Zähler enthält die durchschnittliche Wartezeit der Aufträge die momentan vorliegen und<br />
noch verarbeitet werden müssen. Der Wert in Millisekunden sollte weniger als 50 betragen. Ein<br />
höherer Wert deutet auf ein überlastetes System hin.<br />
MS<strong>Exchange</strong>IS\RPC Requests<br />
Dieser Zähler enthält die Anzahl der Aufträge die momentan vorliegen und noch verarbeitet werden<br />
müssen. Der Wert sollte weniger als 30 betragen. Ein höherer Wert deutet auf ein überlastetes<br />
System hin.<br />
MS<strong>Exchange</strong>IS\VM Total Large Free Block Size (MB)<br />
Dieser Zähler enthält die Größe des größten freien virtuellen Speicherblockes. Der Wert ist ein<br />
Maß für die Fragmentierung des virtuellen Adressraums. Er sollte mehr als 500 MB betragen.<br />
Weitere Informationen dazu kann man dem Microsoft TechNet Artikel KB325044 [L19] entnehmen.<br />
Wie Eingangs diese Kapitels bereits erwähnt, stellen die beschriebenen Performance Counter nur eine<br />
kleine Auswahl der für <strong>Exchange</strong> verfügbaren und relevanten Performance Counter dar. Für tiefer<br />
gehendere Engpassanalysen müssen sicherlich weitere Performance Counter hinzugezogen werden. Die<br />
Beschreibung aller <strong>Exchange</strong>-relevanten Counter würde den Umfang diese Papiers sprengen, daher sei auf<br />
entsprechende Dokumentation von Microsoft [L10] verwiesen, insbesondere sei hier das White Paper<br />
Troubleshooting <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Performance [L12] erwähnt.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 43 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY als <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
Welche PRIMERGY Modelle eignen sich für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong>? Zunächst hat jedes PRIMERGY Modell<br />
genügend Rechenleistung und bietet ausreichend Speicherausbau für eine bestimmte Anzahl <strong>Exchange</strong><br />
Benutzer. Da wir aus den vorangegangenen Kapiteln wissen, dass der <strong>Exchange</strong> <strong>Server</strong> eine sehr Disk-I/Ointensive<br />
Anwendung ist, spielt der Festplattenausbau der PRIMERGY eine wesentliche Rolle bei der<br />
Eignung für <strong>Exchange</strong>, bzw. bei der maximalen Benutzeranzahl.<br />
Hinsichtlich des Disk-I/Os sind für <strong>Exchange</strong> die internen Ausbaumöglichkeiten der <strong>Server</strong> meist nicht ausreichend.<br />
Somit ist es sinnvoll, den <strong>Server</strong> um ein externes Disk-Subsystem zu erweitern. Für <strong>Exchange</strong><br />
<strong>Server</strong> <strong>2003</strong> eignen sich uneingeschränkt Direct Attached Storages (siehe Kapitel Disk Subsystem) oder ein<br />
Storage Area Network (SAN). Für den Anschluss solcher Disk-Subsysteme gibt es verschiedene Technologien:<br />
SCSI für den direkten Anschluss und Fibre-Channel (FC) oder Internet-SCSI (iSCSI) im SAN-Umfeld.<br />
Eine weitere Anschlussmöglichkeit stellt Network Attached Storage (NAS) in Verbindung mit Windows<br />
Storage <strong>Server</strong> <strong>2003</strong> dar.<br />
Auf den folgenden Seiten werden die heute aktuellen PRIMERGY Systeme und deren Leistungsklassen hinsichtlich<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> erläutert und Konfigurationsmöglichkeiten für die Leistungsklassen von 75<br />
bis 5000 Benutzer vorgestellt. Konfigurationen mit mehr als 5000 Benutzern sind in Cluster-Lösungen mit<br />
PRIMERGY Systemen möglich, aber an dieser Stelle nicht beschrieben.<br />
Die hier beschriebenen Konfigurationen wurden im PRIMERGY Performance Lab jeweils auf Funktionalität<br />
getestet und dem im Kapitel <strong>Exchange</strong> Messmethodik beschriebenen Medium-Lastprofil unterzogen.<br />
Bei der Dimensionierung aller Konfigurationen wurden die folgenden Annahmen zugrunde gelegt:<br />
Plattenkapazität<br />
• Für das Betriebssystem und Programmdateien veranschlagen wir 10 GB.<br />
• Für das Active Directory veranschlagen wir 2 GB, das ist ausreichend für ca. 300000 Einträge.<br />
• Die <strong>Exchange</strong> Datenbanken kalkulieren wir auf Basis einer durchschnittlichen Mailbox-Größe von<br />
100 MB pro Benutzer. Da Mails aus einer Datenbank nicht unmittelbar gelöscht werden, sondern erst<br />
nach einer festgelegten Latenzzeit (Default 30 Tage), kalkulieren wir hierfür zusätzliche 100% an<br />
Plattenkapazität.<br />
• Für den Plattenbedarf der Log-Files gehen wir von einem durchschnittlichen Mail-Volumen von 3 MB<br />
pro Benutzer und Tag aus. Der Plattenbereich für die Log-Files muss ausreichend sein, um alle anfallenden<br />
Daten bis zum nächsten Online-Backup zu speichern. Ein tägliches Backup ist empfehlenswert.<br />
Aus Sicherheitsgründen planen wir einen Log-File-Space, der für sieben Tage ausreichend ist.<br />
• Für SMTP- und MTA-Queues planen wir, ebenfalls basierend auf einem Mail-Volumen von 3 MB pro<br />
Benutzer und Tag, Platzbedarf für einen Tag ein.<br />
• Während der Restore einer Datenbank direkt auf das Volume der Datenbank erfolgt, ist für den Restore<br />
von Log-Files extra Plattenplatz vorzusehen, dessen Größe durch die Summe der Log-Files bestimmt<br />
wird, die als Differentials zwischen zwei Full-Backups anfallen. Wir kalkulieren hierfür die gleiche<br />
Plattenkapazität wie für die Log-Files einer Storage-Group.<br />
Prozessorleistung und Arbeitsspeicher<br />
• Die Prozessorleistung wurde so dimensioniert, dass bei einer Lastsimulation (ohne Virenscanner,<br />
SPAM-Filter und Backup) die Prozessor-Auslastung nicht über 30% lag. Damit ist genügend Raum für<br />
andere Dienste wie Virenscanner oder Backup gegeben.<br />
• Da der meiste Arbeitsspeicher als Cache für die <strong>Exchange</strong> Datenbanken verwendet wird, wurde er in<br />
Abhängigkeit zu dem Disksubsystem so dimensioniert, dass einerseits die Disk-Queue-Länge nicht<br />
größer als die Anzahl der für die Datenbanken verwendeten Festplatten ist und ferner die Antwortzeit<br />
für 95% aller Transaktionen nicht über 500 ms liegt.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 44 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Backup<br />
Da für einen stabilen <strong>Exchange</strong> Betrieb regelmäßige Datensicherungen unumgänglich sind, haben wir für<br />
die Konfigurationsbeispiele folgendes beachtet:<br />
• Das gesamte Backup, bei maximaler Datenbank-Größe, muss in maximal sieben Stunden durchgeführt<br />
werden können.<br />
• Der Restore einer einzelnen Datenbank darf nicht länger als vier Stunden dauern. Diese Forderung hat<br />
auch Auswirkung auf das <strong>Exchange</strong> Design und die Gliederung in Storage-Groups und Datenbanken.<br />
Bei den vorgestellten Konfigurationsbeispielen handelt es sich um reine <strong>Exchange</strong> Mailbox-<strong>Server</strong>, so<br />
genannte Back-End-<strong>Server</strong>. Insbesondere bei größeren <strong>Exchange</strong> Installationen bedarf es weiterer <strong>Server</strong><br />
für Active Directory, DNS und ggf. andere Dienste, wie Outlook Web Access (OWA), SharePoint Portal<br />
<strong>Server</strong>, oder andere.<br />
In jedem Fall bedarf es aber bei der Dimensionierung eines <strong>Exchange</strong> <strong>Server</strong>s einer Analyse der Kundenanforderungen<br />
und der vorhandenen Infrastruktur sowie einer fachlichen Beratung.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 45 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY Econel 100<br />
Das Mono Prozessor System<br />
PRIMERGY Econel 100 bietet<br />
Ausbaumöglichkeiten mit bis zu<br />
8 GB Arbeitsspeicher und vier<br />
internen SATA-Festplatten. Der<br />
optional vorgesehene 1-Kanal<br />
SCSI-Controller ist zur Steuerung<br />
von Backup-Medien bestimmt.<br />
Festplatten intern max. 4, 80 – 500 GB, 7200 rpm<br />
Als Einstiegsmodell der<br />
Festplatten extern Keine<br />
PRIMERGY <strong>Server</strong> Familie<br />
eignet sich die PRIMERGY<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
Econel 100 für kleine Firmen im<br />
Small-Business-Segment, hier bietet sie Datensicheheit für kleinere Budgets. Zu beachten ist, dass bei<br />
einem solchen Einsatzszenario meist auch das Active Directory mit auf dem System untergebracht werden<br />
muss. Im Small-Business-Umfeld ist das Active Directory bzgl. Festplattenzugriffen aber unkritisch, da sich<br />
nicht häufig Änderungen ergeben dürften und lesende Zugriffe seitens <strong>Exchange</strong> zwischengepuffert werden.<br />
Hier sollte also lediglich etwas mehr Arbeitsspeicher vorgesehen werden. Beim Einsatz in Zweigstellen<br />
größerer Firmen ist es vom Design des Active Directories abhängig, wie viele Daten durch Replikation des<br />
Active Directory entstehen. Dies hat sowohl Einfluss auf die benötigte Netzwerkbandbreite zwischen<br />
Zweigstelle und Hauptstelle, als auch auf die Hardware des Active Directory-<strong>Server</strong>s der Zweigstelle.<br />
Bei Verwendung eines Pentium 4 631, einem Speicherausbau von 1 GB und vier 80 GB Festplatten könnte<br />
die nachstehend abgebildete Konfiguration in Verbindung mit dem Komplettpaket Microsoft Small Business<br />
<strong>Server</strong> <strong>2003</strong> [L16] eine Einstiegslösung für bis zu 75 Benutzer darstellen. Da eine regelmäßige<br />
Datensicherung unabdingbar für den reibungslosen Betrieb eines <strong>Exchange</strong> <strong>Server</strong>s ist (vgl. Kapitel<br />
Backup), ist ein DDS Gen5 oder VXA-2 Bandlaufwerk empfehlenswert.<br />
In Verbindung mit den Standardprodukten von Windows <strong>Server</strong> <strong>2003</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> anstelle<br />
des Small Business <strong>Server</strong> <strong>2003</strong> besteht keine Limitierung auf 75 Benutzer und eine PRIMERGY Econel 100<br />
kann mit den 4 internen SATA-Festplatten, einem Pentium D 820 und einem Arbeitsspeicher von 2 GB bis<br />
zu 200 <strong>Exchange</strong> Benutzer bedienen. Für das Backup sollte in dieser größeren Konfiguration ein VXA-2<br />
Laufwerk eingesetzt werden, da bei DDS Gen5 die Bandkapazität evtl. nicht ausreichend ist ein komplettes<br />
Backup ohne Bandwechsel durchzuführen.<br />
Obgleich Festplatten mit einer Kapazität bis 500 GB für die PRIMERGY Econel 100 verfügbar sind, sollte<br />
man nicht auf die Idee verfallen, die vier Festplatten kleiner Kapazität durch zwei Festplatten großer<br />
Kapazität zu ersetzen. Hier werden bewusst vier Festplatten eingesetzt, um die <strong>Exchange</strong> Datenbanken und<br />
Log-Files auf unterschiedliche physikalische Festplatten ablegen zu können. Dies hat Performance- und<br />
Sicherheitsgründe, vgl. Kapitel Disk-Subsystem.<br />
Die nebenstehende Abbildung zeigt eine kleine<br />
Konfiguration für einen <strong>Exchange</strong> <strong>Server</strong> mit Active<br />
Directory. Die vier Platten werden direkt am internen<br />
onboard SATA-Controller angeschlossen. Die RAID 1<br />
Funktionalität kann entweder mit dem Disk-Mirroring<br />
von Windows <strong>Server</strong> <strong>2003</strong> oder mit dem onboard 4-<br />
Port SATA-Controller mit HW-RAID realisiert werden.<br />
Unter der Bedingung, dass das System USVgesichert<br />
ist, sollten die Platten-Caches zur Verbesserung<br />
der Performance eingeschaltet werden.<br />
Prozessoren 1 × Pentium D 820, 2.8 GHz, 2×1 MB SLC<br />
oder<br />
1 × Pentium 4 631/641, 3.0/3.2 GHz, 2 MB<br />
SLC oder<br />
1 × Celeron D 346, 3.06 GHz, 256 kB SLC<br />
Speicher max. 8 GB<br />
onboard RAID SATA<br />
PCI SCSI-Controller 1 × 1-Kanal<br />
SCSI-Kanäle 1 für Backup-Laufwerke<br />
RAID 1<br />
OS, AD,<br />
Logs, Queues<br />
RAID 1<br />
Store<br />
Es werden zwei gespiegelte System-Drives eingerichtet. Pro System-Drive wird eine Partition angelegt. Das<br />
erste System-Drive wird für das Betriebssystem, Active Directory, Log-Files und Queues verwendet, das<br />
zweite ausschließlich für die <strong>Exchange</strong> Datenbanken (Store).<br />
<strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> in der Standard Edition unterstützt zwei Datenbanken mit einer maximalen Datenbankgröße<br />
von 75 Gigabyte. Dabei wird eine Datenbank für die Postfächer und eine Datenbank für die<br />
Öffentlichen Ordner benötigt. Damit genügt diese Konfiguration den Eingangs der Kalkulation zugrunde<br />
gelegten Annahmen für eine durchschnittliche Mailbox-Größe von 100 MB pro Benutzer und 100% Reserve<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 46 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
für Datenbankobjekte, die nicht unmittelbar gelöscht werden sondern erst nach einer standardmäßigen<br />
Latenzzeit von 30 Tagen. Unter diesen Bedingungen würde die Datenbank für die Postfächer im Extremfall<br />
auf bis zu 100 MB × 200 User × 2 = 40 GB anwachsen.<br />
Entsprechend der Eingangs getroffenen Annahmen eines Log-File-Volumens von 3 MB pro Benutzer und<br />
Tag, ist für eine 7 Tage Bevorratung der Log-Files für 200 Benutzer ein Plattenplatzbedarf von 4 GB<br />
einzukalkulieren.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 47 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY Econel 200<br />
Das Dual Prozessor System PRIMERGY<br />
Econel 200 bietet die Rechenleistung von<br />
zwei Intel Xeon DP Prozessoren und Ausbaumöglichkeiten<br />
mit bis zu 4 GB Arbeitsspeicher<br />
sowie vier internen SATA-Festplatten.<br />
Der optional vorgesehene 1-Kanal<br />
SCSI-Controller ist zur Ansteuerung von<br />
Backup-Laufwerken bestimmt.<br />
Wie das Einstiegsmodell PRIMERGY<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
Econel 100 eignet sich auch die<br />
PRIMERGY Econel 200 ideal für das Small-Business-Segment oder für Zweigstellen, wo mehr<br />
Rechenleistung benötigt wird als ein Mono Prozessor System bieten kann.<br />
Zu beachten ist, dass bei einem solchen Einsatzszenario meist auch das Active Directory mit auf dem<br />
System untergebracht werden muss. Im Small-Business-Umfeld ist das Active Directory bzgl.<br />
Festplattenzugriffen aber unkritisch, da sich nicht häufig Änderungen ergeben dürften und lesende Zugriffe<br />
seitens <strong>Exchange</strong> zwischengepuffert werden. Hier sollte also lediglich etwas mehr Arbeitsspeicher<br />
vorgesehen werden. Beim Einsatz in Zweigstellen größerer Firmen ist es vom Design des Active Directories<br />
abhängig, wie viele Daten durch Replikation des Active Directory entstehen. Dies hat sowohl Einfluss auf die<br />
benötigte Netzwerkbandbreite zwischen Zweigstelle und Hauptstelle, als auch auf die Hardware des Active<br />
Directory-<strong>Server</strong>s der Zweigstelle.<br />
Die nebenstehende Abbildung zeigt eine kleine Konfiguration<br />
für einen <strong>Exchange</strong> <strong>Server</strong> mit Active<br />
Directory. Die vier Platten werden direkt am internen<br />
onboard SATA-Controller angeschlossen. Die RAID 1<br />
Funktionalität kann entweder mit dem Disk-Mirroring<br />
von Windows <strong>Server</strong> <strong>2003</strong> oder mit dem onboard 4-Port<br />
SATA-RAID-Controller realisiert werden. Unter der<br />
Bedingung, dass das System USV-gesichert ist, sollten<br />
die Platten-Caches eingeschaltet werden. Obgleich<br />
Prozessoren 2 × Xeon DP<br />
2.8/3.4 GHz, 2 MB SLC<br />
Speicher max. 4 GB<br />
onboard RAID SATA<br />
PCI SCSI-Controller 1 × 1-Kanal<br />
SCSI-Kanäle 1 (Backup Device)<br />
Festplatten intern max. 4<br />
80 – 500 GB, 7200 rpm<br />
Festplatten extern Keine<br />
RAID 1<br />
OS, AD,<br />
Logs, Queues<br />
RAID 1<br />
Store<br />
Festplatten mit einer Kapazität bis 500 GB für die PRIMERGY Econel 200 verfügbar sind, sollte man nicht<br />
auf die Idee verfallen, die vier Festplatten kleiner Kapazität durch zwei Festplatten großer Kapazität zu<br />
ersetzen. Hier werden bewusst vier Festplatten eingesetzt, um die <strong>Exchange</strong> Datenbanken und Log-Files auf<br />
unterschiedliche physikalische Festplatten ablegen zu können. Dies hat Performance- und<br />
Sicherheitsgründe, vgl. Kapitel Disk-Subsystem.<br />
Es werden zwei gespiegelte System-Drives eingerichtet. Pro System-Drive wird eine Partition angelegt. Das<br />
erste System-Drive wird für das Betriebssystem, Active Directory, Log-Files und Queues verwendet, das<br />
zweite ausschließlich für die <strong>Exchange</strong> Datenbanken (Store).<br />
Bestückt man die PRIMERGY Econel 200 mit ein oder zwei Xeon DP Prozessoren und einem<br />
Speicherausbau von 1 GB, kann diese Konfiguration in Verbindung mit dem Komplettpaket Microsoft Small<br />
Business <strong>Server</strong> <strong>2003</strong> [L16] eine Einstiegskonfiguration für bis zu 75 Benutzern darstellen, die mit weiteren<br />
CPU- oder Speicher-intensiven Aufgaben belastet werden kann. Da eine regelmäßige Datensicherung<br />
unabdingbar für den reibungslosen Betrieb eines <strong>Exchange</strong> <strong>Server</strong>s ist (vgl. Kapitel Backup), ist ein VXA-2<br />
oder VXA-320 Bandlaufwerk empfehlenswert.<br />
Setzt man anstelle der auf 75 Benutzer limitierten Microsoft Small Business <strong>Server</strong> Edition, die Standard<br />
Produkte von Windows <strong>Server</strong> <strong>2003</strong> und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> ein, so kann eine PRIMERGY Econel 200<br />
bei entsprechender Ausstattung mit zwei Prozessoren und 2 GB Arbeitsspeicher durchaus bis zu 200<br />
Benutzer bedienen. Dabei erweist sich das Disk-Subsystem von maximal vier internen SATA-Festplatten als<br />
limiterender Faktor. Alternativ kann auch ein Network Attached Storage (NAS) auf Basis des Windows<br />
Storage <strong>Server</strong> <strong>2003</strong> als Disk-Subsystem eingesetzt werden. Damit würde sich von der Rechenleistung die<br />
PRIMERGY Econel 200 auch als kostengünstige Lösung für dedizierte <strong>Exchange</strong> <strong>Server</strong> für Zweigstellen<br />
oder Application Service Provider (ASP) Rechenzentren eignen. Aufgrund fehlender Möglichkeit, die<br />
PRIMERGY Econel 200 in ein 19"-Rack zu integireren, ist sie für diesen Einsatzbereich jedoch weniger<br />
geeignet und es empfehlen sich hier die Rack-<strong>Server</strong> der PRIMERGY Produkt-Linie.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 48 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY TX150 S4<br />
Das Mono Prozessor System<br />
PRIMERGY TX150 S4 bietet<br />
Ausbaumöglichkeiten mit bis zu 8 GB<br />
RAM und vier internen SAS- oder SATA-<br />
Festplatten. Optional sind mit zwei extern<br />
angeschlossenen PRIMERGY SX30<br />
weitere 28 Festplatten möglich. Neben<br />
der klassischen Floorstand-Gehäuseform<br />
ist die PRIMERGY TX150 S4 auch in<br />
einer Rack-Variante erhältlich.<br />
Als Floorstand-<strong>Server</strong> eignet sich die<br />
PRIMERGY TX150 S4 für kleine Firmen<br />
im Small-Business-Segment oder als<br />
<strong>Server</strong> für kleine Zweigstellen. Zu beachten<br />
ist, dass bei einem solchen<br />
Einsatzszenario meist auch das Active<br />
Directory mit auf dem System untergebracht<br />
werden muss. Im Small-<br />
Business Umfeld ist das Active Directory<br />
bzgl. Festplattenzugriffen aber unkritisch,<br />
da sich nicht häufig Änderungen ergeben<br />
dürften und lesende Zugriffe seitens<br />
<strong>Exchange</strong> zwischengepuffert werden.<br />
Hier sollte also lediglich etwas mehr<br />
Arbeitsspeicher vorgesehen werden. Beim Einsatz in Zweigstellen größerer Firmen ist es vom Design des<br />
Active Directories abhängig, wie viele Daten durch Replikation des Active Directory entstehen. Dies hat<br />
sowohl Einfluss auf die benötigte Netzwerkbandbreite zwischen Zweigstelle und Hauptstelle, als auch auf die<br />
Hardware des Active Directory-<strong>Server</strong>s der Zweigstelle.<br />
Bei Verwendung eines Pentium 4 631 und einem Speicherausbau von 1 GB kann die PRIMERGY TX150 S4<br />
mit vier internen 80 GB SATA- oder vier 73 GB SCSI-Festplatten in Verbindung mit dem Komplettpaket<br />
Microsoft Small Business <strong>Server</strong> <strong>2003</strong> [L16] eine Einstiegskonfiguration für bis zu 75 Benutzern darstellen.<br />
Die nebenstehende Abbildung zeigt eine kleine Konfiguration<br />
für einen <strong>Exchange</strong> <strong>Server</strong> mit Active<br />
Directory. Die vier Platten können direkt am internen<br />
onboard SCSI- oder SATA-Controller angeschlossen<br />
werden. Die RAID 1 Funktionalität kann entweder mit<br />
dem Disk-Mirroring von Windows <strong>Server</strong> <strong>2003</strong> oder<br />
mit der Zero-Channel-RAID-Option des einkanaligen<br />
onboard Ultra 320 SCSI-Controller »LSI 1020A« oder<br />
mit dem 4-Port SATA-Controller »Promise FastTrak<br />
Prozessoren 1 × Pentium D 820 / 930 / 940 / 950<br />
(2.8/3.0/3.2/3.4 GHz, 2 MB SLC) oder<br />
1 × Pentium 4 631/651 (3.0/3.4 GHz,2 MB SLC) oder<br />
1 × Celeron D 346 (3.06 GHz, 256 KB SLC)<br />
Speicher Max. 8 GB<br />
onboard RAID SCSI oder SATA<br />
PCI SCSI-Controller 1 × 1-Kanal (Backup Device)<br />
1 × 2-Kanal RAID<br />
Festplatten intern Max. 4<br />
Festplatten extern Max. 28<br />
onboard LAN 1 × 10/100/1000 Mbit<br />
RAID 1<br />
OS, AD, Logs,<br />
Queues<br />
RAID 1<br />
Store<br />
S150-TX4« mit HW-RAID realisiert werden. Unter der Bedingung, dass das System USV-gesichert ist,<br />
sollten die Controller- und Platten-Caches eingeschaltet werden.<br />
Es werden zwei gespiegelte System-Drives eingerichtet. Pro System-Drive wird eine Partition angelegt. Das<br />
erste System-Drive wird für das Betriebssystem, Active Directory, Log-Files und Queues verwendet, das<br />
zweite ausschließlich für die <strong>Exchange</strong> Datenbanken (Store).<br />
Auf keinen Fall sollte aus den vier Festplatten, welche in der PRIMERGY TX150 S4 Platz finden, ein RAID 5-<br />
Verband gebildet werden, oder gar noch an einer Festplatte gespart werden und ein RAID 5-Verband mit nur<br />
drei Festplatten erstellt werden. Ebenso sollten nicht anstelle der beiden RAID 1-Verbände aus vier Festplatten<br />
nur ein RAID 1-Verband aus zwei Festplatten größerer Kapazität erstellt werden. Dies hätte einen<br />
fatalen Effekt auf die Systemleistung. Zum einen ist ein solches RAID 5 wesentlich langsamer als RAID 1,<br />
zum anderen würde dann das Betriebssystem und alle Anwenderdaten mit unterschiedlichen Zugriffsmustern<br />
auf einem Volume liegen. Die Performance wäre nicht mehr akzeptabel.<br />
Bei maximal 75 Benutzern unter Small Business <strong>Server</strong> <strong>2003</strong> wird die <strong>Exchange</strong> Datenbank für die<br />
Postfächer, unter den Eingangs zugrunde gelegten Annahmen für eine durchschnittliche Mailbox-Größe von<br />
100 MB pro Benutzer und 100% Reserve für Datenbankobjekte, etwa bis zu einer Größe von<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 49 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
100 MB × 75 User × 2 = 15 GB anwachsen. Als Backup-Laufwerk empfiehlt sich daher ein DDS Gen5<br />
Laufwerk.<br />
Stattet man die PRIMERGY TX150 S4 mit einem stärkeren Prozessor, z.B. einem Pentium D 820, und<br />
einem Arbeitsspeicher von 2 GB aus, so kann man durchaus bis zu 200 <strong>Exchange</strong> Benutzer bedienen.<br />
Allerdings genügt dann nicht mehr der auf 75 Benutzer limitierte Small Business <strong>Server</strong> <strong>2003</strong>, sondern es<br />
sind dann die Produkte Windows <strong>Server</strong> <strong>2003</strong> Standard Edition und <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Standard Edition<br />
einzusetzen. Die Datenbank für die Postfächer von 200 Benutzern wird bei einer maximal Mailbox-Größe<br />
von 100 MB auf bis zu ca. 100 MB × 200 User × 2 = 40 GB anwachsen. Als Backup-Medium sollte daher<br />
VXA-2 eingesetzt werden, da ansonsten unter Umständen für ein Total-Backup mehr als ein Band benötigt<br />
wird.<br />
Ein <strong>Server</strong> im »Small and Medium-Sized Enterprise« (SME)-Umfeld oder in Zweigstellen wird häufig zusätzlich<br />
noch als File- und Print-<strong>Server</strong> verwendet, da dies häufig der einzige <strong>Server</strong> vor Ort ist. Für einfache<br />
Print-Dienste genügt ein etwas stärkerer Prozessor, z.B. Pentium D 940, und etwas mehr Arbeitsspeicher.<br />
Für zusätzliche File-<strong>Server</strong>-Dienste, welche über gelegentliche Zugriffe hinausgehen, reichen jedoch die<br />
Festplatten nicht aus. Hier sollten mindestens zwei weitere Festplatten in einem sicheren RAID 1-Verband<br />
hinzugefügt werden. Das bedeutet die Erweiterung um eine PRIMERGY SX30, mit der 14 weitere Festplatten<br />
möglich sind. Die PRIMERGY SX30 ist als ein- oder zweikanalige Ausführung erhältlich. Welcher<br />
PRIMERGY SX30 Version der Vorzug geben wird, hängt vom Einsatzgebiet ab. Im SME-Umfeld, wo neben<br />
den RAID-Verbänden für die <strong>Exchange</strong> Datenbanken weitere RAID-Verbände innerhalb der PRIMERGY<br />
SX30 gebildet werden, empfiehlt sich die zweikanalige Variante mit entsprechendem RAID-Controller.<br />
RAID 1<br />
OS<br />
RAID 1<br />
Queues<br />
RAID 1<br />
AD<br />
RAID 1<br />
Logs<br />
Bei größerem Platten- und Speicherausbau kann diese Konfiguration als dedizierter <strong>Exchange</strong> <strong>Server</strong><br />
durchaus bis zu 700 Benutzer bedienen. Hier empfiehlt es sich, eine einkanalige PRIMERGY SX30 einzusetzen<br />
und gegebenenfalls um eine zweite PRIMERGY SX30 zu ergänzen, wenn weiteres Datenvolumen für<br />
die <strong>Exchange</strong> Datenbanken benötigt wird. Die obige Abbildung zeigt beispielhaft einen Ausbau mit einem 2-<br />
Kanal RAID-Controller und einer PRIMERGY SX30.<br />
Die PRIMERGY TX150 S4 und PRIMERGY SX30 werden alternativ<br />
auch als Rack-Lösung angeboten. Der Einsatzbereich wäre dann<br />
weniger als Office-<strong>Server</strong>, sondern vielmehr als dedizierter <strong>Server</strong> im<br />
Rechenzentrum oder bei einem Application Service Provider (ASP) zu<br />
sehen.<br />
RAID 1+0<br />
Store<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 50 (71)<br />
... 6 ...<br />
... 4 ...<br />
RAID 1+0 or RAID 5<br />
File Sharing, etc
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY TX200 S3<br />
Die PRIMERGY TX200 S3 ist der »größere Bruder«<br />
der PRIMERGY TX150 S4. Ebenfalls im Gewand<br />
eines Tower-<strong>Server</strong>s als Allround-<strong>Server</strong> konzipiert,<br />
bietet sie die Rechenleistung von zwei Intel Xeon<br />
DP dual-core Prozessoren, maximal neun internen<br />
hot-plug Festplatten und einem RAID-fähigen<br />
onboard SCSI-, SATA- oder SAS-Controller. Mit<br />
Hilfe von zwei zusätzlichen 2-Kanal PCI-RAID-<br />
Controllern können extern bis zu vier PRIMERGY<br />
SX30 mit bis zu 56 Festplatten angeschlossen<br />
werden.<br />
Ebenso wie die PRIMERGY TX150 S4 ist auch die<br />
PRIMERGY TX200 S3 in einer Rack-Variante verfügbar,<br />
allerdings dürften für den Einsatz im Rack<br />
die rack-optimierten Systeme PRIMERGY<br />
RX200 S3 bzw. PRIMERGY RX300 S3 bei gleicher<br />
Rechenleistung von größerem Interesse sein.<br />
Als Floorstand-Variante eignet sich die PRIMERGY<br />
Festplatten intern 6 × SAS/SATA (optional 9 × SCSI)<br />
TX200 S3 ideal sowohl für das SME-Segment als<br />
Festplatten extern max. 56<br />
auch für Zweigstellen, wo mehr Rechenleistung be-<br />
onboard LAN 1 × 10/100/1000 Mbit<br />
nötigt wird als ein Mono Prozessor System bieten<br />
kann. In einem solchen Umfeld kommen auf einen<br />
<strong>Server</strong>, wie bereits bei der PRIMERGY TX150 S4 diskutiert, meist noch zusätzliche Aufgaben hinzu. Da in<br />
diesen Umgebungen meist nur ein <strong>Server</strong> installiert wird, muss dieser neben <strong>Exchange</strong> weitere Dienste wie<br />
Active Directory, DNS, File- und Print-Service leisten. Die folgende Abbildung zeigt beispielhaft einen<br />
Ausbau für solche Aufgaben.<br />
RAID 1<br />
OS<br />
RAID 1<br />
Logs<br />
Prozessoren 2 × Xeon DP 5050/5060,<br />
3.0/3.2 GHz, 2 × 2 MB SLC oder<br />
2 × Xeon DP 5110/5120/5130/5140<br />
1.6/1.8/2.0/2.3 GHz, 4 MB SLC<br />
Speicher max. 16 GB<br />
onboard RAID 2-Kanal SCSI oder 2-Port SATA oder<br />
8-Port SAS mit 0-Ch.-RAID-Controller<br />
PCI RAID-Controller 2 × 2-Kanal SCSI<br />
RAID 1<br />
AD<br />
RAID 1+0<br />
Store<br />
Die sechs internen Festplatten werden jeweils paarweise gespiegelt (RAID 1). Das erste System-Drive wird<br />
für das Betriebssystem, das zweite für das Active Directory und das dritte für Queues und Restore verwendet.<br />
Zwei der externen Festplatten sind als RAID 1 für die Aufnahme der Log-Files vorgesehen. Jeweils<br />
sechs Festplatten in einem RAID 10-Verband beherbergen die <strong>Exchange</strong> Datenbanken (Store) und den<br />
Datenbereich für File Sharing. Unter der Bedingung, dass das System USV-gesichert ist, sollten aus<br />
Performance-Gründen die Controller- und Platten-Caches eingeschaltet werden.<br />
Mit diesem Disk-Subsystem sowie zwei Xeon DP 51xx Prozessoren und 3 GB Arbeitsspeicher können<br />
durchaus bis zu 700 Benutzer bedient werden. Je nach Anforderungen an die Plattenkapazität kann auch<br />
mit einer zweiten PRIMERGY SX30 nachgerüstet werden. Als dedizierter <strong>Exchange</strong> <strong>Server</strong>, bei guter CPU-<br />
und Speicherausstattung und dem Einsatz schneller Festplatten mit 15 krpm, lassen sich so durchaus bis zu<br />
1200 Benutzer einer Zweigstelle oder einer mittelständigen Firma bedienen.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 51 (71)<br />
... 6 ...<br />
RAID 1<br />
Queues<br />
... 6 ...<br />
RAID 1+0<br />
File Sharing, etc
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Für eine optimale Ausnutzung des Arbeitsspeichers sollten die BOOT.INI Optionen /3GB und /USERVA verwendet<br />
werden (siehe Kapitel Arbeitsspeicher und Betriebssystem), damit wird der virtuelle Adressraum von<br />
vier Gigabyte zu Gunsten von Anwendungen im Verhältnis 3:1 aufgeteilt – drei Gigabyte für die Anwendung<br />
und ein Gigabyte für den Kernel. Die Standardaufteilung ist 2:2. Bereits ab einem physikalischen Speicherausbau<br />
von einem Gigabyte empfiehlt Microsoft die /3GB-Option zu verwenden. Weitere Details siehe<br />
Microsoft Knowledge Base Artikel Q823440.<br />
Legen wir die zu Beginn dieses Kapitels getroffenen Randbedingungen zugrunde, dass eine Mailbox<br />
maximal 100 MB groß ist und wir den Platzbedarf gelöschter, aber noch nicht aus der Datenbank entfernter<br />
Mails mit dem Faktor zwei ansetzen, so benötigen wir z.B. bei 700 Benutzern<br />
700 User × 100 MB × 2 = 140 GB und bei 1200 Benutzern 1200 User × 100 MB × 2 = 240 GB an Plattenplatz<br />
für die <strong>Exchange</strong> Datenbanken. Eine einzelne Datenbank sollte jedoch nicht größer als 100 GB<br />
werden, da ansonsten die Restore-Zeit einer Datenbank mehr als vier Stunden betragen kann. Um schnelle<br />
Restore-Zeiten zu ermöglichen, sollten daher mehrere kleine Datenbanken bevorzugt werden. Wie bereits in<br />
den Kapiteln Transaktionsprinzip und Backup erläutert, unterstützt <strong>Exchange</strong> <strong>Server</strong> bis zu 20 Datenbanken,<br />
die in Gruppen von maximal fünf Datenbanken in so genannten Storage-Groups (SG) organisiert werden.<br />
Galt für Versionen vor <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> auf Grund von Verwaltungs-Overhead die Regel, die<br />
einzelnen Storage-Groups mit Datenbanken möglichst aufzufüllen, bevor eine weitere Storage-Group<br />
angelegt wird, so ist für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> die Empfehlung, bereits bei mehr als zwei Datenbanken eine<br />
weitere Storage-Group zu eröffnen (vgl. Microsoft Knowledgebase-Artikel Q890699). Wenn organisatorische<br />
Gründe keine andere Aufteilung nahe legen, würde man bei 700 Benutzern eine Storage-Group mit zwei<br />
Datenbanken und bei 1200 Benutzern zwei Storage-Groups mit jeweils zwei Datenbanken verwenden.<br />
Entsprechend der Eingangs getroffenen Annahmen einer Log-File-Größe von 3 MB pro Benutzer und Tag,<br />
wird für 7 Tage ein Plattenplatzbedarf bei 700 Benutzern von ca. 15 GB und bei 1200 Benutzern von ca.<br />
26 GB benötigt. Somit ist es ausreichend, hierfür ein sicheres RAID 1 aus zwei 36 GB Festplatten zu bilden.<br />
Als Backup-Medium eignet sich aufgrund der Datenbankgröße bei 700 Benutzern noch VXA-320 oder LTO2<br />
mit einer Bandkapazität von 160 bzw. 200 GB. Bei 1200 Benutzern sollte ein LTO3 mit einer Bandkapazität<br />
von 400 GB eingesetzt werden, da ansonsten unter Umständen für ein Total-Backup mehr als Band benötigt<br />
wird.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 52 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY RX100 S3<br />
Die PRIMERGY RX100 S3 ist ein Rack-optimierter<br />
<strong>Server</strong>, der nur eine Höheneinheit (1U) im Rack belegt.<br />
Die PRIMERGY RX100 S3 wurde insbesondere für<br />
den Einsatz in <strong>Server</strong>-Farmen, Appliances, Front-end<br />
Lösungen sowie für »hard disk less« Lösungen für<br />
Internet und Application Service Provider (ASP) konzipiert.<br />
Also für Einsatzgebiete, bei denen es wichtig<br />
ist, viele <strong>Server</strong> auf kleinstem Raum einzusetzen.<br />
Die PRIMERGY RX100 S3 bietet intern zwei SATA-<br />
Festplatten mit integriertem RAID 1-Controller. Trotz<br />
der kompakten Bauweise stehen ein PCI-Slot voller<br />
Bauhöhe und ein Low-Profile PCI-Slot mit jeweils halber<br />
Baulänge zur Verfügung.<br />
Prozessoren 1 × Celeron D 346<br />
3.06 GHz, 256 SLC oder<br />
1 × Pentium 4 631<br />
3.0 GHz, 2 MB SLC oder<br />
1 × Pentium D 820<br />
2.8 GHz, 2 × 1 MB SLC oder<br />
1 × Pentium D 930/940/950<br />
3.0/3.2/3.4 GHz, 2 × 2 MB SLC<br />
Speicher max. 8 GB<br />
onboard RAID SATA<br />
Festplatten intern max. 2<br />
Festplatten extern keine<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
Die Rechenleistung ist mit der einer PRIMERGY<br />
TX150 S4 vergleichbar. Aufgrund der Rack-<br />
Optimierung sind die Ausbaumöglichkeiten jedoch eingeschränkt. Die internen Festplatten genügen den<br />
Anforderungen des Betriebssystems. Für die Daten von <strong>Exchange</strong> muss jedoch ein externes Disk-<br />
Subsystem angeschlossen werden. SCSI-RAID-Controller oder Fibre-Channel-Controller lassen sich leider<br />
nicht verwenden. Somit eignet sich die PRIMERGY RX100 S3 lediglich in Verbindung mit einem Network<br />
Attached Storage (NAS) zusammen mit Windows Storage <strong>Server</strong> <strong>2003</strong> oder mit einem iSCSI-fähigen<br />
Storage-System für Zweigstellen oder Application Service Provider (ASP) Rechenzentren, welche auf dieser<br />
Basis ihren Kunden kostengünstige dedizierte <strong>Exchange</strong> <strong>Server</strong> bereitstellen.<br />
In Verbindung mit einem hinreichend ausgestatteten LAN-basierten Disk-Subsystem kann die PRIMERGY<br />
RX100 S3 bis zu 250 Benutzer bedienen. Für den Anschluss von externen Backup-Laufwerken wird entweder<br />
eine PRIMERGY SX10 in Verbindung mit 5¼“-Devices eingesetzt, oder es finden Backup-Devices im<br />
19“-Format Verwendung.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 53 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY RX200 S3<br />
Die PRIMERGY RX200 S3 ist wie die<br />
PRIMERGY RX100 S3 ein auf eine<br />
Höheneinheit (1U) optimierter Compu-<br />
Node. Im Gegensatz zur PRIMERGY<br />
RX100 S3 kann die PRIMERGY RX200 S3<br />
jedoch trotz der geringen Bauhöhe mit zwei<br />
dual-core Prozessoren und vier SAS-<br />
Festplatten aufwarten. Ferner bietet die<br />
PRIMERGY RX200 S3 onboard bereits<br />
einen RAID-fähigen SAS-Controller für die<br />
internen Festplatten und zwei Gigabit LAN-<br />
Schnittstellen. Für einen weiteren Ausbau<br />
kann ein 2-kanaliger RAID-Controller<br />
eingesetzt werden, damit ist sie ideal mit<br />
einer oder zwei PRIMERGY SX30<br />
kombinierbar. Alternativ zu einem SCSIbasierten<br />
Disk-Subsystem kann auch ein<br />
SAN über bis zu zwei 1-kanalige Fibre-<br />
Channel-Controller angeschlossen werden.<br />
Prozessoren 2 × Xeon DP 5050/5060/5080<br />
3.0/3.2/3.73 GHz, 2 × 2 MB SLC oder<br />
2 × Xeon DP<br />
5110/5120/5130/5140/5150/5160<br />
1.66/1.86/2.0/2.33/2.66/3.0 GHz, 4 MB SLC<br />
Speicher Max. 32 GB<br />
onboard RAID SAS / SATA<br />
PCI SCSI-Controller 2 × 1 Kanal<br />
1 × 2 Kanal RAID<br />
Festplatten intern 2 × SAS oder SATA 3½” oder<br />
4 × SAS oder SATA 2½”<br />
Festplatten DAS extern 28<br />
Fibre-Channel max. 2 Kanäle<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
Bei einem Ausbau mit zwei Xeon DP 51xx<br />
Prozessoren und 3 GB Arbeitsspeicher lassen sich mit der PRIMERGY RX200 S3 und einem<br />
angemessenen Ausbau mit einer PRIMERGY SX30 durchaus bis zu 1200 Mail-Benutzer performant<br />
bedienen.<br />
RAID 1<br />
OS, AD<br />
RAID 1<br />
Logs<br />
RAID 1<br />
Queues<br />
RAID 1+0<br />
Store<br />
Hierzu werden über den onboard SAS-Controller die vier internen Festplatten jeweils paarweise gespiegelt<br />
(RAID 1). Das erste logische Laufwerk wird für Betriebssystem und für das Active Directory verwendet, das<br />
zweite logische Laufwerk für Queues und Restore. Die Log-Files werden auf zwei als RAID 1 konfigurierten<br />
externen Festplatten abgelegt. Die verbleibenden acht Festplatten werden zu einem RAID 10 zusammengefasst<br />
und beherbergen die <strong>Exchange</strong> Datenbanken (Store). Hierbei sollten man nicht dem Irrglauben<br />
verfallen, man könne durch Verwendung eines RAID 5 anstelle des RAID 10 oder den Einsatz von<br />
Festplatten größerer Kapazität die Plattenanzahl reduzieren. Die Anzahl der Festplatten berechnet sich aus<br />
den zu erwartenden I/O-Zugriffen pro Sekunde. Im Kapitel Festplatten wurde ausführlich die Leistungsfähigkeit<br />
einzelner Festplatten und RAID-Levels diskutiert. In diesem Szenario für ca. 1200 Benutzer<br />
bedeutet dies für die <strong>Exchange</strong> Datenbanken eine I/O-Rate von 1200 User × 0.6 IO/User/s = 720 IO/s. Legt<br />
man Festplatten mit 15 krpm zugrunde, so benötigt man sechs Festplatten, um diese I/O-Rate zu<br />
befriedigen. Bei Verwendung von Festplatten mit 10 krpm werden acht Stück benötigt.<br />
Unter der Bedingung, dass das System USV-gesichert ist, sollten zu Verbesserung der Performance die<br />
Controller- und die Platten-Caches eingeschaltet werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 54 (71)<br />
... 8 ...
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Alternativ zu einem SCSI-basierten Disk-Subsystem ist es auch möglich, ein Fibre-Channel-basiertes SAN<br />
zu nutzen. Unabhängig vom verwendeten Disk-Subsystem sollte dabei die logische Aufteilung der<br />
Festplatten analog zu der SCSI-Lösung gewählt werden.<br />
Für den Anschluss von externen Backup-Laufwerken wird entweder eine PRIMERGY SX10 in Verbindung<br />
mit 5¼“-Devices eingesetzt, oder es finden Backup-Devices im 19“-Format Verwendung. Aufgrund des<br />
Datenvolumens bei 1200 Benutzern sollte entweder ein LTO3-Laufwerk eingesetzt werden oder eine Tape-<br />
Library, die automatisch die Bänder wechselt.<br />
Für eine optimale Ausnutzung des Arbeitsspeichers sollten die BOOT.INI Optionen /3GB und /USERVA<br />
verwendet werden (siehe Kapitel Arbeitsspeicher und Betriebssystem), damit wird der virtuelle Adressraum<br />
von vier Gigabyte zu Gunsten von Anwendungen im Verhältnis 3:1 aufgeteilt – drei Gigabyte für die Anwendung<br />
und ein Gigabyte für den Kernel. Die Standardaufteilung ist 2:2. Bereits ab einem physikalischen<br />
Speicherausbau von einem Gigabyte empfiehlt Microsoft die /3GB-Option zu verwenden. Weitere Details<br />
siehe Microsoft Knowledge Base Artikel Q823440.<br />
Bei anvisierten 1200 <strong>Exchange</strong> Benutzern wird, bei den zu Beginn des Kapitels definierten<br />
Randbedingungen, ein Platzbedarf von bis zu 1200 User × 100 MB × 2 = 240 GB für die <strong>Exchange</strong><br />
Datenbanken benötigt. Eine einzelne Datenbank sollte jedoch nicht größer als 100 GB werden, da<br />
ansonsten die Restore-Zeit einer Datenbank mehr als vier Stunden betragen kann. Um schnelle Restore-<br />
Zeiten zu ermöglichen, sollten daher mehrere kleine Datenbanken bevorzugt werden. Wie bereits in den<br />
Kapiteln Transaktionsprinzip und Backup erläutert unterstützt <strong>Exchange</strong> <strong>Server</strong> bis zu 20 Datenbanken, die<br />
in Gruppen von maximal fünf Datenbanken in so genannten Storage-Groups (SG) organisiert werden. Galt<br />
für Versionen vor <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> auf Grund von Verwaltungs-Overhead die Regel, die einzelnen<br />
Storage-Groups mit Datenbanken möglichst aufzufüllen, bevor eine weitere Storage-Group angelegt wird, so<br />
ist für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> die Empfehlung, bereits bei mehr als zwei Datenbanken eine weitere Storage-<br />
Group zu eröffnen (vgl. Microsoft Knowledgebase-Artikel Q890699). Wenn organisatorische Gründe keine<br />
andere Aufteilung nahe legen, würde man für 1200 Benutzer zwei Storage-Groups mit jeweils zwei<br />
Datenbanken verwenden.<br />
Für die Log-Files sind 26 GB an Plattenplatzbedarf einzuplanen. Dies ergibt sich aus den Eingangs getroffenen<br />
Annahmen eines Log-File-Bedarfs von 3 MB pro Benutzer und Tag.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 55 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY RX220<br />
Die PRIMERGY RX220 ist wie die PRIMERGY<br />
RX200 S3 ein auf eine Höheneinheit (1U) optimierter<br />
Compu-Node mit zwei Prozessoren. Im Gegensatz<br />
zur auf Intel Xeon Architektur basierenden<br />
PRIMERGY RX200 S3 basiert die PRIMERGY<br />
RX220 auf AMD Opteron Architektur. Die<br />
PRIMERGY RX220 bietet onboard einen RAIDfähigen<br />
SATA-Controller für die beiden internen Hot-<br />
Plug-SATA-Festplatten und zwei Gigabit LAN-<br />
Schnittstellen. Für einen weiteren Ausbau stehen<br />
zwei PCI-Slots zur Verfügung. Des Weiteren kann<br />
ein 2-kanaliger RAID-Controller eingesetzt werden,<br />
damit ist sie ideal mit einer oder zwei PRIMERGY<br />
SX30 kombinierbar. Alternativ findet die PRIMERGY<br />
RX220 auch über einen Fibre-Channel-Controller<br />
Anschluss an ein SAN.<br />
Bei einem Ausbau mit zwei AMD Opteron 280<br />
Prozessoren und 3 GB Arbeitsspeicher lassen sich mit der PRIMERGY RX220 und einem angemessenen<br />
Ausbau mit PRIMERGY SX30 oder einem leistungsmäßig entsprechenden SAN-Disk-Subsystem durchaus<br />
bis zu 1200 Mail-Benutzer performant bedienen.<br />
RAID 1<br />
OS, AD<br />
RAID 1<br />
Queues<br />
Prozessoren 2 × Opteron DP 246 – 256<br />
2.0 - 3.0 GHz, 1 MB SLC oder<br />
2 × Opteron DP 265 – 280<br />
1.8 - 2.4 GHz, 2 × 1 MB SLC<br />
Speicher Max. 28 GB<br />
onboard RAID SATA<br />
PCI SCSI-Controller 1 × 1-Kanal<br />
1 × 2-Kanal RAID<br />
PCI FC-Controller 1 × 2-Kanal<br />
Festplatten intern 2 × SATA 3½”<br />
Festplatten DAS extern Max. 28 SCSI<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
RAID 1<br />
Logs<br />
RAID 1+0<br />
Store<br />
Über den onboard SATA-Controller werden die beiden internen Festplatten gespiegelt (RAID 1) und für das<br />
Betriebssystem und das Active Directory verwendet. Zwei der externen Festplatten sind als RAID 1 für<br />
Queues und Restore vorgesehen. Die Log-Files werden auf zwei weiteren als RAID 1 konfigurierten Festplatten<br />
abgelegt. Die verbleibenden acht Festplatten werden zu einem RAID 10 zusammengefasst und<br />
beherbergen die <strong>Exchange</strong> Datenbanken (Store). Hierbei sollte man aber nicht dem Irrglauben verfallen,<br />
man könne durch Verwendung eines RAID 5 anstelle des RAID 10 oder den Einsatz von Festplatten<br />
größerer Kapazität die Plattenanzahl reduzieren. Die Anzahl der Festplatten berechnet sich aus den zu<br />
erwartenden I/O-Zugriffen pro Sekunde. Im Kapitel Festplatten wurde ausführlich die Leistungsfähigkeit<br />
einzelner Festplatten und RAID-Levels diskutiert. In diesem Szenario für ca. 1200 Benutzer bedeutet dies für<br />
die <strong>Exchange</strong> Datenbanken eine I/O-Rate von 1200 User × 0.6 IO/User/s = 720 IO/s. Legt man Festplatten<br />
mit 15 krpm zugrunde, so benötigt man sechs Festplatten, um diese I/O-Rate zu befriedigen. Bei<br />
Verwendung von Festplatten mit 10 krpm werden acht Stück benötigt.<br />
Unter der Bedingung, dass das System USV-gesichert ist, sollten zu Verbesserung der Performance die<br />
Controller- und die Platten-Caches eingeschaltet werden.<br />
Alternativ zu einem SCSI-basierten Disk-Subsystem ist es auch möglich ein Fibre-Channel-basiertes SAN zu<br />
nutzen. Unabhängig vom verwendeten Disk-Subsystem sollte dabei die logische Aufteilung der Festplatten<br />
analog zu der SCSI-Lösung gewählt werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 56 (71)<br />
... 8 ...
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Für den Anschluss von externen Backup-Laufwerken wird entweder eine PRIMERGY SX10 in Verbindung<br />
mit 5¼“-Devices eingesetzt, oder es finden Backup-Devices im 19“-Format Verwendung. Aufgrund des<br />
Datenvolumens bei 1200 Benutzern sollte entweder ein LTO3-Laufwerk eingesetzt werden oder eine Tape-<br />
Library, die automatisch die Bänder wechselt.<br />
Für eine optimale Ausnutzung des Arbeitsspeichers sollten die BOOT.INI Optionen /3GB und /USERVA<br />
verwendet werden (siehe Kapitel Arbeitsspeicher und Betriebssystem), damit wird der virtuelle Adressraum<br />
von vier Gigabyte zu Gunsten von Anwendungen im Verhältnis 3:1 aufgeteilt – drei Gigabyte für die<br />
Anwendung und ein Gigabyte für den Kernel. Die Standardaufteilung ist 2:2. Bereits ab einem physikalischen<br />
Speicherausbau von einem Gigabyte empfiehlt Microsoft die /3GB-Option zu verwenden. Weitere<br />
Details siehe Microsoft Knowledge Base Artikel Q823440.<br />
Bei anvisierten 1200 <strong>Exchange</strong> Benutzern wird, bei den zu Beginn des Kapitels definierten<br />
Randbedingungen, ein Platzbedarf von bis zu 1200 User × 100 MB × 2 = 240 GB für die <strong>Exchange</strong><br />
Datenbanken benötigt. Eine einzelne Datenbank sollte jedoch nicht größer als 100 GB werden, da<br />
ansonsten die Restore-Zeit einer Datenbank mehr als vier Stunden betragen kann. Um schnelle Restore-<br />
Zeiten zu ermöglichen, sollten daher mehrere kleine Datenbanken bevorzugt werden. Wie bereits in den<br />
Kapiteln Transaktionsprinzip und Backup erläutert, unterstützt <strong>Exchange</strong> <strong>Server</strong> bis zu 20 Datenbanken, die<br />
in Gruppen von maximal fünf Datenbanken in so genannten Storage-Groups (SG) organisiert werden. Galt<br />
für Versionen vor <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> auf Grund von Verwaltungs-Overhead die Regel, die einzelnen<br />
Storage-Groups möglichst mit Datenbanken möglichst aufzufüllen, bevor eine weitere Storage-Group<br />
angelegt wird, so ist für <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> die Empfehlung, bereits bei mehr als zwei Datenbanken eine<br />
weitere Storage-Group zu eröffnen (vgl. Microsoft Knowledgebase-Artikel Q890699). Wenn organisatorische<br />
Gründe keine andere Aufteilung nahe legen, würde man für 1200 Benutzer zwei Storage-Groups mit jeweils<br />
zwei Datenbanken verwenden.<br />
Entsprechend der Eingangs getroffenen Annahmen bzgl. des Umfangs der Log-Daten von 3 MB pro<br />
Benutzer und Tag, wird für sieben Tage und 1200 Benutzer ein Plattenplatzbedarf von 26 GB benötigt.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 57 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY RX300 S3 / TX300 S3<br />
Die PRIMERGY RX300 S3 ist wie die<br />
PRIMERGY RX200 S3 ein rackoptimiertes<br />
dual-core Dual Prozessor<br />
System. Mit ihrer doppelten Bauhöhe von<br />
zwei Höheneinheiten (2U) bietet sie<br />
jedoch einer größeren Anzahl Festplatten<br />
und PCI-Controllern Platz. Somit ist ein<br />
größerer Ausbau mit externen Disk-<br />
Subsystemen möglich.<br />
Die PRIMERGY TX300 S3 bietet vergleichbare<br />
Rechenleistung wie eine<br />
PRIMERGY RX300 S3, ist jedoch aufgrund<br />
ihres größeren Gehäuses für die<br />
Aufnahme von 5¼”-Laufwerken, z.B.<br />
Backup-Medien, geeignet.<br />
Sowohl die PRIMERGY RX300 S3 wie<br />
auch die PRIMERGY TX300 S2 kann mit<br />
zwei 2-Kanal-RAID-Controllern bestückt<br />
werden. Dies ermöglicht den Anschluss<br />
von bis zu vier PRIMERGY SX30 mit insgesamt<br />
56 Festplatten. Ebenso kann über<br />
bis zu sechs Fibre-Channel-Kanäle ein<br />
SAN als externes Disk-Subsystem angebunden<br />
werden.<br />
RX300 S3<br />
Prozessoren 2 × Xeon DP 5050/5060/5080<br />
3.0/3.2/3.73 GHz, 2 × 2 MB SLC oder<br />
2 × Xeon DP 5110/5120/5130/5140/5150/5160<br />
1.66/1.86/2.0/2.33/2.66/3.0 GHz, 4 MB SLC<br />
Speicher max. 32 GB<br />
onboard RAID SAS, optional “MegaRaid ROMB”-Kit<br />
PCI RAID-Controller 2 × 2-Kanal SCSI<br />
PCI FC-Controller 3 × 2-Kanäle<br />
Festplatten intern 6 × 3½" SAS/SATA<br />
Festplatten DAS extern max. 56 SCSI<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
Prozessoren<br />
Speicher max. 32 GB<br />
TX300 S3<br />
2 × Xeon DP 5110/5120/5130/5140/5150/5160<br />
1.66/1.86/2.0/2.33/2.66/3.0 GHz, 4 MB SLC<br />
onboard RAID SAS, optional “MegaRaid ROMB”-Kit<br />
PCI RAID-Controller 1 × 8 Port SAS<br />
2 × 2-Kanal SCSI<br />
PCI FC-Controller 3 × 2-Kanäle<br />
Festplatten intern 6 × 3½" SAS/SATA, optional 8 × 3½"<br />
Festplatten extern max. 56 SCSI<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
Mit zwei Xeon DP 51xx Prozessoren, 4 GB Arbeitsspeicher und einem wohl dimensionierten Disk-<br />
Subsystem mit schnellen 15 krpm Festplatten kann die PRIMERGY RX300 S3 bzw. PRIMERGY TX300 S3<br />
als dedizierter <strong>Exchange</strong> <strong>Server</strong> durchaus bis zu 3000 <strong>Exchange</strong> Benutzer bedienen. Die auf der nächsten<br />
Seite folgende Abbildung zeigt eine Lösung mit einem SCSI-basierten Disk-Subsystem mit einem 2-Kanal<br />
RAID-Controller und zwei PRIMERGY SX30. Natürlich kann anstelle des SCSI-basierten Disk-Subsystems<br />
auch ein SAN verwendet werden. Hinsichtlich der zu verwendenden Anzahl Festplatten und RAID-<br />
Verbänden ergibt sich hieraus jedoch kein Unterschied.<br />
Bei 3000 <strong>Exchange</strong> Benutzern ist bei dem im Kapitel <strong>Exchange</strong> Messmethodik beschriebenen Benutzerprofil<br />
mit einer I/O-Rate von 3000 User × 0.6 IO/User/s = 1800 IO/s zu erwarten. <strong>Exchange</strong> zeigt typischerweise 2 /3<br />
lesende und 1 /3 schreibende Zugriffe. Damit ergeben sich für ein RAID 10 2400 IO/s, die von den Festplatten<br />
verarbeitet werden müssen. Um diese I/O-Rate leisten zu können werden 16 Festplatten mit 15 krpm<br />
benötigt. Auf RAID 5 sollte verzichtet werden. Denn wie bereits im Kapitel Festplatten diskutiert, besitzt jede<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 58 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Festplatte und jeder RAID-Level nur eine gewisse I/O-Leistung. Bei Verwendung eines RAID 5 würde man<br />
22 Festplatten im Vergleich zu nur 16 Festplatten beim RAID 10 benötigen.<br />
Der Platzbedarf für die Mailbox-Inhalte von 3000 <strong>Exchange</strong> Benutzern berechnet sich, bei den zu Beginn<br />
des Kapitels definierten Randbedingungen, zu 3000 User × 100 MB × 2 = 600 GB. Bei 16 Festplatten in<br />
einem oder mehreren RAID 10-Verbänden werden hierzu Festplatten mit einer Kapazität von mindestens<br />
75 GB benötigt. Festplatten mit 73 GB sind also etwas zu klein für 3000 Benutzer, es sollten also Festplatten<br />
mit einer Kapazität von 146 GB und 15 krpm für die Datenbanken (Store) verwendet werden. Für die Log-<br />
Daten ergibt sich bei 3 MB pro Benutzer und Tag über sieben Tage ein Umfang von 63 GB für 3000<br />
Benutzer. Aus Performance- und Datensicherheitsgründen sollte jedoch pro Storage-Group ein dediziertes<br />
Laufwerk für die Log-Files verwendet werden. Da es sich empfiehlt, vier Storage-Groups zu verwenden,<br />
ergibt dies 63 GB / 4 ≈ 16 GB. Daher ist es ausreichend, Festplatten mit der kleinsten verfügbaren Kapazität<br />
von 36 GB zu verwenden.<br />
Eine einzelne Datenbank sollte nicht größer als 100 GB werden, da ansonsten die Restore-Zeit einer Datenbank<br />
mehr als vier Stunden betragen kann. Um schnelle Restore-Zeiten zu ermöglichen, sollten daher<br />
mehrere kleine Datenbanken bevorzugt werden. Es empfiehlt sich daher, sofern andere organisatorische<br />
Gründe nicht dagegen sprechen, vier Storage-Groups mit jeweils zwei Datenbanken zu verwenden.<br />
Bei einem <strong>Exchange</strong> <strong>Server</strong> dieser Größe empfiehlt es sich, pro Storage-Group dedizierte Festplatten für die<br />
Datenbank-Log-Files zu verwenden. Damit ergibt sich folgende Aufteilung des Disk-Subsystems:<br />
RAID 1<br />
Logs SG 1<br />
RAID 1<br />
Logs SG 3<br />
RAID 1<br />
OS<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 1<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 3<br />
RAID 1<br />
Queues<br />
RAID 1<br />
Logs SG 2<br />
RAID 1<br />
Logs SG 4<br />
RAID 1<br />
Restore<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 2<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 4<br />
Die internen sechs Festplatten werden an dem onboard Controller der PRIMERGY RX300 S3 betrieben. Aus<br />
den sechs Festplatten werden drei RAID 1-Pärchen gebildet, eines für das Betriebssystem, eines für die<br />
Queues und ein drittes für Restore. Die PRIMERGY SX30 mit ihren Festplatten werden die <strong>Exchange</strong><br />
Datenbanken und Logs beinhalten. Wir bilden je PRIMERGY SX30 zwei RAID 1-Verbände aus zwei<br />
Festplatten für die Log-Dateien und zwei RAID 10-Verbände aus schnellen Festplatten mit 15 krpm für die<br />
Datenbanken.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 59 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Bei einer Installation dieser Größe sollte das Gesamtsystem bzw. das Rechenzentrum USV-gesichert<br />
werden, so dass die Caches der Controller und Festplatten aktiviert werden können, ohne dass es zu Datenverlusten<br />
bei einem eventuellen Stromausfall kommen kann.<br />
Für eine optimale Ausnutzung des Arbeitsspeichers sollten die BOOT.INI Optionen /3GB und /USERVA verwendet<br />
werden (siehe Kapitel Arbeitsspeicher und Betriebssystem), damit wird der virtuelle Adressraum von<br />
4 GB zu Gunsten von Anwendungen im Verhältnis 3:1 aufgeteilt – 3 GB für die Anwendung und 1 GB für<br />
den Kernel. Die Standardaufteilung ist 2:2. Bereits ab einem physikalischen Speicherausbau von einem<br />
Gigabyte empfiehlt Microsoft die /3GB-Option zu verwenden. Weitere Details siehe Microsoft Knowledge<br />
Base Artikel Q823440.<br />
Bei einem <strong>Exchange</strong> <strong>Server</strong> dieser Größenordnung sollte das Active Directory auf einem dedizierten <strong>Server</strong><br />
platziert werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 60 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY BX600<br />
Die PRIMERGY BX600 ist ein skalierbares 19"-Rack-<strong>Server</strong>system.<br />
Mit nur sieben Höheneinheiten (HE) bietet es Raum<br />
für bis zu zehn <strong>Server</strong> Blades, sowie der gesamten Infrastruktur,<br />
wie Gigabit-LAN-, Fibre-Channel- und KVM-<br />
(Keyboard-Mouse-Video)-Switche und Remote-Management.<br />
Wahlweise kann das PRIMERGY BX600 Rack-<strong>Server</strong>system<br />
mit dem von zwei bis acht Prozessoren skalierbaren<br />
PRIMERGY BX630 Blade mit AMD Opteron Prozessoren<br />
bestückt werden oder mit dem PRIMERGY BX620 S3 Blade<br />
mit Intel Xeon Prozessoren.<br />
PRIMERGY BX620 S3<br />
Die PRIMERGY BX620 S3 ist ein <strong>Server</strong> Blade mit<br />
zwei Intel Xeon Prozessoren. Seine Rechenleistung<br />
ist mit der einer PRIMERGY RX300 S3 vergleichbar.<br />
Jeder PRIMERGY BX620 S3 <strong>Server</strong> Blade bietet<br />
einen onboard SAS/SATA-Controller mit RAID-<br />
Funktionalität, zwei hot-plug 2½" SAS/SATA-Platten<br />
und zwei Gigabit-LAN-Interfaces. Optional kann die<br />
PRIMERGY BX620 S3 mit einem 2-kanaligen Fibre-<br />
Channel-Interface bestückt werden.<br />
PRIMERGY BX630<br />
Die PRIMERGY BX630 ist ein <strong>Server</strong> Blade mit zwei<br />
AMD Opteron Prozessoren. Seine Rechenleistung<br />
ist mit der einer PRIMERGY RX220 vergleichbar.<br />
Die PRIMERGY BX630 bietet zwei hot-plug 3½"-<br />
Festplatten und kann wahlweise mit einem SAS-<br />
oder SATA-Controller bestückt werden. Onboard<br />
sind zwei Gigabit-LAN-Interfaces vorhanden und<br />
optional kann ein 2-kanaliges Fibre-Channel-<br />
Interface bestückt werden.<br />
Die Besonderheit des PRIMERGY BX630 <strong>Server</strong><br />
Blade besteht jedoch in seiner Skalierbarkeit. So<br />
können zwei PRIMERGY BX630 zu einem 4-<br />
Prozessor-System und vier PRIMERGY BX630 zu<br />
einem 8-Prozessor-System gekoppelt werden.<br />
Prozessoren 2 × Xeon DP 5050/5060/5080/5063<br />
3.0/3.2/3.73/3.2 GHz, 2 × 2 MB SLC<br />
2 × Xeon DP 5110/5120/5130/5140<br />
1.6/1.8/2.0/2.3 GHz, 4 MB SLC<br />
Speicher Max. 32 GB<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
onboard RAID SAS/SATA<br />
Festplatten intern 2 × SAS/SATA 2½”<br />
Fibre-Channel 2 × 2 Gbit<br />
Festplatten extern abhängig vom SAN-Disk-Subsystem<br />
Prozessoren 2 × Opteron DP 246 – 256<br />
2.0 – 3.0 GHz, 1MB SLC, oder<br />
2 × Opteron DP 265 – 285<br />
1.8 – 2.6 GHz, 2 × 1MB SLC, oder<br />
2 × Opteron MP 865 – 885<br />
1.8 – 2.6 GHz, 2 × 1MB SLC<br />
Speicher Max. 16 GB<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
onboard RAID SAS/SATA<br />
Festplatten intern 2 × SAS/SATA 3½”<br />
Fibre-Channel 2 × 2 Gbit<br />
Festplatten extern abhängig vom SAN-Disk-Subsystem<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 61 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Die Rechenleistung einer mit zwei AMD Opteron 2xx dual-core Prozessoren ausgestatteten PRIMERGY<br />
BX630 und einer mit zwei Xeon 51xx Prozessoren bestückten PRIMERGY BX620 S3 ist sehr ähnlich und<br />
beide <strong>Server</strong> Blades können als dedizierter <strong>Exchange</strong> <strong>Server</strong> mit einem wohl dimensionierten SAN-Disk-<br />
Subsystem durchaus bis zu 3000 <strong>Exchange</strong> Benutzer bedienen. Die Abbildung zeigt symbolisch eine<br />
FibreCAT CX500, aber natürlich kann auch jedes andere SAN-Disk-Subsystem adäquater Leistung verwendet<br />
werden.<br />
RAID 1<br />
Queues<br />
RAID 1<br />
Logs SG 1<br />
RAID 1<br />
Logs SG 3<br />
RAID 1<br />
OS<br />
RAID 1<br />
Restore<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 1<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 3<br />
RAID 1<br />
Logs SG 2<br />
RAID 1<br />
Logs SG 4<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 2<br />
...<br />
...<br />
4 ...<br />
4 ...<br />
RAID 10<br />
Store SG 4<br />
Bei 3000 <strong>Exchange</strong> Benutzern ist bei dem im Kapitel <strong>Exchange</strong> Messmethodik beschriebenen Benutzerprofil<br />
mit einer I/O-Rate von 0.6 IO/User/s × 3000 User = 1800 IO/s zu erwarten. <strong>Exchange</strong> zeigt typischerweise<br />
2 /3 lesende und 1 /3 schreibende Zugriffe. Damit ergeben sich für ein RAID 10 2400 IO/s, die von den<br />
Festplatten verarbeitet werden müssen. Um diese I/O-Rate leisten zu können, werden 16 Festplatten mit<br />
15 krpm benötigt. Auf RAID 5 sollte verzichtet werden. Denn wie bereits im Kapitel Festplatten diskutiert,<br />
besitzt jede Festplatte und jeder RAID-Level nur eine gewisse I/O-Leistung. Bei Verwendung eines RAID 5<br />
würde man 22 Festplatten im Vergleich zu nur 16 Festplatten beim RAID 10 benötigen.<br />
Der Platzbedarf für die Mailbox-Inhalte von 3000 <strong>Exchange</strong> Benutzern berechnet sich, bei den zu Beginn<br />
des Kapitels definierten Randbedingungen, zu 3000 User × 100 MB × 2 = 600 GB. Bei 16 Festplatten in<br />
einem oder mehreren RAID 10-Verbänden werden hierzu Festplatten mit einer Kapazität von mindestens<br />
75 GB benötigt. Festplatten mit 73 GB sind also etwas zu klein für 3000 Benutzer, es sollten also Festplatten<br />
mit einer Kapazität von 146 GB und 15 krpm für die Datenbanken (Store) verwendet werden.<br />
Eine einzelne Datenbank sollte nicht größer als 100 GB werden, da ansonsten die Restore-Zeit einer Datenbank<br />
mehr als vier Stunden betragen kann. Um schnelle Restore-Zeiten zu ermöglichen, sollten daher<br />
mehrere kleine Datenbanken bevorzugt werden. Es empfiehlt sich daher, sofern andere organisatorische<br />
Gründe nicht dagegen sprechen, vier Storage-Groups mit jeweils zwei Datenbanken zu verwenden. Bei<br />
einem <strong>Exchange</strong> <strong>Server</strong> dieser Größe empfiehlt es sich, pro Storage-Group dedizierte Festplatten für die<br />
Datenbank-Log-Files zu verwenden. Für die Log-Daten ergibt sich bei 3 MB pro Benutzer und Tag über<br />
sieben Tage ein Umfang von 63 GB für 3000 Benutzer. Da es sich empfiehlt, vier Storage-Groups zu<br />
verwenden, ergibt dies 63 GB / 4 ≈ 16 GB. Daher ist es ausreichend, Festplatten mit der kleinsten verfügbaren<br />
Kapazität von 36 GB zu verwenden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 62 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Die beiden internen Festplatten werden als RAID 1 an dem onboard SAS- oder SATA-Controller der<br />
PRIMERGY BX620 S3 bzw. PRIMERGY BX630 betrieben und dienen der Aufnahme des Betriebssystems.<br />
Im SAN werden zwei RAID 1-Verbände für Queues und Restore gebildet, des Weiteren jeweils vier RAID 1-<br />
Verbände für die Log-Files und vier RAID 10-Verbände aus schnellen Festplatten mit 15 krpm für die<br />
Datenbanken.<br />
Bei einer Installation dieser Größe sollte das Gesamtsystem bzw. das Rechenzentrum USV-gesichert<br />
werden, so dass die Caches der Controller und Festplatten aktiviert werden können, ohne dass es zu Datenverlusten<br />
bei einem eventuellen Stromausfall kommen kann.<br />
Für eine optimale Ausnutzung des Arbeitsspeichers sollten die BOOT.INI Optionen /3GB und /USERVA<br />
verwendet werden (siehe Kapitel Arbeitsspeicher und Betriebssystem), damit wird der virtuelle Adressraum<br />
von 4 GB zu Gunsten von Anwendungen im Verhältnis 3:1 aufgeteilt – 3 GB für die Anwendung und 1 GB für<br />
den Kernel. Die Standardaufteilung ist 2:2. Bereits ab einem physikalischen Speicherausbau von einem<br />
Gigabyte empfiehlt Microsoft die /3GB-Option zu verwenden. Weitere Details siehe Microsoft Knowledge<br />
Base Artikel Q823440.<br />
Bei einem <strong>Exchange</strong> <strong>Server</strong> dieser Größenordnung sollte das Active Directory auf einem dedizierten <strong>Server</strong><br />
platziert werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 63 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Kombiniert man zwei PRIMERGY BX630 <strong>Server</strong> Blades zu einem 4-Prozessor-System, so lassen sich bei<br />
einem Ausbau mit vier AMD Opteron 8xx dual-core Prozessoren, 4 GB Arbeitsspeicher und einem<br />
adäquaten Disk-Subsystem 5000 bis 6000 Benutzer bedienen.<br />
RAID 1<br />
Queues<br />
RAID 1<br />
Logs SG 1<br />
RAID 1<br />
Logs SG 3<br />
RAID 1<br />
OS<br />
RAID 1<br />
Restore<br />
...<br />
...<br />
6 ...<br />
4 ...<br />
RAID 10<br />
Store SG 1<br />
...<br />
...<br />
6 ...<br />
4 ...<br />
RAID 10<br />
Store SG 3<br />
RAID 1<br />
Logs SG 2<br />
RAID 1<br />
Logs SG 4<br />
...<br />
...<br />
6 ...<br />
4 ...<br />
RAID 10<br />
Store SG 2<br />
...<br />
...<br />
6 ...<br />
4 ...<br />
RAID 10<br />
Store SG 4<br />
Das Disk-Subsystem unterscheidet sich zu der auf der vorangegangen Seite gezeigten Konfiguration mit<br />
3000 Benutzern im wesentlichen in einer größeren Anzahl an Festplatten für die Datenbanken von<br />
<strong>Exchange</strong> (Store). Die große Anzahl von 24 Festplatten mit 15 krpm ist notwendig, um die höhere I/O-Rate,<br />
die durch ein mehr von 2000 Benutzern induziert wird, zu bewältigen. Des Weiteren müssen natürlich die<br />
Festplatten für Queues, Restore und Log-Files kapazitätsmäßig an die höheren Bedürfnisse angepasst<br />
werden.<br />
Die PRIMERGY BX630 kann wie bereits beschrieben bis zu einem 8-Prozessor-System durch Kombination<br />
von vier PRIMERGY BX630 <strong>Server</strong> Blades skaliert werden. Jedoch kann diese geballte Rechenleistung von<br />
<strong>Exchange</strong> als reine 32-bit Anwendung, die keinen Gebrauch von PAE macht, nicht sinnvoll genutzt werden.<br />
Eine Skalierung über die bereits mit einem 4-Prozessor-System bedienbaren 5000 bis 6000 Benutzer hinaus<br />
ist nicht gegeben. Für eine Skalierung von <strong>Exchange</strong> über 5000 Benutzer sollte stattdessen besser ein<br />
Scale-Out-Szenario verwendet werden und weitere <strong>Exchange</strong> <strong>Server</strong> auf 2- oder 4-Prozessor-Systemen<br />
installiert werden. Vgl. auch Kapitel <strong>Exchange</strong> Architektur.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 64 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY RX600 S3 / TX600 S3<br />
Die PRIMERGY RX600 S3 und PRIMERGY<br />
TX600 S3 stellen mit vier Prozessoren und<br />
weiträumigen Ausbaumöglichkeiten von Speicher<br />
und PCI-Controllern eine Basis für große<br />
Applikationsserver dar. Die PRIMERGY<br />
RX600 S3 und PRIMERGY TX600 S3 unterscheiden<br />
sich nur hinsichtlich der Gehäuse-<br />
Form. Die PRIMERGY RX600 S3 ist als reine<br />
Recheneinheit für den Rack-Einbau auf vier<br />
Höheneinheiten (4U) optimiert, wohingegen die<br />
PRIMERGY TX600 S3 sechs Höheneinheiten<br />
(6U) belegt. Dafür bietet die PRIMERGY<br />
TX600 S3 aber auch weiteren fünf Festplatten<br />
und bedienbaren 5¼“-Geräten Platz. Die<br />
PRIMERGY TX600 S3 ist ferner in einer<br />
Floorstand-Version erhältlich.<br />
Obwohl diese <strong>Server</strong> bis zu 64 GB Speicher<br />
aufnehmen können, ist für <strong>Exchange</strong> als reine<br />
32-bit Anwendung nur ein Ausbau von 4 GB<br />
sinnvoll (vgl. Abschnitt Arbeitsspeicher). Damit<br />
sind auch der Skalierung eines <strong>Exchange</strong><br />
<strong>Server</strong>s Grenzen gesetzt. mehr als 5000 bis<br />
6000 Benutzer lassen sich auf einem einzelnen<br />
<strong>Exchange</strong> <strong>Server</strong> nicht sinnvoll betreiben.<br />
Aufgrund der Speicherlimitierung macht sich<br />
eine höhere Benutzerzahl insbesondere in erhöhten<br />
Zugriffen auf die <strong>Exchange</strong> Datenbanken<br />
bemerkbar. So schlägt insbesondere die zusätzliche<br />
Last bei 6000 anstelle von 5000 Benutzern<br />
voll auf das Disk-Subsystem durch, da mangels<br />
Arbeitsspeicher der <strong>Exchange</strong> <strong>Server</strong> Datenbankzugriffe<br />
nicht ausreichend puffern kann.<br />
Möchte man einen derart großen monolithischen<br />
<strong>Exchange</strong> <strong>Server</strong> betreiben, so sollte man ein<br />
leistungsfähiges und großzügig dimensioniertes<br />
Fibre-Channel-basiertes Disk-Subsystem wählen,<br />
das durch einen Disk-Subsystem-seitigen<br />
Cache Lastspitzen entkoppeln kann.<br />
Bis 5000 Benutzer kann durchaus auch noch ein<br />
SCSI-basiertes Direct Attached Storage (DAS)<br />
Subsystem verwendet werden, wie auf der folgenden<br />
Seite gezeigt wird. Eine Konfiguration<br />
mit einem Fibre-Channel-basierten Disk-Subsystem<br />
für 5000 Benutzer wurde bereits im<br />
vorangegangenen Kapitel PRIMERGY BX600<br />
gezeigt.<br />
RX600 S3<br />
Prozessoren 4 × Xeon MP<br />
3.16/3.66 GHz, 1 MB SLC, oder<br />
4 × Xeon MP 7020/7030<br />
2.67/2.80 GHz, 2 × 1 MB SLC, oder<br />
4 × Xeon MP 7041<br />
3.0 GHz, 2 x 2 MB SLC<br />
Speicher max. 64 GB<br />
onboard RAID 2-Kanal SCSI<br />
PCI RAID-Controller bis zu 2 × 2-Kanal SCSI<br />
PCI FC-Controller bis zu 4 × 2-Kanal<br />
Festplatten intern max. 5<br />
Festplatten DAS extern max. 56<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
TX600 S3<br />
Prozessoren 4 × Xeon MP<br />
3.16/3.66 GHz, 1 MB SLC, oder<br />
4 × Xeon MP 7020/7030<br />
2.67/2.80 GHz, 2 x 1 MB SLC, oder<br />
4 × Xeon MP 7041<br />
3.0 GHz, 2 x 2 MB SLC<br />
Speicher max. 64 GB<br />
onboard RAID 2-Kanal SCSI<br />
PCI RAID-Controller 2 × 2-Kanal SCSI<br />
PCI FC-Controller bis zu 4 × 2-Kanal<br />
Festplatten intern max. 10<br />
Festplatten DAS extern max. 56<br />
onboard LAN 2 × 10/100/1000 Mbit<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 65 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Für 5000 Benutzer sollte die PRIMERGY RX600 S3 bzw. PRIMERGY TX600 S3 mit vier Prozessoren Xeon<br />
7041 und 4 GB Arbeitsspeicher ausgestattet werden. Mit dem im Kapitel <strong>Exchange</strong> Messmethodik<br />
beschriebenen Benutzerprofil ist eine I/O-Rate von 5000 User × 0.6 IO/User/s = 3000 IO/s zu erwarten.<br />
<strong>Exchange</strong> zeigt typischerweise 2 /3 lesende und 1 /3 schreibende Zugriffe. Damit ergeben sich für ein RAID 10<br />
4000 IO/s, die von den Festplatten verarbeitet werden müssen. Um diese I/O-Rate leisten zu können,<br />
werden 24 Festplatten mit 15 krpm benötigt. Auf RAID 5 sollte verzichtet werden. Denn wie bereits im Kapitel<br />
Festplatten diskutiert, besitzt jede Festplatte und jeder RAID-Level nur eine gewisse I/O-Leistung. Bei<br />
Verwendung eines RAID 5 würde man 36 Festplatten im Vergleich zu nur 24 Festplatten beim RAID 10<br />
benötigen.<br />
Der Platzbedarf für die Mailbox-Inhalte von 5000 <strong>Exchange</strong> Benutzern berechnet sich, bei den zu Beginn<br />
des Kapitels definierten Randbedingungen, zu 5000 User × 100 MB × 2 = 1 TB. Bei 24 Festplatten in einem<br />
oder mehreren RAID 10-Verbänden werden hierzu Festplatten mit einer Kapazität von mindestens 84 GB<br />
benötigt. Es sollten also Festplatten mit einer Kapazität von 146 GB und 15 krpm für die Datenbanken<br />
(Store) verwendet werden.<br />
Eine einzelne Datenbank sollte nicht größer als 100 GB werden, da ansonsten die Restore-Zeit einer Datenbank<br />
mehr als vier Stunden betragen kann. Um schnelle Restore-Zeiten zu ermöglichen, sollten daher<br />
mehrere kleine Datenbanken bevorzugt werden. Es empfiehlt sich daher, sofern andere organisatorische<br />
Gründe nicht dagegen sprechen, vier Storage-Groups mit jeweils drei Datenbanken zu verwenden.<br />
Für die Log-Files sind bei 5000 Benutzern ca. 105 GB einzuplanen, sofern man die zu Beginn des Kapitels<br />
getroffene Annahme von 3 MB pro Benutzer und Tag, bei einer Log-File-Bevorratung von 7 Tagen, zugrunde<br />
legt. Es empfiehlt sich, für jede Storage-Group aus Performance- und Datensicherheitsgründen ein<br />
separates Laufwerk für die Log-Files einzurichten. Bei vier Storage-Groups werden dafür<br />
105 GB / 4 ≈ 27 GB je Log-File-Volume benötigt. Es sind daher ausreichend Festplatten mit einer Kapazität<br />
von 36 GB zu verwenden.<br />
Bei einem <strong>Exchange</strong> <strong>Server</strong> dieser Größe empfiehlt es sich, pro Storage-Group dedizierte Festplatten für die<br />
Datenbank-Log-Files zu verwenden. Damit ergibt sich folgende Aufteilung des Disk-Subsystems:<br />
RAID 1<br />
OS<br />
RAID 1<br />
Logs<br />
RAID 1<br />
Queues<br />
Restore<br />
Die internen Festplatten der PRIMERGY RX600 S3 werden an dem onboard SAS-Controller betrieben. Es<br />
wird ein RAID 1-Verband für das Betriebssystem verwendet und ein zweiter RAID 1-Verband für die SMTP-<br />
Queues. Die fünfte Festplatte ist als temporärerer Plattenplatz für Restores vorgesehen, und da hier nur<br />
temporäre Daten liegen, ist es nicht notwendig diese zu spiegeln.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 66 (71)<br />
... 6 ...<br />
... 6 ...<br />
... 6 ...<br />
... 6 ...<br />
RAID 10<br />
Stores
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Die beiden 2-Kanal RAID-Controller steuern die vier einkanaligen PRIMERGY SX30. Je PRIMERGY SX30<br />
wird ein RAID 1-Verband für die Log-Files und ein RAID 10 aus sechs schnellen Festplatten mit 15 krpm für<br />
die Datenbanken eingerichtet.<br />
Bei einem <strong>Exchange</strong> <strong>Server</strong> dieser Größenordnung sollten dedizierte <strong>Server</strong> für das Active Directory<br />
verwendet werden, so dass in diesem System keine Festplatten für die Datenbank des Active Directories<br />
vorzusehen sind.<br />
Ferner sollte ein <strong>Exchange</strong> <strong>Server</strong> dieser Dimension gegen Stromausfälle mit einer USV gesichert werden.<br />
Dann können auch bedenkenlos die Caches der Controller und Festplatten zur Steigerung der Performance<br />
eingeschaltet werden.<br />
Für eine optimale Ausnutzung des Arbeitsspeichers müssen die BOOT.INI Optionen /3GB und /USERVA<br />
verwendet werden (siehe Kapitel Arbeitsspeicher und Betriebssystem), damit wird der virtuelle Adressraum<br />
von 4 GB zu Gunsten von Anwendungen im Verhältnis 3:1 aufgeteilt – 3 GB für die Anwendung und 1 GB für<br />
den Kernel. Die Standardaufteilung ist 2:2. Da <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> etwa das 1.8-fache an virtuellem<br />
Adressraum gegenüber physikalischem Speicher benötigt, würde, bei einer Standardaufteilung von 2 GB für<br />
Anwendungen, <strong>Exchange</strong> den physikalischen Speicher von 2 GB nicht nutzen können, sondern nur 1.1 GB.<br />
Vergleichsmessungen mit und ohne /3GB haben hier einen Performance-Gewinn von 28% gezeigt. Weitere<br />
Details siehe Microsoft Knowledge Base Artikel Q823440.<br />
Es ist Eigenschaft des Chipsatzes dieses Systems, den Adressbereich von 3 bis 4 GB vollständig für die<br />
Adressierung von Controllern zu reservieren. Damit ein in diesem Adressbereich liegender physikalischer<br />
Speicher trotzdem verwendet werden kann, kann er vom Chipsatz im Adressbereich von 4 bis 5 GB wieder<br />
eingeblendet werden. Deshalb sollte bei einer Ausstattung von mehr als 3 GB physikalischem Speicher,<br />
entgegen den Empfehlungen an anderer Stelle, PAE aktiviert werden, um den Speicherbereich oberhalb von<br />
4 GB adressieren zu können.<br />
Weitere Hinweise zur Optimierung großer <strong>Exchange</strong> <strong>Server</strong> können dem Microsoft Knowledge Base Artikel<br />
Q815372 entnommen werden.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 67 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
PRIMERGY RX800 S2<br />
Die PRIMERGY RX800 S2 ist ein Topmodell der<br />
PRIMERGY Familie. In Schritten von jeweils vier<br />
Prozessoren lässt sich die PRIMERGY RX800 S2 vom<br />
4-Prozessor- bis hin zum 16-Prozessor-System skalieren.<br />
Im Vollausbau stehen bis zu 256 GB Arbeitsspeicher<br />
zur Verfügung.<br />
Leider macht <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> mit seiner<br />
Limitierung hinsichtlich Arbeitsspeichernutzung und der<br />
starken Abhängigkeit zum Disk-I/O nicht im vollen<br />
Umfang von der möglichen Rechenleistung einer<br />
PRIMERGY RX800 S2 Gebrauch. Im Umfeld der standalone<br />
<strong>Exchange</strong> <strong>Server</strong> wird die PRIMERGY RX800 S2<br />
daher kaum zum Einsatz kommen.<br />
Prozessoren 4 - 16 × Xeon MP 7020<br />
2.67 GHz, 2 × 1 MB SLC, oder<br />
4 - 16 × Xeon MP 7040<br />
3.0 GHz, 2 × 2 MB SLC<br />
Speicher max. 265 GB<br />
onboard RAID SAS<br />
PCI RAID-Controller 16 × 2-Kanal SCSI<br />
PCI FC-Controller bis zu 6 × 1-Kanal<br />
Festplatten intern 6 × SAS<br />
Die PRIMERGY RX800 S2 ist jedoch ein adäquates onboard LAN 2 × 10/100/1000 Mbit per Unit<br />
System für den Aufbau hochverfügbarer high-end<br />
<strong>Exchange</strong>Cluster auf der Basis von Windows <strong>Server</strong> <strong>2003</strong> Datacenter Edition. Unter Windows <strong>Server</strong> <strong>2003</strong><br />
Datacenter Edition können bis zu acht PRIMERGY RX800 S2 gemeinsam in einem Cluster operieren. Dabei<br />
werden typischerweise sechs oder sieben <strong>Server</strong> aktiv betrieben und ein oder zwei <strong>Server</strong> passiv, so dass<br />
diese einspringen können, wenn einer der aktiven <strong>Server</strong> im Cluster ausfällt. Auf diesem Modell kann ein<br />
hochverfügbarer <strong>Exchange</strong> Cluster realisiert werden, der bis zu ca. 35000 (7 × 5000) aktive Benutzer<br />
bedienen kann.<br />
PRIMERGY RXI300 / RXI600<br />
Die PRIMERGY RXI300 und PRIMERGY RXI600<br />
basieren auf Intels modernster 64-bit Plattform mit<br />
Itanium®2 Prozessorarchitektur. Da aber <strong>Exchange</strong><br />
<strong>Server</strong> <strong>2003</strong> bislang nicht in einer 64-bit Version<br />
verfügbar ist, ist ein <strong>Exchange</strong> <strong>Server</strong> auf Basis einer<br />
PRIMERGY RXI300 oder PRIMERGY RXI600 nicht<br />
möglich.<br />
Prozessoren 2 oder 4 × Itanium2<br />
1.5 GHz, 4 MB TLC<br />
1.6 GHz, 9 MB TLC<br />
Speicher 16 oder 32 GB<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 68 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Zusammenfassung<br />
Fassen wir die im vorangegangen<br />
diskutierten<br />
Ergebnisse noch mal<br />
übersichtlich zusammen,<br />
so ergibt sich nebenstehendes<br />
Bild. (Hinweis: die<br />
horizontale Achse ist nicht<br />
linear unterteilt.) Man erkennt<br />
sofort, dass sich<br />
viele PRIMERGY Systeme<br />
hinsichtlich ihrer<br />
Leistungsfähigkeit bzgl.<br />
<strong>Exchange</strong> überlappen<br />
oder gar ebenbürtig sind.<br />
Eine gut ausgestattete<br />
PRIMERGY RX300 S3<br />
kann ebenso viele Benutzer<br />
bedienen wie ein<br />
kleiner Ausbau einer<br />
PRIMERGY RX600 S3.<br />
Harte Grenzen gibt es<br />
nicht, da wie bereits eingangs<br />
intensiv diskutiert,<br />
die reale Benutzerzahl<br />
von dem kundenspezifischen<br />
Lastprofil abhängt.<br />
In der Grafik wird dieser<br />
PRIMERGY<br />
RX100 S3<br />
Econel 200<br />
Econel 100<br />
TX150 S4<br />
RX220<br />
RX200 S3<br />
TX200 S3<br />
Sachverhalt durch den Farbverlauf der Balken dargestellt.<br />
RX300 S3<br />
TX300 S3<br />
TX600 S3<br />
RX600 S3 Cluster<br />
BX600 Cluster<br />
RX300 S3 Cluster<br />
BX630 dual<br />
BX620 S3<br />
BX630 quad<br />
RX600 S3<br />
RX800 Cluster<br />
Cluster<br />
Solutions<br />
Blade<br />
Solutions<br />
Rack<br />
Solutions<br />
Tower<br />
Solutions<br />
Economy<br />
Solutions<br />
50 100 250 500 1000 1500 2500 5000 15000 35000 User<br />
Welches System letztendlich am Besten geeignet ist, hängt von den Kundenanforderungen ab. Ist<br />
beispielsweise Floorstand oder Rack erwünscht, soll das Backup mit <strong>Server</strong>-internen oder -externen Geräten<br />
erfolgen, ist Ausbaufähigkeit wegen Wachstumspotential gewünscht und vieles mehr.<br />
Unabhängig von der Leistungsfähigkeit der Hardware ist aufgrund von Limitierungen in der <strong>Exchange</strong><br />
Software bei ca. 5000 aktiven Benutzern pro <strong>Server</strong> die maximale Skalierung im Scale-Up-Szenario erreicht.<br />
Eine größere Anzahl Benutzer lassen sich durch weitere <strong>Server</strong> in einem Scale-Out-Szenario erreichen. Hier<br />
ist es sinnvoll, geclusterte Lösungen einzusetzen, da diese zusätzlich noch eine Redundanz gegen<br />
Hardware-Ausfälle bieten. Auf diese Weise lassen sich Cluster für bis zu ca. 35000 Benutzer aufbauen.<br />
Bei der Dimensionierung eines <strong>Exchange</strong> <strong>Server</strong>s bedarf es aber in jedem Fall der Analyse der Kundenanforderungen<br />
und der vorhandenen Infrastruktur, wie Netzwerk, Active Directory, etc. Diese sind dann mit<br />
Bedacht in die Planung des <strong>Exchange</strong> <strong>Server</strong>s und der <strong>Exchange</strong> Umgebung einzubeziehen. Einige<br />
Einflüsse, wie Datenvolumen bei Backup, kann man direkt berechnen, andere Einflüsse kann man nur<br />
abschätzen bzw. auf Erfahrungswerten aufbauend abwägen. Daher ist beim Aufbau eines mittleren bis<br />
großen <strong>Exchange</strong> <strong>Server</strong>s eine detaillierte Planung und Beratung dringend zu empfehlen.<br />
Es sei an dieser Stelle nochmals explizit darauf hingewiesen, dass alle Daten, die den Aussagen in diesem<br />
Papier zugrunde liegen, zwar auf Basis des Medium-Benutzerprofils der Simulationssoftware LoadSim<br />
ermittelt wurden, dabei jedoch nicht nach dem ultimativ höchst möglichen Wert gestrebt und optimiert wurde.<br />
Allen Messungen lagen gegen Hardwareausfall geschützte RAID-Systeme zugrunde. Des Weiteren stand<br />
auf allen Systemen zusätzlich ausreichend Rechenleistung für aktiven Virenschutz und Backup zur<br />
Verfügung. Unser Mitbewerb nennt sehr häufig für die Leistungsfähigkeit seiner Systeme Benchmarkergebnisse.<br />
Diese beruhen jedoch im Allgemeinen auf unsicheren RAID 0-Arrays und lassen keinerlei Raum<br />
für Virenschutz, <strong>Server</strong>-Management oder ähnliches.<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 69 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Literatur<br />
[L1] Allgemeine Informationen zu Produkten von <strong>Fujitsu</strong><br />
http://de.ts.fujitsu.com<br />
[L2] Allgemeine Informationen zur PRIMERGY Produktfamilie<br />
http://de.ts.fujitsu.com/primergy<br />
[L3] PRIMERGY Benchmarks – Performance Reports und <strong>Sizing</strong> <strong>Guide</strong>s<br />
http://de.ts.fujitsu.com/products/standard_servers/primergy_bov.html<br />
[L4] Performance Report iSCSI and iSCSI Boot<br />
http://docs.ts.fujitsu.com/dl.aspx?id=c7d8d1c0-f2d5-438f-9263-b7b49a37a04f<br />
[L5] Performance Report Modular RAID<br />
http://docs.ts.fujitsu.com/dl.aspx?id=2d0d20d8-7c14-407c-b904-6112f4c7821c<br />
[L6] Microsoft <strong>Exchange</strong> <strong>Server</strong><br />
http://www.microsoft.com/exchange/default.mspx<br />
[L7] What's new in <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
http://www.microsoft.com/downloads/details.aspx?FamilyID=84236bd9-ac54-4113-b037c04a96a977fd&DisplayLang=en<br />
[L8] Performance Benchmarks for Computers Running <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
http://technet.microsoft.com/en-us/library/cc507123.aspx<br />
[L9] Downloads for <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong><br />
http://technet.microsoft.com/en-us/exchange/bb288488.aspx<br />
[L10] <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Technical Documentation Library<br />
http://www.microsoft.com/technet/prodtechnol/exchange/<strong>2003</strong>/library<br />
[L11] <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Performance and Scalability <strong>Guide</strong><br />
http://www.microsoft.com/technet/prodtechnol/exchange/<strong>2003</strong>/library/perfscalguide.mspx<br />
[L12] Troubleshooting <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Performance<br />
http://www.microsoft.com/technet/prodtechnol/exchange/<strong>2003</strong>/library/e2k3perf.mspx<br />
[L13] <strong>Exchange</strong> 2000 <strong>Server</strong> Resource Kit<br />
http://www.microsoft.com/technet/prodtechnol/exchange/2000/library/reskit/default.mspx<br />
[L14] System Center Capacity Planner 2006<br />
http://www.microsoft.com/windowsserversystem/systemcenter/sccp/default.mspx<br />
[L15] Microsoft Operations Manager<br />
http://www.microsoft.com/mom/default.mspx<br />
[L16] Windows Small Business <strong>Server</strong> <strong>2003</strong><br />
http://www.microsoft.com/windowsserver<strong>2003</strong>/sbs<br />
[L17] Windows <strong>Server</strong> <strong>2003</strong> Active Directory<br />
http://www.microsoft.com/windowsserver<strong>2003</strong>/technologies/directory/activedirectory/default.mspx<br />
[L18] Physical Address Extension - PAE Memory and Windows<br />
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx<br />
[L19] Microsoft TechNet<br />
http://technet.microsoft.com<br />
© <strong>Fujitsu</strong> Technology Solutions, 2009 Seite 70 (71)
White Paper <strong>Sizing</strong> <strong>Guide</strong> <strong>Exchange</strong> <strong>Server</strong> <strong>2003</strong> Version: 4.2, July 2006<br />
Dokument Historie<br />
Version Erscheinungsdatum <strong>Exchange</strong> Version<br />
Version 1.0 März 1997 4.0<br />
Version 2.0 Juli 1999 5.5<br />
Version 3.0 Februar 2002 2000<br />
Version 3.1 September 2002 2000<br />
Version 4.0 Februar 2004 <strong>2003</strong><br />
Version 4.1 Juli 2006 <strong>2003</strong><br />
Version 4.2 Juli 2006 <strong>2003</strong><br />
Kontakt<br />
PRIMERGY Performance und Benchmarks<br />
mailto:primergy.benchmark@ts.fujitsu.com<br />
PRIMERGY Produkt Marketing<br />
mailto:Primergy-PM@ts.fujitsu.com<br />
Lieferung vorbehaltlich Verfügbarkeit, technische Änderungen ohne<br />
Vorankündigung möglich, Korrektur von Irrtümern und Auslassungen<br />
vorbehalten.<br />
Alle angegebenen Konditionen (TCs) sind empfohlene Einstandspreise in<br />
Euro ohne MwSt. (sofern im Text nicht anderweitig angegeben). Sämtliche<br />
verwendete Hardware- und Software- Namen sind Handelsnamen und/oder<br />
Warenzeichen ihrer jeweiligen Hersteller.<br />
Herausgegeben durch:<br />
Enterprise Products<br />
PRIMERGY <strong>Server</strong><br />
PRIMERGY Performance Lab<br />
mailto:primergy.benchmark@ts.fujitsu.com<br />
Internet:<br />
http://ts.fujitsu.com/primergy<br />
Extranet:<br />
http://partners.ts.fujitsu.com/com/produc<br />
ts/servers/primergy<br />
©<br />
Copyright<br />
<strong>Fujitsu</strong><br />
©<br />
Technology<br />
<strong>Fujitsu</strong> Technology<br />
Solutions,<br />
Solutions<br />
2009<br />
GmbH 2009<br />
Seite 71 (71)