Модуль sds-drbd: FAQ

Когда следует использовать LVM, а когда LVMThin?

• LVM проще и обладает производительностью, сравнимой с производительностью накопителя;
• LVMThin позволяет использовать snapshot’ы и overprovisioning, но существенно медленнее.

Как получить информацию об используемом пространстве?

Есть два варианта:

• Через дашборд Grafana: перейдите Dashboards –> Storage –> LINSTOR/DRBD
  В правом верхнем углу вы найдете информацию об используемом пространстве в кластере.

  Внимание! Эта информация отражает состояние всего сырого пространства в кластере. То есть если вы создаете тома в двух репликах, то эти значения стоит поделить на два. Это нужно, чтобы получить примерное представление о том, сколько таких томов может быть размещено в вашем кластере.

• Через командный интерфейс LINSTOR:

  kubectl exec -n d8-sds-drbd deploy/linstor-controller -- linstor storage-pool list
  

  Внимание! Эта информация отражает состояние сырого пространства для каждого узла в кластере. То есть если вы создаете тома в двух репликах, то эти две реплики обязательно должны целиком поместиться на двух узлах вашего кластера.

Как назначить StorageClass по умолчанию?

В соответствующем пользовательском ресурсе DRBDStorageClass в поле spec.isDefault указать true.

Как добавить существующую LVM Volume Group или LVMThin-пул?

1. Вручную назначить на Volume Group тег storage.deckhouse.io/enabled=true:

   vgchange myvg-0 --add-tag storage.deckhouse.io/enabled=true
   

2. Данный VG будет автоматически обнаружен и в кластере для него будет создан соответствующий ресурс LVMVolumeGroup.

3. Этот ресурс можно указать в параметрах DRBDStoragePool в поле spec.lvmVolumeGroups[].name (для LVMThin-пула необходимо дополнительно указать имя в spec.lvmVolumeGroups[].thinPoolName).

Как выгнать ресурсы с узла?

• Загрузите скрипт evict.sh на хост, имеющий доступ к API Kubernetes с правами администратора (для работы скрипта потребуются установленные kubectl и jq):

  kubectl -n d8-sds-drbd cp -c sds-drbd-controller $(kubectl -n d8-sds-drbd get po -l app=sds-drbd-controller -o jsonpath='{.items[0].metadata.name}'):/tools/evict.sh ./evict.sh
  chmod 700 evict.sh
  

• Исправьте все ошибочные ресурсы LINSTOR в кластере. Чтобы найти их, выполните следующую команду:

  kubectl -n d8-sds-drbd exec -ti deploy/linstor-controller -- linstor resource list --faulty
  

• Убедитесь, что все поды в пространстве имен d8-sds-drbd находятся в состоянии Running:

  kubectl -n d8-sds-drbd get pods | grep -v Running
  

Выгнать ресурсы с узла без удаления его из LINSTOR и Kubernetes

Запустите скрипт evict.sh в интерактивном режиме, указав режим удаления --delete-resources-only:

./evict.sh --delete-resources-only

Для запуска скрипта evict.sh в неинтерактивном режиме необходимо добавить флаг --non-interactive при его вызове, а также имя узла, с которого необходимо выгнать ресурсы. В этом режиме скрипт выполнит все действия без запроса подтверждения от пользователя. Пример вызова:

./evict.sh --non-interactive --delete-resources-only --node-name "worker-1"

Важно! После завершении работы скрипта узел в Kubernetes останется в статусе SchedulingDisabled, а в LINSTOR у данного узла будет выставлен параметр AutoplaceTarget=false, что запретит планировщику LINSTOR создавать на этом узле ресурсы.

Если необходимо снова разрешить размещать ресурсы и поды на узле, нужно выполнить команды:

alias linstor='kubectl -n d8-sds-drbd exec -ti deploy/linstor-controller -- linstor'
linstor node set-property "worker-1" AutoplaceTarget
kubectl uncordon "worker-1"

Проверить параметр AutoplaceTarget у всех узлов можно так (поле AutoplaceTarget будет пустым у тех узлов, на которых разрешено размещать ресурсы LINSTOR):

alias linstor='kubectl -n d8-sds-drbd exec -ti deploy/linstor-controller -- linstor'
linstor node list -s AutoplaceTarget

Диагностика проблем

Проблемы могут возникнуть на разных уровнях работы компонентов. Эта простая шпаргалка поможет вам быстро сориентироваться при диагностике различных проблем с томами, созданными в LINSTOR:

Некоторые типичные проблемы описаны ниже.

