Make it a double
One of the things you find in infrastructure technology is that you can often do the same thing in more than one place.
Take data compression, for example. All proper storage sub-systems have their own built-in compression or deduplication options, but then if you work up through the layers you will often find that they provide equivalent functionality (particularly the server virtualisation).
You can even turn on data compression right at the top of the stack on a Windows server, but of course that is only for the criminally insane.
Similarly, in network switching your hypervisor is able to pass traffic between some virtual machines (notably those in the same VLAN and on the same physical host) without the physical LAN switches ever seeing it.
This is where you take the next step of collaboration. You have already got your service owners together, so now is the time to bring in the vendors as well.
Where you can do the same thing in two places, get the vendors involved
One particular storage vendor recently told me that the best way to eke performance out of its kit was to get the VMware guys to “thick provision” virtual disks (set aside the entire amount of space instead of letting VMware grow them as required).
Similarly, I asked a virtualisation guy a while ago whether I should be turning on the optimisation options on the storage or the hypervisor.“Both,” he answered very firmly.
So where you can do the same thing in two places, get the vendors involved and make sure you go for the best combination of options. This will require your internal experts to work together, as you will often need to change two systems at once to eliminate needless downtime.
Call the experts
If you are thinking at this point that we have forgotten the application guys, don't worry: we haven't.
While the server, storage and network experts are all working together they need to consider the application team as customers – in part at least. In return, the application people need to take a step back and think, instead of simply clicking Next, Next, Next in their installers.
How many applications do we all have where the app is back-ended by a relational database, and that relational database is in fact a copy of SQL Server Express that was installed by the app installer? (Answer: shedloads).
How many of those databases are properly backed up – or for that matter even known to the servers and storage teams? (Answer: not many, I suspect).
While we are at it, how many application servers are actually provisioned correctly in terms of RAM and CPU?
It is very easy to set up a server based on the system requirements of the apps that will be running on it, but it is rare to see any real scientific analysis done, particularly in a virtual world where you can over-provision CPU on servers and let the hypervisor share out the spare cycles for you.
So the application teams need to work with the server and storage teams in particular. One especially forward-thinking organisation I worked with had a dedicated SQL Server cluster which serviced the back-end database requirements for the front-end apps that needed it.
It was resilient, it was efficiently provisioned, it saved the company a packet in licensing (many apps were too big to fit into the limits of SQL Server Express and so needed a commercial version) and it was backed up properly.
So the main thing you need to do to defrag your data centre is to defrag the teams that look after it.
At the very least, even if you leave the application team on the periphery and consider them as a service user (or a customer) of the infrastructure, you need to have the infrastructure team under one roof, preferably headed by a single manager.
I have worked with companies where servers, storage and networks were looked after by separate teams. In some it worked, and in others it didn't.
Quite recently I also worked in a company where the key service owners and specialists for servers, storage and networks (the latter being me) all sat within 20 feet of each other, and it was by far the most effective team I have ever worked in.
This is not to say everything was centralised – in fact each of us had technical staff based in other continents – but co-ordination lay with the central team and if there was a major issue we could convene in minutes. We could work through the diagnosis as a group instead of a finger-pointing mess.
In short: if you have service teams in silos, your data centre is likely to run in the same way. Give the setup a onceover and bring the people together to make it better.
Most importantly, don't be frightened to bring in the vendors as part of the extended team. Your particular combination of systems will almost certainly have unique interactions that the vendors’ specialists can help you with.
You may well surprise yourself by how quickly you have achieved a coherent, unified infrastructure in your data centre. ®