Speicherentwurf für Transport-Server

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2009-01-26

Edge-Transport- und Hub-Transport-Server sind die Serverfunktionen, die Folgendes bereitstellen:

• In die Organisation eingehende und aus ihr ausgehende E-Mail.

• Bei Postfachservern ein- und ausgehende E-Mail.

• Von Unified Messaging-Servern übermittelte Voicemail-Nachrichten.

Um eine effiziente Nachrichtenübermittlung und Zustellung in der Exchange-Organisation zu gewährleisten, benötigen Edge-Transport- und Hub-Transport-Server eine ordnungsgemäß entworfene Speicherlösung.

Dieses Thema enthält Informationen und Beispiele zur Ermittlung der Kapazität und E/A-Anforderungen (Eingabe/Ausgabe) für Edge-Transport- und Hub-Transport-Server.

Kapazität und E/A-Anforderungen für Edge-Transport-Server

Edge-Transport-Server müssen entsprechend der Kapazität sowie der transaktionellen E/A-Anforderungen für jede Organisation entworfen werden. Von entscheidender Bedeutung sind die ordnungsgemäße Verwaltung des Warteschlangenwachstums sowie die schnellstmögliche Weiterleitung von E-Mail, damit es nicht zu negativen Auswirkungen auf den Umfang von Serviceleistungen (Service Level Agreement, SLA) kommt. Es gibt verschiedene Faktoren, die sich auf die Gesamtkapazität eines Edge-Transport-Servers auswirken:

• Nachrichtenverfolgungsprotokolle

• Protokollaufzeichnungen

• Mail-Datenbank

• Verbindungsprotokolle

• Agentprotokolle

Das Laufwerk mit der Nachrichtenwarteschlangendatenbank muss mindestens 500 MB freien Speicher sowie freien Datenbankspeicher aufweisen. Ansonsten aktiviert das Transportsystem einen Rückstau, ein Feature des Microsoft Exchange Server 2007-Transportdiensts zum Überwachen der Systemressourcen.

Hinweis

In der RTM-Version (Release to Manufacturing) von Exchange Server 2007 aktiviert das Transportsystem die Rückstaufunktion, wenn der freie Speicher unter 4 GB fällt. Dieser Schwellenwert wurde in Exchange 2007 Service Pack 1 auf 500 MB gesenkt.

Der Standardwert für den Rückstau wird über den Parameter PercentageDatabaseDiskSpaceUsedHighThreshold gesteuert und kann bei Bedarf geändert werden. Weitere Informationen zum Rückstau sowie zu den entsprechenden Konfigurationsoptionen finden Sie unter Grundlagen der Rückstaufunktion.

Sind Nachrichtenverfolgungsprotokolle aktiviert, wird weitere Kapazität benötigt. Die Kapazitätsanforderungen bei der Nachrichtenverfolgung richten sich nach der Anzahl der Nachrichten, die vom Transportserver empfangen werden. Wird in Ihrer Organisation derzeit Microsoft Exchange Server 2003 eingesetzt, können Sie die Protokollgenerierungsrate sowie die maximale Anzahl an Tagen zum Aufbewahren von Daten festlegen, z. B. 10 Tage. Microsoft erzeugt 220 MB an Nachrichtenverfolgungsprotokollen pro Arbeitstag (am Wochenende weniger) und gewährleistet ausreichend Kapazität für die Protokollaufzeichnungen einer Woche (ungefähr 1,3 GB). Die Größe von Protokollen, Konnektivitätsprotokollen und Agent-Protokollen richtet sich nach der Aktivität. Die Produktionstransportserver bei Microsoft erzeugen zur Orientierung Folgendes:

• 5 bis 15 GB an Protokollen pro Tag auf den Edge-Transport-Servern. Ausreichend Kapazität für das Protokollkontingent von 15 GB ist garantiert.

• 100 MB an Konnektivitätsprotokollen pro Tag auf den Edge-Transport-Servern. Ausreichend Kapazität für die Protokolle einer Woche (ungefähr 600 MB) ist garantiert.

