NetApp Tech OnTap
     

Exchange 2010 auf VMware

Wenn Sie die Verwendung von Microsoft Exchange 2010 auf VMware erwägen, gibt es zahlreiche Gründe, die dafür sprechen:

  • Bessere Auslastung Ihrer Prozessorkerne: Große Multicore Server werden allmählich zur Norm, allerdings sind die meisten Applikationen nicht in der Lage, alle Kerne eines physischen Servers auszunutzen.
  • Isolierte Rollen ohne zusätzliche Hardwarekosten: Exchange 2010 hat sich zu einer modularen Architektur mit individuellen Serverrollen entwickelt, einschließlich Mailbox, Edge-Transport, Hub-Transport und Clientzugriff. Durch die Isolierung dieser Rollen lassen sich Fehler bei Exchange einfacher beheben, jedoch ist hierfür eine große Zahl an physischen Servern erforderlich, vor allem in kleineren Umgebungen.
  • Vermeidung von Überdimensionierung: Natürlich ist es schwierig, Ihre zukünftigen Anforderungen an Exchange jetzt schon vorherzusagen. Durch Nutzung von Exchange auf VMware können Sie die passenden Ressourcen jetzt bereitstellen und dann je nach Bedarf schrittweise erweitern, ohne dass Sie Ihr System von vorneherein kostspielig überdimensionieren.
  • Einfachere Erfüllung Ihrer Geschäftsanforderungen: Der genaue Entwurf Ihrer Exchange Implementierung hängt von Ihren spezifischen Anforderungen ab. Benötigen Sie einen separaten Mailbox-Server für jede Abteilung bzw. Unternehmenseinheit? Durch Virtualisierung können Sie dies problemlos erreichen, und zwar ohne zusätzliche Hardwarekosten oder weitere physische Server.
  • Schnelle Bereitstellung eines neuen Exchange Servers: Die Bereitstellung eines physischen Servers benötigt selbst dann Zeit, wenn Sie die erforderliche Hardware schon haben. Mit VMware erstellen Sie einfach Vorlagen für die verschiedenen Typen von Exchange Servern und speichern diese, um später Server desselben Typs schneller bereitzustellen.
  • Bereithaltung einer Exchange Testumgebung: Benötigen Sie eine Testumgebung zum Finden und Beheben von Fehlern bei Exchange? Die VMware Virtualisierung bietet eine ausgezeichnete Grundlage für Evaluierungs- und Testverfahren mit Exchange 2010.
  • Klonen zum Testen und zur Fehlersuche: Mit Snapshot Kopien und Klonen können Sie im Handumdrehen eine bestimmte Exchange VM zur Fehlersuche klonen.

Trotz dieser und weiterer Vorteile höre ich in Gesprächen zu Exchange auf VMware bestimmte Fragen immer wieder. In diesem Artikel werde ich versuchen, Ihnen die häufigsten Sorgen zu nehmen, und einige Best Practices erläutern, mit denen Exchange in verbundenen VMware und NetApp Umgebungen am besten gehandhabt werden sollte.

Gibt es Kundensupport?


Die Frage nach dem Support wird immer wieder gestellt, da Microsoft konkurrierende Virtualisierungsprodukte anbietet. Zwei kürzliche Änderungen an Microsofts Lizenzierungs- und Supportmodell für VMware adressieren zahlreiche der wiederkehrenden Bedenken:

  • Support für Exchange 2010 auf einer VMware Infrastruktur/vSphere: VMware ESX 3.5 Update 2 war der erste Hypervisor, der im Microsoft Server Virtualization Validation Program (SVVP) aufgeführt wurde. Durch diese Zertifizierung erhalten Kunden, die ESX 3.5 Update 2 oder höher (einschließlich vSphere), Windows Server 2008 und Exchange Server 2007 SP1 oder Exchange 2010 nutzen, Zugriff auf den gemeinsamen technischen Support von Microsoft und VMware.
  • Weniger strenge Vorgaben zur Mobilität von Anwendungslizenzen: Microsoft hat sein Lizenzierungsmodell für Exchange aktualisiert, um der Nutzung in einer virtuellen Umgebung besser gerecht zu werden. Die Anwendungslizenzen sind immer noch an physische Server gebunden. Allerdings hat Microsoft die Klausel entfernt, laut der eine Anwendungslizenz nur einmal alle 90 Tage neu zugewiesen werden darf. Somit können Sie die Lizenzierungsvorgaben einhalten und gleichzeitig Virtual Machines migrieren und hohe Verfügbarkeit in einer virtuellen Umgebung gewährleisten.

