Но теперь нам нужно ещё 3 такие штуки на случай отказа тех штучек

По 3 на каждую и так далее

Кстати, там система размазана по нескольким физическим серверам. Так что плейны могут дохнуть сколько угодно.

А для пожара в ЦОД и ядреного удара есть катастрофаустойчивые решения (IBM Geographically Dispersed Parallel Sysplex (GDPS))

Смотри, я говорю про случай, когда отказывает та самая система, которая обеспечивает отказоустойчивость
Скажем, координация между контролплейнами ломается и они начинают глючить сразу все

Да уж, такое администрировать..

ну нет. )))
просто есть у тебя 2 штуки, и допустим на каждой из них принято разное решение....
Системе непонятно что делать.

А если таких штуки 3, то по кворуму можно принять решение

Напеример CEPH рекомендует не менее 3х нод.

Есть пример, которые  я знаю -  mongodb
Она спроектирована как отказоустойчивая, ее узлы могут автоматически выбирать мастера при отвале любой из нод, мастера не нужно переключать руками
Но если у тебя будет постоянно флапать сеть, мастер будет переключаться туда-сюда, в процессе переключения монга не будет нормально обрабатывать запросы, и ты получишь дохлый кластер
Или если будет тупить механизм выбора мастера (хотя с таким в случае монги я не сталкивался, но это возможно, как раз про такие случаи я говорю)

То есть регрессии в софте NSK?
Ну дык надо просто не коммитить код в прод после приема веществ. Не брать в коре тим индусов-джунов. Вообще не менять ПО которое отвечает за базовые сервисы и будет счастье.

Это отлично, но вот пример Селектела без индусов
Понятно, что они делали опасную вещь (хотели полностью заменить внутреннюю сеть), но и без индусов все сломалось. Потому что сломалась что-то центральное, что нельзя зарезервировать, по кр мере на ходу.

Это как? Сети вообще самое что всегда можно делать на ходу.

Я сам ножницами случайно 2 нитки FC отрезал из 6 под нагрузкой биллинговой системы в сотовом операторе посреди рабдня и ничего.

Всю сеть опасно же менять, а они всю сеть меняли
Можно, но опасно)
Если я правильно понял, у них синхронизация данных стореджа летала через ту же сеть, через которую ходили данные к клиентам (то есть сеть стореджа не была отделена от сети передачи данных; если так, то это неправильно кнш)
Они "наживую" делали вторую сеть и сторедж переключали в нее.

Ааа.... Ну как говорит мой знакомый мотоциклист "Надо чаще с головой созваниваться!" © 😂

а еще извечная проблема когда мастеров становится 2

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

Стореджу нужен гарантированный канал, там задержка в несколько мс критична
Данные могут обойтись без таких гарантий

Точно

Vlans +qos ?