• 250 MB an Agent-Protokollen pro Tag auf den Edge-Transport-Servern. Ausreichend Kapazität für die Protokolle einer Woche (ungefähr 1,5 MB) ist garantiert.

Transaktionsprotokolle benötigen keine große Festplattenkapazität, da die normale Protokollerstellung durch die Verwendung der Umlaufprotokollierung begrenzt wird. Folglich können Transaktionsprotokolle auf der logischen Gerätenummer (Logical Unit Number, LUN), die das Betriebssystem enthält, gespeichert werden. Microsoft verwendet zwei gespiegelte Festplattenlaufwerke für diese LUN.

Elemente werden in der Datenbank (mail.que) nicht auf unbegrenzte Zeit gespeichert. Bei der reservierten Kapazität sollte es sich um die durchschnittliche Nachrichtengröße multipliziert mit der maximalen Warteschlange für den Fall handeln, dass die Warteschlange die maximal zulässige Größe erreicht hat und der Server heruntergefahren wird. Eine Warteschlange mit 500.000 Elementen und einer durchschnittlichen Nachrichtengröße von 50 KB erzeugt etwa 25 GB an Daten in der Datenbank.

Edge-Transport-Server, die eingehende E-Mail auf Viren überwachen, benötigen ausreichend Speicherplatz zum Isolieren von Viren. Die Ressourcenanforderungen an die Datenträger-E/A richten sich nach dem in der Regel geringen Prozentsatz an eingehenden infizierten E-Mail-Nachrichten. Die Anzahl der infizierten Nachrichten und Anlagen und deren Verweildauer in der Quarantäne bestimmen den benötigten Speicherplatz. Ein Gigabyte sollte für den Anfang genügen, obgleich sich die tatsächlichen Bedürfnisse der jeweiligen Organisationen unterscheiden.

Für die meisten Edge-Transport-Serverbereitstellungen empfehlen wird die Anwendung eines Overheadfaktors von 20 Prozent auf die Datenbankgröße (nachdem alle anderen Faktoren berücksichtigt wurden). Dieser Wert berücksichtigt interne Strukturen in der Datenbank und garantiert ausreichend Speicherplatz, wenn eine Spitze oder eine Änderung in der Nachrichtenübermittlung Auswirkungen auf die Datenbankgröße hat.

Kapazitätsbeispiel für einen Edge-Transport-Server

In diesem Beispiel werden die Transaktionsprotokolle auf der Betriebssystempartition (C:) gespeichert, die auf einem akkugesicherten RAID-Controller mit Cache gehostet wird. Die Kapazitätsanforderungen sind gering (im Bereich von mehreren MB).

Die Bestimmung der Kapazität eines Edge-Transport-Servers erfolgt in zwei Schritten. Zuerst muss die Datenbankgröße und dann die Transaktionsprotokollgröße festgelegt werden.

Schritt 1: Datenbankgröße

Ausgegangen wird von einem Edge-Transport-Server, der durchschnittlich 5 Nachrichten pro Sekunde (mit einer Durchschnittsgröße von 50 KB) über einen Zeitraum von 24 empfängt und dessen Warteschlange maximal 500.000 Elemente aufnehmen kann. Nach Berücksichtigung aller anderen Faktoren wird zusätzlich ein Overhead von 20 Prozent einkalkuliert. Die Gesamtgröße auf dem Datenträger beträgt 58 GB (siehe folgende Tabelle).

Datenbankgröße

Maximale Warteschlangengröße	Warteschlangenkapazität	Protokollaufzeichnungen	Nachrichtenverfolgungsprotokolle	Virusquarantäne	Verbindungsprotokolle	Agentprotokolle	Freier Speicher	Gesamtgröße auf dem Datenträger
500.000	Ungefähr 25 GB (500.000 × 50 KB)	15 GB	1,3 GB	1 GB	600 MB	1,5 GB	4 GB	58 GB (48 GB + 20%)

Schritt 2: Größe des Transaktionsprotokolls

