The two different paths of SANs

Storage-area networks are hardly new to mainframe storage managers, and we have clearly reached the point where they are no longer unknown territory for most open system managers either. 

Many enterprises began to experiment with SANs several years ago. As is the case with most intelligent pilot projects, early SANs were treated with caution in their first implementations. Although some started up in departmental roles, most were in the glass house along with the other enterprise data, but were relegated to non-critical roles. 

It took a while for SANs to become trusted partners in the IT establishment, but it happened and SANs began to proliferate. Interestingly however, this growth moved along two very different paths.

Some companies took a path that added to their existing SAN, accumulating more and more switched ports and creating a single large and complex fabric on which they could consolidate all of their storage.  This provided the opportunity for centralized management and geographically centralized infrastructure.

Other sites took a different route, building a number of different SANs in distributed locations.  Each of these “SAN islands” often focused on a single application or service, and was managed as a discrete operation separate from the others.  These delivered “SAN values,” but without the cost of inordinate complexity

Which has turned out to be the best route?  That depends.

In the main, IT turned to SANs for three reasons: improved performance, greater reliability and enhanced manageability. 

All these qualities are available from consolidated and distributed SANs. 

In some cases, storage consolidation is leading to “mega-SANs,” large and multifaceted storage networks at the enterprise’s core that have centralized everything – but at the cost of enormous complexity.  The topology diagrams of such SANs are complex, and give some indication of the concerns the managers will have regarding the interoperability of the network’s various parts whenever an upgrade is needed or a new element is added to the mix.  And of course, when a large SAN loses a key asset the potential ripple effect of system degradation across the corporation can be enormous until recovery is complete.  Director class switches and storage arrays offer greater protection here, but at considerable cost.

With distributed SANs the complexity of the mega-SAN is avoided, but at the substantial inconvenience and inefficiency of decentralizing the assets and, as a typical consequence, decentralizing the management of the assets as well.  In one sense at least, topology problems are avoided at the cost of introducing topographical ones.

The ideal situation is likely to turn out to be one where the advantages of distributed SANs and dense switching infrastructures are combined into a single entity, and where the downsides of both are avoided.  This is a significant technology goal, but fortunately one that is on this side of the horizon. 

Several vendors are working towards this end. It will be interesting to see which one is able to introduce a solution that combines the best of both worlds.