Извините за неясность ранее.
У нас есть экземпляр виртуализированного сервера vmware, который является нашим основным производственным сервером. Я храню серию веб-приложений примерно в сотне уникальных доменов верхнего уровня. Для обслуживания веб-страниц мы используем стек LAMP. На этом сервере работают наши первичный и вторичный DNS-серверы (на двух IP-адресах, отличных от того, который используется для обслуживания веб-контента). И, наконец, мы также размещаем нашу почту (pop и smtp) с помощью exim (я полагаю).
Недавно у нас возникли проблемы, из-за которых наша корневая fs стала доступной только для чтения, предотвращая соединения apache2 или mysql и предотвращая входящую электронную почту. По сути, прекращение присутствия в Интернете и электронной почты для многих тысяч клиентов. Природа проблемы (все еще не определенная системой под контролем) не повлияла на привязку, поэтому DNS все еще разрешался нормально.
С тех пор мы начали зеркалировать рабочие веб-сайты и связанные базы данных mysql на вторичный сервер. Этот сервер полностью готов к производству.
У меня вопрос, каковы рекомендуемые методы аварийного переключения в случае, если apache на нашем основном производственном сервере не может (по какой-либо причине) быстро, если не автоматически, начать перенаправление трафика на вторичный, насколько это возможно.
Циклический перебор DNS нежелателен для нас, поскольку мы не хотим загружать два сервера, фактически мы хотим, чтобы вторичный сервер получал HTTP-запросы только в том случае, если главный сервер не отвечает. Отчасти это связано с тем, что наш процесс зеркалирования является односторонним, и изменения на вторичном сервере будут отражены на главном сервере и даже потеряны.
Циклический перебор DNS не рекомендуется, потому что:
1- Разные серверы не могут получать одинаковое количество запросов. Таким образом, они будут загружены неравномерно.
2- Балансировка нагрузки DNS не принимает во внимание доступность сервера. Запись DN сервера останется и может быть использована в случае сбоя.
3- DNS-кеширование только усугубит ситуацию. У вас нет контроля над кешами DNS ваших клиентов и промежуточным DNS-сервером между ними. Если вы планируете отмерять значение TTL, это может работать не так, как ожидалось. смотреть на эта почта. В принятом ответе говорится, что Many DNS server do not honor your TTL.
Рекомендуемое решение - установить балансировщик нагрузки, такой как HAProxy, вместе с решением высокой доступности, таким как Heartbeat. Эта установка должна быть установлена на двух машинах. Если один выйдет из строя, другой займет VIP-место (по сердцебиению). Работающая машина позаботится о проверке работоспособности внутренних серверов и распределении нагрузки (с помощью haproxy).
РЕДАКТИРОВАТЬ:
Если вы хотите, чтобы серверы работали в активно-пассивном режиме, вам не нужен балансировщик нагрузки. Вы можете установить Heartbeat с кардиостимулятором для мониторинга системных ресурсов, таких как apache, mysql и т. Д. Кластер можно настроить так, чтобы поддерживать только один активный сервер.
В Виртуальный сервер Linux - это высокомасштабируемый и высокодоступный сервер, построенный на кластере реальных серверов с балансировщиком нагрузки.
UCARP позволяет паре хостов совместно использовать общие виртуальные IP-адреса для обеспечения автоматического переключения при отказе
Установите nginx перед Apache. Если один сервер Apache не работает, nginx исключит его и будет обслуживать данные от других «рабочих».
Итак, настройка должна выглядеть так
nginx -> worker # 1 (Apache), worker # 2, worker # 3 и т. д.
Конечно, nginx должен быть установлен на выделенном сервере. Одна проблема, которую вы должны решить - что, если nginx выйдет из строя, но ...
сайт nginx: http://nginx.org
Насколько я понимаю, вы ищете решение с высокой доступностью, т.е. когда один сервер выходит из строя, другой сервер может взять его на себя.
ThomK предложил один из способов сделать это, за исключением того, что единственной точкой отказа будет блок nginx. Еще одна вещь, на которую вы можете обратить внимание, - это использование HAProxy (или даже nginx), но с некоторой отказоустойчивостью на основе IP.
Вы можете получить много идеи из в другом месте.
Для обеспечения избыточности в рамках одного сайта в одном интернет-канале вы хотите разместить кластерное оборудование на своем интерфейсе с резервным устройством, готовым принять IP-адрес отказавшего устройства. Но вы выйдете из строя, если у вашего интернет-провайдера произойдет сбой, или ваш сайт потеряет питание или возникнет другая проблема.
Если вам нужна защита от потери всего сайта или потери вашего интернет-провайдера, то на самом деле есть только два варианта. Один из них - получить собственный номер автономной системы BGP и запустить свои собственные маршруты BGP с пирингом (ну, платным транзитом) с несколькими разными интернет-провайдерами. Наименьший сетевой блок, с которым вы можете это сделать, - это / 24, поэтому вам понадобится сетевой блок как минимум такого размера. Затем вы можете рекламировать разные маршруты на другой сайт, если ваш основной сайт выйдет из строя.
Другой вариант, как вы предлагаете, - это циклический DNS. Некоторые люди советуют не делать этого на теоретических основаниях, и есть проблемы с тем, что клиенты Windows Vista выбирают адреса неслучайно, но это должно работать нормально для избыточности, с резервным ящиком просто обратным проксированием трафика обратно в основной ящик, если только основной ящик / сайт / Интернет-канал отключается.
После некоторого исследования выяснилось, что циклический перебор DNS ... нежелателен или рекомендуется для этой службы.
В самом деле? Мне было бы очень интересно увидеть статьи об этом.
Вы не упомянули, на какой ОС это работает - что имеет большое отношение к тому, как реализована кластеризация, или какое программное обеспечение вы в настоящее время используете для DNS / насколько легко это изменить.
Если это возможно, я настоятельно рекомендую использовать кластер реплицированного типа, а не кластер общего хранилища, особенно если данные не меняются часто.
Bind уже обеспечивает репликацию master / slave, таким образом распределяя данные по нескольким платформам, так что это просто вопрос разработки какого-либо способа маршрутизации запросов на доступный сервер.
Аналогично для MySQL.
Реализовать то же самое для файлов вашего веб-сервера просто с помощью rsync.
Хотя циклическое переключение при отказе немного медленнее по сравнению с другими методами - оно НАМНОГО надежнее, проще в администрировании и дешевле, чем другие подходы. Не зная причин, по которым вы предпочитаете круговой алгоритм, трудно предложить что-то более приемлемое. (Ребята, написавшие HA-Proxy, рекомендуют использовать как минимум 2 прокси-сервера с циклическим перебором перед кластером HA).
Я бы посоветовал вам использовать (по крайней мере, для внутреннего использования) виртуальные адреса главного и подчиненного серверов - это упрощает продвижение подчиненного. Возможно, вы даже захотите использовать виртуальные адреса для каждого узла службы / кластера. Это упрощает настройку тактового сигнала, привязанного к отработке отказа - это не будет быстрее, чем циклический перебор, но дает незначительные преимущества при сокращении обслуживания - при условии, что он реализован правильно и вы можете решить проблемы с разделенным мозгом.