HOW iSCSI WORKS

When an end user or application sends a request, the operating system generates the appropriate SCSI commands and data request, which then will be encapsulated in an iSCSI packet and send over a TCP stream. When a packet is received, it is disassembled.

iSCSI: SANs FOR THE REST OF US

The benefits of Fibre Channel SANs are widely known. The problem has been that it's very expensive and has therefore been limited to the the largest of enterprises, it adds a new and relatively foreign layer of IT infrastructure and administration, and has distance limitations because its intended use and subsequent design.

IP SANs, namely iSCSI, have lowered the cost of entry to that of traditional SCSI or NAS solutions, maintained the performance that FC has demonstrated, and converged two distinct IT concerns over one medium. By leveraging IP, all provisioning, administration and infrastructure requirements are applied to storage, thus enhancing what can be done with storage.

For more information on articles, case studies, ROI & TCO, design and use ideas, please visit these sites.

iSCSI Vendor List and Info: http://www.storagesearch.com/iscsi.html and http://www.iscsistorage.com
iSCSI Primer: http://www.digit-life.com/articles2/iscsi/
Storage Networking Industry Association's focus on IP Storage: http://www.snia.org/ipstorage/home

iSCSI: LIMITATIONS AND HURDLES

Ethernet is the standard for LANs everywhere. IP is the standard for transmitting and receiving data, too. Whether you have 10Mbps, 100Mbps, 1Gbps, even 10Gbps (there are specifications in the Ethernet steering committee that support up to 10Tbps currently), your IP packets traverse the LAN, MAN and WAN everyday.

There are a few things you should be aware of when designing an IP SAN, however. First, TCP has some inherent overhead embedded in the protocol. This is necessary when transmitting over unsecured and potentially unstable networks (e.g., the Internet). This overhead reduces performance of the theoretical speeds of Ethernet. Additionally, the faster the implementation of Ethernet, such as 1Gbps, the larger and more frequent the TCP overhead will be on the servers and clients in the network. One major reason folks have had to upgrade their servers when migrating to 1Gbps Ethernet can be traced to the simple fact that they're now handling roughly 10 times the TCP they were before. This can severely cripple, even crash servers that are only a couple years old.

To overcome the TCP overhead is to offload it from the host (i.e. server or client workstation) to the host bus adapter (HBA) or network interface card (NIC) by using TCP Offload Engines, or TOE. TOE embeds the TCP header management layer in ASICs and code that are embedded in HBAs and NICs (referred to as TNICs in the case of the latter).

Not only have TOEs proven their value in 1Gbps and early 10Gbps uses for general IP traffic, but they've enabled iSCSI to reach performance speeds that rival Fibre Channels. Nearly every case that has implemented some form of TOE has reported near wire-speed throughput with IP and iSCSI.

Another concern about using IP for storage is security. Many Fibre Channel gurus will insist that having a separate, unique topology for storage traffic is the only sure-fire way of insuring that data's integrity and safety with each transfer. There are many arguments against this, even some who would say that a statement like that simply reflects the fear of job security and the ignorance of IP's more robust and diverse security features over FC's. IPSec and other security features in IP deployments provide a rich set of features for one to work with. Whatever the case or the argument, security is a very critical concern and one that needs to be addressed in new ways when designing and using IP storage services. If you do not have such expertise, you can contact us.