Стадия жизненного цикла модуля: Общедоступная версия

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

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

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

d8 k -n d8-csi-huawei get pod -owide -w

Какие СХД поддерживаются?

  • OceanStor V5 (V500R007, V500R007 Kunpeng)
  • OceanStor (6.1.x / V700R001C00 / V700R001C10)
  • OceanStor Dorado
  • OceanStor A series / A Series
  • OceanStor Pacific series
  • FusionStorage block
  • OceanDisk 1500T (NAS)
  • OceanDisk 1500/1600 series

Как я могу использовать одну физическую СХД для разных кластеров независимо?

В СХД Huawei есть такое понятие, как vStore. Это виртуальная СХД — по сути хранилище в хранилище.

Не поддерживается использование двух vStore в одном и том же кластере. Ограничение связано с маппингом хостов к vStore — у разных vStore не может быть хостов с одинаковыми именами, а также одинаковых iSCSI-инициаторов.

В качестве примера рассмотрим настройку СХД для двух кластеров, в каждом из которых развёрнут модуль csi-huawei.

Настройка СХД

Создание vStore

  1. Войдите в СХД под суперадмином, который был создан на этапе инициализации СХД.

  2. Перейдите в пункт меню (сверху) Services - vStores.

  3. Нажмите кнопку Create и заполните форму:

    Где:

    • Name — имя vStore (например, vStore_2);
    • Associate with Storage Pool — возможность привязать vStore к конкретным Storage Pool. В этом случае vStore сможет использовать только их;
    • Associate with FC Port — возможность привязать vStore к конкретным физическим портам FibreChannel.

    Нажмите кнопку ОК — vStore создан.

  4. Создайте пользователя для управления vStore.

    В списке vStore выберите нужный vStore одиночным щелчком, в открывшемся окне перейдите на вкладку User management и нажмите кнопку Create:

    Заполните форму:

    Где:

    • Username — имя пользователя, например, admin_2;
    • Password и Confirm Password — пароль пользователя;
    • Role — выберите vStore Administrator (пользователю нужны права на управление ресурсами vStore).

    Нажмите кнопку ОК — пользователь создан.

  5. Создайте management-порт для vStore.

    Чтобы к vStore можно было подключаться, ему необходим собственный порт для управления. Системные management-порты не используются для входа администраторов vStore.

    Перейдите в Services - Logical ports, нажмите кнопку Create и заполните форму:

    Где:

    • Name — название порта, например data-management-port-2;
    • Role — management или service+management. В первом случае это будет порт только для control plane и потребуется создать ещё один логический порт для data plane; во втором — порт и для управления, и для данных;
    • Owning vStore — имя vStore, созданного выше;
    • IP address, subnet mask, gateway — сетевые настройки порта;
    • Port type — Ethernet port/Bond/VLAN;
    • Home port — физический порт СХД, который будет использоваться для управления vStore (или и для данных тоже).

    Нажмите кнопку ОК — порт создан, можно подключаться к консоли управления vStore.

  6. Подключитесь к консоли управления vStore.

    Откройте в браузере адрес https://[IP-адрес логического порта]:8088 (например: https://10.220.0.101:8088). Введите логин и пароль пользователя. СХД предложит сменить пароль — задайте новый постоянный пароль, который будет использоваться для последующих подключений.

СХД настроена.

Аналогичным образом создайте второй vStore — с другим названием, пользователем и логическим портом для управления.

Подключение к СХД из кластера

Разверните модуль csi-huawei в кластере (подробную информацию можно прочитать в руководстве по настройке csi-huawei).

Создайте HuaweiStorageConnection, например такой:

apiVersion: storage.deckhouse.io/v1alpha1
kind: HuaweiStorageConnection
metadata:
  name: hsconn-220
spec:
  storageType: OceanStorSAN
  pools:
    - prod # Имя StoragePool
  urls:
    - https://10.220.0.101:8088 # IP-адрес логического порта
  login: "admin_2" # Логин администратора vStore
  password: '<your-password>' # Его пароль
  protocol: ISCSI
  portals:
    - 10.220.0.101 # Data-plane address
  maxClientThreads: 30

Далее создайте HuaweiStorageClass, после чего уже можно создавать поды и PVC, используя имя StorageClass, который вы создали.

