StorageScope from EMC Corp. provides monitoring and reporting features within the ControlCenter family of SRM tools.
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
HP's StorageEssentials SRM tool is based on software originally acquired from AppIQ Inc., but Goodwin points out the product's strong use of interface standards and broad heterogeneous support, including storage area network (SAN), network attached storage (NAS) and direct attached storage (DAS) products across HP, Sun Microsystems Inc. and Hitachi Data Systems Inc. (HDS) platforms. "It supports a larger heterogeneous environment largely because it is SMI-S based, which is supported by all the big vendors in the industry," Goodwin says.
Storage Manager from Softek Storage Solutions Corp. is primarily a reporting tool, offering a complete view of data and the storage infrastructure, as well as task automation, like auto discovery and data profiling -- all from a single console. Goodwin acknowledges that Storage Manager indeed offers solid heterogeneity for disk-based platforms but notes a lack of support for tape as an important disadvantage.
Selecting the right product
SRM tools are readily available, but they can vary dramatically in complexity and feature sets. Before selecting a tool, understand the information and reporting capabilities needed by your own organization, and verify that the tool provides compatibility across the current storage infrastructure. Once you narrow the field, a few potential candidates can be thoroughly tested in-house. Analysts suggest the following points that can help you identify the best product for your own production environment.
Identify the tool's suitability to the environment. An SRM tool absolutely must support the servers, storage platforms, switches and applications used in the infrastructure. If not, the tool cannot access potentially important parts of the infrastructure. This can restrict the tool's ability to automate key tasks, and lower the accuracy and quality of its analytical results -- it's simply less useful. An SRM tool should also bring automation to the environment, allowing fewer IT staff to effectively manage more storage. "In 2000, an average IT organization would manage approximately 2 terabytes (TB) of storage per administrator, where today that number is more like 15 TB per administrator," Goodwin says. "You have to make your people more and more efficient, and that's what SRM does."
Understand how data is collected. Analysts recommend selecting "agentless" SRM tools that adhere to SMI-S standards. Tools that are based upon agents require software installations on each server or other device being queried or controlled. This intrusive technique imposes more software maintenance demands on administrators and can potentially open the door to security threats through the agent software. The additional burden of agent software can also impinge on system performance -- sometimes resulting in artificially low performance results.
Look for key features or functions. Not only must a tool be suited to the environment, the tool must also provide the environment with a feature set that meets the organization's needs. For example, when an SRM tool is intended to analyze storage utilization, features like chargeback functionality and integration with the company's billing application can become exceptionally important. "If you have, for example, a huge tape environment -- tens of thousands of tapes -- and that's one of your primary cost areas and points of concern, then you'll want an SRM package that addresses it," Goodwin says. "Not all of them do."
Consider whether the tool is deployable. Some SRM tools are quite powerful but require a small army to implement. Other tools lack the "push" functionality to keep agents and applets updated throughout the infrastructure, and this wastes valuable time by forcing a manual installation on each platform. Tools that are difficult to implement or use will probably not be used consistently, if at all, compromising the tool's value right from the start. "It needs to be very unintrusive," Schulz says. "Ideally it should be able to plug in, and you should be able to unplug it. It shouldn't ingrain itself into your environment."
Consider the reporting functionality. SRM tools typically offer a rich selection of depth and format options, but the options should be conducive to the business. For example, a storage administrator should not need to program the SRM tool to deliver reports -- a tool with a standard library of report formats will probably be used more frequently. Report delivery is also an important consideration. "The fact that it has 'umpteen-hundred' [sic] different kinds of reports is not necessarily helpful. How are those reports delivered?" Goodwin says. "Can that [report] information be pushed to the user, or does the user have to go dig it out?"
Evaluate support for specific applications. Storage allocation and utilization based on specific applications (e.g., databases) are important aspects of storage management, so an SRM tool should offer clear management and reporting detail for mission-critical applications.
Best practices for implementation
SRM tools are deployed to gather and report on important information, but not all of that information is necessarily "good news." If you simply use SRM to see what is doing well, the tool's true value is diminished. Regardless of how you intend to utilize SRM, analysts remind administrators to focus on reality -- pay attention to the "bad news" and use that to recommend important storage improvements. Other well-grounded policies can help smooth any SRM implementation issues.
Start small and build out. The time and effort needed to build out a comprehensive SRM practice can be extremely challenging, and SRM tool deployments are underutilized, and even abandoned, because administrators are simply overwhelmed. Analysts suggest starting small with SRM -- gaining experience and building a series of successful efforts as deployment expands. "Do your pilot, become familiar with it [the tool], use it to discover. Learn what you have, learn how it's being used," Schulz says. "Establish what is normal and what is not abnormal."
Establish naming conventions. SRM tool results can be difficult to interpret because the designations used for switches, servers, logical unit numbers (LUN) and other network items are often inconsistent -- as devices are added and replaced, their names are frequently assigned indiscriminately. Analysts suggest revisiting the device naming scheme for your infrastructure and adopting conventions that make device identification more intuitive.
Limit initial reporting. Another way to develop skill with SRM is to start with simplified reporting -- don't let the SRM tool swamp you with excessive information. "Simplify the amount of data and the key stats you want utilization reports on," Babineau says. Once the SRM tool is used regularly, expand the reporting and refine the detail levels to meet specific administrative needs.
Implement security measures. SRM tools are often used simply for monitoring purposes, but many tools include provisioning, backup, replication and other advanced management features that can have a profound impact on the storage infrastructure. Once an SRM tool is deployed and configured, administrators should make the effort to implement user authentication and security measures to guard sensitive setups and prevent unauthorized resource changes. "If you're going to be making changes and adjustments, look into change control and change management tools as well," Schulz says.
Verify change discovery and reporting. Any SRM tool should be able to adapt to changes as they occur in the environment, so be sure to evaluate the tool to see how it adjusts. "As you add additional storage resources, how does the SRM application keep up with those changes in the infrastructure?" Goodwin says. "Is it automatic? Is it discovered? Is it immediately managed? And so on." Knowing exactly how the SRM tool adapts to changes will influence your change management and reporting processes. ***
This was first published in August 2006