Over the past few months the one common issue I've been struggling with is the growing complexity of managing my storage network. What specific steps should be taken to simplify the storage management process?
- Adding software? If so, what kind?
- Consolidating hardware vendors/platforms?
- Streamlining operations through merging or breaking out storage roles?
- How can I reduce my time to provision storage?
Unfortunately there is no simple way to reduce the issues raised by the growing complexity of storage environments. Even if storage resource management (SRM) software becomes a good solution, it will, at best, be only a vital tool used to keep the storage network running smooth.
The prerequisites for getting your storage network manageable -- and keeping it manageable -- lies beyond tools. Especially when you consider the rising demand from users in terms of accessibility and security as well as simply the sheer amount of storage requested, this is no small feat.
If you really want to get out of the firefighting and quick fix solutions, you need to stop and think this through. To start, you need to perform an analyses of what you have, how it's utilized, what the risks and benefits are and what capabilities your current storage estate has especially in growth potential versus the cost of running it.
To highlight why it is so important let me pick a comparison that might, at first glance, be pretty unusual -- especially because real world examples from other areas are rare in IT. (Just kidding.)
In the medieval times, London was the biggest city in the known world with an approximated population of several hundred thousand people. Within the 200 years between the 15th and the 17th centuries, greater London burned down to its walls three times. Each fire left a death toll of hundreds of thousands of people including some 10 night watchman who were blamed for the fire breaking out. After each fire London was erected again the same way as before with wooden houses, no firewalls between them, small streets without street names, and insufficient water supply. Guess what was the outcome? There was another furious firestorm, another 100,000 killed and another 10 night watchman executed.
Eventually after the big disaster in the 17th century, the London Major implemented policies that effectively reduced the risk of fires. Wooden houses without firewalls where not allowed to be built anymore. The streets had to have a minimum broadness, and every building had to comply with the rules set up and controlled by the city. Since that time no fire has broken out in London with such disastrous consequences than those in the medieval times. And on further remark, the London fire department has roughly the same amount of service women and men that were on duty in the medieval times (these were full time paid employees also).
Here is my conclusion on what IT can learn from the majors of the medieval cities: If you want to prevent disastrous events you need to prevent the emerging chain reaction from a single threat -- decide what is manageable and what isn't manageable by establishing policies and processes to ensure that when fires do occur, they can be fought efficiently. In addition, let your policies and processes reduce to the risk of fires breaking out to as small a risk as possible.
This can only be done through changes within the infrastructure. Automating firefighting through systems without the supporting framework of policies and processes is at best a way to reduce the increasing need for new firefighters, but it will never lead to a smooth and efficient running environment.
After you know what you have and what you expect you'll need to provide in the future, you can start planning your infrastructure. A good consultant is highly recommended to support you here even if you have the expertise by yourself, as he or she can add the much needed outside view.
The question about what software to add depends on your existing infrastructure. If you have a single vendor SAN and decided to live with the risk to be dependent on one vendor (there are good reasons for and against such an approach), using the software the vendor provides is a good bet.
In a multi-vendor environment I would pay attention to the amount of vendors and devices a software management sy
This was first published in September 2003