Порядок запуска это задержка, а не зависимость

Порядок запуска настраивают в расчёте на то, что вторая машина подождёт готовности первой. Она не ждёт. Она выжидает фиксированное число секунд и стартует в любом случае, поэтому порядок, работавший на испытаниях, подводит утром после настоящего отключения света.

AtlasPVE ·

Эта статья отвечает на

  • proxmox порядок запуска
  • proxmox boot order не работает
  • proxmox задержка запуска вм
  • proxmox порядок выключения
  • proxmox start order

Узел возвращается после отключения света, и половина того, что должно работать, не работает. Машина с базой данных поднялась, а приложение перед ней сдалось; или контейнер не смог подключить хранилище, которое другой контейнер ещё только поднимал. Ничего не сломано, и никто не записал ошибку, которую стоило бы читать. Части просто поднялись не в том порядке.

Именно здесь форма вашей установки, то есть кто от кого зависит, перестаёт быть схемой в голове и становится тем, что машина действительно исполняет. Стоит точно знать, что делает этот механизм, потому что он уже, чем принято думать.

Фраза, объясняющая большинство неожиданностей

Задержка запуска это интервал, а не условие.

Когда вы задаёте гостю задержку, Proxmox VE запускает этого гостя, ждёт указанное число секунд и переходит к следующему. Он не проверяет, завершилась ли загрузка внутри гостя. Он не проверяет, отвечает ли служба. Он ждёт и идёт дальше.

То есть построение в вашей голове, "приложение ждёт базу данных", никогда не становится настройкой. Настройкой становится другое: "приложение стартует через девяносто секунд после того, как базе данных велели стартовать". При спокойной тестовой перезагрузке эти два случая неразличимы. После настоящего отключения света, когда диски медленнее, идёт проверка файловой системы или гость уходит в аварийный режим, различие проявляется.

Четыре правила, которые стоит знать до расстановки цифр

Меньшее стартует первым и выключается последним. Порядок выключения представляет собой обращение порядка запуска, отдельной настройки нет. Гость с порядком 1 поднимается первым и гаснет последним, а это обычно и нужно тому, от чего зависит всё остальное.

Одинаковые числа не означают случайность. Гости с одинаковым порядком дополнительно сортируются по возрастанию идентификатора. Значит, совпадения устойчивы и предсказуемы, и не нужно давать каждому гостю отдельное число ради повторяемого поведения.

Гости без порядка всегда стартуют после тех, у кого он задан. Это полезнее, чем звучит. Нумеровать всё не требуется. Пронумеруйте три или четыре вещи, которым действительно нужно быть ранними, а остальное оставьте как есть.

Порядок действует в пределах одного узла, а не кластера. Он не может выразить требование "этот гость на узле A должен подняться раньше того, что на узле B". Как только зависимость пересекает границу узла, механизму нечего о ней сказать.

Ловушка, появляющаяся позже

Гости под управлением стека высокой доступности игнорируют и автозапуск, и порядок запуска. Процедура запуска и остановки пропускает их целиком, потому что решение о времени их работы принимает менеджер высокой доступности.

Эта ловушка кусает поздно. Одиночный узел с тщательно выверенным порядком работает год. Потом появляется второй узел, часть гостей переходит под высокую доступность, и их порядок тихо перестаёт применяться. Ничто вас не предупредит, потому что ничего не сломано: просто сменился ответственный.

Задержка, которая вам действительно нужна, часто другая

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

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

Число, которое никто не настраивает, пока не заболит

Тайм-аут выключения по умолчанию составляет 180 секунд на гостя. Proxmox VE просит гостя выключиться, ждёт, и если по истечении срока гость всё ещё работает, его останавливают принудительно. У массовой остановки всех гостей есть собственный общий предел в три минуты, после которого происходит то же самое.

Для машины, которая при выключении сбрасывает данные на диск, этот потолок стоит проверить намеренно, а не обнаружить во время аварии. Значение по умолчанию щедро для большинства гостей и коротко для нескольких, и эти несколько как раз те, где принудительная остановка вам чего-то стоит.

Что мы видим на практике

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

Это нормальное положение дел, и часто оно вполне уместно. Машинам, не зависящим друг от друга, порядок не нужен. Задача этого текста уже: если вы хоть раз произносили вслух, что одному гостю нужен другой поднятым раньше, то сейчас эта фраза живёт только в вашей памяти, а отключение света вашу память не читает.

Что делает Atlas

Atlas ничего не переупорядочивает за вас и не выдумывает систему зависимостей поверх той, что есть у Proxmox VE. Он делает связи видимыми одной картинкой вместо перебора по гостю, чтобы вопрос "что здесь на самом деле от чего зависит" можно было задать, пока машина спокойна, а не пока она поднимается.

Увидеть форму не значит настроить её. Но никто не задаёт разумный порядок для схемы, которую ни разу не видел нарисованной.

Источники

Собственная документация Proxmox. На английском, и последнее слово в этом вопросе за ней.

Похожие статьи

Как это выглядит внутри Atlas?

Перейти на страницу продукта