iSCSI

The protocol allows clients (called initiators) to send SCSI commands (CDBs) to storage devices (targets) on remote servers.

[3] In essence, iSCSI allows two hosts to negotiate and then exchange SCSI commands using Internet Protocol (IP) networks.

Unlike some SAN protocols, iSCSI requires no dedicated cabling; it can be run over existing IP infrastructure.

However, the performance of an iSCSI SAN deployment can be severely degraded if not operated on a dedicated network or subnet (LAN or VLAN), due to competition for a fixed amount of bandwidth.

iSOE may be implemented with additional services such as TCP offload engine (TOE) to further reduce host server CPU usage.

These arrays can be in the form of commodity hardware with free-software-based iSCSI implementations, or as commercial products such as in StorTrends, Pure Storage, HP StorageWorks, EqualLogic, Tegile Systems, Nimble storage, IBM Storwize family, Isilon, NetApp filer, Dell EMC, Kaminario, NS-series, CX4, VNX, VNXe, VMAX, Hitachi Data Systems HNAS, or Pivot3 vSTAC.

In enterprise deployments, LUNs usually represent subsets of large RAID disk arrays, often allocated one per client.

For general data storage on an already-booted computer, any type of generic network interface may be used to access iSCSI devices.

[citation needed] However, a generic consumer-grade network interface is not able to boot a diskless computer from a remote iSCSI data source.

This can be achieved using an existing Preboot Execution Environment (PXE) boot ROM, which is available on many wired Ethernet adapters.

iSCSI initiators and targets prove their identity to each other using CHAP, which includes a mechanism to prevent cleartext passwords from appearing on the wire.

The iSCSI negotiation protocol is designed to accommodate other authentication schemes, though interoperability issues limit their deployment.

To ensure that only valid initiators connect to storage arrays, administrators most commonly run iSCSI only over logically isolated backchannel networks.

This mitigates authentication concerns; unauthorized users are not physically provisioned for iSCSI, and thus cannot talk to storage arrays.

While iSCSI could be implemented as just a VLAN cluster of ports on a large multi-port switch that is also used for general network usage, the administrator may instead choose to use physically separate switches dedicated to iSCSI VLANs only, to further prevent the possibility of an incorrectly connected cable plugged into the wrong port bridging the logical barrier.

As a pathological example, a single enterprise storage array could hold data for servers variously regulated by the Sarbanes–Oxley Act for corporate accounting, HIPAA for health benefits information, and PCI DSS for credit card processing.

For the most part, iSCSI operates as a cleartext protocol that provides no cryptographic protection for data in motion during SCSI transactions.

Third-party drivers for Windows and Linux were available as early as 2001, specifically for attaching IBM's IP Storage 200i appliance.

Multiple systems exist that allow Fibre Channel, SCSI and SAS devices to be attached to an IP network for use via iSCSI.