linstor-node не может запуститься из-за невозможности загрузки drbd-модуля

Проверьте состояние подов linstor-node:

kubectl get pod -n d8-sds-drbd -l app=linstor-node

Если вы видите, что некоторые из них находятся в состоянии Init, проверьте версию drbd и логи bashible на узле:

cat /proc/drbd
journalctl -fu bashible

Наиболее вероятные причины, почему он не может загрузить модуль ядра:

• Возможно, у вас уже загружена in-tree-версия модуля DRBDv8, тогда как модуль требует DRBDv9. Проверить версию загруженного модуля: cat /proc/drbd. Если файл отсутствует, значит, модуль не загружен и проблема не в этом.

• Возможно, у вас включен Secure Boot. Так как модуль DRBD, который мы поставляем, компилируется динамически для вашего ядра (аналог dkms), он не имеет цифровой подписи. На данный момент мы не поддерживаем работу модуля DRBD в конфигурации с Secure Boot.

Под не может запуститься из-за ошибки FailedMount

Под завис на стадии ContainerCreating

Если под завис на стадии ContainerCreating, а в выводе kubectl describe pod есть ошибки следующего вида, то значит устройство все еще смонтировано на одном из других узлов:

rpc error: code = Internal desc = NodePublishVolume failed for pvc-b3e51b8a-9733-4d9a-bf34-84e0fee3168d: checking
for exclusive open failed: wrong medium type, check device health

Проверить это можно с помощью следующей команды:

alias linstor='kubectl -n d8-sds-drbd exec -ti deploy/linstor-controller -- linstor'
linstor resource list -r pvc-b3e51b8a-9733-4d9a-bf34-84e0fee3168d

Флаг InUse укажет, на каком узле используется устройство, на этом узле потребуется вручную отмонтировать диск.

Ошибки вида Input/output error

Такие ошибки обычно возникают на стадии создания файловой системы (mkfs).

Проверьте dmesg на узле, где запускается под:

dmesg | grep 'Remote failed to finish a request within'

Если вывод команды не пустой (в выводе dmesg есть строки вида “Remote failed to finish a request within …”), скорее всего, ваша дисковая подсистема слишком медленная для нормального функционирования DRBD.

Я удалил ресурс DRBDStoragePool, но соответствующий Storage Pool в бэкенде LINSTOR остался. Так и должно быть?

Да, в настоящий момент модуль sds-drbd не обрабатывает операции при удалении ресурса DRBDStoragePool.

Я не могу обновить поля в spec у ресурса DRBDStorageClass. Это ожидаемое поведение?

Да, поведение ожидаемое. В spec можно изменять только поле isDefault. Остальные поля в spec ресурса сделаны неизменяемыми.

При удалении ресурса DRBDStorageClass не удаляется его дочерний StorageClass в Kubernetes. Что делать?

Если StorageClass находится в статусе Created, то его можно удалить. Если статус другой, нужно восстановить ресурс или удалить StorageClass вручную.

При попытке создать Storage Pool / StorageClass возникла ошибка, но в итоге необходимая сущность успешно создалась. Такое допустимо?

Это поведение ожидаемо. Модуль автоматически повторит выполнение неудачной операции, если причиной ошибки послужили независящие от модуля обстоятельства (например, kube-apiserver временно стал недоступен).

При выполнении команд в CLI, LINSTOR мне выдает ошибку “You’re not allowed to change state of linstor cluster manually. Please contact tech support”. Что делать?

Операции, которые требуют ручного вмешательства в LINSTOR, в модуле sds-drbd частично или полностью автоматизированы. Поэтому модуль sds-drbd ограничивает список разрешенных команд в LINSTOR. Например, автоматизировано создание Tie-Breaker, — LINSTOR иногда их не создает для ресурсов с двумя репликами. Список разрешенных команд можно посмотреть, выполнив следующую команду:

alias linstor='kubectl -n d8-sds-drbd exec -ti deploy/linstor-controller -- linstor'
linstor --help

Я не нашел ответа на свой вопрос и испытываю проблемы с работой модуля. Что делать?

Информация о причинах неудавшейся операции должна быть отображена в поле status.reason ресурсов DRBDStoragePool и DRBDStorageClass. Если предоставленной информации не хватает для идентификации проблемы, вы можете обратиться к логам sds-drbd-controller.

Как выполнить миграцию со встроенного модуля linstor Deckhouse Kubernetes Platform на модуль sds-drbd?

