Once again.. another session I didn't sign up with and zero issues getting into.

To start off RIM & VMware have been working together for 2 years and it is officially supported on VMware. Together RIM & VMware have done many numerous and successful engagements running BES on VMware. The interesting thing is RIM runs their own BES on VMware for over 3 years now.

Today BES best practice is no more than 1k users per server and they are not very multi-core friendly. It is not cluster aware or have any HA built in. The new 5.0 version of BES is coming with some HA availability via replication at the application layer. One thing that has been seen in various engagements is if you put the BES servers on the same VMware Hosts as virtualized Exchange, there are noticable performance improvements.

The support options for BES do clearly state that they support on VMware ESX.

One of the big reasons to virtualize BES is that since it can not use multi-cores effectively the big 32 core boxes today are only able to use a fraction. By virtualizing BES can get significant consolidation. Then when doing the virtualization BES gets all the advantages of running virtual such as Test/Dev deployments and server consolidation and HA etc. Things that are well known and talked about already.

BES encourages template use to do rapid deployments. The gotcha is just what your company policies and rules are and can potentially save quite a bit of time. This presentation is really trying to show how to use VMware/Virtualization with BES for change management improvements, server maintenance, HA, component failures and other base vSphere technologies. VMware is looking towards using Fault Tolerance for their own BES servers.

BES is often not considered Tier 1 for DR events. Even though email is often the biggest thing needed to start working after a DR event to start communications. The reason is generally been seen due to the complexity and cost of DR.

The performance testing with the Alliance Team from VMware has been successfully done numerous times for the past couple of years. They have done testing at both RIM & VMware offices. The main goal of these efforts was to generate white papers and a reference architectures that are known to work. The testing was to use Exchange LoadGen & PERK load driver (BES testing driver). Part of this is how to scale outwith more VMs as the scale up is known.

The hardware was 8 cpus, Intel E5450 3Ghz, 16 G RAM and FAS3020 Netapp on vSphere 4 & BES 4.1.6. The 2k user test with 2 Exchange systems the results were 23% CPU utilization on 2 vCPU BES VMs. Latency numbers was under 10 ms. Nothing majorly wrong seen in the testing metrics. Going from ESX 3.5 to vSphere 4 was a 10-15% CPU reduction in the same workload tests. Adding in Hardware Assist for Memory saw what looks like another 3-5% reducting in CPU usage. In their high load testing when doing VMotion there is a small hiccup of about 10% increase in CPU utilization during the cut over period of the VMotion. This is well within the capacity available on the host and in the Guest OS.

Their recommendation is to do no more than 2k users on a 2vCPU VM. If you need more then add more VMs. Scales and performs well in this scale out architecture. Be sure you give the storage the number of spindles needed. The standard statement when talking about virtualization management.

The presenter then went into a couple of reference architecture designs. Small Business & Enterprise with a couple different varieties.

BES @ VMware. 3 physical locations, 6,500 Exchange users. 1k of them have 5G mailboxes and the default for the rest are 2G. BES has become pretty common. They run Exchange 2007 & Windows 2003 for AD & the Guest OS. Looks fairly straight forward.

4 prod BES VMS, 1 STandby BES VM, 1 Attachment BES VM and 1 BES dedicated Database VM. Done on 7 physical servers and 40 additional VM workloads on this cluster.