Slashdot Mirror
HyperSCSI Examined
An anonymous reader writes "Eugenie Larson of byteandswitch.com has published a brief article that reviews the HyperSCSI protocol, which like iSCSI allows for an IP based san. The twist of HyperSCSI is that it's opensource, and runs over raw ethernet, avoiding the overhead of TCP/IP. The article has some comments from early adopters of HyperSCSI, as well as some comments from top vendors in the iSCSI industry."
The summary says "IP based" then "without the overhead of TCP/IP" and then "raw ethernet".
Which one?
Can't be both IP based and raw ethernet at the same time.
You don't expect us to RTFA do you?
And this is a technology breakthrough? I wouldn't want my data travelling down a wire with no error recovery no matter how small the error rate.
From excellent karma to terible karma with a single +5 funny post...
Two big disadvantages:
First, Ethernet can't be routed, so hyperSCSI isn't going to be nearly as flexible as iSCSI. This is the reason that just about everything that might want to be routed is usually carried over IP (and TCP and UDP and other stuff on top of IP). Straight ethernet is for stuff like ARP that really doesn't want to leave a network segment.
Of course, one could reasonably do something hyperSCSI-like across IP, and still save the TCP overhead. (Consider that in a low-loss short-hop environment, NFS over UDP generally outperforms NFS over TCP). The problem here is that SCSI was never ever intended to run well over a lossy transport, and it doesn't. That seems a serious objection to running SCSI over both non-routable and non-reliable ethernet and routable but still non-reliable IP.
C'mon, there's a reason why people use TCP....
And why iSCSI chose TCP as the transport....
Use loose and fast HyperSCSI on your local segment where it's possible, and use a concentrator that translates into iSCSI over IPSEC for secure WAN connectivity.
That way you only need to buy one TOE card per WAN edge. Those can get expensive!
Fuck Beta. Fuck Dice
i've got tonnes of files that i'd like easy to access, speed is minimal,, it would still be far less that looking thorough my over 500 cd's for a doc file or game,, etc..
Reece,
If it is truly raw ethernet, this means that you cannot route it. On most current networks, you probably wouldn't want to because of latency issues, but, on networks with 1 gig or 10 gig links, latency should not be a problem. So, if it does use raw ethernet, this is actually a limitation of it, not a benefit.
Need Free Juniper/NetScreen Support? JuniperForum
More to the point, we have usb 2, serial ata, and firewire. Really all you should need is usb 1.1 and firewire in ever-increasing speeds, besides your display output. There's literally no need for anything else. Firewire can be operated in a synchronous fashion, after all. It supports lots of devices per adapter (63 or 127 depending on implementation) and comes in powered and unpowered as well as peer to peer or host-based forms, but nearly all devices will fall back to the lowest, slowest mode - which is capable of 400Mbps per second, or 50 Megabytes, clearly enough for all but the fastest hard drives, and nearly any other use to which you might put it. 800Mbps firewire is available today, and 1.6Gbps is uh, just over the horizon or something. They claim they'll do 3.2Gbps over fiber in the near future as well, but I'll just stick to developments just over the horizon, not way over it, here.
Frankly what I want to see more than anything is native 1394 storage devices. 1394 is somewhat to scsi (it would kind of have to be, wouldn't it?) and is at least well documented. I want hard drives that have only power and 6 pin 1394 connections on them, pass through style. You could treat them basically like an external scsi chain not requiring termination, but inside your PC. Firewire to IDE bridges are not the answer, they just make things more complicated and firewire is supposed to make things less complicated, though I suppose they are a sort of interim solution.
For the average user, if you could get native (and thus inexpensive) firewire solutions for everything, it would fulfill your needs much better and would make computer use much simpler. The only thing you need besides firewire and USB for every common peripheral is video output and possibly high speed networking, perhaps provided from a MII or similar connection, just as AUI was the standard at one time. Just, without the annoying box and cables. And let us not forget, a memory slot. I assume most people would also like to have wireless ethernet with an external antenna jack. For the rest of us, we would continue to run our however-shaped boxes with internal expansion, PCI-Express or what have you, and our cabling would be much simplified. Once again, 800Mbps is 100MBps, yes? Assuming you can only really sustain 50 or 60% of that with multiple devices competing for the bus, that's still fast enough for basically any two hard drives anyone is likely to have at home. So 800Mbps firewire is perfectly adequate to the task of connecting hard drives today. It's not that SATA isn't, it's that having less types of interface simplify a computer. If you're only going to have two interfaces, you will get more mileage out of USB2 and IEEE1394 than you will USB2 and SATA, even one of the bastardized forms of it like External SATA, if people will just make IEEE1394 devices.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Fiber Channel SANs aren't based on IP either, yet people manage to do off site replication with them.
I don't know how far away you want to put your off-site backup, but Cisco have been selling a GBIC (Gigabit Interface Converter ? Too many FLAs for my head these days), which they've been calling 1000BaseZX, which will send an GigE signal around 90 Kilometers over single mode fibre.
Even Full Duplex Fast Ethernet over multi-mode fibre will go 2 Kilometers.
You can build some really big ethernet networks these days. I don't think the non-IP thing is all that much of an issue.
Although the idea of using cheap commodity equipment like ethernet is to rationalise multiple networks down to a single IP network, there are also good reasons to using commodity ethernet to build a separate network for your storage, security being the main one. It probably wouldn't be too good to have CodeRed or other worms of its ilk infecting your storage network.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
The lessons of NFS are being ignored, and I'd expect HyperSCSI to die when it hits the same limitations.
NFS started out UDP-based, and moved toward TCP with NFSv3. Why? Because having all that error correction done at the network layer made for a better product; TCP does all the work to insure packets aren't lost or out-of-order. UDP doesn't, and the NFS application layer had to handle it, making it slower, more painful, and a duplication of effort better spent elsewhere.
The industry guys are almost right on this one. It isn't a beer can with a motor; it's a beer can with an M-80. Fun to watch when it works right, damn painful if you screw it up.
In looking for a cheap substitute for a FC SAN you don't need or want routing. You're looking a cheap way to implement a local, reliable, high performance fabric. That's all. People like iSCSI because it's compatible with existing infrastructure but they don't stop to think that they won't want to put their server farm storage on the routable corporate net. The problem with ethernet is that it's hard to scale performance with small packet sizes and all the buffering. Work is being done to fix that and it has nothing to do whether it's IP-based or not. Look at InfiniBand and iWarp for what's really important.
Not a tolkien ring?
Otherwise you might accidentally release a product that sucks as bad as NFS.
But seriously, NFS is only good for short haul networks. Over those networks, NFS/UDP is faster than NFS/TCP.
So what about long-haul networks? Answer: don't use NFS. NFS is FAR from secure. User management across administrator domains isn't handled either and therefore is all but impossible.
For what NFS is actually good at UDP usually fits the bill better than TCP.
And funny thing, I think you'll find this the case for internet SCSI too. You don't use a sector-by-sector remote block device protocol over long haul networks. It's horribly inefficient. Use a file-based sharing system instead.
I just think there's a horrible misunderstanding as to what this is good for. This is a block device protocol, not a file access protocol. That means that only one client can mount a drive (or technically range of blocks) at a time. A special case is multiple read-only mounters at once. But you have to bar any write access in that case.
So, if you have a protocol that is inefficient over long-latency links regardless of transport and requires a 1:1 match of volumes to users, why do you care whether it works well from cross country?
I think if you read again, and this time don't assume every poster above you doesn't already know this, you'll see the point they were trying to make.
If this uses it's own Layer 3 protocol (presumably, and for the sake of argument, called HyperSCSI), then it's NOT IP BASED... and the article summary indicated it was IP based, then contradicted itself.