Entwurfsbeispiel für die Exchange 2010-Postfachserverrolle

Letztes Änderungsdatum des Themas: 2009-12-09

In diesem Thema wird ein Beispiel für die Ermittlung der entsprechenden Leistungsanforderungen in Bezug auf Arbeitsspeicher, Kapazität, E/A und CPU für die Postfachserverrolle und die zugehörige Architektur dargestellt.

Mit dem Anforderungsrechner für die Exchange Server 2010-Postfachserverrolle können Sie die jeweiligen Anforderungen für die Postfachserverrolle durch Angeben einer Reihe von Eingabefaktoren ermitteln. Mit dem Rechner können die in diesem Beispiel beschriebenen Anforderungen ermittelt werden. Weitere Informationen zum Rechner (sowie zum Herunterladen des Rechners) finden Sie im Exchange Server-Teamblogartikel Anforderungsrechner für die Exchange 2010-Postfachserverrolle (möglicherweise in englischer Sprache).

Weitere Informationen zum Speicherentwurf der Postfachserverrolle finden Sie unter Speicherentwurf für Postfachserver.

Bei dem Szenario in diesem Beispiel geht es um eine Lösung mit drei Datenbankkopien, bei der die JBOD-Speicherung (Just a Bunch Of Disks) verwendet wird. Berücksichtigen Sie für die Zwecke dieses Beispiels die folgenden Anforderungen für die Architektur:

• Sechs Postfachserver in einer Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG)
• Jeder Server verfügt über Intel Xeon x5470-Prozessoren mit 3,33 GHz (Anordnung von 2x4 Prozessorkernen).
• Drei Postfachdatenbankkopien mit hoher Verfügbarkeit, keine verzögerten Datenbankkopien
• 1-Terabyte-SATA-Spindles mit 7.200 U/Min
• JBOD-Speicherkonfiguration (1 logische Gerätenummer (Logical Unit Number, LUN)/Datenbank-LUN-Architektur)
• Sicherungsarchitektur mit systemeigenen Datenschutzfunktionen, die über die Wiederherstellung einzelner Elemente und die Ausfallsicherheit von Postfächern bereitgestellt werden
• Eine Wiederherstellungs-LUN für Wartungs- und Wiederherstellungsvorgänge
• Mindestens 20 Prozent freier Speicherplatz auf jeder LUN
• Die Lösung sollte Ausfälle von zwei Servern überstehen können.
• Die Postfachserverrolle ist als einzige Serverrolle installiert.

Inhalt

Kapazitätsanforderungen für Postfächer

Anforderungen für Datenbankkopien

Anforderungen für den Arbeitsspeicher von Postfächern

Anforderungen für Postfach-E/A-Vorgänge

CPU-Anforderungen für Postfächer

Kapazitätsanforderungen für Postfächer

Im folgenden Beispiel wird die richtige Größenberechnung für eine Umgebung veranschaulicht, in der 24.000 Postfächer mit einem Aufkommen von 100 Nachrichten mit 2 GB pro Tag auf sechs Postfachserver in einer Datenbankverfügbarkeitsgruppe verteilt sind, in der jede Datenbank über drei Kopien verfügt. Diese Postfächer empfangen pro Arbeitswoche (5 Tage) durchschnittlich 37 MB an E-Mails mit einer durchschnittlichen Nachrichtengröße von 75 KB. Die Wiederherstellung einzelner Elemente ist mit einer 14-tägigen Aufbewahrungszeit für gelöschte Elemente aktiviert. Die Postfachgröße wird anhand der folgenden Berechnungen ermittelt:

Postfachgröße = Postfachbegrenzung + Leere Seiten + Dumpster

Leere Seiten = 100 Nachrichten pro Tag x 75/1024 MB = 7,3 MB

Dumpster = (100 Nachrichten pro Tag x 75/1024 MB * 14 Tage) + (2048 MB x 0,012) + (2048 MB x 0,058) = 246 MB

Beispielwerte zum Bestimmen der tatsächlichen Postfachgröße auf dem Datenträger

In dieser Umgebung verbraucht jeder Benutzer 2,25 GB Speicherplatz. Darüber hinaus werden bei dieser Lösung 1 TB-Datenträger in einer JBOD-Konfiguration verwendet. Daher beträgt die maximale Datenbankgröße 667 GB. Zur Unterstützung von 24.000 Postfächern mit einer Datenbankgröße von 667 GB sind 102 Datenbanken erforderlich. Dies führt zu einer Gesamtanzahl von 235 Postfächern pro Datenbank.

