Empfiehlt es sich, Exchange 2007 SP1 zu virtualisieren?

Letztes Änderungsdatum des Themas: 2009-03-02

Durch Windows Server 2008 mit Hyper-V-Technologie und Microsoft Hyper-V Server 2008 ist ein virtualisierter Server mit Microsoft Exchange Server 2007 Service Pack 1 (SP1) nicht mehr auf Testumgebungen eingeschränkt - er kann in einer Produktionsumgebung bereitgestellt werden und umfassende Unterstützung von Microsoft erhalten. Im August 2008 hat Microsoft Supportrichtlinien und Empfehlungen für die Virtualisierung von Exchange veröffentlicht. Dieses Thema gibt Antworten auf eine philosophischere Frage: Ist die Virtualisierung von Exchange ein vertretbarer Ansatzpunkt?

Aufgrund der Leitungs- und Geschäftsanforderungen von Exchange Server profitieren die meisten Bereitstellungen von der Bereitstellung von Exchange-Serverfunktionen auf physikalischen Servern. Unter bestimmten Umständen kann die Ausführung von Exchange in einer Hardwarevirtualisierungsumgebung jedoch echte Vorteile hinsichtlich Platzbedarf, Stromkosten und Bereitstellungsflexibilität mit sich bringen. Dieses Thema beschäftigt sich mit den folgenden Aspekten:

• Scenarios   In diesem Abschnitt werden vier Szenarien beschrieben, in denen die Virtualisierung von Exchange 2007 SP1 ggf. sinnvoll ist.

• Technical Checklists   In diesem Abschnitt finden Sie Checklisten, mit denen Sie ermitteln können, ob die aktuelle Last in Ihrer Infrastruktur eine Virtualisierung sinnvoll erscheinen lässt.

Szenarien

In diesem Abschnitt werden vier Szenarien erläutert:

• Small Office with High Availability

• Remote or Branch Office with High Availability

• Disaster Recovery

• Mobile LAN

Kleine Organisation mit hoher Verfügbarkeit

Einige Organisationen sind klein und benötigen dennoch Verfügbarkeit der Unternehmensklasse. Contoso, Ltd. (ein fiktives Unternehmen) ist z. B. eine solche Organisation, die E-Mail als unternehmenswichtigen Dienst betrachtet. Contoso besteht aus mehreren kleinen Zweigstellen mit 250 Benutzern. Contoso möchte aus rechtlichen Gründen die E-Mail-Umgebung am Firmenstandort ausführen, und das Unternehmen möchte über ein vollständig redundantes E-Mail-System verfügen. Die Benutzer von Contoso verfügen über Benutzermessagingprofile des Tys "Durchschnittlich" mit 2 GB großen Postfächern.

Contoso müsste sieben Server bereitstellen, um vollständige Redundanz für alle Exchange-Serverfunktionen bei Verwendung physikalischer Hardware zu erreichen: zwei Server für Active Directory und DNS, einen Server für Datei- und Druckdienste, zwei Server, die die Serverfunktionen ClientAccess und Hub-Transport ausführen, und zwei Server, die die Serverfunktion Mailbox in einer CCR-Umgebung (Cluster Continuous Replication, fortlaufende Clusterreplikation) ausführen. Diese Server sollten mit zwei Quad-Core-Prozessoren ausgestattet sein. Die RAM-Größe basiert auf den Empfehlungen von Microsoft für jede installierte Serverfunktion. Jeder CCR-Knoten verfügt über 4 GB RAM, und jeder der anderen Server weist mindestens 2 GB RAM auf, um die Benutzer und Datenverkehrsmuster zu unterstützen. Mit durchschnittlichen Benutzermessagingprofilen sollte die normale Last 35 % - 45 % der CPU auf einem Server mit acht Cores betragen.

