Thou shalt not use Resource Pools as Folders ... no .. really .. don't

jibbajabba

So why is this a (really) bad idea.

I think most companies I have worked for doing that. I am surely guilty of doing it myself.
I prefer the cluster view but still want to separate VMs. Folders won't work on VM level (unless of course you are in the VM view) so people tend to use Resource Pools.

In most environments it probably doesn't even matter. I worked in big corporates - they don't care if something is slow - they just throw more resources at the VM not fixing the underlying issue. Not realising that bloody resource pools are to blame. Plus they don't care who gets the higher amount of shares - they are all equally important.

Hosting companies - same principal .. Each customer has the same right to the resources, so who cares if one runs slower than the other, right ? Wrong ...

So here an example .. This environment (created Resources Pools in my lab just for the sake of demonstrating the issue as I cannot post screenshots of customer's environments).

In this environment, resource pools are really really bad .. because of the use of vCloud Director. ANd worse worse, because the vCloud Director pool is further down the chain.



So, here is why it is really bad ... two 'Main' Resource Pools.

-- Production
-- Development



So, you got vApps and Resource Pools in the top tree.

Here each vApp and Resource Pool get 16% shares of expandable resources - 16%

Let's go further down the production tree - as this is where vCloud Director sits.

-- Production
---- Clients
---- Own Stuff



Each Resource Pool getting 50% ... that is 50% of 16% ... that's 8% expandable resources !!

Let's go down further into the Clients pool - still chasing that vCloud Director pool


-- Production
---- Clients

---

Non-vCD

---

vCloud Director

Each Resource Pool getting again 50% ... that is 50% of 50% of 16% ... 4% expandable resources !!

And that is when you get errors like that in vCloud Director



So VMware, for the love of vGod, give us folders in the DC view

kj0

You're one Angry man. :P

To be honest, until I read your debate in your VCAP thread, I had never really thought about using them as folders. Smaller environment and fairy easy to manage, but I would just like it if when under a cluster, they kept them under that host - I understand there could be something against HA/DRS moving them. What about several different views.. Folders/Hosts/etc.




Also, love the vCrucial domain - Went to finally spend a day getting it set up and noticed it was down.

Essendon

Dont ya get me started on this! It's beyond me how even experienced folks just dont get this concept and the "Resource Pie Paradox". Never ceases to amaze me.

Another pet peeve I have is the use of reservations and "host failures a cluster tolerates" admission control policy. I have an environment in a far flung area of the country where there's only one junior admin on site, he went in the other day and created 3 SQL machines, all with 32GB RAM, reserved it all, and now cant build any more machines in a brand new cluster! The customer was bawling their lungs out when the distress call came to me. Oh mate!!

kj0

You're going to have to set limits on that kid.

Essendon

You are not wrong kj0!

In this day and age no one should be using the "host failures a cluster tolerates" policy. You are lazy if you do.

jibbajabba

Ah admission control. Indeed another topic. Especially when you got uneven sized hosts and stupid reservations.

HOWEVER, our environment has identical hosts and no reservations at all. I would argue that adminission control can easily used. It would take only memory overhead into consideration anyway - please correct me if I am wrong though

Essendon

Admission Control should almost always be used to ensure HA can restart your machines. The only place where you wouldnt have it enabled is in a lab or something where you'd want to use your hosts to the fullest and not care about a successful restart of your VM's.

Yep, your not wrong

jibbajabba

I mean in my case hosts > %

JeanM

Essendon wrote: »

Dont ya get me started on this! It's beyond me how even experienced folks just dont get this concept and the "Resource Pie Paradox". Never ceases to amaze me.

Another pet peeve I have is the use of reservations and "host failures a cluster tolerates" admission control policy. I have an environment in a far flung area of the country where there's only one junior admin on site, he went in the other day and created 3 SQL machines, all with 32GB RAM, reserved it all, and now cant build any more machines in a brand new cluster! The customer was bawling their lungs out when the distress call came to me. Oh mate!!

HAha, I learned this one while playing around on my pos lab.

kj0

We're lucky we are running only 3 hosts. One host has more than 2x the RAM that all 3 of our old hosts had. N+1 Unlocked with the ability to create 2 or 3 more VMs while everything is running on one host. (although, I would be looking at fixing the other 2 hosts first before building more VMs) :P

Essendon

@kj0 - keep in mind that HA will disregard the larger host for your slot calculations, worst case scenario. If you dont have homogeneous hosts I highly recommend you use %age based admission control policy to derive maximum benefit..

dave330i

If you're not using reservations (most of the places I've consulted aren't), then there's no difference between host failure vs. % based.

jibbajabba

Essendon wrote: »

@kj0 - keep in mind that HA will disregard the larger host for your slot calculations.

Murphy's Law will make sure that this is the host which will fail first which is 90% utilized

dave330i

Essendon wrote: »

@kj0 - keep in mind that HA will disregard the larger host for your slot calculations, worst case scenario. If you dont have homogeneous hosts I highly recommend you use %age based admission control policy to derive maximum benefit..

When using % based admission control, % reserved should be based on the largest host.

kj0

dave330i wrote: »

When using % based admission control, % reserved should be based on the largest host.

Which is fine in our case of all 3 being the same.

jibbajabba

kj0 wrote: »

Which is fine in our case of all 3 being the same.

kj0 wrote: »

We're lucky we are running only 3 hosts. One host has more than 2x the RAM

confused.com

kj0

jibbajabba wrote: »

confused.com

Finish the sentence, it might help.

jibbajabba

kj0 wrote: »

Finish the sentence, it might help.

Lemme try ... confused.com is rubbish and has too many adverts ?

kj0

kj0 wrote: »

We're lucky we are running only 3 hosts. One host has more than 2x the RAM that all 3 of our old hosts had.

Or my sentence.

jibbajabba

kj0 wrote: »

Or my sentence.

I got that - was kidding

kj0

jibbajabba wrote: »

I got that - was kidding

Or was I??


Better be careful, the OP might get upset with killing his thread.


Back on topic, This came up at a good time today, I didn't end up using it as an example, but I had an interview with a cloud provider today and this would have been useful if they had asked some scenario based questions, or even really anything technical.

jibbajabba

kj0 wrote: »

the OP might get upset with killing his thread.

I'd only have to blame myself

Most cloud related jobs I applied for mostly asked basic questions - HA / DRS and the sorts ..