Что делать, если том не монтируется из-за ошибок файловой системы?

Перед монтированием уже отформатированного тома драйвер проверяет файловую систему командой e2fsck -p. Если проверка нашла ошибки, которые не может исправить самостоятельно, том не монтируется, а в событиях пода появляется ошибка вида:

device /dev/dm-11 carries filesystem errors that e2fsck could not correct on its own, exit code: 4

Это означает, что файловая система была повреждена раньше — как правило, когда блочное устройство пропало из-под смонтированной файловой системы: потеря путей SAN, переключение контроллера СХД, отключение питания. Ошибки, которые e2fsck исправляет сам (например, незавершённый журнал), устраняются автоматически, и том монтируется.

Проверка не выполняется для файловых систем xfs и для томов с режимами доступа ReadWriteMany и ReadOnlyMany.

Чтобы восстановить такой том, файловую систему нужно проверить в размонтированном виде. Драйвер отключает LUN от узла, когда останавливается последний использующий его под, поэтому нужен под-держатель, который удерживает том подключённым:

Перед восстановлением сделайте снимок тома на СХД: e2fsck может перенести повреждённые данные в lost+found.

  1. Остановите нагрузку:

    d8 k -n <namespace> scale deploy/<app> --replicas=0

  2. Запустите под-держатель на узле, к которому есть доступ по SSH. Параметр mountPropagation: HostToContainer обязателен: без него контейнер сохранит собственную копию монтирования и файловая система останется смонтированной внутри него.

    apiVersion: v1
kind: Pod
metadata:
  name: fsck-holder
  namespace: <namespace>
spec:
  nodeName: <worker-node>
  terminationGracePeriodSeconds: 1
  containers:
    - name: holder
      image: <образ с sleep>
      command: ["sleep", "infinity"]
      volumeMounts:
        - name: data
          mountPath: /data
          mountPropagation: HostToContainer
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: <pvc>

  3. На узле найдите оба монтирования тома и сохраните опции монтирования globalmount:

    findmnt -rn -o TARGET,SOURCE,FSTYPE,OPTIONS | grep -F "<pv-name>"

  4. Размонтируйте их и убедитесь, что устройство никем не занято (вывод последней команды должен быть пустым):

    umount /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount
umount /var/lib/kubelet/plugins/kubernetes.io/csi/csi.huawei.com/<hash>/globalmount
grep -H " $(lsblk -no MAJ:MIN /dev/dm-11 | tr -d ' ') " /proc/*/mountinfo

  5. Проверьте и исправьте файловую систему. Сообщение Device or resource busy означает, что она где-то ещё смонтирована — вернитесь к предыдущему шагу:

    e2fsck -fy /dev/dm-11
dumpe2fs -h /dev/dm-11 | grep -iE 'state|error'

  6. Верните монтирование globalmount с теми же опциями, удалите под-держатель и запустите нагрузку:

    mount -t ext4 -o <сохранённые опции> /dev/dm-11 /var/lib/kubelet/plugins/kubernetes.io/csi/csi.huawei.com/<hash>/globalmount
d8 k -n <namespace> delete pod fsck-holder
d8 k -n <namespace> scale deploy/<app> --replicas=<N>

После восстановления проверьте каталог lost+found на томе и целостность данных средствами самого приложения: e2fsck восстанавливает метаданные файловой системы, но не содержимое файлов.

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

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

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

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

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

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

Узловой плагин вызывает хостовый iscsiadm по имени, через nsenter, поэтому имя разрешается по PATH контейнера, но уже в mount namespace хоста. Если iscsiadm взят из модуля, скрипт кладет для этого обертку в /usr/local/sbin/iscsiadm, и эта обертка уступает дистрибутивному iscsiadm, едва тот появится.

А multipathd из пакета читает конфигурацию по префиксу, с которым он собран, а не по /etc. Если multipathd взят из модуля, скрипт связывает multipath.conf и multipath из этого префикса с теми, что на узле, — чтобы настройки deferred_remove/flush_on_last_del из NodeGroupConfiguration и wwid’ы, которые записывает узловой плагин, попадали к одному и тому же демону. Сами эти настройки NodeGroupConfiguration записывает, какой бы multipathd ни работал на узле.

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

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

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

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

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

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

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

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

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

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

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