iSCSI support (considerations)

Edit online

Be aware of the following general iSCSI support considerations.

The general iSCSI parameters are applicable regardless of the operating system.

  • The system supports:
    • The standard iSCSI port (3260)
    • For more information on hosts per I/O group and sessions per I/O group, see Configuration limits.
    • I/O from Fibre Channel and iSCSI initiators in different hosts to the same volumes.
      Note: The system does not support I/O from Fibre Channel and iSCSI initiators in the same hosts to the same volumes.
    • Multiple sessions from iSCSI hosts, with a maximum of four sessions from one iSCSI host to each system iSCSI target.
    • Unidirectional (one-way) CHAP authentication, where you can specify an authentication username with a maximum of 255 characters, or you can use the initiator's IQN as the username .
    • Bidirectional (two-way) authentication with initiators that use the storage_username and storage_secret for username and password fields.
    • CHAP algorithms MD5, SHA1, SHA2, and SHA3-256 for unidirectional (one-way) and bidirectional (two-way) CHAP authentication.
    • Only SHA3-256 and SHA256 hashing algorithms are supported when iSCSI host authentication mode is enabled.
    • A large number of sessions per host can cause multiple issues such as iscsid soft lockup or OOM Killer on the host side. To avoid these issues, it is recommended to have a maximum 512 sessions per host.
  • iSCSI uses either iSCSI qualified name (IQN) (223 bytes) or extended unique identifier (EUI) (64-bit) names.
    Note: Ensure that the IP takeover facility in an I/O group is enabled. Then, if the node that is acting as the iSCSI target fails, the partner node takes over the IP addresses of the failed node, thus continuing operations. During takeover, the iSCSI initiator is logged out from the failed node. A new session or login is reestablished with the partner (working) node that uses the IP address of the failed node.
  • Each iSCSI target can support both IPv4 and IPv6 concurrently.
  • Host operating systems such as Linux® that have many Ethernet interfaces are subject to an Address Resolution Protocol (ARP) Flux problem. This problem might occur when a host replies to ARP requests for interfaces on the same or different subnet from any interface on that same or different subnet. Usually, this behavior is not a problem. However, in specific cases, ARP Flux generates unexpected behavior of applications due to an incorrect mapping between IPv4 addresses and MAC addresses.
    To avoid ARP Flux on Linux, use the following setting on the host:
    echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

    To make this behavior persistent, add a net.ipv4.conf.all.arp_filter=1 entry in /etc/sysctl.conf.

    If you use other operating systems such as VMware ESX, check your settings to avoid ARP Flux on those hosts as well.

  • Volumes are mapped to a host that uses the same host mapping mechanism as Fibre Channel attachment. A volume can be mapped to a Fibre Channel host or an iSCSI host. Mapping a volume through both iSCSI and Fibre Channel to the same host is not supported.
  • All IP addresses (service and configuration) associated with a clustered-system Ethernet port must be on the same subnet. However, IP addresses associated with a node Ethernet port that is used for iSCSI traffic can be configured to belong to different subnets.
  • A host can discover and login to only those IP addresses that are mapped to it via portsets.
  • For a host to login to 'n' nodes of SVC, it must be mapped to a portset that contains IP addresses from all 'n' nodes.
  • Unconfigured logins will now be rejected.
  • A host that is associated with portset x, if tries to discover through portset y, discovery succeeds and will give IP addresses associated with portset x.
  • Modifying IP addresses mapped to a portset results in login disruptions from hosts mapped to that portset.
  • Enter the following command to disable iWARP Port Mapper (iwpmd) service on RHEL 7.5 and higher host machine:
    $ systemctl stop iwpmd
    Note: With the IBM Storage Virtualize software, the iWARP Port Mapper (iwpmd) service results in host system hang or restart.