Когда кластер виртуализации выглядит сломанным, но проблема не в storage

Обезличенный кейс диагностики zVirt/oVirt HCI: как отделить storage failure от проблемы host identity, DNS/NSS и management-plane.

Коротко

В авариях виртуализации самое опасное - принять симптом в панели управления за точную причину. Хост NonResponsive в UI не всегда означает, что storage умер, quorum потерян или ноду надо срочно перезагрузить.

В одном обезличенном рабочем кейсе HCI-кластер на zVirt/oVirt после физического переезда выглядел деградированным: часть хостов была в состояниях NonResponsive и Connecting, при этом часть ВМ продолжала работать, а Hosted Engine был жив. Быстрая реакция “перезагрузим проблемную ноду” могла создать дополнительный риск, потому что сначала нужно было понять, где сейчас Hosted Engine, что со storage и не сломан ли Gluster.

Итог оказался не в Gluster. Ключевая проблема была на уровне host identity: статические записи FQDN в /etc/hosts оказались потеряны, а nsswitch.conf с myhostname возвращал self-FQDN хоста как fe80::... link-local IPv6 вместо management IPv4. Отдельная вероятная причина потери записей - обновление zVirt на новый релиз, после которого локальные host records на нодах могли быть перезаписаны или сброшены. После восстановления корректного резолва хосты вернулись в Up, storage остался целым.

Исходная проблема

Типовая картина для такой аварии:

панель управления показывает один или несколько хостов как NonResponsive / Connecting;
Hosted Engine доступен, но не всегда очевидно, на какой ноде он сейчас запущен;
management IP между нодами пингуется;
storage-сервисы и ВМ могут быть живы;
в логах VDSM/libvirt видны TLS/SSL handshake errors;
есть соблазн нажать force-действия в UI или перезагрузить “плохой” хост.

Именно здесь важно остановиться. В HCI-кластере одна нода может одновременно быть частью storage, compute и площадкой для Hosted Engine. Ошибка порядка действий способна превратить управляемую деградацию в полноценную аварию.

Почему это важно

Для бизнеса или production-инфраструктуры проблема не только в том, что “кластер красный”. Риск в другом:

Можно перезагрузить ноду, на которой сейчас работает управляющая ВМ.
Можно запустить лишний recovery storage, хотя Gluster уже в порядке.
Можно принять TLS/SSL errors за проблему сертификатов, хотя первопричина в резолве имени.
Можно потерять время на опасные гипотезы, не проверив простую вещь: во что хост резолвит собственный FQDN.

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

Что нужно получить

Минимальная цель диагностики в такой ситуации:

Понять, где сейчас Hosted Engine и жив ли он.
Проверить, что Gluster peers подключены, bricks online, heal pending и split-brain равны нулю.
Проверить management и storage-сети отдельно.
Проверить, что FQDN хостов резолвятся в ожидаемые адреса, а не в случайный или link-local адрес.
После каждого изменения перечитывать состояние, а не продолжать по старому предположению.

Практическое решение

1. Сначала Hosted Engine

Перед любыми действиями нужно понять, где управляющая ВМ находится сейчас:

hosted-engine --vm-status
hosted-engine --check-liveliness

Ожидаемый минимум:

ровно одна нода показывает, что Engine VM up и health good;
hosted-engine --check-liveliness подтверждает, что Engine жив;
нет global maintenance, если вы ее специально не включали.

Правило простое: ноду с текущим Hosted Engine не трогать первой. Даже если раньше Engine был на другой ноде, перед каждым сервисным действием проверять статус заново.

2. Потом storage и Gluster

Не надо лечить Gluster, пока не доказано, что он болен. В HCI-кластере сначала нужны read-only проверки:

gluster peer status
gluster volume status
gluster volume heal <volume> info summary
gluster volume heal <volume> info split-brain

Признаки, что проблема не похожа на storage disaster:

peers Connected;
bricks online;
active volume tasks отсутствуют;
heal pending 0;
split-brain 0.

Если эти признаки чистые, опасные действия вроде gluster volume heal ... full, force remove storage или массовых рестартов storage-сервисов не должны быть первым шагом.

3. Проверить management, storage и host identity

Следующий слой - сеть и имена. Проверки выглядят банально, но именно они часто экономят часы:

hostname -f
ip -br addr
ip route
getent hosts $(hostname -f)
getent ahostsv4 $(hostname -f)
getent ahostsv6 $(hostname -f)
grep '^hosts:' /etc/nsswitch.conf
cat /etc/hosts

