Как я могу сбалансировать входящий веб-трафик между серверами N apache?

Я хочу использовать что-то вроде Heartbeat / Squid / Varnish / etc, чтобы сбалансировать объем входящего трафика между внутренними экземплярами apache. Это должно быть программное, а не аппаратное обеспечение, так как все мои вещи работают на VPS. У меня нет большого опыта в этой области, поэтому извините, если я неправильно использую терминологию и выбираю неправильные пакеты.

Я нарисовал что-то, чтобы проиллюстрировать, что я хочу. Зеленая сторона - это то, на что будет похожа первоначальная установка, а синяя сторона - на то, как она может выглядеть после добавления большего количества экземпляров apache из-за увеличения трафика. Возможно, это не так, но в идеале я бы добавил IP-адрес балансировщика / -ов в DNS домена. Затем подсистема балансировки увидит, сколько подключений имеется в каждом экземпляре Apache (через некоторый список конфигурации внутренних или вечных IP-адресов), и распределит соединения в равной степени. На синем фоне есть второй балансировщик, так как я уверен, что в какой-то момент балансировщику тоже понадобится помощь.

Может быть, я ошибаюсь, но мне нужна помощь в определении того, какими должны быть «балансировщики», и передовой практики по их настройке.

Любая помощь будет отличной.

Почти любой "обратный прокси" будет делать то, что вы просите.

Например, Varnish, Pound и HAProxy хороши в том, что они делают, но у них также есть свои отличия - однако, то, что вы просите, подойдет любой из них. Лично я думаю, что вам лучше всего использовать HAProxy, но это только предположение.

Возможно, вам лучше прочитать статью о балансировщиках нагрузки, которая поможет вам решить, какой тип вам нужен: http://1wt.eu/articles/2006_lb/

Кроме того, вы можете подумать об использовании предварительно созданного сервиса для этого - например, запустить свое программное обеспечение в Amazon Elastic Compute Cloud и использовать их Elastic Load Balancing.

Во-первых, есть важный вопрос, на который нужно ответить:
нужно ли, чтобы пользовательские сеансы обрабатывались балансировщиком нагрузки и всегда направлялись на один и тот же веб-сервер (если он жив)?

• сеансы не требуются : в этом случае вы должны использовать эффективную программу nginx в качестве балансировщика нагрузки. Конфигурация проста в настройке, когда вам нужно всего лишь указать список веб-серверов в upstream upstream_name { server1, ..., serverN }выражении, тогда для данного домена вам нужна простая proxy_pass upstream_nameдиректива.
  Смотрите Nginx вики .

• Для сеанса требуется аналогичный параметр для фунта, где вы указываете имя файла cookie, в котором будет размещаться идентификатор сеанса ( ID MYCOOKIENAME), а затем список BACKENDдля всех ваших серверов.
  Смотрите, например, пример установки фунта .

Когда возникает необходимость в нескольких балансировщиках нагрузки, вы можете выбрать heartbeatконфигурацию, которая либо гарантирует, что только один балансировщик монтирует виртуальный IP-адрес для данного домена (если требуются сеансы, либо монтирует оба и отправляет DNS с двумя IP-адресами для экземпляр). Может быть, это должно быть подробно описано в другом вопросе в тот момент, когда это становится необходимым (поскольку инструменты развиваются быстро).
Смотрите также эту ссылку, например.

У вас должна быть очень веская причина для внесения дополнительной сложности и единой точки отказа в вашу архитектуру.

Round-Robin балансировка нагрузки

• ничего не стоит
• прост в реализации и управлении
• реализует аварийное переключение на клиенте - единственное место, где сбой может быть надежно обнаружен
• неявно поддерживает привязку к серверу, но все же допускает аварийное переключение без проблем управления сеансами, связанных с липкими сеансами
• не требует дополнительного программного / аппаратного обеспечения / конфигурации на узлах кластера

Это удивляет меня количеством неверной информации о круговом приеме. Если бы я был циничным человеком, я мог бы задаться вопросом, есть ли какая-либо связь с поставщиками, которые производят большое дорогое оборудование для балансировки нагрузки.

Единственное, что я признаю, это то, что

1. Адреса IPV4 становятся дефицитными и, следовательно, дорогими, но все же значительными. намного дешевле, чем, скажем, Cisco CSS.

2. Интернет все чаще работает на веб-сервисах - и не все разработчики реализуют поддержку DNS в соответствии со спецификациями . Но каждый браузер, который я когда-либо использовал, работает как надо