Zusätzlich zum SVVP haben Sie Anspruch auf direkten Support für virtualisierte Microsoft Anwendungen, wenn Sie sich für das Microsoft Services Premier Support-Programm registrieren. Support steht darüber hinaus über Ihren Server-OEM-Händler, die VMware Global Support Services (GSS) und das Technical Support Alliance Network (TSANet) zur Verfügung.

Weitere Informationen zu verfügbaren Supportoptionen erhalten Sie in dem Lizenzierungsleitfaden Microsoft Exchange 2010 on VMware Support and Licensing Guide.

Welche Performance bietet Exchange auf VMware?


Messbare Performance

Für solch kritische Anwendungen wie Exchange ist weithin bekannt, welche Performance von einem physischen Server zu erwarten ist, jedoch gibt es immer wieder Bedenken zur Performance auf virtualisierten Servern. Überraschungen bezüglich der Performance bei der Virtualisierung von Exchange vermeiden Sie am besten durch einen Blick auf die umfangreichen Performance-Tests von VMware und NetApp. Die meisten Versuche wurden hier zwar mit Exchange 2007 durchgeführt, aber angesichts der deutlichen E/A-Reduzierung von Exchange 2007 auf Exchange 2010 können Sie meiner Meinung nach darauf vertrauen, dass sich die ordentliche Performance von Exchange 2007 auch bei Exchange 2010 einstellen wird.

Abbildung 1 zeigt eine Zusammenfassung der Performance von Exchange auf VMware. Wie Sie sehen, weicht die virtuelle Leistung nie mehr als 5% von der physischen Leistung ab. Selbst bei 4.000 Nutzern erreicht die CPU-Auslastung lediglich 25 %. Die Anzahl an anforderungsintensiven Nutzern skaliert dabei linear mit weiteren hinzugefügten CPUs, sowohl im physischen als auch im virtuellen Fall.

Zusammenfassung der Exchange 2007 Performance in virtuellen bzw. physischen Umgebungen.

Abbildung 1) Zusammenfassung der Exchange 2007 Performance in virtuellen bzw. physischen Umgebungen.

Weitere Details zur Performance-Messung finden Sie in einem aktuellen VMware Whitepaper.

VMware Best Practices

VMware hat umfassende Best Practices zur Verwendung von Exchange in VMware Umgebungen aufgestellt. Diese Best Practices werden nachfolgend zusammengefasst. Vollständige Details finden Sie im Microsoft Exchange 2010 on VMware Best Practices Guide.

Best Practices für Virtual CPUs (vCPUs)

  • Weisen Sie einer Virtual Machine nur dann mehrere vCPUs zu, wenn der zu erwartende Exchange Workload auch tatsächlich alle vCPUs ausnutzen kann.
  • Ist der exakte Workload nicht bekannt, so weisen Sie der Virtual Machine anfänglich eine kleinere Zahl an vCPUs zu und erhöhen Sie diese später nach Bedarf.
  • Stellen Sie für rechenintensive Exchange Virtual Machines (beispielsweise Produktionssysteme) nach Möglichkeit sicher, dass die Gesamtzahl an zugewiesenen vCPUs aller Virtual Machines kleiner oder gleich der Gesamtzahl aller Kerne auf der ESX Host Machine ist.

