Я работаю на небольшого интернет-провайдера, и мы размещаем около 250 доменов и все, что с этим связано: DNS, почту, фильтрацию спама и резервное копирование. В настоящее время у нас есть отдельные DNS-серверы (два из них) и почтовые серверы (исходящая почта фактически находится на вторичном DNS-сервере, но ранее была на собственном сервере). В прошлом это делалось в качестве страховой меры. Последнее, что нам нужно, это чтобы какой-нибудь дурак (обычно ваш покорный слуга) обрушил сервер, убирая DNS и почту вместе с ним, или чтобы спамеры заглушили наш входящий SMTP-сервер, предотвращая отправку исходящей почты. В прошлом это было проблемой, и наши серверы были настроены так, как сейчас, чтобы бороться с ней.
Однако решения кластеризации, такие как Sun Cobalt RAQ (в былые времена) и Virtualmin, похоже, обслуживают комплексный подход, а затем устраняют сбои с помощью резервных серверов. До сих пор я избегал этого, но мы уже некоторое время используем Virtualmin на нашем веб-сервере, и я хотел бы расширить его до использования для кластера высокой доступности. Наш сетевой партнер недавно построил центр обработки данных, который устранил все наши другие недоработки, такие как проблемы с сетью, охлаждением и питанием, поэтому теперь единственное, что может пойти не так, - это то, что я подключил сервер, что произошло в начале этого месяца.
Одна из главных причин, по которой мы избегали этого пути, заключается в том, что наши требования к оборудованию не особенно высоки. Один сервер легко обрабатывает все сайты, которые мы размещаем (большинство из них плоские). Кроме того, маршрутизаторы с балансировкой нагрузки обычно дороги и сложны. Все, что я действительно ожидаю, - это построить двухузловой кластер для избыточности, чтобы, когда я подключаю сервер (как бы редко это ни было), мы не уходили в течение 8-12 часов, пока я его перестраиваю.
Что мне нужно знать, так это с чего начать и могу ли я вообще возиться с такими вещами.
Я обнаружил, что использование балансировки нагрузки - мое предпочтительное решение для обеспечения высокой доступности веб-серверов. Есть преимущества для промежуточного развертывания кода, не простаивая доступные ресурсы и вводя избыточность. LVS это мое предпочтительное решение там. Другим нравится Фунт и я также заинтригован HAProxy. С помощью LVS настройка сервера ldirectord и использование arptables на веб-сервере может быть простой реализацией. Вы можете предотвратить единую точку отказа с LVS, имея реализацию активного / пассивного сервера с аварийным переключением, используя сердцебиение.
Теперь, если вы продаете учетные записи на виртуальном хостинге, внедрение высокой доступности с автоматическим переключением при отказе будет более сложным. При этом вам, возможно, придется подумать о решении избыточного хранилища, к которому могут иметь доступ несколько серверов, и настроить активный / пассивный сервер с помощью пульса. DRBD похоже, здесь это может быть полезно.
Вы можете реализовать полные решения высокой доступности без единой точки отказа, используя полностью открытое и стандартное оборудование. Если вам нужны дополнительные рекомендации, я буду рад помочь. Это одна из моих любимых областей, на которой нужно сосредоточиться.
Недавно мы настроили Ucarp в нашем кластере и установите 4 идентично настроенных узла. Мы запускаем веб-приложение собственной разработки, поэтому 4 узла, когда они не служат интерфейсом, фактически выполняют внутреннюю работу.
UCARP и несколько сценариев, которые я собрал, будут автоматически вызывать IP на другом узле, когда узел, обслуживающий вещи, начинает действовать. NGINX - это наш интерфейсный сервер, который обеспечивает перенаправление запросов на доступный узел.
Результатом всего этого является то, что я могу без предупреждения отключить практически любой из наших 4 узлов, и службы будут автоматически мигрировать на другой доступный узел в течение нескольких секунд. (Существующие соединения с этим узлом прерываются, но в любой данный момент есть только небольшая горстка, к тому времени, когда они перезагружаются, все возвращается на полную скорость в другом месте.) UCARP обнаружит сбои в IP-подключении --- если другие вещи идут плохо, вам нужно разработать способ отключить IP-соединение от плохого узла, чтобы другие работающие узлы взяли на себя управление.
Все 4 узла монтируют файловую систему, экспортированную в nfs, которая обрабатывается парой машин, на которых работает drbd.