Собрал кластер, а машины не переезжают: не хватает хранилища

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

Не хватает не кластера, а хранилища.

Переезжает не машина, а оперативная память

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

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

Значит, ответ умещается в одну фразу: диск должен быть виден с обоих узлов.

Два способа это устроить

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

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

Вопрос, который решает, что подходит вам: если узел внезапно умрёт, сколько минут потери вы принимаете? Если ответ «ноль», нужно общее хранилище. Если «пара минут не страшно», хватит копирования по расписанию, и оно намного дешевле.

Контейнеры переезжают не так, как виртуальные машины

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

То есть переноса без перерыва для ваших контейнеров не существует, даже с кластером. Это не недостаток, а природа контейнера: виртуальная машина несёт своё ядро, контейнер пользуется серверным, а это ядро путешествовать не может.

Практическое следствие: учитывайте это, решая, какая работа живёт в контейнере, а какая в виртуальной машине. Если работа, не терпящая перерыва, живёт в контейнере, в ночи обслуживания она будет останавливаться.

Установите порядок заранее

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

Считать это в ту же ночь, плохая мысль. Запишите один раз и отложите.

Что делает Atlas

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

Различие для контейнеров сделано здесь явно. Для виртуальных машин предлагаемый способ, перенос на ходу; для контейнеров цепочка выключить, перенести, запустить. Продукт не подаёт это как выбор, он констатирует, что иначе контейнер перенести нельзя.

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

И предложение остаётся предложением: команда переноса сама не выполняется, кнопку нажимаете вы.

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