Talking to a fellow end-user a few weeks ago reminded me of a frustration that I frequently experienced when I worked as a storage engineer. What was driving him crazy (and what often drove me crazy) was the lack of communication that was occurring between his organization’s internal storage, server and database teams. Specifically, he wanted to better manage and optimize his organization’s backup and storage infrastructure but no one was willing to share any information as to how much storage capacity they were utilizing, how they were using it or how much they might need going forward.
When I spoke to him, he didn’t really know which way to turn. He was making plans to redesign his backup infrastructure and needed some insight into how much storage capacity his company’s databases were consuming and how fast they were growing.
One would think all he had to do was ask a database administrator (DBA) or turn to storage resource management (SRM) software for this sort of information. However the DBA refused to cooperate and would not provide him with the information he sought and he had no SRM tool to turn to as an alternative.
On the surface, this problem sounds simple enough to solve. Either get the manager or VP or CIO (or someone) to tell everyone to play nice and share information or deploy an SRM tool that would automate the gathering of this information so he would not have to bother the DBA anymore for routine information.
Unfortunately his management refused to get involved (“We don’t talk to them and they don’t talk to us”) and achieving consensus on SRM software sounds great in theory but having once been down the path of deploying SRM software myself that is sometimes easier said than done.
Whether or not my friend can resolve his specific dilemma, I do not know. However I do know from my conversations with other administrators (database, server and storage alike) that his situation is not unique. In fact, I was describing this situation to a DBA friend of mine last week over the phone who now works as a consultant. He said that he had done the same thing in his past where he had declined to share information about his environment because of how it would it come back to bite him.
He kept extra storage capacity on hand for tests he needed to occasionally run to preemptively fix database problems but never told anyone about it. The reason is that if the storage administrator saw this unused storage capacity on one of his database servers, the storage administrator would confiscate it and return it to the general storage pool where the DBA could not easily access it.
So what is it about improving capacity planning and sharing storage information or, ideally, using an SRM tool that automatically does these two tasks, that gets everyone so uptight? My own experience tells me that while everyone understands the benefits that SRM software provides, the fear that each of these different groups possesses is how the information will be used against them – whether intentionally or inadvertantly.
I know I am guilty of this. When an SRM tool was deployed in my environment, all of sudden I had access to information that I never saw before and I thought I hit a gold mine in terms of helping my company reduce costs. For instance, some applications servers were utilizing only 30% of their SAN-attached storage and I (too quickly in my case) went to my management to show them how the SRM tool was paying for itself as it could recover all of this unused SAN storage.
The only problem was I only got a snapshot of information and did not get a full picture of the environment, as least in this one example. The application servers that I was looking at nightly received downloads from the mainframe so they needed all of that extra space to hold the data contained in those downloads.
Once the data was processed by the application, the data was deleted. This left a big empty space for the next night’s download and which, to the uninformed, looked like space prime for recovery. To my detriment, the first reports that I looked at just showed this big empty unused chunk of space that led me to make the wrong conclusion.
In hindsight, I should have waited to share any information and gather more data first so I could analyze it over a longer period of time. While I did not mean any harm (I was trying to show an ROI for the SRM tool I just purchased) my mistake is representative of what can occur when the information gathered by an SRM tool is not well managed or carefully analyzed by those who have access to it before they communicate it or share it. Shared too quickly or without proper analysis, the one responsible for managing the information can lose credibility and diminish the value of the software in the eyes of those around you.
Yet if there was any good news in this example, at least it was an early version of SRM software and not a more comprehensive SRM software package like Symantec’s Veritas CommandCentral Storage that collects much more data about the environment. These more mature SRM software packages gather data from many more sources so it becomes easier to jump to the wrong conclusions too soon before all of the information can be viewed in the appropriate context.
SRM software such as CommandCentral can certainly help organizations gather data across their entire IT infrastructure – databases, virtual and physical servers, Fibre Channel switches and directors and storage systems. Part of the hope is that it avoids the need for database, server and storage administrators to run around talking to another to manually gather this information so they can better leverage it to manage the environment. CommandCentral will ideally lead teams to improve their communications and visibility into their storage infrastructure so they ultimately improve their ability to do storage capacity planning.
Just because storage capacity on a particular application server is over or under-utilized does not necessarily mean anything is wrong. It just means whoever in the organization has access to this information needs to check with the responsible party first to ensure they are interpreting the information correctly and using it to make better decisions going forward.
SRM software can alleviate the need for some communication by automating the collection of needed data, possibly provide a central console from which to manage some aspects of databases, servers, switches and storage and better plan for the future. However organization should not look at SRM software as a reason to abandon all communication between departments once it is implemented. Rather they should view it as a way to automate the gathering of data and then use it as a platform to identify the issues so departments can build bridges to better understand each other’s requirements and needs and then build an infrastructure that reflects those requirements.