Logically we all agree; storage virtualisation is a good thing because it radically improves disk utilisation. But putting it into practise has up against an either:or problem.
Either you have the virtualisation carried out in the data path and face potential choking as storage network traffic ramps up or you have it carried out away from the data network link and have to have software agents on every server accessing the storage. That means all your server hardware/operating system platforms have to be supported, which is no easy thing.
Enterprises have not taken to storage virtualisation with any great enthusiasm as a result. Their need to get greater disk utilisation isn't enough to overcome these obstacles. But some vendors think that the focus on server agents is not valid. Sure the out-of-band virtualisation approach gets away from the potential bottleneck of a single in-band virtualisation device choking a growing storage network and slowing it down; that's a given for these vendors. But server agent software is not.
Virtualisation lego blocksA virtualised storage system has three building blocks:
1. A metadata server
2. A control path
3. A data path.
A metadata server is a dedicated computer application that maps the physical disk storage to the virtualised storage and enables all the various disk arrays and drives to be presented as a single virtual pool of storage. When a server makes a storage network data request it is intercepted and a message goes to the metadata server asking for the server's storage address to be translated into a real physical storage address. The server responds to this by sending back that address.
The metadata server is the heart of an virtualisation appliance or device. An in-band one sits on the data path. An out-of-band one doesn't. The virtualisation device has to 'see' all the servers and all the storage arrays for it to work. So, at a point where all the SAN network links come together then there the virtualisation device has to be located.
In a very busy storage area network with potentially thousands of servers the load of all the requests on the metadata server will be huge. If it is in the data path; if all the data moving requests have to wait until the metadata server does the necessary address translation from its mapping tables, then the whole storage network could slow down and server applications slow as a result.
In-band virtualisation has all the processing required for metadata, control path and data path software performed by one device in the fabric. Intel-based servers running Datacore, FalconStor or IBM's SANVolume Controller software are examples of this. HP's CASA was also an in-band device.
One way of avoiding having a limited central resource throttling the whole SAN is to take it out of the data path. When a server makes a storage request it is captured by a software agent in that server which sends it via a different network link, the control path, to the metadata server. It returns the real address, and the software agent then lets the storage request go ahead using the real address. StoreAge SAN management software is based on this approach. It will work well where there is a homogeneous server environment but less well as the number of server HW/SW platforms and O/S levels increase.
SPAIDThe newish insight is that instead of having software agents in the server, what you can do is to capture the server's storage request before it would hit an in-band virtualisation device. As long as you can capture the message up to or at the receiving port in the SAN and then divert it off via a now shorter control path to the metadata server, then you have an out-of-band virtualisation facility without the host server HW/SW platform limitation on SW agents.
This idea is called SPAID for Split Path Architecture for Intelligent Devices
The idea of there being a single data path in a SAN is actually un-real. There are as many data paths as there are ports. If the SAN has a central director though which every link passes then that director is the fabric centre and can 'see' all the servers and all the storage arrays. But it doesn't have one central path across which every SAN data message passes. It has as many paths as there are port-to-port links inside it. Virtualisation, of necessity, operates at the port level.
How do we achieve it? We either have a separate virtualisation device linked to the ports and intercepting traffic or the virtualisation function is carried out in the port box, meaning in the switch or director. This is what an intelligent switch or director does, amongst other things.
These devices run layer 4 network functions such as storage disk or tape virtualisation. A SAN router for example, intercepts SAN traffic, looks inside data packets and gets port addresses so that it can route the SAN traffic between different logical SANs. Such devices are a natural place to locate storage virtualisation since they already have the packet intercept capability.
What are the various vendors doing? Existing switch and director vendors are adding blades or intelligence to their devices. Newer vendors such as Maxxan and Maranti are introducing new devices built from the ground up to be intelligent.
BrocadeBrocade has its Fabric AP7420 intelligent SAN Router. It already runs Alachritus' virtual tape software.
CiscoThe Cisco MDS9000 switches can run Veritas' Foundation Suite and IBM's SAN Volume Controller.
EMC EMC's coming Storage Router is SPAID firmware running on intelligent switches from Brocade, Cisco and McData. This strikes me as rather odd. It's almost as if EMC is now regretting letting McData become independent. We might also ask why Cisco is letting partners provide director application firmware when it doesn't do so with its general network routing gear.
MarantiMaranti has its CoreSTO range of intelligent switches. To quote its web site: "Maranti CoreSTOR 3000 is a modular, Network Storage Controller which scales to 128 ports across the highly-available chassis. CoreSTOR 3000 delivers distributed virtualization and Storage Services across heterogeneous storage arrays with dynamic Storage Quality of Service (SQoS) enforcement across all ports."
MaxxanAnother intelligent switch comes from Maxxan with its MXV500. The company states: " the new MXV500 eliminates the need to deploy storage applications on host servers, independent appliances or array controllers. Its design reduces operating expenses and overall management costs by centralizing the deployment and management of applications such as virtualization, data replication, snapshot, mirroring, NAS and virtual tape to a heterogeneous IT environment. The MXV500 scales up to 256 ports in a single-chassis and up to 512 ports in a dual-chassis configuration without the need for Inter-Switch Links (ISL) that reduce SAN performance, allowing the full 512 ports to be configured and managed as a single intelligent fabric."
McDataMcData's Intrepid 10000 director is an intelligent device using technology McData acquired when it bought Sanera. A McData spokesperson has discussed in-switch virtualisation which the Intrepid 10000 can be expected to offer.
McData also has bought-in CNT's UMD high-end director that offers intelligent switch functions.
SAN simplicityThe notion of having storage virtualisation carried out by, in effect, the SAN fabric, with no obvious performance throttling and no server SW agent dependency, provides a much simpler route to achieving the virtualisation end. Just as we accept virtualisation carried out within and by disk arrays because it is hidden and 'just happens' so too we will probably accept in-fabric, or rather in-switch, virtualisation for the same reason. This assumes of course that cost and performance levels are acceptable.
And so...It's early, quite early, days yet in the intelligent switch area. Exactluy what an intelligent fabric platform does is open for debate. Who provides the software, the layer 4 level storage applications, is up for debate. If it is third parties like Veritas, Legato, Alachritus and IBM then they will surely want a standard API for talking to intelligent fabric platforms.
There is a potential standard, called FAIS, for Fabric Application Interface Standard. CNT's UMB box supports it. McData's Tom Clark has written about it.
Maxxan and Maranti have to persuade customers to buy boxes from new and relatively un-tried suppliers instead of from Brocade, Cisco and McData. And these are generally going to be critical boxes for large SANs belonging to risk-averse customers. That could be a tough call.
With five busy and active vendors building SPAID products there should be a lot of developments occurring over the next year or two.