[Note: This article was written before the recent death of Margret Thatcher.]
One of the concepts I’ve been struggling with (from the very start of my journey) is the idea of Organizations, Organization Virtual Datacenters and Leases. Now, don’t get me wrong. I do understand them completely. But the “design” struggle is centered around where leases get applied, rather than the concept of leasing. I guess this blogposts is much a tale about how in life/IT before we really know a technology we build up in our minds a mental map of “how we think it should work”. That’s an essential part of the learning process – the trouble is when your “how you think it works” is at odds with “how it actually works”. The concept of the lease it a pretty striaght forward one – but for the uninitiated… The leases allow you set period of time for which VMs/vApps can be powered on (runtime lease), and once they have been powered off (either by the expiration of the lease, or when the tenant powers off a VM) the storage lease. When the storage lease expires the vApps can be moved to the “Expired Items” container or deleted… The same goes for templates in the catalog as well, they can be given a lease duration…
My trouble from a design perspective is WHERE these settings are applied. They are applied to the Organization, not the Organization Virtual Datacenter within the Organization. A fact I rather glossed over when I first started my journey, and one chose to ignore during the start of my original journey. That’s always a bit dangerous… “oh, that doesn’t seem right to me” you say “I’ll just ignore that elephant in the room, and come back to it later”. Mmm, perhaps not the wisest move in the book…
Back then I created four Orgs – CorpHQ, COIG, Quark and iSTOXS. These are individual businesses that part of my fictitious Evil Global Corporate called “Corp Holdings, Inc.”. This OrgChart will give you an idea of the structure of the business/vCloud Director.
The Green is my representation of the Holding Company. This object doesn’t exist in vCloud Director – although it could as an “empty org” used to facilitate the publishing of catalogs. In the end I did that with the CorpHQ Org. The Blue boxes represent my Organizations, and the Red boxes represent my Organizational Virtual Datacenters. This is all very logical, and represents my “how I think it works” viewpoint. HOWEVER here’s the design “problem”, because the “lease” setting is actually set at the Organization level NOT the Organization Virtual Datacenter level – this presents an issue in my design. If I keep the default lease of 7-days and 30-days it would affect my Test&Dev vDC (which is fine) AND my Production vDC (which is not appropriate). Now I DON’T think this “problem” is an error in vCloud Director, but rather an “error” in my own self-imposed ideas of what I thought an Organization was. I mapped the Org concept to a business unit – not an department or Organization unit within one of my companies within the holding group. I think my mistake was a misplaced desire to create a nice tidy heirarchy. Incidentally, I still like this approach. It makes taking stuff from the “Test&Dev” world to the “Production” world very easy – but sadly its at odds with the design of vCloud Director.
I have analogy for this situation – I like to think this a bit like market forces. Margret Thatcher once pronounced that “You cannot buck the market“.Despite my generally dislike of her politics, I’d have to admit that on this subject I think she was right. When ever a government tries to take on the market – like pumping loads of taxpayers money into the market to prop-up the currency. It’s doomed to fail or to be a VERY expensive proposition. Because if the market thinks your stock or currency is worth-less than you think – generally they win. There’s more folks speculating on a given share or currency values (and more money as consequence) than most governments have lying around in their Federal Reserves. Perhaps if the Conservative Government had listen to their own former leader “Black Wednesday” wouldn’t have happened.
But I digress… My point here is the same thing really. Much though I think vCD should work like X, the fact is that it works like Y. By trying impose my own ideas on how an Organization should work, I stored up a heap of trouble for myself. The above Org and OrgVDC structure actually creates a heap of problems. For example the unpleasant situation where production VMs would get powered off by 7-days if I retained the default lease. I guess there is another option which is turning off leases all together (which is what I’ve done). But that seems to be a bit of shame. The whole point of cloud and leases is especially attractive in Test&Dev environment where folks have tendency to spin-up VMs, and the never shut them down or archive them. I guess there’s another direction as well – a bit more extreme which is make your production VMs subject to a lease as well, say 12 months. In effort to stop VM sprawl – after all sprawl comes with the twin evils of no-approval mechanism or an audit that ceaselessly asks – do we still need this. I doubt that many here would accept the idea of leases on production VMs. It would be seen as too risky, too radical a notion. Does that attitude reflect an ingrained conservative mindset amongst people who manage physical/virtual infrastructure. Perhaps…
So if I can’t “buck the market”, and must accept the realities as I find them. What’s a more appropriate design for Corp Holdings, Inc.
So in this case the “Organization” represents not the business within the holding company, but the Organizations that make up those business – crudely delimitated as Dev and Prod. For a bit of realism I’ve created Organization Virtual Datacenters within each Org. So the Dev Organization have Test/Dev and the Staging/UAT (whether you need a separate vDC for this is debatable). Must admit I was rather trying hard to create MULTIPLE vDC in each Org – thats because an Org with only one vDC looks a bit “stupid” and overkill. But I must remember that Organizations do other things – like acts as logical domain for permissions and rights and so on – they’re not just about leases. There other features of an Org to consider as well. The Production Orgs were easier to “justify” with the different vDC getting their resources from different Providers Virtual Datacenters (an object that points to the cluster(s) within vSphere). In the older model a single Test&Dev vDC was pointed at the Silver Provider and single Production vDC was pointed at the Gold Provider. This newer model is somewhat more pleasing – because it means that within production I can offer different tiers of compute – and those different tiers of compute can be back by different types of storage & storage features – for example in “Gold” the clusters have 2GB connections to FC-Storage on my NetApp2040s with SnapMirror replication every 5mins…
Of course, this second model is more admin. When you create an Org in vCloud Director you creating a logical boundary – so each one would need to be configured for LDAP – either using a central directory service delimited by OUs or a dedicate director service for each Org. Do people do that. Do people “silo” their LDAP in this way – Production LDAP domain and Test/Dev Domain. It does mean you can have radically different security/password policies – and they child-domains in the same tree such as testdev.corphq.corp.com or different trees for each BU testdev.corphq.com. I guess this question depends on who you are. For the Service Provider the Org is boundary between one customer another – and they don’t see the underlying LDAP model. Configuring LDAP on a per Org basis is admin intensive, and probably makes more sense for them – to have an LDAP space that merely separates each tenant on an OU basis.
Oh dear, I sense another rabbit-hole. Time to run away before it all gets too complicated eh? 😉