Exchange 2010 can be virtualized and this session covers how they did it.

Some of the design points that need to be covered are:

  • DAS vs SAN
  • Scale up or Scale out

The choices made here are arbitrary and dependent on how you manage your datacenter and what you like/don't like.

Their layout is:

  • 4 datacenters, 2 DCs in US & 2 in Europe

  • If they have a DC failure, can run around 25% reduced capacity
  • 3 Hosts per datacenter

  • 2 Hosts are active, 1 failover
  • SAN backend with 1TB 7k rpm SATA disks

How did they do it?

  1. Virtuals are manually balanced across the hosts per role
  2. DRS set to level 1 - don't VMotion naturally
  3. No Reservations
  4. Dedicated Farm versus using the general farm
    • Exchange, all roles, all support systems etc

The Exchange 2010 Role layout is defined per OS instance, minimal sharing here.

CAS Role

  • 4 G, 2 vCPUs
  • VMDK based

Hub Role

  • 4G , 4 vCPUs
  • VMDK based

MBX Role

  • 2000 mailboxes per server
  • 6 vCPU
  • 36G of RAM
  • 3 NIC (MAPI, Backup & Replication)
  • VMDK for OS & Pagefile
  • RDM for Log & DB disks
  • For the 1TB LUN sizes use the 8MB block size format

SAN configuration

  • EMC Clarion CX4, 1TB 7200rpm SAT disk
  • RAID 6
  • Datastores in 8MB
  • Presented as 500GB and 1TB
  • OS, Pagefiles, & Misc Storage are VMDK
  • Logfile & Databases are RDM

LoadGen Physical versus Virtual

They ran some testing with VMware Assistance and the performance numbers were significantly under where Microsoft states are required. In most cases significantly under.

Lessons Learned:

Backups and disk contention as things grew did start to become an issue as load was added. Symptoms would be dropped connections. Moved the backups to the passive copies instead. This addressed much of the concerns.

When doing the migrations, take breaks in between each batch of migrations to iron out any issues. Found problems like pocket of users had unique issues and needed to have time to iron out the gotchas.

Database sizes introduce issues around backup, replication etc. Make sure you can manage them for the demands for your environment.

Some interesting discussions is that Hyper-Threading is not supported for production. It complicates performance discussions by Microsoft. VMware can do either so be sure to follow the Microsoft standards at the VM level.

Memory is a big question. Basically set

Storage.. the main points are make sure you have appropriate IOP capability behind the scenes. The other is if setting up VMDK files, should eagerZeroThick the VMDKs. If you check the box for enabling FT during creatio, this will eagerZeroThick is automatically. Otherwise this should be done when the machine is powered off and run VMKFSTOOLS from the command line.

16 months later...

  • Success doing VMotions and DAG failovers
  • Backups are running lights out
  • Will add more hosts to expand the environment
  • Pain Points:

  • Service Desk new process adoptions
  • Integration with legacy tools in house.

After all is said and done this has done quite a bit for the company.

  1. Datacenter savings
  2. TCO is down and has been passed on to the business
  3. much greater flexibility
  4. Scale out or Scale up very quickly
  5. Lower Administrative overhead so far
  6. More options for disaster recovery and scenarios

Exchange 2010 is possible.