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