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