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

Практически любой «обратный прокси» сделает то, о чем вы просите.

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

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

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

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

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

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

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

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

Циклическая балансировка нагрузки

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

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

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

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

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

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

начните свой квест здесь: 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/

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

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

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

Вы должны прочитать Введение в балансировку нагрузки Вилли Тарро что 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-адреса может быть жизнеспособным. Это позволяет избежать необходимости совместного использования состояния сеанса между серверами веб-приложений. Каждый узел webapp видит 1 / N от общего трафика, и отображение клиент-сервер статично при нормальной работе. Однако это не подходит для установки большего размера.

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

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

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

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

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