Best Practices für virtuellen Speicher

  • Sichern Sie nicht übermäßig viel Speicher zu, bevor vCenter anzeigt, dass die Steady-State-Nutzung niedriger als der physische Speicher auf dem Server ist.
  • Stellen Sie die Speicherreservierung auf die konfigurierte Größe der VM ein. Dies führt zu einer VMkernel-Auslagerungsdatei von Null Byte pro VM. Bedenken Sie, dass eingestellte Reservierungen VMotion einschränken könnten.
  • Es ist wichtig, die richtige Größe für den konfigurierten Speicher einer VM zu finden. Wenn die Exchange VMs den konfigurierten Speicher nicht vollständig ausnutzen, bedeutet dies die Verschwendung von Speicherressourcen.
  • Aktivieren Sie das VMware Distributed Resource Scheduling (DRS), damit Workloads im ESX-Cluster gleichmäßig verteilt werden. DRS und Reservierungen gewährleisten, dass kritische Workloads über die notwendigen Ressourcen zum optimalen Betrieb verfügen.
  • Um Auslagerungen bei Gastbetriebssystemen zu minimieren, sollte die konfigurierte Größe der VM größer sein als der durchschnittliche Speicherverbrauch von Exchange in dem Gastsystem. Folgen Sie den Microsoft Richtlinien zur Konfiguration von Speicher und Auslagerungsdatei für Exchange VMs.

Best Practices für Netzwerke

  • Weisen Sie separate NICs/Netzwerke für VMotion, zur FT-Protokollierung und zum Management von ESX-Konsolenzugriffen zu, oder verwenden Sie VLAN-Tagging.
  • Weisen Sie mindestens zwei NICs für den Exchange Produktionsverkehr zu, um die NIC-Teamfunktionen auszunutzen. Allgemein sollten Sie mindestens vier NICs je ESX-Host zuweisen.
  • Nutzen Sie VMXNET3: eine paravirtualisierte vNIC, die mit VMware Tools installiert wird. VMXNET3 ist für virtuelle Umgebungen optimiert und liefert hohe Performance.
  • Zur Unterstützung von VLANs in vSphere muss das virtuelle oder physische Netzwerk die Ethernet Frames mit 802.1Q-Tags markieren, und zwar entweder über Virtual Switch Tagging (VST), Virtual Machine Guest Tagging (VGT) oder External Switch Tagging (EST). Am häufigsten wird der VST-Modus genutzt.
  • Folgen Sie den Netzwerk-Entwurfsrichtlinien im Dokument VMworld 2009 Session TA2105: Virtual Networking Concepts and Best Practices. In diesen finden Sie Designs zur effizienten Verwaltung mehrerer Netzwerke und von Redundanz von Netzwerkadaptern auf ESX-Hosts.

Best Practices für Ressourcen-Management und DRS

  • Die Quell- und Ziel-ESX-Hosts müssen mit demselben Gigabit-Netzwerk und Shared Storage verbunden sein.
  • Hier empfiehlt sich ein speziell für VMware VMotion vorgesehenes Gigabit-Netzwerk.
  • Der Ziel-Host muss über ausreichende Ressourcen verfügen.
  • Die VM darf keine physischen Geräte wie CD-ROM- oder Diskettenlaufwerke nutzen.
  • Die Quell- und Ziel-Hosts müssen kompatible CPU-Modelle nutzen, sonst schlägt die Migration mit VMware VMotion fehl.
  • Zur Minimierung des Netzwerkverkehrs sollten VMs, die miteinander kommunizieren (bspw. Mailbox und GCs), auf derselben Host Machine gehalten werden.
  • VMs mit kleineren Speichergrößen eignen sich besser zur Migration als größere.

Best Practices für Storage

  • Implementieren Sie Exchange VMs auf Shared Storage, um VMotion, HA und DRS zu ermöglichen.
  • Storage Multipathing: Erstellen Sie mindestens vier Pfade von einem ESX-Server zu einem Storage Array (erfordert mindestens zwei HBA-Ports).
  • Erstellen Sie VMFS-Dateisysteme über VirtualCenter, um die Partitionen bestmöglich zu koordinieren.

Best Practices für Performance mit NetApp Storage

NetApp hat weitere Best Practices zur Verwendung von Exchange 2010 mit NetApp Storage aufgestellt. Diese wurden in einem aktuellen Tech OnTap Artikel sowie in einem detaillierten technischen Bericht erläutert und umfassen die besten Methoden zur vollen Ausnutzung aller Vorteile der NetApp Storage-Effizienz.