Zur Bestimmung der Transaktionsprotokollgröße müssen Sie die transaktionelle E/A, andere Datenträger E/A sowie die Datenbank-E/A pro Sekunde pro Nachricht hinzuziehen.

Transaktionelle E/A

Verfügt der Server über ausreichend Speicherplatz, werden eingehende E-Mail-Nachrichten im RAM sowie im Transaktionsprotokoll gespeichert, wodurch Festplattenzugriffe vermieden werden. Sind die Speicherressourcen gering, werden nur die ersten 128 KB der Nachricht im RAM und im Transaktionsprotokoll gespeichert. Der Rest der Nachricht wird in der Datenbank gespeichert. Während der Inhaltskonvertierung werden die Daten zur Verarbeitung in ein temporäres Verzeichnis verschoben. Dieses temporäre Verzeichnis wird mithilfe der Einstellung TemporaryStoragePath in der Datei EdgeTransport.exe.config angegeben. Der Wert von TemporaryStoragePath ist standardmäßig auf C:\Programme\Microsoft\Exchange Server\TransportRoles\data\Temp festgelegt.

Hinweis

Die Datei EdgeTransport.exe.config befindet sich standardmäßig im Ordner %ProgramFiles%\Microsoft\Exchange Server\Bin.

Es ist wichtig, dass sich das temporäre Verzeichnis auf derselben LUN wie die Datenbank befindet. Darüber hinaus muss der Cache des Speichercontrollers auf 50 Prozent für Lesevorgänge und 50 Prozent für Schreibvorgänge festgelegt werden. Bei einer kleinen Warteschlange handelt es sich nur bei wenigen Datenträger-E/As um Lesevorgänge. Ist eine Warteschlange vorhanden, befindet sich die Nachricht unter Umständen nicht im Datenbankcache, wodurch eine größere Anzahl an Datenträger-E/As benötigt werden.

Weitere Datenträger-E/A

Zusätzlich zur transaktionellen E/A befindet sich weitere Datenträger-E/A im System. Beispiel:

• Die Aktivierung von Nachrichtenverfolgungsprotokollen erfordert weitere 2-5 Prozent Overhead für Datenträger-E/A.

• Die Aktivierung von Protokoll- und Konnektivitätsprotokollen hat einen geringen Overhead für Datenträger-E/A, der sich nach der Anzahl der eingehenden E-Mail-Nachrichten richtet.

• Die Aktivierung von standardmäßigen Agent-Protokollen hat einen geringen Overhead für Datenträger-E/A. Bei Verwendung benutzerdefinierter Agenten werden jedoch weitere Datenträgerressourcen benötigt.

• Antispam- und Antivirusoperationen werden im Speicher durchgeführt und benötigen weitere CPU-Ressourcen.

Stellen Sie sicher, dass Sie die Edge-Transport-Server mit allen Diensten getestet haben, die in der Produktion verwendet werden sollen.

Datenbank-IOPS pro Nachricht

Während interner Tests bei Microsoft wurde eine durchschnittliche Nachrichtengröße von 60 KB verwendet. Zahlreiche Organisationen richten ihre Transportserver unter Annahme einer bestimmten Nachrichtenrate ein, z. B. 20 Nachrichten pro Sekunde. Diese Nachrichtenrate erfordert 140 (20 × (4,5 + 2,5)) Datenbank-E/As und 220 (20 × 11) Protokoll-E/As.

Wenn eine Warteschlange entsteht, sind zusätzliche Lesevorgänge erforderlich, insbesondere bei RAID-1/0, da jeder physische Datenträger auf die Lesevorgänge reagiert (siehe folgende Tabelle).

Datenbank-IOPS pro Nachricht

Edge-Transport-Datenbank-E/A (Dauerstatus)	Geschätzte Edge-E/A
Gesamt-IOPS pro Nachricht (ungefähr 60 KB)	18
Protokollschreib-E/As pro Nachricht (aufeinander folgend)	11
Datenbankschreib-E/As pro Nachricht (zufällig)	4,5
Datenbanklese-E/As pro Nachricht (zufällig)	2,5

