CPU Shares

[DFN]

I have 4 IIS and 3 SQL machines in my cluster. I have the IIS on one blade, the SQL on a second blade, and a third blade in case one failes.

Two questions:

1. How do I configure CPU shares if I want the IIS to always have maximum CPU that they will ever need.

2. How do I prevent, during failover that all the IIS move to the s tandby blade and not the SQL blade. Reason for this is that each IIS requires full 2 pCPU to run or else the applications fail. So if the blade has 8 procs, then 4 IIS need all 8 so the IIS machines can never share space with the SQL servers.

Thanks,

Dave

[mcowger]

1) You wouldn't do it with a share, you would do it with a reservation of X MHz.

2) Set an anti-affinity rule in the DRS cluster settings.

--Matt

[DFN]

Hi Matt,

I'm new to this and just curious as for part 2. All I see for rules is "keep them seperate" or "keep them together". Am I missing something?

[RParker]

That's what he meant "keep them separate".

[patrickds]

2. How do I prevent, during failover that all the IIS move to the s tandby blade and not the SQL blade. Reason for this is that each IIS requires full 2 pCPU to run or else the applications fail. So if the blade has 8 procs, then 4 IIS need all 8 so the IIS machines can never share space with the SQL servers.

If you set reservations in the resource pool for the IIS machines, DRS will take care of the placement of VMs in case of a host failing.

With 3 hosts, 8 cores each, you have a total of 24 cores.

Set a CPU reservation for the IIS servers to equal 2 cores, so 8 cores total.

Let's say SQL can manage with 1 CPU's worth: 3 cores.

This gives you a total of 11 cores worth used out of 24 available.(or 16 active, 8 standby)

In case 1 host fails, you will still have 16 cores, more than enough.

Just let DRS manage the placement, it will automatically start VMs on the host which can provide its reserved amount of CPU cycles.

You do realize that there is no point in having 1 standby host?

You need all 3 in the cluster to be able to use HA, so DRS will always try to move VMs to the standby host.

Although you can prevent automatic migartions, when you power down and restart a VM it will almost certainly get started on the empty host.

Ans using all hosts will optimize performance by distributing CPU and memory resources, but also, and probably more importantly, i/o resources.

[DFN]

Great detail with very personalized informatin. Question as a follow up then marking you for correct answer:

I thought reservations were only for total Mhz. Can you set on "core" level? Or do you mean that if I want the thing to use 2 x 2.33Ghz I set the minimum reservationi to 4.66? Or am I missing how to just say "minimum reservation of 2 cores..."

[patrickds]

No, you set it to MHz.

I'm just counting in 'cores' because its easier to make the point.

just replace the word 'core' by whichever amount of MHz your CPU cores have.

[azn2kew]

I would create a resource pool for both IIS and SQL and that resources will be assigned and guaranteed. In case any resources being idled, these servers can still utilize it at anytime if it idling. You can set your VMs to behave if it failed it will move to specified Host, Shutdown behavior, or priority for startup or also seperate the VMs among others. Edit your cluster settings to play around...Look in to your VI client for details.

"The Power of Knowledge"

[patrickds]

I know you can do all that.

Problem with using a resource pool is that resources are reserved for all the VMs in the pool, so you cannot guarantee resources for any specific VM when it gets migrated.

Moving a VM to a specific host in case of a failure could prove difficult if DRS moved your VMs around and the specified host doesnt have enough resources anymore, in which case the VM will get started on the other available host anyway.

I prefer to the least amount of tweaking and editing options, to keep my infrastructure transparent and easy to rebuild in case of a disaster.

In my opinion and experience DRS and HA work best if you just let them do their jobs.