Exchange 2010 als virtueller Cluster

Wer Exchange Server 2010 in einer virtualisierten Umgebung einsetzen möchte, kann dies seit Kurzem auch mit einem VM-Cluster tun (also einem Exchange-Cluster, dessen Knoten virtuelle Server sind). Microsoft hat seine diesbezügliche Support-Policy vor einigen Wochen geändert und im Nachgang noch einige Klarstellungen dazu gegeben.

Update 16. Mai 2011: Microsoft hat seine Support-Richtlinie erneut erweitert. Mit der heutigen Änderung ist Exchange 2010 auch auf Host-Clustern praktisch vollständig supported. Siehe:

[faq-o-matic.net » Exchange-DAG in VM-Cluster jetzt voll supported]
http://www.faq-o-matic.net/2011/05/17/exchange-dag-in-vm-cluster-jetzt-voll-supported/

Vorsicht: Exchange Server 2010 stellt in großen Umgebungen u.U. hohe Anforderungen an die Ressourcen des Serversystems (insbesondere Arbeitsspeicher und CPU). Die Frage, ob eine Virtualisierung überhaupt sinnvoll ist, muss immer bezogen auf das konkrete System beantwortet werden.

Hier das einschlägige Dokument, danach ein paar Erläuterungen dazu.

[Exchange 2010 System Requirements: Exchange 2010 Help]
http://technet.microsoft.com/en-us/library/aa996719.aspx

Relevant ist dort der Abschnitt “Hardware virtualization”.

Dort findet sich folgender Passus:

The storage used by the Exchange guest machine for storage of Exchange data (for example, mailbox databases or Hub transport queues) can be virtual storage of a fixed size (for example, fixed virtual hard disks (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that’s configured at the host level and dedicated to one guest machine.

Wichtig ist außerdem folgende Aussage:

DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

Zusammengefasst bedeutet dies:

• Ein Exchange-Cluster auf Exchange-Ebene (sog. Database Avaliability Group, DAG) darf nur dann auf einem Host-Cluster (also Hyper-V-Cluster, ESX-Cluster, Xen-Cluster usw.) laufen, wenn per Konfiguration für die beteiligten VMs, die die DAG ausführen, kein Host-Failover und kein automatischer (!) Verschiebevorgang auf einen anderen Host (= Hardwareserver, der die Virtualisierung ausführt) möglich ist.
  • Hintergrund: Wenn DAG und Host-Clustering gleichzeitig aktiv sind, könnte es dazu kommen, dass zwei Failover-Vorgänge gleichzeitig stattfinden (Failover auf DAG-Ebene und gleichzeitig Failover auf Host-Ebene). Das würde zu undefinierten Zuständen führen und könnte Daten- oder Funktionsverluste nach sich ziehen. Daher muss für die VMs, die die DAG ausführen, im Host-Cluster das Failover deaktiviert sein. Die DAG selbst wird natürlich ganz normal für den Failover eingerichtet – damit hat sie die alleinige Steuerung bei einem Ausfall.
  • Meiner Kenntnis nach lässt sich das in allen Virtualisierern so einrichten.
• Die Daten-Laufwerke, auf denen die Exchange-VMs die Exchange-Datenbanken ablegen, dürfen vom SAN kommen und per iSCSI direkt in die VM eingebunden sein oder aber als “Pass-through storage” eingebunden sein. Hinter letzterem verbirgt sich die Technik, dass die LUN tatsächlich an den Host angebunden und dann an die jeweilige VM weitergereicht wird.
  • So erklärt sich in diesem Fall auch der in dem Artikel stehende Begriff “SCSI pass-through storage”: Die VM weiß nichts über die tatsächliche technische Ansprache der LUN. Aufgrund des Mappings sieht sie ein SCSI-Device, mit dem sie SCSI spricht.
  • In anderen Virtualisierern hat diese Technik andere Namen, bei VMware etwa heißt sie “Raw Device Mapping”.
  • De facto kann die LUN deshalb mit einer beliebigen, für Windows zugelassenen Technik an den Host angebunden sein: Also per Fibre Channel (FC), Fibre Channel over Ethernet (FCoE), iSCSI oder anders.
  • Wichtig ist, dass die Cluster-Validierung fehlerfrei verläuft.

Alle Aussagen in diesem Artikel sind ohne Gewähr! Verbindlich sind ausschließlich die Aussagen, die von Microsofts Support selbst getätigt werden!
(Die hier dargestellte Interpretation wurde mir allerdings am 19. Juli 2010 vom deutschen Microsoft-Support bestätigt.)