Coraid's simpler-than-iSCSI Ethernet storage protocol has been validated by ESG which found it could install and use it in less than two minutes, and get better-than Fibre Channel performance at a fifth of the cost. Coraid's EtherDrive SAN storage uses the lightweight ATA-over-Ethernet (AoE) protocol to link servers and storage …
There is so much fail here
There is so much fail here, I hardly know where to begin:
1) FC does NOT run SCSI over a high-level networking protocol. The parts of FC that actually pass traffic are rather low-level. Other than the simple (and woefully lame) BB-Credits, it's a low-level, fully-switched transport with no more overhead than straight Ethernet.
2) They magically ensure lossless delivery. Great. How does it pull this feat off without adding overhead? Or does it merely assume lossless delivery like Fibre Channel, and then go to crap when the network isn't as lossless as hoped. (Getting Ethernet congestion control working and deployed is what is retarding FCoE deployment.)
3) "It found that it could take LUNs offline while virtual machines are running and not have a server crash. You can't do this with most if not all Fibre Channel and iSCSI SANS." False. Back-end LUN mirroring is not a new feature. IBM's SVC does this I know (vDisk mirroring), and I'm sure it's not a unique feature.
4) "Rock-solid reliability"? They tested this how? Of COURSE a few live part pulls didn't cause it to fail; those are the easiest failover cases to test.
5) Even with existing reasonably-simple SAN arrays you don't need a "storage administrator" to provision storage; minimal training and you are good to go. But once you have a large reasonably complicated environment, it isn't the complexity of the CLI that holds a server admin back.
I ignore all ESG "independent reports". All the storage vendors use them to write puff-pieces.
Ok, it's a total puff piece. AoE is still nifty.
Really, AoE is worth a look The specification is impressively brief.
If I were to pick on something awkward, I would wonder what happens when the ethernet switch became saturated. Everyone knows ethernet is fast and cheap under ideal conditions; when it's not too busy. When it's stressed, well...
Some light reading was coughed up by the development of the LHC:
Pity they didn't (couldn't?) name the switches.
A paper on FC behaviour when similarly stressed? Anyone?
Not really a new idea
A non routable ethernet protocol for storage not using IP and TCP, something new? Not really. Good old DEC used many non routable ethernet protocols for specific purposes. For storage they had the Mass Storage Control Protocol.
From the the introduction of the MSCP manual (1982):
Mass Storage Control Protocol (MSCP) is the protocol used by a
family of mass storage controllers and devices designed and built
by Digital Equipment Corporation. In a system that uses an MSCP
storage subsystem, the controller contains intelligence to
perform the detailed I/O handling tasks. This arrangement allows
the host to simply send command messages (requests for reads or
writes) to the controller and receive response messages back from
the controller. The host does not concern itself with details
such as device type, media geometry, media format, error
To me this even sounds better then sending ATA commands over a low level ethernet protocol.
Plan9 finally on route to victory?
CoRaid is the one cool company that largely develops on Plan9
All the best to them, and in a way using AoE on a small lan might still be less fail than any enterprises falling for the FCoE hoax, pulling out their working setup to find convergence is when they need to deploy a second LAN on expensive high-specced 10GE switches and still never get full ISL speeds :)
Way too many fails
AoE - ATA over Ethernet. Easy, ATA doesn't offer much of a sophisticated command set, it's all master-slave stuff so the transport can be simple. I see resource locking is pretty coarse, hmmm, not good for performance. In essence a point to point topology that's exploiting that most all Ethernets are now layer 2 switched. Not much likelihood of collision there so traffic can assume the network to be deterministic. AoE can't be regarded as a storage network but it's good enough for simple configs (otherwise there'd be no CoRAID customers).
iSCSI - protocol heavy & exploited by LeftHand and Equallogic to build storage networks out of server bricks. So the thinking goes, Joe Admin's comfortable with NAS, let's do something similar but hook up via iSCSI. iSCSI ok its weight mitigated by network speeds but the "brick" concept.... I (personally) don't believe the brick concept, in all failure modes, can assure a write all the way through its appliance software, the underlying OS stack and the off-the-shelf RAID controller to the disks (it's only the last bit that has cache). Of course, Joe's use case might not be sensitive to a little bit of data loss.
FCoE - overcoming the reasons "ethernet" networks are not good for complex storage networks.
Simple, really, it's about choice & how easily that's ill informed. However, with run for consolidation on virtualised infrastructure Joe Admin needs to be confident of how he's managing his risks.