Exchange 2016: Optimization on VMware ESXi 5.5 / 6.0

Many people will now be running Exchange Server as virtual machines. There are a few things to bear in mind to ensure that Exchange 2016 also delivers optimum performance in a VM. I would like to briefly introduce the most important ones here:

Exchange 2016 on VMware ESXi 5.5

vCPUs:

The following applies to virtual CPUs: as much as necessary, as little as possible. This is where the Exchange 2013 Server Role Requirements Calculator further. There is currently no separate version for Exchange 2016, but the requirements differ only minimally. If possible, you should make sure that the VM fits into a NUMA node. So if you have an ESX with 2 CPUs with 4 cores each, then the VM should also have a maximum of 4 vCPUs and not 6.

vRAM:

The calculator also helps here, as there is no general statement. However, I would assume a minimum of 16 GB RAM for Exchange 2016 to run properly. Microsoft specifies 8 GB as the minimum. You should also make sure that the RAM fits into a NUMA node. As in the example above, if the ESXi has 2 CPU sockets and a total of 64 GB RAM, then the Exchange VM should not have more than 32 GB RAM. NUMA is very well explained here.

vNIC:

Very easy to answer: Use VMXNet3

Storage:

This is a little more difficult to answer. The storage manufacturer's best practices must be observed here. However, there are a few simple recommendations:

Use 3 virtual SCSI controllers per Exchange VM, 1 SCSI controller for the operating system and the swap partition, 1 SCSI controller for the databases and one SCSI controller for the logs. With Windows Server 2012 R2 as the OS, the controller for the operating system should be of type LSI Logic SAS and the controllers for the database and logs should be of type Paravirtual.

Databases and logs should be stored on different volumes. I recommend using VMDKs, which are more flexible than raw device mappings.

1

The VMDKs for all volumes should be provisioned thick-ager-zeroed. VMDKs for the databases, for example, are then attached to SCSI controller 1, VMDKs for logs to SCSI controller 2. The VMDKs should be located on different datastores.

2

Exchange 2016 on Windows Server 2012 R2

While we're on the subject of storage, there are also a few recommendations for the guest operating system.

Storage:

Either NTFS or ReFS is used as the file system. If NTFS is used as the file system, then with 64KB block size and without quick formatting

4

With ReFS as file system also without quick formatting, the block size is already 64KB. With ReFS, the integrity feature for databases and logs must also be switched off:

Get-Item DB1.edb | Set-FileIntegrity -Enable $false

Whether the volumes are assigned drive letters or mounted in folders only plays a role in the number of volumes and databases. If you have many volumes and databases, it is better to create a small 2 GB hard disk and use this for the mount points. Here is an example:

7

A small VMDK with 2 GB, a folder structure is created on the volume, for example DB1_EDB, DB1_LOG, DB2_EDB, DB2_LOG etc.. All volumes are then mounted in the folders.

Page File (swap file):

It is best to create a separate volume for the page file or swap file. The size of the swap file is set according to the following rule of thumb:

Size of RAM plus 10 MB but maximum 32778 MB (32GB plus 10 MB)

With 16 GB RAM for the VM, 16394 MB for the swap file (16 x 1024 + 10). With 64 GB RAM for the VM, 32778 GB for the swap file.

Further settings if a DAG is used

If a DAG is used, there are other important points:

vNIC:

At least 2 network cards of type VMXNet3, preferably connected via separate uplinks. Alternatively, separate VLANs. One vNIC for client data traffic, one for replication.

vMotion:

Adjust cluster heartbeat to avoid unwanted failovers:

    • (Get-Cluster).SameSubnetThreshold=10
    • (Get-Cluster).SameSubnetDelay=1000

DRS:

Create DRS AntiAffinity rules to always run the Exchange VMs on different ESX servers.

Storage:

If ReFS is used as the file system, then configure the DAG accordingly:

Set-DatabaseAvailabilityGroup DAGNAME -FileSystem ReFS

8 thoughts on “Exchange 2016: Optimierung auf VMware ESXi 5.5 / 6.0”

  1. 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.

    Reply
  2. 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

    Reply
    • 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

      Reply
      • 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

        Reply
  3. 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

    Reply
  4. 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é

    Reply
    • 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

      Reply

Leave a Comment