Як можна збалансувати вхідний веб-трафік серед N apache-серверів?

Я хочу використати щось на зразок Heartbeat / Squid / Varnish / тощо, щоб збалансувати кількість вхідного трафіку серед внутрішніх апаратних апаратів. Це повинно бути програмним, а не апаратним забезпеченням, оскільки всі мої речі працюють на VPS. Я не маю багато досвіду в цій галузі, тому шкода, якщо я зловживаю термінологією і підбираю неправильні пакети.

Я намалював щось, щоб проілюструвати те, що я хочу. Зелена сторона - це те, як виглядатимуть початкові налаштування, а синя - це те, що може виглядати після додавання більшої кількості примірників apache через збільшення трафіку. Це може бути не таким чином, як ці речі працюють, але в ідеалі я б додав IP-адресу балансира / ів до DNS домену. Тоді врівноважувач (и) побачать, скільки з'єднань є в кожному екземплярі apache (через деякий список конфігурацій внутрішніх IP-адрес або вічних IP-адрес) і розподіляє з'єднання порівну. У синьому кольорі є другий балансир, я впевнений, що в якийсь момент і балансиру знадобиться допомога.

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

Будь-яка допомога була б чудовою.

Практично будь-який "зворотний проксі" зробить те, що ви просите.

Наприклад, лак, фунт і HAProxy - все добре в тому, що вони роблять, але вони також мають свої відмінності - однак, щодо того, що ви просите, будь-який з них зробить. Особисто я б подумав, що вам найкраще буде з HAProxy, але це лише здогадка.

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

Крім того, ви можете скористатися для цього заздалегідь побудованою послугою - наприклад, запустити програмне забезпечення на обласному обчислювальному хмарі Amazon Elastic та використовувати їх еластичне балансування навантаження.

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

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

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

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

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

Балансування навантаження на круглий Робін

• нічого не коштує
• просто реалізувати та керувати
• реалізує відмову у клієнта - єдине місце, яке може бути надійно виявлено
• неявно підтримує спорідненість із сервером, але все ще дозволяє відмову без проблем управління сеансами, пов'язані з липкими сеансами
• не вимагає додаткового програмного забезпечення / обладнання / конфігурації на вузлах кластера

Мене дивує кількість недостовірної інформації, що стосується круглого столу. Якби я був цинічною людиною, я міг би задуматися, чи є зв’язок із постачальниками, які виробляють велике дороге обладнання для балансування навантаження.

Єдиний момент, який я зізнаюся, це

1. Адреси IPV4 стають дефіцитними і, отже, дорогими - але все ще набагато. набагато дешевше, ніж скажімо, CSS Cisco.

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 та серцебиття, щоб направити трафік та виконати відмову.

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

Добре, про це попросили деякий час назад, і я запізнююсь на вечірку. Все-таки тут є що додати.

Джекі, ти її майже прибив. Ваша ілюстрація показує, як балансування навантажень обробляється на більшості менших і середніх установок.

Ви повинні прочитати вступ про балансування навантаження від Віллі Тарре, до якого Nakedible пов'язаний. Він все ще діє, і це хороший вступ.

Вам потрібно врахувати, як вони відповідають вашим потребам:

• Балансори навантаження TCP / IP (Linux Virtual Server та ін.) Найнижча за кожне з'єднання накладна, найвища швидкість, не може "бачити" HTTP.
• Балансори завантаження рівня HTTP (HAProxy, nginx, Apache 2.2, Pound, Microsoft ARR та ін.). Більш високі накладні, можуть бачити HTTP, можуть gzip HTTP, можуть робити SSL, можуть робити липке балансування навантаження сеансу.
• Зворотні проксі HTTP (сервер трафіку Apache, лак, кальмар). Можна зберігати кешовані об'єкти (деякі веб-сторінки, css, js, зображення) в оперативній пам’яті та пересилати їх наступним клієнтам, не залучаючи веб-сервер із заднім числом. Часто можна робити те саме, що роблять балансири навантаження L7 HTTP.

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

Ну, звичайно. Але балансування навантаження просто, і часто один балансир навантаження може швидко працювати . Я посилаюсь на цю статтю, яка вразила нерв в Інтернеті, як лише приклад того, яку продуктивність може забезпечити єдиний сучасний сервер . Не використовуйте кілька ЛБ, перш ніж вам потрібно. Коли вам потрібен загальний підхід, це балансири навантажень на рівні IP на самому фронті (або DNS Round Robin), перехід на балансири навантажень рівня HTTP, перехід на проксі-сервери та веб-сервери.

допомога щодо того, якими мають бути "балансири / ті", та найкращі практики щодо їх налаштування.

Місце неприємності - це обробка стану сеансу і певною мірою поведінка відмови. Налаштування самих балансирів навантажень порівняно просто.

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

Ці дві кращі алгоритми балансування навантаження, в тому сенсі , що вони мають доброякісний поведінку при високих навантаженнях і рівномірний розподіл навантаження, є кругової і справжня балансування випадкової навантаження. І те й інше вимагає, щоб ваша веб-програма мала глобальний стан сесії, доступний на вузлах webapp. Як це зробити, залежить від стека технологій webapp; але, як правило, для цього доступні стандартні рішення.

Якщо ні статичне хешуваннявання, ні загальний стан сеансу не підходять для вас, то вибір, як правило, " балансуючий сеанс " балансування навантаження та стан сеансу на сервері. У більшості випадків це працює добре, і це цілком життєздатний вибір.

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

Так, деякі сайти використовують це. Існує багато імен для безлічі різних алгоритмів балансування навантаження, які існують. Якщо ви можете обрати кругового або випадкового (або зваженого кругового робіна, зваженого випадкового), то я рекомендую вам це зробити з причин, наведених вище.

І останнє: Не забувайте, що багато постачальників (F5, Cisco та інших компаній високого класу, fx Coyote Point і Kemp Technologies за більш прийнятними цінами) пропонують зрілі пристрої для балансування навантаження .