У меня есть следующая настройка, стек Linux, с внешним интерфейсом, работающим с прокси-сервером nginx и статическими активами, и внутренним интерфейсом, работающим с Ruby on Rails и MySQL в режиме репликации мастер-мастер:
front-end.a, back-end.afront-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 на обоих сообщает другому узлу, что он отключен. Чтобы заставить его работать, службу Heartbeat необходимо перезапустить на одном или других узлах - и иногда для ее остановки требуется SIGKILL, а не SIGTERM. Кроме того, crm_mon показывает, что CIB (база данных кластера) реплицируется практически мгновенно, когда конфигурация изменяется на любом из front-end.a или front-end.b, но Pacemaker не торопится с фактическим перемещением IP-ресурса - это может занять несколько минут, что может поставить под угрозу наши SLA.
Итак, я начинаю рассматривать другие варианты, которые больше ориентированы на виртуальные IP-адреса и аварийное переключение IP-адресов, а не на общие кластерные ресурсы. Я вижу еще два варианта: Ucarp и оставайся живым.
Однако, учитывая количество времени, которое я потратил на настройку пульса и т. Д. И пытался заставить его работать, я хотел бы получить отзывы о лучшем подходе для этой настройки.
Прошло некоторое время с тех пор, как я посмотрел на Pacemaker, но здесь есть параметры конфигурации, которые должны помочь. Вы можете явно настроить его, чтобы не возвращаться к основному узлу автоматически. Это поможет частично решить вашу проблему. Быстрый поиск показывает, что «on-fail = standby» может быть тем, что вам нужно, но я думаю, что есть другие настройки, которые делают то же самое. Здесь вам нужна терминология «прилипчивость ресурсов».
Кроме того, имея всего два узла, вы можете легко столкнуться с ситуациями, когда оба узла находятся в сети, но думаете, что другой узел не работает. Это довольно легко может привести к повреждению данных. Вы не упомянули, что настроили его, но STONITH предназначен именно для этого. Запускать Pacemaker без него довольно рискованно, особенно если для вас важна целостность данных.