Tuesday, December 15, 2009

Network Computing Feature: WHY A STORAGE BACKBONE BENEFITS FROM HARDWARE INDEPENDENCE WHEN BUILDING A STORAGE VIRTUALISATION STRATEGY.

http://networkcomputing.co.uk/articles/reviews.asp?a_id=253
From Network Computing Vol 18

Over the past 12 months as the credit crunch has deepened, organisations have sought alternatives from purchasing costly storage hardware. In turn, many have explored the adoption of software virtualisation to enable and optimise their storage. They have understood that software based Storage Area Networks (SAN) offer immediate advantages to the bottom line, invariably meaning that the IT Department can enable the project to progress, rather than be stopped at sign off. The Finance Manager has also seen that software based SANs enable the IT Manager to repurpose existing hardware, or to elect to buy lower cost hardware, as opposed to always chasing newer, high cost hardware, to get the required functionality.

The inherent beauty of storage virtualisation software is that it can bring high performance and high functionality along with hardware independence at lower investment and with lower operational costs. This approach can also be highly complementary to an IT Department's preferred hardware, giving an extra lease of life, or adding that extra functionality normally only available on highend disk arrays. So storage virtualisation, like server virtualisation, implies the use of software to overcome inherent hardware limitations, without regard to the make or model of the underlying storage devices; those who limit use of this powerful technology to a given hardware configuration, are doing the industry a disservice, setting users up for avoidable obsolescence. The central point of the debate lies not in hardware versus software, but in the hardware choices offered to run the storage virtualisation code, this year, next year, and the year after that.

Pick an appliance and your fate is sealed. The moment that appliance runs out of steam, be it processing power, I/O bandwidth or expansion slots, determines its end of life. The rate of change in the computer industry suggests that could be as short lived as 6 months. What would you say to anyone who told you that your server virtualisation license can only run on your current server? And that you have to buy a new license to move it to a bigger or faster server? Worse yet, that you have to buy them together from the same supplier, who only offers two models! And it only supports their "special" disks. Pretty ridiculous, but that is exactly what storage virtualisation appliance vendors promote under the header of being 'factory integrated'.

Does it matter whether you use Fibre Channel or iSCSI for a software based SAN? Both provide solutions for different needs today. Fibre Channel is very fast and easily outperforms iSCSI at the moment. It was designed and optimised for a SAN, and many companies have taken the jump and invested in Fibre Channel switches, Host Bus Adapters and storage, but it is costly compared to IP SANs where iSCSI uses NICs and switches that are commodity items, available at commodity prices. Often an enterprise that has already invested in Fibre Channel or needs the performance of Fibre Channel for its high transaction and high workload applications also uses iSCSI for lower performance applications.

Using the existing skills in an organisation of IP Networks rather than the 'dark magic' of Fibre Channel, means that human resources are more readily available and their costs are invariably lower. But as technology moves forward and iSCSI speeds increase from 10Gbit to 100Gbit and eventually to 1Tbit, the cost differences will be minor, let alone looking at FCoE, and other network technologies of the future.

Once again, only a truly independent software virtualisation solution can work with all these technologies today and future proof the options for tomorrow. Those who have adopted a hardware appliance have done so at their own peril, playing the future-guess game and possibly limiting their business.