Hinweis

Bei den Zahlen in der folgenden Tabelle handelt es sich um Durchschnittswerte zahlreicher Server in der Produktion mit Schwankungen von plus/minus 30 Prozent. Weitere Features, wie z. B. die Journal- und Transportregeln, wirken sich auch auf die erwartete E/A pro Nachricht aus. Weiterhin beeinflussen diese Features die in diesem Thema bereitgestellten Beispielzahlen.

Anwenden von Größenrichtlinien auf den Hardwareentwurf eines Edge-Transport-Servers

Nachdem Sie die Anforderungen für die Kapazität sowie die transaktionelle E/A für einen Edge-Transport-Server ermittelt haben, können Sie diese in den geplanten Hardwareentwurf einfließen lassen. Informationen zu Prozessor- und Speicherkonfigurationen finden Sie unter Planen von Prozessorkonfigurationen und Planen von Speicherkonfigurationen. Beim Entwurf eines Edge-Transport-Servers muss ausreichend RAM (jede Nachricht benötigt 8 oder 9 KB Speicherplatz) im System zur Verfügung stehen, um die temporäre Zwischenspeicherung von Nachrichten in der Warteschlange auf die Festplatte zu verhindern.

Ein Edge-Transport-Server verwendet eine ESE-Datenbank (Extensible Storage Engine). Zur Gewährleistung von Flexibilität und optimaler Leistung müssen die Protokoll- und Datenbankdateien auf eigenen physischen Datenträgern in Umgebungen mit einer großen Warteschlange gespeichert werden. In kleineren Bereitstellungen mit niedrigeren Datenträger-E/A-Anforderungen können die Transaktionsprotokolle und die Datenbank auf derselben LUN platziert werden. Der Edge-Transport-Server ebenso wie der Postfachserver benötigen E/A-Reaktionszeiten unter 20 Millisekunden.

Es ist wichtig, akkugesicherte RAID-Controller mit Cache zu verwenden und die Wartung der Datenbank nachts durchzuführen. Stellen Sie ebenfalls sicher, dass der ausgewählte Datenträgertyp das richtige Verhältnis zwischen Kapazität und Leistung bietet.

Hardwareskalierungsbeispiel für einen Edge-Transport-Server

In diesem Beispiel wird ein Speicherentwurf dargestellt, der die erwarteten Nachrichten pro Sekunde berücksichtigt. Es handelt sich um einen Edge-Transport-Server, der 20 Nachrichten pro Sekunde verarbeitet und 140 IOPS für die Datenbank-LUN und 220 IOPS für die Protokoll-LUN benötigt. Fügen Sie immer einen Wachstumsfaktor von 20 Prozent für die Datenträger-E/A-Leistung hinzu, um Tage mit höherem Nachrichtenaufkommen zu kompensieren. Als Festplattenlayout wird RAID10 verwendet. Die folgende Tabelle enthält die Ergebnisse für die Hardwareskalierung.

Hardwareskalierung

Datenträger (1) und (2), RAID1-Layout	Datenträger (3), (4), (5) und (6), RAID10-Layout
Betriebssystem und Transaktionsprotokolle 220 + 20% = 264 IOPS	Datenbankprotokolle, Protokolle und Nachrichtenverfolgungsprotokolle sowie Virusquarantäne 140 + 20% = 168 IOPS

Als Kapazitätsanforderung für die Datenbank-LUN werden in diesem Beispiel ungefähr 70 GB für die Daten einer Woche benötigt. Sie müssen die Kapazitätsanforderung auf 140 GB verdoppeln, wenn die Daten von zwei Wochen aufgezeichnet werden sollen. Die Verwendung von physischen Datenträgern mit 146 GB ermöglicht eine LUN von 292 GB in einer RAID10-Konfiguration.

Kapazität und E/A-Anforderungen für Hub-Transport-Server

