Почему кластер из двух узлов, худший выбор: вопрос большинства

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

Не продолжит. Кластер из двух узлов хрупче одного узла, и день, когда вы это узнаёте, обычно плохой день.

Почему

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

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

То есть кластер защищает вас, запирая. Но при двух узлах эта защита срабатывает в половине всех отказов.

Правильное число, три

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

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

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

Если остаётесь на двух узлах, знайте

Когда один узел выводят на обслуживание, оставшийся единственный узел тоже становится неуправляемым. То есть даже плановое обновление оставляет вас запертым.

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

Собрать кластер, это не то же самое, что делать резервные копии

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

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

Что делает Atlas

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

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

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

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