Модуль csi-hpe: FAQ

Какие требования предъявляются к модулю csi-hpe?

Модуль csi-hpe требует:

• Наличие развернутой и настроенной СХД HPE.
• Уникальные iqn в /etc/iscsi/initiatorname.iscsi на каждой из Kubernetes Nodes
• Модуль snapshot-controller должен быть включен в кластере (требуется для функциональности снапшотов томов).

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

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

kubectl -n d8-csi-hpe get pod -owide -w

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

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

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

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

Значение — целое число процентов от 0 до 50; при некорректном значении HPEStorageClass остаётся с Ready=False и причиной в статусе, а не ломает создание томов позже.

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

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

Откуда на узле берутся open-iscsi и multipath-tools?

Их ставит сам модуль. NodeGroupConfiguration никогда не обращается к пакетному менеджеру узла, поэтому узел в закрытой среде без доступа к репозиториям дистрибутива настраивается так же, как любой другой, и ни один запуск bashible не ждет этих репозиториев.

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

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

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

Для пар модуля скрипт установки делает две вещи, о которых стоит знать: обе незаметны до того момента, когда том перестает монтироваться.

Драйвер обращается к хостовому iscsiadm через контейнерный /bin/iscsiadm — это встроенный бинарный файл host-iscsiadm: он делает chroot в /host и ищет клиента уже там, по собственному PATH. Если iscsiadm взят из модуля, скрипт кладет обертку в /usr/local/sbin/iscsiadm, который этот PATH просматривает раньше дистрибутивных каталогов, и обертка уступает дистрибутивному iscsiadm, едва тот появится.

А multipathd из пакета читает конфигурацию по префиксу, с которым он собран, а не по /etc. Если multipathd взят из модуля, скрипт связывает multipath.conf и multipath из этого префикса с теми, что на узле. Здесь это важнее, чем где-либо: драйвер находит застейдженный LUN исключительно по его карте device-mapper, поэтому find_multipaths no, который модуль пишет в /etc/multipath/conf.d на каждом узле, какой бы multipathd там ни работал, и есть разница между работающим подключением и ошибкой device not found with serial <wwn>.

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

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

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

sg3-utils не устанавливается вовсе, и ничего от этого не теряется: единственным обращением драйвера к нему был rescan-scsi-bus.sh, и патчи модуля заменили его прямыми записями в sysfs.