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

Exchange Server 2003

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)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

Exchange Server 2003 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: Exchange Server 2003 Standard Edition Exchange Server 2003 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.

© Fujitsu Technology Solutions, 2009

Seite 3 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

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)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 5 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 6 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 7 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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]

© Fujitsu Technology Solutions, 2009

-

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)

White Paper Sizing Guide

Exchange Server 2003

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.

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 9 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 10 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 11 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 12 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 13 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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

© Fujitsu Technology Solutions, 2009

Seite 14 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 15 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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-

© Fujitsu Technology Solutions, 2009

# 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)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 17 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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-

© Fujitsu Technology Solutions, 2009

Seite 18 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 19 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 20 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 21 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 22 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Durchsatz in MB/s

Seite 23 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 24 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 25 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 26 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 27 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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

© Fujitsu Technology Solutions, 2009

Seite 28 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Es können mehrere VSS Requestoren und mehrere VSSProvider für verschiedene Volumes nebeneinander existieren.

Seite 29 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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

© Fujitsu Technology Solutions, 2009

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)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

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)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 32 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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

© Fujitsu Technology Solutions, 2009

Backup Software

Backup Server

Seite 33 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 34 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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].

© Fujitsu Technology Solutions, 2009

Seite 35 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 36 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 37 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 38 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 39 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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 \\\SMTP Server(_Total)\Remote Queue Length

Dabei ist in Abhängigkeit der Konfiguration der zu überwachende 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) : auszuwählen.

© Fujitsu Technology Solutions, 2009

Seite 40 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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).

© Fujitsu Technology Solutions, 2009

Seite 41 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

Logical Disk LogicalDisk(:)\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(:)\Avg. Disk sec/Read LogicalDisk(:)\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(:)\Disk Reads/sec LogicalDisk(:)\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.

© Fujitsu Technology Solutions, 2009

Seite 42 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 43 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 44 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 45 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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

© Fujitsu Technology Solutions, 2009

Seite 46 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 47 (71)

White Paper Sizing Guide

Exchange Server 2003

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.

Version: 4.2, July 2006

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. 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). 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.

© Fujitsu Technology Solutions, 2009

Seite 48 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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. 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). 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

© Fujitsu Technology Solutions, 2009

Seite 49 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 50 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 51 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 52 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 53 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 54 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 55 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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½”

Festplatten DAS extern

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.

© Fujitsu Technology Solutions, 2009

Seite 56 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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 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.

© Fujitsu Technology Solutions, 2009

Seite 57 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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

Festplatten DAS extern

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

© Fujitsu Technology Solutions, 2009

Seite 58 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 59 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 60 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 61 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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. 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. 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. 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.

© Fujitsu Technology Solutions, 2009

Seite 62 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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. 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.

© Fujitsu Technology Solutions, 2009

Seite 63 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 64 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

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

Festplatten DAS extern

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

Festplatten DAS extern

max. 56

onboard LAN

2 × 10/100/1000 Mbit

TX600 S3

Seite 65 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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. Der Platzbedarf für die Mailbox-Inhalte von 5000 Exchange Benutzern berechnet sich, bei den zu Beginn 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. 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 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.

© Fujitsu Technology Solutions, 2009

Seite 66 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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 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. 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.

© Fujitsu Technology Solutions, 2009

Seite 67 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

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)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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.

© Fujitsu Technology Solutions, 2009

Seite 69 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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

© Fujitsu Technology Solutions, 2009

Seite 70 (71)

White Paper Sizing Guide

Exchange Server 2003

Version: 4.2, July 2006

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:[email protected] PRIMERGY Produkt Marketing mailto:[email protected]

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:[email protected]

Seite 71 (71)