Da jedoch bei dieser Lösung eine JBOD-Speicherarchitektur genutzt wird, muss unbedingt sichergestellt werden, dass die Anzahl von Postfächern pro Datenbank nicht die Anzahl der zufälligen E/A-Vorgänge überschreitet, die auf dem einzelnen Datenträger erreicht werden können. Weil bei dieser Lösung 7,2 K-SATA-Spindles mit großem Formfaktor verwendet werden, kann die Spindle bei voller Auslastung maximal 55 zufällige E/A-Vorgänge pro Sekunde (I/O Per Second, IOPS) erreichen. Bei Berücksichtigung eines E/A-Overheadwachstumspuffers von 20 Prozent bedeutet dies, dass von der Spindle insgesamt 44 zufällige E/A-Vorgänge pro Sekunde verarbeitet werden können.

Unter der Voraussetzung, dass der Meldungsfluss der Benutzerbasis 100 Nachrichten pro Tag umfasst, verarbeitet jedes Postfach 0,1 IOPS. Daher können vom Datenträger maximal 440 Postfächer mit diesem IOPS-Profil unterstützt werden. Da bei den Kapazitätsberechnungen ermittelt wurde, dass maximal 235 Postfächer unterstützt werden können, und dieser Wert unter den auf der Grundlage des IOPS-Profils ermittelten 440 Postfächern liegt, kann diese Lösung auf einem einzigen Datenträger bereitgestellt werden.

Verwenden Sie zum Ermitteln der tatsächlichen Datenbankgröße die folgende Formel:

Datenbankgröße = Anzahl von Postfächern x Postfachgröße auf dem Datenträger x Datenbankoverhead-Wachstumsfaktor

Basierend auf der Anzahl der Postfächer, der tatsächlichen Größe der Postfächer und einem Datenbankoverhead-Wachstumsfaktor von 20 Prozent beträgt die Datenbankgröße (wie in der folgenden Tabelle dargstellt) 635 GB.

Anforderungen an die Datenbankkapazität

Zur Vermeidung von Ausfällen des Postfachservers aufgrund von Speicherzuordnungsproblemen muss auch die Größe der Transaktionsprotokolle angepasst werden, damit alle während des Sicherungssatzes generierten Protokolle problemlos gespeichert werden können. Unter der Voraussetzung, dass im Rahmen dieser Architektur die Funktionen für die Ausfallsicherheit von Postfächern und für die Wiederherstellung einzelner Elemente als Sicherungsarchitektur genutzt werden, muss die Protokollkapazität für den Fall, dass eine fehlerhafte Kopie nicht innerhalb von drei Tagen repariert werden kann, das Dreifache der täglichen Protokollgenerierungsrate betragen. (Fehlerhafte Kopien verhindern das Abschneiden von Protokollen.)

Für ein Postfach mit einem Aufkommen von 100 Nachrichten pro Tag werden durchschnittlich 20 Transaktionsprotokolle pro Tag generiert. Folglich werden in einer Umgebung mit 24.000 Postfächern 576.000 Transaktionsprotokolle pro Tag generiert. Dies bedeutet, dass jede Datenbank 5.647 Protokolle pro Tag generiert. 1 Prozent der Postfächer werden einmal pro Woche (am Samstag) verschoben. Bei dieser Lösung werden die systemeigenen Datenschutzfunktionen in Exchange verwendet. Aus diesem Grund werden keine Sicherungsvorgänge ausgeführt, und es können drei Tage ohne Protokollabschneidevorgänge toleriert werden.

Wie aus der folgenden Tabelle hervorgeht, benötigt dieser Server 23 GB Speicherplatz für jede Datenbankkopie.

Anforderungen an die Protokollkapazität

Unter der Voraussetzung, dass es sich hierbei um eine JBOD-Konfiguration mit Ausfallsicherheit von Postfächern mit drei Kopien handelt, werden die einzelnen Datenbanken und die zugehörigen Transaktionsprotokolle auf derselben LUN gespeichert. Die erforderliche LUN-Größe wird wie folgt berechnet:

LUN-Kapazität = Datengröße / (1 - Anforderung für freien Speicherplatz in Prozent)

= (Datenbankgröße + Größe der Transaktionsprotokolle + Inhaltsindexgröße) / (1 - 0,2)

= (635 GB + 23 GB + 63,5 GB) / 0,8

= 902 GB

Ermitteln der erforderlichen LUN-Größe

Nach oben

Anforderungen für Datenbankkopien

Unter der Voraussetzung, dass insgesamt 102 Datenbanken für die Unterstützung von 24.000 Postfächern erforderlich sind und jede Datenbank über drei Kopien verfügt, werden von der Datenbankverfügbarkeitsgruppe insgesamt 306 Datenbanken unterstützt. Wenn 306 Datenbanken auf sechs Postfachserver verteilt sind, bedeutet dies, dass auf jedem Postfachserver 51 Datenbankkopien verwaltet werden. Die Datenbankkopien müssen so auf den Servern in der Datenbankverfügbarkeitsgruppe verteilt sein, dass bei Fehlern oder Ausfällen auf Serverebene ein Failover für die aktiven Datenbanken auf möglichst viele der restlichen Server ausgeführt wird (Datenbankkopien werden nicht symmetrisch verteilt).

Zur Maximierung der Effizienz der Postfachserver in der Datenbankverfügbarkeitsgruppe werden die aktiven Datenbanken gleichmäßig auf alle Postfachserver verteilt. Wenn also alle sechs Postfachserver funktionsfähig sind, werden auf jedem Server 17 aktive Datenbankkopien verwaltet.

Falls ein Postfachserver ausfällt, werden die 17 Datenbanken auf den restlichen Postfachservern neu verteilt, sodass sich die Anzahl der aktiven Datenbankkopien pro Server auf 21 erhöht.

Falls zwei Postfachserver ausfallen, werden die 34 Datenbanken auf den restlichen Postfachservern neu verteilt, sodass sich die Anzahl der aktiven Datenbankkopien pro Server auf 26 erhöht. Basierend auf dieser Anzahl der aktiven Kopien werden die Anforderungen in Bezug auf Arbeitsspeicher und CPU für die Postfachserver ermittelt.

Nach oben

Anforderungen für den Arbeitsspeicher von Postfächern

Bei einem Meldungsfluss von 100 Nachrichten pro Tag beträgt der zur Unterstützung des Datenbankcaches mindestens erforderliche Arbeitsspeicher pro Postfach 6 MB. Wenn im schlimmsten Fall die Anzahl der aktiven Postfachdatenbanken pro Server 26 beträgt, könnten auf jedem Server insgesamt 6.110 aktive Postfächer verwaltet werden. Darüber hinaus sind insgesamt 51 Datenbanken pro Server vorhanden. Für den Postfachserver ist mindestens ein Datenbankcache von 12 GB erforderlich. Daher wird der zur Unterstützung des Datenbankcaches erforderliche Arbeitsspeicher wie folgt berechnet:

Mindestens erforderlicher Datenbankcache = MAX((Anzahl von aktiven Postfächern x erforderlicher Arbeitsspeicher / Postfach), Mindestarbeitsspeicher für Datenbanken)

= MAX(6110 x 6/1024 GB, 12 GB)

= MAX (36 GB, 12 GB)

= 36 GB

Der zur Unterstützung dieser Konfiguration insgesamt erforderliche physikalische Arbeitsspeicher beträgt (basierend auf der Tabelle in Grundlegendes zum Postfachdatenbankcache) 48 GB.

Nach oben

Anforderungen für Postfach-E/A-Vorgänge

Jedes Postfach sendet oder empfängt 100 Nachrichten pro Tag. Daher hat jedes Postfach ein IOPS-Profil von 0,1. In jeder Datenbank werden 235 Postfächer verwaltet. Daher wird die Gesamtanzahl der Datenbankvolume-E/A-Vorgänge wie folgt berechnet:

Datenbankvolume-E/A-Vorgänge = Anzahl von Postfächern x IOPS-Profil x (1 + Wachstumsfaktor des E/A-Overheads)

= 235 x 0,1 x 1,2

= 28,2 IOPS

Die E/A-Datenbanklesevorgänge für diese Architektur betragen 60 Prozent. Daher werden von jedem Datenbankvolume 16,92 E/A-Lesevorgänge pro Sekunde und 11,28 E/A-Schreibvorgänge pro Sekunde generiert.

In dieser Architektur generiert jeder Protokolldatenstrom 50 Prozent der E/A-Datenbankschreibvorgänge. Daher belaufen sich die E/A-Protokollschreibvorgänge pro Volume auf 5,64 IOPS.

Von den 26 aktiven Datenbankkopien werden auch E/A-Protokolllesevorgänge generiert, die 10 Prozent der E/A-Protokollschreibvorgänge ausmachen. Daher belaufen sich die E/A-Protokolllesevorgänge für diese Datenbanken auf 0,56 IOPS.

Wenn wir davon ausgehen, dass jeder 7,2 K-SATA-Datenträger mit großem Formfaktor 55 zufällige IOPS generiert, brauchen wir uns keine Gedanken machen, dass die E/A-Anforderungen der Datenbank nicht vom Datenträger verarbeitet werden können.

Nach oben

CPU-Anforderungen für Postfächer

Bei einem Ausfall von zwei Servern werden auf den restlichen Servern jeweils 26 Datenbanken für insgesamt 6.110 aktive Postfächer pro Server gehostet. Basierend auf den unter Kapazitätsplanung für den Postfachserverprozessor aufgeführten Berechnungen gelten für jeden Server die folgenden Anforderungen für CPU-Megazyklen.

Ermitteln der Anforderungen für CPU-Megazyklen

Unter der Voraussetzung, dass die gewählte Serverplattform Unterstützung für insgesamt 26.400 Megazyklen bietet, kann die CPU-Serverplattform die Umgebung bei einem Ausfall von zwei Servern unterstützen.

Nach oben