Part 31: My vCloud Journey Journal – Adding Organization vDC (Reservation)
I’ve been working my way making different types of Organizational Virtual Datacenter. Primarily I’ve been focusing on just one of my Organization the Corporate Headquarters of my made-up company, Corp, Inc Holdings. I want to move away from this Organization and start with a “fresh” one to look at the final “resource model” for vDCs. So in this case I select the “Corp Investment Overseas Group” or CIOG Organization. In typical dyslexic fashion I’ve got my abbreviations a bit muddled. Should it be “Corp Investment Overseas Group” or “Corp Overseas Investment Group”? If you look at my previous screen grabs you will see sometimes the labels read CIOG or COIG! Fortunately, the Organization I’d created for CIOG was empty – so it was relatively easy to blast it it away and re-create it. But there’s message there for dyslexics everywhere…
As you might know when you create a Organization Virtual Datacenter – you asked to assign either a Pay-As-You-Go, Allocation Model and Reservation Model. Well, actually vCD calls these “pools” – but I prefer to use the term “models” because they are really different ways of modeling resource consumption, and guiding tenant/consumer behaviour. Plus there are lots of pools elsewhere which some might find a bit confusing/overwhelming – although in essence by selecting a Provider Virtual Datacenter (I selected my Gold Provider vDC) the creation of a new Organization vDC is accompanied by the creation of a new resource pool on DRS enabled vSphere Cluster [or resource pool within resource pools if you used resources pools for your Provider vDC – think of this as form of vCD “inception” where only folks able to sustain their sanity with pools within pools within pools can hope to come out alive!]
So I decide to create “Production” Virtual Datacenter for the COIG Organization using the “Reservation Model”…
The model gets its name because it literally carves out, and guarantees a chunk of CPU/Memory Resources from the Provider vDC. It’s then up to the Organization Admin and the vApp folks to control how much over-commit they allow on a vApp by vApp basis. One of things I like about this – is the “offloading” of the over-commitment question to the tenant. As the SysAdmin its one thing less for me to worry about. However, I just so happen to be the Organization Admin, Catalog Author and vApp Author as well – so really I’m just offloading the problem back to myself! But to be serious at this level its like I’m carving out a chunk of resource and saying to my underlings – get on with it. It means if they run out of resources its there problem because of how they have consumed them. Whether that shakes out in the real world is moot. I assigned the resources, and if they have run out – there’s a good chance they will come back for more. But at least I know on my side of the fence I’ve made guaranteed commitment that I can know I can meet. I can offer these guys 15GB of RAM and know for definite that 15GB is what they are gonna-git (unlike Forest Gumps box of chocolates for instance). The other thing I like about the “reservation model” is how simple is. Being a simple person and not at all “high functioning” the more stupid the configuration the more likely that stupid person like me will understand it. Okay, I’m being inordinately falsely modest about my intellectual abilities – but I’m think of the age old principle – KISFPLM. Keep it Simple For Stupid People Like Mike.
However, I do perceive “risks”. There’s a good chance I could wind-up assigning more resources to COIG “Production” Virtual Datacenter more than they actually need, and artificially “orphaning” memory and CPU resources that could have been allocated elsewhere. Sure, I could dial these values down. But if I enter into agreement with tenant to provide a certain QoS at certain price – they might not take kindly to me moving the goalposts midway through the match. So the other thing I’m thinking is that is one of THE most conservative allocations models you could have for da cloud. If I’m guaranteeing 16GB of RAM that’s like me buying 4x4GB boxes and saying their you go. But maybe this is precisely the sort of conservative policy that might appeal to cloud naysers and doom-and-gloomsters. After all – we all know Application Owners ALWAYS overstate how much resources they will need. They keep on saying this despite us telling, and it being demonstrated it is not the case.
I see this reservation model is being one of the most expensive models because it offers to my tenents the highest quality of service they could expect. For that reason I decided to limit COIG Production Virtual Datacenter to being only able to access the top teir of my storage:
Additionally, I turned off Thin Provisioning & Fast Provisioning. I figure if these ultra-orthodox application owners figure that memory-commitment and TPS are voodoo-technologies, they probably think thin-provisioning and fast-provisioning are awful evil sins of storage too. At the end of the day they will get what they pay for – and if they want the absolute best with maximum guarantees – then who am I as the Provider to deny them these privileges? Or deny myself the right to bill them for the pleasure.
I must admit that does with me a mix of Organizations using a mix of different resource allocation methods.
I guess there’s no problem in doing that. After all different Orgs are likely to have different views of what type of model suits their business needs. From my perspective these different models/methods are being served up from the SAME physical resources fundamentally. That does make me a little anxious that I’m playing one Organization off another – so COIG might be getting a bigger/better bite of the apple. That might be regarded as some as being unfair. If they can make the business case, and if they generate the financial revenues that justify the costs incurred – and so long as it them who incur those costs then what’s the problem…?
This kind of concludes for me a cycle of creating different types of Organization and Organization vDCs and Organization Networks.