Organizations must first decide what capacity they want to measure. That decision will largely determine what tool or set of tools to choose. A tool should feature:
- Disk utilization reporting
- File-level reporting
- Database reporting
- Visualization of the storage network infrastructure
- Storage array reporting
An increasing number of products now report on tape libraries, but that feature isn't that critical for an organization just starting to deploy an SRM product. So, how do the SRM tools differ? Basically, in terms of how they gather the data and what they are architected to accomplish. The architecture of each product bears a direct correlation to the size of the agent deployed, how many agents get deployed, their level of activity or if any agents even need to be deployed.
Tools like Fujitsu Softek's Storage Manager and Tek-Tool's Storage Profiler for OS provide one small, easy-to-deploy agent that meets the first two criteria. Their agents can be installed and configured in just a few minutes, consume minimal disk space (maximum 30MB) and remain dormant except during scheduled collection times. They measure disk utilization filtered by such criteria as servers, users and group. For file-level reporting, the agents provide more granularity, enabling users to identify certain file types such as mpg, jpg and xls. They also determine the age of the file types and see historical trending and forecasting information that illustrates how fast these file types are growing while predicting how fast they may grow.
Similar tools, from EMC, for example, aren't as simple to install and configure because of the way they are architected. EMC currently offers two tools, one called VisualSRM, which provides an easier to install point solution but gathers less information than their flagship product, Control Center (CC), which requires the deployment of a 100+MB agent and licensing for four products: Control Center, StorageScope, StorageScope FLR and Automated Resource Manager ARM. The CC agent can consume anywhere from 1% to 15% of a host's CPU while it performs storage capacity monitoring and reporting functions.
Some companies like AppIQ collect device-level and host-level capacity information without an agent. Its StorageAuthority Suite software--written to the Storage Networking Industry Association's Storage Management Initiative Specification (SMI-S) and Distributed Management Task Force's Common Information Model (CIM) standards--gathers this information simply by querying SMI-S compliant operating systems. The query may take place over either a Fibre Channel (FC) fabric or an Ethernet network. The operating system vendor must provide or ship a CIM Object Manager (CIMON)--such as Microsoft Windows WMI--and devices must offer SMI-S interfaces.
SMI-S compliance should no longer be considered optional when making new storage purchases. While users should remain skeptical about any vendor's claims that their capacity management tool can manage their storage infrastructure through only the SMI-S standard, they can certainly expect these products to deliver fundamental reporting capabilities. Any capacity management product that doesn't have an SMI-S road map shouldn't be viewed as a viable long-term solution.
Gaining visibility into databases beyond their raw size requires the deployment of database-specific agents. Most databases require a reporting agent that's specifically tailored for the database; for example, an Oracle database requires the deployment of an Oracle agent. Other products such as Storability's Global Storage Manager (GSM) require the deployment of two agents--a core database agent and one specific to the database being monitored.
