Hardware

Ask something
Question Locked

SAN on Windows, SAN on Unix or iSCSI?

0 helpful
3 replies

by neon samurai

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

My own initial ideas are the following though I'm in early research on the topic.

Between SAN and iSCSI the latter is probably prefered for speed and security. I'm mostly basing this on speed as I'm not sure what platform iSCSI would require on the storage side or if it can be managed purely as a hardware appliance function.

Between SAN/Windows and SAN/Unix, my initial feeling is the latter also.

- higher potential security in the Unix host OS
- better use of resources in the Unix host OS
- minimal Unix install requiring only the SAN application dependencies

In skimming a whitepaper on SAN/Windows the points raised for the first option above are the following:

- Windows memory management catches hidden memory errors
- Windows provides deterministic interrupt processing (aka. real-time processing)

- Unix like OS must have SAN vendor kernel modifications to provide close to real-time processing required for 400, IOPS processing. This can also introduce undocumented issues which can only be fixed by the vendor when discovered.

These are not measured facts as I have to read up on the various solutions further. What have others found in adding SAN solutions? Has anyone run on top of Windows and Unix host platforms or compared SAN and iSCSI options?

3 replies

by churdoo

I am by no means an expert either. You refer to SAN vs iSCSI seemingly as the communication vehicles between the servers and the disk storage, presumably that of a Storage Area Network. Do you really mean Fibre-Channel vs iSCSI as 2 of the prevalent communication mediums between the servers and storage on the SAN?

Since Fibre Channel is presently implemented in 2gbps and 4gbps, and since iSCSI runs over TCP/IP which presently tops out at 1gbps, the Fibre Channel is actually faster than iSCSI. Also there is a lot of CPU overhead required for typical TCP/IP operations, so without a TOE card (TCP/IP Offload Engine), CPU utilization just to manage the iSCSI communications would take away from the total throughput as well.

So even though iSCSI is not faster than Fibre Channel, some of the nice things about iSCSI are that since it does ride over TCP/IP, it can run over existing IP infrastructure, and even over WAN links (security?). It can also run over regular ethernet cards, but again as stated above, TOE cards are recommended. Another benefit to iSCSI and the fact that it runs over IP, is that it doesn't require any (or much) additional training to set up your SAN iSCSI IP network -- i.e. even though iSCSI "can" run over existing IP infrastructure, you generally don't want it to, and will generally create a separate IP infrastructure for your iSCSI IP traffic.

Fibre Channel, again typically runs at 2gbps or 4gbps, and requires a fibre channel HBA or Host Bus Adaptor, fibre patch cables, and fibre channel switches. The HBA can be a bootable device, so you can have servers boot from the SAN with zero local disk. The fibre-channel switches and Fibre Channel network are somewhat different than IP switching, so some retraining is required (i.e. switch zoning for one).

Just some general comments on some connectivity options. I've only used the SAN with Windows servers so I know nothing of Windows/Unix SAN operability comparisons.

by neon samurai

When mentioning it to some other local techs, I asked about SAN and they suggested skipping a SAN solution in favor of bulk storage through iSCSI. I'm guessing the aproach would be a two or three U rack chassis with a row of hotswap drive slots in the front and a iSCSI port out the back. The software between the two I'm learning about now.

Cheers though, this gives me more direction for my reading.

This discussion is closed to new replies.