Beispielsweise kann die Kombination aus NetApp Deduplizierung und Thin Provisioning in Exchange 2010 Umgebungen zu Storage-Einsparungen von 40 bis 60 % führen.

Weitere neuere Arbeiten widmen sich Methoden zur Optimierung der Exchange Performance mit NetApp Storage. So konnte in einem Leistungsvergleich mit Microsoft Exchange 2010 durch Nutzung eines Flash Cache die Anzahl an erzielten IOPs verdoppelt und die Menge an unterstützten Mailboxen um 67 % erhöht werden. Diese Ergebnisse werden im technischen Bericht TR-3867 (Using Flash Cache for Exchange 2010) vom September 2010 genauer ausgeführt.

Wie sorge ich für HA und DR?


Die Erstellung von Konfigurationen für Hochverfügbarkeit (High Availability, HA) und Disaster Recovery (DR) für Exchange 2010 ist in einer virtualisierten Umgebung viel einfacher und weniger kostspielig. Sie haben auf allen Ebenen mehr Möglichkeiten und mehr Flexibilität beim Datenschutz.

Zur Konfiguration von HA und DR müssen Sie zuerst die wichtigen Änderungen verstehen, die Microsoft an seinen nativen Stabilitätsoptionen für Exchange 2010 vorgenommen hat.

Um die Server- und Datenstabilitätsoptionen früherer Versionen von Exchange zu ersetzen, hat Microsoft die Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) implementiert. Die DAG nutzt dieselben Log Shipping-Funktionen, die bei der Cluster Continuous Replication (CCR) in Exchange 2007 eingesetzt wurde. Eine DAG besteht aus 2 bis 16 Mailbox-Servern. Jeder Mailbox-Server kann eine oder mehrere aktive oder passive Kopien einer Datenbank enthalten. Jede Datenbank verfügt über einen separaten Status. Ein Server kann so Kopien von mehreren Datenbanken hosten, wobei sich auch nur einige dieser Kopien gleichzeitig im aktiven Zustand befinden können.

Die DAG verwendet eine neue Exchange Komponente namens Active Manager. Der Active Manager erleichtert Failover und Failback. Im Fehlerfall (einschließlich Fehler im zugrundeliegenden Storage oder in der Storage-Konnektivität) "befördert" Exchange 2010 eine der Datenbankkopien in den aktiven Status. Die Mailbox-Rolle übernimmt dann die Aufgabe, die Mailboxen auf dieser Datenbank zu bedienen. Failover geschieht in weniger als 30 Sekunden.

Schutz vor lokalen Ausfällen

VMware bietet verschiedene Mechanismen zum Schutz der Exchange 2010 Verfügbarkeit vor lokalen Ausfällen.

  • VMware HA selbst kann vor Ausfallzeiten durch lokales Hardware-Versagen schützen.
  • Die Kombination von VMware mit einer DAG schützt sowohl vor Hardware- als auch vor Software-Ausfällen, während gleichzeitig die Zeit, in der sich die Datenbank in einem ungeschützten Zustand befindet, im Vergleich zur alleinigen Nutzung einer DAG verkürzt wird.

Schutz vor standortweiten Ausfällen

Zum Schutz vor standortweiten Ausfällen empfiehlt VMware, den VMware Site Recovery Manager (SRM) mit der DAG-Funktionalität zu kombinieren. Die DAG bietet lokalen Standortschutz, wohingegen Storage-basierte Replizierung wie der NetApp SnapMirror genutzt wird, um einen DR-Standort mit dem Hauptstandort zu synchronisieren. Der NetApp SnapManager für Exchange kann zu Zwecken der Konsistenz für die anwendungsgerechte Replizierung sorgen. Wenn am DR-Standort die Recovery eingeleitet wird, automatisiert und beschleunigt SRM den Recovery-Prozess. Mitarbeiter von VMware und NetApp haben die Details zur DR für Microsoft Applikationen (einschließlich Exchange), die SRM nutzen, in einem aktuellen Tech OnTap Roundtable diskutiert.

