Sizing Guide Exchange Server 2003

Transcription

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

Sizing Guide Exchange Server 2003

Transcription

Similar documents

- Detecon

Terminal Server Sizing Guide

Terminal Server Sizing Guide

Inhalt Editorial - Comment

Ökologischer Vergleich der Klimarelevanz von PC und Thin Client

Ausgabe - Wochenspiegel

Facharbeit Datenschutz und Datensicherheit - ice

Installation Administration Netzeinbindung