Over time, every technology ages and starts to cause its own problems. That's happening now with RAID (Redundant Array of Independent Disks.) For years, the various flavors of RAID have been one of the most cost-effective ways to boost disk performance and to protect data that an organization can't afford to lose. Raid stripes data across multiple disks to either increase the speed with which data can be read from or written to the disks, or to ensure no data is lost if even one disk fails.
But as the amount of data that can be stored on the average drive rises to hundreds of gigabytes, or even a Tbyte or more, the amount of time it takes for a RAID array to recover from a disk failure can stretch into a day or more. Customers can't wait that long if they need that data to accept orders, ship products or keep their e-mail system up.
A number of vendors in the iSCSI space are claiming workarounds to this problem. By creating mirrors of LUNs (logical unit numbers) FalconStor's FalconStor IPStor can continue to run as a primary storage device (keeping data available) even while a failed disk is being rebuilt. The high end of Hifn Inc.'s Swarm SAN appliances use Raid 61, which creates two sets of parity data, either of which can be used to rebuild data from a failed disk. This allows the array to remain functioning even while rebuilding not one, but two, failed desks.
My guess is that like most "legacy" technologies, RAID will never fade away, but just be enhanced and improved over time. That means some of you will get to pitch "RAID is dead" stories to editors, and others will get to pitch "RAID isn't dead after all" stories. The good news is that either way, you can make a good, convincing case -- as long as you're very, very clear about exactly which RAID-related problems you're solving, exactly how you're solving those problems and of course why your approach is better than the competitors. And don't forget those all-important reference customers, either.
Recent Comments