ПСИ q7 — 2026-09-16

Стенд: q7, 5 узлов / 5 пулов, vStack OS 3.1.0-rc06. Окно: 10:55–12:18 UTC. Нагрузка: 8 тестовых ВМ (Debian 13.3, 4 vCPU / 8 ГБ, схема 2+2+2+2 на z01/z02/z03/z05 — больше не дала квота vDC 9). Сценарии: отказ одного узла (u003), возврат + Hard Transfer, отказ двух узлов (u003+u004), возврат, отказ узла с пулом mgmtVM (u002), возврат. Разница с прошлыми ПСИ сверена с локальными протоколами Q7_PSI от 10.09 и 11.09 (каталог docs/reports в GitLab пока пуст).

Что пошло не так

1. Remote-ВМ пула не поднимается после failover. ВМ и диски разделены: диски отдаются по NVMe-oF с ноды-лидера пула, а саму ВМ планировщик сажает на любую ноду (local — на лидере, remote — на другой; в логе так и помечено: Pool:'z05' LOCAL vs Pool:'' REMOTE). При падении лидера гаснут все его ВМ, пул встаёт на новой ноде за 48–66 с, дальше vms-start рассылается — судя по логам, только по списку ВМ погибшей ноды (за 1.1 ровно 3 пары status=1, все три жили на мёртвой n3). Итог, дважды за прогон: ВМ с погибших нод поднялись все (1039202 за +97 с, 1039194, 1039199/1039200), а ВМ упавшего пула с живых нод — нет:

• 1039203 (z05; пул n4→n1, ВМ всё время на n1): Offline 11:42:01 → тишина → ручной старт 11:57:02 (logs/vm-1039203-z05.log);
• 1039193 (z01; пул n2→n4, ВМ на n1): Offline 11:58:16 → тишина → ручной старт 12:18:27 (logs/vm-1039193-z01.log). Ручной старт в обоих случаях сразу code=1 без -440 — ресурсов хватало, просто никто не позвал. В логе только факт останова (stopped with status: 104), ошибки нет — ВМ лежит в o1 невидимо для мониторинга. До половины нагрузки пула после failover остаётся погашенной до ручного вмешательства. Это отдельный срез от DEF0000922 (тот закрыт для ВМ с погибшей ноды). Проверить покрытие дефектом, если нет — завести.

2. Простой управления 2м17с при отказе пула с mgmtVM. Power off u002 (лидер z01 с mgmtVM + z04) 11:57:58: API недоступен с +15 с, z01 через RECOVERING уходит на n4, z04 — на n3. mgmtVM стартует сама в +74 с, первый API=200 — через +2м17с (logs/step-23-timeline.log). Пока API лежит, все тенанты без управления. INC0003951 остаётся открыт; на операцию с пулом mgmt заведена фронтенд-задача с предупреждением. Попутно за окно 167 ошибок потери метрик (INC0003959).

Замечания (не продукт): BMC .244 по root отбит (0xc1, рабочий — admin) — причина дрейфа доступов известна (затирание master.passwd/ccrd.db при обновлении); SSH только на u003/u005; сценарий двух узлов вышел разнесённым на ~7 мин из-за BMC.

Что ломалось раньше, а теперь работает

Hard Transfer пула с работающими ВМ: 10–11.09 падал E030 → EA90001 с уходом в Not Consuming, 16.09 прошёл с первого раза ({"response"}, обе ВМ включая remote остановлены штатно) — plausibly фикс DEF0001492 (Center). Узел после failover его пулов: 10.09 висел OFFLINE навсегда, 16.09 все 4 вернулись с NODE-ONLINE, resilver везде автоматический.

Материалы

Файл	Содержание
logs/vm-1039203-z05.log	Жизнь 1039203: create, REMOTE-старт, Offline 11:42:01, тишина, ручной старт
logs/vm-1039193-z01.log	Жизнь 1039193: create, REMOTE-старт, Offline 11:58:16, тишина, ручной старт
logs/step-21b-timeline.log	Покадрово: отказ u004, z05 → n1 за 66 с
logs/step-23-timeline.log	Покадрово: отказ u002, простой API 2м17с
logs/step-24-timeline.log	Возврат u002: ONLINE за 2м21с, без залипания
logs/step-13-cluster-snippet.log	Hard Transfer z03: stop→OK, start→OK
logs/step-11-timeline.log	Отказ u003: все vms-start — только ВМ погибшей ноды