Time To Kill Clustered Raid Controllers

You have 1,000 servers, running 5,000 virtual machines, connected via 2,000 ethernet cables (or even Fibre Channel) to piles of switches, and out of the back end you spit out two lousy little connections to a Raid Controller. Double it for redundancy. Those RAID controllers then fan out to connect to a zillion disk drives.

You see what's wrong with the picture yet? No wonder we're talking about I/O problems for the first time in decades.

A RAID controller is a monolithic compute/IO "system" containing processors, memory and I/O. It's a "SUB-SYSTEM." It's wicked smart and wicked fast. But it's paired (clustered) with another Sub-system to form a "storage system." Sometimes we even cluster more together—like four or even eight! Whoopdie doo.

We have 5,000 vMachines connected to eight RAID controllers connected to 1,000 drives. Nutty.

What we need are 5,000 vMachines connected to 5,000 (or 10,000) RAID controllers, connected to 1,000 drives. That would be far more logical. That would provide linear scale irrespective of transient workloads.

I'll expand in more detail in a paper I'm committed to getting done shortly, but hopefully you see the logic.

Just like it was okay to have one mainframe in 1972, that did all the system functions, be replaced by distributed functionality in the age of of the PC era, so too is it OK to distribute the RAID/IO function in the age of the virtualized distributed era.

Thus I'm now enamoured with the concept of grid as applied to storage.

Massively parallel storage.

High performance storage.

More to follow. Plus a nifty graphic!

Topics: Storage IT Infrastructure