SPAID cuts both ways

13.04.2006
The growing consensus in the analyst and vendor community is that SPAID (split-path acceleration of intelligent devices) will eventually become the predominant form of network-based virtualization implementation in enterprise shops. While I agree with these sentiments, the operative word is "eventually." Standardizing on a relatively untested platform in complex SAN environments may take longer than even some of the more pessimistic projections.

SPAID introduces both new software and hardware into the data path. While the technologies it uses, volume management software, management servers and intelligent network switches are not new, the combination of them working together in sync is. Add in expectations that this combination will need to work flawlessly every day for thousands of days on end should give every organization pause.

Some also will argue that SPAID technology should be deployed in stages. But how gradual is gradual enough and under what scenarios? For instance, different storage arrays have different port-flag settings. So does introducing an appliance between multiple servers and storage arrays make sense, and will it work reliably? Or if you are using Hitachi Data System's multipathing driver and decide to present a volume including logical unit numbers from IBM and HDS arrays using CA's and StoreAge Networking Technologies' co-branded SPAID software to a VMware server, how will that work, and who will assume ownership of the support call if it doesn't?

Conversely, if this technology doesn't work in all of these different and rather complicated configurations, is it worth deploying at all?

Network-based virtualization is the right corporate direction from both a cost and management perspective, and the SPAID version should eventually predominate at the enterprise level. But this evolution will not occur overnight and will not fit heterogeneous environments anytime soon, so companies should plan on doing more of the same for now.

Jerome Wendt currently works as a storage engineer and storage analyst. He contributes regularly to a variety of industry trade publications and can be reached at jerome.wendt@att.net.