Replizierungsarchitektur für SRM mit NetApp SnapMirror und SnapManager Software

Abbildung 2) Replizierungsarchitektur für SRM mit NetApp SnapMirror und SnapManager Software

Diese und weitere Methoden für HA und DR werden detailliert im Dokument Microsoft Exchange 2010 on VMware: Availability and Recovery Options beschrieben.

NetApp Best Practices

NetApp hat verschiedene Best Practices erstellt, die Sie in Exchange Umgebungen mit DAGs im Hinterkopf behalten sollten:

  • Microsoft empfiehlt ein Minimum von drei Kopien für jede Mailbox-Datenbank, um Probleme durch mögliche Storage-Ausfälle, einschließlich doppelter Festplattenausfälle, zu verhindern. NetApp empfiehlt Implementierungen auf NetApp Storage mit RAID-DP, wodurch Schutz vor doppelten Festplattenausfällen gegeben ist und gleichzeitig die Anzahl an Mailbox-Datenbankkopien reduziert wird. Wir empfehlen zwei Kopien einer jeden Mailbox-Datenbank, wenn die Kopien auf RAID-DP liegen.
  • Jede DAG-Kopie ist aktuell und nimmt somit nicht den Platz eines Backups ein. Zur zeitpunktgenauen Wiederherstellung empfiehlt Microsoft eine zusätzliche "verzögerte" Datenbankkopie, mit der zeitpunktgenaue Wiederherstellungen bis zu 14 Tage in die Vergangenheit möglich werden. Als Alternative bietet NetApp den SnapManager für Exchange, mit dem Sie platzsparende Snapshot Kopien erstellen und Wiederherstellungen für beliebige Zeitpunkte ohne verzögerte Kopien vornehmen können.
  • Der Storage für aktive und passive Kopien sollte in Sachen Kapazität und Performance identisch sein.
  • Aktive und passive Kopien sollten in separaten Volumes hinterlegt werden.
  • Führen Sie auf einem der passiven Knoten Backups durch.

Schlussfolgerung

Die Einführungsquote für Exchange 2010 ist hoch und der Virtualisierung wird dabei viel Aufmerksamkeit geschenkt. VMware hat eine umfangreiche Sammlung an Referenzmaterialien und weiteren Ressourcen zusammengestellt, um Sie bei der erfolgreichen Virtualisierung von Exchange 2010 zu unterstützen. Die vollständige Sammlung finden Sie hier. Sie enthält zahlreiche Informationen zur Kapazitätsplanung, Dimensionierung und zu vielen weiteren Themen.

VMware hat außerdem Bemühungen unternommen, Exchange Lösungen gemeinsam mit wichtigen Partnern wie NetApp zu testen und weiterzuentwickeln. In Tech OnTap finden Sie mehrere aktuelle Artikel mit Schwerpunkt auf der Virtualisierung von Exchange und anderen Microsoft Applikationen. (Siehe Randleiste.) Die komplette Sammlung aller NetApp Ressourcen finden Sie auf der NetApp Exchange Seite.

NetApp Community
 Was halten Sie von Exchange 2010 auf VMware mit NetApp Storage?

Stellen Sie Fragen, tauschen Sie Ideen aus und diskutieren Sie mit der NetApp Community!

Scott Salyer

Scott Salyer
Lead Architect – Microsoft Solutions
VMware

Scott gehört der VMware Solution Readiness Group an, die sich auf Best Practices zur Virtualisierung von Microsoft Enterprise-Applikationen konzentriert. Er ist seit Mai 2007 bei VMware und hat zahlreiche Exchange und SQL Server Whitepaper auf der VMware Website zu geschäftskritischen Applikationen verfasst. Bevor er zu VMware kam, arbeitete Scott 11 Jahre lang als Professional Services Consultant mit direktem Kundenkontakt und hat große Kunden bei Entwurf und Implementierung von Lösungen basierend auf VMware Virtualisierung, Microsoft Applikationen und Identitäts-/Zugriffsmanagement unterstützt.

Weitere Infos