Viele werden wohl mittlerweile Exchange Server als Virtuelle Maschinen betreiben. Damit Exchange 2016 auch in einer VM optimale Performance liefert, gibt es ein paar Dinge zu beachten. Die wichtigsten möchte ich hier kurz vorstellen:
Exchange 2016 auf VMware ESXi 5.5
vCPUs:
Bei den virtuellen CPUs gilt: Soviel wie nötig, so wenig wie möglich. Hier hilft der Exchange 2013 Server Role Requirements Calculator weiter. Derzeit gibt es noch keine separate Version für Exchange 2016, die Anforderungen unterscheiden sich aber nur minimal. Wenn es geht, sollte hier darauf geachtet werden, das die VM in einen NUMA Knoten passt. Habt ihr also einen ESX mit 2 CPUs mit je 4 Kernen, dann sollte auch die VM maximal 4 vCPUs haben, und nicht 6.
vRAM:
Auch hier hilft der Calculator, da es hier keine pauschale Aussage gibt. 16 GB RAM würde ich aber als Minimum ansetzen, damit Exchange 2016 vernünftig läuft. Microsoft gibt 8 GB als Minimum an. Auch hier sollte darauf geachtet werden, dass der RAM in einen NUMA Knoten passt. Wie im Beispiel oben, wenn der ESXi 2 CPU Sockel hat und in Summe 64 GB RAM, dann sollte die Exchange VM nicht mehr als 32 GB RAM haben. NUMA ist hier sehr gut erklärt.
vNIC:
Ganz einfach zu beantworten: VMXNet3 benutzen
Storage:
Das wird schon etwas schwieriger zu beantworten. Hier gilt es die Best Practises des Storage Herstellers zu beachten. Ein paar einfache Empfehlungen gibt es aber:
Pro Exchange VM 3 virtuelle SCSI Controller benutzen, 1 SCSI Controller für das Betriebssystem und die Swap Partition, 1 SCSI Controller für die Datenbanken und ein SCSI Controller für die Logs. Bei Windows Server 2012 R2 als OS, sollte der Controller für das Betriebssystem den Typ LSI Logic SAS haben. die Controller für Datenbank und Logs den Typ Paravirtual.
Datenbanken und Logs sollten auf unterschiedlichen Volumes gespeichert werden. Ich empfehle VMDKs zu nehmen, das ist flexibler als Raw Device Mappings.
Die VMDKs für alle Volumes sollten Thick-Eager-Zeroed provisioniert werden. VMDKs für die Datenbanken, hängen dann beispielsweise an SCSI Controller 1, VMDKs für Logs an SCSI Controller 2. Die VMDKs sollten sich auf unterschiedlichen Datastores befinden.
Exchange 2016 auf Windows Server 2012 R2
Da wir schon beim Thema Storage sind, es gibt auch ein paar Empfehlungen zum Gastbetriebssystem.
Storage:
Als Dateisystem dient entweder NTFS oder ReFS. Wenn NTFS als Dateisystem zum Einsatz kommt, dann mit 64KB Blocksize und ohne Schnellformatierung
Bei ReFS als Dateisystem ebenfalls ohne Schnellformatierung, die Blocksize ist bereits 64KB. Bei ReFS ist zusätzlich das Integrity Feature für Datenbanken und Logs abzuschalten:
Get-Item DB1.edb | Set-FileIntegrity -Enable $false
Ob die Volumes mit Laufwerksbuchstaben versehen werden oder in Ordner gemounted werden, spielt nur bei der Anzahl der Volumes und Datenbanken eine Rolle. Wer viele Volumes und Datenbanken hat, erstellt lieber eine kleine 2 GB Festplatte und benutzt diese für die Mountpoints. Hier ein Beispiel:
Ein kleines VMDK mit 2 GB, auf dem Volume wird eine Ordnerstruktur angelegt, beispielsweise DB1_EDB, DB1_LOG, DB2_EDB, DB2_LOG usw. In den Ordnern werden dann alle Volumes gemounted.
Page File (Auslagerungsdatei):
Für das Page File, bzw die Auslagerungsdatei am besten ein eigenes Volume anlegen. Die Größe der Auslagerungsdatei wird fest nach folgender Faustformel eingestellt:
Größe des RAM plus 10 MB aber maximal 32778 MB (32GB plus 10 MB)
Bei 16 GB RAM für die VM also 16394 MB für die Auslagerungsdatei (16 x 1024 + 10). Bei 64 GB RAM für die VM, 32778 GB für die Auslagerungsdatei.
Weitere Einstellungen wenn eine DAG verwendet wird
Wenn eine DAG verwendet wird, dann gibt es weitere wichtige Punkte:
vNIC:
Mindestens 2 Netzwerkkarten vom Typ VMXNet3, am besten über seperate Uplinks verbunden. Alternativ seperate VLANs. Eine vNIC für den Client Datenverkehr, eine für die Replikation.
vMotion:
Cluster Heartbeat anpassen um ungewünschte Failovers zu vermeiden:
- (Get-Cluster).SameSubnetThreshold=10
- (Get-Cluster).SameSubnetDelay=1000
DRS:
DRS AntiAffinity Regeln erstellen um die Exchange VMs immer auf unterschiedlichen ESX Servern zu betreiben.
Storage:
Wenn ReFS als Dateisystem zum Einsatz kommt, dann die DAG entsprechend konfigurieren:
Set-DatabaseAvailabilityGroup DAGNAME -FileSystem ReFS
Hi,
ich wollte kurz eine Erfahrung teilen: Ich hab seit einer gefühlten Ewigkeit mit meiner 2016er DAG auf VMware gekämpft. Symptom war, dass ich den Contenindex der DB-Copy in der DAG nicht Healthy bekommen hab. Es gibt dazu diverse Artikel und Lösungsansätze, die hier aber alle nicht geholfen haben, ich hab wir wirklich den Wolf konfiguriert.
Kurzer Rede langer Sinn: erst nach dem ich den Controllertyp für die DB- und die Log-Platte von Paravirtuell zurück auf „LSI Logic SAS“ gestellt hab, ging sofort alles problemlos. Nur, falls noch jemand damit Probleme haben sollte, ist es vielleicht einen Versuch wert.
Wie sieht es z.B. bei einem einzel ESXi Host (v6.0.0U2) mit lokalem Storage aus?
Sollte man da auch die DBs und Logs so aufteilen?
Wir haben bei einem unserer Kunden einen 2x6Core mit 64GB RAM und RAID5 5x900GB 2,5″10k SAS. im Einsatz. Darauf laufen 3VMs (DC-/Fileserver, Backup/vCenter-Server und Exchange 2016 Server). Der Exchange hat folgende Zuteilung: 6vCPU, 32GB RAM, 1x400GB HDD bei 23 Postfächern und einer aktuellen Mailbox-DB-Größe von 114GB. Da wir Performanceprobleme in den Outlook 2010 Clients feststellen, ist die Frage, ob so eine Storageaufteilung etwas bringen würde.
Wenn ja, wie kann man das nachträglich anpassen?
MfG
Ulli
Das hängt natürlich davon ab, wo die Performance Probleme herkommen. So pauschal lässt sich die Frage also nicht beantworten. Es hilft wahrscheinlich sich erst einmal die Leistungsdaten der VM anzuschauen um einen Ansatzpunkt zu erhalten.
Gruß, Frank
Es scheint am Outlook 2010 zu liegen.
Wir haben jetzt testweise bei 2 Usern ein Office 365 v2016 installiert. Da haben wir jetzt keine Performanceprobleme.
Es währe trotzdem interessant zu wissen (generelle Info), ob und wie man die Trennung der DBs und Logs vom System machen kann.
Gruß, Ulli
Hallo Frank,
vielen Dank für die „Super Anleitung“ .
Gehe ich recht in der Annahme, das man das man das auch für Exchange 2013 +SP1 cu9 einsetzten kann.
Danke Gruß und weiter so
Torsten
Hi Torsten,
ja, das kann man 1 zu 1 übernehmen.
Gruß, Frank
Hallo Frank,
wieder mal ein Spitzenartikel!
Ich habe in einem (schon etwas älteren) Artikel von MS gelesen das nur FibreChannel bzw. iSCSI Laufwerke für DBs + LOGs supported werden und wenn diese Voraussetzungen nicht gegeben sind, ein evtl. notwendiger Support nicht gewährt wird.
Ist diese Information noch aktuell bzw. wie machst Du das mit den VMDKs bei Deinen Umgebungen?
Viele Grüße
André
Hi André,
soweit mir bekannt ist, wird kein NFS Datastore supported. Der Datastore muss also mit VMFS formatiert sein. Neben iSCSI und FC, darf aber auch lokaler Storage verwendet werden. Die Entscheidung ob RDM oder VMDK ist daher eher eine technische Entscheidung, supported wird beides. Ich habe für die Exchange Server nur VMDKs auf VMFS Datastores via FC im Einsatz. Es ist immer sinnvoll mal zu testen, wie viele IOs das Storage und SAN verträgt, dann bekommt man ein Gefühl dafür, wann einzelne LUNs überlastet sein werden oder sind. Bei VMDKs hat man dann den Vorteil von Storage vMotion und kann ggf. umschichten. Auch bei voll werdenden Volumes lässt sich ein VMDK schnell vergrößern. Bei RDMs wird das mit unter schwierig. Kurz um: Ich würde VMDKs bevorzugen, das hängt aber sicherlich von der eigenen Umgebung ab.
Gruß, Frank