Диагностика дисковой подсистемы

На этой странице описаны типовые проблемы дисковой подсистемы Stackland и способы их устранения.

Диагностика состоянияДиагностика состояния

Проверьте состояние Volume Groups на всех узлах:

kubectl get volumegroups -A -o wide

Проверьте условия синхронизации:

kubectl get volumegroups -A -o custom-columns="NAME:.metadata.name,NODE:.spec.nodeName,REASON:.status.conditions[0].reason,STATUS:.status.conditions[0].status"

Для детальной диагностики подключитесь к поду topovgm-operator на нужном узле. В поде доступны все утилиты LVM:

kubectl -n stackland-volumes exec -it <имя_пода_topovgm> -- sh

Внутри пода выполните команды LVM:

pvs   # список физических томов
vgs   # список Volume Groups
lvs   # список логических томов

Типовые проблемыТиповые проблемы

В разделе перечислены типовые проблемы дисковой подсистемы и меры для их исправления.

VolumeGroupSyncedOnNode = FalseVolumeGroupSyncedOnNode = False

Условие VolumeGroupSyncedOnNode в статусе ресурса VolumeGroup имеет значение False.

• Диск отсутствует или недоступен. Проверьте физическое подключение диска. Выполните pvs в поде topovgm-operator и убедитесь, что все физические тома видны.

• Ошибка инициализации Volume Group. Проверьте логи оператора:

  kubectl -n stackland-volumes logs -l app.kubernetes.io/name=topovgm-operator --tail=100
  

• Диск содержит данные и не прошел автоматическое обнаружение. Проверьте поле status.discoveredDevices ресурса VolumeGroup — там указана причина исключения диска.

PhantomDeviceDetectedPhantomDeviceDetected

На узле установлено условие PhantomDeviceDetected. Это означает, что диск, ранее входивший в Volume Group, временно недоступен, но его метаданные сохранились в LVM.

1. Проверьте физическое подключение диска.
2. Если диск переподключен, оператор автоматически обновит таблицы device-mapper и восстановит Volume Group.
3. Если диск заменен, следуйте процедуре замены поврежденного диска.

PVC зависает в состоянии PendingPVC зависает в состоянии Pending

PersistentVolumeClaim долго находится в состоянии Pending.

• Недостаточно свободного места в Volume Group нужного типа. Проверьте свободное место:

  kubectl get volumegroups -A -o custom-columns="NAME:.metadata.name,NODE:.spec.nodeName,FREE:.status.free,SIZE:.status.size"
  

• Указан несуществующий Storage Class. Проверьте имя Storage Class в манифесте PVC. Допустимые значения: stackland-nvme, stackland-ssd, stackland-hdd, stackland-other.

• На узлах нет дисков нужного типа. Например, если указан stackland-nvme, но NVMe-дисков нет, Volume Group для этого типа не создается.

Ошибки I/O на дискеОшибки I/O на диске

В мониторинге оборудования срабатывает алерт DiskIOErrors. Приложения сообщают об ошибках записи или чтения.

1. Определите проблемный диск по дашборду Hardware Monitoring в Grafana.
2. Если по данным SMART-мониторинга диск неисправен, следуйте процедуре замены поврежденного диска.

Замена поврежденного дискаЗамена поврежденного диска

Шаг 1. Определите поврежденный дискШаг 1. Определите поврежденный диск

Найдите Volume Group с проблемным диском:

kubectl get volumegroups -A -o wide

Получите детальный статус Volume Group:

kubectl describe volumegroup <имя_vg> -n stackland-volumes

В поле status.physicalVolumes найдите диск с атрибутом attributes, содержащим признак отсутствия (m — missing).

Подключитесь к поду topovgm-operator на нужном узле и проверьте состояние физических томов:

kubectl -n stackland-volumes exec -it <имя_пода_topovgm> -- pvs

Шаг 2. Перенесите данные с диска (если возможно)Шаг 2. Перенесите данные с диска (если возможно)

Если диск еще доступен и на нем есть данные, перенесите их на другие диски Volume Group:

kubectl -n stackland-volumes exec -it <имя_пода_topovgm> -- pvmove /dev/<имя_диска>

Если диск полностью недоступен, пропустите этот шаг.

Шаг 3. Удалите диск из Volume GroupШаг 3. Удалите диск из Volume Group

Если диск недоступен, установите политику удаления в ресурсе VolumeGroup. Для удаления без данных:

kubectl patch volumegroup <имя_vg> -n stackland-volumes --type=merge \
  -p '{"spec":{"deviceLossSynchronizationPolicy":"Remove"}}'

Оператор автоматически выполнит vgreduce --removemissing и удалит отсутствующий физический том из Volume Group.

После завершения верните политику в исходное значение:

kubectl patch volumegroup <имя_vg> -n stackland-volumes --type=merge \
  -p '{"spec":{"deviceLossSynchronizationPolicy":"Fail"}}'

Шаг 4. Замените физический дискШаг 4. Замените физический диск

Выполните физическую замену диска на сервере согласно документации производителя оборудования.

Шаг 5. Убедитесь, что новый диск обнаруженШаг 5. Убедитесь, что новый диск обнаружен

После замены диска оператор topovgm-operator автоматически обнаружит новый диск при следующем цикле согласования.

Если используется автоматический режим обнаружения (physicalVolumeSelector не задан), новый диск будет добавлен в Volume Group автоматически.

Если используется явный селектор (physicalVolumeSelector с конкретными путями), обновите ресурс VolumeGroup, указав путь к новому диску:

kubectl edit volumegroup <имя_vg> -n stackland-volumes

Шаг 6. Проверьте восстановлениеШаг 6. Проверьте восстановление

Убедитесь, что Volume Group синхронизирована:

kubectl get volumegroup <имя_vg> -n stackland-volumes -o jsonpath='{.status.conditions[0]}'

Условие VolumeGroupSyncedOnNode должно принять значение True.

Проверьте состояние Volume Group в LVM:

kubectl -n stackland-volumes exec -it <имя_пода_topovgm> -- vgs