iSCSI Target and Initiator Setup for Block Storage

We integrate iSCSI target and initiator for block storage — from a simple LUN to fault-tolerant multipath with CHAP and jumbo frames. Our certified engineers with 10+ years of experience ensure compatibility with VMware, Hyper-V, cluster filesystems, and databases. Infrastructure savings: iSCSI on existing Ethernet costs 3-5 times less than Fibre Channel, and with optimization delivers up to 200,000 IOPS. Over 150 projects, we've accumulated best practices for any scenario.

Why iSCSI, not NFS?

NFS works at the file level, adding overhead and lock management. iSCSI transmits SCSI block commands over TCP/IP, presenting a RAW disk to the client. This is critical for databases (PostgreSQL, MySQL), cluster filesystems (GFS2, OCFS2), and virtualization (KVM, Hyper-V). According to RFC 7143, iSCSI provides block-level access with minimal latency. In fio tests, iSCSI on SSD arrays shows 2-3 times higher random write IOPS than NFS on the same network.

Common problems iSCSI solves

First — high latency when using databases over NFS. Second — need for direct block access for cluster filesystems (GFS2, OCFS2) or databases with their own cache management. Third — budget constraints: Fibre Channel is expensive (typical setup $10,000-$50,000), while iSCSI works over existing Ethernet and costs $500-$2,000 for configuration. Fourth — migration from physical servers to virtualization: iSCSI allows attaching block volumes to guest OS without additional software.

How to set up an iSCSI target on Linux with targetcli

Install targetcli: apt install targetcli-fb. Create block storage and target:

1. Create backstores: backstores/block create name=lun-db dev=/dev/sdb and backstores/block create name=lun-app dev=/dev/sdc
2. Create target: iscsi/ create iqn.2024-01.com.example:storage01
3. Assign LUNs: iscsi/iqn.2024-01.com.example:storage01/tpg1/luns create /backstores/block/lun-db and iscsi/iqn.2024-01.com.example:storage01/tpg1/luns create /backstores/block/lun-app
4. Configure ACLs: iscsi/iqn.2024-01.com.example:storage01/tpg1/acls create iqn.2024-01.com.example:dbserver01 and iscsi/iqn.2024-01.com.example:storage01/tpg1/acls create iqn.2024-01.com.example:appserver01
5. Set portal IP: iscsi/iqn.2024-01.com.example:storage01/tpg1/portals delete ip_address=0.0.0.0 ip_port=3260 then iscsi/iqn.2024-01.com.example:storage01/tpg1/portals create 192.168.20.10 3260
6. Save: saveconfig

Dedicate iSCSI to a separate VLAN so storage traffic doesn't compete with application traffic. Auto-start: systemctl enable --now rtslib-fb-targetctl. For repeatable deployments we use Ansible — configuration is versioned in Git and reproduced in minutes.

How to secure iSCSI with CHAP

Without CHAP, any initiator with the correct IQN gets access. Configure mutual authentication:

/> iscsi/iqn.2024-01.com.example:storage01/tpg1 set attribute authentication=1
/> iscsi/iqn.2024-01.com.example:storage01/tpg1/acls/iqn.2024-01.com.example:dbserver01/ set auth userid=dbserver01
/> iscsi/iqn.2024-01.com.example:storage01/tpg1/acls/iqn.2024-01.com.example:dbserver01/ set auth password=strong-password-16+chars
/> saveconfig

The password must be at least 16 characters — this prevents brute force.

How to configure the iSCSI initiator

On the client server:

apt install open-iscsi
# set IQN in /etc/iscsi/initiatorname.iscsi:
InitiatorName=iqn.2024-01.com.example:dbserver01
# CHAP in /etc/iscsi/iscsid.conf:
node.session.auth.authmethod = CHAP
node.session.auth.username = dbserver01
node.session.auth.password = strong-password-16+chars
# discovery and login:
iscsiadm -m discovery -t sendtargets -p 192.168.20.10:3260
iscsiadm -m node -T iqn.2024-01.com.example:storage01 -p 192.168.20.10:3260 --login
# autoconnect:
iscsiadm -m node -T iqn.2024-01.com.example:storage01 -p 192.168.20.10:3260 --op update -n node.startup -v automatic
systemctl enable iscsid open-iscsi

After connection, check session: iscsiadm -m session -P3 and see the new disk in lsblk.

How to configure multipath for failover

If the target is accessible via two network interfaces, configure multipath for automatic failover:

apt install multipath-tools
# /etc/multipath.conf:
defaults {
  user_friendly_names yes
  path_grouping_policy failover
  failback immediate
  no_path_retry 5
}
blacklist {
  devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
}
multipaths {
  multipath {
    wwid 360000000000000001
    alias db-storage
  }
}
systemctl enable --now multipathd
multipath -ll

After configuration, work with /dev/mapper/db-storage — when one path fails, multipath switches to another with failover time under 1 second.

How to optimize iSCSI performance

To unlock the potential of SSD arrays, enable jumbo frames (MTU 9000) on the storage VLAN. Session parameters increase queue depth:

ip link set eth1 mtu 9000
# in /etc/iscsi/iscsid.conf:
node.session.cmds_max = 1024
node.session.queue_depth = 128
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5

These settings boost throughput by up to 40% on large blocks. With proper configuration, iSCSI achieves latency <1 ms, comparable to Fibre Channel. Additionally, iSCSI Direct Connect can be used for isolated environments.

Common iSCSI target and initiator setup mistakes

• Using MTU 1500 without jumbo frames on the storage VLAN — IOPS drop 20-30%.
• Lack of CHAP — risk of unauthorized access.
• Single network path without multipath — single point of failure.
• Too short CHAP passwords (<16 characters) — easily brute-forced.
• Incorrect disk configuration on target (write-back vs write-through) — for critical data only write-through.

When to choose iSCSI over Fibre Channel?

Fibre Channel offers minimal latency and isolation but requires expensive equipment. Properly configured iSCSI on 10GbE approaches its performance (80% of FC IOPS) while costing 3-5 times less ($1,000 vs $5,000 for comparable performance). If your infrastructure already has Ethernet switches with jumbo frames and non-volatile queues, iSCSI is a cost-effective solution. For environments with critical latency (<0.5 ms), Fibre Channel remains better, but for most tasks iSCSI is sufficient.

What's included in iSCSI target and initiator setup

Approximate timeline: from 1 day (basic configuration) to 4 days (with cluster). Cost is determined after audit. Contact us — we will assess your infrastructure and propose the optimal configuration. Guaranteed: all settings are covered by documentation, configurations are reproducible via Ansible (on request). Order an iSCSI infrastructure audit — get a detailed migration plan and performance estimate.