We've currently got 21 ESXi 4.0 Embedded hosts running 301 guests in 1 DRS Cluster. I know this goes against the 10-15 host best practice maximum, and we intend to split the large cluster into two or three smaller ones.
There are multiple trains of thought regarding what lines we should use to split the hosts:
This is a Dev/QA cluster. There are 135 Dev VMs and 166 QA VMs. Splitting Dev/QA into 1 Dev and 1 QA cluster would see 10 hosts in 1 and 11 hosts in the other. This seems to be the simplest option.
The second option is splitting the guests by OS. There are 210 Linux VMs (121x 64-bit and 89x 32-bit) and 91 Windows VMs (68x 32-bit and 23x 64-bit) CURRENTLY we have Windows Datacenter & RHEL Advanced licensing on every host, which allows us to run whatever VMs on whichever hosts. This isn't particularly cost effective though. As well, I believe that running the VMs of the same OS flavour on the same ESX host will improve performance, especially with TMP in play.
So as a second option would it make sense to split our current cluster into 3 smaller ones, using Linux 32-bit, Linux 64-bit and Windows as guides? We already run our Windows and Linux machines off of different datastores, so that wouldn't be an issue.
I would not split by VMs but by datastores.
Leave half of the hosts and half of the datastores (with the VMs located on them) in the existing cluster
and build a new cluster with the other half of the hosts and the other half of the datastores.
It is best practice that you do not share datastores/LUNs over multiple clusters, so you need to separate the datastores anyway. If you don't want to do a lot of Storage VMotions this is the easiest way to go.
- Check out my VMware Front Experience Blog
As well, I believe that running the VMs of the same OS flavour on the same ESX host will improve performance, especially with TMP in play.
I'm curious if you're referring to TPS (Transparent Page Sharing)? If so, the use of Large Paging (LP) makes this a non issue, as TPS will not break down LPs until a high memory state is reached (96%+) on a host.
It makes sense to break up the cluster from a growth and management standpoint. For me I would lean towards dividing by environment, not operating system.
I'd split it as you have said - Dev and QA - but then move VMs around to also align with the above idea of limiting the storage to the relevant clusters. (try not spanning storage across both clusters)
Lastly, you could then move VMs around on the 2 new clusters to loosely maintain your 'same OS, same Host' idea.
This way, you pretty much address all 3 of the above.
If your Environment is not overloaded, you should not really get much DRS movement so don;t have to do too much tidying up.
Lastly, if you storage has deduplication - you'll want to match Operating Systems on each datastore for max deduplication.
Thanks guys. Our current cluster is not overloaded and I would definitely not span datastores across clusters. However, I do want to keep the same datastore setup methodology within each cluster.. for Linux and Windows we separate system drives, log drives and data drives into different datastores. I will have to mull over your responses