ISCSI to SCSI Bridge! 1

[Walyeska]

Hi, thanks for reading. I am interested in input about ISCSI to SCSI bridging vs. actual SAN implementation. Is anyone using bridging? If so in what area do you use it? What benefits have you gained/lost from it? I see the selling point of turning your DAS into a NAS via ISCSI bridging, but other than a couple small situations I do not see other uses for it. Can someone enlighten me on why this may be a better solution (other than cost) than to not implement a SAN or AD NAS?
Essentially we are a Novell shop and NAS is not an option so we are looking at alternative solutions to a full blown SAN.


Thanks!

 

[comtec17]

It is not a better solution, just a cost effective one.

NAS and SAN are simular with a few exceptions.

NAS - File level transfer structure using CIFS/NFS and network protocols.

SAN - Block level transfer structure using SCSI commands.

iSCSI - Block level transfer structure using SCSI commands but limited to the network speed of the infrastructure. Is a cheaper alternative to SAN but only runs 1Gb performance and the Disk I/O is much slower.

Please note that when using an iSCSI bridge with a DAS device doesn't give you many options or much security at a LUN level. Typical DAS devices do not have Caching mechanisms to help with Disk spindle performance.

There is much more detail, but I have to run to a meeting. I hope this information helps.

 

[xmsre]

iSCSI - Block level transfer structure using SCSI commands but limited to the network speed of the infrastructure. Is a cheaper alternative to SAN but only runs 1Gb performance and the Disk I/O is much slower."

That's a gross oversimplification that's not correct in all cases.

Let's start with:

FCP - Block level transfer structure using SCSI commands but limited to the speed of the dedicated Fibre Channel infrastucture. Current signaling speeds include 1G and 2G with 4G and 10G trunking on the horizion. A FCP frame carries a max payload of 2112 bytes. Each transfer includes overhead involving a fibre channel exchange and sequence. The FCP exchange overhead is fixed irregardless of the transfer size. Typical transfer rates for small block IO (4K) on 1G fibre are ~30mb/sec. As the block size increases, the efficiency increases. At a 64K block size, the transfer rate is about 85mb/sec for 1G fibre.

Let's modify the iSCSI explanation:

iSCSI - Block level transfer structure using SCSI commands but limited to the network speed of the (preferrably dedicated) network infrastructure. The overhead of iSCSI is a thin sequence layer. The overhead remains fairly constant irregardless of the block size. With Jumbo Frames enabled, the max payload of an iSCSI packet is about 9000 bytes. For small block IO (4K) on 1Ge, transfer rates of 118mb/sec can be expected. Increasing the block size does not significantly increase transfer rates. Current signaling speeds are based on 1Ge with 10Ge on the horizon.

For small block IO, iSCSI is significantly faster than current 2G FCP, even though the signaling rate is twice as fast for 2G FCP. For large block IO, 2G FCP wins hands down. The size of the transfer is driven by the application and is something you design to, not something you set. For MS Exchange, the IO size is generally 4K, SQL - 8K, Oracle - 8K, Lotus Domino - 4K. On the Windows platform, you can use perfmon to determine the IO transfer size of your application.


Take a look at the SNIA presentation "SCSI - The Protocol for All Storage Architectures" for more information on the FCP and iSCSI implementations of the SCSI protcol.

http://www.snia.org/education/tutorials/spr2005/storage/#scsi-the-protocol

I hope this information helps