iSCSI (Internet Small Computer Systems Interface) turns standard Ethernet networks into high-speed storage highways. Instead of attaching a hard drive directly to a single computer, iSCSI lets servers send SCSI commands over IP networks, making a remote storage array look and act like a local drive.
If you're scaling an IT environment without the high cost of a dedicated Fibre Channel infrastructure, iSCSI bridges the gap. It uses existing TCP/IP networks to connect servers (initiators) to storage devices (targets). This guide breaks down how iSCSI works, how to configure it, and where it fits in modern data centers.
Understanding the iSCSI Architecture
At its core, iSCSI encapsulates SCSI commands within IP packets. This means storage traffic travels across standard switches, routers, and copper or fiber Ethernet cables. To understand how the system operates, you need to look at its two main components and the protocol layers beneath them.
Initiators and Targets
Every iSCSI setup relies on a client-server relationship split into two distinct roles:
- iSCSI Initiator: This is the client software or hardware installed on the server or workstation that needs storage. The initiator requests data and sends SCSI commands over the network. Initiators can be software-based (built into modern operating systems like Windows, Linux, and VMware ESXi) or hardware-based, using a specialized Host Bus Adapter (HBA) called an iSCSI HBA to offload processing from the server CPU.
- iSCSI Target: This is the storage resource—such as a Network Attached Storage (NAS) device, Storage Area Network (SAN), or a dedicated server—that receives requests from the initiator, processes them, and reads or writes data to the physical disks.
How Encapsulation Works
When an operating system writes a file, it generates standard SCSI commands. In an iSCSI environment, the initiator takes these SCSI commands and wraps them in TCP/IP packets. The packets travel across your local network or wide area network just like web traffic or file transfers.
When the packets reach the iSCSI target, the storage device strips away the TCP/IP wrappers, reads the underlying SCSI commands, executes the read or write operation on the physical disks, and sends the response back to the initiator using the same encapsulation method.
Hardware vs Software iSCSI
Choosing the right implementation depends on your performance requirements, budget, and hardware constraints. You have three primary options for deploying initiators.
Software Initiators
Software initiators are built into almost all major enterprise operating systems. They are cost-effective because they require no specialized hardware—any standard network interface card (NIC) will work.
However, because the server's main CPU must handle the overhead of encapsulating and decapsulating SCSI packets over TCP/IP, software initiators consume extra processor cycles. For most mid-sized workloads, modern multi-core processors handle this overhead easily.
TOE NICs (TCP Offload Engine)
A TOE NIC offloads the TCP/IP processing from the server's main CPU to a dedicated processor on the network card. This reduces CPU utilization and improves throughput, making it a solid mid-tier option for environments experiencing moderate to high storage traffic.
iSCSI Host Bus Adapters (HBAs)
Hardware iSCSI HBAs are dedicated PCIe expansion cards that handle all iSCSI and TCP/IP processing on-board. They often feature hardware-level support for boot-from-SAN capabilities, meaning a server can boot an operating system directly from an iSCSI target without having a local hard drive. These are ideal for high-performance enterprise virtualization clusters where CPU cycles must be strictly reserved for virtual machines.
Network Requirements for Reliable iSCSI
Because iSCSI transmits block-level storage data over Ethernet, network performance directly dictates storage performance. A sluggish or congested network results in dropped packets, high latency, and application timeouts.
Gigabit vs 10GbE and Beyond
While iSCSI can run over standard 1 Gbps Ethernet, high-performance environments demand 10 Gbps, 25 Gbps, or faster connections. Block storage is sensitive to latency. When multiple virtual machines share an iSCSI target, a 1 Gbps link quickly saturates.
Jumbo Frames
Enabling jumbo frames (typically setting the Maximum Transmission Unit or MTU to 9000 bytes instead of the standard 1500 bytes) significantly reduces CPU overhead and packet processing demands. Larger frames mean fewer packets cross the network for the same amount of data, yielding better throughput and lower latency. Ensure that every device along the path—from the server NIC, through all switch ports, to the storage array—is explicitly configured to support jumbo frames.
Network Isolation and VLANs
Never mix iSCSI storage traffic with general office traffic or user internet access on the same unmanaged network switch. Storage networks require strict isolation. Use dedicated physical switches or isolated VLANs (Virtual Local Area Networks) solely for iSCSI traffic. This prevents broadcast storms, minimizes security risks, and guarantees bandwidth availability.
Step-by-Step iSCSI Configuration Example
Setting up an iSCSI connection involves configuring the target storage array first, then connecting the host initiator. Below is a practical walkthrough for connecting a Linux host to an iSCSI target using the standard open-iscsi utilities.
Step 1: Install the iSCSI Initiator Package
On an Ubuntu or Debian-based server, install the open-iscsi package using your package manager:
sudo apt update
sudo apt install open-iscsi
sudo systemctl enable --now open-iscsi
Step 2: Discover Available Targets
Before logging into a target, you must discover the IQN (iSCSI Qualified Name) and IP address hosted by your storage array. Replace 192.168.100.50 with your actual storage target IP address:
sudo iscsiadm -m discovery -t sendtargets -p 192.168.100.50
The command returns a list of available targets, displaying their target IP addresses and unique IQNs.
Step 3: Log In to the Target
Once you have identified the target IQN, establish a session by logging in:
sudo iscsiadm -m node --targetname "iqn.2023-06.com.example:storage.disk1" -p 192.168.100.50 --login
A successful login returns a message confirming that the session has been successfully added and started.
Step 4: Verify the New Disk
Check your system logs or partition tables to confirm that the operating system recognizes the new block device:
lsblk
The new iSCSI storage appears as a standard unpartitioned disk (for example, /dev/sdb). You can now partition, format with a file system like ext4, or hand it over directly to a hypervisor like KVM or VMware.
iSCSI Security Best Practices
Because iSCSI traffic travels over Ethernet networks, it is vulnerable to sniffing, unauthorized access, and spoofing if left unprotected. Securing your storage network requires deliberate configuration choices.
CHAP Authentication
Always enable Challenge Handshake Authentication Protocol (CHAP) for your iSCSI sessions. CHAP ensures that both the initiator and the target authenticate each other before data transfer begins, preventing unauthorized servers from mounting your storage volumes. Use strong, unique passwords for every initiator-target relationship.
Access Control Lists (ACLs)
Restrict target access using IQN-based or IP-based Access Control Lists on your storage array. Configure the storage target so that only specific server IQNs are permitted to log in. This ensures that even if a machine gains access to the storage subnet, it cannot mount volumes unless its IQN is explicitly authorized.
Encryption Considerations
Standard iSCSI traffic is unencrypted. If your storage network traverses untrusted switches or physical boundaries, consider implementing IPsec to encrypt all iSCSI packets in transit, though keep in mind that software-based encryption adds CPU overhead.
Common iSCSI Mistakes to Avoid
Administrators new to block storage over Ethernet often run into a few recurring pitfalls. Avoiding these saves hours of troubleshooting.
- Mixing Storage and General Traffic: Running iSCSI over a congested corporate LAN causes high latency spikes. Always isolate storage traffic onto dedicated VLANs or physical switches.
- Ignoring Multipathing: Relying on a single network path creates a single point of failure. Always configure multiple network adapters and enable Multipath I/O (MPIO) for redundancy and load balancing.
- Neglecting Timeout Values: Default OS disk timeout values are often too short for network storage hiccups. Tune your timeout settings to prevent servers from dropping storage connections during minor network blips.
Frequently Asked Questions
What is the difference between iSCSI and NFS?
iSCSI is a block-level storage protocol that presents raw disk space to a host, allowing the host to format it with any file system it chooses. NFS (Network File System) is a file-level protocol where the storage device manages the file system and shares folders over the network. Block storage is typically required for databases and virtual machine datastores that need direct disk access.
Do I need special network cables for iSCSI?
No. iSCSI runs over standard Category 6 (Cat6) or Category 6A copper Ethernet cables, as well as fiber optic cables when using SFP+ transceivers. The cabling depends on your network switch and NIC speeds rather than the iSCSI protocol itself.
Can iSCSI run over Wi-Fi?
Technically yes, but practically no. Wireless networks suffer from packet loss, jitter, and variable latency, all of which will corrupt block-level storage sessions and cause persistent file system errors. iSCSI requires a wired, stable Ethernet connection.
How does Multipath I/O (MPIO) improve iSCSI?
MPIO creates multiple active network paths between the server initiator and the storage target. If one network cable, switch port, or interface card fails, MPIO automatically reroutes storage traffic through the remaining healthy path without dropping connections or crashing applications.
