LVS vs HAproxy vs NLB

lets the srach begins

69 Responses to LVS vs HAproxy

  1. KNTam:

    Ну, кто чем обмазывается, рассказывайте. Кстати, реквест best practice от наших адептов майкрософта.

  2. GibApp:

    Только F5, только Radware, только Citrix, только хардкор! Швабодка не пройдет!

  3. KNTam:

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

  4. Nared:

    : У F5 имеется русский саппорт в лице Шапы.

  5. GibApp:

    : бери Crescendo, там по русски говорят. В Radware, впрочем, тоже, и спецы весьма неплохие при этом.

  6. KNTam:

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

  7. GibApp:

    : вместо этого они вбухивают тонны денег на разработчиков и сисадминов. Для крупных сервис-провайдеров это может быть разумным в некоторых случаях, для всех остальных выйдет дороже (soho не рассматриваем).
    Впрочем, тебе со всем этим жить, ты и решай. Но я никогда не поверю в слова «Я могу купить всякие big–ip и всякую нешвабодку, но мне не хочется». Только если это слова фанатика, либо он нап**ел про «могу».

  8. YilLt:

    Есть и LVS, и HAproxy.
    NLB? Не, не слышал.
    С какой целью интересуетесь?

  9. KNTam:

    : Расскажи

  10. KNTam:

    : Да так, попиздеть просто

  11. Nared:

    : Я тебе по опыту скажу. Нормальная пачка балансеров с линупсом, умеющая прокачать через себе прилично rps — по деньгам на круг выйдет сравнимо с виприоном.
    Не забываем еще про необходимость человеческого L2 между всеми этими балансерами.

    Впрочем, по мне — пачка балансеров с линупсом выгоднее, ибо нету единой точки отказа, есть возможность блочной замены и расковыривать трафик можно на гораздо более глубоком уровне.

  12. KNTam:

    : У меня пока нет цели прокацивать через себя безумные rps, мне скорее нужно отсутствие единой точки отказа, ога

  13. Nared:

    : Если тебе нужно отсутствие единой точки — то тебе нужно минимум две железки big-ip 🙂

  14. KNTam:

    : kepalived, геораспределение пока не нужно

  15. Nared:

    : Я не знаю, что такое keepalived — судя по всему, какое-то кривое поделие 🙂

    Я говорил про то, что отсутствие единой точки отказа достигается всегда только дублированием оборудования. Минимум дублированием.

  16. KNTam:

    : keepalived — vrrp еболда для lvs. Есстественно все задублировано, да

  17. Nared:

    : Угу, я читал доку, когда пытался во все это играть.
    Потом подумал головой, плюнул, взял ucarp и перепилил архитектуру на попроще и понадежнее.

  18. KNTam:

    : Мне балансировка еще нужна, не просто же так вот это все

  19. KNTam:

    Я таки жду экспертов от майкрософт

  20. Nared:

    : Балансировка чего? Что у тебя на вход вливается?

    Есть подозрение, что в 90% случаев городить вот это все и рожь — не надо.

  21. KNTam:

    : > вместо этого они вбухивают тонны денег на разработчиков и сисадминов
    А вот с чего ты вот это вот взял?

  22. KNTam:

    : Какая разница что на входе, хоть http, хоть ftp, хоть mapi, lvs же tcp балансит, а что внутри — ему похеру. в 90% случаев.

  23. GibApp:

    : из опыта знаю. Кроме того, техника по OPEX’у всегда в итоге обойдется дешевле людей в итоге, даже если CAPEX выше в несколько десятков раз.

  24. KNTam:

    : Привет, кэп. Саппорт от вендора в OPEX посчитай. Они ломят конский прайс. Если этот прайс можно сэкономить (при равном sla у швабодкорешений и нешвабодкарешений) и вымутить себе премию, то почему бы и нет? Ктому же я то уже тут, и никаких лишних разработчиков/сисадминов при этом не нужно.

  25. AkaNo:

    А можно с радваре делать балансинг если все запросы идут с одного ip?
    И если да, то как?

  26. GibApp:

    : 15% от стоимости, как правило. А сколько ты заплатишь парочке инженеров за год? А если доработка нужна (читай — программист)?

  27. GibApp:

    под «ты» я имею в виду владельца бизнеса.

  28. Nared:

    : Это популярнейшее заблуждение.
    Почти всегда tcp балансить нинада. Надо http (ну, или что-то сессионное, похожее на http) — а это резко позволяет упростить систему.

  29. KNTam:

    : Ох вот тут ты не прав вот.

  30. Vansuper:

    А что такое HAProxy? Даже в педивикии гейской нет статьи про него.

  31. KNTam:

    : первая ссылка в гугле по запросу haproxy. Что там с nlb, виндузятник?

  32. Vansuper:

    : А чо в педивикии статьи то нет?

    С NLB всё ок! Не на LVS же Exchange кластеры строить, верно?

  33. KNTam:

    : Почему нет? LVS гораздо круче NLB, поэтому меня просят помочь с балансером.

  34. Nared:

    : История рассудит нас! ©

  35. Vansuper:

    : И что, неужто реально кластер Exchange поднять на LVS? Расскажи!

  36. KNTam:

    : В гугол сходи, там тысячи охуенных историй про это.

  37. Vansuper:

    : чото не нашёл

    Как можно поставить линуховую службу на винду ваще я не поэл?

  38. KNTam:

    : LVS раскидывает соединения на кучу экчейнджей. Проксирование tcp соединений, прозрачно для пользователя.
    Ищи lvs

  39. KNTam:

    : Вот схематичная картинка

    image

  40. GibApp:

    : т.е. LVS застрял где-то в эпохе хабов?

  41. KNTam:

    : Ты смищной. LVS в режиме DR застрял где-то на уровне L2.

  42. YilLt:

    : Да чо там рассказывать. Каждую неделю в зависимости от нагрузки и результатов «трудов» девелоперов меняем шедулер LVS (wlc-wrr и обратно), подкручиваем веса веб нод.
    Давным давно один из наших гениев напедалил клиент-серверную софтину которая в зависимости от загрузки ноды через ipvsadm динамически весами рулит — от оно и работает.

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

  43. KNTam:

    : persistence-ом балуетесь?

  44. YilLt:

    : Не, не юзаем. Сессии по NFS шарятся, а ни для чего больше persistent нам не пригождался ни разу.

  45. Vansuper:

    : Если честно я где-то слыхал что разрабы Exchange официально не рекомундуют NLB. ХАхаха. Забавно. Но exchange может глючить с NLB. Более того, последние 2 недели я три раза ездил на объект к заказчику именно из-за этой херни — NLB + Exchange = FUCKUP

  46. YtsZZ:

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

  47. KNTam:

    : мне для a/b нужно, но спасибо

  48. KNTam:

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

  49. KNTam:

    : вот поэтому меня и попросили помочь. Там еще ограничения какие-то на количество машин в кластере и т.д.

  50. YilLt:

    : Что есть a/b?
    У нас просто fair scheduling нужен, а с persistent не очень «fair» получается.

  51. YilLt:

    : Ну а какие задачи то стоят конкретно? Просто нагрузку балансировать, или как то с подвыподвертом?

  52. YilLt:

    : LVS — больше для балансировки. Если нужно HA — надо будет заморочиться с extra-checks. Слегка нетривиален в настройке (по сравнению с HAproxy.
    HAproxy — для high availability больше заточен, ну и балансировать умеет неплохо. Downside — работает в user-level, жрёт CPU при большом траффике, было замечено что иногда под нагрузкой затыкается и перестаёт балансировать.

  53. KNTam:

    : Балансировка, масштабируемость, failover

  54. YilLt:

    : А, ну ты ж вверху писал что «просто попиздеть», я и забыл 🙂

  55. KNTam:

    : эй, keepalived это vrrp для lvs, HA+LB, ок и нормулет, все по взрослому

  56. YilLt:

    :
    Если трафик предполагается небольшой (скажем, до 1000 одновременных коннектов на ноду) — бери HAproxy.
    Для реально больших нагрузок — я б рекомендовал LVS таки. Порог вхождения у него выше, и под конкретные задачи придётся додумывать своего немало (особенно для failover — heartbeat ещё покури), но на выходе получится как раз чонада. Стабильне, мжвячни, безотказне.

  57. KNTam:

    : fair с persistant кстати вполне получается, не понимаю в чем проблема

  58. KNTam:

    : посоны говорят heartbeat умер и плохо пахнет, и рекомендуют pacemaker.
    Таки загугли keepalived, я настаиваю, все уже давно придумано

  59. YilLt:

    : чота я не догнал вот этого: «keepalived это vrrp для lvs».
    LVS — это ж частный случай VRRP, не?

  60. KNTam:

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

  61. KNTam:

    : эээ, в каком месте lvs vrrp? ни в каком же! lvs он standalone, а инстансы keepalived как раз и юникастят друг-другу для HA lvs

  62. YilLt:

    : Ну как же!
    Вот возьмём ситуёвину:
    — пришёл 1.2.3.4 на сервис, все его запросы балансер кинул на node1;
    — пришли ещё клиенты, балансер их покидал на node2, node3 … nodeN;
    — 1.2.3.4 в это время колбасит запросами node1, приходит 4.3.2.1 — балансер его хуяк опять на node1 (ибо fair шедулинг — всем нодам поровну клиентов);
    Итог: 1.2.3.4 и 4.3.2.1 ебошат node1 тяжёлыми запросами, от остальных клиентов запросы лёгкие, другие ноды с ними справляются ок; node1 — под оверлоадом, остальные ноды — ок.
    На малом количестве нод (до 10) такое будет постоянно.
    Вырубаем persistent — и избегаем ситуации когда одна-две ноды загибаются под тяжёлыми запросами, а остальные в это время курят.

  63. YilLt:

    : Ух ты, спасибо за наводку на keepalived. А мы себе сами подобное написали, ппц.

  64. YilLt:

    : Всё-всё, то я не разобрамшись полез отвечать. Про keepalived почитал — всё сразу стало ясно.

  65. KNTam:

    : > На малом количестве нод
    Ну вот ты сам себе ответил
    Я такую ситуацию пока не рассматривал, для меня не актуальна, но как ты написал, да, проблема имеет место быть

  66. KNTam:

    : Ну хоть кому-то пост оказался полезным 🙂

  67. YilLt:

    : Про персистент — я вообще-то ХЗ, как ни прикидываю — получается что при любом кол-ве нод N в какой-то момент трафик достигнет объёма S, при котором какая-то часть нод будет перегружена, а какая-то — простаивать, в итоге будет performance degradation для тех клиентов, которые колбасят тяжёлые запросы.
    Хотя я со своей колокольни смотрю, тут надо смареть уже конкретно — какой именно трафик балансим.

Добавить комментарий