В разобранном кейсе перед этим обнаружилась важная деталь: на нодах были потеряны локальные записи FQDN в /etc/hosts. Это не главный публичный тезис, но полезная инженерная оговорка: такие записи могли быть затёрты при обновлении zVirt на новый релиз, поэтому после upgrade стоит отдельно сверять host identity baseline.

Критичный симптом был таким:

getent hosts $(hostname -f) -> fe80::... <fqdn>
getent ahostsv4 $(hostname -f) -> 192.0.2.10 <fqdn>

То есть IPv4-запись для management-сети существовала, но обычный путь резолва собственного FQDN возвращал link-local IPv6. Для сервисов, которые завязаны на host identity, TLS, VDSM/libvirt и management-plane, это уже не мелочь.

4. Не путать адреса management и storage

В HCI важно не только, чтобы имя резолвилось, но и чтобы оно резолвилось в правильную сеть:

management FQDN хоста должен вести в management-сеть;
storage/brick FQDN должен вести в storage-сеть;
short name и FQDN должны быть согласованы;
reverse DNS желательно проверять отдельно.

В качестве примера буду использовать такие адреса:

192.0.2.10 hci-node-01.example.org hci-node-01
192.0.2.11 hci-node-02.example.org hci-node-02
192.0.2.12 hci-node-03.example.org hci-node-03
198.51.100.10 storage-node-01.example.org storage-node-01
198.51.100.11 storage-node-02.example.org storage-node-02
198.51.100.12 storage-node-03.example.org storage-node-03

5. Если виноват `myhostname` и `authselect`

На Linux-системах с systemd модуль myhostname может возвращать локальное имя хоста, если оно не найдено раньше через files или dns. В некоторых аварийных сценариях это приводит к неожиданному self-FQDN -> fe80::....

Диагностический тест обычно выглядит так:

cp -a /etc/nsswitch.conf /etc/nsswitch.conf.bak.$(date +%Y%m%d-%H%M%S)
sed -i 's/^hosts:.*/hosts:      files dns/' /etc/nsswitch.conf
getent hosts $(hostname -f)
getent ahostsv4 $(hostname -f)

Но в production это не финальная процедура. Если nsswitch.conf управляется authselect, ручная правка может быть перезаписана или сделать состояние профиля невалидным. Нужно сначала проверить текущий профиль на конкретной машине:

authselect current
authselect check

И только затем закреплять изменение через профиль. Профиль нельзя угадывать: на разных ролях кластера он может отличаться.

6. Проверить Engine-side состояние

Когда хосты возвращаются в норму, важно подтвердить это не только глазами в UI. В зависимости от версии zVirt/oVirt можно использовать API или Engine DB wrapper. Пример класса проверки:

/usr/share/ovirt-engine/dbscripts/engine-psql.sh   -c "select vds_name,status,spm_status from vds;"

/usr/share/ovirt-engine/dbscripts/engine-psql.sh   -c "select id,status,master_domain_version from storage_pool;"

Здесь тоже есть ограничение: SQL-схемы зависят от версии. Не стоит слепо копировать запросы к storage domains из чужой инструкции без проверки схемы. Если таблица или колонка в вашей версии называется иначе, это не значит, что storage сломан.

Ограничения и риски

Этот разбор не является универсальным runbook для любого zVirt/oVirt-кластера. В другой аварии основная причина может быть в сети, storage, сертификатах, времени, split-brain, SPM locks или оборудовании.

Безопасные ограничения:

не делать force-действия в UI без понимания роли ноды;
не ребутать HCI-ноду, пока не ясно, где Hosted Engine;
не запускать Gluster heal full без доказанного повода;
не менять сразу DNS, NSS, сертификаты и сервисы одновременно;
после каждого изменения перечитывать факты.

Главный вывод

Когда кластер виртуализации выглядит сломанным, проверять надо не только storage. Иногда решающий слой: как хост видит сам себя, какой адрес получает его FQDN и совпадает ли это с ожиданиями management-plane.

В этом кейсе аккуратная диагностика помогла не трогать здоровый Gluster и восстановить кластер через исправление /etc/hosts и NSS, без лишних рестартов критичных сервисов.

Что проверить дальше

Если у вас есть кластер виртуализации или HCI, полезно заранее проверить три вещи:

Есть ли короткая схема management/storage-сетей и ролей хостов.
Понятно ли, где смотреть текущий Hosted Engine/SPM и как не трогать их первыми.
Резолвится ли self-FQDN каждого хоста именно в ожидаемый management IPv4.

Это не заменяет полноценный аудит, но сильно снижает шанс действовать вслепую в аварии.