In the real world, different SRM solutions have been built around specific hardware platforms, or to focus on different elements within the storage infrastructure. Many products touting themselves as “SRM” only deliver some of the functions customers need, or work only with a certain vendor’s hardware.
Therefore, many administrators have added “stacks” of software atop their physical storage infrastructure to manage its different elements.
One example is path management, meaning the configuration and management of multiple data paths between servers and storage to increase performance or provide fault-tolerance.
Another example is volume management software, which works at a layer above path management and allows administrators to create, delete and change the size of the volumes, which are available to applications and operating systems.
Virtualisation software is designed to make it easier for multiple servers and applications to access the same physical arrays by making multiple physical arrays appear as a single, “virtual” storage resource. Virtualisation software may run on a server; on a storage controller; within a storage array or within a dedicated virtualisation appliance in the storage network.
SAN design and validation tools allow administrators to perform “what-if” analysis of how different SAN designs and the use of different components will perform under actual business conditions and to identify compatibility or interoperability issues before the design is set in stone.
Finally, there is software for managing elements within the infrastructure, such as the HBAs that link servers to storage networks.
Adding each of these management tools probably made sense at the time as a logical point solution to an immediate need. But over time that approach results in complex software stacks that are difficult and expensive to learn, administer and manage. Storage administrators are forced to switch from one application to another to perform even routine, but time-consuming tasks. This makes SRM far more complex and costly than it needs to be, resulting in excessively high storage management operating costs.
This approach also reduces efficiency by making it more difficult to balance ever changing storage provisioning needs. Rather than go through the burden of a time-consuming and error-prone re-provisioning of volumes across existing, unused storage when an application needs more space, the storage administrator may simply buy more physical storage for that application. This results in higher than necessary capital spending, the creation of yet more inefficiently-used storage, and more physical devices to manage over time – all of which increases storage operating costs over time.