Mithilfe von Virtualisierung kann Contoso den gleichen Redundanz- und Verfügbarkeitsgrad mit nur drei Servern zur Verfügung stellen. Jeder physikalische Server führt unter diesen Umständen mehrere virtualisierte Server als Gastcomputer aus. In diesem Szenario stellen drei physikalische Server mit zwei Quad-Core-Prozessoren und 16 GB RAM ausreichende Kapazität für die Benutzer von Contoso zur Verfügung. Jeder der virtuellen Server ist mit zwei virtuellen CPUs konfiguriert. Neben RAM und Prozessoren müssen die Server auch über mehrere Netzwerkadapter und redundante Pfade für die Speicherung verfügen. Da Contoso noch immer die gleiche Anzahl von Servercomputern mit Exchange verwalten muss, entsteht unter dem Gesichtspunkt des Betriebs und der Wartung kein Vorteil, es ergeben sich jedoch Vorteile hinsichtlich Platzbedarf, Strom- und Kühlungskosten.

Die folgende Abbildung zeigt dieses Szenario.

In diesem Szenario ergeben sich durch die Umstellung von sieben physikalischen Servern auf drei physikalische Server und sieben virtuelle Server mögliche Einsparungen von 25.754 kWh und 22.516 US-Dollar pro Jahr. Das Virtualisierungstool von Microsoft wurde verwendet, um diese Angaben zu ermitteln.

Die Skalierung von Exchange für eine Hardwarevirtualisierungsumgebung unterscheidet sich nicht von der Skalierung von Exchange für physikalische Server. Unabhängig davon, ob physikalische oder virtualisierte Server verwendet werden, benötigt jeder CCR-Knoten 4 GB RAM und Speicherplatz für die Unterstützung von 48 IOPS für die Datenbanken und 19 IOPS für die Transaktionsprotokolle. In diesem Szenario sind die IOPS-Anforderungen sehr gering und sollten in einer virtualisierten Umgebung erreichbar sein. Die Verwendung fester virtueller Festplattenlaufwerke ist in Anbetracht der kleinen Anzahl von Benutzern, die auf virtualisierten Servercomputern mit Exchange gehostet werden, für diese Lösung ausreichend. Bei einer größeren Benutzerzahl empfiehlt Microsoft die Verwendung externen Speichers.

Return to top

Remoteorganisation oder Zweigstelle mit hoher Verfügbarkeit

In der Vergangenheit benötigten einige Organisationen lokale Servercomputer mit Exchange in Remoteorganisationen oder Zweigstellen, um ausreichende Leistung für die Benutzer an diesen Standorten bereitzustellen. Durch Optimierungen wie z. B. den Exchange-Cachemodus und Outlook Anywhere wurde die Konsolidierung dieser Server in einem zentralen Datacenter die empfohlene Vorgehensweise.

In bestimmten Fällen ist aufgrund schlechter Netzwerkverbindungen mit Remotestandorten jedoch für einige Organisationen noch immer das Vorhandensein eines lokalen Servercomputers mit Exchange an diesen Standorten erforderlich. Häufig ist die Benutzerzahl an diesen Standorten so klein, dass es nicht sinnvoll ist, einen physikalischen Server für die Exchange-Umgebung zu reservieren. Die technischen Erwägungen sind unter diesen Umständen mit dem oben beschriebenen Szenario "Kleine Organisation mit hoher Verfügbarkeit" identisch. Als Beispiel für dieses Szenario, in dem ein Unternehmen Exchange 2007 SP1 in einer Hyper-V-Umgebung verwendet, können Sie die folgende Fallstudie der Windows Server 2008-Kundenlösungen zum Thema Caspian Pipeline Consortium (englischsprachig) herunterladen.

Wiederherstellung nach einem Notfall

Damit Standortflexibilität und Redundanz für einen Produktionsstandort bereitgestellt werden, benötigen einige Organisationen ggf. einen teilweise ausgestatteten Standort ("Warm Site"), der ein Duplikat der primären Exchange 2007-Produktionsinfrastruktur enthält. Dieser teilweise ausgestattete Standort soll für den Fall des Verlusts des primären Standorts einen Funktionsgrad bereitstellen, der so weit wie möglich mit dem primären Standort übereinstimmt. Die Bereitstellung einer doppelten Infrastruktur aus Standbygründen ist zwar für hohe SLA-Anforderungen (Service Level Agreement, Vereinbarung zum Servicelevel) sinnvoll, kann jedoch für einige Organisationen erheblich zu teuer sein.