Начните свой квест здесь: http://httpd.apache.org/docs/2.1/mod/mod_proxy_balancer.html и http://www.barneyb.com/barneyblog/2009/02/26/apache-httpds-mod_proxy_balancer/

Для балансировщиков вы можете обратиться к LVS по адресу http://www.linuxvirtualserver.org/ , возможно, запустив ldirectord и heartbeat для направления трафика и выполнения отработки отказа.

Nginx великолепен в качестве прокси-сервера верхнего уровня, я с большим успехом использовал его в конфигурации, выполняющей 1M + уникальных приложений в день

Хорошо, об этом недавно спросили, и я опоздал на вечеринку. Тем не менее, здесь есть что добавить.

Джеки, ты в значительной степени прибил это. На иллюстрации показано, как выполняется балансировка нагрузки в большинстве небольших и средних установок.

Вы должны прочитать введение Вилли Тарро по балансировке нагрузки, с которым связался Nakedible. Это все еще действует, и это хорошее введение.

Вы должны рассмотреть, как они соответствуют вашим потребностям:

• Балансировщики нагрузки на уровне TCP / IP (Linux Virtual Server и др.). Самые низкие издержки на соединение, самая высокая скорость, не может «видеть» HTTP.
• Балансировщики нагрузки уровня HTTP (HAProxy, nginx, Apache 2.2, Pound, Microsoft ARR и другие). Более высокая нагрузка, может видеть HTTP, может gzip HTTP, может делать SSL, может выполнять балансировку нагрузки сессионного режима.
• Обратные прокси HTTP (Apache Traffic Server, Varnish, Squid). Может хранить объекты с кэшем (некоторые веб-страницы, CSS, JS, изображения) в оперативной памяти и пересылать их последующим клиентам без участия серверного веб-сервера. Часто может выполнять те же действия, что и балансировщики нагрузки HTTP L7.

есть второй балансир, так как я уверен, что в какой-то момент балансиру тоже понадобится помощь.

Хорошо обязательно. Но балансировка нагрузки проста, и часто один балансировщик нагрузки может работать быстро . Я ссылаюсь на эту статью, которая поразила нервы в сети, как пример того, какую производительность может обеспечить один современный сервер . Не используйте несколько LB, прежде чем вам нужно. Когда вам нужен общий подход, это балансировщики нагрузки на уровне IP в самом начале (или DNS Round Robin), переход к балансировщикам нагрузки на уровне HTTP, переход на прокси и серверы веб-приложений.

справка о том, какими должны быть «балансировщики», и рекомендации по их настройке.

Проблемой является обработка состояния сеанса и, в некоторой степени, поведение состояния сбоя. Настройка самих балансировщиков нагрузки сравнительно проста.

Если вы используете только 2-4 серверных веб-приложения, статическое хеширование на основе исходного IP-адреса может быть жизнеспособным. Это устраняет необходимость в общем состоянии сеанса между серверами веб-приложений. Каждый узел веб-приложения видит 1 / N всего трафика, а сопоставление клиент-сервер статично при нормальной работе. Это не подходит для больших установок, хотя.

Эти две лучшие алгоритмы балансировки нагрузки, в том смысле , что они имеют доброкачественное поведение при высоких нагрузках и равномерное распределение нагрузки, являются круговой и истинная балансировка случайной нагрузки. Оба из них требуют, чтобы ваше веб-приложение имело глобальное состояние сеанса, доступное на узлах веб-приложений. Как это сделать, зависит от технологического стека webapp; но обычно есть стандартные решения для этого.

Если вам не подходят ни статическое хеширование, ни состояние общего сеанса, то обычно выбирается балансировка нагрузки « липкий сеанс » и состояние сеанса для каждого сервера. В большинстве случаев это работает нормально, и это вполне жизнеспособный выбор.

Балансировщик / ы будет видеть, сколько подключений на каждом экземпляре Apache (через некоторый список конфигурации внутренних IP-адресов или вечных IP-адресов) и распределяет подключения одинаково

Да, некоторые сайты используют это. Существует множество названий для множества существующих алгоритмов балансировки нагрузки . Если вы можете выбрать циклический или случайный (или взвешенный круговой, взвешенный случайный), я бы порекомендовал вам сделать это по причинам, указанным выше.

И последнее: не забывайте, что многие поставщики (F5, Cisco и другие высококлассные, FX Coyote Point и Kemp Technologies по более разумным ценам) предлагают зрелые устройства балансировки нагрузки .