iSCSI support

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)
  • A maximum of 512 hosts per I/O group for all supported node types.
  • Up to 1024 sessions per system iSCSI target from different iSCSI hosts. A maximum of 2048 sessions per I/O group from iSCSI hosts with up to four sessions from one iSCSI host to each system iSCSI target.
  • 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.
  • One-way CHAP authentication, where you can specify an authentication user name with a maximum of 31 ASCII characters, or you can use the initiator's IQN as the user name.
  • BI-CHAP authentication with initiators that accept a blank user name field.
  • 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 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. In most cases, 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.
• In order 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 which is associated with portset x, if tries to discover through portset y, discovery will succeed and will give IP addresses associated with portset x.
• Modifying IP addresses mapped to a portset will result 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 Spectrum Virtualize storage software, the iWARP Port Mapper (iwpmd) service results in host system hang or reboot.