Zur Verringerung dieser Kosten ist es möglich, ein Duplikat des gesamten primären Standorts mithilfe von Gastcomputern in einer Hyper-V-Umgebung bereitzustellen. Eine typische Konfiguration eines teilweise ausgestatteten Standorts bei Verwendung physikalischer Servercomputer mit Exchange 2007 umfasst mindestens einen Server, der als Standbycluster konfiguriert ist, sowie mindestens einen weiteren Server, der für die Serverfunktionen ClientAccess und Hub-Transport konfiguriert ist. Damit Redundanz nur der Messagingdienste am teilweise ausgestatteten Standort erzielt wird, sind vier physikalische Server erforderlich. Im Gegensatz dazu kann eine virtualisierte Lösung mit nur drei physikalischen Servern einer Organisation einen teilweise ausgestatteten Standort zur Verfügung stellen, der zwei Postfachserver in einer CCR-Umgebung sowie redundante Clientzugriffs- und Hub-Transport-Server umfasst. Durch die Virtualisierung von Exchange in diesem Szenario können Sie Benutzern einen höheren Grad an Diensten zur Verfügung stellen und im Vergleich zu einer auf physikalischen Servern ähnlich konfigurierten Lösung gleichzeitig den Platzbedarf verringern sowie Hardware-, Strom und Kühlkosten einsparen.

Die folgende Abbildung zeigt diese Konfiguration.

Der primäre Standort verwendet aufgrund der Größe und der anspruchsvollen Messagingprofile der Benutzergemeinde physikalische Hardware. In diesem Szenario soll der teilweise ausgestattete Standort die gesamte Benutzergemeinde vom primären Standort unterstützen. Die Verwendung des teilweise ausgestatteten Standorts ist zwar nur vorübergehend und erfolgt mit verringerter Leistung, dennoch muss die Konfiguration der Umgebung, die die Benutzergemeinde unterstützt, sorgfältig geplant werden.

Die Abbildung zeigt, dass der teilweise ausgestattete Standort ein Standbycluster enthält. Ein Knoten ist als SCR-Ziel (Standby Continuous Replication, fortlaufende Standbyreplikation) für die CCR-Produktionsumgebung konfiguriert. Ein Paar von Domänencontrollern wird ebenfalls bereitgestellt. Das SCR-Ziel ist ein Standbycluster mit zwei Knoten. Im Fall eines Standortfehlers wird der Standbycluster mithilfe von Restore-StorageGroupCopy aktiviert, dann wird der Postfachclusterserver (Clustered Mailbox Server, CMS) mithilfe des Schalters Setup /recoverCMS wiederhergestellt. Die gleichen Verfahren für die Wiederherstellung nach einem Notfall mithilfe eines Standbyclusters gelten noch immer, obwohl es sich beim Standbycluster um einen Gastcomputer in einer Hardwarevirtualisierungsumgebung handelt. Nachdem der Standbycluster online geschaltet wurde und den Postfachclusterserver vom fehlerhaften Standort hostet, wird der Clientzugriff auf Messagingdienste und Daten wiederhergestellt, nachdem die DNS- und Active Directory-Replikation aufgetreten ist.

Der teilweise ausgestattete virtuelle Standort muss in der Lage sein, ein ausreichendes Leistungsniveau für Benutzer im Fall des Verlusts des primären Standorts bereitzustellen. Dabei ist bekannt, dass ggf. ein geringeres Leistungsniveau aufgrund der WAN- bzw. Internetverbindungen mit dem teilweise ausgestatteten Standort besteht. Da der Standort jedoch nur für einen kurzen Zeitraum für die Bereitstellung von Notfallfunktionen vorgesehen ist, sollte dieses geringere Leistungsniveau akzeptabel sein. Sie sollten sich jedoch bewusst machen, dass während des Ausfalls des primären Standorts keine Standortflexibilität für den teilweise ausgestatteten Standort verfügbar ist.

In diesem Szenario ergeben sich durch die Umstellung von acht physikalischen Servern auf drei physikalische Server und acht virtuelle Server mögliche Einsparungen von 33.005 kWh und 28.225 US-Dollar pro Jahr. Das Virtualisierungstool von Microsoft wurde verwendet, um diese Angaben zu ermitteln.

Return to top

Mobiles LAN

