Какой метод следует выбрать для восстановления после отказа IP с ручным управлением

У меня есть следующая установка, стек Linux, с внешним интерфейсом, работающим с прокси-сервером nginx и статическими ресурсами, и внутренним сервером, на котором запущены Ruby on Rails и MySQL в репликации мастер-мастер:

• Основной сайт: front-end.a, back-end.a
• Вторичный сайт: front-end.b, back-end.b
• Маршрутизатор в общей сети, который может маршрутизировать как на первичные, так и на вторичные сайты.

Основной сайт обслуживает запросы большую часть времени. Вторичный сайт является избыточным. back-end.b находится в реплике мастер-мастер с back-end.a но только для чтения.

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

Первичный сайт может затем быть возвращен контролируемым образом, с back-end.a становится ведомым репликации только для чтения back-end.b, Когда все на первичном сайте снова готово, front-end.b начнет обслуживать недоступно, back-end.b переключится в режим "только для чтения", запросы необходимо будет снова перенаправить на основной сайт, и, наконец, первичный сайт должен стать для чтения и записи.

Приоритеты:

• Сайт не должен становиться полностью мертвым и недоступным
• Переход на работающий сайт должен быть достаточно быстрым
• Предотвращение потери / несоответствия данных важнее абсолютной надежности

В настоящее время используется текущий подход Linux-HA / Heartbeat / Pacemaker, использующий виртуальный IP-адрес, совместно используемый front-end.a а также front-end.b с предпочтением местоположения, установленным на front-end.a,

Это отлично работает для переключения через IP, если основной сайт исчезает. Тем не менее, уровень ручного управления после этого довольно не хватает.

Например, после того, как основной сайт вышел из строя, и дополнительный сайт должен быть запущен, мы должны убедиться, что основной сайт не пытается украсть IP-адрес, когда он возвращается. Однако Linux-HA, похоже, не очень хорошо это поддерживает. crm resource move является документированной командой для перемещения ресурса (она работает путем добавления правила определения местоположения с бесконечным весом), но если ресурс уже перенесен, эта команда завершается неудачно, говоря, что ресурс уже перемещен. Добавление явного предпочтения местоположения с более высоким весом, похоже, не работает надежно. До сих пор самым надежным способом было удалить существующее правило местоположения и заменить его новым правилом, предпочитающим дополнительный сайт. Такое ощущение, что мы боремся с инструментом и пытаемся заставить его делать то, для чего он не предназначен.

Есть и другие странности с Linux-HA. Часто кластер застревает в состоянии разделения мозга при загрузке - оба узла отправляют пакеты контрольных сигналов (проверяется с помощью перехвата пакетов), оба узла могут пропинговать друг друга, но crm_mon на обоих сообщает, что другой узел отключен. Служба сердцебиения должна быть перезапущена на одном или других узлах, чтобы заставить ее работать - и иногда для ее отключения требуется SIGKILL, а не SIGTERM. Кроме того, crm_mon показывает, что CIB (база данных кластера) реплицируется почти мгновенно, когда конфигурация изменяется front-end.a или же front-end.b, но Pacemaker тратит время на перемещение IP-ресурса - может потребоваться несколько минут для его перемещения, что может подвергнуть риску наши SLA.

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

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