Hub-Transport-Server müssen ebenfalls entsprechend der Kapazität sowie der transaktionellen E/A-Anforderungen der Organisation entworfen werden. Wie beim Edge-Transport-Server müssen auf dem Laufwerk, das die Nachrichtenwarteschlangendatenbank enthält, mindestens 500 MB freier Festplatten- und Datenbankspeicher vorhanden sein. Ansonsten aktiviert das Transportsystem einen Rückstau. Sie können den Standardwert für den Parameter PercentageDatabaseDiskSpaceUsedHighThreshold auf Hub-Transport-Servern ändern.

Hinweis

In der RTM-Version von Exchange Server 2007 aktiviert das Transportsystem die Rückstaufunktion, wenn der freie Speicher unter 4 GB fällt. Dieser Schwellenwert wurde in Microsoft Exchange 2007 Service Pack 1 (SP1) auf 500 MB gesenkt.

Die Kapazitätsanforderungen bei der Nachrichtenverfolgung richten sich nach der Anzahl der Nachrichten, die vom Transportserver empfangen werden. Wird in Ihrer Organisation derzeit Exchange 2003 eingesetzt, können Sie die Protokollgenerierungsrate sowie die maximale Anzahl an Tagen zum Aufbewahren von Daten festlegen, z. B. 10 Tage. Microsoft erzeugt 700 MB an Nachrichtenverfolgungsprotokollen pro Arbeitstag (am Wochenende weniger) auf dem Hub-Transport-Server und gewährleistet ausreichend Kapazität für die Protokollaufzeichnungen einer Woche (ungefähr 4,5 GB).

Protokollgrößen richten sich nach der Aktivität. Microsoft erzeugt 2,7 MB an Protokollen pro Tag auf den Hub-Transport-Servern und garantiert, dass ausreichend Kapazität für die Protokolle einer Woche (ungefähr 16 GB) zur Verfügung steht.

Transaktionsprotokolle benötigen keine große Festplattenkapazität, da die normale Protokollerstellung durch die Verwendung der Umlaufprotokollierung begrenzt wird. Folglich können die Transaktionsprotokolle auf der Betriebssystem-LUN gespeichert werden. Microsoft verwendet zwei gespiegelte Festplattenlaufwerke für diese LUN.

Elemente werden in der Datenbank (mail.que) nicht auf unbegrenzte Zeit gespeichert. Bei der reservierten Kapazität sollte es sich um die durchschnittliche Nachrichtengröße multipliziert mit der maximalen Warteschlange für den Fall handeln, dass die Warteschlange die maximal zulässige Größe erreicht hat und der Server heruntergefahren wird. Eine Warteschlange mit 500.000 Elementen und einer durchschnittlichen Nachrichtengröße von 50 KB erzeugt etwa 25 GB an Daten in der Datenbank.

Für die meisten Hub-Transport-Serverbereitstellungen empfehlen wird die Anwendung eines Overheadfaktors von 20 Prozent auf die Datenbankgröße (nachdem alle anderen Faktoren berücksichtigt wurden).

Transportpapierkorb

Besondere Überlegungen sind für Hub-Transport-Server an Standorten notwendig, die folgende Server enthalten:

• In einer Umgebung mit fortlaufender Clusterreplikation (Cluster Continuous Replication, CCR) bereitgestellte Postfachclusterserver, die entweder Exchange Server 2007 RTM oder Exchange 2007 SP1 verwenden.

• Postfachserver unter Exchange 2007 (SP1) mit mindestens einer Speichergruppe, die für die lokale fortlaufende Replikation (Local Continuous Replication, LCR) aktiviert ist.

Stellen Sie beim Bereitstellen einer der vorherigen Umgebungen sicher, dass der Hub-Transport-Server über genügend Kapazität verfügt, um Nachrichten ausreichend lange für alle Speichergruppen am Standort zu speichern, sodass Nachrichten im Falle eines ungeplanten Ausfalls des aktiven Knotens wiederhergestellt werden können. Dieses Feature wird auch als Transportpapierkorb bezeichnet.

Der E/A-Overhead des Transportpapierkorbs ist vergleichbar mit dem Anwachsen einer Warteschlange. Die Parameter MaxDumpsterSizePerStorageGroup und MaxDumpsterTime können verwendet werden, um die Verweildauer einer Nachricht im Transportpapierkorb festzulegen. Der Standardwert für MaxDumpsterSizePerStorageGroup beträgt 18 MB. Um die Größe des Transportpapierkorbs für Ihre Umgebung zu ermitteln, verwenden Sie die höchste akzeptierte Nachrichtengröße und erhöhen Sie diese um 50 Prozent. Liegt das Nachrichtenkontingent beispielsweise bei 10 MB muss der Parameter MaxDumpsterSizePerStorageGroup auf 15 MB gesetzt werden. Befinden sich mehrere Hub-Transport-Server am selben Active Directory-Verzeichnisdienststandort wie der Postfachclusterserver in der CCR-Umgebung oder einer LCR-Umgebung unter Exchange 2007 SP1, wird der Gesamtspeicher für die Speichergruppen auf diesem Postfachclusterserver auf alle Hub-Transport-Server verteilt. Wenn Sie beispielsweise vier Hub-Transport-Server mit einem Transportpapierkorb von jeweils 15 MB verwenden, umfasst der Transportpapierkorb für diese Speichergruppe 60 MB.

Für Organisationen ohne Begrenzung der Nachrichtengröße wird empfohlen, den Parameter MaxDumpsterSizePerStorageGroup auf das 1,5-Fache der Durchschnittsgröße von Nachrichten festzulegen, die in der Organisation gesendet werden. Wird keine maximale Nachrichtengröße angegeben, kann nicht garantiert werden, dass eine Nachricht nach einem ungeplanten Failover in einer CCR-Umgebung oder nach Aktivierung der passiven Kopie in einer LCR-Umgebung unter Exchange 2007 SP1 wiederhergestellt werden kann.

Es wird angeraten, den Parameter MaxDumpsterTime auf den Standardwert von 7 Tagen festzulegen.

Die vom Transportpapierkorb benötigte Kapazität sollte der Anzahl der Speichergruppen multipliziert mit der maximalen Größe des Transportpapierkorbs entsprechen. Liegt die maximale Größe des Transportpapierkorbs bei 15 MB und bedient der Hub-Transport-Server 100 Speichergruppen in einer LCR- (Exchange 2007 SP1) oder CCR-Umgebung (Exchange 2007 RTM ), sollten dem Transportpapierkorb 1,5 GB zugewiesen werden.

Größenbeispiel für einen Transportpapierkorb

In diesem Beispiel befinden sich die Transaktionsprotokolle auf dem Datenträger mit der Betriebssystempartition (C:), die auf einem akkugesicherten RAID-Controller mit Cache gehostet wird. Die Kapazitätsanforderungen sind gering (im MB-Bereich). Die folgenden Tabellen enthält die entsprechenden Ergebnisse.

Die Bestimmung der vom Transportpapierkorb benötigten Kapazität erfolgt in zwei Schritten. Zuerst muss die Datenbankgröße und dann die Transaktionsprotokollgröße festgelegt werden.

Schritt 1: Datenbankgröße

Ausgegangen wird von einem Hub-Transport-Server, der durchschnittlich 5 Nachrichten pro Sekunde über einen Zeitraum von 24 empfängt und dessen Warteschlange maximal 500.000 Elemente aufnehmen kann.

Größe des Transportpapierkorbs

Maximale Warteschlangengröße	Warteschlangenkapazität	Protokollaufzeichnungen	Nachrichtenverfolgungsprotokolle	Transportpapierkorb	Gesamtgröße auf dem Datenträger
500.000	25 GB (500.000 × 50 KB)	15 GB	4,5 GB	1,5 GB	55 GB (46 GB + 20%)

Schritt 2: Größe des Transaktionsprotokolls

Zur Bestimmung der Transaktionsprotokollgröße müssen Sie die transaktionelle E/A, andere Datenträger E/A sowie die Datenbank-E/A pro Sekunde pro Nachricht hinzuziehen.

Transaktionelle E/A

Für Hub-Transport-Server gilt dieselbe Vorgehensweise zu transaktioneller E/A wie für Edge-Transport-Server (siehe oben). Wie zuvor bereits erwähnt, ist es besonders wichtig, die Cacheeinstellungen auf dem Speichercontroller wie folgt zu konfigurieren: 50 Prozent Lesevorgänge, 50 Prozent Schreibvorgänge.

Transportpapierkorb-E/A

Bei aktiviertem Transportpapierkorb nimmt die Datenträger-E/A zu. Obwohl die Datenbankschreibvorgänge zunehmen, treten nun auch Datenbanklesevorgänge auf (auf Microsoft-Produktionsservern etwa 3 Lesevorgängen pro Nachricht).

Weitere Datenträger-E/A

Für Hub-Transport-Server gilt dieselbe Vorgehensweise zu anderer Datenträger-E/A wie für Edge-Transport-Server (siehe oben). Stellen Sie sicher, dass Sie die Hub-Transport-Server mit allen Diensten getestet haben, die in der Produktion verwendet werden sollen.

Datenbank-IOPS pro Nachricht

Während interner Tests bei Microsoft, bei denen eine durchschnittliche Nachrichtengröße von 40 KB verwendet wird, erfordert die Aktivierung des Transportpapierkorbs weitere Datenträgerressourcen auf dem Hub-Transport-Server. Zahlreiche Unternehmen richten ihre Transportserver unter Annahme einer bestimmten Nachrichtenrate ein, z. B. 20 Nachrichten pro Sekunde. Bei aktiviertem Transportpapierkorb werden 200 Datenbank-E/As (20 × (7 + 3)) und 140 Protokoll-E/As (20 × 7) benötigt, um eine Nachrichtenrate von 20 eingehenden Nachrichten pro Sekunde zu verarbeiten. Bei deaktiviertem Transportpapierkorb werden 40 Datenbank-E/As (20 × 2) und 40 Protokoll-E/As (20 × 2), benötigt um eine Nachrichtenrate von 20 eingehenden Nachrichten pro Sekunde zu verarbeiten.

Wenn eine Warteschlange entsteht, sind insbesondere bei RAID10 zusätzliche Lesevorgänge notwendig, da jeder physische Datenträger auf die Leseanforderungen reagiert. Weitere Informationen hierzu finden Sie unter der folgenden Tabelle:

Größe des Transaktionsprotokolls

Hub-Transport-Datenbank-E/A (Dauerstatus)	Transportpapierkorb aktiviert	Transportpapierkorb deaktiviert
Gesamt-IOPS pro Nachricht (ungefähr 40 KB)	17	4
Protokollschreib-E/As pro Nachricht (aufeinander folgend)	7	2
Datenbankschreib-E/As pro Nachricht (zufällig)	7	2
Datenbanklese-E/As pro Nachricht (zufällig)	3	0

Hinweis

Bei den Zahlen in der folgenden Tabelle handelt es sich um Durchschnittswerte zahlreicher Server in der Produktion mit Schwankungen von plus/minus 30 Prozent. Zusätzliche Features, wie z. B. Journal- und Transportregeln, haben einen Einfluss auf die erwartete E/A pro Nachricht. Diese Features wirken sich auf die Werte in dieser Tabelle aus.

Anwenden von Größenrichtlinien auf den Hardwareentwurf eines Hub-Transport-Servers

Nachdem Sie die Anforderungen für die Kapazität sowie die transaktionelle E/A für einen Hub-Transport-Server ermittelt haben, können Sie diese in den geplanten Hardwareentwurf einfließen lassen. Informationen zu Prozessor- und Speicherkonfigurationen für Hub-Transport-Server finden Sie unter Planen von Prozessorkonfigurationen und Planen von Speicherkonfigurationen. Beim Entwurf eines Hub-Transport-Servers muss ausreichend RAM (jede Nachricht benötigt 8 oder 9 KB Speicherplatz) im System zur Verfügung stehen, um die temporäre Zwischenspeicherung von Nachrichten in der Warteschlange auf die Festplatte zu verhindern.

