LINUX.ORG.RU
ФорумAdmin

Балансировка нагрузки. Надежность. HAProxy, nginx

 , , , ,


0

2

Привет.

Поделитесь опытом про сабж. В первую очередь интересует веб. Какие должны быть масштабы проекта, когда уже нужно задуматься о распределении нагрузки на несколько серверов? Или балансировка может быть полезна и для небольших проектов? Кто-нибудь реально занимался такими вещами не на локалхосте? Эта тема в интернете часто обсуждается, такое ощущение что у каждого второго свое облако, но я сам лично вообще ни разу ничего подобного не видел.

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

Про HAProxy в вики написано:

HAProxy используется в ряде высоконагруженных веб-сайтов, включая Twitter, Instagram Github, Stack Overflow, Reddit, Tumblr и OpsWorks product из Amazon Web Services, W3C (W3C Validator), а также является составной частью облачной платформы Red Hat OpenShift и балансировщиком по умолчанию в облачной платформе OpenStack.

Я уверен что у этих компаний есть свои дата-центры. Почему используется балансировка на L7? В своем дата-центре можно организовать балансировку на нижних уровнях OSI. Почему отдается предпочтение L7? Ведь теоритически L7 должен быть медленнее L3.

Понимаю что вопросы детские, но тема очень интересная. В теории боллее-менее подкован, а на практике просто даже негде попробовать.

Какие должны быть масштабы проекта, когда уже нужно задуматься о распределении нагрузки на несколько серверов?

Это вопрос прогнозирования. Если есть основания полагать что нагрузка в ближайшее время вырастет.

TDrive ★★★★★
()

Кратенько щаз отвечу. Потом, развернуто с компа отвечу.

Я возился балансировками nginx/haproxy довольно долго. Для меня выбор много маленьких серверов однозначно удобнее одного большого.

Балансировка на L7 уровне позволяет удобно управлять запросами ( например в случае nginx направлять на разные бекенды в зависимости от http-headers )

trofk ★★★
()
Ответ на: комментарий от trofk

Для меня выбор много маленьких серверов однозначно удобнее одного большого.

Но ведь тогда нужно полностью автоматизировать поднятие нового инстанса. Управление конфигами тоже должно быть только через Puppet/Ansible/etc. Уже не получится быстренько поправить конфиг на продакшене. Это же должно быть наоборот сложнее и неудобнее.

Понятно что автоматизация и так должна быть, просто с одним сервером можно автоматизировать только то, что часто делается или то, что лень делать руками.

Black_Roland ★★★★
() автор топика
Ответ на: комментарий от Black_Roland

если ты собираешься использовать балансировку (т.е иметь N одинаковых узлов), то без автоматизации поднятия нового узла - это полная бессмыслица.

Komintern ★★★★★
()
Ответ на: комментарий от Black_Roland

чем несколько узлов может быть удобнее одного.

настолько риторично, что прям не знаю что ответить.
новую версию приложения своего деплоишь ты допустим - а тушить сервис нельзя. а тут узел потушил - апдейт накатил. второй потушил - накатил. и т.д.

Komintern ★★★★★
()
Ответ на: комментарий от Komintern

новую версию приложения своего деплоишь ты допустим - а тушить сервис нельзя. а тут узел потушил - апдейт накатил. второй потушил - накатил. и т.д.

Смотря какое приложение. PHP-приложения можно деплоить без простоя (из-за миграций только возможно на секунду придется все приостановить).

узел потушил - апдейт накатил. второй потушил - накатил. и т.д.

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

Black_Roland ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.