As part of my recent testing with Exchange 2010 on vSphere 4.1, I created a Database Availability Group (DAG) and used it to create copies of the mailbox databases on a VM. To keep things simple I only used a two Exchange 2010 mailbox server VMs for this test: a primary VM and a copy VM. The primary VM was where the active mailbox databases were running handling all of the users requests. The copy VM was only supporting the replicated copy that was created within the DAG.

 

I used the same VMs and server as in my previous Exchange 2010 tests. In the configuration for these tests each VM was configured with 2 vCPU and 24 GB of RAM. The server was a Dell R710 with Intel X5570 processors and 96GB of RAM.

 

 

There were three test scenarios. The first was with both VMs in the DAG, but no database copies created. The second was with only one of the eight mailbox databases replicated to the copy VM and the third test was with all eight mailbox databases being replicated. In all tests 4000 LoadGen 2010 users with the Outlook 2007 Online Heavy profile were run for a full 10 hour test run.

 

 

Of primary concern was if the addition of the DAG group with the replicated databases would affect the performance as seen by end users. The graph below shows the SendMail response time for all three tests with a very small increase in latency.

 

 

http://communities.vmware.com/servlet/JiveServlet/downloadImage/10201/Exch2010DAG_SendMailRT.JPG

 

 

It was also interesting to see what effect on CPU and IOPS would be with the DAG group and active database copies. The graph below shows that the IOPS on the primary VM remained flat and the CPU only increased slightly. It also shows that the work being done on the VM just maintaining the copy is much lower than the primary VM.

 

 

http://communities.vmware.com/servlet/JiveServlet/downloadImage/10201/Exch2010DAG_SendMailRT.JPG

 

 

Overall, the effect of a DAG on the Exchange VM performance was very small with only slight increases in CPU, IOPS, and response time. This must be tempered by the configuration used here, as both the primary and copy VM were running on the same physical host.