* We need a single mgmt. tool capable of looking across both storage and fiber
Midsize and larger businesses often find their IT topology has become a complex mix of servers, networks and storage systems that typically come from a variety of vendors. Many of these companies also route long-haul traffic over fiber-based networks – metropolitan-area networks, WANs and private optical networks.
The convergence of fiber-based long distance connectivity and storage offers some interesting challenges. These are not necessarily new challenges of course – fiber networks have been moving traffic since at least the early 1980s – but because of their complexity and also because of the distances involved, such IT environments can challenge the best IT teams when something goes wrong. And naturally, because of the complexities, something almost always does.
Networking and storage people often don’t spend much time with one another. The exception to this rule crops up when a storage-related problem occurs on a fiber network. In such cases, the two groups often find they spend way too much time on collective fire drills.
Storage managers have their toolsets, network managers have theirs, and like their human counterparts, these rarely work together. At this point however, what we really need is not a set of tools that work together but a single management tool capable of looking out across both the storage and the fiber networks, and then applying some intelligence to what it sees. Given such a tool, IT organizations would get see the entire data path and get some insight into the interactions occurring between two important subsets of their overall IT system.
Storage management tools tend to be remarkably unintelligent about what happens to the data as it transits between arrays and switches across a storage-area network, and most are just plain stupid about what happens when the data moves onto long distance fiber. It would be nice to have a tool that provides an integrated view of disks, HBAs, SAN switches and fabrics, and dense wavelength division multiplexing and SONET devices. In fact, it would be nice to have even a reasonable subset of this capability.
A really useful tool should do more than just monitor what goes on, however; when a fault occurs it should also be able to drill down into the various elements along the data path and isolate the location and cause of a fault. This would most likely require the ability first to collect data from each element in real time – SNMP traps from the network elements, SMI-S information from the storage, and proprietary data for those elements where neither of the first two is available.
The tool would then have to “normalize” the disparate data into a common data set. Data would likely be allocated to specific columns to facilitate analysis, and might be nothing more than a simple comma-delineated file. Once that is done, additional data smoothing can take place: a correlation engine would examine the normalized data, compare it against a database of known events and remove redundant references (alerts from various points along the data path that report the same problem).
What is left would be significant data, against which intelligence could be applied to identify the root cause of the problem.
Real-time topology and performance monitoring, plus fault analysis, will lead to much more reliable systems. IT shops sending data out over fiber to remote sites need such a product, particularly if they have been dispatching multiple IT personnel to address a single problem or to verify false positives appearing in error reports. Actually, just about any site requiring more than a few minutes to locate faults on the data path might view this sort of thing as almost a gift from the IT gods.
Whether managers will be willing to spend money on this sort of tool depends. After all, they still have an alternative – going through life always keeping one finger on the escape key.