В процессе миграции будет недоступен control plane LINSTOR и его CSI. Это приведет к невозможности создания/расширения/удаления PV и созданию/удалению подов, использующих PV LINSTOR, на время проведения миграции.

Важно! Миграция не затронет пользовательские данные, так как произойдет переезд в новый namespace и будут добавлены новые компоненты, которые в будущем исполнят функциональность LINSTOR по управлению томами.

Порядок действий для миграции

• Удостоверьтесь, что в кластере нет “плохих ресурсов” LINSTOR. Эта команда должна выводить пустой список:

alias linstor='kubectl -n d8-linstor exec -ti deploy/linstor-controller -- linstor'
linstor resource list --faulty

Внимание! Важно починить все ресурсы LINSTOR перед миграцией.

• Выключите модуль linstor:

kubectl patch moduleconfig linstor --type=merge -p '{"spec": {"enabled": false}}'

• Дождитесь, когда namespace d8-linstor будет удален.

kubectl get namespace d8-linstor

• Создайте ресурс ModuleConfig для sds-node-configurator.

kubectl apply -f -<<EOF
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: sds-node-configurator
spec:
  enabled: true
  version: 1
EOF

• Дождитесь, когда модуль sds-node-configurator перейдет в состояние Ready.

kubectl get moduleconfig sds-node-configurator

• Создать ресурс ModuleConfig для sds-drbd.

Внимание! Если в настройках модуля sds-drbd вы не укажете параметр settings.dataNodes.nodeSelector, то значение для этого параметра при установке модуля sds-drbd будет взято из модуля linstor. Если этот параметр не указан и там, то только в этом случае он останется пустым.

k apply -f - <<EOF
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: sds-drbd
spec:
  enabled: true
  version: 1
EOF

• Дождитесь, когда модуль sds-drbd перейдет в состояние Ready.

kubectl get moduleconfig sds-drbd

• Проверьте настройки модуля sds-drbd:

kubectl get moduleconfig sds-drbd -oyaml

• Дождитесь, пока все поды в namespace d8-sds-drbd и d8-sds-node-configurator перейдут в состояние Ready или Completed.

kubectl get po -n d8-sds-node-configurator
kubectl get po -n d8-sds-drbd

• Измените алиас к команде linstor и проверьте ресурсы LINSTOR:

alias linstor='kubectl -n d8-sds-drbd exec -ti deploy/linstor-controller -- linstor'
linstor resource list --faulty

Если “плохие” ресурсы не появились, значит миграция выполнена успешно.

Миграция на DRBDStorageClass.

StorageClass’ы в данном модуле управляются через ресурс DRBDStorageClass. Вручную StorageClass’ы создаваться не должны.

При миграции с модуля Linstor удалите старые StorageClass’ы и создайте новые через ресурс DRBDStorageClass в соответствии с таблицей.

Обратите внимание, что в старых StorageClass нужно смотреть опцию из секции parameter самого StorageClass, а указывать соответствующую опцию при создании нового необходимо в DRBDStorageClass.

Кроме них, можно использовать параметры:

• reclaimPolicy (Delete, Retain) - соответствует параметру reclaimPolicy у старого StorageClass
• zones - перечисление зон, которые нужно использовать для размещения ресурсов (прямое указание названия зон в облаке). Обратите внимание, что удаленный доступ пода к тому с данными возможен только в пределах одной зоны!
• volumeAccess может принимать значения “Local” (доступ строго в пределах узла), “EventuallyLocal” (реплика данных будет синхронизироваться на узле с запущенным подом спустя некоторое время после запуска), “PreferablyLocal” (удаленный доступ пода к тому с данными разрешен, volumeBindingMode: WaitForFirstConsumer), “Any” (удаленный доступ пода к тому с данными разрешен, volumeBindingMode: Immediate)
• При необходимости использовать volumeBindingMode: Immediate, нужно выставлять параметр DRBDStorageClass volumeAccess равным Any.

Подробнее про работу с ресурсами DRBDStorageClass можно прочитать здесь.

Миграция на DRBDStoragePool

Ресурс DRBDStoragePool позволяет создавать Storage Pool в LINSTOR. Рекомендуется создать этот ресурс даже для уже существующих в LINSTOR Storage Pool и указать в этом ресурсе существующие LVMVolumeGroup. В этом случае контроллер увидит, что соответствующие Storage Pool созданы, и оставит их без изменений, а в поле status.phase созданного ресурса будет отображено значение Created. Подробнее про работу с ресурсами LVMVolumeGroup можно прочитать в документации модуля sds-node-configurator, а с ресурсами DRBDStoragePool здесь.