Стадия жизненного цикла модуля: Предварительная версия (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 никогда не обращается к пакетному менеджеру узла, поэтому узел в закрытой среде без доступа к репозиториям дистрибутива настраивается так же, как любой другой, и ни один запуск bashible не ждет этих репозиториев.

На каждом обслуживаемом узле bashible скачивает из реестра модуля образ-пакет iscsi-tools, распаковывает его и запускает скрипт установки. Стек состоит из двух пар — iscsiadm с iscsid и multipath с multipathd, — и скрипт решает по каждой паре отдельно:

  • пара, которая на узле уже есть, остается узловой, а модуль только включает и настраивает юнит ее демона из дистрибутива;
  • недостающая пара размещается в /var/lib/deckhouse/sds/csi-scsi-generic, каждый ее бинарный файл запускается через собственный загрузчик со своим путем к библиотекам, а для демона поднимается юнит модуля.

Клиент и его демон всегда берутся из одного источника, поскольку iscsiadm одной версии не разговаривает с iscsid другой. Сами пары друг с другом не взаимодействуют, поэтому на узле вполне может работать узловой iscsid рядом с multipathd модуля.

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

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

На самом узле стек модуля меняет немногое. Его библиотеки никогда не добавляются в хостовые /lib64 и /usr/lib; единственные файлы вне собственного каталога — модули проверки путей multipath в /usr/lib/multipath, где их ищет multipathd, и только те, которых на узле еще нет. И он не трогает /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 это не влияет.