TommyAD
Contributor
Contributor

Looking into migrating Exchange and SQL from Physical servers to VMs...thoughts?

Jump to solution

Hi all, I've been using VMs for several years now, however new to using VMWare. I am currently running ESXi 4 on 2 seperate host servers, with about 16 small resource type of apps with no issues. I have heard for years keep the intensive stuff like Exchange and SQL off a guest VM, for perofrmance reasons, but now I am seeing a ton of VMWare articles and showcases pushing this as the thing to do. I have a relatively small environment compared to what they are touting...just wondering if there is anyone out there that has any experiance/thoughts on this? If I did go this route I would likely be looking to buy some of the nicer features instead of just using the free ESXi version.

My current setup uses HP DL360G5 servers that are coming up out of warranty early next year, with the disk subsystem being provided by an Equallogic iSCSI SAN environment, built on a GB isolated network. I was thinking instead of buying the 2 replacement servers I could put the money toward the full version of vSphere with some other goodies it offers.

My Exchange environment is a relatively small number of mailboxes, but larger in size, running 2003 currently with 200 mailboxes at about 300 GB of space. I am planning to upgrade to 2007 or 2010 next year as part of the migration to VM. I know going to the next version will likely involve standing up another server so I could be looking at buying 2 servers instead of 1.

My SQL environment is small to start off with, a single SQL 2005 instance with around 20 DB about 120GB in total size.

The 2 host machines I have are both dual socket quad Xeon processors with 16GB and 24GB of RAM, with less than 50% RAM utilization each...and the processing power is hardly being touched at all.

Sorry its a lot of info, I hope it makes sense to someone...

0 Kudos
1 Solution

Accepted Solutions
amvmware
Expert
Expert

Correct .

You just need to do some storage analysis before virtualising the servers to understand the IO requirements. But if you are moving from local disk storage then any performance loss you may get by virtualising the server is offset by the gains in terms of the SAN storage solution - faster & high performance disks, virtual RAID, active\active controllers, cache ..etc

View solution in original post

0 Kudos
8 Replies
amvmware
Expert
Expert

For Exchange - consider deploying new Exchange servers as VM's and then migrate the mailboxes - this approach is less risky than trying to P2V the server and it means you can move the mailboxes as a phased piece of work. Deploying the Exchange servers as new VM's also means you have clean virtual machines - if you P2V then you will need to clean up the VM and remove software no longer required.

If possible look at performing a virtual assessment to understand the virtualisation requirements of your Exchange & SQL workloads. The tools will also help you with key information such as disk IO and CPU utilisation. The options are VMware Capacity Planner ( VMware partner tool), Platespin or Lanamark you can do yourself - but you have to interpret and analys the results.

The information will enable you to design your virtual disk requirements - this may be VMFS datastores or utilising RDM's.

You also do not need to utuilise the resilience and redundancy features of MS such as clustering as vSphere featrures take care of this for you.

0 Kudos
AlbertWT
Virtuoso
Virtuoso

Great, so in this case can we simply conclude that using VMware Fault tolerance in Exchange Server 2007 Mailbox role can performs better than implementing Cluster Continuous Replication of one VM and the other one is Physical server ?

I'm wondering of which path that is recommended and less hassle to manage.

1. vSphere High Availability

2.OS level clustering service ?

Kind Regards,

AWT

/* Any kind of comment or input would be greatly appreciated */
0 Kudos
TommyAD
Contributor
Contributor

Thank you, I'm sorry I didn't mention in my first post but yes I am planning to stand up new installs and then perform the 2003 to 2007 migration (leaving the original exchange server intact as a physical machine). I guess I am just triyng to find out if there is a significant performance penalty going from physical servers with iSCSI connected data stores, into VMs...and I've heard several different ways to do the guest disk...either with guest based iSCSI initiator access to the LUN or letting the host connect via iSCSI and just have the guest access a .vdmk file.

0 Kudos
hutchingsp
Enthusiast
Enthusiast

At the kind of level you're talking about (we're in a similar position having virtualized almost completely) I think the bottom line is that unless you're doing something in the virtual world that would be stupid in the physical world i.e. too little RAM or slow disks, you'll have no issues.

We do our Exchange and SQL using VMDKs, though that's because we have an FC SAN and the gain using RDM didn't seems substantial vs. the "convenience" of VMDK.

amvmware
Expert
Expert

To use VMDK's or RDM's does depend on various factors including the IO load. I would start with VMFS datstores for the datasbases and log files and if disk performance is an issue then look at RDM's.

TommyAD
Contributor
Contributor

Thank you for the information all. It sounds like even with my large Exchange data size this is very do-able, it's just a matter of getting the right configuration in regards to the datastores.

0 Kudos
amvmware
Expert
Expert

Correct .

You just need to do some storage analysis before virtualising the servers to understand the IO requirements. But if you are moving from local disk storage then any performance loss you may get by virtualising the server is offset by the gains in terms of the SAN storage solution - faster & high performance disks, virtual RAID, active\active controllers, cache ..etc

View solution in original post

0 Kudos
amvmware
Expert
Expert

Tommy

You might find the following useful.

This is my rule of thumb.

  • The virtual machines will be mixed on the datastores to maximise the storage efficiency and I/O efficiency - mix low I/O virtual machines with high I/O virtual machines on the same datastore.

  • A maximum of 12 - 16 virtual machines per VMFS datastore.

  • A maximum of 16 VMDK files per VMFS datastore.

  • One VMFS volume per storage LUN.

  • At least 15% to 20% of a VMFS datastore should be left as free space to accommodate requirements such as virtual machine swap files and snapshots.

0 Kudos