The module lifecycle stage: Preview

The module has requirements for installation

How to check module health?

To do this, you need to check the status of the pods in the d8-csi-scsi-generic namespace. All pods should be in the Running or Completed state and should be running on all nodes.

kubectl -n d8-csi-scsi-generic get pod -owide -w

How to verify Fibre Channel prerequisites on a node?

Check that Fibre Channel adapters (FC HBA) are available on the node and that LUN paths are visible after Storage Area Network (SAN) zoning:

To verify that, run the following commands:

ls /sys/class/fc_host/
ls -l /dev/disk/by-path/ | grep -E 'fc-|/fc-'

Possible results:

  • If the /sys/class/fc_host/ directory is empty, the node has no FC HBA or the corresponding driver is not loaded.
  • If there are no fc-* entries in the /dev/disk/by-path/ directory, check zoning and LUN masking settings on the storage system.
  • If the FC paths are displayed, the node is ready to detect LUN provided via Fibre Channel.

Why are no SCSIDevice objects created for an Fibre Channel SCSITarget?

If no SCSIDevice objects are present after a SCSITarget is created, check the following:

  • WWPN values set in the spec.fibreChannel.WWNs field match the storage system ports.
  • Cluster nodes have access to LUNs and can detect FC paths (there are fc-* entries in the /dev/disk/by-path/ directory).
  • Only one connection type is specified under spec in the SCSITarget: iSCSI or fibreChannel.

Also inspect controller logs in the d8-csi-scsi-generic namespace and verify the target WWPN with your storage administrator.

What happens if a node’s repositories cannot provide open-iscsi and multipath-tools?

The module installs them itself, from an image of its own.

On every node it serves, the NodeGroupConfiguration first asks the node’s package manager for open-iscsi and multipath-tools. That stays the preferred path: a host’s own client and daemon are what the rest of that host is built around, and nothing about them is the module’s business while they are there.

When the install fails — a closed environment with no route to the repositories, or a distribution that does not ship the packages — the module falls back to its own package image, iscsi-tools. bashible pulls it from the module’s registry, unpacks it on the node and runs its install script. The payload lands under /var/lib/deckhouse/sds/csi-scsi-generic, every binary is started through its own dynamic loader with its own library path, and two units come up for the daemons:

systemctl is-active d8-csi-scsi-generic-iscsid.service d8-csi-scsi-generic-multipathd.service

The two paths never mix. A host that already has iscsiadm of its own keeps everything of its own, and the install script does nothing there: the client and the daemon must always come from the same source, because iscsiadm of one version does not speak to iscsid of another.

To tell which path a node took, look at what is running on it:

# the distribution's stack
systemctl is-active iscsid multipathd
# the module's own
ls /var/lib/deckhouse/sds/csi-scsi-generic/bin

Two things the fallback deliberately does not change. It never merges anything into the host’s /lib64 or /usr/lib — the payload is self-contained. And it does not touch /etc/iscsi/initiatorname.iscsi when the node already has one: the IQN is the node’s identity on the array, registered there in a host object, and a node that comes back under a different name is a node the array has never heard of.

sg3-utils is asked of the distribution but is not in the fallback: no code path in the driver invokes its tools.

How much of a volume is reserved for the superuser?

Nothing, by default: the module formats ext4 with -m 0, so the whole volume is available to the workload.

Where the classic 5% ext4 reserve is wanted — for example to keep a filesystem writable for a privileged process after a workload has filled it — annotate the SCSIStorageClass with the percentage to reserve:

d8 k annotate scsistorageclass <name> storage.deckhouse.io/ext4-reserved-percent=5

The value is a whole number of percent between 0 and 50; an invalid one puts the SCSIStorageClass into the Failed phase with the reason in status.reason, instead of breaking volume creation later.

The reserve applies only to volumes created after the annotation was set — filesystems that already exist keep the reserve they were created with. Only the ext filesystems keep blocks for the superuser, so with fsType: xfs the annotation is ignored and the node logs a warning.

Changing the annotation makes the controller recreate the StorageClass, because parameters of an existing StorageClass are immutable in Kubernetes. Existing volumes and PVCs are not affected.