With iSCSI SAN servers called upon to serve many different operating systems at the same time, an initial concern for any deployment is simple interoperability: Do these products work with different operating systems?

We tested each iSCSI SAN server with three very common use cases. We deployed them in a test environment with software initiators for Microsoft Windows Server 2008 and Centos 5 Linux, and a hardware initiator from QLogic. In iSCSI terminology "initiator" is the network equivalent to client, while "target" is the network equivalent to server. We'll use "virtual disk" instead of target to help keep things clear. Our results show many different models for how iSCSI initiators and virtual disk targets authenticate, load balance and interact.

Basic operating system interoperability was fine for all products tested. And we were able to connect and exchange data with the three different initiators -- eventually. Three products gave us some headaches along the way, though. The Nexsan SATAbeast and the Kano NetCOR 7500 systems both required software upgrades before they worked properly. The Kano NetCOR 7500 reacted to our Qlogic hardware initiators by actually crashing the controllers. Because the Kano NetCOR 7500 has dual controllers acting as a high-availability pair, one controller would crash and the other would take over, but the whole system never completely stopped working, even as the crash-takeover-reboot cycle kept repeating itself. The Nexsan SATAbeast didn't work well with Windows Server 2008 when we ran it with multiple data paths, refusing to connect to Windows some of the time. A firmware upgrade downloaded from the Nexsan Web site solved that problem.

We encountered a more subtle problem working with the Compellent StorageCenter on Windows 2008. Compellent uses a model for disk space where its products transparently allocate disk from various parts of the subsystem based on performance. When a new virtual disk drive is created and quickly filled with data, there may be system delays while the Compellent controller gathers array space. Compellent engineers advised us to edit the Windows registry settings to increase disk timeouts to resolve the problem.

The ensuing interoperability challenges we then encountered all focused on a single area: making the connection between the iSCSI initiator and iSCSI target fast and reliable.