It would be nice to have this granularity. Do not consider only virtual. A VM may depend on a physical host. So let’s say:
host1.service2 depends host2.service1
etc.

So this datacenter-start-stop system doesnt need to be related to VMware. It should have a module that talked with vCenter/hosts at least. Another module for each operating system, maybe even for management cards (RSA/DRAC/iLO) and IPMI.

Those modules should help write the dependency logic. You should have ways to:
- change/read host on/off status
- change/read service on/off status
- service could be:
– storage (including SAN, iSCSI, NFS)
– network service
– application running
– hardware (network card up?)
—

We have some hosts that use each other’s NFS servers and it’s a little bit messy. I was looking for a solution and hit this page. I mean:
vm1 needs vm2:/share, vm3:/share2
vm2 needs vm4:/share

I think one could use VMware tools custom scripts to say “allow shutdown”/”deny shut down” for a vm. From example above, if I try to shutdown vm4 and vm2 is still up and mouting its vm4:/share, vm4 custom script vm-poweroff should return “deny”, possibly with a error message saying why.

That could be extended. vCenter could ask via custom script (say “vm-depends”) to a vm which vm’s are its dependencies. It’s getting complicated. We would need a way for a vm to say that needs a service and not a vm (think of a DNS service that could be provided by more than one vm and other clustered services).

Found your article again using Google, and again I can’t agree more. Have been evangelizing this for quite a while.

One problem is how to get control of the dependencies. Use makefiles one said, but that’s complex and it doesn’t leave you with some overview.

Thus I am still looking for a graphical tool that can manage my components (servers, installation, etc.), services (dhcp, AD, etc.) and their respective relationships.
Not only that – the tool should help me with start-up shut-down plan, including attributes of my components and services like their respective IP addresses, locations, accounts, passwords (?), contact information (just in case) etc.

This would be my ideal tool for a good preparation controlled DC operations – and will give good insight when shit hits the fan!!

Just haven’t found this tool yet… Visio won’t cut it. All tips will be appreciated.

Thanks for the comment. In my article, I implied sorting out application dependencies on other applications where I should have been more explicit about it. In my environment, we have plenty of application dependencies which makes the startup order for application servers particularly interesting. Depending on how the application has been architected and the platforms they use, databases, middleware, and applications need to come up in the correct order. Add domain controllers to that mix as well. It’s a safe assumption that domain controllers (referred to as DCs in my screenshot) always need to come up first and shut down last, again, in a staggered fashion like cluster nodes.

Great article about a subject nobody thinks about to often. Our data centre provider had a major change to their power delivery setup last year which resulted in the first full shutdown of our datacentre since we outsourced. We had to pull a run order for shutdown together very quickly and it all went very smoothly in the end. One thing you didn’t mention was application dependencies, working in the finance sector for example tends to provide systems that consist of multiple servers and numerous dependencies. I wonder what other industries have these complex application environments to add into the mix.

Regards

C Stewart ( VirtualPro)