
Я бы поспорил.
Автор топика не расписал поподробнее суть задачи, а мы сидим и гадаем

В данной схеме отказоустойчивость как раз на высоте:
1. управляющая система не имеет никаких особых настроек, кроме самого контролирующего скрипта. А значит, в случае падения, восстановить можно в считанные минуты (не говоря о том, что система вообще может быть на liveCD)
Падение этой системы не приводит к остановке сервисов. Т.к. её задача - скомандовать основным серверам принять на себя реальный IP
В случае падения, просто нарушится автоматическое управление.
2. самостоятельная разработка "резервного скриптика" потребует дни и недели на написание и отладку. Зачем? если есть готовая рабочая схема.
3. распределения нагрузки тут нет. Но автором ставилась задача - "отказоустойчивость", что предполагает наличие какого-то сервиса, который, в случае выхода железок из строя, подхватился бы другой машиной, стоящей "на боевом взводе"
А значит, нужна полная идентичность данных.
Внешние хранилища не спасут. Например, храним данные на супер надежном массиве. Но службы то работают на обычной машине...
В случае выхода машины из строя, да, данные сохранены. Но сами службы (да тот-же веб сайт) отвечать перестанут.
А кластер, имхо, подразумевает именно распределение нагрузки. Когда запросы отрабатываются на разных машинах. Здесь тоже есть элемент отказоустойчивости, но другой.
К примеру, проект openMosix (который благополучно сдыхает) или его прародитель Mosix (который живет).
Совершенно прозрачная система для приложений. Но эффективна она на программах, работающих сравнительно длительное время (начиная от десятков секунд).
Пробовал на openMosix кластере запускать компиляцию ядра. Так процессы просто не успевали мигрировать на другую ноду.
А значит, для тех-же веб сайтов она неприменима (когда время запуска-отработки скриптов меньше секунды).
Так что, нужно более подробное описание задачи, чтобы можно было рассуждать детальнее.
"No! Try not! Do. Or do not. There is no try." -- Yoda