Manchmal muss ein Unternehmen, eine Agentur oder eine Behörde eine Netzwerkinfrastruktur planen, die an bestimmten Standorten kurzfristig bereitgestellt werden kann. Diese Infrastruktur wird dann über Satellit oder eine andere WAN-Remotetechnologie mit dem Netzwerk der Organisation verbunden. Eine nicht behördliche Organisation muss z. B. ggf. auf einen Notfall reagieren und lokale Server einrichten, um der betroffenen Benutzergemeinde Dienste zur Verfügung zu stellen. Diese Teilmenge von Servern müsste vollständig in sich abgeschlossen und in der Lage sein, dem Personal an Zielstandort alle erforderlichen Dienste zur Verfügung zu stellen.

Unter solchen Umständen muss das mobile LAN leicht zu transportieren sein. Es muss einen kleinen und hocheffizienten Formfaktor aufweisen, alle erforderlichen Dienste der lokalen Benutzer bereitstellen und gleichzeitig den kleinstmöglichen Platzbedarf haben. Aufgrund der möglichen Entfernung der Standorte, an denen das mobile LAN bereitgestellt wird, muss es außerdem Fehlertoleranzfunktionen zur Verfügung stellen, damit sichergestellt ist, dass keine einzelne Fehlerquelle an einem Standort auftritt, an dem Ersatzteile ggf. schwer zu beschaffen sind.

In diesen Szenario kann ein Hyper-V-Server als Host für Exchange-Dienste, Dateiserverdienste und Domäneninfrastrukturdienste mit einem kompakten Formfaktor verwendet werden.

Die folgende Abbildung zeigt eine mögliche Konfiguration für einen Hyper-V-Server, der als Host für die Exchange 2007- und Domäneninfrastruktursysteme fungiert. Aufgrund der Eigenschaften dieses Szenarios wurde keine der Exchange-Serverfunktionen auf dem gleichen Gastcomputer kombiniert.

Die Abbildung zeigt eine umfassende Netzwerklösung für eine Organisation, die verlangt, dass alle erforderlichen Serverdienste unabhängig vom Standort lokal bereitgestellt werden. Die Lösung ist so klein wie möglich und erlaubt dennoch einen hohen Grad an Fehlertoleranz und Systemverfügbarkeit.

Das Gestell muss außerdem die erforderliche Netzwerkinfrastrukturausrüstung enthalten, um die Hypervisor-Stammserver und die Arbeitsstationen zu unterstützen. Die Hypervisor-Stammsysteme verwenden ein iSCSI- oder ein Fiber Channel-SAN. Das SAN sollte eine ausreichende Anzahl von Spindles besitzen, um die erforderliche Leistung für die Gastsysteme bereitstellen zu können. In diesem Szenario passen alle Komponenten in ein einzelnes 42U-Gestell.

In diesem Szenario ergeben sich durch die Umstellung von 14 physikalischen Servern auf drei physikalische Server und 14 virtuelle Server mögliche Einsparungen von 91.012 kWh und 73.891 US-Dollar pro Jahr. Das Virtualisierungstool von Microsoft wurde verwendet, um diese Angaben zu ermitteln.

Return to top

Technische Checklisten

In jedem der oben beschriebenen Szenarien währen die Ressourcen nicht genügend ausgelastet, wenn Exchange auf physikalischer Hardware bereitgestellt würde. Sie können mithilfe der folgenden Checklisten ermitteln, ob Ihre Exchange-Umgebung ein möglicher Kandidat für die Konsolidierung ist. Wenn Sie anhand dieser Checklisten feststellen, dass Ihre Hardware unzureichend ausgelastet ist, sollten Sie die folgenden möglichen Aktionen in Betracht ziehen:

• Wenn es sich um eine kleine Organisation handelt, sind Sie mithilfe von Virtualisierung ggf. in der Lage, den Aufwand für physikalische Server auf bis zu drei physikalische Server mit vollständiger Redundanz der Exchange-Funktionen zu verringern.

• Wenn sich die nicht ausgelastete Hardware in einer Zweigstelle oder einem Remotestandort befindet, die bzw. der nicht in einem zentralen Datacenter konsolidiert werden kann, sind Sie ggf. in der Lage, den Aufwand für physikalische Server am Standort mithilfe von Virtualisierung zu verringern.

