Entwurfsbeispiel für die Exchange 2010-Postfachserverrolle

Exchange 2010
 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

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.

Mithilfe des Anforderungsrechners für die Exchange Server 2010-Postfachserverrolle können Sie Ihre Anforderungen für die Postfachserverrolle ermitteln, indem Sie eine Reihe von Eingabefaktoren angeben. Mit dem Rechner können die in diesem Beispiel beschriebenen Anforderungen ermittelt werden. Weitere Informationen zu diesem Rechner (sowie zum Herunterladen des Rechners) finden Sie im Exchange Server Team Blog-Artikel Anforderungsrechner für die Exchange 2010-Postfachserverrolle (möglicherweise in englischer Sprache).

HinweisHinweis:
Der Inhalt jedes Blogs und die dazugehörige URL kann ohne vorherige Ankündigung geändert werden. Der Inhalt jedes Blogs wird "WIE BESEHEN" ohne Gewährleistungen bereitgestellt und überträgt keine Rechte. Die Verwendung der enthaltenen Skriptbeispiele unterliegt den in den Nutzungsbestimmungen angegebenen Bedingungen.

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 Database Availability Group (DAG)

  • Der Exchange-Postfachserver hostet auch Hub-Transport- und Clientzugriffs-Serverrollen

  • 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

Das folgende Beispiel zeigt die Berechnung der geeigneten Größe für eine Umgebung, in der 24.000 Postfächer mit einer Größe von 2 GB und dem Profil "100 Nachrichten pro Tag" auf sechs Postfachserver verteilt sind. Die Postfachserver wiederum gehören einer Database Availability Group (DAG) an, bei der jede Datenbank über drei Kopien verfügt. Diese Postfächer empfangen durchschnittlich 37 MB an E-Mails pro Arbeitswoche (5 Tage), bei einer durchschnittlichen Nachrichtengröße von 75 KB. Die Wiederherstellung einzelner Elemente ist aktiviert, das Zeitfenster für die Aufbewahrung gelöschter Elemente ist auf 14 Tage festgelegt. Die Postfachgröße wird anhand der folgenden Berechnungen ermittelt:

Postfachgröße = Postfachbegrenzung + Leere Seiten + Dumpster

Leere Seiten = 100 Nachrichten pro Tag x 75/1.024 MB = 7,32 MB

Dumpster = (100 Nachrichten pro Tag x 75/1.024 MB * 14 Tage) + (2.048 MB x 0,012) + (2.048 MB x 0,03) = 188,6 MB

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

Postfachkontingent Dumpstergröße (2 Wochen) Leere Seiten Gesamtgröße auf dem Datenträger

2 GB

188,7 MB

7,3 MB

2,19 GB (+12%)

Da in dieser Umgebung JBOD-Speicher verwendet wird, richtet sich die maximal zulässige Datenbankgröße nach der Größe der Festplatte. Zur Ermittlung der maximalen Datenbankgröße für das JBOD-Szenario verwenden Sie die folgende Formel. Hierbei liegt die Kapazität einer formatierten 1-TB-Festplatte bei 931 GB, die Anforderung an den freien Speicherplatz beträgt 20 Prozent, und der Prozentsatz für den Inhaltsindex liegt bei 10 Prozent:

Maximale Datenbankgröße = [Kapazität formatierte Festplatte x (1 – Anforderung an den freien Speicherplatz in Prozent)] / (1 + Prozentsatz für den Inhaltsindex)

= [931 GB x (1 - 0,2)] / ( 1+ 0,10)

= 744,8 GB / 1,1

= 677 GB

In dieser Umgebung belegt jedes Benutzerpostfach 2,25 GB an Speicherplatz. Zur Unterstützung von 24.000 Postfächern bei einer Datenbankgröße von 677 GB sind 102 Datenbanken erforderlich. Diese Anforderung ergibt 235 Postfächer 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.

