Slashdot Mirror
iSCSI vs. Fibre Channel vs. Direct Attached Disks?
mrscott asks: "Does anyone have any good, simple benchmarks about iSCSI performance in a SAN as it relates to fibre channel and direct attached storage? There's a lot of information out there about iSCSI TCP offload adapters that improve performance, but it's still hard to get a handle on even those stats without the original numbers for comparison. We're considering an iSCSI solution from Lefthand networks, but finding independent (and reasonably simple) numbers has proven somewhat difficult, even with the awesome power of Google behind me."
With disks so cheap just add another disk to ServerA.
m
There are many external SCSI storage systems with integrated RAID and management functions (everything from audible alarms to SNMP/email support). e.g. http://www.promise.com/product/externalstorage.ht
The cost of disks have fallen so much that the idea of a giga-SAN ($$$$) to master all storage is just plain silly. Local attached external RAID storage with management is all one really needs. Only when talking about multi-Terabytes of data should one consider a SAN.
This sig space tolet, reasonable rate.
What do you mean by 'more promise'? I agree that iSCSI is complicated, but there is a reason it was done at the IP level. Another thing that diffrentiates iSCSI from ATAOE or even HyperSCSI (SCSI over Eth), is its inbuilt catering for redundancy,scalability and error management. In fact, if you look at the iSCSI spec approx 40% caters to error management, and in IMHO is done well.
Regarding complexity, speed is not an issue as protocol processing is already being offloaded into hardware. The big advantage of going over IP is just that. An IP packet is ubiquitous.
And when you've filled the rack that the server is in, where do you stick your disk array? Or do you only populate your racks 1/3 full, to allow for additional capacity, just in case? When the server in the 1U case needs more disk, where do you add it? How do you add space w/o taking the server down? A TB is 1000 GB, which is 100 10GB servers. Any decent sized shop will easily suck up a TB. Any large shop will devour lots more.
I want to delete my account but Slashdot doesn't allow it.
but, but... iSCSI has nothing to do with Ethernet.
iSCSI is an IP protocol, and it could be running
over anything that sends datagrams. FiDDI, HiPPI,
Myrinet, la la la...
If you dislike iSCSI over Ethernet (and frankly,
it's only interesting in low-performance cases where
IP routing is important for WAN access to NAS,
so I can understand your aversion), don't use it.
But keep iSCSI in your toolkit. The interoperability
and the option to route is extremely valuable.
-I like my women like I like my tea: green-
That's called, "having all your eggs in 1 basket", and we all know what a bad idea that is...
About the booting part: at work we boot from local disks because we Unix SAs don't have control of the EMCs, thus if a machine does not boot, we cannot do much beside calling someone who has no idea about Sparc machines. If we Unix SAs were able to control the EMCs and everything related like the FC switches, then we would boot directly from SAN. If I were able to control the iSCSI storage box, the routers and switches for the iSCSI SAN, then I see no problem of not booting off the local disks. After all, if a machine does boot but all the data and apps is not reachable, the machine is not very useful. A not booting machine is not much better.