Earlier, we talked about iSCSI HBAs that have built in TOE cards or TCP offload engines. One of the risks with iSCSI is that storage performance or the CPU bandwidth utilization might be higher than people expect if they don't use the TCP offload engine, so the server carries a bigger burden in non-iSCSI HBA environments. That could be a risk if the servers are already pretty heavily burdened.
In non-prioritized networks it could go one of two ways. First, the iSCSI performance could suffer and people could be dissatisfied with it. Or, iSCSI traffic could saturate the network, upsetting other areas of network performance. IP telephony, for example, could suffer because of putting iSCSI on the network. There's a risk there.
One of the other things people don't think about is that iSCSI is easy to deploy. It's not contained like a traditional Fibre Channel SAN. It's difficult to reverse-engineer existing iSCSI infrastructures to determine who is using which storage. Documentation of an iSCSI SAN, if not done with discipline, could turn out to be a risk in the long run. Imagine if you don't know where that iSCSI initiator is -- it's somewhere in the ether -- and you need to do a storage upgrade on your storage array. You'll want to warn all of your customers about a possible outage. But you have no idea where the device is; without good documentation, it could make maintenance difficult.
Listen to the iSCSI vs Fibre Channel podcast here.
Go back to the beginning of the iSCSI vs Fibre Channel FAQ Guide.