Wenn das Benutzerprofil 100 Nachrichten pro Tag vorsieht, belegt jedes Postfach 0,1 IOPS, d. h. die Festplatte kann maximal 440 Postfächer mit diesem IOPS-Profil unterstützen. 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 von Postfächern, der tatsächlichen Größe der Postfächer und einem Datenbankwachstumsfaktor von 20 Prozent liegt die Datenbankgröße bei 619 GB (siehe folgende Tabelle).

Anforderungen an die Datenbankkapazität

Postfächer pro Datenbank Gesamtanzahl der Datenbanken Anforderungen an die Datenbankgröße

235

102

619 GB

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

Ein Postfach mit dem Profil "100 Nachrichten pro Tag" generiert durchschnittlich 20 Transaktionsprotokolle pro Tag, sodass eine Umgebung mit 24.000 Postfächern 576.000 Transaktionsprotokolle pro Tag generiert. Damit erzeugt jede Datenbank pro Tag 5.647 Protokolle. 1 Prozent der Postfächer werden einmal pro Woche (am Samstag) verschoben. Die Lösung nutzt die Funktionen für den systemeigenen Datenschutz in Exchange. Daher werden keine Sicherungen durchgeführt, und es können drei Tage ohne das Abschneiden von Protokollen toleriert werden.

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

Anforderungen an die Protokollkapazität

Protokolle pro Datenbank Größe der Protokolldatei Tägliche Protokollgröße Größe des zu verschiebenden Postfachs ÷ Datenbank Fehlertoleranz bei Abschneidevorgängen Anforderungen an die Protokollgröße

5647

1 MB

5,65 GB

6 GB

(240 × 2,19 GB x 1,2 / 102)

16,5 GB

(3 × 5,65 GB)

23 GB

(16,5 GB + 6 GB)

Vorausgesetzt, dass es sich um eine Konfiguration mit Ausfallsicherheit für Postfächer und JBOD mit drei Kopien handelt, wird jede Datenbank gemeinsam mit den zugehörigen Transaktionsprotokollen auf derselben LUN platziert. Die erforderliche LUN-Größe wird wie folgt berechnet:

LUN-Kapazität = Datenbankgröße ÷ (1 - Anforderung an den freien Speicherplatz in Prozent)

= (Datenbankgröße + Transaktionsprotokollgröße + Inhaltsindexgröße) ÷ (1 - 0,2)

= (619 GB + 23 GB + 61,9 GB) / 0,8

= 879 GB

Ermitteln der erforderlichen LUN-Größe

Datenbankgröße Größe des Transaktionsprotokolls Inhaltsindexgröße Größe der Datenbank-LUN

619 GB

23 GB

61,9 GB

879 GB

Zurück zum Seitenanfang

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 Database Availability Group 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 Database Availability Group verteilt sein, dass bei Fehlern oder Ausfällen auf Serverebene ein Failover für die aktiven Datenbanken auf möglichst viele der übrigen Server ausgeführt wird (Datenbankkopien werden nicht symmetrisch verteilt).

Zur Maximierung der Effizienz der Postfachserver in der Database Availability Group 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.

Weitere Informationen zum Verteilen der Datenbankkopien auf die Postfachserver finden Sie unter Entwurf des Layouts von Datenbankkopien.

Zurück zum Seitenanfang

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

Bei der Bereitstellung einer Architektur mit mehreren Rollen sind 64 GB an physischem Arbeitsspeicher zur Unterstützung der Konfiguration erforderlich, siehe Tabelle im Abschnitt Grundlegendes zum Postfachdatenbankcache.

Zurück zum Seitenanfang

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.

Zurück zum Seitenanfang

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

Anforderungen für CPU-Megazyklen von aktiven Postfächern Anforderungen für CPU-Megazyklen von passiven Postfächern Gesamtanforderungen für CPU-Megazyklen

14,682

1,765

16,447

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.

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Anzeigen: