Exchange 2010-getestete Lösungen: 32.400 Postfächer an drei Standorten mit Hyper-V auf Cisco Unified Compute System Blade-Servern und EMC CLARiiON-Speicher

 

Letztes Änderungsdatum des Themas: 2016-12-14

Rob Simpson, Program Manager, Microsoft Exchange; Boris Voronin, Sr. Solutions Engineer, Exchange Solutions Engineering, EMC; Mike Mankovsky, Microsoft Solutions Architect, Cisco

Datum

Juni 2011

Exchange 2010 – Getestete Lösungen

Bei den getesteten Lösungen von Exchange 2010 untersuchen Microsoft und beteiligte Server-, Speicher- und Netzwerkpartner gängige Kundenszenarien und wichtige Punkte der Entwurfsentscheidungen von Kunden, die die Bereitstellung von Microsoft Exchange Server 2010 planen. In dieser Reihe von Whitepapern werden Beispiele gut durchdachter, kosteneffektiver Exchange 2010-Lösungen vorgestellt, die auf der von einigen unserer Server-, Speicher- und Netzwerkpartner angebotenen Hardware bereitgestellt wurden.

Sie können dieses Dokument im Microsoft Download Center herunterladen.

Gilt für

Microsoft Exchange Server 2010 mit Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

Inhalt

• Einführung

• Zusammenfassung der Lösung

• Kundenanforderungen

  • Anforderungen an Postfachprofile

  • Anforderungen an geografische Standorte

  • Server- und Datenschutzanforderungen

• Entwurfsannahmen

  • Annahmen zur Serverkonfiguration

  • Annahmen zur Speicherkonfiguration

• Lösungsentwurf

  • Bestimmen der Strategie für Hochverfügbarkeit

  • Schätzen der Speicherkapazitätsanforderungen für Postfächer

  • Schätzen der E/A-Anforderungen von Postfächern

  • Bestimmen des Speichertyps

  • Bestimmen, ob eine DAS- oder SAN-Speicherlösung bevorzugt wird

  • Auswählen der Speicherlösung

  • Schätzen der Arbeitsspeicheranforderungen für Postfächer

  • Berechnen des erforderlichen Datenbankcache

  • Schätzen der CPU-Anforderungen für Postfächer

  • Zusammenfassen der Postfachanforderungen

  • Bestimmen des Servermodells

  • Berechnen der CPU-Kapazität des Servermodells

  • Bestimmen der erforderlichen Anzahl physischer Postfachserver

  • Bestimmen der Anzahl aktiver Postfächer pro Postfachserver in Szenarien mit normalen Betrieb und Ausfällen

  • Bestimmen, ob die Clientzugriffs- und Hub-Transport-Serverrollen auf separaten physischen Servern bereitgestellt werden

  • Bestimmen der erforderlichen Anzahl physischer Clientzugriffs- und Hub-Transport-Kombinationsserver

  • Bestimmen der erforderlichen Gesamtanzahl physischer Server

  • Bestimmen, ob Servervirtualisierung verwendet wird

  • Bestimmen, ob durch Virtualisierung die Anzahl physischer Server reduziert werden kann

  • Berechnen der CPU-Kapazität des Hyper-V-Stammservers

  • Anpassen der verfügbaren Megazyklen für den Virtualisierungsoverhead

  • Bestimmen der CPU-Kapazität der VMs

  • Überprüfen der CPU-Kapazität der primären Postfachserver-VMs

  • Überprüfen der CPU-Kapazität der sekundären Postfachserver-VMs

  • Bestimmen des erforderlichen Arbeitsspeichers pro primärer Postfachserver-VM

  • Bestimmen des erforderlichen Arbeitsspeichers pro sekundärer Postfachserver-VM

  • Bestimmen des erforderlichen Arbeitsspeichers pro Kombination aus Clientzugriffs- und Hub-Transport-Server

  • Bestimmen des erforderlichen Arbeitsspeichers pro Hyper-V-Stammserver

  • Entwerfen von Database Availability Groups

  • Entwerfen des Layouts von Datenbankkopien

  • Datencenter-Aktivierungsmodus

  • Festlegen der Platzierung des Dateifreigabenzeugen

  • Planen von Namespaces

  • Bestimmen der Strategie für das Clientzugriffsserver-Array und den Lastenausgleich

  • Bestimmen eines Modells für den Hardwarelastenausgleich

  • Bestimmen des Speicherentwurfs

• Die Lösung im Überblick

  • Diagramm der logischen Lösung

  • Diagramm der physischen Lösung

  • Zusammenfassung der Hyper-V-Stammserverkonfiguration

  • Konfiguration der Clientzugriffs- und Hub-Transport-Server

  • Konfiguration der Postfachserver

  • Datenbanklayout

  • Zusammenfassung der Speicherhardware

  • Speicherkonfiguration

• Methodik zur Überprüfung der Lösung

  • Methodik der Überprüfung des Speicherentwurfs

  • Überprüfung des Serverentwurfs

  • Tests zur Funktionsüberprüfung

  • Überprüfung des Datenbankswitchovers

  • Überprüfung des Serverswitchovers

  • Überprüfung des Serverfailovers

  • Überprüfung des Datencenterswitchovers

  • Überprüfung der Wiederherstellung des Diensts des primären Datencenters

  • Testeinrichtung

• Ergebnisse der Lösungsüberprüfung

  • Ergebnisse der Funktionsüberprüfung

  • Ergebnisse der Überprüfung des Speicherentwurfs

  • Ergebnisse der Überprüfung des Serverentwurfs

• Zusammenfassung

• Weitere Informationen

Einführung

In diesem Dokument wird ein Bespiel dargestellt, wie eine Exchange Server 2010-Lösung mit der Hyper-V-Technologie von Windows Server 2008 R2 in einer Kundenumgebung mit 32.400 Postfächern auf Cisco Unified Computing System-Bladeservern und mit EMC CLARiiON-Speicherlösungen entworfen, getestet und überprüft wird. Eine der größten Herausforderungen beim Entwurf größerer Exchange 2010-Umgebungen ist die Prüfung der aktuell erhältlichen Server- und Speicheroptionen und die Auswahl der richtigen Hardware, sodass der optimale Nutzen im Verlauf der geschätzten Lebensdauer der Lösung erzielt wird. Im Anschluss an die schrittweise Methodik in diesem Dokument werden die wichtigen Punkte der Entwurfsentscheidungen vorgestellt, mit denen diese Herausforderungen bewältigt werden können, während gleichzeitig sichergestellt wird, dass die grundlegenden Unternehmensanforderungen des Kunden erfüllt werden. Nachdem die optimale Lösung für diesen Kunden bestimmt wurde, wird die Lösung einer standardmäßigen Überprüfung unterzogen, um sicherzustellen, dass sie simulierten Produktionslasten in Szenarien mit normalem Betrieb, Wartung und Ausfällen standhält.

Exchange 2010 – Getestete Lösungen

Zusammenfassung der Lösung

In der folgenden Tabelle werden die wichtigsten Exchange- und Hardwarekomponenten der Lösung dargestellt.

Exchange-Komponenten

Exchange-Komponente	Wert oder Beschreibung
Geplante Postfachanzahl	32400
Geplante durchschnittliche Postfachgröße	2 Gigabyte (GB) (für eine schlanke Speicherzuweisung mit 600 Megabyte (MB) als Anfangsgröße)
Geplantes durchschnittliches Nachrichtenprofil	100 Nachrichten pro Tag
Anzahl der Datenbankkopien	3
Sicherung mit Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS)	Keine
Ausfallsicherheit von Standorten	Ja
Anzahl der Standorte	3
DAG-Modell (Database Availability Group)	Aktiv/Aktiv-Verteilung (mehrere DAGs)
Virtualisierung	Hyper-V
Anzahl der Exchange-Server	4 virtuelle Computer (VMs)
Anzahl physischer Server	2

Hardwarekomponenten

Hardwarekomponente	Wert oder Beschreibung
Partner für Server	Cisco
Servermodell	M200
Servertyp	Blade
Prozessor	Intel Xeon X5570
Partner für Speicher	Exchange-Verwaltungskonsole
Speichermodell	CX4-480
Speichertyp	Storage Area Network (SAN)
Datenträgertyp	450 GB 15.000 SAS 3,5"
Partner für Lastenausgleich	Cisco
Modell für den Hardwarelastenausgleich	ACE

Exchange 2010 – Getestete Lösungen

Kundenanforderungen

Einer der wichtigsten ersten Schritte beim Entwurf einer Exchange-Lösung ist die genaue Zusammenfassung der Unternehmensanforderungen und der technischen Anforderungen, die für die richtigen Entwurfsentscheidungen unabdingbar sind. In den folgenden Abschnitte werden die Kundenanforderungen für diese Lösung skizziert.

Exchange 2010 – Getestete Lösungen

Anforderungen an Postfachprofile

Bestimmen Sie die Anforderungen an Postfachprofile möglichst genau, da diese Anforderungen Einfluss auf alle anderen Komponenten des Entwurfs haben können. Wenn Sie noch nicht mit Exchange vertraut sind, müssen Sie möglicherweise einige fundierte Vermutungen anstellen. Wenn Sie bereits über eine Exchange-Umgebung verfügen, können Sie mit dem Tool Microsoft Exchange Server Profile Analyzer (möglicherweise in englischer Sprache) die meisten dieser Informationen zusammentragen. In den folgenden Tabellen werden die Anforderungen an Postfachprofile für diese Lösung zusammengefasst.

Anforderungen an die Postfachanzahl

Anforderung an die Postfachanzahl	Wert
Postfachanzahl (Gesamtanzahl von Postfächern einschließlich der Ressourcenpostfächer)	30000
Erwartete Zunahme in Prozent (%) der Postfachanzahl (erwartete Zunahme der Postfachanzahl während der Lebensdauer der Lösung)	8 %
Erwarteter Prozentsatz der gleichzeitig genutzten Postfächer (maximale Anzahl aktiver Postfächer zu einem beliebigen Zeitpunkt)	100 %
Geplante Postfachanzahl (Postfachanzahl einschließlich der Zunahme x erwarteter gleichzeitiger Nutzung)	32400

Anforderungen an die Postfachgröße

Anforderung an die Postfachgröße	Wert
Durchschnittliche Postfachgröße in MB	600 MB
Durchschnittliche Postfacharchivgröße in MB	Nicht zutreffend
Erwartete Zunahme in Prozent (%) der Postfachgröße in MB (erwartete Zunahme der Postfachgröße während der Lebensdauer der Lösung)	230 %
Geplante durchschnittliche Postfachgröße in MB	2.048 MB

Anforderungen an Postfachprofile

Anforderung an Postfachprofile	Wert
Geplantes Nachrichtenprofil (durchschnittliche Gesamtanzahl gesendeter und empfangener Nachrichten pro Benutzer und Tag)	100 Nachrichten pro Tag
Geplante durchschnittliche Nachrichtengröße in Kilobyte (KB)	75
% im MAPI-Cachemodus	100
% im MAPI-Onlinemodus	0
% im Outlook Anywhere-Cachemodus	0
% in Microsoft Office Outlook Web App (Outlook Web Access in Exchange 2007 und früheren Versionen)	0
% in Exchange ActiveSync	0

Exchange 2010 – Getestete Lösungen

Anforderungen an geografische Standorte

Es ist wichtig, die Verteilung der Postfachbenutzer und der Datencenter zu kennen, wenn Entscheidungen über Hochverfügbarkeit und die Ausfallsicherheit von Standorten getroffen werden.

In der folgenden Tabelle wird die geografische Verteilung der Benutzer des Exchange-Systems dargestellt.

Geografische Verteilung der Benutzer

Standortanforderung für Postfachbenutzer	Wert
Anzahl großer Standorte mit Postfachbenutzern	3
Anzahl der Postfachbenutzer an Standort 1	10800
Anzahl der Postfachbenutzer an Standort 2	10800
Anzahl der Postfachbenutzer an Standort 3	10800

In der folgenden Tabelle wird die geografische Verteilung der Datencenter dargestellt, die die Exchange-E-Mail-Infrastruktur unterstützen könnten.

Geografische Verteilung der Datencenter

Standortanforderung für Datencenter	Wert
Gesamtanzahl der Datencenter	3
Anzahl der aktiven Postfächer in der Nähe von Datencenter 1	10800
Anzahl der aktiven Postfächer in der Nähe von Datencenter 2	10800
Anzahl der aktiven Postfächer in der Nähe von Datencenter 3	10800
Anforderung, dass Exchange in mehr als einem Datencenter installiert ist	Ja

Exchange 2010 – Getestete Lösungen

Server- und Datenschutzanforderungen

Es ist auch wichtig, die Server- und Datenschutzanforderungen für die Umgebung zu definieren, da diese Anforderungen Entwurfsentscheidungen zu Hochverfügbarkeit und Ausfallsicherheit von Standorten unterstützen.

In der folgenden Tabelle werden die Serverschutzanforderungen aufgezeigt.

Serverschutzanforderungen

Serverschutzanforderung	Wert
Anzahl gleichzeitiger Server- oder VM-Ausfälle am Standort	1
Anzahl gleichzeitiger Server- oder VM-Ausfälle während eines Standortausfalls	0

In der folgenden Tabelle werden die Datenschutzanforderungen aufgezeigt.

Datenschutzanforderungen

Datenschutzanforderung	Wert oder Beschreibung
Anforderung zur Aufbewahrung einer Sicherung der Exchange-Datenbanken außerhalb der Exchange-Umgebung (beispielsweise eine Sicherungslösung eines Drittanbieters)	Nein
Anforderung zur Aufbewahrung von Kopien der Exchange-Datenbanken in der Exchange-Umgebung (beispielsweise der systemeigene Exchange-Datenschutz)	Ja
Anforderung zur Aufbewahrung mehrerer Kopien von Postfachdaten im primären Datencenter	Ja
Anforderung zur Aufbewahrung mehrerer Kopien von Postfachdaten in einem sekundären Datencenter	Nein
Anforderung zur Aufbewahrung einer verzögerten Kopie von Exchange-Datenbanken	Nein
Zeitraum der verzögerten Kopie in Tagen	Nicht zutreffend
Geplante Anzahl von Datenbankkopien	3
Aufbewahrung des Ordners "Gelöschte Elemente" in Tagen	14

Exchange 2010 – Getestete Lösungen

Entwurfsannahmen

Dieser Abschnitt enthält Informationen, die nicht üblicherweise zusammen mit den Kundenanforderungen erfasst werden, die aber für den Entwurf und die Vorgehensweise zur Entwurfsprüfung entscheidend sind.

Exchange 2010 – Getestete Lösungen

Annahmen zur Serverkonfiguration

In der folgenden Tabelle wird die geplante CPU-Spitzenauslastung bei normalen Betriebsbedingungen und bei Ausfällen bzw. der Wartung von Standortservern beschrieben.

Geplante Serverauslastung

Entwurfsannahme für die geplante CPU-Auslastung des Servers	Wert
Normaler Betrieb für Postfachserver	< 70 %
Normaler Betrieb für Clientzugriffsserver	< 70 %
Normaler Betrieb für Hub-Transport-Server	< 70 %
Normaler Betrieb für mehrere Serverrollen (Clientzugriffs-, Hub-Transport- und Postfachserver)	< 70 %
Normaler Betrieb für mehrere Serverrollen (Clientzugriffs- und Hub-Transport-Server)	< 70 %
Knotenausfall für Postfachserver	< 80 %
Knotenausfall für Clientzugriffsserver	< 80 %
Knotenausfall für Hub-Transport-Server	< 80 %
Knotenausfall für mehrere Serverrollen (Clientzugriffs-, Hub-Transport- und Postfachserver)	< 80 %
Knotenausfall für mehrere Serverrollen (Clientzugriffs- und Hub-Transport-Server)	< 80 %
Standortausfall für Postfachserver	< 80 %
Standortausfall für Clientzugriffsserver	< 80 %
Standortausfall für Hub-Transport-Server	< 80 %
Standortausfall für mehrere Serverrollen (Clientzugriffs-, Hub-Transport- und Postfachserver)	<80 %
Standortausfall für mehrere Serverrollen (Clientzugriffs- und Hub-Transport-Server)	< 80 %

Exchange 2010 – Getestete Lösungen

Annahmen zur Speicherkonfiguration

In der folgenden Tabelle werden einige Annahmen zur Datenkonfiguration und zu Eingabe/Ausgabe (E/A) zusammengefasst, die beim Entwurf der Speicherkonfiguration festgelegt wurden.

Annahmen zur Datenkonfiguration

Annahme zur Datenkonfiguration	Wert oder Beschreibung
Datenoverheadfaktor	20 %
Postfachverschiebungen pro Woche	1 %
Dedizierte Wartung oder Wiederherstellung logischer Gerätenummern (Logical Unit Number, LUN)	Nein
Freier LUN-Speicherplatz	20 %
Komprimierung beim Protokollversand aktiviert	Ja
Verschlüsselung beim Protokollversand aktiviert	Ja

Annahmen zur E/A-Konfiguration

Annahme zur E/A-Konfiguration	Wert oder Beschreibung
E/A-Overheadfaktor	20 %
Zusätzliche E/A-Anforderungen	Keine

Exchange 2010 – Getestete Lösungen

Lösungsentwurf

Der folgende Abschnitt enthält eine schrittweise Methodik für den Entwurf dieser Lösung. Bei dieser Methodik werden die Kundenanforderungen und Entwurfsannahmen berücksichtigt und wichtige Punkte der Entwurfsentscheidungen behandelt, die beim Entwurf einer Exchange 2010-Umgebung getroffen werden müssen.

Exchange 2010 – Getestete Lösungen

Bestimmen der Strategie für Hochverfügbarkeit

Beim Entwurf einer Exchange 2010-Umgebung haben viele Punkte der Entwurfsentscheidungen hinsichtlich der Strategien für Hochverfügbarkeit Einfluss auf andere Entwurfskomponenten. Wir empfehlen, dass Sie als ersten Schritt des Entwurfs Ihre Strategie für Hochverfügbarkeit festlegen. Wir empfehlen dringend, die folgenden Informationen zu lesen, bevor Sie mit diesem Schritt beginnen:

• Grundlegendes zu hoher Verfügbarkeit

• Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten

• Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung

Schritt 1: Bestimmen, ob Ausfallsicherheit von Standorten erforderlich ist

Wenn Sie über mehr als ein Datencenter verfügen, müssen Sie entscheiden, ob Sie die Exchange-Infrastruktur in einem Datencenter bereitstellen oder über zwei oder mehr Datencenter verteilen. Die Vereinbarungen zum Servicelevel (SLAs, Service Level Agreements) für Wiederherstellungen in der Organisation definieren, welcher Servicelevel nach einem Ausfall des primären Datencenters erforderlich ist. Diese Informationen sollten die Grundlage für diese Entscheidung bilden.

*Entwurfsentscheidungspunkt*

In dieser Lösung gibt es drei physische Datencenterstandorte. In der SLA ist angegeben, dass Ausfallsicherheit von Datencentern für alle geschäftskritischen Dienste, einschließlich E-Mail, erforderlich ist. Der Exchange 2010-Entwurf wird auf einer Bereitstellung mit mehreren Standorten mit Ausfallsicherheit von Standorten für den Messagingdienst und die entsprechenden Daten basieren.

Schritt 2: Bestimmen der Beziehung zwischen den Standorten von Postfachbenutzern und Datencentern

In diesem Schritt wird geprüft, ob sich alle Postfachbenutzer primär an einem Standort befinden oder ob sie über viele Standorte verteilt sind und ob diesen Standorten Datencenter zugeordnet sind. Wenn sie über viele Standorte verteilt sind und diesen Standorten Datencenter zugeordnet sind, müssen Sie bestimmen, ob die Affinität zwischen Postfachbenutzern und den dem Standort zugeordneten Datencenter erhalten bleiben muss.

*Entwurfsentscheidungspunkt*

In diesem Beispiel befinden sich die drei Datencenter in regionalen Niederlassungen. Es besteht der Wunsch, die Affinität zwischen dem Benutzerstandort und dem Standort der primären aktiven Kopie des Postfachs während normaler Betriebsbedingungen zu erhalten.

Schritt 3: Bestimmen des Modells für die Datenbankverteilung

Da der Kunde entschieden hat, die Exchange-Infrastruktur an mehreren physischen Standorten bereitzustellen, muss der Kunde bestimmen, welches Modell für die Datenbankverteilung die Anforderungen der Organisation am besten erfüllt. Es gibt drei Modelle für die Datenbankverteilung:

• Aktiv/Passiv-Verteilung   Aktive Postfachdatenbankkopien werden im primären Datencenter bereitgestellt, und nur passive Datenbankkopien werden im sekundären Datencenter bereitgestellt. Das sekundäre Datencenter dient als Ersatzdatencenter, und unter normalen Betriebsbedingungen werden keine aktiven Postfächer im Datencenter gehostet. Bei einem Ausfall mit Auswirkungen auf das primäre Datencenter erfolgt ein manueller Switchover auf das sekundäre Datencenter, und die Datenbanken werden dort gehostet, bis das primäre Datencenter wieder online ist.

  Aktiv/Passiv-Verteilung

• Aktiv/Aktiv-Verteilung (eine DAG)   Aktive Postfachdatenbanken werden im primären und sekundären Datencenter bereitgestellt. Eine entsprechende passive Kopie befindet sich im alternativen Datencenter. Alle Postfachserver sind Mitglieder einer einzelnen DAG. In diesem Modell stellt die WAN-Verbindung (Wide Area Network) zwischen den beiden Datencentern eine mögliche Fehlerquelle dar. Die Unterbrechung der WAN-Verbindung führt dazu, dass die Postfachserver in einem der Datencenter aufgrund des Quorumverlusts in einen Fehlerzustand versetzt.

  Aktiv/Aktiv-Verteilung (eine DAG)

• Aktiv/Aktiv-Verteilung (mehrere DAGs)   Dieses Modell nutzt mehrere DAGs, um die WAN-Verbindung als Fehlerquelle auszuschließen. Eine DAG enthält aktive Datenbankkopien im ersten Datencenter und die entsprechenden passiven Datenbankkopien im zweiten Datencenter. Die zweite DAG enthält aktive Datenbankkopien im zweiten Datencenter und die entsprechenden passiven Datenbankkopien im ersten Datencenter. Bei einer Unterbrechung der WAN-Verbindung ist durch die aktiven Kopien an jedem Standort die Datenbank für die lokalen Postfachbenutzer weiterhin verfügbar.

  Aktiv/Aktiv-Verteilung (mehrere DAGs)

*Entwurfsentscheidungspunkt*

Da in diesem Beispiel die aktiven Postfachdatenbanken an jedem der drei Datencenterstandorte bereitgestellt werden, ist das Modell für die Datenbankverteilung Aktiv/Aktiv mit mehreren DAGs. Es gibt einige zusätzliche Entwurfsüberlegungen bei der Bereitstellung eines Modells für die Datenbankverteilung vom Typ Aktiv/Aktiv mit mehreren DAGs, die in einem späteren Schritt behandelt werden.

Schritt 4: Bestimmen einer Strategie für Sicherung und Ausfallsicherheit von Datenbanken

In Exchange 2010 sind verschiedene neue Funktionen und grundlegende Änderungen enthalten, die bei ordnungsgemäßer Bereitstellung und Konfiguration einen Schutz systemeigener Daten bieten können, der die Notwendigkeit aufhebt, herkömmliche Datensicherungen zu erstellen. Sicherungen werden üblicherweise für eine Notfallwiederherstellung, die Wiederherstellung versehentlich gelöschter Elemente, eine langfristige Datenspeicherung und die Datenbankwiederherstellung zu einem bestimmten Zeitpunkt verwendet. Exchange 2010 ist ohne herkömmliche Sicherungen für diese Szenarien geeignet:

• Notfallwiederherstellung   Bei einem Hardware- oder Softwareausfall ermöglicht das Vorhandensein mehrerer Datenbankkopien in einer DAG eine hohe Verfügbarkeit mit schnellem Failover und ohne Datenverluste. DAGs können auf mehrere Standorte erweitert werden, um Ausfallsicherheit für Datencenter bereitzustellen.

• Wiederherstellung versehentlich gelöschter Elemente   Mit dem neuen Ordner "Wiederherstellbare Elemente" in Exchange 2010 und der Aufbewahrungsrichtlinie, die auf ihn angewendet werden kann, können alle gelöschten und geänderten Daten für einen angegebenen Zeitraum aufbewahrt werden, sodass ihre Wiederherstellung leichter und schneller möglich ist. Weitere Informationen finden Sie unter Messagingrichtlinie und -einhaltung, Grundlegendes zu wiederherstellbaren Elementen und Grundlegendes zu Aufbewahrungstags und Aufbewahrungsrichtlinien.

• Langfristige Datenspeicherung   Manchmal dienen Sicherungen auch zur Archivierung. Üblicherweise werden Bänder verwendet, um Momentaufnahmen von Daten für längere Zeit aufzubewahren, wie von den Anforderungen zur Einhaltung von Vorschriften vorgegeben. Die neuen Funktionen für Archivierung, Suche in mehreren Postfächern und Nachrichtenaufbewahrung in Exchange 2010 stellen einen Mechanismus für die effiziente langfristige Aufbewahrung von Daten bereit, wobei die Endbenutzer auf die Daten zugreifen können. Weitere Informationen finden Sie unter Grundlegendes zu persönlichen Archiven, Grundlegendes zur Suche in mehreren Postfächern und Grundlegendes zu Aufbewahrungstags und Aufbewahrungsrichtlinien.

• Datenbankmomentaufnahme   Wenn für Ihre Organisation eine Kopie der Postfachdaten zu einem vergangenen Zeitpunkt erforderlich ist, können Sie mit Exchange eine verzögerte Kopie in einer DAG-Umgebung erstellen. Dies kann in dem seltenen Fall nützlich sein, dass eine logische Beschädigung vorliegt und auf die Datenbanken in der DAG repliziert wird, sodass die Rückkehr zu einem bestimmten Zeitpunkt in der Vergangenheit erforderlich ist. Es kann auch hilfreich sein, wenn ein Administrator versehentlich Postfächer oder Benutzerdaten löscht.

Sie sollten technische Aspekte und verschiedene Probleme berücksichtigen, bevor Sie die integrierten Funktionen von Exchange 2010 als Ersatz für herkömmliche Sicherungen verwenden. Lesen Sie Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung, bevor Sie diese Entscheidung treffen.

*Entwurfsentscheidungspunkt*

In diesem Beispiel ist mit der aktuellen Exchange-Implementierung die primäre Verwendung der herkömmlichen Sicherungslösung die Wiederherstellung versehentlich gelöschter Nachrichtenelemente. 80 Prozent der Anforderungen zur Wiederherstellung einzelner Elemente beziehen sich auf Nachrichten, die weniger als 15 Tage alt sind. Daher beträgt der Aufbewahrungszeitraum für gelöschte Elemente 14 Tage. Da herkömmliche VSS-Sicherungen für die Wiederherstellung eines einzelnen Elements nicht erforderlich sind und die angestrebte Wiederherstellungsdauer nicht einhalten, werden als Aufbewahrungsfunktionen der systemeigene Exchange-Datenschutz und der Ordner "Gelöschte Elemente" für die Strategie zur Ausfallsicherheit von Datenbanken verwendet.

Schritt 5: Bestimmen der erforderlichen Anzahl von Datenbankkopien

Die nächste wichtige Entscheidung bei der Definition der Strategie zur Ausfallsicherheit von Datenbanken besteht darin, die Anzahl der bereitzustellenden Datenbankkopien zu bestimmen. Es wird dringend empfohlen, mindestens drei Kopien einer Postfachdatenbank bereitzustellen, bevor Sie herkömmliche Arten des Schutzes für die Datenbank aufgeben, z. B. RAID (Redundant Array of Independent Disks) oder herkömmliche VSS-basierte Sicherungen.

Lesen Sie Grundlegendes zu Postfachdatenbankkopien, bevor Sie diese Entscheidung treffen.

*Entwurfsentscheidungspunkt*

Da in diesem Beispiel eine herkömmliche VSS-Sicherungslösung nicht bereitgestellt wird, werden mindestens drei Datenbankkopien bereitgestellt, damit die Anforderungen für die angestrebte Wiederherstellungsdauer und den angestrebten Wiederherstellungszeitpunkt erfüllt werden. Zwei Kopien werden im primären Datencenter abgelegt, und eine dritte Kopie wird in einem alternativen Datencenter gespeichert, um Ausfallsicherheit von Standorten zu schaffen.

Schritt 6: Bestimmen des Datenbankkopietyps

Es gibt zwei Typen von Datenbankkopien:

• Datenbankkopie mit hoher Verfügbarkeit   Diese Datenbankkopie wird mit einer Wiedergabeverzögerung von null konfiguriert. Wie der Name nahelegt, werden Datenbankkopien mit hoher Verfügbarkeit vom System aktualisiert, sie können vom System automatisch aktiviert werden, und sie werden verwendet, um Hochverfügbarkeit für Postfachdienste und -daten bereitzustellen.

• Verzögerte Datenbankkopie   Diese Datenbankkopie wird so konfiguriert, dass sie die Wiedergabe von Transaktionsprotokollen für eine bestimmte Zeit verzögert. Verzögerte Datenbankkopien bieten Zeitpunktschutz für die Wiederherstellung eines Informationsspeichers nach logischer Beschädigung, administrativen Fehlern (z. B. Löschen oder Leeren eines getrennten Postfachs) und Automatisierungsfehlern (z. B. Massenleeren getrennter Postfächer).

*Entwurfsentscheidungspunkt*

In diesem Beispiel werden alle drei Postfachdatenbankkopien als Kopien mit hoher Verfügbarkeit bereitgestellt. Die SLA erfordert keine verzögerte Kopie der Daten. Da in der Vergangenheit keine logische Beschädigung aufgetreten ist und keine anderen Anwendungen verwendet werden, die Messagingdaten bearbeiten, ist eine verzögerte Kopie nicht erforderlich. Der einzige andere Grund für eine verzögerte Kopie wäre, eine Möglichkeit zur Wiederherstellung einzelner gelöschter Elemente bereitzustellen. Diese Anforderung kann aber viel einfacher und kosteneffektiver über den Ordner "Gelöschte Elemente" als Aufbewahrungsfunktion erfüllt werden.

Schritt 7: Bestimmen der Strategie für die Ausfallsicherheit von Postfachservern

Exchange 2010 wurde im Hinblick auf die Ausfallsicherheit von Postfächern überarbeitet. Jetzt wird ein automatischer Failoverschutz auf Ebene der Postfachdatenbanken angeboten, und nicht auf Serverebene. Sie können aktive und passive Datenbankkopien an Postfachserver innerhalb einer DAG strategisch verteilen. Die Bestimmung, wie viele Datenbankkopien pro Server aktiviert werden sollen, ist ein wichtiger Aspekt der Exchange 2010-Kapazitätsplanung. Es gibt unterschiedliche Modelle für die Datenbankverteilung, die Sie bereitstellen können, aber wir empfehlen im Allgemeinen eines der folgenden:

• Entwurf für alle aktivierten Kopien   In diesem Modell ist die Größe der Postfachserverrolle so ausgelegt, dass die Aktivierung aller Datenbankkopien auf dem Server möglich ist. Beispielsweise kann ein Postfachserver vier Datenbankkopien hosten. Bei normalen Betriebsbedingungen können auf dem Server zwei Datenbankkopien aktiv und zwei passiv sein. Bei einem Ausfall oder während einer Wartung werden alle vier Datenbankkopien auf dem Postfachserver aktiviert. Diese Lösung wird normalerweise paarweise bereitgestellt. Wenn z. B. vier Server bereitgestellt werden, ist das erste Serverpaar MBX1 und MBX2, und das zweite Serverpaar ist MBX3 und MBX4. Bei einem Entwurf nach diesem Modell legen Sie zudem als Größe der einzelnen Postfachserver nicht mehr als 40 Prozent der verfügbaren Ressourcen bei normalen Betriebsbedingungen fest. In einer Bereitstellung mit ausfallsicheren Standorten mit drei Datenbankkopien und sechs Servern kann dieses Modell in Gruppen aus drei Servern bereitgestellt werden, wobei sich der dritte Server im sekundären Datencenter befindet. Dieses Modell bietet einen Baustein aus drei Servern für Lösungen, in denen ein Aktiv/Passiv-Modell mit Ausfallsicherheit von Standorten eingesetzt wird.

  Dieses Modell kann in folgenden Szenarien verwendet werden:

  • Aktiv/Passiv-Konfiguration mit mehreren Standorten, in der für Fehlerbereiche (wie Gestelle, Bladesysteme und Speicherarrays) eine leichte Isolation von Datenbankkopien im primären Datencenter erforderlich ist

  • Aktiv/Passiv-Konfiguration mit mehreren Standorten, in der das erwartete Wachstum einer leichte Ergänzung logischer Einheiten zur Skalierung erfordern kann

  • Konfigurationen, die den gleichzeitigen Verlust von zwei beliebigen Postfachservern in der DAG nicht überstehen müssen

  Bei diesem Modell müssen Server in Bereitstellungen mit einem Standort paarweise und in Bereitstellungen mit mehreren Standorten in Gruppen zu je drei bereitgestellt werden. Die folgende Tabelle zeigt ein Beispiellayout der Datenbank für dieses Modell.

  Entwurf für alle aktivierten Kopien

  In der obigen Tabelle gilt Folgendes:

  • C1 = aktive Kopie (Aktivierungseinstellungswert 1) im normalen Betrieb

  • C2 = passive Kopie (Aktivierungseinstellungswert 2) im normalen Betrieb

  • C3 = passive Kopie (Aktivierungseinstellungswert 3) bei einem Standortausfall

• Entwurf für geplante Fehlerszenarien   In diesem Modell ist die Postfachserverrolle so ausgelegt, dass die Aktivierung einer Teilmenge der Datenbankkopien auf dem Server möglich ist. Die Anzahl der Datenbankkopien in der Teilmenge hängt vom jeweiligen Fehlerszenario ab, für das der Entwurf gilt. Das Hauptziel dieses Entwurfs ist eine gleichmäßige Verteilung der aktiven Datenbanklasten auf die verbleibenden Postfachserver in der DAG.

  Dieses Modell sollte in folgenden Szenarien verwendet werden:

  • Alle Konfigurationen mit einem Standort und mit drei oder mehr Datenbankkopien

  • Konfigurationen, die den gleichzeitigen Verlust von zwei beliebigen Postfachservern in der DAG überstehen müssen

  Der DAG-Entwurf für dieses Modell erfordert zwischen drei und 16 Postfachserver. Die folgende Tabelle zeigt ein Beispiellayout der Datenbank für dieses Modell.

  Entwurf für geplante Fehlerszenarien

  In der obigen Tabelle gilt Folgendes:

  • C1 = aktive Kopie (Aktivierungseinstellungswert 1) im normalen Betrieb

  • C2 = passive Kopie (Aktivierungseinstellungswert 2) im normalen Betrieb

  • C3 = passive Kopie (Aktivierungseinstellungswert 3) im normalen Betrieb

*Entwurfsentscheidungspunkt*

In einem vorherigen Schritt wurde entschieden, ein Modell für die Datenbankverteilung vom Typ Aktiv/Aktiv mit mehreren DAGs bereitzustellen. Da jede DAG in diesem Modell eine Aktiv/Passiv-Konfiguration mit nur zwei Datenbankkopien mit hoher Verfügbarkeit im primären Datencenter aufweist, ist eine Strategie für die Ausfallsicherheit von Postfachservern, bei der alle Kopien aktiviert sind, am besten geeignet.

Schritt 8: Bestimmen der Anzahl von Database Availability Groups

Eine Database Availability Group (DAG) ist die Basiskomponente des Systems für Hochverfügbarkeit und Ausfallsicherheit von Standorten in Exchange 2010. Eine DAG besteht aus bis zu 16 Postfachservern, die eine Gruppe von replizierten Datenbanken hosten und eine automatische Wiederherstellung auf Datenbankebene nach Fehlern bieten, die einzelne Server oder Datenbanken betreffen.

Eine DAG stellt eine Abgrenzung für die Replikation der Postfachdatenbank, für Datenbank- und Serverswitchover, für Failover sowie für eine interne Komponente namens Active Manager dar. Active Manager ist eine Exchange 2010-Komponente, die Switchover und Failover verwaltet. Active Manager wird auf jedem Server in einer DAG ausgeführt.

Im Hinblick auf die Planung sollten Sie die Anzahl der bereitgestellten DAGs minimieren. In folgenden Fällen sollten Sie mehr als eine DAG nutzen:

• Sie stellen mehr als 16 Postfachserver bereit.

• Sie haben aktive Postfachbenutzer an mehreren Standorten (Aktiv/Aktiv-Standortkonfiguration).

• Sie benötigen separate Verwaltungsgrenzen auf DAG-Ebene.

• Sie verfügen über Postfachserver in separaten Domänen. (Die DAG ist an die Domäne gebunden.)

*Entwurfsentscheidungspunkt*

In einem vorherigen Schritt wurde entschieden, ein Modell für die Datenbankverteilung vom Typ Aktiv/Aktiv bereitzustellen. Eine DAG mit aktiven Postfachbenutzern an jedem Standort könnte bereitgestellt werden. Wenn jedoch DAG-Mitglieder an einem Standort vorübergehend die Verbindung mit DAG-Mitgliedern am anderen Standort verlieren, verliert der Cluster an dem Standort Quorum und funktioniert nicht mehr ordnungsgemäß. Aus diesem Grund werden drei DAGs bereitgestellt. Jede DAG enthält Postfachserver aus dem primären Datencenter, die die primären und sekundären Datenbankkopien hosten. Jede DAG enthält zudem Server in einem der alternativen Datencenter, die die dritte Datenbankkopie hosten. Der resultierende Entwurf besteht aus drei Aktiv/Passiv-DAGs, bei denen das Datencenter jeweils die primären und sekundären Kopien von einer DAG sowie die dritten Kopien von einer anderen DAG hostet.

Schritt 9: Bestimmen der Anzahl der Postfachserver pro DAG

In diesem Schritt müssen Sie die Mindestanzahl der Postfachserver bestimmen, die zur Unterstützung des DAG-Entwurfs erforderlich sind. Diese Anzahl kann sich von der Anzahl der Server unterscheiden, die für die Arbeitslast erforderlich sind. Die endgültige Entscheidung zur Serveranzahl wird deshalb in einem späteren Schritt getroffen.

*Entwurfsentscheidungspunkt*

In einem vorherigen Schritt wurde entschieden, drei Aktiv/Passiv-DAGs bereitzustellen und eine Strategie für die Ausfallsicherheit von Servern zu entwerfen, bei der alle Kopien aktiviert sind. Für jede DAG müssen drei Server (zwei am primären Standort oder einer am alternativen Standort) schrittweise bereitgestellt werden. Da drei DAGs bereitgestellt werden, sind zur Unterstützung des DAG-Entwurfs mindestens neun Server erforderlich. Abhängig von der für die Arbeitslast erforderlichen Anzahl von Servern weist die Lösung 9, 18 oder 27 Server auf. Die folgende Tabelle zeigt mögliche Konfigurationen.

Anzahl der Postfachserver pro DAG

DAG1 – Primäres Datencenter	DAG1 – Sekundäres Datencenter	DAG2 – Primäres Datencenter	DAG2 – Sekundäres Datencenter	DAG3 – Primäres Datencenter	DAG3 – Sekundäres Datencenter	Gesamtanzahl der Postfachserver
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

Exchange 2010 – Getestete Lösungen

Schätzen der Speicherkapazitätsanforderungen für Postfächer

Viele Faktoren beeinflussen die Speicherkapazitätsanforderungen für die Postfachserverrolle. Weitere Informationen finden Sie unter Grundlegendes zu Postfachdatenbank- und Protokollkapazität.

Die folgenden Schritte beschreiben, wie die Kapazitätsanforderungen für Postfächer berechnet werden. Diese Anforderungen werden dann herangezogen, um Entscheidungen darüber zu treffen, welche Optionen für Speicherlösungen die Kapazitätsanforderungen erfüllen. In einem späteren Abschnitt werden zusätzliche Berechnungen behandelt, die für den ordnungsgemäßen Entwurf des Speicherlayouts auf der ausgewählten Speicherplattform erforderlich sind.

Microsoft hat einen Anforderungsrechner für die Postfachserverrolle erstellt, der Ihnen einen Großteil dieser Arbeit abnimmt. Informationen zum Herunterladen des Rechners finden Sie unter Anforderungsrechner für die E2010-Postfachserverrolle (möglicherweise in englischer Sprache). Weitere Informationen zur Verwendung des Rechners finden Sie unter Anforderungsrechner für die Exchange 2010-Postfachserverrolle (möglicherweise in englischer Sprache).

Schritt 1: Berechnen der Postfachgröße auf dem Datenträger

Bevor Sie versuchen, die Gesamtspeicheranforderungen zu bestimmen, sollten Sie die Postfachgröße auf dem Datenträger kennen. Ein volles Postfach mit einem Kontingent von 1 GB erfordert einen Speicherplatz von mehr als 1 GB, da Sie die Grenzwerte für Sende- und Empfangsverbote, die Anzahl der vom Benutzer pro Tag gesendeten oder empfangenen Nachrichten, die Aufbewahrung im Ordner "Gelöschte Elemente" (mit oder ohne Aktivierung von Kalenderversionsprotokollierung und Wiederherstellung einzelner Objekte) und die täglichen Schwankungen einer durchschnittlichen Datenbank pro Postfach berücksichtigen müssen. Der Anforderungsrechner für die Postfachserverrolle nimmt diese Berechnungen für Sie vor. Sie können auch die folgenden Informationen verwenden, um die Berechnungen manuell durchzuführen.

Mit den folgenden Berechnungen wird die Postfachgröße auf dem Datenträger für ein Postfach mit einer Postfachbegrenzung von 2 GB in dieser Lösung bestimmt:

• Leere Seiten = 100 Nachrichten pro Tag × 75 ÷ 1024 MB = 7,3 MB

• Dumpster = (100 Nachrichten pro Tag × 75 ÷ 1024 MB × 14 Tage) + (2048 MB × 0,012) + (2048 MB × 0,058) = 246 MB

• Postfachgröße auf dem Datenträger = Postfachbegrenzung + leere Seiten + Dumpster

  = 2048 + 7,3 + 246

  = 2301 MB

Schritt 2: Berechnen der Speicherkapazitätsanforderungen für die Datenbank

In diesem Schritt wird die allgemeine Speicherkapazität bestimmt, die für alle Postfachdatenbanken erforderlich ist. Die berechnete Kapazität umfasst die Datenbankgröße, die Katalogindexgröße und 20 Prozent freien Speicherplatz.

Verwenden Sie die folgenden Formeln, um die für alle Datenbanken erforderliche Speicherkapazität zu bestimmen:

• Datenbankgröße = (Anzahl von Postfächern × Postfachgröße auf dem Datenträger × Datenbankoverhead-Wachstumsfaktor) + (20 % Datenoverhead)

  = (32400 × 2301 × 1) + (14910480)

  = 89462880 MB

  = 87366 GB

• Datenbankindexgröße = 10 % der Datenbankgröße

  = 87366 × 0,10

  = 8737 GB

• Gesamtdatenbankkapazität = (Datenbankgröße) + (Indexgröße) ÷ 0,80, um 20 % freien Speicherplatz auf dem Volume zu ergänzen

  = (87366 + 8737) ÷ 0,8

  = 120128 GB

Schritt 3: Berechnen der Speicherkapazitätsanforderungen für das Transaktionsprotokoll

Um zu vermeiden, dass der Postfachserver aufgrund von Speicherzuordnungsproblemen ausfällt, muss die Größe der Transaktionsprotokolle ebenfalls festgelegt werden, sodass alle während des Sicherungssatzes generierten Protokolle problemlos speichert werden können. Vorausgesetzt, dass in dieser Architektur die Funktionen für die Ausfallsicherheit von Postfächern und die Wiederherstellung einzelner Elemente als Sicherungsarchitektur verwendet werden, sollte für die Protokollkapazität das dreifache der täglichen Protokollgenerierungsrate reserviert werden, falls eine fehlerhafte Kopie nicht innerhalb von drei Tagen repariert wird. (Jede fehlerhafte Kopie verhindert die Protokollabschneidung.) Falls der Server innerhalb von drei Tagen nicht wieder online ist, könnten Sie die Kopie vorübergehend entfernen, um die Abschneidung zu ermöglichen.

Verwenden Sie die folgenden Formeln, um die für alle Transaktionsprotokolle erforderliche Speicherkapazität zu bestimmen:

• Größe der Protokolldateien = (Größe der Protokolldatei × Anzahl von Protokollen pro Postfach und Tag × Anzahl der für den Ersatz einer ausgefallenen Infrastruktur erforderlich Tage × Anzahl von Postfachbenutzern) + (1 % Postfachverschiebungsoverhead)

  = (1 MB × 20 × 4 × 32400) + (32400 × 0,01 × 2048 MB)

  = 3255552 MB

  = 3179 GB

• Gesamtprotokollkapazität = (Größe der Protokolldateien) ÷ 0,80, um 20 % freien Speicherplatz auf dem Volume zu ergänzen

  = (3179) ÷ 0,80

  = 3974

Schritt 4: Bestimmen der gesamten Speicherkapazitätsanforderungen

In der folgenden Tabelle werden die allgemeinen Speicherkapazitätsanforderungen für diese Lösung zusammengefasst. In einem späteren Schritt werden Sie anhand dieser Informationen Entscheidungen darüber treffen, welche Speicherlösung bereitgestellt werden soll. Dann werden Sie sich in späteren Schritten die speziellen Speicheranforderungen genauer ansehen.

Zusammenfassung der Speicherkapazitätsanforderungen

Erforderlicher Speicherplatz	Wert
Durchschnittliche Postfachgröße auf dem Datenträger (MB)	2301
Erforderliche Datenbankkapazität (GB)	120128
Erforderliche Protokollkapazität (GB)	3974
Erforderliche Gesamtkapazität (GB)	124102
Erforderliche Gesamtkapazität für drei Datenbankkopien (GB)	372306
Erforderliche Gesamtkapazität für drei Datenbankkopien (Terabyte)	364
Für jeden Standort erforderliche Gesamtkapazität (Terabyte)	122

Exchange 2010 – Getestete Lösungen

Schätzen der E/A-Anforderungen von Postfächern

Beim Entwurf einer Exchange-Umgebung müssen Sie die Datenbank- und Protokollleistungsfaktoren verstehen. Es wird empfohlen, das Thema Grundlegendes zu Faktoren für Datenbank- und Protokollleistung zu lesen.

Schritt 1: Berechnen der E/A-Gesamtanforderungen für Postfächer

Da es eine der wichtigsten transaktionellen E/A-Metriken ist, die zur angemessenen Dimensionierung des Speichers erforderlich ist, sollten Sie den Umfang von Datenbank-E/A pro Sekunde (I/O Per Second, IOPS) kennen, der von jedem Postfachbenutzer genutzt wird. Rein sequenzielle E/A-Vorgänge werden bei der Berechnung der IPOS pro Postfachserver nicht berücksichtigt, da sequenzielle E/A-Vorgänge wesentlich effizienter von Speichersubsystemen verarbeitet werden können, als zufällige E/A-Vorgänge. Diese Vorgänge umfassen die Datenbankwartung im Hintergrund, transaktionelle Protokoll-E/A und Protokollreplikations-E/A. In diesem Schritt berechnen Sie mit den folgenden Angaben den IOPS-Gesamtwert, der zur Unterstützung aller Postfachbenutzer erforderlich ist:

• Geschätzte IOPS pro Postfachbenutzer = 0,10

• Insgesamt erforderliche IOPS = IOPS pro Postfachbenutzer × Anzahl von Postfächern × E/A-Overheadfaktor

  = 0,10 × 32400 × 1,2

  = 3888

Schritt 2: Berechnen der E/A-Gesamtanforderungen für Postfächer pro Standort

Da es sich um eine Bereitstellung mit mehreren Standorten handelt, müssen Sie die IOPS-Anforderungen pro Standort berücksichtigen, um den Speicher für jeden Standort richtig zu dimensionieren. In einem vorherigen Schritt wurde entschieden, dass jeder Standort die primären und sekundären Datenbankkopien der primären DAG und die tertiäre Datenbankkopie einer anderen DAG hostet. In diesem Modell wäre der schlimmste Fall, dass ein Standort ausfällt und dabei 10.800 Postfächer der primären DAG und 10.800 Postfächer der anderen DAG im Speicher dieses Standorts aktiv sind. Verwenden Sie die folgende Berechnung:

• Insgesamt pro Standort erforderliche IOPS = IOPS pro Postfachbenutzer × Anzahl von Postfächern × E/A-Overheadfaktor

  = 0,10 × 21600 × 1,2

  = 2592

Exchange 2010 – Getestete Lösungen

Bestimmen des Speichertyps

Exchange 2010 umfasst Verbesserungen bei Leistung, Zuverlässigkeit und Hochverfügbarkeit, mit denen Organisationen Exchange auf einer Vielzahl von Speicheroptionen ausführen können.

Bei der Untersuchung der verfügbaren Speicheroptionen ist es für die Entwicklung einer erfolgreichen Speicherlösung für Exchange entscheidend, einen Kompromiss hinsichtlich der Anforderungen an Leistung, Kapazität, Verwaltbarkeit und Kosten zu finden.

Weitere Informationen zur Auswahl einer Speicherlösung für Exchange 2010 finden Sie unter Speicherentwurf für Postfachserver.

Exchange 2010 – Getestete Lösungen

Bestimmen, ob eine DAS- oder SAN-Speicherlösung bevorzugt wird

Für Exchange 2010 ist eine Vielzahl an Speicheroptionen verfügbar. Die Liste der Optionen kann reduziert werden, indem Sie bestimmen, ob die Bereitstellung einer DAS-Lösung (Direct-Attached Storage), einschließlich der Nutzung des lokalen Datenträgers, oder einer SAN-Lösung bevorzugt wird. Es gibt viele Gründe für die Auswahl der einen oder der anderen Lösung. Bestimmen Sie zusammen mit Ihrem bevorzugten Speicheranbieter die Lösung, die Ihre Unternehmensanforderungen und die Anforderungen an die Gesamtbetriebskosten (Total Cost of Ownership, TCO) erfüllt.

*Entwurfsentscheidungspunkt*

In diesem Beispiel wird eine SAN-Infrastruktur bereitgestellt, und SAN wird zum Speichern aller Daten in der Umgebung verwendet. Eine SAN-Speicherlösung wird weiterhin verwendet, und die Optionen für die Bereitstellung von Exchange 2010 werden untersucht.

Exchange 2010 – Getestete Lösungen

Auswählen der Speicherlösung

Verwenden Sie die folgenden Schritte, um eine Speicherlösung auszuwählen.

Schritt 1: Bestimmen des bevorzugten Speicheranbieters

In diesem Beispiel werden bereits seit vielen Jahren EMC-Speicher verwendet, und eine EMC-Speicherlösung wird für die Exchange 2010-Bereitstellung eingesetzt. Die EMC Corporation bietet leistungsstarke Speicherarrays wie CLARiiON und Symmetric.

Schritt 2: Prüfen der verfügbaren Optionen des bevorzugten Anbieters

Die EMC CLARiiON-Produktfamilie bietet mehrere Speicherebenen, wie Enterprise Flash-Laufwerke, Fibre Channel und Serial ATA (SATA). Dadurch werden die Kosten gesenkt, da mehrere Ebenen mit einer Verwaltungsschnittstelle verwaltet werden können.

CLARiiON Virtual Provisioning bietet Vorteile, die über die herkömmliche schlanke Speicherzuweisung hinausgehen. Dazu zählen vereinfachte Speicherverwaltung und verbesserte Kapazitätsnutzung. Sie können einem Host eine hohe Kapazität bereitstellen und dann nach Bedarf Speicherplatz aus einem freigegebenen Pool verbrauchen.

Die CLARiiON CX4-Serie bietet vier Modelle mit flexiblen Ebenen an Kapazität, Funktionalität und Leistung. Die Funktionen der einzelnen Modelle werden in der folgenden Tabelle beschrieben.

Funktionen der CLARiiON CX4-Serie

Funktion	CX4 Model 120	CX4 Model 240	CX4 Model 480	CX4 Model 960
Maximale Datenträger	120	240	480	960
Speicherprozessoren	2	2	2	2
Physischer Arbeitsspeicher pro Speicherprozessor	3 GB	4 GB	8 GB	16 GB
Maximaler Schreibcache	600 MB	1,264 GB	4,5 GB	10,764 GB
Maximale Initiatoren pro System	256	512	512	1024
Hosts mit hoher Verfügbarkeit	128	256	256	512
Minimale Formfaktorgröße	6U	6U	6U	9U
Maximale Standard-LUNs	1024	1024	4096	4096
SnapView-Momentaufnahmen	Ja	Ja	Ja	Ja
SnapView-Klone	Ja	Ja	Ja	Ja
SAN-Kopie	Ja	Ja	Ja	Ja
MirrorView/S	Ja	Ja	Ja	Ja
MirrorView/A	Ja	Ja	Ja	Ja
RecoverPoint/S	Ja	Ja	Ja	Ja
RecoverPoint/A	Ja	Ja	Ja	Ja

Schritt 3: Auswählen eines Datenträgertyps

In diesem Beispiel wurden Fibre Channel-Datenträger mit 450 GB und 15.000 RPM ausgewählt, die eine gute E/A-Leistung und Kapazität bieten, sodass die anfänglichen Anforderungen der Exchange-Benutzer erfüllt werden.

Schritt 4: Auswählen eines Arrays

In diesem Beispiel muss die Lösung 122 Terabyte nutzbaren Speicher und 2.592 IOPS bereitstellen. Alle Optionen in der obigen Tabelle bewältigen die IOPS-Anforderungen. Die Entscheidung hängt also von den Kapazitätsanforderungen ab. CLARiiON CX4 Model 240 bietet mit 450-GB-Datenträgern in einer RAID-5-Konfiguration nur etwa 100 Terabyte nutzbare Kapazität. EMC CLARiiON CX4 Model 480 wurde ausgewählt, da die erforderliche Kapazität und E/A-Leistung für alle Exchange 2010-Anforderungen damit erreicht werden.

Exchange 2010 – Getestete Lösungen

Schätzen der Arbeitsspeicheranforderungen für Postfächer

Die richtige Dimensionierung des Arbeitsspeichers ist ein wichtiger Schritt beim Entwurf einer fehlerfreien Exchange-Umgebung. Es wird empfohlen, die Themen Grundlegendes zu Speicherkonfigurationen und Exchange-Leistung und Grundlegendes zum Postfachdatenbankcache zu lesen.

Exchange 2010 – Getestete Lösungen

Berechnen des erforderlichen Datenbankcache

ESE (Extensible Storage Engine) verwendet Datenbankcache, um E/A-Vorgänge zu reduzieren. Allgemein gilt, je größer der verfügbare Datenbankcache, desto weniger E/A wird auf einem Exchange 2010-Postfachserver generiert. Ab einem bestimmten Punkt führt jedoch das Hinzufügen von zusätzlichem Datenbankcache nicht mehr zu einer beträchtlichen IOPS-Reduzierung. Daher kann die starke Vergrößerung des physischen Arbeitsspeichers auf Ihrem Exchange-Server, ohne die optimale Größe des erforderlichen Datenbankcache zu bestimmen, zu höheren Kosten bei minimalen Leistungsvorteilen führen.

Die IOPS-Schätzungen, die Sie in einem vorherigen Schritt vorgenommen haben, setzen eine Mindestgröße des Datenbankcache pro Postfach voraus. Diese Mindestgrößen sind unter Grundlegendes zum Postfachdatenbankcache in der Tabelle "Geschätzte IOPS pro Postfach basierend auf Nachrichtaktivität und Postfachdatenbankcache" zusammengefasst.

In der folgenden Tabelle ist der Datenbankcache pro Benutzer für verschiedene Nachrichtenprofile dargestellt.

Datenbankcache pro Benutzer

Pro Postfach und Tag gesendete oder empfangene Nachrichten (durchschnittliche Nachrichtengröße von etwa 75 KB)	Datenbankcache pro Benutzer (MB)
50	3 MB
100	6 MB
150	9 MB
200	12 MB

In diesem Schritt bestimmen Sie die allgemeinen Arbeitsspeicheranforderungen für die gesamte Umgebung. In einem späteren Schritt verwenden Sie dieses Ergebnis, um die erforderliche Größe des physischen Arbeitsspeichers für jeden Postfachserver zu ermitteln. Verwenden Sie die folgende Berechnung:

• Datenbankcache = profilspezifischer Datenbankcache × Anzahl der Postfachbenutzer

  = 6 MB × 32400

  = 194400 MB

  = 190 GB

Exchange 2010 – Getestete Lösungen

Schätzen der CPU-Anforderungen für Postfächer

Die Kapazitätsplanung für den Postfachserver hat sich im Vergleich zu früheren Exchange-Versionen beträchtlich verändert. Die Ursache ist das neue Modell für die Ausfallsicherheit von Postfachdatenbanken in Exchange 2010. Weitere Informationen finden Sie unter Kapazitätsplanung für den Postfachserverprozessor.

In den folgenden Schritten berechnen Sie die allgemeinen Megazyklusanforderungen für aktive und passive Datenbankkopien. Diese Anforderungen werden in einem späteren Schritt verwendet, um die erforderliche Anzahl von Postfachservern für die Arbeitslast zu bestimmen. Beachten Sie, dass die erforderliche Anzahl von Postfachserver auch vom Modell für die Ausfallsicherheit von Postfachservern und dem Layout für Datenbankkopien abhängt.

Die Verwendung der Megazyklusanforderungen für die Bestimmung der Anzahl von Postfachbenutzern, die ein Exchange-Postfachserver unterstützen kann, führt zu keinem genauen Resultat. Eine Reihe von Faktoren kann unerwartete Megazyklusergebnisse in Test- und Produktionsumgebungen ergeben. Megazyklen sollten nur verwendet werden, um die ungefähre Anzahl der Postfachbenutzer zu bestimmen, die ein Exchange-Postfachserver unterstützen kann. Bei der Kapazitätsplanung während des Entwurfs ist es immer besser, konservativ statt aggressiv zu schätzen.

Die folgenden Berechnungen basieren auf veröffentlichten Megazyklusschätzungen, wie in der folgenden Tabelle angegeben.

Megazyklusschätzungen

Täglich pro Postfach gesendete oder empfangene Nachrichten	Megazyklen pro Postfach für aktive Postfachdatenbanken	Megazyklen pro Postfach für passive Postfachdatenbanken (remote)	Megazyklen pro Postfach für passive Postfächer (lokal)
50	1	0,1	0,15
100	2	0,2	0,3
150	3	0,3	0,45
200	4	0,4	0,6

Schritt 1: Berechnen der CPU-Anforderungen für aktive Postfächer

In diesem Schritt berechnen Sie mit den folgenden Angaben die Megazyklen, die zur Unterstützung aller aktiven Datenbankkopien erforderlich sind:

• Erforderliche Megazyklen für aktive Postfächer = profilspezifische Megazyklen × Anzahl der Postfachbenutzer

  = 2 × 32400

  = 64800

Schritt 2: Berechnen der CPU-Anforderungen für die Remotedatenbankkopie der aktiven Postfächer

In einem Entwurf mit drei Kopien jeder Datenbank ist mit der Übertragung der Protokolle, die für die Verwaltung der Datenbankkopien auf den Remoteservern erforderlich sind, ein Prozessoroverhead verbunden. Dieser Overhead beträgt üblicherweise 10 Prozent der Megazyklen für aktive Postfächer für jede verwaltete Remotekopie. Berechnen Sie die Anforderungen mit folgenden Angaben:

• Erforderliche Megazyklen für die Remotekopie = profilspezifische Megazyklen × Anzahl der Postfachbenutzer × Anzahl der Remotekopien

  = 0,1 × 32400 × 2

  = 6480

Schritt 3: Berechnen der CPU-Anforderungen für lokale passive Postfächer

In einem Entwurf mit drei Kopien jeder Datenbank ist mit der Verwaltung der lokalen passiven Kopien jeder Datenbank ein Prozessoroverhead verbunden. In diesem Schritt werden die allgemeinen Megazyklen berechnet, die zur Unterstützung lokaler passiver Datenbankkopien erforderlich sind. Diese Zahlen werden in einem späteren Schritt verfeinert, sodass sie zur Strategie für die Ausfallsicherheit von Servern und zum Layout der Datenbankkopien passen. Berechnen Sie die Anforderungen mit folgenden Angaben:

• Erforderliche Megazyklen für lokale passive Postfächer = profilspezifische Megazyklen × Anzahl der Postfachbenutzer × Anzahl der passiven Kopien

  = 0,3 × 32400 × 2

  = 19440

Schritt 4: Berechnen der gesamten CPU-Anforderungen

Berechnen Sie die Anforderungen mit folgenden Angaben:

• Insgesamt erforderliche Megazyklen = aktives Postfach + remote passiv + lokal passiv

  = 64800 + 6480 + 19440

  = 90720

  Durchschnittliche Megazyklen pro Postfach = 90720 ÷ 32400 = 2,8

Exchange 2010 – Getestete Lösungen

Zusammenfassen der Postfachanforderungen

In der folgenden Tabelle werden die ungefähren Werte für Megazyklen und den Datenbankcache zusammengefasst, die für diese Umgebung erforderlich sind. Diese Informationen werden in späteren Schritten verwendet, um die in der Lösung bereitgestellten Server zu bestimmen.

Zusammenfassung der Postfachanforderungen

CPU-Anforderungen für Postfächer	Wert
Insgesamt erforderliche Megazyklen für die gesamte Umgebung	97200
Insgesamt erforderlicher Datenbankcache für die gesamte Umgebung	190 GB

Exchange 2010 – Getestete Lösungen

Bestimmen des Servermodells

Mit den folgenden Schritten können Sie das Servermodell bestimmen.

Schritt 1: Bestimmen des bevorzugten Anbieters

In dieser Lösung ist die bevorzugte Serverplattform Cisco Unified Computing System, eine Datencenterplattform, die Computer, Netzwerke, Speicherzugriff und Virtualisierung in einem System vereint, das für TCO-Reduzierung und Flexibilitätssteigerungen konzipiert ist. Das System integriert eine einheitliche 10-Gigabit-Ethernet-Netzwerkstruktur mit geringer Wartezeit in Server mit x86-Architektur, die für Unternehmen konzipiert sind. Mit einem Systemzugang zu Architektur, Technologie, Partnerschaften und Diensten optimiert Cisco Unified Computing System Datencenterressourcen, skaliert die Dienstbereitstellung und reduziert die Anzahl der Geräte, die eingerichtet, verwaltet, betrieben, gekühlt und verkabelt werden müssen.

Schritt 2: Prüfen der verfügbaren Optionen des bevorzugten Anbieters

Cisco Unified Computing System ist ein Bladeserversystem, das aus vier primären Systemkomponenten besteht. Diese Systemkomponenten sind der Fabric Interconnect, das Gehäuse, Fabric-Erweiterungen (E/A-Module) und Bladeserver.

Die folgenden Bladeservermodelle sind mögliche Optionen für diese Lösung.

Option 1: B200 Blade Server

Cisco Unified Computing System B200 Blade Server ist ein Bladeserver halber Breite mit zwei Sockets. Das System nutzt zwei Prozessoren der Serien Intel Xeon 5500 oder 5600, bis zu 96 GB DDR3-Arbeitsspeicher, zwei optionale Hot-Swap-fähige SAS-Datenträgerlaufwerke mit geringem Formfaktor und einen Mezzanine-Anschluss für bis zu 20 Gigabit pro Sekunde (GBit/s) E/A-Durchsatz. Der Server schafft einen Ausgleich zwischen Einfachheit, Leistung und Dichte für eine Virtualisierung auf Produktionsebene und andere allgemeine Arbeitslasten im Datencenter.

Option 2: B250 Blade Server

Cisco Unified Computing System B250 Extended Memory Blade Server ist ein Bladeserver voller Breite mit zwei Sockets und der Cisco-Technologie für erweiterten Arbeitsspeicher. Das System unterstützt zwei Prozessoren der Serien Intel Xeon 5500 oder 5600, bis zu 384 GB DDR3-Arbeitsspeicher, zwei optionale SAS-Datenträgerlaufwerke mit geringem Formfaktor und zwei Mezzanine-Anschlüsse für bis zu 40 GBit/s E/A-Durchsatz. Der Server erhöht die Leistung und die Kapazität für die Virtualisierung und große Datasetarbeitslasten.

Option 3: B440 Blade Server

Cisco Unified Computing System B440 Blade Server ist für den Betrieb von Unternehmensanwendungen wie Datenbanken mit großen Datasets oder vielen Transaktionen, ERP-Programme (Enterprise Resource Planning) und Entscheidungsunterstützungssysteme vorgesehen. Gestützt durch die skalierbare Leistung und Zuverlässigkeit von Prozessoren der Serie Intel Xeon 7500 können mit Cisco Unified Computing System B440 in einer integrierten, vereinfachten Infrastruktur der Umfang der Arbeitslastvirtualisierung ausgebaut und leistungsintensive eigenständige Anwendungen vereinheitlicht werden. Cisco Unified Computing System B440 unterstützt bis zu 32 Prozessorkerne und 256 GB Hauptarbeitsspeicher kombiniert mit einem E/A-Durchsatz von bis zu 40 GBit/s.

Schritt 3: Auswählen eines Servermodells

Cisco Unified Computing System B200 mit Intel Xeon X5570-Prozessoren wurde ausgewählt, weil dieser Bladeserver den optimalen Kompromiss zwischen Prozessorleistung, Arbeitsspeicherkapazität und Formfaktor für diese Bereitstellung bildet. Eine Serverplattform mit zwei Sockets ist unter Berücksichtigung aller relevanten Faktoren, einschließlich Skalierbarkeit und Kosten, häufig eine gute Wahl für Exchange 2010-Bereitstellungen. Cisco Unified Computing System B250 unterstützt eine Konfiguration mit mehr Arbeitsspeicher und einen höheren E/A-Durchsatz, für die Lösung ist dies aber nicht erforderlich.

Exchange 2010 – Getestete Lösungen

Berechnen der CPU-Kapazität des Servermodells

In vorherigen Schritten haben Sie die Megazyklen berechnet, die zur Unterstützung der Anzahl aktiver Postfachbenutzer erforderlich sind. In den folgenden Schritten bestimmen Sie, wie viele verfügbare Megazyklen das Servermodell und der Prozessor unterstützen können, um die Anzahl aktiver Postfächer für jeden Server zu ermitteln.

Schritt 1: Bestimmen des Benchmarkwerts für den Server und den Prozessor

Da die Megazyklusanforderungen auf einem Baselinemodell für Server und Prozessor basieren, müssen Sie die verfügbaren Megazyklen für den Server im Vergleich zur Baseline anpassen. Dazu werden unabhängige Leistungsbenchmarks verwendet, die von der Standard Performance Evaluation Corporation (SPEC) gepflegt werden. SPEC ist ein gemeinnütziges Unternehmen, das gegründet wurde, um einen standardisierten Satz relevanter Benchmarks zu erarbeiten, zu pflegen und zu unterstützen, die auf die neueste Generation von Hochleistungscomputern angewendet werden können.

Verwenden Sie das Abfragetool für Exchange-Prozessoren (möglicherweise in englischer Sprache), um das Abrufen der Benchmarkwerte für Ihren Server und Prozessor zu vereinfachen. Mit diesem Tool werden manuelle Schritte automatisiert, um den Wert für die SPECint 2006-Bewertung des geplanten Prozessors zu ermitteln. Um dieses Tool auszuführen, muss Ihr Computer mit dem Internet verbunden sein. Das Tool verwendet das geplante Prozessormodell als Eingabe und führt dann eine Abfrage auf der Standard Performance Evaluation Corporation-Website durch, die alle Testergebnisdaten für dieses bestimmte Prozessormodell zurückgibt. Das Tool berechnet auch einen Durchschnittswert der SPECint 2006-Bewertung, die auf der Anzahl der Prozessoren basiert, die in den einzelnen Postfachservern eingesetzt werden sollen. Verwenden Sie die folgende Berechnung:

• Prozessor = Intel X5570 mit 2,93 Gigahertz (GHz)

• SPECint_rate2006-Wert = 256

• SPECint_rate2006-Wert pro Prozessorkern = 256 ÷ 8

  = 32

Schritt 2: Berechnen der angepassten Megazyklen

In vorherigen Schritten haben Sie die erforderlichen Megazyklen für die gesamte Umgebung berechnet. Diese Berechnung basierte auf Schätzungen der Megazyklen pro Postfach. Diese Schätzungen wurden auf einem Baselinesystem (HP DL380 G5 x5470 mit 3,33 GHz, 8 Kerne) gemessen, das einen SPECint_rate2006-Wert von 150 (für einen Server mit 8 Kernen) oder 18,75 pro Kern aufweist.

In diesem Schritt müssen Sie die verfügbaren Megazyklen für den ausgewählten Server und Prozessor im Vergleich zum Baselineprozessor anpassen, sodass die erforderlichen Megazyklen für die Kapazitätsplanung herangezogen werden können.

Verwenden Sie die folgenden Formeln, um die Megazyklen der Plattform Cisco B200-M1 mit Intel X5570 und 2,93 GHz zu bestimmen:

• Angepasste Megazyklen pro Kern = (Wert pro Kern der neuen Plattform) × (Hertz pro Kern der Baselineplattform) ÷ (Baselinewert pro Kern)

  = (32 × 3330) ÷ 18,75

  = 5683

• Angepasste Megazyklen pro Server = angepasste Megazyklen pro Kern × Anzahl der Kerne

  = 5683 × 8

  = 45466

Schritt 3: Berechnen der verfügbaren Megazyklen pro Postfachserver

Da jetzt die angepassten Megazyklen pro Server bekannt sind, müssen Sie eine Anpassung für die geplante maximale Prozessorauslastung vornehmen. In einem vorherigen Abschnitt wurde entschieden, dass eine Prozessorauslastung von 80 Prozent bei Spitzenlasten oder in Ausfallszenarien nicht überschritten werden soll. Verwenden Sie die folgende Berechnung:

• Angepasste verfügbare Megazyklen = verfügbare Megazyklen pro Server × geplante maximale Prozessorauslastung

  = 45466 × 0,80

  = 36372

Jeder Server verfügt über eine nutzbare Kapazität der 36.372 Megazyklen.

Exchange 2010 – Getestete Lösungen

Bestimmen der erforderlichen Anzahl physischer Postfachserver

Mit den folgenden Schritten können Sie die erforderliche Anzahl physischer Postfachserver bestimmen.

Schritt 1: Bestimmen der maximalen Anzahl aktiver Postfächer, die von einem Postfachserver unterstützt werden

Verwenden Sie die folgende Berechnung, um die Anzahl aktiver Postfächer zu bestimmen, die von einem Postfachserver unterstützt werden:

• Anzahl aktiver Postfächer = verfügbare Megazyklen pro Server ÷ Megazyklen pro Postfach

  = 36372 ÷ 2,8

  = 12990

Schritt 2: Bestimmen der Mindestanzahl der pro Standort erforderlichen Postfachserver, um die erforderliche Arbeitslast jeder DAG zu unterstützen

Jede DAG weist 10.800 aktive Postfächer auf. Verwenden Sie die folgende Berechnung, um die erforderliche Mindestanzahl von Postfachservern zu bestimmen, um alle Postfächer in einer DAG zu unterstützen:

• Anzahl erforderlicher Server = Gesamtanzahl von Postfächern pro DAG ÷ aktive Postfächer pro Server

  = 10800 ÷ 12990

  = 0,83

Mindestens ein Postfachserver ist für jede DAG erforderlich, um die Arbeitslast von 10.800 Postfächern zu unterstützen.

Schritt 3: Bestimmen der erforderlichen Serveranzahl, um die Strategie für die Ausfallsicherheit von Postfächern für jede DAG zu unterstützen

In einem vorherigen Schritt wurde bestimmt, dass im Entwurf vorgesehen sein soll, alle Kopien in einer Aktiv/Passiv-DAG zu aktivieren. Diese Modell erfordert, dass die Postfachserverrollen für jede DAG in Gruppen zu je drei bereitgestellt werden müssen.

Anzahl der Postfachserver und DAGs

DAG1 – Primäres Datencenter	DAG1 – Sekundäres Datencenter	DAG2 – Primäres Datencenter	DAG2 – Sekundäres Datencenter	DAG3 – Primäres Datencenter	DAG3 – Sekundäres Datencenter	Gesamtanzahl der Postfachserver
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

Basierend auf dem DAG-Entwurf sind mindestens drei physische Postfachserver in jeder DAG oder insgesamt neun physische Postfachserver für alle drei DAGs erforderlich.

Exchange 2010 – Getestete Lösungen

Bestimmen der Anzahl aktiver Postfächer pro Postfachserver in Szenarien mit normalen Betrieb und Ausfällen

Sie können die folgenden Schritte verwenden, um die Anzahl aktiver Postfächer pro Postfachserver in Szenarien mit normalem Betrieb und Ausfällen zu bestimmen.

Schritt 1: Bestimmen der Anzahl aktiver Postfächer pro Postfachserver während des normalen Betriebs

Verwenden Sie die folgende Berechnung, um die Anzahl aktiver Postfächer zu bestimmen, die von jedem Postfachserver während des normalen Betriebs gehostet werden:

• Anzahl der Postfächer pro Server = Gesamtanzahl von Postfächern in der DAG ÷ Anzahl von Postfachservern im primären Datencenter

  = 10800 ÷ 2

  = 5400

Schritt 2: Bestimmen der Anzahl aktiver Postfächer pro Postfachserver während des Ausfalls eines Postfachservers im primären Datencenter

Falls ein Postfachserver im primären Datencenter ausfällt, werden die 5.400 aktiven Postfächer auf dem ausgefallenen Server auf den übrigen Servern aktiviert. In diesem Szenario weisen die übrigen Postfachserver 10.800 aktive Postfächer auf.

Schritt 3: Bestimmen der Anzahl aktiver Postfächer pro Postfachserver während des Ausfalls von beiden Postfachservern im primären Datencenter

Falls das primäre Datencenter offline geschaltet wird, werden die 10.800 aktiven Postfächer im primären Datencenter im sekundären Datencenter aktiviert. In diesem Szenario weist der Server im sekundären Datencenter 10.800 aktive Postfächer auf.

Exchange 2010 – Getestete Lösungen

Bestimmen, ob die Clientzugriffs- und Hub-Transport-Serverrollen auf separaten physischen Servern bereitgestellt werden

Wenn Sie die Anzahl der Clientzugriffs-Serverrollen und Hub-Transport-Serverrollen bestimmen, die in Umgebungen mit einer geringen Anzahl von Servern bereitgestellt werden müssen, könnten Sie in Betracht ziehen, beide Rollen auf demselben physischen Computer bereitzustellen. Dadurch werden die Anzahl physischer Computer, die verwaltet werden müssen, die Anzahl von Serverbetriebssystemen, die aktualisiert und gewartet werden müssen, und die Anzahl von Windows- und Exchange-Lizenzen, die gekauft werden müssen, reduziert. Der andere Vorteil der Kombination von Clientzugriffs- und Hub-Transport-Serverrollen ist die Vereinfachung des Entwurfs. Bei der isolierten Bereitstellung der Rollen empfiehlt es sich, einen logischen Hub-Transport-Serverprozessor für alle vier logischen Postfachserverprozessoren und drei logische Clientzugriffs-Serverprozessoren für alle vier logischen Postfachserverprozessoren bereitzustellen. Dies kann verwirrend werden, insbesondere, wenn Sie berücksichtigen, dass Sie bei Ausfällen mehrerer physischer Server oder in Wartungsszenarien ausreichend Clientzugriffs- und Hub-Transport-Server bereitstellen müssen. Wenn Sie Clientzugriffs- und Hub-Transport-Server zusammen mit Postfachservern auf den gleichen physischen Servern oder VMs bereitstellen, können Sie für jeden Postfachserver am Standort eine Kombination aus Clientzugriffs- und Hub-Transport-Server bereitstellen.

*Entwurfsentscheidungspunkt*

Für diese Lösung wurde entschieden, die Hub-Transport- und Clientzugriffs-Serverrollen zusammen auf dem gleichen physischen Computer zu installieren. Dadurch wird die Anzahl der zu verwaltenden Betriebssysteme reduziert, und die Ausfallsicherheit von Servern kann leichter geplant werden.

Exchange 2010 – Getestete Lösungen

Bestimmen der erforderlichen Anzahl physischer Clientzugriffs- und Hub-Transport-Kombinationsserver

In einem vorherigen Schritt haben Sie bestimmt, dass an jedem Standort drei Postfachserver erforderlich sind (zwei Postfachserver der DAG zum Hosten der aktiven Postfächer für den Standort und ein Postfachserver einer anderen DAG zur Unterstützung der Ausfallsicherheit von Standorten, falls das primäre Datencenter für diese DAG ausfällt).

Es wird empfohlen, eine Kombination aus Clientzugriffs- und Hub-Transport-Server für jeden Postfachserver bereitzustellen, wie in der folgenden Tabelle veranschaulicht.

Erforderliche Anzahl physischer Clientzugriffs- und Hub-Transport-Kombinationsserver

Serverrollenkonfiguration	Empfohlenes Prozessorkernverhältnis
Postfachserverrolle zu kombinierter Konfiguration von Clientzugriffs- und Hub-Transport-Serverrolle	1:1

Wenn an einem Standort mehr als eine DAG vorhanden ist, müssen Sie das schlimmste Ausfallszenario untersuchen, bevor Sie die erforderliche Anzahl von Clientzugriffs- und Hub-Transport-Kombinationsservern bestimmen können. In dieser Lösung wäre das schlimmste Ausfallszenario der Ausfall einer der beiden Postfachserver in der primären DAG und ein gleichzeitiger Standortausfall, sodass aktive Postfächer eines anderen Standorts jetzt am gleichen Standort gehostet werden. In diesem Fall befinden sich 21.600 aktive Postfächer am Standort, die auf zwei Postfachservern ausgeführt werden. Daher benötigen Sie an jedem Standort mindestens zwei Clientzugriffs- und Hub-Transport-Kombinationsserver, wie in der folgenden Abbildung veranschaulicht.

Clientzugriffs- und Hub-Transport-Server

Exchange 2010 – Getestete Lösungen

Bestimmen der erforderlichen Gesamtanzahl physischer Server

Bislang haben Sie bestimmt, dass 15 physische Server erforderlich sind, um die Clientzugriffs-, Hub-Transport- und Postfachserverrollen für 32.400 aktive Postfächer in drei Datencentern zu unterstützen, wie in der folgenden Abbildung veranschaulicht.

Erforderliche Anzahl von physischen Servern

Exchange 2010 – Getestete Lösungen

Bestimmen, ob Servervirtualisierung verwendet wird

Mehrere Faktoren sind wichtig, wenn Servervirtualisierung für Exchange in Betracht gezogen wird. Weitere Informationen zu unterstützten Konfigurationen für die Virtualisierung finden Sie unter Exchange 2010 – Systemanforderungen.

Ziehen Sie eine Nutzung der Virtualisierung mit Exchange aus den folgenden Gründen in Betracht:

• Wenn Sie erwarten, dass die Serverkapazität nicht ausgenutzt wird, und Sie eine bessere Auslastung erreichen möchten, können Sie als Ergebnis der Virtualisierung weniger Server kaufen.

• Sie können den Windows-Netzwerklastenausgleich (Network Load Balancing, NLB) bei der Bereitstellung der Clientzugriffs-, Hub-Transport- und Postfachserverrollen auf dem gleichen physischen Server verwenden.

• Wenn in Ihrer Organisation die Virtualisierung in der gesamten Serverinfrastruktur verwendet wird, können Sie die Virtualisierung mit Exchange nutzen, um Standardrichtlinien des Unternehmens einzuhalten.

Um zu bestimmen, ob Virtualisierung in dieser Umgebung eingesetzt werden soll, betrachten Sie die erwartete Prozessorauslastung, und bestimmen Sie, ob die Server wahrscheinlich nicht ausgelastet werden.

Schritt 1: Bestimmen der erwarteten CPU-Auslastung des Postfachservers während normaler Betriebsbedingungen

Verwenden Sie die folgende Berechnung, um die CPU-Auslastung von 5.400 aktiven Postfächern auf einem Postfachserver zu bestimmen:

• Prozentsatz Prozessorauslastung (normale Spitzenlast) = erforderliche Megazyklen ÷ verfügbare Megazyklen

  = (5400 × 2.8) ÷ 45466

  = 33,2 %

Schritt 2: Berechnen der erwarteten CPU-Auslastung des Postfachservers während der schlimmsten Ausfallbedingungen

Verwenden Sie die folgende Berechnung, um die CPU-Auslastung von 10.800 aktiven Postfächern auf einem Postfachserver zu bestimmen:

• Prozentsatz Prozessorauslastung (schlimmste Ausfallbedingungen) = erforderliche Megazyklen ÷ verfügbare Megazyklen

  = (10800 × 2.8) ÷ 45466

  = 66,5 %

*Entwurfsentscheidungspunkt*

Da das Ziel für den Server ist, unterhalb der geplanten Auslastung von 80 Prozent im schlimmsten Ausfallszenario zu bleiben, kann dies eine Gelegenheit sein, die Serveranzahl durch Virtualisierung zu reduzieren. Dies wird in den folgenden Schritten weiter untersucht.

Exchange 2010 – Getestete Lösungen

Bestimmen, ob durch Virtualisierung die Anzahl physischer Server reduziert werden kann

In den folgenden Schritten bestimmen Sie, ob in dieser Lösung die erforderliche Anzahl physischer Server durch Virtualisierung reduziert werden kann. Microsoft Hyper-V wird als Virtualisierungsplattform verwendet.

Schritt 1: Hinzufügen von Virtualisierung zur vorhandenen Anzahl physischer Server

Zum Zeitpunkt des Tests hat Microsoft Hyper-V maximal vier virtuelle Prozessoren pro VM unterstützt. Im physischen Entwurf wurde die Postfachserverrolle für die primäre DAG auf zwei physischen Servern mit insgesamt 16 logischen Prozessoren bereitgestellt. Durch Hinzufügen von Virtualisierung wird die Postfachserverrolle für die primäre DAG jetzt auf vier VMs bereitgestellt, die jeweils vier virtuelle Prozessoren für eine Gesamtanzahl von 16 virtuellen Prozessoren aufweisen.

Im physischen Entwurf wurde die Postfachserverrolle für die alternative DAG auf einem physischen Servern mit acht logischen Prozessoren bereitgestellt. Durch Hinzufügen von Virtualisierung wird die Postfachserverrolle für die alternative DAG jetzt auf zwei VMs bereitgestellt, die jeweils vier virtuelle Prozessoren für eine Gesamtanzahl von acht virtuellen Prozessoren aufweisen.

Im physischen Entwurf wurde der Clientzugriffs- und Hub-Transport-Kombinationsserver auf zwei physischen Servern mit insgesamt 16 logischen Prozessoren bereitgestellt. Durch Hinzufügen von Virtualisierung werden die Clientzugriffs- und Hub-Transport-Kombinationsserver jetzt auf vier VMs bereitgestellt, die jeweils vier virtuelle Prozessoren für eine Gesamtanzahl von 16 virtuellen Prozessoren aufweisen.

Wenn Hyper-V-Stammserver mit acht logischen Prozessoren verwendet werden, empfiehlt es sich, eine VM für Postfachserver und eine VM für Clientzugriffs- und Hub-Transport-Kombinationsserver auf jedem Hyper-V-Stammserver bereitzustellen.

Die Lösung weist jetzt 10 VMs auf, die auf fünf physischen Servern an jedem Standort ausgeführt werden, wie in der folgenden Abbildung veranschaulicht.

Virtuelle Computer

Schritt 2: Reduzieren der Anzahl physischer Server

Basierend auf den Berechnungen in einem vorherigen Schritt erwarten Sie, dass die Megazyklusanforderungen für die Arbeitslast im schlimmsten Fall von vier physischen Servern verarbeitet werden kann. In diesem Schritt reduzieren Sie die Anzahl physischer Server von fünf auf vier und verteilen die Postfachserver in der alternativen DAG auf die übrigen vier physischen Server. Um die Symmetrie der vier physischen Server beizubehalten, müssen Sie die zwei Postfachserver-VMs (mit vier virtuellen Prozessoren) in vier Postfachserver-VMs (mit zwei virtuellen Prozessoren) ändern.

Dies ergibt 12 VMs, die auf vier physischen Servern an jedem Standort ausgeführt werden, wie in den folgenden Abbildungen veranschaulicht.

Virtuelle Computer

Virtuelle Computer

Schritt 3: Bestimmen der Anzahl virtueller Prozessoren, die jeder VM zugewiesen sind

In diesem Schritt schätzen Sie die Anzahl virtueller Prozessoren, die für jede VM erforderlich sind. In den folgenden Schritten führen Sie Berechnungen durch, um die getroffenen Annahmen zu überprüfen.

Jede der vier Postfachserver-VMs in der primären DAG unterstützt unter normalen Betriebsbedingungen 25 Prozent der 10.800 aktiven Postfächer in der DAG, oder jeweils 2.700 Postfächer. Bei einem Serverausfall muss die noch funktionierende Postfachserver-VM 5.400 aktive Postfächer unterstützen.

Bei einem Standortausfall unterstützt jede der vier Postfachserver-VMs in der primären DAG 25 Prozent der 10.800 aktiven Postfächer in der DAG, oder jeweils 2.700 Postfächer. In diesen Szenario werden die Postfächer mit der dritten und endgültigen Kopie der Datenbank ausgeführt. Bei einem Server- oder VM-Ausfall muss die noch funktionierende VM keine 5.400 aktiven Postfächer unterstützen. Die maximale Anzahl von Postfächern ist immer 2.700.

Es ist sinnvoll, dass die VMs in der alternativen DAG halb so viele virtuelle Prozessoren wie die VMs in der primären DAG aufweisen. Weisen Sie in dieser Lösung vier virtuelle Prozessoren den VMs in der primären DAG und zwei virtuelle Prozessoren den VMs in der alternativen DAG zu.

Wenn Sie ein Verhältnis von 1:1 für die logischen und virtuellen Prozessoren beibehalten, verbleiben zwei virtuelle Prozessoren für jeden Clientzugriffs- und Hub-Transport-Kombinationsserver. Da Sie ein Verhältnis von 1:1 für Postfachserverkerne und Clientzugriffs- und Hub-Transport-Kombinationsserverkerne beibehalten, weisen Sie jedem Clientzugriffs- und Hub-Transport-Kombinationsserver vier virtuelle Prozessoren zu. Dies ergibt ein Szenario, in dem die Anzahl der virtuellen Prozessoren die Anzahl der physischen Prozessoren auf dem Stammserver übersteigt. Dies wird als Überzeichnung bezeichnet. In den meisten Fällen wird empfohlen, dass Sie eine Überzeichnung vermeiden. In dieser Lösung werden die Postfachserver-VMs in der alternativen DAG jedoch nur bei einem Standortausfall verwendet. Da dies selten vorkommt, ist eine leichte Überzeichnung vertretbar.

Die folgende Tabelle zeigt die vorgeschlagenen Zuweisungen virtueller Prozessoren.

Zuweisung virtueller Prozessoren

Virtueller Computer	Anzahl virtueller Prozessoren
Clientzugriffs- und Hub-Transport-Kombination	3
Postfach (primäre DAG)	4
Postfach (alternative DAG)	2
Gesamt	9

Exchange 2010 – Getestete Lösungen

Berechnen der CPU-Kapazität des Hyper-V-Stammservers

In vorherigen Schritten haben Sie die Megazyklen berechnet, die zur Unterstützung der Anzahl aktiver Postfachbenutzer erforderlich sind. In den folgenden Schritten bestimmen Sie, wie viele verfügbare Megazyklen das Servermodell und der Prozessor unterstützen können, um die Anzahl aktiver Postfächer zu ermitteln, die jeder virtuelle Server unterstützen kann.

Exchange 2010 – Getestete Lösungen

Anpassen der verfügbaren Megazyklen für den Virtualisierungsoverhead

Beim Bereitstellen von VMs auf dem Stammserver müssen Sie die Megazyklen berücksichtigen, die für den Hypervisor und den Virtualisierungsstapel erforderlich sind. Dieser Overhead variiert von Server zu Server und je nach Arbeitslast. Eine konservative Schätzung von 10 Prozent der verfügbaren Megazyklen wird verwendet, wie in der folgenden Berechnung veranschaulicht:

• Angepasste verfügbare Megazyklen = verfügbare Megazyklen × 0,90

  = 45466 × 0,90

  = 40919

Jeder Server verfügt über eine nutzbare Kapazität für VMs von 40.919 Megazyklen.

Die nutzbare Kapazität pro logischem Prozessor beträgt 5.115 Megazyklen.

Exchange 2010 – Getestete Lösungen

Bestimmen der CPU-Kapazität der VMs

In einem vorherigen Schritt haben Sie die Zuweisung virtueller Prozessoren für die drei VM-Typen bestimmt, wie in der folgenden Tabelle gezeigt.

Zuweisung virtueller Prozessoren

Virtueller Computer	Anzahl virtueller Prozessoren
Clientzugriffs- und Hub-Transport-Kombination	3
Postfach (primäre DAG)	4
Postfach (alternative DAG)	2
Gesamt	9

Schritt 1: Ermitteln der verfügbaren Megazyklen pro virtuellem Prozessor

Da auf einem Stammserver mit acht logischen Prozessoren neun virtuelle Prozessoren ausgeführt werden, ist die Megazykluskapazität eines virtuellen Prozessors nicht gleich der Megazykluskapazität eines logischen Prozessors. In diesem Schritt berechnen Sie die verfügbaren Megazyklen pro virtuellem Prozessor:

• Megazyklen pro virtuellem Prozessor = Megazyklen pro logischem Prozessor × (Anzahl logischer Prozessoren ÷ Anzahl virtueller Prozessoren)

  = 5115 × (8 ÷ 9)

  = 4547

Schritt 2: Bestimmen der verfügbaren Megazyklen pro VM

Verwenden Sie in diesem Schritt die folgende Tabelle, um die verfügbaren Megazyklen pro VM zu bestimmen.

Verfügbare Megazyklen pro VM

Virtueller Computer	Anzahl virtueller Prozessoren	Megazyklen pro virtuellem Prozessor	Verfügbare Megazyklen
Clientzugriffs- und Hub-Transport-Kombination	3	4547	13641
Postfach (primäre DAG)	4	4547	18188
Postfach (alternative DAG)	2	4547	9094

Schritt 3: Bestimmen der geplanten verfügbaren Megazyklen pro VM

Da in den Entwurfsannahmen festgelegt ist, dass 80 Prozent der Prozessorauslastung nicht überschritten werden soll, passen Sie die verfügbaren Megazyklen an, sodass das Ziel von 80 Prozent widergespiegelt wird, wie in der folgenden Tabelle gezeigt.

Geplante verfügbare Megazyklen pro VM

Virtueller Computer	Verfügbare Megazyklen	Maximale Prozessorauslastung	Geplante verfügbare Megazyklen
Clientzugriffs- und Hub-Transport-Kombination	13641	80 %	10913
Postfach (primäre DAG)	18188	80 %	14550
Postfach (alternative DAG)	9094	80 %	7275

Exchange 2010 – Getestete Lösungen

Überprüfen der CPU-Kapazität der primären Postfachserver-VMs

Führen Sie die folgenden Schritte aus, um die CPU-Kapazität der primären Postfachserver-VMs zu überprüfen.

Schritt 1: Bestimmen der Megazyklusanforderungen für die Arbeitslast im schlimmsten Fall

Der schlimmste Fall hinsichtlich der Arbeitslast auf dem primären Postfachserver besteht während eines Serverausfalls oder einer Wartung, wenn 5.400 Postfächer auf dem primären Postfachserver aktiv sind und die zweiten und dritten Remotekopien gewartet werden (beispielsweise nach einer Wiederherstellung, wenn die passiven Kopien aktualisiert werden, aber die aktiven Postfächer noch nicht wieder auf den Zielserver verschoben wurden). In diesem Schritt bestimmen Sie mit der folgenden Berechnung die Megazyklusanforderungen für die primäre Postfachserver-VM:

• Erforderliche Postfachmegazyklen = (Anzahl der Postfachbenutzer × profilspezifische Megazyklen) + Anzahl der Remotedatenbankkopien × (Anzahl der Postfachbenutzer × profilspezifische Megazyklen × 10 %)

  = (5400 × 2) + 2 × (5400 × 2 × 0,1)

  = 10800 + 2160

  = 12960

Schritt 2: Bestimmen, ob Postfachserver-VMs die Arbeitslast im schlimmsten Fall unterstützen können

In diesem Schritt bestimmen Sie, ob die Anzahl der verfügbaren Megazyklen größer ist als die Anzahl der erforderlichen Megazyklen. Es sind 12.960 Megazyklen erforderlich, Sie verfügen über 14.550 Megazyklen. Die primäre Postfachserver-VM hat also ausreichend Kapazität, um 5.400 aktive Postfächer zu unterstützen.

Exchange 2010 – Getestete Lösungen

Überprüfen der CPU-Kapazität der sekundären Postfachserver-VMs

Führen Sie die folgenden Schritte aus, um die CPU-Kapazität der sekundären Postfachserver-VMs zu überprüfen.

Schritt 1: Bestimmen der Megazyklusanforderungen für die Arbeitslast im schlimmsten Fall

Der schlimmste Fall hinsichtlich Arbeitslast auf dem sekundären Postfachserver besteht während eines Standortausfalls, wenn 2.700 Postfächer auf dem sekundären Postfachserver aktiv sind und die zweiten und dritten Remotekopien gewartet werden (beispielsweise nachdem der ursprüngliche Standort wieder online geschaltet wird und die ursprünglichen primären und sekundären Kopien aktualisiert werden, aber die aktiven Postfächer noch nicht wieder auf den ursprünglichen Server verschoben wurden). In diesem Schritt bestimmen Sie mit der folgenden Berechnung die Megazyklusanforderungen für die sekundäre Postfachserver-VM:

• Erforderliche Postfachmegazyklen = (Anzahl der Postfachbenutzer × profilspezifische Megazyklen) + Anzahl der Remotedatenbankkopien × (Anzahl der Postfachbenutzer × profilspezifische Megazyklen × 10 %)

  = (2700 × 2) + 2 × (2700 × 2 × 0,1)

  = 5400 + 1080

  = 6480

Schritt 2: Bestimmen, ob Postfachserver-VMs die Arbeitslast im schlimmsten Fall unterstützen können

In diesem Schritt bestimmen Sie, ob die Anzahl der verfügbaren Megazyklen größer ist als die Anzahl der erforderlichen Megazyklen. Es sind 6.480 Megazyklen erforderlich, Sie verfügen über 7.275 Megazyklen. Die sekundäre Postfachserver-VM hat also ausreichend Kapazität, um 2.700 aktive Postfächer zu unterstützen.

Exchange 2010 – Getestete Lösungen

Bestimmen des erforderlichen Arbeitsspeichers pro primärer Postfachserver-VM

Mit den folgenden Schritten können Sie den erforderlichen Arbeitsspeicher pro primärer Postfachserver-VM bestimmen.

Schritt 1: Bestimmen der Datenbankcacheanforderungen pro Server für das schlimmste Ausfallszenario

In einem vorherigen Schritt haben Sie bestimmt, dass die Datenbankcacheanforderungen für alle Postfächer 190 GB betragen und für jedes aktive Postfach durchschnittlich ein Cache von 6 MB erforderlich ist.

Berechnen Sie den erforderlichen Datenbankcache basierend auf 5.400 aktiven Postfächern auf den übrigen Postfachserver-VMs, um im Entwurf das schlimmste Ausfallszenario zu berücksichtigen:

• Erforderlicher Arbeitsspeicher für den Datenbankcache = Anzahl aktiver Postfächer × durchschnittlicher Cache pro Postfach

  = 5400 × 6 MB

  = 32400 MB

  = 31,6 GB

Schritt 2: Bestimmen der gesamten Arbeitsspeicheranforderungen pro Postfachserver-VM für das schlimmste Ausfallszenario

Verwenden Sie in diesem Schritt die folgende Tabelle, um die empfohlene Arbeitsspeicherkonfiguration zu bestimmen.

Arbeitsspeicheranforderungen

Physischer Arbeitsspeicher (RAM) des Servers	Größe des Datenbankcache (nur Postfachserverrolle)
24 GB	17,6 GB
32 GB	24,4 GB
48 GB	39,2 GB

Die empfohlene Speicherkonfiguration zur Unterstützung eines Datenbankcache von 31,6 GB für eine Postfachserverrolle beträgt 48 GB.

Exchange 2010 – Getestete Lösungen

Bestimmen des erforderlichen Arbeitsspeichers pro sekundärer Postfachserver-VM

Mit den folgenden Schritten können Sie den erforderlichen Arbeitsspeicher pro sekundärer Postfachserver-VM bestimmen.

Schritt 1: Bestimmen der Datenbankcacheanforderungen pro Server für das schlimmste Ausfallszenario

In einem vorherigen Schritt haben Sie bestimmt, dass die Datenbankcacheanforderungen für alle Postfächer 190 GB betragen und für jedes aktive Postfach durchschnittlich ein Cache von 6 MB erforderlich ist.

Berechnen Sie den erforderlichen Datenbankcache basierend auf 2.700 aktiven Postfächern auf den sekundären Postfachserver-VMs, um im Entwurf das schlimmste Ausfallszenario zu berücksichtigen:

• Erforderlicher Arbeitsspeicher für den Datenbankcache = Anzahl aktiver Postfächer × durchschnittlicher Cache pro Postfach

  = 2700 × 6 MB

  = 16200 MB

  = 15,8 GB

Schritt 2: Bestimmen der gesamten Arbeitsspeicheranforderungen pro Postfachserver-VM für das schlimmste Ausfallszenario

Verwenden Sie in diesem Schritt die folgende Tabelle, um die empfohlene Arbeitsspeicherkonfiguration zu bestimmen.

Arbeitsspeicheranforderungen

Physischer Arbeitsspeicher (RAM) des Servers	Größe des Datenbankcache (nur Postfachserverrolle)	Größe des Datenbankcache (mehrere Serverrollen, beispielsweise Postfach- und Hub-Transport-Serverrollen)
24 GB	17,6 GB	14 GB
32 GB	24,4 GB	20 GB
48 GB	39,2 GB	32 GB

Die empfohlene Arbeitsspeicherkonfiguration zur Unterstützung eines Datenbankcache von 15,8 GB für eine Postfachserverrolle beträgt 24 GB.

Exchange 2010 – Getestete Lösungen

Bestimmen des erforderlichen Arbeitsspeichers pro Kombination aus Clientzugriffs- und Hub-Transport-Server

Verwenden Sie die folgende Tabelle, um die Arbeitsspeicherkonfiguration für die VM für Clientzugriffs- und Hub-Transport-Kombinationsserver zu bestimmen.

Auf den installierten Serverrollen basierende Speicherkonfigurationen für Servercomputer mit Exchange 2010

Exchange 2010-Serverrolle	Unterstützes Minimum	Empfohlenes Maximum
Kombinierte Clientzugriffs- und Hub-Transport-Serverrolle (Clientzugriffs- und Hub-Transport-Serverrollen, die auf dem gleichen physischen Server ausgeführt werden)	4 GB	2 GB pro Kern (mindestens 8 GB)

Da die VM für Clientzugriffs- und Hub-Transport-Kombinationsserver drei virtuelle Prozessoren aufweist, werden 6 GB des Arbeitsspeichers jeder VM für Clientzugriffs- und Hub-Transport-Kombinationsserver zugeordnet.

Exchange 2010 – Getestete Lösungen

Bestimmen des erforderlichen Arbeitsspeichers pro Hyper-V-Stammserver

Verwenden Sie die folgende Berechnung, um den erforderlichen Arbeitsspeicher pro Hyper-V-Stammserver zu bestimmen:

• Stammserver-Arbeitsspeicher = Arbeitsspeicher für das Stammbetriebssystem + Arbeitsspeicher für die VM für Clientzugriffs- und Hub-Transport-Kombinationsserver + Arbeitsspeicher für die primäre Postfachserver-VM + Arbeitsspeicher für die sekundäre Postfachserver-VM

  = 4 GB + 6 GB + 48 GB + 24 GB

  = 82 GB

Die physische Arbeitsspeicheranforderung für den Stammserver beträgt 82 GB. In Abstimmung mit den empfohlenen Konfigurationen des physischen Arbeitsspeichers erhält der Server 96 GB.

Exchange 2010 – Getestete Lösungen

Entwerfen von Database Availability Groups

In einem vorherigen Schritt haben Sie bestimmt, dass die Lösung drei DAGs enthalten würde und dass jede DAG zwei der drei physische Standorte umfassen würde. Da Sie jetzt bestimmt haben, wie viele Postfachserver erforderlich sind, um die Arbeitslast und die DAG-Anforderungen zu unterstützen, können Sie mit dem DAG-Entwurf fortfahren.

DAG-Entwurf

Exchange 2010 – Getestete Lösungen

Entwerfen des Layouts von Datenbankkopien

Führen Sie die folgenden Schritte aus, um das Layout von Datenbankkopien zu entwerfen.

Schritt 1: Bestimmen der Anzahl eindeutiger Exchange-Datenbanken in der DAG

Verwenden Sie den Anforderungsrechner für die Exchange 2010-Postfachserverrolle, um die optimale Anzahl bereitzustellender Exchange-Datenbanken zu bestimmen. Geben Sie die entsprechenden Informationen auf der Eingaberegisterkarte ein, und wählen Sie Yes (Ja) für Automatically Calculate Number of Databases / DAG (Anzahl der Datenbanken automatisch berechnen / DAG) aus. Verwenden Sie im Feld für die Begrenzung der Postfachgröße ein Kontingent von 2.048 MB für das vollständig bereitgestellte Postfach.

Exchange-Datenbanken in der DAG

Auf der Registerkarte Role Requirements (Rollenanforderungen) wird die empfohlene Anzahl von Datenbanken angezeigt. Für diese Lösung empfiehlt der Rechner, dass jede DAG mindestens 24 eindeutige Datenbanken aufweist.

*Entwurfsentscheidungspunkt*

In Übereinstimmung mit den Empfehlungen des Rechners werden 24 Datenbanken pro DAG bereitgestellt.

Schritt 2: Bestimmen des Datenbanklayouts bei normalen Betriebsbedingungen

Da es pro DAG 24 eindeutige Datenbanken gibt und in der DAG acht Server sind, hostet jeder der vier Server am primären Standort bei normalen Betriebsbedingungen sechs aktive Datenbankkopien.

Fügen Sie zuerst den vier Servern die aktiven Datenbankkopien hinzu, wie in der folgenden Tabelle gezeigt.

Datenbanklayout bei normalen Betriebsbedingungen

Database	MBX1	MBX2	MBX3	MBX4
DB1-6	A1
DB7-12		A1
DB13-18			A1
DB19-24				A1

In der obigen Tabelle gilt Folgendes:

• A1 = aktive Datenbankkopie

In einem vorherigen Schritt haben Sie bestimmt, dass die Strategie für die Ausfallsicherheit von Postfachservern auf betriebliche Effizienz ausgelegt sein soll. Postfachserver werden paarweise bereitgestellt.

Da die DAG vier Postfachserver aufweist, bilden Server 1 und 2 sowie Server 3 und 4 jeweils ein Paar. In diesem Schritt fügen Sie die passiven Datenbankkopien (P1) dem alternativen Server in jedem Paar hinzu, wie in der folgenden Tabelle gezeigt.

Datenbanklayout bei normalen Betriebsbedingungen mit passiven Kopien

Database	MBX1	MBX2	MBX3	MBX4
DB1-6	A1	P1
DB7-12	P1	A1
DB13-18			A1	P1
DB19-24			P1	A1

In der obigen Tabelle gilt Folgendes:

• A1 = aktive Datenbankkopie

• P1 = passive Datenbankkopie

Schritt 3: Bestimmen des Datenbanklayouts bei einem Serverausfall oder einer Wartung am Standort

Bei einem Serverausfall oder einer Wartung werden die P1-Kopien auf dem alternativen Server aktiviert. In der folgenden Tabelle wird dies gezeigt, wobei MBX2 und MBX4 zur Wartung offline sind.

Layout der Datenbankkopien bei einem Serverausfall oder einer Wartung am Standort

In der obigen Tabelle gilt Folgendes:

• A1 = aktive Datenbankkopie

• P1 = passive Datenbankkopie

Schritt 4: Hinzufügen von Datenbankkopien zum sekundären Datencenter, um Ausfallsicherheit von Standorten zu unterstützen

In diesem Schritt wird für die Ausfallsicherheit von Standorten eine dritte Datenbankkopie den DAG-Mitgliedern im sekundären Datencenter hinzugefügt, wie in der folgenden Tabelle gezeigt.

Zur Unterstützung der Ausfallsicherheit von Standorten dem sekundären Datencenter hinzugefügte Datenbankkopien

Database	StandortA MBX1	StandortA MBX2	StandortA MBX3	StandortA MBX4	StandortB MBX5	StandortB MBX6	StandortB MBX7	StandortB MBX8
DB1-6	A1	P1			P2
DB7-12	P1	A1				P2
DB13-18			A1	P1			P2
DB19-24			P1	A1				P2

In der obigen Tabelle gilt Folgendes:

• A1 = aktive Datenbankkopie

• P1 = lokale passive Datenbankkopie

• P2 = passive Remotedatenbankkopie

Schritt 5: Bestimmen des Datenbanklayouts bei Standortausfällen

Bei einem Ausfall des primären Datencenters werden die P2-Kopien am sekundären Standort aktiviert, wie in der folgenden Tabelle gezeigt. Solange der primäre Standort nicht wieder online geschaltet wurde, gibt es nur eine Kopie der Datenbank.

Datenbanklayout bei Standortausfällen

In der obigen Tabelle gilt Folgendes:

• A1 = aktive Datenbankkopie

• P1 = passive Datenbankkopie

• P2 = passive Datenbankkopie

Exchange 2010 – Getestete Lösungen

Datencenter-Aktivierungsmodus

Bei einem schwerwiegenden Fehler, der sich auf die DAG auswirkt (z. B. der vollständige Ausfall eines Datencenters), wird mit dem Datencenter-Aktivierungsmodus (Datacenter Activation Coordination, DAC) das Aktivierungsverhalten der DAG gesteuert. Wenn der Datacenter-Aktivierungsmodus nicht aktiviert ist und ein Fehler auftritt, der sich auf mehrere Server in der DAG auswirkt, passiert Folgendes: Wird die Mehrzahl der DAG-Mitglieder nach dem Ausfall wiederhergestellt, wird die DAG neu gestartet und versucht, die Datenbanken einzubinden. In einer Konfiguration mit mehreren Datencentern kann dieses Verhalten zu einem Split Brain-Syndrom führen, einer Bedingung, die entsteht, wenn alle Netzwerke ausfallen und DAG-Mitglieder untereinander keine Taktsignale empfangen können. Das Split Brain-Syndrom kann auch auftreten, wenn die Netzwerkkonnektivität zwischen den Datencentern unterbrochen ist. Das Split Brain-Syndrom wird verhindert, indem immer die Mehrzahl der Mitglieder der DAG (bei einer geraden Mitgliederzahl wird der Zeugenserver der DAG einbezogen) verfügbar und aktiv sein muss, damit die DAG funktionsfähig ist. Weitere Informationen finden Sie unter Grundlegendes zum Aktivierungsmodus des Datencenters.

*Entwurfsentscheidungspunkt*

Der DAC-Modus wird für alle drei DAGs in der Umgebung aktiviert, um das Split Brain-Syndrom zu verhindern.

Exchange 2010 – Getestete Lösungen

Festlegen der Platzierung des Dateifreigabenzeugen

In Exchange 2010 verwendet die DAG einen minimalen Komponentensatz des Windows-Failoverclusterings. Eine dieser Komponenten ist die Quorumressource, die bei der Bestimmung des Clusterzustands und bei der Mitgliedschaft einen Mechanismus für Entscheidungen bietet. Es ist entscheidend, dass jedes DAG-Mitglied über eine konsistente Ansicht darauf verfügt, wie der der DAG zugrunde liegende Cluster konfiguriert ist. Das Quorum dient als definitives Repository für alle Konfigurationsinformationen über den Cluster. Mit dem Quorum werden zudem Verbindungen getrennt, um ein Split Brain-Syndrom zu vermeiden. Das Split Brain-Syndrom stellt eine Bedingung dar, die auftritt, wenn DAG-Mitglieder aktiv sind, aber nicht miteinander kommunizieren können. Das Split Brain-Syndrom wird verhindert, indem immer eine Mehrheit der DAG-Mitglieder (bei DAGs mit einer geraden Anzahl von Mitgliedern wird der DAG-Zeugenserver einbezogen) verfügbar und aktiv sein muss, damit die DAG funktionsfähig ist.

Ein Zeugenserver ist ein Server außerhalb einer DAG, der den Dateifreigabenzeugen hostet, der zum Erreichen und Erhalten des Quorums verwendet wird, wenn die DAG über eine gerade Anzahl von Mitgliedern verfügt. DAGs mit einer ungeraden Anzahl von Mitgliedern verwenden keinen Zeugenserver. Nach der Erstellung einer DAG wird der Dateifreigabenzeuge standardmäßig am gleichen Standort wie das erste Mitglied der DAG einem Hub-Transport-Server hinzugefügt (auf dem nicht die Postfachserverrolle installiert ist). Wenn Ihr Hub-Transport-Server in einer VM ausgeführt wird, die sich auf dem gleichen Stammserver befindet wie die VMs, die die Postfachserverrolle ausführen, sollten Sie den Speicherort des Dateifreigabenzeugen auf einen anderen Server mit hoher Verfügbarkeit verschieben. Sie können den Dateifreigabenzeugen auf einen Domänencontroller verschieben, aber aufgrund von möglichen Auswirkungen auf die Sicherheit sollte dies der letzte Ausweg sein.

In Lösungen, in denen die DAG mehrere Standorte umfasst, sollte für den sekundären Standort ein alternativer Dateifreigabenzeuge definiert werden. Dadurch kann der Cluster das Quorum bei einem Standortausfall mit aktiviertem DAC-Modus beibehalten.

*Entwurfsentscheidungspunkt*

Da entschieden wurde, drei DAGs bereitzustellen, und alle DAGs Mitglieder an mehreren Standorten enthalten, müssen drei primäre Zeugenverzeichnisse und drei alternative Zeugenverzeichnisse definiert werden. Diese Verzeichnisse werden auf Dateiservern innerhalb jedes Standorts gespeichert.

Exchange 2010 – Getestete Lösungen

Planen von Namespaces

Wenn Sie Ihre Exchange 2010-Organisation planen, besteht eine der wichtigsten Entscheidungen, die Sie treffen müssen, in der Auswahl der Anordnung des externen Namespaces Ihrer Organisation. Ein Namespace ist eine logische Struktur, die normalerweise durch einen Domänennamen im Domain Name System (DNS) dargestellt wird. Wenn Sie Ihren Namespace definieren, müssen Sie die verschiedenen Standorte Ihrer Clients und Server berücksichtigen, auf denen Postfächer gespeichert sind. Neben den physischen Standorten der Clients müssen Sie berücksichtigen, wie Verbindungen mit Exchange 2010 hergestellt werden. Die Antworten auf diese Fragen legen fest, wie viele Namespaces erforderlich sind. Ihre Namespaces sind normalerweise an Ihrer DNS-Konfiguration ausgerichtet. Es wird empfohlen, dass jeder Active Directory-Standort in einer Region mit mindestens einem mit dem Internet verbundenen Clientzugriffsserver einen eindeutigen Namespace aufweist. Dieser Sachverhalt wird in DNS normalerweise durch einen A-Datensatz wie z. B. "mail.contoso.com" oder "mail.europe.contoso.com" dargestellt.

Weitere Informationen finden Sie unter Grundlegendes zu Clientzugriffsserver-Namespaces.

Es gibt eine Reihe unterschiedlicher Möglichkeiten für die Anordnung der externen Namespaces, aber normalerweise können Ihre Anforderungen mit einem der folgenden Namespacemodelle erfüllt werden:

• Konsolidiertes Datencentermodell   Dieses Modell besteht aus einem einzigen physischen Standort. Alle Server befinden sich innerhalb des Standorts, und es ist ein einziger Namespace vorhanden, z. B. "mail.contoso.com".

• Einzelner Namespace mit Proxystandorten   Dieses Modell besteht aus mehreren physischen Standorten. Nur ein Standort enthält einen mit dem Internet verbundenen Clientzugriffsserver. Die anderen Standorte sind nicht mit dem Internet verbunden. Für die Standorte in diesem Modell ist nur ein Namespace vorhanden, z. B. mail.contoso.com.

• Einzelner Namespace und mehrere Standorte   Dieses Modell besteht aus mehreren physischen Standorten. Jeder Standort kann einen mit dem Internet verbundenen Clientzugriffsserver aufweisen. Alternativ kann es auch nur einen Standort mit einem mit dem Internet verbundenen Clientzugriffsserver geben. Für die Standorte in diesem Modell ist nur ein Namespace vorhanden, z. B. mail.contoso.com.

• Regionale Namespaces   Dieses Modell besteht aus mehreren physischen Standorten und mehreren Namespaces. Ein Standort in New York City verwendet z. B. den Namespace "mail.usa.contoso.com", ein Standort in Toronto den Namespace "mail.canada.contoso.com" und ein Standort in London den Namespace "mail.europe.contoso.com".

• Mehrere Gesamtstrukturen   Dieses Modell besteht aus mehreren Gesamtstrukturen mit mehreren Namespaces. Eine Organisation, die dieses Modell verwendet, könnte aus zwei Partnerunternehmen bestehen, z. B. aus Contoso und Fabrikam. Die Namespaces könnten "mail.usa.contoso.com", "mail.europe.contoso.com", "mail.asia.fabrikam.com" und "mail.europe.fabrikam.com" lauten.

*Entwurfsentscheidungspunkt*

Für dieses Szenario wurde das Modell mit regionalen Namespaces ausgewählt, da es für Organisationen mit aktiven Postfächern an mehreren Standorten am besten geeignet ist.

Der Vorteil dieses Modells besteht darin, dass die Proxyweiterleitung reduziert wird, da ein größerer Prozentsatz der Benutzer eine Verbindung mit einem Clientzugriffsserver am gleichen Active Directory-Standort wie ihr Postfachserver herstellen kann. Auf diese Weise wird die Benutzerumgebung und die Leistung verbessert. Für Benutzer mit Postfächern an einem Standort, der nicht über einen mit dem Internet verbundenen Clientzugriffsserver verfügt, erfolgt weiterhin die Proxyweiterleitung.

Für diese Lösung gelten auch die folgenden Konfigurationsanforderungen:

• Es müssen mehrere DNS-Datensätze verwaltet werden.

• Mehrere Zertifikate müssen erworben, konfiguriert und verwaltet werden.

• Die Verwaltung der Sicherheit ist komplexer, da für einen Standort mit Internetzugriff ein Computer mit Microsoft Forefront Threat Management Gateway oder einer anderen Reverseproxy- oder Firewalllösung erforderlich ist.

• Die Benutzer müssen eine Verbindung mit ihrem eigenen regionalen Namespace herstellen. Dies kann zu vermehrten Anrufen beim Helpdesk und zu einem erhöhten Schulungsbedarf führen.

Exchange 2010 – Getestete Lösungen

Bestimmen der Strategie für das Clientzugriffsserver-Array und den Lastenausgleich

In Exchange 2010 wurden der RPC-Clientzugriffsdienst und der Exchange-Adressbuchdienst auf der Clientzugriffs-Serverrolle eingeführt, um die Funktionalität für Postfachbenutzer zu verbessern, wenn die aktive Postfachdatenbankkopie auf einen anderen Postfachserver verschoben wird (beispielsweise bei Ausfällen oder der Wartung der Postfachdatenbanken). Die Verbindungsendpunkte für den Postfachzugriff über Microsoft Outlook und andere MAPI-Clients wurde von der Postfachserverrolle auf die Clientzugriffs-Serverrolle übertragen. Daher muss für interne und externe Outlook-Verbindungen jetzt ein Lastenausgleich über alle Clientzugriffsserver am Standort erfolgen, um Fehlertoleranz zu erreichen. Sie können ein Clientzugriffsserver-Array definieren, um den MAPI-Endpunkt einer Gruppe von Clientzugriffsservern und nicht nur einem bestimmten Clientzugriffsserver zuzuordnen. Sie können nur ein Array pro Active Directory-Standort definieren, und ein Array kann nicht mehr als einen Active Directory-Standort umfassen. Weitere Informationen finden Sie unter Grundlegendes zum RPC-Clientzugriff und Understanding Load Balancing in Exchange.

*Entwurfsentscheidungspunkt*

Da dies eine Bereitstellung mit drei Standorten ist, bei der an jedem Standort auf vier Servern die Clientzugriffs-Serverrolle ausgeführt wird, gibt es insgesamt drei Clientzugriffsserver-Arrays. Eine Lösung für den Hardwarelastenausgleich wird verwendet, um die Last auf die Clientzugriffsserver-Arrays an jedem Standort zu verteilen.

Exchange 2010 – Getestete Lösungen

Bestimmen eines Modells für den Hardwarelastenausgleich

Führen Sie die folgenden Schritte aus, um ein Modell für den Hardwarelastenausgleich zu bestimmen.

Schritt 1: Bestimmen des bevorzugten Anbieters für den Hardwarelastenausgleich

In diesem Beispiel ist der bevorzugte Anbieter Cisco, da die Produktreihe Cisco Application Control Engine (ACE) mit Cisco Unified Computing System eingesetzt werden kann, das für die Server-, Netzwerk- und Speicherverbindungskomponenten dieser Lösung ausgewählt wurde.

Die Cisco ACE-Produktreihe bietet eine gut skalierbare Datencenterlösung mit hoher Verfügbarkeit, von der die Exchange 2010-Anwendungsumgebung profitieren kann. Cisco ACE-Produkte bieten Interoperabilität mit den folgenden Vorteilen:

• Leistung, Skalierbarkeit, Durchsatz und Anwendungsverfügbarkeit

• Standardbasierter Entwurf

• Virtuelle Architektur mit Gerätepartitionierung

• Rollenbasierte Administration und zentrale Verwaltung

• Sicherheitsdienste durch umfassende Paketprüfung, Zugriffssteuerungslisten (Access Control Lists, ACLs), Unicast Reverse Path Forwarding und Netzwerkadressenübersetzung (Network Address Translation, NAT)/Portadressenübersetzung

Schritt 2: Prüfen der verfügbaren Optionen des bevorzugten Anbieters

Die Cisco ACE-Produktreihe enthält zwei unterschiedliche Modelle für den Hardwarelastenausgleich, die die Anforderungen für die gut skalierbare Datencenterlösung mit hoher Verfügbarkeit erfüllen, die für die Exchange 2010-Anwendungsumgebung geeignet ist. Dabei handelt es sich um das Gerät Cisco ACE 4710 und das integrierte Dienstmodul der Routingplattformen Cisco Catalyst 6500/Cisco 7600.

Das Gerät Cisco ACE 4710 bietet einen Durchsatz von bis zu 4 GBit/s mit einem Formfaktor von 1RU (One-Rack-Unit) und kann über Softwarelizenzen aktualisiert werden, sodass Sie die Investition in Schutz und Skalierbarkeit langfristig nutzen können. An der Basis ist das 4710 ein 1U-Rackgehäuse mit einer Cavium Nitrox Octeon-Beschleunigerkarte, die vier Gigabit-Ethernet-Ports bereitstellt, die mithilfe von Cisco EtherChannel gebündelt und mit einem Switch verbunden werden können. Standardmäßig unterstützt Cisco ACE 4710 Virtualisierung mit einem Administratorgerät und fünf Benutzergeräten, einer Bandbreite von 1 GBit/s, 1.000 SSL-Transaktionen (Secure Sockets Layer) pro Sekunde und einer Komprimierung von 100 Megabit pro Sekunde (MBit/s). Mit den folgenden Softwarelizenzupgrades kann die Lösung ohne den Einsatz neuer Geräte erweitert werden:

• Durchsatz   Der Standarddurchsatz von 1 GBit/s kann auf 2 oder 4 GBit/s erhöht werden.

• Virtuelle Geräte   Die Anzahl virtueller Geräte kann von 5 auf 20 virtuelle Geräte erhöht werden.

• SSL-Transaktionen pro Sekunde   Der Wert für die SSL-Transaktionen pro Sekunde kann von 1.000 auf 5.000 oder 7.500 erhöht werden.

• Komprimierung   Die Komprimierung kann auf 500 MBit/s oder 1 oder 2 GBit/s des Durchsatzes erhöht werden.

• Rollenbasierte Zugriffssteuerung   Zentrale rollenbasierte Verwaltung wird über die Application Network Manager-Benutzeroberfläche oder eine Befehlszeilenschnittstelle (Command Line Interface, CLI) ermöglicht.

• Hohe Verfügbarkeit   Es gibt Unterstützung für redundante Konfigurationen (im Gerät und kontextübergreifend).

Das Cisco ACE-Modul für Cisco Catalyst 6500 Series Switches oder Cisco 7600 Series Router bietet einen Durchsatz von bis zu 16 GBit/s mit einem Formfaktor von einem Steckplatz pro Modul. Wie auch bei ACE 4710 ist ein Upgrade über Softwarelizenzen möglich. Bis zu vier Cisco ACE-Module können in einem Cisco Catalyst 6500 Series Switch oder Cisco 7600 Series Router installiert werden. Jedes kann die Geschäftsprozesse mehrerer unabhängiger Unternehmenseinheiten unterstützen und dabei von der Vielzahl von Verbindungsmöglichkeiten des Switches oder Routers profitieren. Der Systemadministrator bestimmt die Anwendungsanforderungen und weist die entsprechenden Netzwerkdienste als virtuelle Kontexte zu. Jeder Kontext enthält einen eigenen Satz von Richtlinien, Schnittstellen, Ressourcen und Administratoren:

• Durchsatz   Lastenausgleichsdienste bieten eine Durchsatzkapazität von bis zu 16 GBit/s und 345.000 Schicht 4-Verbindungen pro Sekunde.

• Virtuelle Geräte   Die Anzahl virtueller Geräte kann von 5 auf 250 erhöht werden.

• SSL-Transaktionen pro Sekunde   Die SSL-Transaktionen pro Sekunden können durch Lizenzen auf ACE20-Modulen auf 15.000 SSL-Sitzungen und auf ACE30-Modulen auf 30.000 erhöht werden.

• Komprimierung   Die Komprimierung kann auf ACE30-Modulen auf 6 GBit/s erhöht werden.

• Rollenbasierte Zugriffssteuerung   Zentrale rollenbasierte Verwaltung wird über die Application Network Manager-Benutzeroberfläche oder eine Befehlszeilenschnittstelle ermöglicht.

• Hohe Verfügbarkeit   Es gibt Unterstützung für redundante Konfigurationen (im Gehäuse, gehäuseübergreifend und kontextübergreifend).

Schritt 3: Auswählen des Modells für den Hardwarelastenausgleich

Das Gerät Cisco ACE 4710 wurde ausgewählt, da es maximierte Anwendungsverfügbarkeit, umfassende Anwendungssicherheit, eine virtualisierte Architektur und Nutzen und Schutz der Investition bietet:

• Maximierte Anwendungsverfügbarkeit   Mit Cisco ACE 4710 werden für den Endbenutzer Geschäftskontinuität und Dienste sichergestellt, indem die Verfügbarkeit durch den hoch skalierbaren Schicht 4-Lastenausgleich und Schicht 7-Inhaltswechsel optimiert wird. Dadurch werden auch die Auswirkungen von Anwendungs- und Geräteausfällen minimiert.

• Umfassende Anwendungssicherheit   Cisco ACE 4710 ist eine letzte Schutzmaßnahme für Server, die mit Funktionen wie umfassender Paketprüfung, Netzwerk- und Protokollsicherheit und gut skalierbaren Möglichkeiten für die Zugriffssteuerung Schutz vor Anwendungsbedrohungen und DoS-Angriffen (Denial-of-Service) bietet.

• Virtualisierte Architektur   Die virtualisierte Architektur ist ein wichtiger Entwurfsbestandteil von Cisco ACE und ein eindeutiges Verkaufsargument im Vergleich zu anderen angebotenen Lösungen. IT-Manager können auf einem Cisco ACE 4710-Gerät bis zu 20 virtuelle Geräte konfigurieren. Der Vorteil ist, dass mit der Zunahme von Anwendungsbereitstellungen weniger Geräte verwaltet werden müssen, die Kosten für Strom und Kühlung deutlich geringer sind und neue Anwendungen schneller genutzt werden können.

Exchange 2010 – Getestete Lösungen

Bestimmen des Speicherentwurfs

Eine gut durchdachte Speicherlösung ist ein entscheidender Aspekt der erfolgreichen Bereitstellung einer Exchange 2010-Postfachserverrolle. Weitere Informationen finden Sie unter Speicherentwurf für Postfachserver.

Schritt 1: Zusammenfassen der Speicheranforderungen

In der folgenden Tabelle werden die Speicheranforderungen zusammengefasst, die Sie in einem vorherigen Entwurfsschritt berechnet oder bestimmt haben.

Zusammenfassung der Speicherplatzanforderungen

Erforderlicher Speicherplatz	Wert
Postfachgröße auf dem Datenträger für ein 2-GB-Postfach (MB)	2301
Insgesamt erforderliche Datenbankkapazität (GB)	120128
Insgesamt erforderliche Protokollkapazität (GB)	3974
Erforderliche Gesamtkapazität (GB)	124102
Erforderliche Gesamtkapazität für drei Datenbankkopien (GB)	372306
Erforderliche Gesamtkapazität für drei Datenbankkopien (Terabyte)	364
Pro Standort erforderliche Gesamtkapazität (Terabyte)	122

Schritt 2: Bestimmen, ob eine virtuelle Bereitstellung oder eine Bereitstellung mit schlanker Speicherzuweisung verwendet wird

Viele Kunden möchten mit dem Wechsel auf Exchange 2010 ihre Postfachkontingente beträchtlich vergrößern. Es kann jedoch einige Zeit dauern, bis die Postfachgrößen von einigen hundert Megabyte auf mehrere Gigabyte anwachsen. In diesem Fall kann es für einige Organisationen von Vorteil sein, den Kauf von zusätzlichem Speicher aufzuschieben, um von wahrscheinlichen Preissenkungen bei Datenträgerspeichern in der Zukunft zu profitieren.

Viele Speicheranbieter bieten Lösungen mit schlanker Speicherzuweisung, sodass der Exchange-Server über eine größere Speicherkapazität verfügen kann, als physisch vorhanden ist. Fügen Sie dann nach und nach physischen Speicher hinzu, um die steigende Nachfrage ohne Störungen oder Ausfallzeiten zu erfüllen. Dadurch werden die Gesamtbetriebskosten gesenkt, indem die anfängliche Zuweisung von Speicherkapazität reduziert wird. Zudem wird die Verwaltung vereinfacht, da zur Unterstützung des Wachstums weniger Schritte notwendig sind.

Die EMC Unified Storage-Implementierung der schlanken Speicherzuweisung wird von der Funktion für virtuelle Bereitstellungen umgesetzt, die Hotsparing, proaktives Sparing, nicht störende Erweiterung des Thin Pools und die Möglichkeit, ohne Ausfallzeiten zwischen Thin-LUNs und herkömmlichen Thick-LUNs zu migrieren, unterstützt. Durch diese Flexibilität unterscheidet sich die virtuelle EMC Unified Storage-Bereitstellung von typischen Implementierungen der schlanken Speicherzuweisung.

*Entwurfsentscheidungspunkt*

Die aktuelle Exchange-Implementierung weist ein definiertes Postfachkontingent von 200 MB auf. Es wird geschätzt, dass nach dem Wechsel auf Exchange 2010 die Postfachgrößen in den ersten 12 bis 18 Monaten um etwa 300 Prozent zunehmen werden. Der Plan besteht darin, ausreichend Speicher für eine durchschnittliche Postfachgröße von 600 MB zu erwerben. Während der Lebensdauer der Exchange 2010-Implementierung wird eine durchschnittliche Postfachgröße von annähernd 2 GB erwartet. Da Postfachkontingente von 2 GB teuer sind, wird die schlanke Speicherzuweisung implementiert, damit das anfängliche Postfachkontingent von 600 MB bereitgestellt werden kann. Der zugrunde liegende physische Speicher wird in kommenden Budgetzyklen erweitert, bis er den erwarteten Bedarf erfüllt.

Schritt 3: Bestimmen, ob Protokolle und Datenbanken auf der gleichen LUN abgelegt werden

Bei der Nutzung der schlanken Speicherzuweisung auf EMC Unified Storage für Exchange 2010-Bereitstellungen empfiehlt es sich, die Protokolldateien von den Datenbankdateien zu trennen. Wenn Sie eine Zunahme der Postfachgröße erwarten, aber keine Änderung des Nachrichtenprofils (pro Tag gesendete/empfangene Nachrichten), müssen Sie die Datenbank-LUNs nach und nach vergrößern, aber nicht die Protokoll-LUNs. Möglicherweise ist es nicht von Vorteil, die Protokolle auf für schlanke Speicherzuweisung geeignete LUNs abzulegen.

Durch die Trennung der Datenbank- und Protokoll-LUNs haben Sie auch die Flexibilität, sie auf anderen Datenträgertypen abzulegen oder verschiedene RAID-Stufen zu verwenden.

*Entwurfsentscheidungspunkt*

Gemäß der bewährten Methode von EMC werden die Datenbanken und Protokolle auf unterschiedlichen LUNs gespeichert. Da erwartet wird, dass das Nachrichtenprofil in den nächsten drei Jahren ziemlich konstant bleiben wird, ergibt sich kein Vorteil daraus, die Protokolle auf für schlanke Speicherzuweisung geeignete LUNs abzulegen.

Schritt 4: Bestimmen der Anzahl von Datenbanken pro LUN

Da VSS-basierte Sicherungen und Wiederherstellungen auf LUN-Ebene verarbeitet werden, wird die Anzahl der Datenbanken pro LUN normalerweise durch die Sicherungsstrategie bestimmt. In einem vorherigen Schritt wurde entschieden, VSS-basierte Sicherungen nicht in die Strategie für die Ausfallsicherheit von Datenbanken aufzunehmen. Die Entscheidung für die Anzahl von Datenbanken pro LUN wird von anderen Faktoren abhängig gemacht. Es empfiehlt sich im Allgemeinen, eine Datenbank pro LUN bereitzustellen. Mehr als eine Datenbank pro LUN kann diese Folgen haben:

• Eine überladene Datenbank, die die Fehlerfreiheit einer Datenbank beeinträchtigt

• Ein Seedingvorgang in einer Datenbank, der die Fehlerfreiheit einer Datenbank beeinträchtigt

• E/A-Vorgänge passiver Datenbanken, die aktive Datenbanken beeinträchtigen

*Entwurfsentscheidungspunkt*

Da es keine Anforderungen für die Bereitstellung von mehr als einer Datenbank pro LUN gibt, wird als Grundlage für den Speicherentwurf ein Modell mit einer Datenbank pro LUN verwendet.

Schritt 5: Bestimmen der Anzahl von LUNs pro Server für die Postfachserver des primären Datencenters

In einem vorherigen Schritt haben Sie bestimmt, dass jeder primäre Postfachserver sechs aktive und sechs passive Datenbanken unterstützen soll. Es gibt insgesamt 24 LUNs für jeden Postfachserver des primären Datencenters, wie in der folgenden Tabelle gezeigt.

Anzahl der pro Postfachserver erforderlichen LUNs

LUN-Typen	LUNs pro Server
LUNs für aktive Datenbanken	6
LUNs für aktive Protokolle	6
LUNs für passive Datenbanken	6
LUNs für passive Protokolle	6
LUNs insgesamt	24

Schritt 6: Bestimmen der Anzahl von LUNs pro Server für die Postfachserver des sekundären Datencenters

In einem vorherigen Schritt haben Sie bestimmt, dass jeder sekundäre Postfachserver sechs passive Datenbanken unterstützen soll. Es gibt insgesamt 12 LUNs für jeden Postfachserver des sekundären Datencenters, wie in der folgenden Tabelle gezeigt.

Anzahl der pro Postfachserver erforderlichen LUNs

LUN-Typen	LUNs pro Server
LUNs für passive Datenbanken	6
LUNs für passive Protokolle	6
LUNs insgesamt	12

Schritt 7: Definieren des Speicherbausteins

Verwenden Sie eine Bausteinmethode, um die restlichen Schritte des Speicherentwurfs zu vereinfachen. In dieser Lösung unterstützt jede Datenbank 450 aktive Postfächer. Jeder Postfachserver unterstützt 6 Datenbanken oder 2.700 aktive Postfächer auf 6 Datenbank-LUNs und 6 Protokoll-LUNs. Es wird ein Baustein mit 12 LUNs verwendet, der Inkremente von 2.700 Postfächern unterstützt.

Schritt 8: Bestimmen der IOPS-Anforderungen des Bausteins

In diesem Schritt berechnen Sie die transaktionellen IOPS, die für die Unterstützung der 2.700 aktiven Postfachbenutzer im Baustein erforderlich sind. In einem der folgenden Schritte werden Sie mit den IOPS-Anforderungen die minimale und die maximale Anzahl von Spindles bestimmen, die basierend auf dem anfänglichen Postfachkontingent und dem Postfachkontingent der vollständigen Bereitstellung bereitgestellt werden müssen. Verwenden Sie die folgende Berechnung:

• Insgesamt erforderliche transaktionelle IOPS für den Baustein = IOPS pro Postfachbenutzer × Anzahl von Postfächern × E/A-Overheadfaktor

  = 0,10 × 2700 × 20%

  = 324 IOPS

Schritt 9: Bestimmen der anfänglichen Postfachgröße auf dem Datenträger

In einem vorherigen Schritt haben Sie als Postfachgröße auf dem Datenträger für eine Postfachkontingentbegrenzung von 2.048 MB den Wert 2.301 MB errechnet. Da schlanke Speicherzuweisung verwendet wird, berechnen Sie die anfängliche Postfachgröße auf dem Datenträger. Mit diesem Wert werden in einem späteren Schritt die anfänglichen Kapazitätsanforderungen berechnet.

Die folgenden Berechnungen werden verwendet, um für diese Lösung basierend auf einem 600-MB-Postfachkontingent die anfängliche Postfachgröße auf dem Datenträger zu bestimmen:

• Leere Seiten = 100 Nachrichten pro Tag × 75 ÷ 1024 MB = 7,3 MB

• Dumpster = (100 Nachrichten pro Tag × 75 ÷ 1024 MB × 14 Tage) + (600 MB × 0,012) + (600 MB × 0,058) = 144,2 MB

• Postfachgröße auf dem Datenträger = Postfachbegrenzung + leere Seiten + Dumpster

  = 600 MB + 7,3 MB + 144,2 MB

  = 752 MB

Schritt 10: Bestimmen der anfänglichen Datenbankkapazitätsanforderungen des Bausteins

Verwenden Sie folgende Berechnungen, um die anfänglich erforderliche Speicherkapazität für 2.700 Postfächer mit einem anfänglichen Postfachkontingent von 600 MB zu bestimmen:

• Kapazität für Datenbankdateien = (Anzahl von Postfächern × Postfachgröße auf dem Datenträger × Datenbankoverhead-Wachstumsfaktor) + (20 % Datenoverhead)

  = (2700 × 752 × 1) + (406080)

  = 2436480 MB

  = 2379 GB

• Kapazität für Datenbankkatalog = 10 % der Kapazität für Datenbankdateien

  = 238 GB

• Gesamtdatenbankkapazität = (Größe der Datenbankdateien) + (Indexgröße) ÷ 0,80, um 20 % freien Speicherplatz auf dem Volume bereitzustellen

  = (2379 + 238) ÷ 0,8

  = 3271 GB

Für die sechs Datenbanken im Baustein ist eine anfängliche Speicherkapazität von 3.271 GB erforderlich.

Schritt 11: Bestimmen der Kapazitätsanforderungen für die vollständig bereitgestellte Datenbank des Bausteins

Verwenden Sie folgende Berechnungen, um die erforderliche Speicherkapazität einer vollständigen Bereitstellung für 2.700 Postfächer mit einem Postfachkontingent von 2.048 MB zu bestimmen:

• Kapazität für Datenbankdateien = (Anzahl von Postfächern × Postfachgröße auf dem Datenträger × Datenbankoverhead-Wachstumsfaktor) + (20 % Datenoverhead)

  = (2700 × 2301 × 1) + (1242540)

  = 7455240 MB

  = 7281 GB

• Kapazität für Datenbankkatalog = 10 % der Kapazität für Datenbankdateien

  = 728 GB

• Gesamtdatenbankkapazität = (Größe der Datenbankdateien) + (Indexgröße) ÷ 0,80, um 20 % freien Speicherplatz auf dem Volume bereitzustellen

  = (7281 + 728) ÷ 0,8

  = 10011 GB

Für die sechs Datenbanken im Baustein ist bei vollständiger Bereitstellung eine Speicherkapazität von 10.011 GB erforderlich.

Schritt 12: Bestimmen der Protokollkapazitätsanforderungen des Bausteins

Verwenden Sie folgende Berechnungen, um die für die 2.700 Postfächer im Baustein erforderliche Protokollspeicherkapazität zu bestimmen:

• Erforderliche Protokollkapazität des Bausteins = Anzahl der Postfachbenutzer × Anzahl der Protokolle pro Postfach und Tag × Protokollgröße × (Anzahl der erforderlichen Tage für einen Ersatz einer ausgefallenen Infrastruktur) + (Prozentoverhead für Postfachverschiebungen)

  = (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

  = 216054 MB

  = 211 GB

• Protokollkapazität insgesamt = Protokollkapazität ÷ 0,80, um 20 % freien Speicherplatz auf dem Volume zu schaffen

  = 211 ÷ 0,80

  = 264

Für die sechs Protokollsätze im Baustein ist eine Speicherkapazität von 264 GB erforderlich.

Schritt 13: Bestimmen der erforderlichen Anzahl von Spindles zur Unterstützung der IOPS-Anforderungen des Bausteins

In diesem Schritt bestimmen Sie die erforderliche Anzahl von Spindles zur Unterstützung der IOPS-Anforderungen. Im nächsten Schritt bestimmen Sie die Spindleanzahl, mit der die Kapazitätsanforderungen erfüllt werden.

In einem vorherigen Schritt wurde bestimmt, dass 324 IOPS erforderlich sind, um den Baustein mit 2.700 Postfächern zu unterstützen. In diesem Schritt bestimmen Sie mit der folgenden Berechnung die erforderliche Anzahl von Datenträgern, um die IOPS-Anforderungen zu erfüllen:

• Datenträgeranzahl = (Benutzer-IOPS × Lesequotient) + Abzug für Schreibvorgänge × (Benutzer-IOPS × Schreibquotient) ÷ IOPS-Potenzial des ausgewählten Datenträgertyps

  = (324 × 0,6) + 4 × (324 × 0,4) ÷ 155

  = 4,6

Die IOPS-Anforderungen können mit fünf Datenträgern in einer RAID-5-Konfiguration erfüllt werden.

Schritt 14: Bestimmen der erforderlichen Anzahl von Spindles zur Unterstützung der anfänglichen Datenbankkapazitätsanforderungen des Bausteins

In einem vorherigen Schritt haben Sie bestimmt, dass der Baustein mit 2.700 Postfächern für ein anfänglich bereitgestelltes 600-MB-Postfach eine Speicherkapazität von 3.271 GB erfordert. Die nutzbare Kapazität pro 450-GB-Spindle in einer RAID-5-Konfiguration von CX4 Model 480 liegt bei etwa 402 GB. Verwenden Sie die folgende Berechnung, um die erforderliche Anzahl von Datenträgern zu bestimmen:

• Datenträgeranzahl = (erforderliche Gesamtkapazität) ÷ (nutzbare Kapazität pro Spindle mit RAID-5)

  = 3271 GB ÷ 402 GB

  = 8,1

Mit neun Datenträgern können die anfänglichen Datenbankkapazitätsanforderungen erfüllt werden.

Die bewährte Methoden von EMC für die Bereitstellung von Speicher auf EMC Unified Storage mit schlanker Speicherzuweisung sind die Konfiguration von RAID-5-Thin Pools auf einem Vielfachen von fünf Datenträgern. Weisen Sie 10 Datenträger für einen Baustein mit 2.700 Postfächern zu, und Sie haben Kapazitäten für späteres Wachstum.

Schritt 15: Bestimmen der erforderlichen Anzahl von Spindles zur Unterstützung der Datenbankkapazitätsanforderungen für eine vollständige Bereitstellung des Bausteins

In einem vorherigen Schritt haben Sie bestimmt, dass der Baustein mit 2.700 Postfächern für ein anfänglich bereitgestelltes 2.048-MB-Postfach eine Speicherkapazität von 10.011 GB erfordert. Die nutzbare Kapazität pro 450-GB-Spindle in einer RAID-5-Konfiguration von CX4 Model 480 liegt bei etwa 402 GB. Verwenden Sie die folgende Berechnung, um die erforderliche Anzahl von Datenträgern zu bestimmen:

• Datenträgeranzahl = (erforderliche Gesamtkapazität) ÷ (nutzbare Kapazität pro Spindle mit RAID-5)

  = 10011 GB ÷ 402 GB

  = 24,9

Mit 25 Datenträgern können die Datenbankkapazitätsanforderungen für eine vollständige Bereitstellung erfüllt werden.

Schritt 16: Bestimmen der erforderlichen Anzahl von Spindles zur Unterstützung der Protokollkapazitätsanforderungen des Bausteins

In einem vorherigen Schritt haben Sie bestimmt, dass der Baustein für 2.700 Postfächer eine Protokollspeicherkapazität von 264 GB erfordert. Der Einsatz von zwei 450-GB-Laufwerken in einer RAID-1/0-Konfiguration auf CX4-480 bietet eine nutzbare Speicherkapazität von 402 GB. Die vorgeschlagene Konfiguration mit zwei Datenträgern erfüllt die Protokollkapazitätsanforderungen des Bausteins für 2.700 Postfächer.

Schritt 17: Bestimmen der Strategie für den Thin Pool

Da jetzt die erforderliche Spindleanzahl zur Unterstützung der IOPS- und Kapazitätsanforderungen des Bausteins bestimmt wurde, müssen Sie die optimale Methode für die Bereitstellung von LUNs auf dem Array für den Baustein mit virtueller Bereitstellung oder schlanker Speicherzuweisung bestimmen.

Es gibt drei Hauptmodelle für den Entwurf von Thin Pools für Exchange:

• Ein Speicherpool   Ein großer Speicherpool für alle Exchange-Datenbanken und -Protokolle ist die einfachste Methode und bietet die beste Speicherplatznutzung. Ein einzelner Thin Pool empfiehlt sich jedoch nicht, wenn mehrere Kopien derselben Datenbank auf demselben physischen Array gespeichert sind.

• Ein Speicherpool pro Server   Ein Speicherpool für jeden Exchange-Postfachserver bietet bei der Anordnung von LUNs auf dem Array mehr Granularität. Mit einem geeigneten Entwurf können Datenbankkopien auf getrennten Spindlesätzen isoliert und Probleme mit Datenträgerkonflikten minimiert werden, die bei Aktivitäten wie Seeding/erneutes Seeding, Sicherung und Onlinewartung (Datenbankwartung im Hintergrund) auftreten können. Abhängig von der Anzahl von Postfachservern kann dieses Modell zu vielen Thin Pools führen, die schwieriger zu verwalten sind.

• Ein Speicherpool pro Datenbankkopie   Mit einem Speicherpool für jede Datenbankkopie wird sichergestellt, dass jede Kopie auf einem anderen Spindlesatz auf dem Array isoliert ist. Da in den meisten Organisationen zwischen zwei und vier Datenbankkopien bereitgestellt werden, bleibt die Anzahl der Thin Pools handhabbar. In diesem Modell verfügen mehrere Postfachserver über Datenbank-LUNs im gleichen Thin Pool. Es besteht das Risiko, dass Aktivitäten wie Seeding/erneutes Seeding, Sicherung und Onlinewartung (Datenbankwartung im Hintergrund) auf einem Postfachserver die Leistung auf einem anderen Postfachserver beeinträchtigen können.

*Entwurfsentscheidungspunkt*

Obwohl die Vorteile von einem Speicherpool pro Servermodell reizvoll sind, würde dies zu acht Thin Pools an jedem Standort bzw. insgesamt 24 Thin Pools führen. Der Einfachheit halber wird das Modell mit einem Speicherpool pro Datenbankkopie verwendet. Dies ergibt drei Thin Pools an jedem Standort und gewährleistet, dass jede Datenbankkopie auf einem eindeutigen Spindlesatz gespeichert wird. Dadurch wird sichergestellt, dass die Datenbankkopien auch in Situationen, in denen zusätzlicher Speicher aufgrund des Wachstums ergänzt werden muss, auf Spindles isoliert bleiben.

Schritt 18: Bestimmen der anfänglichen Spindleanzahl pro Thin Pool

Der erste Thin Pool enthält einen Baustein für 2.700 Postfächer von jedem der vier Postfachserver des primären Datencenters am Standort. In einem vorherigen Schritt wurde bestimmt, dass 10 Spindles zur Unterstützung der IOPS- und Kapazitätsanforderungen des Bausteins erforderlich sind. Der erste Thin Pool zur Unterstützung von 10.800 aktiven Postfächern erfordert 40 Spindles.

Der zweite Thin Pool enthält auch einen Baustein für 2.700 Postfächer von jedem der vier Postfachserver des primären Datencenters am Standort. Der zweite Thin Pool zur Unterstützung von 10.800 passiven Postfächern erfordert 40 Spindles.

Der dritte Thin Pool enthält auch einen Baustein für 2.700 Postfächer von jedem der vier Postfachserver des sekundären Datencenters am Standort (die Server aus einer alternativen DAG, die die Datenbankkopien für die Ausfallsicherheit des Standorts unterstützen). Der dritte Thin Pool zur Unterstützung von 10.800 passiven Postfächern erfordert 40 Spindles.

Insgesamt sind 120 Spindles pro Standort erforderlich, um die anfänglichen Kapazitätsanforderungen für die Datenbanken zu unterstützen.

Schritt 19: Bestimmen der Spindleanzahl pro Thin Pool für die vollständige Bereitstellung

Der erste Thin Pool enthält einen Baustein für 2.700 Postfächer von jedem der vier Postfachserver des primären Datencenters am Standort. In einem vorherigen Schritt wurde bestimmt, dass 25 Spindles zur Unterstützung der IOPS- und Kapazitätsanforderungen für die vollständige Bereitstellung des Bausteins erforderlich sind. Der erste Thin Pool zur Unterstützung von 10.800 aktiven Postfächern erfordert 100 Spindles.

Der zweite Thin Pool enthält auch einen Baustein für 2.700 Postfächer von jedem der vier Postfachserver des primären Datencenters am Standort. Der zweite Thin Pool zur Unterstützung von 10.800 passiven Postfächern erfordert 100 Spindles.

Der dritte Thin Pool enthält auch einen Baustein für 2.700 Postfächer von jedem der vier Postfachserver des sekundären Datencenters am Standort (die Server aus einer alternativen DAG, die die Datenbankkopien für die Ausfallsicherheit des Standorts unterstützen). Der dritte Thin Pool zur Unterstützung von 10.800 passiven Postfächern erfordert 100 Spindles.

Insgesamt sind 300 Spindles pro Standort erforderlich, um die Kapazitätsanforderungen für die vollständige Bereitstellung der Datenbanken zu unterstützen.

Schritt 20: Bestimmen der erforderlichen Spindleanzahl zur Unterstützung aller Protokoll-LUNs

In einem vorherigen Schritt wurde bestimmt, dass jeder Baustein für 2.700 Postfächer zwei Spindles zur Unterstützung der Anforderungen für Protokoll-LUNs erfordert.

Es gibt vier Bausteine, die die aktiven Postfachdatenbanken auf den Postfachservern des primären Datencenters unterstützen. Die Protokoll-LUN, die 10.800 aktive Postfächer unterstützt, erfordert acht Spindles.

Es gibt vier Bausteine, die die passiven Postfachdatenbanken auf den Postfachservern des primären Datencenters unterstützen. Die Protokoll-LUN, die 10.800 passive Postfächer unterstützt, erfordert acht Spindles.

Es gibt vier Bausteine, die die passiven Postfachdatenbanken auf den Postfachservern des sekundären Datencenters unterstützen. Die Protokoll-LUN, die 10.800 passive Postfächer unterstützt, erfordert acht Spindles.

Zur Unterstützung der Anforderungen für Protokoll-LUNs an einem Standort sind 24 Spindles erforderlich.

Schritt 21: Sicherstellen, dass das Speicherarray die anfänglich erforderliche Spindleanzahl unterstützen kann

In diesem Schritt stellen Sie mit der folgenden Berechnung sicher, dass die insgesamt erforderliche Spindleanzahl vom ausgewählten Speicherarray unterstützt werden kann:

• Insgesamt pro Standort erforderliche Spindles = für die Datenbank-LUNs erforderliche Spindles + für die Protokoll-LUNs erforderliche Spindles

  = 120 + 24

  = 144

CX4-480 mit Systemen aus 10 Datenträgerarrays weist 150 Spindles auf und erfüllt diese Anforderungen.

Schritt 22: Bestimmen der erforderlichen Spindleanzahl zur Unterstützung der vollständig bereitgestellten Umgebung

In diesem Schritt berechnen Sie mit der folgenden Berechnung die insgesamt erforderliche Spindleanzahl zur Unterstützung der vollständig bereitgestellten Umgebung:

• Insgesamt pro Standort erforderliche Spindles = für die Datenbank-LUNs erforderliche Spindles + für die Protokoll-LUNs erforderliche Spindles

  = 300 + 24

  = 324

CX4-480 mit Systemen aus 22 Datenträgerarrays weist 330 Spindles auf und erfüllt diese Anforderungen.

Exchange 2010 – Getestete Lösungen

Die Lösung im Überblick

Der vorherige Abschnitt enthält Informationen zu den Entwurfsentscheidungen im Hinblick auf eine Exchange 2010-Lösung. Der folgende Abschnitt enthält einen Überblick über die Lösung.

Exchange 2010 – Getestete Lösungen

Diagramm der logischen Lösung

Diese Lösung besteht aus insgesamt 36 Exchange 2010-Servern, die in einer Topologie mit mehreren Standorten bereitgestellt werden. Auf zwölf der 36 Server werden die Clientzugriffs- und die Hub-Transport-Serverrollen ausgeführt. Auf den anderen 24 Servern wird die Postfachserverrolle ausgeführt. Es gibt ein Clientzugriffsserver-Array mit vier Clientzugriffs- und Hub-Transport-Kombinationsservern an jedem Standort. Es gibt drei DAGs, jeweils mit acht Postfachservern. Die Dateiserver an jedem Standort hosten die primären und alternativen Dateifreigabe-Zeugenserver für jede DAG.

Diagramm der logischen Lösung

Exchange 2010 – Getestete Lösungen

Diagramm der physischen Lösung

Jeder der drei Standorte enthält vier Cisco B200-Bladeserver, die über redundante Cisco Fabric Interconnect 6120- und Cisco MDS 9134-Switches mit einem EMC CLARiiON CX4 Model 480-Speicherarray verbunden sind. Redundante Cisco Nexus 5010 Ethernet-Switches bilden die zugrunde liegende Netzwerkinfrastruktur. Der Lastenausgleich für den Clientdatenverkehr erfolgt über das Clientzugriffsserver-Array an jedem Standort über redundante Cisco ACE 4710-Lastenausgleichgeräte.

Diagramm der physischen Lösung

Exchange 2010 – Getestete Lösungen

Zusammenfassung der Hyper-V-Stammserverkonfiguration

In der folgenden Tabelle wird die in dieser Lösung verwendete physische Serverhardware zusammengefasst.

Cisco Unified Computing System – Zusammenfassung

Element	Beschreibung
Bladeserver	4 × B200 M1
Prozessoren	2 × Intel Zeon x5570 (2,93 GHz)
Arbeitsspeicher	96 GB RAM (12 × 8 GB DIMM)
Konvergierte Netzwerkadapter	M71KR-Q (2 × 10-Gigabit-Ethernet und 2 × 4-GBit/s-Fibre Channel)
Interne Bladespeicher	2 × Datenträger mit 146 GB SAS und 10.000 RPM (RAID-1)
Gehäuse	5108 (6RU)
Fabric-Erweiterung	2 × 2104XP
Fabric Interconnect	2 × 6120XP
Erweiterungsmodul für Fabric Interconnect	2 × Fibre Channel mit 8 Ports und 4 GBit/s

In der folgenden Tabelle wird die in dieser Lösung verwendete Speicher- und Netzwerkhardware zusammengefasst.

LAN- und SAN-Switches

Element	Beschreibung
10-Gigabit-Ethernet-Switch (GbE)	2 × Nexus 5010 (8 feste 1-GbE-/10-GbE-Ports, 12 feste 10-GbE-Ports, Datencenterbridging)
Fibre Channel-Switch	2 × MDS 9134 (32 feste 4-GBit/s-Ports)

Die folgende Tabelle enthält Informationen über die in dieser Lösung verwendete Software.

Zusammenfassung der Software für die Lösung

Element	Beschreibung
Hypervisor-Hostserver	Windows Server 2008 R2 Hyper-V Enterprise
Exchange Server-VMs	Windows Server 2008 R2 Enterprise
Exchange Server 2010-Postfachserverrolle	Enterprise Edition RU2
Exchange Server 2010-Hub-Transport- und -Clientzugriffs-Serverrolle	Standard Edition RU2
Multipfad- und E/A-Ausgleich	EMC PowerPath

Exchange 2010 – Getestete Lösungen

Konfiguration der Clientzugriffs- und Hub-Transport-Server

In der folgenden Tabelle wird die in dieser Lösung verwendete Konfiguration der Clientzugriffs- und Hub-Transport-Kombinationsserver zusammengefasst.

Konfiguration der Clientzugriffs- und Hub-Transport-Server

Komponente	Wert oder Beschreibung
Physisch oder virtuell	Hyper-V-VM
Virtuelle Prozessoren	3
Arbeitsspeicher	8 GB
Speicher	Virtuelle Festplatte auf dem Betriebssystemvolume des Stammservers
Betriebssystem	Windows Server 2008 R2
Exchange-Version	Exchange Server 2010 Standard Edition
Exchange-Updatestufe	Exchange 2010-Updaterollup 2
Software von Drittanbietern	Keine

Exchange 2010 – Getestete Lösungen

Konfiguration der Postfachserver

In der folgenden Tabelle wird die in dieser Lösung verwendete Konfiguration der primären Postfachserver (die die primären und sekundären Datenbankkopien am primären Standort für die DAG hosten) zusammengefasst.

Konfiguration der primären Postfachserver

Komponente	Wert oder Beschreibung
Physisch oder virtuell	Hyper-V-VM
Virtuelle Prozessoren	4
Arbeitsspeicher	53 GB
Speicher	Virtuelle Festplatte auf dem Betriebssystemvolume des Stammservers
Betriebssystem	Windows Server 2008 R2
Exchange-Version	Exchange Server 2010 Enterprise Edition
Exchange-Updatestufe	Exchange 2010-Updaterollup 2
Software von Drittanbietern	Keine

In der folgenden Tabelle wird die in dieser Lösung verwendete Konfiguration der sekundären Postfachserver (die die tertiären Datenbankkopien am sekundären Standort für die DAG hosten) zusammengefasst.

Konfiguration der sekundären Postfachserver

Komponente	Wert oder Beschreibung
Physisch oder virtuell	Hyper-V-VM
Virtuelle Prozessoren	2
Arbeitsspeicher	24 GB
Speicher	Virtuelle Festplatte auf dem Betriebssystemvolume des Stammservers
Betriebssystem	Windows Server 2008 R2
Exchange-Version	Exchange Server 2010 Enterprise Edition
Exchange-Updatestufe	Exchange 2010-Updaterollup 2
Software von Drittanbietern	Keine

Exchange 2010 – Getestete Lösungen

Datenbanklayout

In den folgenden Diagrammen wird das in dieser Lösung verwendete Layout der Datenbankkopien bei normalen Betriebsbedingungen zusammengefasst.

Layout der Datenbankkopien: 1

Layout der Datenbankkopien: 2

Layout der Datenbankkopien: 3

Exchange 2010 – Getestete Lösungen

Zusammenfassung der Speicherhardware

Die folgende Tabelle enthält Informationen über die in dieser Lösung verwendete Speicherhardware.

EMC Unified Storage NS-480 (CLARiiON CX4-480 integriert)

Element	Beschreibung
Speicher	3 CLARiiON CX4-480 (1 pro Standort)
Speicherkonnektivität (Fibre Channel, SAS, SATA, iSCSI)	Fibre Channel
Speichercache	32 GB (600 MB Lesecache und 10.160 MB Schreibcache pro Speicherport)
Anzahl der Speichercontroller	2 pro Speicherframe
Anzahl der verfügbaren oder verwendeten Speicherports	8 (4 pro Speicherport) verfügbar pro Speicherframe, 4 verwendet (2 pro Speicherport)
Maximale Bandbreite der Speicherkonnektivität zum Host	8 × 4 GBit/s
Gesamtanzahl der in der Lösung getesteten Datenträger	432 (360 für Datenbanken und 72 für Protokolle an 3 Standorten)
Maximale Spindleanzahl, die im Speicher gehostet werden kann	480 in einem Speicherarray

Exchange 2010 – Getestete Lösungen

Speicherkonfiguration

Jeder der in dieser Lösung verwendeten CX4 Model 480-Speicherarrays wurde wie in der folgenden Tabelle veranschaulicht konfiguriert.

Speicherkonfiguration

Komponente	Wert oder Beschreibung
Speichersysteme insgesamt	3
Speichersysteme insgesamt pro Standort	1
Datenträger insgesamt pro System	150
Speicherpools insgesamt pro System	3
Datenträger insgesamt pro Speicherpool (anfänglich)	40
Datenträger insgesamt pro Datenbank-LUN (anfänglich)	10
Datenträger insgesamt pro Protokoll-LUN	2
Insgesamt pro System verwendete Datenträger	144
LUN-Größe für die Datenbank (anfänglich)	4.020 GB
LUN-Größe für Protokolle	402 GB
RAID-Stufe für Datenbanken	5
RAID-Stufe für Protokolle	1/0

In der folgenden Tabelle wird veranschaulicht, wie der verfügbare Speicher entworfen und zwischen den drei CX4 Model 480-Speichersystemen zugewiesen wurde.

Speicherkonfiguration zwischen CX4 Model 480-Speichersystemen

Datencenter	DAG	Database	Array1	Array2	Array3
1	1	DB1-24	C1, C2		C3
2	2	DB25-48	C3	C1, C2
3	3	DB49-72		C3	C1, C2

Exchange 2010 – Getestete Lösungen

Methodik zur Überprüfung der Lösung

Überprüfen Sie vor der Bereitstellung einer Exchange-Lösung in einer Produktionsumgebung, ob die Lösung ordnungsgemäß entworfen, dimensioniert und konfiguriert wurde. Die Überprüfung muss Funktionstests umfassen, um sicherzustellen, dass das System wie gewünscht funktioniert. Zudem sind Leistungstests erforderlich, um sicherzustellen, dass das System die gewünschte Benutzerlast verarbeiten kann. In diesem Abschnitt werden die Vorgehensweise und die Testmethodik erläutert, nach der der Server- und Speicherentwurf für diese Lösung überprüft wurde. Insbesondere werden die folgenden Tests im Detail definiert:

• Leistungstests

  • Überprüfung der Speicherleistung (Jetstress)

  • Überprüfung der Serverleistung (Loadgen)

• Funktionstests

  • Überprüfung des Datenbankswitchovers

  • Überprüfung des Serverswitchovers

  • Überprüfung des Serverfailovers

  • Überprüfung des Datencenterswitchovers

Exchange 2010 – Getestete Lösungen

Methodik der Überprüfung des Speicherentwurfs

Das Ausmaß an Leistung und Zuverlässigkeit des Speichersubsystems, das mit der Exchange-Postfachserverrolle verbunden ist, hat beträchtliche Auswirkungen auf den Gesamtstatus der Exchange-Bereitstellung. Zudem führt eine geringe Speicherleistung zu einer hohen Transaktionswartezeit, die primär durch eine schlechte Clientleistung beim Zugriff auf das Exchange-System deutlich wird. Sie können eine möglichst hohe Clientleistung sicherstellen, indem Sie die Speichergröße und -konfiguration mit der in diesem Abschnitt beschriebenen Methode überprüfen.

Tools

Zum Überprüfen der Exchange-Speichergröße und -konfiguration empfiehlt sich das Tool Microsoft Exchange Server Jetstress. Das Jetstress-Tool ist darauf ausgelegt, eine Exchange-E/A-Arbeitslast auf Datenbankebene zu simulieren, indem direkt mit ESE (wird auch als Jet bezeichnet) interagiert wird. ESE ist die Datenbanktechnologie, mit der von Exchange Messagingdaten auf der Postfachserverrolle gespeichert werden. Jetstress kann konfiguriert werden, um den maximalen E/A-Durchsatz zu testen, der für Ihr Speichersubsystem innerhalb der erforderlichen Leistungsbeschränkungen von Exchange zur Verfügung steht. Jetstress kann aber auch ein Zielprofil mit einer Benutzeranzahl und den IOPS pro Benutzer verwenden und überprüfen, ob das Speichersubsystem mit dem Zielprofil eine akzeptable Leistung einhalten kann. Die Testdauer kann angepasst werden, sodass der Test für einen minimalen Zeitraum ausgeführt werden kann, um eine adäquate Leistung zu prüfen, oder für einen längeren Zeitraum, um zudem die Zuverlässigkeit des Speichersubsystems zu testen.

Sie können das Jetstress-Tool im Microsoft Download Center von folgenden Websites herunterladen:

• Microsoft Exchange Server Jetstress 2010 (64 Bit) (möglicherweise in englischer Sprache)

• Microsoft Exchange Server Jetstress 2010 (32 Bit) (möglicherweise in englischer Sprache)

In der zum Jetstress-Installer gehörenden Dokumentation wird beschrieben, wie ein Jetstress-Überprüfungstest auf Ihrer Serverhardware konfiguriert und ausgeführt wird.

Vorgehensweise für die Speicherüberprüfung

Es werden zwei Haupttypen von Speicherkonfigurationen unterschieden:

• DAS- oder interne Datenträgerszenarien

• SAN-Szenarien

In DAS- oder internen Datenträgerszenarien greift nur ein Server auf das Datenträgersubsystem zu. Die Leistungsfähigkeit des Speichersubsystems kann also isoliert überprüft werden.

In SAN-Szenarien kann der von der Lösung verwendete Speicher von vielen Servern gemeinsam genutzt werden, und auch die Infrastruktur, die die Server mit dem Speicher verbindet, kann eine gemeinsame Abhängigkeit sein. Dies erfordert zusätzliche Tests, da die Auswirkungen auf andere Server in der gemeinsam genutzten Infrastruktur adäquat simuliert werden müssen, um Leistung und Funktionalität zu überprüfen.

Testfälle für die Speicherüberprüfung

Die folgenden Testfälle für die Speicherüberprüfung wurden mit der Lösung ausgeführt und sollten als Ausgangspunkt für die Speicherüberprüfung betrachtet werden. Für bestimmte Bereitstellungen können andere Überprüfungsanforderungen gelten, die mit zusätzlichen Tests erfüllt werden können. Diese Liste erhebt keinen Anspruch auf Vollständigkeit:

• Überprüfung des schlimmsten Szenarios bei einem Datenbankswitchover   In diesem Testfall soll der E/A-Umfang vom Speichersubsystem im schlimmsten Switchoverszenario (größtmögliche Anzahl aktiver Kopien auf der geringsten Serveranzahl) verarbeitet werden. Abhängig davon, ob es sich beim Speichersubsystem um DAS oder SAN handelt, muss dieser Test möglicherweise auf mehreren Hosts ausgeführt werden, um sicherzustellen, dass die komplette Lösungslast im Speichersubsystem aufrecht erhalten werden kann.

• Überprüfung der Speicherleistung bei Speicherausfall oder -wiederherstellung (beispielsweise Austausch und Neuerstellung eine ausgefallenen Datenträgers)   In diesem Testfall wird die Leistung des Speichersubsystems während eines Ausfalls und einer Neuerstellung bewertet, um sicherzustellen, dass die erforderliche Leistung für optimale Exchange-Clientleistung gewahrt wird. Die gleiche Einschränkung gilt für die Bereitstellung von DAS oder SAN: Wenn mehrere Hosts von einem freigegebenen Speichersubsystem abhängig sind, muss der Test Lasten dieser Hosts umfassen, um die vollständigen Auswirkungen des Ausfalls oder der Neuerstellung zu simulieren.

Analysieren der Ergebnisse

Das Jetstress-Tool erstellt eine Berichtsdatei, nachdem die Tests abgeschlossen sind. Verwenden Sie für die Analyse des Berichts die Richtlinien unter Jetstress 2010 Test Summary Reports.

Insbesondere sollten Sie die Richtlinien in der folgenden Tabelle verwenden, wenn Sie die Daten in der Tabelle mit den Testergebnissen im Bericht analysieren.

Jetstress-Ergebnisanalyse

Leistungsindikatorinstanz	Richtlinien für den Leistungstest
E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (ms)	Der Durchschnittswert sollte unter 20 Millisekunden (ms) (0,020 Sekunden) liegen, und die Höchstwerte sollten weniger als 50 ms betragen.
E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen (ms)	Schreibvorgänge auf den Protokolldatenträger erfolgen sequenziell, die Schreibwartezeit sollte also unter 10 ms liegen, der Höchstwert sollte nicht mehr als 50 ms betragen.
% Prozessorzeit	Der Durchschnitt sollte unter 80 % liegen, und der Höchstwert sollte nicht mehr als 90 % betragen.
Übergangsseiten mit neuem Zweck/s (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2)	Der Durchschnitt sollte kleiner als 100 sein.

Die Berichtsdatei zeigt verschiedene E/A-Kategorien, die vom Exchange-System durchgeführt werden:

• E/A-Transaktionsleistung   Diese Tabelle enthält E/A, die Benutzeraktivitäten in der Datenbank darstellen (beispielsweise von Outlook generierter E/A). Diese Daten werden generiert, indem E/A für Hintergrundwartung und Protokollreplikation vom während des Tests insgesamt gemessenen E/A abgezogen werden. Diese Daten stellen die tatsächlich generierte Datenbank-IOPS zusammen mit den E/A-Wartezeitmessungen bereit, um zu bestimmen, ob ein Jetstress-Leistungstest bestanden wurde.

• E/A-Leistung der Datenbankwartung im Hintergrund   Diese Tabelle enthält E/A, die aufgrund von permanenter ESE-Datenbankwartung im Hintergrund generiert wird.

• E/A-Leistung der Protokollreplikation   Diese Tabelle enthält E/A, die durch simulierte Protokollreplikation generiert wird.

• E/A-Leistung insgesamt   Diese Tabelle enthält die gesamte E/A, die während des Jetstress-Tests generiert wurde.

Exchange 2010 – Getestete Lösungen

Überprüfung des Serverentwurfs

Nachdem Leistung und Zuverlässigkeit des Speichersubsystems überprüft wurden, stellen Sie sicher, dass alle Komponenten im Messagingsystem gemeinsam auf Funktionalität, Leistung und Skalierbarkeit überprüft werden. Dies bedeutet, einen Schritt weiter zu gehen und die Interaktion der Clientsoftware mit dem Exchange-Produkt und der Produkte auf dem Server, die mit Exchange interagieren, zu überprüfen. Um sicherzustellen, dass die gesamte Clientleistung akzeptabel ist und dass die gesamte Lösung die gewünschte Benutzerlast unterstützen kann, können Sie die in diesem Abschnitt beschriebene Methode für die Überprüfung des Serverentwurfs angewenden.

Tools

Zur Überprüfung der Leistung und Skalierbarkeit der gesamten Lösung empfiehlt sich das Tool Microsoft Exchange Server Load Generator (Loadgen). Loadgen ist dafür konzipiert, eine simulierte Clientarbeitslast in einer Exchange-Bereitstellung zu simulieren. Diese Arbeitslast kann verwendet werden, um die Leistung des Exchange-Systems auszuwerten. Sie kann auch dazu eingesetzt werden, die Auswirkungen verschiedener Konfigurationsänderungen auf die Gesamtlösung unter Systemlast auszuwerten. Mit Loadgen können Clientaktivitäten aus den folgenden Bereichen simuliert werden: Microsoft Office Outlook 2007 (online und zwischengespeichert), Office Outlook 2003 (online und zwischengespeichert), POP3, IMAP4, SMTP, ActiveSync und Outlook Web App (wurde in Exchange 2007 und früheren Versionen als Outlook Web Access bezeichnet). Mit dem Tool kann die Arbeitslast eines einzelnen Protokolls generiert werden. Diese Clientprotokolle können aber auch kombiniert werden, um die Arbeitslast mehrerer Protokolle zu generieren.

Sie können das Loadgen-Tool im Microsoft Download Center von folgenden Websites herunterladen:

• Exchange Load Generator 2010 (64 Bit) (möglicherweise in englischer Sprache)

• Exchange Load Generator 2010 (32 Bit)(möglicherweise in englischer Sprache)

In der zum Loadgen-Installer gehörenden Dokumentation wird beschrieben, wie ein Loadgen-Test für eine Exchange-Bereitstellung konfiguriert und ausgeführt wird.

Vorgehensweise für die Serverüberprüfung

Testen Sie bei der Überprüfung des Serverentwurfs den schlimmsten Fall mit der erwarteten Spitzenlast. Basierend auf einer Reihe von Datasets von Microsoft IT und anderen Kunden entspricht die Spitzenlast im Allgemeinen der doppelten durchschnittlichen Arbeitslast während des restlichen Arbeitstags. Dies wird als Verhältnis von Spitzen- zu Durchschnittslast bezeichnet.

Systemmonitor

In dieser Momentaufnahme des Systemmonitors, in der verschiedene Leistungsindikatoren dargestellt sind, die den Umfang der Exchange-Arbeit auf einem Produktionspostfachserver für einen Zeitraum zeigen, beträgt der Durchschnittswert für RPC-Vorgänge pro Sekunde (die markierte Linie) etwa 2.386, wenn dieser Wert für einen ganzen Tag bestimmt wird. Der Durchschnitt für diesen Leistungsindikator während der Spitzenauslastung von 10:00 bis 11:00 beträgt etwa 4.971. Dies entspricht einem Verhältnis von Spitzen- zu Durchschnittslast von 2,08.

Um sicherzustellen, dass die Exchange-Lösung die als durchschnittliche Spitzenlast generierte Arbeitslast verarbeiten kann, ändern Sie die Loadgen-Einstellungen, um eine konstante Last in der Höhe der durchschnittlichen Spitzenlast zu generieren, statt die Arbeitslast über den ganzen simulierten Arbeitstag zu verteilen. Die aufgabenbasierten Loadgen-Simulationsmodule (wie die Outlook-Simulationsmodule) nutzt ein Aufgabenprofil, in dem definiert ist, wie häufig jede Aufgabe für einen durchschnittlichen Benutzer an einem simulierten Arbeitstag erfolgt.

Die Gesamtanzahl der Aufgaben, die während eines simulierten Tags ausgeführt werden müssen, wird aus der Anzahl der Benutzer multipliziert mit der Summe der Aufgaben im konfigurierten Aufgabenprofil berechnet. Loadgen bestimmt dann die Rate, mit der Aufgaben für die konfigurierte Benutzergruppe ausgeführt werden müssen, indem die Gesamtanzahl der am simulierten Tag auszuführenden Aufgaben durch die Länge des simulierten Tags geteilt wird. Wenn Loadgen z. B. 1.000.000 Aufgaben an einem simulierten Tag ausführen muss und ein simulierter Tag 8 Stunden (28.800 Sekunden) entspricht, muss Loadgen 1.000.000 ÷ 28.800 = 34,72 Aufgaben pro Sekunde ausführen, um die erforderliche Arbeitslastdefinition zu erfüllen. Um die Last auf die gewünschte durchschnittliche Spitzenlast zu erhöhen, teilen Sie die simulierte Standardtageslänge (8 Stunden) durch das Verhältnis Spitzen- zu Durchschnittslast (2) und verwenden diesen Wert als neue simulierte Tageslänge.

Wieder unter Nutzung des Beispiels für die Aufgabenrate: 1.000.000 ÷ 14.400 = 69,44 Aufgaben pro Sekunde. Dadurch wird die simulierte Tageslänge halbiert, die tatsächliche Arbeitslast auf dem Server verdoppelt und das Ziel der durchschnittlichen Spitzenlast erreicht. Sie passen nicht die Dauer der Ausführung des Tests in der Loadgen-Konfiguration an. Mit der Dauer der Ausführung wird die Dauer des Tests angegeben. Sie hat keine Auswirkungen auf die Rate, mit der Aufgaben auf dem Exchange-Server ausgeführt werden.

Testfälle für die Überprüfung des Serverentwurfs

Die folgenden Testfälle für die Überprüfung des Serverentwurfs wurden mit der Lösung ausgeführt und sollten als Ausgangspunkt für die Überprüfung des Serverentwurfs betrachtet werden. Für bestimmte Bereitstellungen können andere Überprüfungsanforderungen gelten, die mit zusätzlichen Tests erfüllt werden können. Diese Liste erhebt keinen Anspruch auf Vollständigkeit:

• Normale Betriebsbedingungen   In diesem Testfall wird der grundlegende Entwurf der Lösung mit allen Komponenten in normalem Betriebszustand (ohne simulierte Ausfälle) überprüft. Die gewünschte Arbeitslast wird in der Lösung getestet, und die Gesamtleistung der Lösung wird anhand der im Folgenden aufgeführten Metriken überprüft.

• Ausfall oder Wartung eines Servers (am Standort)   In diesem Testfall wird ein Server offline genommen, um einen unerwarteten Ausfall des Servers oder eine geplante Wartung des Servers zu simulieren. Die Arbeitslast, die normalerweise vom nicht verfügbaren Server verarbeitet werden würde, wird jetzt von anderen Servern in der Lösungstopologie verarbeitet, und die Gesamtleistung der Lösung wird überprüft.

Testausführung und Datensammlung

Die Exchange-Leistungsdaten weisen natürliche Abweichungen innerhalb und zwischen Testläufen auf. Es wird empfohlen, dass Sie den Durchschnittswert aus mehreren Testläufen heranziehen, um diese Abweichungen auszugleichen. Für die getesteten Exchange-Lösungen wurden mindestens drei unabhängige Testläufe mit einer Dauer von je acht Stunden durchgeführt. Leistungsdaten wurden für die volle Dauer des Tests von acht Stunden gesammelt. Zusammenfassende Leistungsdaten wurden aus einem drei- bis vierstündigen stabilen Zeitraum entnommen (ohne die ersten beiden Stunden und die letzte Stunde des Tests). Für jede Exchange-Serverrolle wurde für die zusammenfassenden Leistungsdaten der Durchschnittswert der Server für jeden Testlauf gebildet, sodass ein Durchschnittswert für jeden Datenpunkt zur Verfügung steht. Aus den Werten für jeden Testlauf wurde dann der Durchschnitt gebildet, sodass ein Datenpunkt für alle Server einer Serverrolle in allen Testläufen zur Verfügung steht.

Überprüfung der erwarteten Last

Überprüfen Sie, ob die erwartete Arbeitslast mit der tatsächlich ausgeführten Arbeitslast übereinstimmt, bevor Sie Leistungsindikatoren betrachten oder eine Analyse zur Leistungsüberprüfung beginnen. Es gibt zwar viele Möglichkeiten zu bestimmen, ob die simulierte Arbeitslast mit der erwarteten Arbeitslast übereinstimmt, am einfachsten und konsequentesten ist es, dafür die Nachrichtenzustellungsrate zu verwenden.

Berechnen der erwarteten Spitzenrate für die Nachrichtenzustellung

Jedes Nachrichtenprofil besteht aus der Summe der durchschnittlichen Anzahl von pro Tag gesendeten und empfangenen Nachrichten. Wählen Sie zur Berechnung der Nachrichtenzustellungsrate die durchschnittliche Anzahl von pro Tag empfangenen Nachrichten aus der folgenden Tabelle aus.

Spitzenrate für die Nachrichtenzustellung

Nachrichtenprofil	Pro Tag gesendete Nachrichten	Pro Tag empfangene Nachrichten
50	10	40
100	20	80
150	30	120
200	40	160

Im folgenden Beispiel wird davon ausgegangen, dass jeder Postfachserver 5.000 aktive Postfächer mit einem Profil von 150 Nachrichten pro Tag (30 gesendete und 120 empfangene Nachrichten pro Tag) aufweist.

Spitzenraten für die Nachrichtenzustellung für 5.000 aktive Postfächer

Beschreibung	Berechnung	Wert
Nachrichtenprofil	Anzahl der pro Tag empfangenen Nachrichten	120
Anzahl der aktiven Postfächer pro Postfachserver	Nicht zutreffend	5000
Gesamtanzahl der pro Tag pro Postfachserver empfangenen Nachrichten	5000 × 120	600000
Gesamtanzahl der pro Sekunde pro Postfachserver empfangenen Nachrichten	600000 ÷ 28800	20,83
Für die Spitzenlast angepasste Gesamtanzahl von Nachrichten	20,83 × 2	41,67

Sie erwarten, dass pro Sekunde 41,67 Nachrichten auf jedem Postfachserver mit 5.000 aktiven Postfächern mit einem Nachrichtenprofil von 150 Nachrichten pro Tag während der Spitzenlast zugestellt werden.

Messen der tatsächlichen Nachrichtenzustellungsrate

Die tatsächliche Nachrichtenzustellungsrate kann mit dem folgenden Leistungsindikator auf jedem Postfachserver gemessen werden: MSExchangeIS Postfach(_Total)\Pro Sekunde zugestellte Nachrichten. Wenn die gemessene Nachrichtenzustellungsrate nur um eine oder zwei Nachrichten pro Sekunde von der geplanten Nachrichtenzustellungsrate abweicht, können Sie davon ausgehen, dass das gewünschte Lastprofil erfolgreich ausgeführt wurde.

Serverüberprüfung: Leistungs- und Statuskriterien

In diesem Abschnitt werden die Leistungsindikatoren und Schwellenwerte des Systemmonitors beschrieben, mit denen bestimmt wird, ob die Exchange-Umgebung richtig dimensioniert wurde und auch während längerer Zeiträume unter Spitzenlast in einem fehlerfreien Zustand ausgeführt wird. Weitere Informationen zu den für die Exchange-Leistung relevanten Leistungsindikatoren finden Sie unter Leistungs- und Skalierbarkeitsindikatoren und -schwellenwerte.

Hyper-V-Stammserver

Um die Leistungs- und Statuskriterien eines Hyper-V-Stammservers und der auf VMs ausgeführten Anwendungen zu überprüfen, müssen Sie über grundlegende Kenntnisse im Hinblick auf die Hyper-V-Architektur und deren Auswirkungen auf die Leistungsüberwachung verfügen.

Hyper-V besteht aus drei Hauptkomponenten: Virtualisierungsstapel, Hypervisor und Geräte. Der Virtualisierungsstapel verarbeitet emulierte Geräte sowie E/A und verwaltet VMs. Der Hypervisor plant virtuelle Prozessoren, verwaltet Interrupts, verarbeitet Zeitgeber und steuert andere Chipfunktionen. Der Hypervisor verarbeitet Geräte oder E/A nicht (es gibt z. B. keine Hypervisortreiber). Die Geräte sind Bestandteil des Stammservers oder im Rahmen von Integrationsdiensten auf Gastservern installiert. Da der Stammserver einen vollständigen Überblick über das System hat und die VMs steuert, stellt er auch Überwachungsinformationen über die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) und Leistungsindikatoren bereit.

Prozessor

Bei der Überprüfung der physischen Prozessorauslastung auf dem Stammserver (oder auf der Gast-VM) ist der standardmäßige Leistungsindikator "Prozessor\% Prozessorzeit" nicht besonders nützlich.

Stattdessen können Sie den Leistungsindikator "Logischer Prozessor für Hyper-V-Hypervisor\% Gesamtausführungszeit" verwenden. Dieser Leistungsindikator zeigt den Prozentsatz der Prozessorzeit, die für die Gast- und Hypervisorausführungszeit aufgewendet wurde. Er wird dazu verwendet, die gesamte Prozessorauslastung für den Hypervisor und alle VMs auf dem Stammserver zu messen. Dieser Leistungsindikator sollte 80 Prozent bzw. das von Ihnen festgelegte maximale Auslastungsziel nicht überschreiten.

Leistungsindikator	Ziel
Logischer Prozessor für Hyper-V-Hypervisor\% Gesamtausführungszeit	< 80 %

Wenn Sie wissen möchten, welcher Prozentsatz der Prozessorzeit für die Gast-VMs aufgewendet wird, können Sie den Leistungsindikator "Logischer Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit" untersuchen. Wenn Sie wissen möchten, welcher Prozentsatz der Prozessorzeit für den Hypervisor aufgewendet wird, können Sie den Leistungsindikator "Logischer Prozessor für Hyper-V-Hypervisor\% Hypervisorausführungszeit" untersuchen. Dieser Leistungsindikator sollte kleiner als 5 Prozent sein. Der Leistungsindikator "Virtueller Prozessor des Hyper-V-Hypervisorstamms\% Gastausführungszeit" zeigt den Prozentsatz der Prozessorzeit für den Virtualisierungsstapel. Dieser Leistungsindikator sollte ebenfalls unter 5 Prozent liegen. Mit diesen beiden Leistungsindikatoren können Sie bestimmen, welcher Prozentsatz der verfügbaren physischen Prozessorzeit für die Unterstützung der Virtualisierung genutzt wird.

Leistungsindikator	Ziel
Logischer Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 80 %
Logischer Prozessor für Hyper-V-Hypervisor\% Hypervisorausführungszeit	< 5 %
Virtueller Prozessor des Hyper-V-Hypervisorstamms\% Gastausführungszeit	< 5 %

Arbeitsspeicher

Sie müssen sicherstellen, dass der Hyper-V-Stammserver über ausreichend Arbeitsspeicher verfügt, um den den VMs zugewiesenen Arbeitsspeicher zu unterstützen. Hyper-V reserviert automatisch 512 MB (dieser Wert kann je nach Hyper-V-Version abweichen) für das Stammbetriebssystem. Wenn Sie nicht über ausreichend Arbeitsspeicher verfügen, verhindert Hyper-V, dass die letzte VM startet. Im Allgemeinen müssen Sie sich über die Überprüfung des Arbeitsspeichers auf einem Hyper-V-Stammserver keine Gedanken machen. Wichtiger ist es sicherzustellen, dass den VMs ausreichend Arbeitsspeicher zugewiesen ist, um die Exchange-Rollen zu unterstützen.

Anwendungsstatus

Eine einfache Methode, den fehlerfreien Status aller VMs zu ermitteln, ist die Analyse der Leistungsindikatoren "Hyper-V - Integritätszusammenfassung für virtuelle Computer".

Leistungsindikator	Ziel
Hyper-V - Statuszusammenfassung für virtuelle Computer\Status OK	1
Hyper-V - Statuszusammenfassung für virtuelle Computer\Status kritisch	0

Postfachserver

Konzentrieren Sie sich bei der Überprüfung der richtigen Dimensionierung eines Postfachservers auf Prozessor-, Arbeitsspeicher-, Speicher- und Exchange-Anwendungsstatus. In diesem Abschnitt wird die Vorgehensweise zum Überprüfen jeder dieser Komponenten beschrieben.

Prozessor

Beim Entwurf haben Sie die angepasste Megazykluskapazität der Server- oder Prozessorplattform berechnet. Sie haben dann die maximale Anzahl aktiver Postfächer bestimmt, die vom Server unterstützt werden können, ohne 80 Prozent der verfügbaren Megazykluskapazität zu überschreiten. Sie haben zudem die prognostizierte CPU-Auslastung bei normalen Betriebsbedingungen und während verschiedener Szenarien von Serverwartung oder -ausfällen bestimmt.

Stellen Sie während der Überprüfung sicher, dass die Arbeitslast im schlimmsten Szenario 80 Prozent der verfügbaren Megazyklen nicht überschreitet. Überprüfen Sie außerdem, dass die tatsächliche CPU-Auslastung annähernd die erwartete CPU-Auslastung bei normalen Betriebsbedingungen und während der verschiedenen Szenarien von Serverwartung oder -ausfällen erreicht.

Verwenden Sie in physischen Exchange-Bereitstellungen den Leistungsindikator "Prozessor(_Total)\% Prozessorzeit", und stellen Sie sicher, dass dieser Leistungsindikator im Durchschnitt weniger als 80 Prozent beträgt.

Leistungsindikator	Ziel
Prozessor(_Total)\Prozessorzeit (%)	< 80 %

Bei virtuellen Exchange-Bereitstellungen wird der Leistungsindikator "Prozessor(_Total)\% Prozessorzeit" in der VM gemessen. In diesem Fall misst der Leistungsindikator nicht die physische CPU-Auslastung. Er misst die Auslastung der vom Hypervisor bereitgestellten virtuellen CPU. Er bietet daher keinen genauen Wert für den physischen Prozessor und sollte zur Überprüfung des Entwurfs nicht verwendet werden. Weitere Informationen finden Sie unter Hyper-V: Zuverlässige Leistungsindikatoren (möglicherweise in englischer Sprache).

Verwenden Sie zur Überprüfung von Exchange-Bereitstellungen unter Microsoft Hyper-V den Leistungsindikator "Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit". Er liefert einen genaueren Wert für den Umfang der physischen CPU, der vom Gastbetriebssystem genutzt wird. Dieser Leistungsindikator sollte im Durchschnitt kleiner als 80 Prozent sein.

Leistungsindikator	Ziel
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 80 %

Arbeitsspeicher

Während des Entwurfs haben Sie die erforderliche Größe des Datenbankcache berechnet, um die maximale Anzahl von aktiven Datenbanken auf jedem Postfachserver zu unterstützen. Sie haben dann die optimale Konfiguration des physischen Arbeitsspeichers bestimmt, um die Anforderungen an Datenbankcache und Systemarbeitsspeicher zu unterstützen.

Es ist keine einfache Aufgabe zu überprüfen, ob ein Exchange-Postfachserver über ausreichend Arbeitsspeicher für die geplante Arbeitslast verfügt. Es ist nicht hilfreich, mit den verfügbaren Leistungsindikatoren für den Speicher den verbleibenden physischen Arbeitspeicher zu bestimmen, da der Speicher-Manager in Exchange darauf ausgelegt ist, fast den gesamten verfügbaren physischen Arbeitsspeicher zu nutzen. Der Informationsspeicher (store.exe) reserviert einen großen Teil des physischen Arbeitsspeichers für den Datenbankcache. Der Datenbankcache wird zum Speichern von Datenbankseiten im Arbeitsspeicher verwendet. Wenn auf eine Seite im Arbeitsspeicher zugegriffen wird, müssen die Daten nicht vom Datenträger abgerufen werden, und Lese-E/A wird so reduziert. Der Datenbankcache wird auch verwendet, um Schreib-E/A zu optimieren.

Wenn eine Datenbankseite geändert wird (wird auch als modifizierte Seite bezeichnet), bleibt die Seite für eine bestimmte Zeit im Cache. Je länger sie im Cache bleibt, desto größer ist die Wahrscheinlichkeit, dass die Seite mehrfach geändert wird, bevor diese Änderungen auf den Datenträger geschrieben werden. Modifizierte Seiten im Cache zu behalten, führt auch dazu, dass mehrere Seiten in einem Vorgang auf den Datenträger geschrieben werden (wird auch als zusammengeführte Schreibvorgänge bezeichnet). Exchange nutzt so viel des verfügbaren Arbeitsspeichers im System wie möglich. Daher gibt es auf einem Exchange-Postfachserver nicht viel verfügbaren Arbeitsspeicher.

Möglicherweise kann nicht leicht festgestellt werden, ob die Konfiguration des Arbeitsspeichers auf dem Exchange-Postfachserver zu klein dimensioniert ist. In den meisten Fällen funktioniert der Postfachserver trotzdem, nur kann das E/A-Profil höher als erwartet ausfallen. Höherer E/A kann auf dem Datenträger zu längeren Wartezeiten beim Lesen und Schreiben führen und dadurch den Anwendungsstatus und die Benutzerfreundlichkeit des Clients beeinträchtigen. Im Ergebnisabschnitt gibt es keine Hinweise auf Leistungsindikatoren für den Arbeitsspeicher. Mögliche Arbeitsspeicherprobleme werden in den Ergebnisabschnitten zur Speicherüberprüfung und zum Anwendungsstatus identifiziert, in denen Probleme im Zusammenhang mit dem Arbeitsspeicher leichter festgestellt werden können.

Speicher

Leistungsprobleme mit dem Exchange-Postfachserver können durch Probleme mit dem Speicher verursacht werden. Speicherprobleme können folgende Ursachen haben: Unzureichende Anzahl von Datenträgern für die geplanten E/A-Anforderungen, überlastete oder schlecht konzipierte Infrastruktur für Speicherverbindungen oder Faktoren, die das geplante E/A-Profil ändern, beispielsweise zu wenig Arbeitsspeicher, wie bereits erläutert.

Der erste Schritt bei der Speicherüberprüfung ist sicherzustellen, dass die Datenbankwartezeiten unter den Zielschwellenwerten liegen. In früheren Versionen wurde mit Leistungsindikatoren für logische Datenträger die Wartezeit beim Lesen und Schreiben ermittelt. In Exchange 2010 weist der Exchange-Postfachserver, den Sie überwachen, wahrscheinlich gleichzeitig aktive und passive Postfachdatenbankkopien auf. Die E/A-Eigenschaften der aktiven und passiven Datenbankkopien unterscheiden sich. Da die E/A für passive Kopien deutlich größer ist, sind die Wartezeiten bei passiven Kopien normalerweise viel länger. Zielwerte für die Wartezeit bei passiven Datenbanken sind 200 ms, dies ist das Zehnfache der Zielwerte bei aktiven Datenbankkopien. Dies ist kein großes Problem, da lange Wartezeiten bei passiven Datenbanken keine Auswirkungen auf die Clientleistung haben. Wenn Sie jedoch die herkömmlichen Leistungsindikatoren für logische Datenträger zur Messung der Wartezeiten verwenden, müssen Sie die einzelnen Volumes prüfen und Volumes mit aktiven und passiven Datenbanken trennen. Es empfiehlt sich, stattdessen die neuen MSExchange-Datenbank-Leistungsindikatoren in Exchange 2010 zu verwenden.

Bei der Überprüfung der Wartezeiten auf Exchange 2010-Postfachservern sollten Sie die in der folgenden Tabelle aufgeführten Leistungsindikatoren für aktive Datenbanken verwenden.

Leistungsindikator	Ziel
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (angefügt)	< 20 ms
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (angefügt)	< 20 ms
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen	< 1 ms

Sie sollten die in der folgenden Tabelle aufgeführten Leistungsindikatoren für passive Datenbanken verwenden.

Leistungsindikator	Ziel
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (Wiederherstellung)	< 200 ms
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (Wiederherstellung)	< 200 ms
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollleseoperationen	< 200 ms

Wenn Sie Datenträgerwartezeiten für Exchange-Bereitstellungen unter Microsoft Hyper-V überprüfen, bedenken Sie, dass die Leistungsindikatoren vom Typ "E/A: Durchschnittliche Wartezeit für Datenbankoperationen" (wie viele andere zeitbasierte Leistungsindikatoren) möglicherweise nicht genau sind, da sich das Konzept von Zeit in VMs von dem auf physischen Servern unterscheidet. Das folgende Beispiel zeigt, dass "E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (Angefügt)" für die gleiche simulierte Arbeitslast in der VM 22,8 und auf einem physischen Server 17,3 beträgt. Wenn die Werte zeitbasierter Leistungsindikatoren über den Zielschwellenwerten liegen, kann der Server richtig ausgeführt werden. Prüfen Sie alle Statuskriterien, um eine Entscheidung hinsichtlich des Serverstatus zu treffen, wenn die Postfachserverrolle in einer VM bereitgestellt wird.

Werte der Leistungsindikatoren für die Datenträgerwartezeit für virtuelle und physische Postfachserver

Leistungsindikator	Virtueller Postfachserver	Physischer Postfachserver
MSExchange-Datenbank/
E/A: Datenbankleseoperationen (Angefügt) / Durchschnittliche Wartezeit	22,792	17,250
E/A: Datenbankleseoperationen (Angefügt)/Sek.	17,693	18,131
E/A: Datenbankleseoperationen (Wiederherstellung) / Durchschnittliche Wartezeit	34,215	27,758
E/A: Datenbankschreiboperationen (Wiederherstellung)/Sek.	10,829	8,483
E/A: Datenbankschreiboperationen (Angefügt) / Durchschnittliche Wartezeit	0,944	0,411
E/A: Datenbankschreiboperationen (Angefügt)/Sek.	10,184	10,963
MSExchangeIS
Durchschnittl. RPC-Wartezeit	1,966	1,695
RPC-Operationen/Sekunde	334,371	341,139
RPC-Pakete/Sek.	180,656	183,360
MSExchangeIS Mailbox
Zugestellte Nachrichten/Sek.	2,062	2,065
Gesendete Nachrichten/Sek.	0,511	0,514

Prüfen Sie zusätzlich zu den Datenträgerwartezeiten den Leistungsindikator "Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.". Dieser Leistungsindikator gibt die Rate an Seitenfehlern an, die nicht bearbeitet werden können, weil keine Seiten für die Zuweisung vom Datenbankcache verfügbar sind. Dieser Leistungsindikator sollte auf fehlerfreien Servern 0 betragen.

Leistungsindikator	Ziel
Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.	< 1

Prüfen Sie auch den Leistungsindikator "Datenbank\Protokolldatensatzverzögerungen/Sek.", der die Anzahl von Protokolldatensätzen angibt, die den Protokollpuffern nicht pro Sekunde hinzugefügt werden können, da die Protokollpuffer voll sind. Dieser Leistungsindikator sollte im Durchschnitt kleiner als 10 sein.

Leistungsindikator	Ziel
Datenbank\Protokolldatensatzverzögerungen/Sek.	< 10

Exchange-Anwendungsstatus

Auch wenn es keine offensichtlichen Probleme mit Prozessor, Arbeitsspeicher und Datenträger gibt, empfehlen wir die Überwachung der standardmäßigen Leistungsindikatoren für den Anwendungsstatus, um sicherzustellen, dass der Exchange-Postfachserver einen fehlerfreien Status aufweist.

Der Leistungsindikator "MSExchangeIS\Durchschnittl. RPC-Wartezeit" liefert den besten Anhaltspunkt, ob andere Leistungsindikatoren mit langen Datenbankwartezeiten Status und Clientleistung von Exchange tatsächlich beeinträchtigen. Häufig sind lange durchschnittliche RPC-Wartezeiten mit einer großen Anzahl von RPC-Anforderungen verbunden, die immer unter 70 liegen sollten.

Leistungsindikator	Ziel
MSExchangeIS\Durchschnittl. RPC-Wartezeit	< 10 ms im Durchschnitt
MSExchangeIS\RPC-Anforderungen	immer < 70

Stellen Sie als Nächstes sicher, dass die Transportschicht fehlerfrei ist. Alle Probleme beim oder nach dem Transport, die Einfluss auf die Transportschicht haben, können mit dem Leistungsindikator "MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten" ermittelt werden. Der Wert dieses Leistungsindikators sollte immer unter 50 liegen. Dieser Leistungsindikator kann vorübergehend ansteigen, aber der Wert sollte nicht mit der Zeit zunehmen und für mehr als 15 Minuten bestehen bleiben.

Leistungsindikator	Ziel
MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten	immer < 50

Stellen Sie als Nächstes sicher, dass die Wartung der Datenbankkopien in einem fehlerfreien Zustand ist. Alle Probleme mit Protokollversand oder -wiedergabe können mit den Leistungsindikatoren "MSExchange-Replikation(*)\CopyQueueLength" und "MSExchange-Replikation(*)\ReplayQueueLength" ermittelt werden. Die Länge der Kopiewarteschlange zeigt die Anzahl der Transaktionsprotokolldateien an, die darauf warten, in den Protokolldateiordner für passive Kopien kopiert zu werden. Der Wert sollte immer kleiner als 1 sein. Die Länge der Wiedergabewarteschlange zeigt die Anzahl der Transaktionsprotokolldateien an, die darauf warten, in die passive Kopie der Datenbank wiedergegeben zu werden. Der Wert sollte kleiner als 5 sein. Höhere Werte haben keinen Einfluss auf die Clientleistung, führen aber bei einer Übergabe, einem Failover oder einer Aktivierung zu längeren Einbindungszeiten des Informationsspeichers.

Leistungsindikator	Ziel
MSExchange-Replikation(*)\CopyQueueLength	< 1
MSExchange-Replikation(*)\ReplayQueueLength	< 5

Clientzugriffsserver

Um zu ermitteln, ob ein Clientzugriffsserver fehlerfrei ist, prüfen Sie Prozessor-, Arbeitsspeicher- und Anwendungsstatus. Eine erweiterte Liste wichtiger Leistungsindikatoren finden Sie unter Leistungsindikatoren für Clientzugriffsserver.

Prozessor

Verwenden Sie für physische Exchange-Bereitstellungen den Leistungsindikator "Prozessor(_Total)\% Prozessorzeit". Dieser Leistungsindikator sollte im Durchschnitt kleiner als 80 Prozent sein.

Leistungsindikator	Ziel
Prozessor(_Total)\Prozessorzeit (%)	< 80 %

Verwenden Sie zur Überprüfung von Exchange-Bereitstellungen unter Microsoft Hyper-V den Leistungsindikator "Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit". Er liefert einen genauen Wert für den Umfang der physischen CPU, der vom Gastbetriebssystem genutzt wird. Dieser Leistungsindikator sollte im Durchschnitt kleiner als 80 Prozent sein.

Leistungsindikator	Ziel
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 80 %

Anwendungsstatus

Um zu bestimmen, ob die Leistung der MAPI-Clients akzeptabel ist, verwenden Sie den Leistungsindikator "MSExchange RpcClientAccess\Durchschnittl. RPC-Wartezeit". Dieser Leistungsindikator sollte kleiner als 250 ms sein. Lange Wartezeiten können mit einer großen Anzahl von RPC-Anforderungen verbunden sein. Der Leistungsindikator "MSExchange RpcClientAccess\RPC-Anforderungen" sollte im Durchschnitt unter 40 liegen.

Leistungsindikator	Ziel
MSExchange RpcClientAccess\Durchschnittl. RPC-Wartezeit	< 250 ms
MSExchange RpcClientAccess\RPC-Anforderungen	< 40

Transportserver

Um zu ermitteln, ob ein Transportserver fehlerfrei ist, prüfen Sie Prozessor-, Datenträger- und Anwendungsstatus. Eine erweiterte Liste wichtiger Leistungsindikatoren finden Sie unter Leistungsindikatoren für Transport-Server.

Prozessor

Verwenden Sie für physische Exchange-Bereitstellungen den Leistungsindikator "Prozessor(_Total)\% Prozessorzeit". Dieser Leistungsindikator sollte im Durchschnitt kleiner als 80 Prozent sein.

Leistungsindikator	Ziel
Prozessor(_Total)\Prozessorzeit (%)	< 80 %

Verwenden Sie zur Überprüfung von Exchange-Bereitstellungen unter Microsoft Hyper-V den Leistungsindikator "Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit". Er liefert einen genauen Wert für den Umfang der physischen CPU, der vom Gastbetriebssystem genutzt wird. Dieser Leistungsindikator sollte im Durchschnitt kleiner als 80 Prozent sein.

Leistungsindikator	Ziel
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 80 %

Datenträger

Um zu bestimmen, ob die Datenträgerleistung akzeptabel ist, verwenden Sie die Leistungsindikatoren "Logischer Datenträger(*)\Mittlere Sek./Leseoperationen" und "Logischer Datenträger(*)\Mittlere Sek./Schreiboperationen" für Volumes mit den Transportprotokollen und der Datenbank. Beide Leistungsindikatoren sollten weniger als 20 ms betragen.

Leistungsindikator	Ziel
Logischer Datenträger(*)\Mittlere Datenträgerlesevorgänge/Sek.	< 20 ms
Logischer Datenträger(*)\Mittlere Datenträgerschreibvorgänge/Sek.	< 20 ms

Anwendungsstatus

Um zu bestimmen, ob ein Hub-Transport-Server richtig dimensioniert ist und in einem fehlerfreien Zustand ausgeführt wird, untersuchen Sie die Leistungsindikatoren "MSExchangeTransport-Warteschlangen", die in der folgenden Tabelle dargestellt sind. Diese Warteschlangen weisen zu unterschiedlichen Zeiten Nachrichten auf. Sie sollten sicherstellen, dass die Länge der Warteschlange nicht bestehen bleibt bzw. mit der Zeit anwächst. Große Warteschlangenlängen können auf einen überlasteten Hub-Transport-Server hinweisen. Es kann aber auch ein Netzwerkproblem oder ein überlasteter Postfachserver vorliegen, der keine neuen Nachrichten empfangen kann. Um sicher zu sein, müssen Sie andere Komponenten in der Exchange-Umgebung überprüfen.

Leistungsindikator	Ziel
MSExchangeTransport-Warteschlangen(_total\Aggregierte Zustellung	< 3000
MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Remotezustellungswarteschlange	< 250
MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Postfachzustellungswarteschlange	< 250
MSExchangeTransport-Warteschlangen(_total)\Länge der Postfachzustellungs-Warteschlange für Wiederholungsversuche	< 100
MSExchangeTransport-Warteschlangen(_total)\Länge der Übermittlungswarteschlange	< 100

Exchange 2010 – Getestete Lösungen

Tests zur Funktionsüberprüfung

Sie können die Informationen in den folgenden Abschnitten für Tests zur Funktionsüberprüfung verwenden.

Exchange 2010 – Getestete Lösungen

Überprüfung des Datenbankswitchovers

Ein Datenbankswitchover ist der Vorgang, bei dem für eine einzelne aktive Datenbank auf eine andere Datenbankkopie (eine passive Kopie) gewechselt wird, wobei diese andere Datenbankkopie zur neuen aktiven Datenbankkopie wird. Datenbankswitchover können sowohl innerhalb eines Datencenters als auch zwischen Datencentern auftreten. Ein Datenbankswitchover kann mithilfe der Exchange-Verwaltungskonsole (Exchange Management Console, EMC) oder der Exchange-Verwaltungsshell durchgeführt werden.

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob eine passive Kopie einer Datenbank erfolgreich auf einem anderen Server aktiviert werden kann.

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

Erfolgskriterien: Die aktive Postfachdatenbank wird auf dem angegebenen Zielserver eingebunden. Dieses Ergebnis kann durch Ausführung des folgenden Befehls überprüft werden:

Get-MailboxDatabaseCopyStatus <DatabaseName>

Exchange 2010 – Getestete Lösungen

Überprüfung des Serverswitchovers

Ein Serverswitchover ist der Vorgang, bei dem alle aktiven Datenbanken auf einem DAG-Mitglied auf mindestens einem anderen DAG-Mitglied aktiviert werden. Wie ein Datenbankswitchover kann ein Serverswitchover innerhalb eines Datencenters und zwischen Datencentern auftreten, und er kann mithilfe der Exchange-Verwaltungskonsole oder der Shell initiiert werden.

• Führen Sie den folgenden Befehl aus, um zu überprüfen, ob alle passiven Kopien der Datenbanken auf einem Server erfolgreich auf anderen Servern aktiviert werden können, die eine passive Kopie hosten.

  Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
  

  Erfolgskriterien: Die aktiven Postfachdatenbanken werden auf dem angegebenen Zielserver eingebunden. Dies kann durch Ausführung des folgenden Befehls überprüft werden.

  Get-MailboxDatabaseCopyStatus <DatabaseName>
  

• Um zu überprüfen, ob eine Kopie jeder der aktiven Datenbanken erfolgreich auf einem anderen Postfachserver aktiviert wird, der passive Kopien der Datenbanken hostet, fahren Sie den Server mit der folgenden Aktion herunter.

  Schalten Sie den aktuellen aktiven Server aus.

  Erfolgskriterien: Die aktiven Postfachdatenbanken sind auf einem anderen Postfachserver in der DAG eingebunden. Dies kann durch Ausführung des folgenden Befehls überprüft werden.

  Get-MailboxDatabaseCopyStatus <DatabaseName>
  

Exchange 2010 – Getestete Lösungen

Überprüfung des Serverfailovers

Ein Serverfailover tritt auf, wenn das DAG-Mitglied das MAPI-Netzwerk nicht mehr bedienen kann oder wenn der Clusterdienst auf einem DAG-Mitglied keine Verbindung mehr mit den übrigen DAG-Mitgliedern herstellen kann.

Um zu überprüfen, ob eine Kopie jeder der aktiven Datenbanken erfolgreich auf einem anderen Postfachserver aktiviert wird, der passive Kopien der Datenbanken hostet, fahren Sie den Server mit einer der folgenden Aktionen herunter.

• Halten Sie den Netzschalter des Servers gedrückt, bis der Server abgeschaltet ist.

• Ziehen Sie die Netzkabel des Servers, sodass der Server abgeschaltet wird.

Erfolgskriterien: Die aktiven Postfachdatenbanken sind auf einem anderen Postfachserver in der DAG eingebunden. Dies kann durch Ausführung des folgenden Befehls überprüft werden.

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Exchange 2010 – Getestete Lösungen

Überprüfung des Datencenterswitchovers

Ein Datencenter- oder Standortausfall wird anders verwaltet als die Arten von Ausfällen, die einen Server- oder Datenbankfailover verursachen können. In einer Konfiguration mit hoher Verfügbarkeit wird die automatische Wiederherstellung vom System initiiert, und nach dem Ausfall weist das Messagingsystem im Allgemeinen eine vollständig funktionsfähigen Status auf. Hingegen wird ein Datencenterausfall als Ereignis der Notfallwiederherstellung betrachtet, und die Wiederherstellung muss daher manuell durchgeführt und abgeschlossen werden, damit der Clientdienst wiederhergestellt und der Ausfall beendet werden kann. Der Vorgang, den Sie durchführen, wird als Datencenterswitchover bezeichnet. Wie bei vielen Szenarien der Notfallwiederherstellung kann eine vorherige Planung und Vorbereitung eines Datencenterswitchovers den Wiederherstellungsvorgang vereinfachen und die Dauer des Ausfalls verringern.

Weitere Informationen, einschließlich detaillierter Schritte zur Ausführung von Datencenterswitchovern, finden Sie unter Datencenterswitchover.

Zwischen der Entscheidung, ein zweites Datencenter zu aktivieren, und dem Ausführen eines Datencenterswitchovers liegen vier grundlegende Schritte:

1. Beenden eines teilweise ausgeführten (ausgefallenen) Datencenters.

2. Überprüfen und Bestätigen der Voraussetzungen für das zweite Datencenter.

3. Aktivieren der Postfachserver.

4. Aktivieren der Clientzugriffsserver.

In den folgenden Abschnitten werden die Schritte beschrieben, mit denen ein Datencenterswitchover überprüft wird.

Beenden des teilweise ausgefallenen Datencenters (mit der DAG im DAC-Modus)

Wenn sich die DAG im DAC-Modus befindet, hängen die Aktionen zur Beendigung noch funktionierender DAG-Mitglieder im primären Datencenter vom Zustand des ausgefallenen Datencenters ab: Führen Sie einen der folgenden Schritte aus:

• Wenn auf die Postfachserver im ausgefallenen Datencenter noch zugegriffen werden kann (ist normalerweise nicht der Fall), führen Sie auf jedem Postfachserver den folgenden Befehl aus.

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
  

• Wenn die Postfachserver im ausgefallenen Datencenter nicht verfügbar sind, aber Active Directory im primären Datencenter verwendet wird, führen Sie auf einem Domänencontroller den folgenden Befehl aus.

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
  

Erfolgskriterien: Alle Postfachserver am ausgefallenen Standort wurden beendet. Sie können dies überprüfen, indem Sie den folgenden Befehl auf einem Server im ausgefallenen Datencenter ausführen.

Get-DatabaseAvailabilityGroup | Format-List

Überprüfen und Bestätigen der Voraussetzungen für das sekundäre Datencenter

Das zweite Datencenter muss aktualisiert werden, um anzuzeigen, welche Server des primären Datencenters beendet wurden. Führen Sie den folgenden Befehl auf einem Server im sekundären Datencenter aus.

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

Zweck dieses Schritts ist das Benachrichtigen der Server im sekundären Datencenter hinsichtlich der Postfachserver, die beim Wiederherstellen des Diensts verwendet werden können.

Erfolgskriterien: Alle Postfachserver im ausgefallenen Datencenter wurden beendet. Führen Sie den folgenden Befehl auf einem Server im sekundären Datencenter aus, um dies zu überprüfen.

Get-DatabaseAvailabilityGroup | Format-List

Aktivieren von Postfachservern (mit der DAG im DAC-Modus)

Vor der Aktivierung von DAG-Mitgliedern im sekundären Datencenter sollten Sie überprüfen, ob die Infrastrukturdienste im sekundären Datencenter für die Aktivierung des Messagingdiensts bereit sind.

Wenn sich die DAG im DAC-Modus befindet, müssen die folgenden Schritte ausgeführt werden, um die Aktivierung von Postfachservern im sekundären Datencenter abzuschließen:

1. Beenden Sie den Clusterdienst auf jedem DAG-Mitglied im sekundären Datencenter. Sie können das Cmdlet Stop-Service verwenden, um den Dienst zu beenden (z. B. Stop-Service ClusSvc), oder net stop clussvc an einer Eingabeaufforderung mit erhöhten Rechten ausführen.

2. Führen Sie den folgenden Befehl aus, um die Postfachserver im sekundären Datencenter zu aktivieren.

   Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
   

   Wird dieser Befehl erfolgreich ausgeführt, berücksichtigen die Quorumkriterien nur noch die Server im sekundären Datencenter. Wenn in diesem Datencenter eine gerade Anzahl von Servern vorhanden ist, verwendet die DAG den alternativen Zeugenserver, der in der Einstellung für das DAG-Objekt angegeben ist.

3. Führen Sie einen der folgenden Befehle aus, um die Datenbanken zu aktivieren.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>
   

   oder

   Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>
   

4. Überprüfen Sie die Ereignisprotokolle und alle Fehler- und Warnmeldungen, um die Fehlerfreiheit des sekundären Standorts sicherzustellen. Angegebene Probleme sollten vor der Einbindung der Datenbanken nachverfolgt und behoben werden.

5. Führen Sie zum Einbinden der Datenbanken den folgenden Befehl aus.

   Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
   

Erfolgskriterien: Die aktiven Postfachdatenbanken sind auf Postfachservern am sekundären Standort eingebunden. Führen Sie zur Bestätigung den folgenden Befehl aus.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Aktivieren von Clientzugriffsservern

Clients stellen eine Verbindung mit Dienstendpunkten her, um auf Exchange-Dienste und -Daten zugreifen zu können. Das Aktivieren von mit dem Internet verbundenen Clientzugriffsservern umfasst daher das Ändern von DNS-Datensätzen dahin gehend, dass diese auf die neuen IP-Adressen verweisen, die für die neuen Dienstendpunkte konfiguriert werden. Clients stellen dann auf zweierlei Art automatisch eine Verbindung mit den neuen Dienstendpunkten her:

• Clients versuchen in regelmäßigen Abständen, eine Verbindung herzustellen, und sollten automatisch verbunden werden, nachdem die Gültigkeitsdauer für den ursprünglichen DNS-Eintrag abgelaufen ist und der Eintrag aus dem DNS-Cache des Clients entfernt wurde. Benutzer können einen DNS-Cache auch manuell löschen, indem sie den Befehl ipconfig /flushdns an der Eingabeaufforderung ausführen. Wenn Sie Outlook Web App verwenden, muss der Webbrowser möglicherweise geschlossen und neu gestartet werden, um den vom Browser verwendeten DNS-Cache zu löschen. In Exchange 2010 SP1 kann dieses Problem mit dem Browsercache vermieden werden, indem der Parameter FailbackURL für das virtuelle Outlook Web App-Verzeichnis "owa" konfiguriert wird.

• Clients führen beim Starten und Neustarten einen DNS-Suchvorgang aus und erhalten die neue IP-Adresse für den Dienstendpunkt, der ein Clientzugriffsserver oder Clientzugriffsserver-Array im zweiten Datencenter ist.

Führen Sie die folgenden Aktionen aus, um das Szenario mit Loadgen zu überprüfen:

1. Ändern Sie den DNS-Eintrag für das Clientzugriffsserver-Array, sodass er auf die virtuelle IP-Adresse des Hardwarelastenausgleichs am sekundären Standort verweist.

2. Führen Sie den Befehl ipconfig /flushdns auf allen Loadgen-Servern aus.

3. Starten Sie den Loadgen-Test neu.

4. Überprüfen Sie, ob die Clientzugriffsserver am sekundären Standort jetzt die Last verarbeiten.

Führen Sie Folgendes aus, um das Szenario mit einem Outlook 2007-Client zu überprüfen:

1. Ändern Sie den DNS-Eintrag für das Clientzugriffsserver-Array, sodass er auf die virtuelle IP-Adresse des Hardwarelastenausgleichs am sekundären Standort verweist.

2. Führen Sie den Befehl ipconfig /flushdns auf dem Client aus, oder warten Sie auf den Ablauf der Gültigkeitsdauer.

3. Warten Sie darauf, dass der Outlook-Client die Verbindung erneut herstellt.

Exchange 2010 – Getestete Lösungen

Überprüfung der Wiederherstellung des Diensts des primären Datencenters

Der Prozess der Wiederherstellung eines Diensts in einem bereits ausgefallenen Datencenter wird auch als Failback bezeichnet. Die Schritte zur Ausführung eines Datencenterfailbacks entsprechen den Schritten zur Ausführung eines Datencenterswitchovers. Ein bedeutender Unterschied besteht darin, dass die Datencenterfailbacks geplant sind und die Dauer des Ausfalls häufig deutlich kürzer ist.

Es ist wichtig, dass ein Failback erst dann ausgeführt wird, wenn die Infrastrukturabhängigkeiten für Exchange reaktiviert wurden, stabil ausgeführt werden und überprüft wurden. Wenn diese Abhängigkeiten nicht verfügbar oder nicht fehlerfrei sind, ist die Wahrscheinlichkeit groß, dass der Failbackprozess zu einem längeren Ausfall als notwendig führt. Es besteht außerdem die Möglichkeit, dass der Vorgang insgesamt nicht erfolgreich ausgeführt werden kann.

Die Postfachserverrolle sollte die erste Rolle sein, für die ein Failback zum primären Datencenter ausgeführt wird. Mit den folgenden Schritten wird der Failbackprozess für die Postfachserverrolle erläutert (mit der DAG im DAC-Modus).

1. Führen Sie den folgenden Befehl aus, um die DAG-Mitglieder erneut in den primären Standort einzubinden.

   Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
   

2. Führen Sie den folgenden Befehl aus, um den Zustand der Datenbankkopien im primären Datencenter zu überprüfen.

   Get-MailboxDatabaseCopyStatus
   

Nach der Integration der Postfachserver im primären Datencenter in die Datenbankverfügbarkeitsgruppe wird die Synchronisierung der Datenbankkopien gestartet; dies kann einige Zeit dauern. In Abhängigkeit von der Art und Länge des Ausfalls und den vom Administrator während des Ausfalls getroffenen Maßnahmen kann ein erneutes Seeding der Datenbankkopien erforderlich sein. Wenn z. B. während des Ausfalls die Datenbankkopien aus dem ausgefallenen primären Datencenter entfernt wurden, um das Abschneiden der Protokolldateien für die noch aktiven Kopien im sekundären Datencenter zuzulassen, ist ein erneutes Seeding erforderlich. Zu diesem Zeitpunkt kann jede Datenbank einzeln synchronisiert werden. Wenn eine replizierte Datenbankkopie im primären Datencenter fehlerfrei ist, kann der nächste Schritt ausgeführt werden.

1. Während des Datencenterswitchovers wurde die DAG so konfiguriert, dass sie auf einen alternativen Zeugenserver zugreift. Führen Sie den folgenden Befehl aus, um die DAG so neu zu konfigurieren, dass sie einen Zeugenserver im primären Datencenter verwendet.

   Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
   

2. Die Einbindung der im primären Datencenter reaktivierten Datenbanken muss im sekundären Datencenter aufgehoben werden. Führen Sie den folgenden Befehl aus.

   Get-MailboxDatabase | Dismount-Database
   

3. Nachdem die Einbindung der Datenbanken aufgehoben wurde, müssen die URLs der Clientzugriffsserver vom sekundären in das primäre Datencenter geändert werden. Ändern Sie dazu den DNS-Datensatz, sodass die URLs auf den Clientzugriffsserver oder das Clientzugriffsserver-Array im primären Datencenter verweisen.

   Wichtig

   Führen Sie den nächsten Schritt erst aus, wenn die URLs des Clientzugriffsservers geändert wurden und die DNS-Gültigkeitsdauer abgelaufen ist bzw. die DNS-Cacheeinträge entfernt wurden. Wenn die Datenbanken im primären Datencenter vor dem Ändern der Clientzugriffsserver-URLs in das primäre Datencenter aktiviert werden, ist die Konfiguration nicht gültig (z. B. eine eingebundene Datenbank, die über keine Clientzugriffsserver am Active Directory-Standort verfügt).

4. Führen Sie einen der folgenden Befehle aus, um die Datenbanken zu aktivieren.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>
   

   oder

   Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
   

5. Führen Sie zum Einbinden der Datenbanken den folgenden Befehl aus.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
   

Erfolgskriterien: Die aktiven Postfachdatenbanken wurden erfolgreich auf Postfachservern am primären Standort eingebunden. Führen Sie zur Bestätigung den folgenden Befehl aus.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Exchange 2010 – Getestete Lösungen

Testeinrichtung

Die Tests wurden im Microsoft Enterprise Engineering Center durchgeführt, einem modernen Labor für die Überprüfung von Unternehmenslösungen auf dem Microsoft-Hauptcampus in Redmond, Washington.

Mit Hardware im Wert von mehr als 125 Millionen US-Dollar und einer anhaltenden zuverlässigen Partnerschaft mit den in der Branche führenden Originalgeräteherstellern (Original Equipment Manufacturers, OEMs) kann praktisch jede Produktionsumgebung im EEC nachgebildet werden. Das EEC bietet eine Umgebung für eine intensive Zusammenarbeit zwischen Kunden, Partnern und Microsoft-Produktingenieuren. Dadurch kann sichergestellt werden, dass Microsoft-Komplettlösungen die hohen Erwartungen der Kunden erfüllen.

Exchange 2010 – Getestete Lösungen

Ergebnisse der Lösungsüberprüfung

Im folgenden Abschnitt werden die Ergebnisse der Tests zur Funktions- und Leistungsüberprüfung zusammengefasst.

Exchange 2010 – Getestete Lösungen

Ergebnisse der Funktionsüberprüfung

In der folgenden Tabelle sind die Ergebnisse der Tests zur Funktionsüberprüfung zusammengefasst.

Ergebnisse der Funktionsüberprüfung

Testfall	Ergebnis	Anmerkungen
Datenbankswitchover	Erfolgreich	Ohne Fehler abgeschlossen
Serverswitchover	Erfolgreich	Ohne Fehler abgeschlossen
Serverausfall	Erfolgreich	Ohne Fehler abgeschlossen
Standortausfall	Erfolgreich	Ohne Fehler abgeschlossen

Exchange 2010 – Getestete Lösungen

Ergebnisse der Überprüfung des Speicherentwurfs

Tests auf allen Datenträgern pro Standort mit einem einzelnen Speicherframe haben gezeigt, dass CX4-480 etwas mehr als 8.000 transaktionelle Exchange 2010-IOPS auf acht Exchange-VMs verarbeitet, die mit einem Benutzerprofil von 150 Nachrichten bei 0,15 IOPS und einer Zusatzkapazität von 20 Prozent konfiguriert sind. Die Leistung übersteigt die geplante Baseline von 5.832 IOPS, die für diese Konfiguration erforderlich ist, sodass Zusatzkapazitäten für Spitzenlasten zur Verfügung stehen. Die Datenträgerwartezeiten lagen alle innerhalb der nach den bewährten Methoden von Microsoft für die Exchange 2010-Leistung akzeptablen Parametern.

Ergebnisse der Überprüfung des Speicherentwurfs

Datenbank-E/A	Zielwerte	4 Postfachserver bei normalen Betriebsbedingungen (2.700 Benutzer pro Postfachserver)	4 Postfachserver bei Switchoverbedingungen (5.400 Benutzer pro Postfachserver)	Gesamt
Erreichte transaktionelle IOPS (E/A: Datenbankleseoperationen/Sek. + E/A: Datenbankschreiboperationen/Sek.)	1944 / 3888	3576 IOPS	4488 IOPS	8064 IOPS
E/A: Datenbankleseoperationen/Sek.	Nicht zutreffend	2193	2729	4922
E/A: Datenbankschreiboperationen/Sek.	Nicht zutreffend	1439	1703	3142
E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (ms)	< 20 ms	14	18	16
E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (ms)	Kein guter Indikator für Clientwartezeiten, da Datenbankschreibvorgänge asynchron sind	14	18	16
E/A: Protokollschreiboperationen/Sek.	Nicht zutreffend	1238	1560	2798
E/A: Durchschnittliche Wartezeit für Protokollleseoperationen (ms)	< 10 ms	2	2	2

Exchange 2010 – Getestete Lösungen

Ergebnisse der Überprüfung des Serverentwurfs

In den folgenden Abschnitten werden die Ergebnisse der Überprüfung des Serverentwurfs für die Testfälle zusammengefasst.

Loadgen-Überprüfung: Testszenarien

Test	Beschreibung
Normaler Betrieb	An einem Standort wurde eine zu 100 Prozent simultane Last für 10.800 Benutzer simuliert, wobei jeder Postfachserver 2.700 Benutzer verarbeitet hat.
Ausfall oder Wartung eines Servers (am Standort)	Der Ausfall eines Hyper-V-Servers pro Standort wurde simuliert. Eine zu 100 Prozent simultane Last wurde auf einem Hyper-V-Host ausgeführt, wobei eine VM 5.400 Benutzer verarbeitet hat. Nur drei kombinierte Clientzugriffs- und Hub-Transport-Server haben die Last verarbeitet.
Standortausfall	Ein Standortausfall wurde simuliert, und die sekundären Images auf Ersatz-VMs für Postfachserver wurden aktiviert. Eine zu 100 Prozent simultane Last wurde für 21.600 Benutzer an einem Standort ausgeführt.

Testfall: Normale Betriebsbedingungen

Dieser Testfall stellt die Spitzenlast bei normalen Betriebsbedingungen dar. Normale Betriebsbedingungen bezeichnen einen Zustand, bei dem sich alle aktiven und passiven Datenbanken auf den Servern befinden, auf denen sie auch ausgeführt werden sollen. Da in diesem Testfall nicht die Arbeitslast im schlimmsten Fall dargestellt wird, ist er kein wichtiger Test zur Leistungsüberprüfung. Er bietet einen guten Anhaltspunkt dafür, wie die Umgebung ausgeführt werden sollte, wenn keine Server ausgefallen sind oder gewartet werden. Das Ziel in diesem Test war, die vollständige Exchange-Umgebung unter normalen Betriebsbedingungen mit einer Spitzenlast zu überprüfen. Alle Exchange-VMs wurden unter normalen Bedingungen ausgeführt. Loadgen wurde so konfiguriert, dass Spitzenlast simuliert wurde. Das Aktionsprofil mit 150 Nachrichten sollte im Spitzenmodus die doppelte Anzahl gesendeter und zugestellter Nachrichten pro Sekunde generieren.

Überprüfung der erwarteten Last

Mit der Nachrichtenzustellungsrate wird überprüft, ob die getestete Arbeitslast mit der geplanten Arbeitslast übereinstimmt. Die Nachrichtenzustellungsrate ist etwas höher als geplant. Dies führt zu einer etwas höheren Last als im gewünschten Profil.

Leistungsindikator	Ziel	Getestetes Ergebnis
Nachrichtenzustellungsrate pro Postfach	15,0	15,2

Überprüfung der primären Postfachserver

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der primären Postfachserver-VMs dargestellt.

Prozessor

Die Prozessorauslastung liegt unter 70 Prozent, wie erwartet.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 70 %	69

Speicher

Die Speicherergebnisse sind gut. Alle Wartezeiten liegen unter den Zielwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (angefügt)	< 20 ms	19
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (angefügt)	< 20 ms < Durchschnittliche Lesevorgänge	18
Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.	0	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen	< 20 ms	5
Datenbank\Protokolldatensatzverzögerungen/Sek.	0	0

Anwendungsstatus

Der Status von Exchange ist sehr gut, und alle zur Bestimmung des Anwendungsstatus eingesetzten Leistungsindikatoren lagen deutlich unter den Zielwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchangeIS\RPC-Anforderungen	< 70	3,0
MSExchangeIS\Durchschnittl. RPC-Wartezeit	< 10 ms	2,0
MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten	0	2,0

Überprüfung der sekundären Postfachserver

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der sekundären Postfachserver-VMs dargestellt.

Prozessor

Die Prozessorauslastung liegt unter 70 Prozent, wie erwartet.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 70 %	26

Speicher

Die Speicherergebnisse sind gut. Alle Wartezeiten liegen unter den Zielwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (Wiederherstellung)	< 100 ms	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (Wiederherstellung)	< 100 ms < Durchschnittliche Lesevorgänge	16
Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.	0	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen	< 20 ms	3
Datenbank\Protokolldatensatzverzögerungen/Sek.	0	0

Anwendungsstatus

Auf den sekundären Postfachservern werden nur die dritten passiven Datenbankkopien verwaltet, die standardmäßigen Leistungsindikatoren für den Status der Exchange-Anwendung gelten in diesem Szenario also nicht.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchangeIS\RPC-Anforderungen	< 70	Nicht zutreffend
MSExchangeIS\Durchschnittl. RPC-Wartezeit	< 10 ms	Nicht zutreffend
MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten	0	Nicht zutreffend

Überprüfung der Clientzugriffs- und Hub-Transport-Server

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der VMs für Clientzugriffs- und Hub-Transport-Server dargestellt.

Prozessor

Die Prozessorauslastung ist gering, wie erwartet.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 70 %	48

Speicher

Die Speicherergebnisse sind gut. Die sehr niedrigen Wartezeiten sollten keine Auswirkungen auf den Nachrichtentransport haben.

Leistungsindikator	Ziel	Getestetes Ergebnis
Logischer/physischer Datenträger(*)\Durchschnittliche Datenträgerlesevorgänge/Sek.	< 20 ms	0,001
Logischer/physischer Datenträger(*)\Durchschnittliche Datenträgerschreibvorgänge/Sek.	< 20 ms	0,005

Anwendungsstatus

Die geringen Werte für die durchschnittliche RPC-Wartezeit bestätigen den fehlerfreien Zustand des Clientzugriffsservers ohne Beeinträchtigung der Clientleistung.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange RpcClientAccess\Durchschnittl. RPC-Wartezeit	< 250 ms	8
MSExchange RpcClientAccess\RPC-Anforderungen	< 40	3

Die Leistungsindikatoren für die Transportwarteschlangen liegen deutlich unter den Zielwerten und bestätigen, dass der Zustand des Hub-Transport-Servers fehlerfrei ist und er in der Lage ist, die erforderlichen Nachrichten zu verarbeiten und zuzustellen.

Leistungsindikator	Ziel	Getestetes Ergebnis
\MSExchangeTransport-Warteschlangen(_total)\Aggregierte Länge Zustellungswarteschlange (alle Warteschlangen)	< 3000	2,5
\MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Remotezustellungswarteschlange	< 250	0
\MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Postfachzustellungswarteschlange	< 250	2,3
\MSExchangeTransport-Warteschlangen(_total)\Länge der Übermittlungswarteschlange	< 100	0
\MSExchangeTransport-Warteschlangen(_total)\Länge der Postfach-Remotezustellungswarteschlange für Wiederholungsversuche	< 100	0,3

Überprüfung des Stammserverstatus

In den folgenden Tabellen sind die Ergebnisse der Überprüfung des Hyper-V-Stammservers dargestellt.

Prozessor

Wie erwartet ist die Prozessorauslastung sehr gering und liegt weit unter den Zielschwellenwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Gastausführungszeit	< 75 %	66
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Hypervisorausführungszeit	< 5 %	2
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Gesamtausführungszeit	< 80 %	68
Virtueller Prozessor des Hyper-V-Hypervisorstamms(_total)\% Gastausführungszeit	< 5 %	3

Anwendungsstatus

Die Leistungsindikatoren für die Statuszusammenfassung virtueller Computer geben an, dass alle VMs einen fehlerfreien Zustand aufweisen.

Leistungsindikator	Ziel	Getestetes Ergebnis
Hyper-V - Statuszusammenfassung für virtuelle Computer\Status kritisch	0	0

Testfall: Ausfall oder Wartung eines Servers (am Standort)

Das Ziel in diesem Test war, die vollständige Exchange-Umgebung bei Ausfall oder Wartung des physischen Hyper-V-Stammservers mit einer Spitzenlast zu überprüfen. Alle VMs, die auf einem der Hyper-V-Stammserver an dem Standort ausgeführt wurden, wurden heruntergefahren, um eine Hostwartung zu simulieren. Dies hat dazu geführt, dass Datenbankimages (Kopien) auf andere Postfachserver-VMs verschoben wurden, sodass in jeder Postfachserver-VM 5.400 Benutzer verarbeitet wurden. Nur die Hälfte der kombinierten Clientzugriffs- und Hub-Transport-Server hat Clientzugriff und E-Mail-Zustellung verarbeitet.

Überprüfung der erwarteten Last

Mit der tatsächlichen Nachrichtenzustellungsrate wurde der Zielwert eingehalten.

Leistungsindikator	Ziel	Getestetes Ergebnis
Nachrichtenzustellungsrate pro Server	30	30

Überprüfung der primären Postfachserver

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der primären Postfachserver-VMs dargestellt.

Prozessor

Die Prozessorauslastung liegt etwas über dem Zielwert. Dieser Testfall stellt ein Ausfall- oder Wartungsszenario mit Spitzenlast dar, es ist also ein Ereignis, das selten eintritt. Für einen längeren Zeitraum sollte die Prozessorauslastung nicht so hoch sein.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 80 %	83

Speicher

Die Speicherergebnisse sehen akzeptabel aus. Die durchschnittliche Wartezeit für Lesevorgänge liegt ein wenig über dem Zielwert. Die durchschnittliche Wartezeit für Datenbankschreibvorgänge ist höher als gewünscht. Dies tritt während des schlimmsten Ausfallszenarios unter Spitzenlast auf, ein seltenes Ereignis. Durch die hohen Wartezeiten überschreiten die Leistungsindikatoren für den Anwendungsstatus die Zielwerte jedoch nicht. Die Leistung für die Benutzer sollte also akzeptabel sein. Für einen längeren Zeitraum sollten die Wartezeiten nicht so hoch sein.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (angefügt)	< 20 ms	20,5
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (angefügt)	< 20 ms	23
Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.	0	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen	< 20 ms	8
Datenbank\Protokolldatensatzverzögerungen/Sek.	0	0

Anwendungsstatus

Die Leistungsindikatoren zeigen, dass Exchange noch einigermaßen fehlerfrei ist. Einige Nachrichten werden unter Spitzenlast in Warteschlangen eingereiht. Für einen längeren Zeitraum sollte dies nicht passieren.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchangeIS\RPC-Anforderungen	< 70	9,0
MSExchangeIS\Durchschnittl. RPC-Wartezeit	< 10 ms	2,0
MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten	0	77

Überprüfung der sekundären Postfachserver

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der sekundären Postfachserver-VMs dargestellt.

Prozessor

Die Prozessorauslastung liegt unter 70 Prozent, wie erwartet.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 70 %	21

Speicher

Die Speicherergebnisse sind gut. Alle Wartezeiten liegen unter den Zielwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (Wiederherstellung)	< 100 ms	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (Wiederherstellung)	< 100 ms < Durchschnittliche Lesevorgänge	21
Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.	0	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen	< 20 ms	3
Datenbank\Protokolldatensatzverzögerungen/Sek.	0	0

Anwendungsstatus

Auf den sekundären Postfachservern werden nur die dritten passiven Datenbankkopien verwaltet, die standardmäßigen Leistungsindikatoren für den Status der Exchange-Anwendung gelten in diesem Szenario also nicht.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchangeIS\RPC-Anforderungen	< 70	Nicht zutreffend
MSExchangeIS\Durchschnittl. RPC-Wartezeit	< 10 ms	Nicht zutreffend
MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten	0	Nicht zutreffend

Überprüfung der Clientzugriffs- und Hub-Transport-Server

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der VMs für Clientzugriffs- und Hub-Transport-Server dargestellt.

Prozessor

Die Prozessorauslastung liegt unter 80 Prozent, wie erwartet.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 80 %	74

Speicher

Die Speicherergebnisse sind gut. Die sehr niedrigen Wartezeiten sollten keine Auswirkungen auf den Nachrichtentransport haben.

Leistungsindikator	Ziel	Getestetes Ergebnis
Logischer/physischer Datenträger(*)\Durchschnittliche Datenträgerlesevorgänge/Sek.	< 20 ms	0,001
Logischer/physischer Datenträger(*)\Durchschnittliche Datenträgerschreibvorgänge/Sek.	< 20 ms	0,008

Anwendungsstatus

Die geringen Werte für die durchschnittliche RPC-Wartezeit bestätigen den fehlerfreien Zustand des Clientzugriffsservers ohne Beeinträchtigung der Clientleistung.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange RpcClientAccess\Durchschnittl. RPC-Wartezeit	< 250 ms	18
MSExchange RpcClientAccess\RPC-Anforderungen	< 40	14

Die Leistungsindikatoren für die Transportwarteschlangen liegen deutlich unter den Zielwerten und bestätigen, dass der Zustand des Hub-Transport-Servers fehlerfrei ist und er in der Lage ist, die erforderlichen Nachrichten zu verarbeiten und zuzustellen.

Leistungsindikator	Ziel	Getestetes Ergebnis
\MSExchangeTransport-Warteschlangen(_total)\Aggregierte Länge Zustellungswarteschlange (alle Warteschlangen)	< 3000	49
\MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Remotezustellungswarteschlange	< 250	0
\MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Postfachzustellungswarteschlange	< 250	43
\MSExchangeTransport-Warteschlangen(_total)\Länge der Übermittlungswarteschlange	< 100	53
\MSExchangeTransport-Warteschlangen(_total)\Länge der Postfach-Remotezustellungswarteschlange für Wiederholungsversuche	< 100	4

Überprüfung des Stammserverstatus

In den folgenden Tabellen sind die Ergebnisse der Überprüfung des Hyper-V-Stammservers dargestellt.

Prozessor

Die Prozessorauslastung erreicht fast die Zielschwellenwerte, was für ein Ausfall- oder Wartungsszenario unter Spitzenlast zu erwarten war.

Leistungsindikator	Ziel	Getestetes Ergebnis
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Gastausführungszeit	< 75 %	77
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Hypervisorausführungszeit	< 5 %	2
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Gesamtausführungszeit	< 80 %	79
Virtueller Prozessor des Hyper-V-Hypervisorstamms(_total)\% Gastausführungszeit	< 5 %	3

Anwendungsstatus

Die Leistungsindikatoren für die Statuszusammenfassung virtueller Computer geben an, dass alle VMs einen fehlerfreien Zustand aufweisen.

Leistungsindikator	Ziel	Getestetes Ergebnis
Hyper-V - Statuszusammenfassung für virtuelle Computer\Status kritisch	0	0

Testfall: Standortausfall und Switchover

In diesem Testfall wird ein Standortausfall simuliert, indem die aktiven Datenbanken im primären Standort auf die passiven Datenbanken im sekundären Standort umgeschaltet werden, was zu 21.600 aktiven Postfächern an einem Standort führt. Die vier primären Postfachserver-VMs am noch aktiven Standort führen eine normale Arbeitslast von je 2.700 aktiven Postfächern aus. Die vier sekundären Postfachserver-VMs am noch aktiven Standort führen jetzt je 2.700 aktive Postfächer aus. Jeder Hyper-V-Stammserver hostet 5.400 aktive Postfächer.

Überprüfung der erwarteten Last

Die Nachrichtenzustellungsrate ist etwas höher als geplant. Dies führt zu einer etwas höheren Last als im gewünschten Profil.

Leistungsindikator	Ziel	Getestetes Ergebnis
Nachrichtenzustellungsrate pro Server	15	15,1

Überprüfung der primären Postfachserver

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der primären Postfachserver-VMs dargestellt.

Prozessor

Auf den primären Postfachserver-VMs wird eine normale Arbeitslast ausgeführt, und sie liegen unter dem Zielwert für die Prozessorauslastung, wie erwartet.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 70 %	63

Speicher

Die Speicherergebnisse sind gut. Alle Wartezeiten liegen unter den Zielwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (angefügt)	< 20 ms	12
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (angefügt)	< 20 ms	13
Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.	0	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen	< 20 ms	4
Datenbank\Protokolldatensatzverzögerungen/Sek.	0	0

Anwendungsstatus

Der Status von Exchange ist sehr gut, und alle zur Bestimmung des Anwendungsstatus eingesetzten Leistungsindikatoren lagen deutlich unter den Zielwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchangeIS\RPC-Anforderungen	< 70	3,0
MSExchangeIS\Durchschnittl. RPC-Wartezeit	< 10 ms	2,0
MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten	0	3

Überprüfung der sekundären Postfachserver

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der sekundären Postfachserver-VMs dargestellt.

Prozessor

Die Prozessorauslastung liegt etwas über dem Zielwert von 80 Prozent. Dies ist höher als gewünscht, scheint aber die anderen Leistungsindikatoren für den Exchange-Status nicht zu beeinträchtigen. Da dieser Test Spitzenlast während eines Standortausfalls, also ein seltenes Ereignis, darstellt, ist der Wert akzeptabel. Für einen längeren Zeitraum sollte die Prozessorauslastung nicht in diesem Bereich liegen.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 80 %	84

Speicher

Die Speicherergebnisse sind gut. Alle Wartezeiten liegen unter den Zielwerten.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (angefügt)	< 20 ms	17
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Datenbankschreiboperationen (angefügt)	< 20 ms < Durchschnittliche Lesevorgänge	12
Datenbank\Datenbank:Seitenfehlerverzögerungen/Sek.	0	0
MSExchange-Datenbank\E/A: Durchschnittliche Wartezeit für Protokollschreiboperationen	< 20 ms	3
Datenbank\Protokolldatensatzverzögerungen/Sek.	0	0

Anwendungsstatus

Die Leistungsindikatoren zeigen, dass Exchange fehlerfrei ist. Eine geringe Anzahl von Nachrichten wird in Warteschlangen eingereiht.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchangeIS\RPC-Anforderungen	< 70	3
MSExchangeIS\Durchschnittl. RPC-Wartezeit	< 10 ms	2
MSExchangeIS Postfach(_Total)\Für die Übermittlung in Warteschlangen eingereihte Nachrichten	0	106

Überprüfung der Clientzugriffs- und Hub-Transport-Server

In den folgenden Tabellen sind die Ergebnisse der Überprüfung der VMs für Clientzugriffs- und Hub-Transport-Server dargestellt.

Prozessor

Die Prozessorauslastung liegt unter 80 Prozent, wie erwartet.

Leistungsindikator	Ziel	Getestetes Ergebnis
Virtueller Prozessor für Hyper-V-Hypervisor\% Gastausführungszeit	< 70 %	63

Speicher

Die Speicherergebnisse sind gut. Die sehr niedrigen Wartezeiten sollten keine Auswirkungen auf den Nachrichtentransport haben.

Leistungsindikator	Ziel	Getestetes Ergebnis
Logischer/physischer Datenträger(*)\Durchschnittliche Datenträgerlesevorgänge/Sek.	< 20 ms	0,002
Logischer/physischer Datenträger(*)\Durchschnittliche Datenträgerschreibvorgänge/Sek.	< 20 ms	0,003

Anwendungsstatus

Die geringen Werte für die durchschnittliche RPC-Wartezeit bestätigen den fehlerfreien Zustand des Clientzugriffsservers ohne Beeinträchtigung der Clientleistung.

Leistungsindikator	Ziel	Getestetes Ergebnis
MSExchange RpcClientAccess\Durchschnittl. RPC-Wartezeit	< 250 ms	9
MSExchange RpcClientAccess\RPC-Anforderungen	< 40	7

Die Leistungsindikatoren für die Transportwarteschlangen liegen deutlich unter den Zielwerten und bestätigen, dass der Zustand des Hub-Transport-Servers fehlerfrei ist und er in der Lage ist, die erforderlichen Nachrichten zu verarbeiten und zuzustellen.

Leistungsindikator	Ziel	Getestetes Ergebnis
\MSExchangeTransport-Warteschlangen(_total)\Aggregierte Länge Zustellungswarteschlange (alle Warteschlangen)	< 3000	5
\MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Remotezustellungswarteschlange	< 250	0
\MSExchangeTransport-Warteschlangen(_total)\Länge der aktiven Postfachzustellungswarteschlange	< 250	4
\MSExchangeTransport-Warteschlangen(_total)\Länge der Übermittlungswarteschlange	< 100	0
\MSExchangeTransport-Warteschlangen(_total)\Länge der Postfach-Remotezustellungswarteschlange für Wiederholungsversuche	< 100	1

Überprüfung des Stammserverstatus

In den folgenden Tabellen sind die Ergebnisse der Überprüfung des Hyper-V-Stammservers dargestellt.

Prozessor

Die Prozessorauslastung liegt über dem Zielwert von 80 Prozent. Da dieser Test Spitzenlast während eines Standortausfalls, also ein seltenes Ereignis, darstellt, ist der Wert akzeptabel. Für einen längeren Zeitraum sollte die Prozessorauslastung nicht in diesem Bereich liegen.

Leistungsindikator	Ziel	Getestetes Ergebnis
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Gastausführungszeit	< 75 %	85
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Hypervisorausführungszeit	< 5 %	2
Logischer Prozessor für Hyper-V-Hypervisor(_total)\% Gesamtausführungszeit	< 80 %	87
Virtueller Prozessor des Hyper-V-Hypervisorstamms(_total)\% Gastausführungszeit	< 5 %	3

Anwendungsstatus

Die Leistungsindikatoren für die Statuszusammenfassung virtueller Computer geben an, dass alle VMs einen fehlerfreien Zustand aufweisen.

Leistungsindikator	Ziel	Getestetes Ergebnis
Hyper-V - Statuszusammenfassung für virtuelle Computer\Status kritisch	0	0

Exchange 2010 – Getestete Lösungen

Zusammenfassung

Dieses Whitepaper enthält ein Beispiel zum Entwerfen, Testen und Überprüfen einer Exchange 2010-Lösung für Kundenumgebungen mit 32.400 Postfächern an mehreren Standorten, die auf Cisco- und EMC-Hardware bereitgestellt wurde. Die schrittweise Methodik in diesem Dokument geht die wichtigen Punkte der Entwurfsentscheidungen durch, mit denen große Herausforderungen bewältigt werden können, während gleichzeitig sichergestellt wird, dass die grundlegenden Unternehmensanforderungen erfüllt werden.

Exchange 2010 – Getestete Lösungen

Weitere Informationen

Die vollständige Exchange 2010-Dokumentation finden Sie unter Exchange Server 2010 (möglicherweise in englischer Sprache).

Weitere Informationen im Zusammenhang mit Cisco und EMC finden Sie in den folgenden Ressourcen:

• EMC CLARiiON CX4-480: Virtuelle EMC CLARiiON-Bereitstellung (möglicherweise in englischer Sprache)

• EMC CLARiiON CX4-480: Produktübersicht (möglicherweise in englischer Sprache)

• Cisco Unified Computing and Servers: UCS im Überblick (möglicherweise in englischer Sprache)

• Cisco Unified Computing and Servers: B-Series-Bladeserver (möglicherweise in englischer Sprache)

• Cisco Unified Computing and Servers: UCS-Manager (möglicherweise in englischer Sprache)

Dieses Dokument wird "as-is" bereitgestellt. Die in diesen Unterlagen enthaltenen Angaben und Ansichten einschließlich URL- und anderen Internet-Websiteverweisen können ohne vorherige Ankündigung geändert werden. Sie tragen das Risiko der Verwendung.

Dieses Dokument gibt Ihnen keine gesetzlichen Rechte an geistigem Eigentum eines Microsoft-Produkts. Sie können dieses Dokument für interne und Referenzzwecke kopieren und verwenden.

Exchange 2010 – Getestete Lösungen