• In anderen Szenarien möchten Sie die Exchange-Umgebung möglicherweise schlanker gestalten, indem Sie erneut überprüfen, wie optimal das Verhältnis zwischen der Serverkapazität und der Benutzerlast ist. Sie können die Anzahl der physikalischen Server verringern, um die Auslastung auf den gewünschten Grad zu steigern. In diesem Szenario ist keine Virtualisierung erforderlich.

Denken Sie daran, dass nicht ausreichend ausgelastete Hardware einfach bedeutet, dass Ihre Exchange-Umgebung überschüssige Kapazität aufweist. Dieses Situation kann sich absichtlich (zur Abdeckung von Auslastungsspitzen oder aufgrund erwarteten Wachstums) oder zufällig ergeben. Ein gewisser Grad überschüssiger Kapazität ist wünschenswert. Diese Tatsache wurde in den folgenden Checklisten berücksichtigt.

Checkliste Nr. 1 – Leistungsindikatoren

Die folgende Checkliste nennt die zu überwachenden Leistungsindikatoren, die ggf. Hinweise darauf geben, dass die Exchange-Umgebung nicht ausreichend ausgelastet ist. Diese Leistungsindikatoren müssen auf physikalischen Servercomputern mit Exchange erfasst werden, nicht auf virtualisierten Servercomputern mit Exchange. Da die Planung der Exchange-Infrastruktur auf der Serverfunktion Mailbox basiert, verwenden die Checklisten unten hauptsächlich die Messwerte des Postfachservers.

Es wird empfohlen, jeden dieser Leistungsindikatoren in regelmäßigen Intervallen über einen Mindestzeitraum von einer Woche zu erfassen. Nachdem die Daten erfasst wurden, können Sie die Ergebnisse mit den erwarteten Werten vergleichen. Wenn die beobachteten Werte geringer als die unten erwarteten Werte sind, ist Ihre Serverhardware nicht ausreichend ausgelastet.

Die Leistungsindikatoren in der Checkliste stammen aus Überwachung ohne System Center Operations Manager. Sie müssen unbedingt sicherstellen, dass Ihre Server überwacht werden, nachdem sie in die Produktion übergeben wurden.

Checkliste für Leistungsindikatoren

Return to top

Checkliste Nr. 2 – Benutzerprofilfaktoren

Ein weniger zeitaufwendiges (und ungenaueres) Verfahren für die Feststellung einer geringen Auslastung Ihrer Server besteht im Vergleichen der Prozessor-Cores mit Benutzerprofilen. Zu diesem Zweck werden die allgemeinen Skalierungsrichtlinien verwendet, die in Planen von Prozessor- und Speicherkonfigurationen bereitgestellt werden. Wenn Sie das Benutzerprofil Ihrer Organisation ermitteln möchten, verwenden Sie die Benutzerprofiltabelle in diesem Artikel (die Sie außerdem auch weiter unten finden).

Wie bereits in Planen von Prozessor- und Speicherkonfigurationen beschrieben wurde, gilt als Faustregel für die Skalierung, dass 1.000 aktive Profilpostfächer des Typs "Mittel" einen Prozessor-Core erfordern. Beispiel: Ein Server mit 4.000 Postfächern und einem Verwendungsprofil des Typs "Durchschnittlich" erfordert vier Prozessor-Cores. Für ein Auslastungsprofil des Typs "Hoch" sind mehr Prozessorzyklen als für ein Profil des Typs "Durchschnittlich" erforderlich. Verwenden Sie für Planungszwecke daher 750 aktive Postfächer mit einem Auslastungsprofil des Typs "Hoch" pro Prozessor-Core. Mithilfe dieser Logik kann in der folgenden Checkliste zusammengefasst werden, wie viele Benutzer erforderlich sind, um einen Prozessor-Core vollständig auszulasten:

Checkliste für Benutzerprofilfaktoren

