Я ищу способ настроить Apache как высокодоступный. Идея заключается в том, чтобы иметь кластер из 2+ серверов Apache, обслуживающих одни и те же веб-сайты. Я могу настроить IP-адрес каждого сервера с циклическим DNS, чтобы каждый запрос случайным образом отправлялся на один из серверов в кластере (пока что я не слишком беспокоюсь о балансировке нагрузки, хотя это может сыграть свою роль позже).
Я уже настроил его и работаю с несколькими серверами Apache VM (распределенными по нескольким физическим серверам), обслуживающими веб-сайты, и циклическим DNS, и это работает отлично. База данных SQL настроена с использованием MariaDB в кластере высокой доступности, веб-данные (HTML, JS, PHP-скрипты, изображения, другие ресурсы) хранятся в LizardFS, а сессии также хранятся в общем расположении. Все это работает хорошо, пока один из серверов в кластере не становится недоступным по какой-либо причине. Затем процент запросов (примерно количество отключенных серверов, деленное на общее количество серверов в кластере) остаются без ответа. Вот варианты, которые я рассматривал:
Автоматические обновления DNS
Иметь некий процесс, который контролирует функциональность веб-серверов и удаляет любые упавшие серверы из DNS. Это имеет две проблемы:
Во-первых, хотя мы можем установить TTL на очень низкое значение (например, 5 секунд), я слышал, что несколько DNS-серверов будут устанавливать минимальный TTL выше нашего. И некоторые браузеры (а именно Chrome) будут кэшировать DNS не менее 60 секунд независимо от настроек TTL. Так что, даже если у нас все хорошо, некоторые клиенты могут не иметь доступа к сайтам в течение некоторого времени в случае обновления DNS.
Во-вторых, программа, которая отслеживает функциональность кластера
и обновляет записи DNS, становится новой единой точкой отказа. Мы
можем обойти это, распределив более одного монитора по нескольким
систем, поскольку если они обе обнаружат проблему и внесут одинаковые изменения в DNS, то это не должно вызвать никаких проблем.
uКарп/Сердцебиение
Сделайте IP-адреса, к которым осуществляется доступ, и в DNS-цикле виртуальными и переназначьте их на работающие серверы с неработающих серверов в случае, если сервер выйдет из строя. Например, VIP сервера 1 — 192.168.0.101, а VIP сервера 2 — 192.168.0.102. Если сервер 1 выйдет из строя, то 192.168.1.102 станет дополнительным IP на сервере 2. Это имеет две проблемы:
Во-первых, насколько мне известно, uCarp/Heartbeat отслеживает своих пиров специально на предмет недоступности, например, если пир не может быть пропингован. Когда это происходит, он берет на себя IP-адрес упавшего пира. Это проблема, потому что есть больше причин, по которым веб-сервер может не обслуживать запросы, помимо того, что он просто недоступен в сети. Apache мог выйти из строя, может быть ошибка конфигурации или какая-то другая причина. Я бы хотел, чтобы критерием было «сервер не обслуживает страницы, как требуется», а не «сервер не пингуется». Я не думаю, что я могу определить это в uCarp/Heartbeat.
Во-вторых, это не работает между центрами обработки данных, потому что каждый набор серверов в центрах обработки данных имеет разные блоки IP-адресов. Я не могу иметь виртуальный IP-флот между центрами обработки данных. Требование функционирования между центрами обработки данных (да, моя распределенная файловая система и кластер базы данных доступны между центрами обработки данных) не является обязательным, но это было бы приятным плюсом.
Вопрос
Итак, есть мысли, как с этим бороться? По сути, святой Грааль высокой доступности: никаких отдельных точек отказа (ни на сервере, ни в балансировщике нагрузки, ни в центре обработки данных) и практически никакого простоя в случае переключения.
решение1
Когда мне нужна HA и распределение нагрузки, я использую keepalived и настраиваю его с двумя VIP. По умолчанию VIP1 назначается server1, а VIP2 назначается server2. Когда какой-либо сервер выходит из строя, другой сервер берет оба VIP.
Keepalived позаботится о HA, наблюдая за другим сервером. Если сервер недоступен или какой-либо интерфейс не работает, он переходит в FAULTсостояние. VIP будет занят другим сервером. Для мониторинга вашего сервиса вы можете использовать track_scriptопцию.
Если вы хотите добавить еще один кластер в другом центре обработки данных, вы можете добавить еще два сервера и выполнить ту же конфигурацию. Теперь вы можете распределять нагрузку между центрами обработки данных с помощью DNS round-robin. В этом случае обновление DNS не требуется.