Why consolidate?

"The SAN island problem is the same problem as separate server-attached storage, just one step higher up," says Bob Venable, manager of information systems, Blue Cross Blue Shield of Tennessee (BCBST), in Chattanooga. The health insurer is concerned that multiple SANs hinder enterprisewide storage sharing.

Experts generally agree that consolidating multiple DAS units into fewer, larger storage subsystems reduces the cost of ownership and simplifies maintenance and administration through centralized management. They don't all agree on how quickly that will occur (the payback period) or whether that should be your real goal (see "The ultimate benefit of consolidation," on this page). The most immediate question, though, is how much to consolidate and how best to achieve it.

The generally recommended approach to storage consolidation is networked storage, which gives multiple servers access to multiple storage devices.

Industry research firms are nearly unanimous in predicting that SANs will become the dominant enterprise storage format within the next few years.

So, how should you organize your SANs? Should you have dedicated SANs based on factors such as geography, application, platform, corporate organizational structure and function or one huge enterprisewide SAN?

The case for multiple SANs
The correct architecture for you will depend on your applications, the diversity of your environment and a host of nontechnical issues that could roughly be grouped under the heading of "organizational issues," or to put it more bluntly, "politics."

Ideally, if you're consolidating storage, "one large monolithic SAN is preferred," says Arun Taneja, a consulting analyst with Taneja Group, in Hopkinton, MA. As a practical matter, implementing multiple SANs may be unavoidable, says Dave Hill, vice president of storage research, Aberdeen Group, Boston. "In large companies, you can't consolidate all the storage at once," Hill contends. "The Holy Grail is a single storage infrastructure, but there are practical reasons for multiple SANs. The question is: What level of aggregation do you need or want?"

The most obvious path to follow is to create multiple SAN islands, each consolidating a portion of your servers and storage. Despite dire warnings from switch vendors and consultants, that's not a problem, says Tom Black, technology services lead, at Petro-Canada, Ontario. For example, multiple SANs allow for greater flexibility and risk management. "If you are doing something risky, you can separate it on a different SAN," he says.

Hill agrees: "I don't see any problem with islands of SANs. It's a positive development." Different SANs, he explains, can support different functions that don't need to share data. In other cases, the organization may have critical systems and, for security reasons, not want to share the data, or the company may have geographically separate facilities or autonomous business units, each with its own SAN. In situations such as these, multiple SANs make sense.

But "SAN islands are difficult and expensive to manage," says Tony Prigmore, a senior analyst at the Enterprise Storage Group, Milford, MA. The piecemeal approach may not be beneficial moving forward, he says.

How to decide
Experts agree that it's not a matter of a coin toss or taste: The choice of how to deploy SANs should be determined either by the application or by the service level.

"A lot of factors eventually come into play, but we start by determining the level of service in terms of performance and high availability," says Scott Robinson, CTO, Datalink Corp. A high-availability SAN, for example, offers redundant everything, which significantly increases the cost, but "doesn't make sense for everything," he says.

Intuit Inc., Mountain View, CA, is one company that takes this approach, setting up its SANs according to quality of service demands. "Everything that needs five-nine reliability we put on the EMC SAN with director-class switches and high availability," a costly configuration, says Eric Ihde, a senior systems engineer. The less-critical systems are put on SANs that use fabric switches and ATA drives, both of which cost significantly less. The company puts development work--which makes the least demands in terms of availability, but often has the highest risk of causing problems--on a SAN with a small edge switch, the least costly of all.

Intuit's approach is driven by the economics of high availability. "We don't want to spend money on high availability where we don't need it. We want to save the costly directors and high-availability storage for the things that are really worth it," explains Ihde. "The developers don't need 24/7 availability."

Taneja takes a different tack than Robinson and Ihde, looking at the application. "Start with the application. Then you can factor in the other realities," he says. Those other realities include platform considerations, security issues, geography and distance and internal organizational and political dynamics.

"The easiest way to propagate SANs is by application or by department and that is how companies have been doing it for the past three years," says Prigmore.

This is the approach Petro-Canada took, where the platform and the application were, in effect, the same thing. "We set up our SANs based on the platform," explains Petro-Canada's Black. The firm's Unix SAN, for instance, handles the Oracle database, transaction processing and a 1.5TB SAP database. The company has a SAN for its large NT servers, but many of the company's NT systems are widely dispersed and small.

				ISL heaven or hell?
				The middle ground between a single consolidated storage area network (SAN) and multiple SANs is the logical SAN consisting of multiple SANs connected through inter-switch linking (ISL). ISL uses the expansion (e-) port to connect one switch to another to turn multiple SAN fabrics into one logical consolidated SAN. For enterprise-scale high performance, companies can opt for ISL trunking, which uses multiple e-port connections to create one high-speed connection linking multiple switches. ISL trunking, for example, can aggregate the bandwidth of the switched ports, so four 2Gb/s switches can be aggregated, theoretically, into an 8Gb/s pipe, although some bandwidth is lost to overhead. "Regardless of how many SANs you have, you want to manage them as one," says Mike Jones, vice president, ViON Corp., a systems integrator based Washington, DC. ISL allows you to do just that, manage multiple SANs as one logical SAN. Storage managers at Blue Cross/Blue Shield of Tennessee (BCBST), however, rejected the use of ISL. "It allows access between the SANs, but it introduces imbalances and problems. It has the potential to become a huge bottleneck. You end up strangled by your ISL," says Bob Venable, manager of information systems, BCBST, in Chattanooga. Certainly, ISL complicates issues such as routing and load balancing, although these capabilities can be built into the ISL device. Intuit has also rejected ISL. "You would only use ISL if you really have to merge the two SANs. But then, everyone sees everything on each fabric, which raises security concerns," says Eric Ihde, a senior systems engineer for Intuit. Of course, you can use zoning and LUN masking to limit who sees what, but configuring those capabilities gets complicated in a merged SAN. "There is a lot of work you have to do in advance to make sure there are no naming or configuration conflicts. Otherwise the whole thing can break down," Ihde adds. Ultimately, ISLs can only go so far before they consume significant amounts of ports, making them uneconomical.