Стадия жизненного цикла модуля: Предварительная версия (preview)

У модуля есть требования для установки

Как проверить работоспособность модуля?

Для этого необходимо проверить состояние подов в namespace d8-csi-scsi-generic. Все поды должны быть в состоянии Running или Completed и запущены на всех узлах.

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

Как проверить готовность узла к работе с Fibre Channel?

Убедитесь, что на узле доступны адаптеры Fibre Channel (FC HBA) и что после настройки зонирования на Storage Area Network (SAN) видны пути к LUN.

Для проверки выполните следующие команды:

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

Результаты проверки:

  • Если директория /sys/class/fc_host/ пуста, на узле отсутствуют FC HBA или не загружен драйвер для них.
  • Если в директории /dev/disk/by-path/ отсутствуют записи вида fc-*, проверьте настройки зонирования и маскирование LUN на СХД.
  • Если FC-пути отображаются, узел готов обнаруживать LUN, предоставленные через Fibre Channel.

Почему для Fibre Channel SCSITarget не создаются объекты SCSIDevice?

Если после создания SCSITarget объекты SCSIDevice не появляются, проверьте следующее:

  • значения WWPN, указанные в поле spec.fibreChannel.WWNs, соответствуют портам СХД, через которые предоставляются LUN;
  • узлы кластера имеют доступ к LUN и обнаруживают FC-пути (в директории /dev/disk/by-path/ присутствуют записи вида fc-*);
  • в секции spec SCSITarget указан только один способ подключения: iSCSI или fibreChannel.

Также проверьте логи контроллера в неймспейсе d8-csi-scsi-generic и сверьте WWPN с администратором СХД.

Что произойдет, если репозитории узла не могут предоставить open-iscsi и multipath-tools?

Модуль установит их сам, из собственного образа.

На каждом обслуживаемом узле NodeGroupConfiguration сначала просит пакетный менеджер узла установить open-iscsi и multipath-tools. Этот путь остается предпочтительным: вокруг собственного клиента и демона узла построено все остальное на этом узле, и пока они на месте, модуль в них не вмешивается.

Если установка не удалась — закрытая среда без доступа к репозиториям или дистрибутив, который этих пакетов не поставляет, — модуль разворачивает собственный образ-пакет iscsi-tools. bashible скачивает его из реестра модуля, распаковывает на узле и запускает скрипт установки. Полезная нагрузка размещается в /var/lib/deckhouse/sds/csi-scsi-generic, каждый бинарный файл запускается через собственный загрузчик со своим путем к библиотекам, а для демонов поднимаются два юнита:

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

Два пути никогда не смешиваются. Узел, у которого уже есть свой iscsiadm, сохраняет все свое, и скрипт установки там ничего не делает: клиент и демон всегда должны быть из одного источника, поскольку iscsiadm одной версии не разговаривает с iscsid другой.

Чтобы понять, какой путь выбран на узле, посмотрите, что на нем запущено:

# стек дистрибутива
systemctl is-active iscsid multipathd
# собственный стек модуля
ls /var/lib/deckhouse/sds/csi-scsi-generic/bin

Две вещи, которых откат намеренно не делает. Он ничего не добавляет в хостовые /lib64 и /usr/lib — полезная нагрузка самодостаточна. И он не трогает /etc/iscsi/initiatorname.iscsi, если файл на узле уже есть: IQN — это идентификатор узла на массиве, под ним там зарегистрирован host-объект, и узел, вернувшийся под другим именем, для массива является незнакомым.

sg3-utils запрашивается у дистрибутива, но в откате его нет: ни один путь исполнения драйвера не вызывает его утилиты.

Сколько места тома резервируется под суперпользователя?

По умолчанию — нисколько: модуль форматирует ext4 с -m 0, весь объём тома доступен нагрузке.

Если классический 5-процентный резерв ext4 всё же нужен — например, чтобы привилегированный процесс мог писать в файловую систему после того, как нагрузка заняла её целиком, — задайте процент аннотацией на ресурсе SCSIStorageClass:

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

Значение — целое число процентов от 0 до 50; при некорректном значении SCSIStorageClass переходит в фазу Failed с причиной в status.reason, а не ломает создание томов позже.

Резерв применяется только к томам, созданным после установки аннотации: уже существующие файловые системы сохраняют тот резерв, с которым были созданы. Блоки для суперпользователя резервируют только файловые системы семейства ext, поэтому при fsType: xfs аннотация игнорируется, а узел пишет предупреждение в лог.

Изменение аннотации приводит к пересозданию StorageClass контроллером, поскольку поле parameters у существующего StorageClass в Kubernetes иммутабельно. На уже созданные тома и PVC это не влияет.