Ein Hub-Transport-Server verwendet eine ESE-Datenbank. Zur Gewährleistung von Flexibilität und optimaler Leistung müssen die Protokoll- und Datenbankdateien auf eigenen physischen Datenträgern in Umgebungen mit einer großen Warteschlange oder bei Verwendung des Transportpapierkorbs gespeichert werden. In kleineren Bereitstellungen mit niedrigeren Datenträger-E/A-Anforderungen können die Transaktionsprotokolle und die Datenbank auf derselben LUN platziert werden. Der Hub-Transport-Server ebenso wie der Edge-Transport-Server benötigen E/A-Reaktionszeiten unter 20 Millisekunden.

Hardwareskalierungsbeispiele für einen Hub-Transport-Server

Beim Speicherentwurf sollten die erwarteten Nachrichten pro Sekunde berücksichtigt werden. In diesem Beispiel verarbeitet ein Hub-Transport-Server 20 Nachrichten pro Sekunde bei deaktiviertem Transportpapierkorb. Benötigt werden 40 IOPS für die Datenbank-LUN und 40 IOPS für die Protokoll-LUN. Fügen Sie immer einen Wachstumsfaktor von 20 Prozent für die Datenträger-E/A-Leistung hinzu, um Tage mit höherem Nachrichtenaufkommen zu kompensieren. Als Datenträgerlayout wird RAID1 verwendet. Als Kapazitätsanforderung für die Datenbank-LUN werden in diesem Beispiel ungefähr 55 GB für die Daten einer Woche benötigt. Sie müssen die Kapazitätsanforderung auf 110 GB verdoppeln, wenn die Daten von zwei Wochen aufgezeichnet werden sollen. Bei Verwendung physischer Datenträger mit 140 GB werden eine Datenbank-LUN von 140 GB in einer RAID1-Konfiguration und eine Protokoll-LUN von 140 GB in einer RAID1-Konfiguration bereitgestellt. Ergebnisse finden Sie in der folgenden Tabelle:

Hardwareskalierung für einen Hub-Transport-Server, der bei deaktiviertem Transportpapierkorb 20 Nachrichten pro Sekunde verarbeitet

Datenträger (1) und (2), RAID1-Layout	Datenträger (3) und (4), RAID1-Layout
Betriebssystem und Transaktionsprotokolle 40 + 20% = 48 IOPS	Datenbankprotokolle, Protokolle und Nachrichtenverfolgungsprotokolle sowie Virusquarantäne 40 + 20% = 48 IOPS

Im nächsten Beispiel handelt es sich um einen Hub-Transport-Server mit aktiviertem Transportpapierkorb, der 20 Nachrichten pro Sekunde verarbeitet. Diese Konfiguration erfordert 200 IOPS für die Datenbank-LUN und 140 IOPS für die Protokoll-LUN sowie einen Wachstumsfaktor von 20 Prozent. Als Festplattenlayout wird RAID10 verwendet. In diesem Beispiel liegt die Kapazitätsanforderung der Datenbank-LUN bei ungefähr 55 GB für die Daten einer Woche und bei 110 GB für die Daten von zwei Wochen. Bei Verwendung physischer Datenträger mit 140 GB werden eine Datenbank-LUN von 280 GB in einer RAID10-Konfiguration und eine Protokoll-LUN von 140 GB in einer RAID1-Konfiguration bereitgestellt.

Hardwareskalierung für einen Hub-Transport-Server, der bei aktiviertem Transportpapierkorb 20 Nachrichten pro Sekunde verarbeitet

Datenträger (1) und (2), RAID1-Layout	Datenträger (3), (4), (5) und (6), RAID10-Layout
Betriebssystem und Transaktionsprotokolle 140 + 20% = 168 IOPS	Datenbankprotokolle, Protokolle und Nachrichtenverfolgungsprotokolle sowie Virusquarantäne 200 + 20% = 240 IOPS