iSCSI benefits from this characteristic, hence, every iSCSI implementation should have some kind of high-availability mechanism built in. Storage vendors have also upgraded their multipathing software to support iSCSI and FC. The use of such software is recommended in addition to the IP mechanisms cited above.

FC SANs enjoyed an intrinsic sense of security because the networks were isolated from the rest of the infrastructure, minimizing external and internal intrusion. Basic security, such as LUN masking and zoning, is also available in iSCSI networks. But that's not all. By default, iSCSI configurations are insecure and by their nature (being IP-based) are exposed to much more risk than FC SANs. In the IP security world, authentication, authorization and auditing categories are commonly used. Most iSCSI configurations can be secured by the use of IPSec, a protocol commonly used in virtual private networks. iSCSI networks should never be configured for open access, just like a server should never be configured for remote access without passing any login credentials.

Booting from SAN
In the FC world, this is a dead issue. Within iSCSI circles, though, this is a topic of great debate and discussion. Should you or should you not boot from an iSCSI SAN? In my opinion, the same reasons for booting (or not booting) from an FC SAN apply to an iSCSI SAN: asset and storage management.

Booting from the SAN allows you to centrally locate all operating system images and eliminates individual images stored internally on servers. This is especially helpful in diskless blade and virtualized environments. But boot from SAN may be a stretch if you're converting to an iSCSI environment and your systems currently boot from local disk. In that case, you're better served keeping your legacy environment as is and having your newer servers boot from SAN.

Performance
In FC networks, one doesn't generally talk about protocol overhead. Indeed, we may be hard-pressed to accurately gauge the overhead posed by the FC protocol. This is because all of the processing is offloaded to the processor on the HBA. In many early iSCSI implementations, iSCSI HBAs or TCP offload engines were available. Some vendors still offer them. Most low-cost iSCSI implementations, however, tend to use just the onboard network interfaces. All of the protocol processing is performed by the server CPU. So the busier the I/O to the iSCSI LUN, the more cycles the CPU needs to spend. This isn't an issue for most applications with medium workloads, but it's something to be aware of when specifying the system configuration for a host to be used as an iSCSI client.

In the IP world, TCP/IP tuning can be an exhaustive exercise. Because iSCSI is IP-based, it's not spared this troubleshooting. While the list of tunable parameters can easily fill a few pages, not all parameters apply to all situations; the storage and/or the iSCSI initiator vendor will generally have a list of parameters that need to be examined. The untuned iSCSI system will function, but the slightest load may cause performance issues.

Once you've deployed your first batch of iSCSI storage systems, you can build on top of that comfort level to deploy more complex solutions such as clusters. The basic concepts of clustering on the SAN remain the same as for FC, except the LUNs are now accessed via iSCSI.

So there you have it. iSCSI is a mature protocol for accessing storage and a solid alternative to FC. Fibre Channel may not be going away anytime soon, but iSCSI is definitely here to stay.