Da die empfohlene Anzahl durchschnittlicher Benutzer 1.000 pro Prozessor-Core beträgt, zeigt eine aktive Benutzergemeinde mit maximal 500 Postfächern mit einem Profil des Typs "Durchschnittlich" an, dass nicht genügend Benutzer vorhanden sind, um den Prozessor-Core eines Postfachservers vollständig auszulasten. Bedenken Sie, dass für physikalische Servercomputer mit Exchange acht Prozessor-Cores die maximale Anzahl von Cores darstellen, die von der Serverfunktion Mailbox effizient genutzt werden können (siehe Planen von Prozessor- und Speicherkonfigurationen). Durch die Bereitstellung von Postfächern auf Servern mit mehr als 8 Cores werden keine wesentlichen Verbesserungen der Skalierbarkeit erreicht.

Wenn Sie diese Checkliste zum Abschätzen der Anzahl der Prozessor-Cores des Postfachservers verwenden, besitzen Sie einen guten Ausgangspunkt für die Überprüfung anderer Exchange-Serverfunktionen, weil die Planungsmethode für die Exchange-Infrastruktur für Hub-Transport- und Clientzugriffsserver teilweise auf dem Verhältnis von Prozessor-Core und Postfachserver basiert (Postfachserver:Hub-Transport-Server und Postfachserver:Clientzugriffsserver). Das Verhältnis von Postfachserver:Hub-Transport-Server ist z. B. 5:1, wenn die Hub-Transport-Server Transport-Antivirussoftware ausführen, und 7:1, wenn die Hub-Transport-Server keine Transport-Antivirussoftware ausführen. Wenn eine Benutzergemeinde wahrscheinlich einen Postfachserver-Prozessor-Core nicht vollständig auslastet, lastet sie daher wahrscheinlich einen Hub-Transport-Prozessor-Core nicht vollständig aus. Diese Tatsache kann ein Hinweis darauf sein, dass die Verwendung von Virtualisierung für die Hub-Transport- und/oder die Clientzugriffsserver empfehlenswert ist.

Zusammenfassung

Durch Windows Server 2008 mit Hyper-V und das neuere Produkt Microsoft Hyper-V Server 2008 ergeben sich neue Optionen für die Bereitstellung von Exchange Server 2007 SP1. In vielen Situationen bietet es sich an, Exchange ohne Virtualisierung auf physikalischer Hardware auszuführen, weil eine bessere Verwaltbarkeit und niedrigere Gesamtbetriebskosten (Total Cost of Ownership, TCO) gewährleistet sind. Unter bestimmten Umständen kann die Ausführung einer virtualisierten Exchange-Infrastruktur jedoch echte Vorteile hinsichtlich Platzbedarf, Stromkosten und Bereitstellungsflexibilität mit sich bringen.

Der zu geringe Auslastungsgrad Ihrer aktuellen Hardware ist ein Schlüsselfaktor dafür, ob die Vorteile von Virtualisierung die Komplexität aufwiegen, die durch das Hinzufügen einer virtuellen Schicht unter Exchange entsteht. Die Vorteile von Virtualisierung sind normalerweise für Umgebungen reserviert, in denen die Exchange-Bereitstellung zu klein ist, um die zugrunde liegenden Server vollständig auszulasten. Kleine Exchange-Bereitstellungen, Remotestandorte mit schlechten Verbindungen, bestimmte Wiederherstellungsszenarien nach einem Notfall und mobile LAN-Bereitstellungen sind Beispiele für gute Kandidaten für die Virtualisierung.

In den meisten Organisationen ist Exchange eine unternehmenswichtige Anwendung. Wenn Sie dies beim Entwerfen Ihrer virtualisierten Umgebung bedenken und die Microsoft-Supportrichtlinien und -Empfehlungen für virtualisierte Servercomputer mit Exchange berücksichtigen, sind Sie auf Erfolgskurs.

Weitere Informationen

• Microsoft-Supportrichtlinien und -Empfehlungen für Computer mit Exchange Server in Hardwarevirtualisierungsumgebungen

• Windows Server Virtualization Validation Program(englischsprachig)

• Exchange 2007 – Systemanforderungen

• Exchange 2007 Mailbox Server Role Storage Requirements Calculator(englischsprachig)

• Überwachung ohne System Center Operations Manager

• Server Virtualization with Advanced Management Datasheet (englischsprachig) (PDF-Datei für den Download)