Перейти к содержимому
Калькуляторы

LVS/IPVS балансировщик и мониторинг узлов

Всем привет!

 

Подскажите, есть у LVS/IPVS какой-то встроенный механизм мониторинга бэкэндов и вывода их из пула, есть что-то не так? Если, нет, то есть какое-то внешнее решение?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

haproxy, если балансировать только tcp

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@fox_m а какая у него вообще сфера применения? почему не nginx/haproxy?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

почитал немного,

  • в режиме nat выглядит как недо-haproxy, затянутый в ядро (недо- потому, что требует ldirectord);
  • в режиме dr работает только в пределах l2 сегмента сети;
  • в режиме tun слишком много телодвижений.

ИМХО не так уж много случаев, когда оно нужно

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 11.06.2022 в 13:41, edo сказал:

@fox_m а какая у него вообще сфера применения? почему не nginx/haproxy?

У IPVS есть несколько преимуществ. Во-первых, в режиме DR (direct respond) backend сервер отвечает клиенту напрямую, минуя балансировщик. Как результат, балансер нагружается несильно. Только входящий трафик. Во-вторых, он поддерживает алгоритм maglev от Гугла, который направляет клиента к конкретному backend'у независимо от того, на какой балансер он пришел

 

В 11.06.2022 в 15:05, edo сказал:

почитал немного,

  • в режиме nat выглядит как недо-haproxy, затянутый в ядро (недо- потому, что требует ldirectord);
  • в режиме dr работает только в пределах l2 сегмента сети;
  • в режиме tun слишком много телодвижений.

ИМХО не так уж много случаев, когда оно нужно

tun настраивается легко. Ненамного сложнее nat. И в этом режиме от как раз позволяет уйти от L2 сегмента, в случае DR. Вот тут отличное объяснение https://debugged.it/blog/ipvs-the-linux-load-balancer/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@fox_m  да я понял как оно работает.

но nginx (haproxy, etc по вкусу) даёт больше взможностей. можно добавить http-заголовок с изначальным ip клиента. можно завернуть http в https (или голый tcp в tls). если апстрим, на который изначально ушёл запрос, лёг, то этот же запрос уйдёт на другой апстрим. и т. п.

да, ipvs теоретически должен быть производительнее. но я пока не упирался в производительность nginx в роли тупого балансировщика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 23.06.2022 в 01:56, edo сказал:

@fox_m  да я понял как оно работает.

но nginx (haproxy, etc по вкусу) даёт больше взможностей. можно добавить http-заголовок с изначальным ip клиента. можно завернуть http в https (или голый tcp в tls). если апстрим, на который изначально ушёл запрос, лёг, то этот же запрос уйдёт на другой апстрим. и т. п.

да, ipvs теоретически должен быть производительнее. но я пока не упирался в производительность nginx в роли тупого балансировщика.

Кстати можно комбинировать ipvs+nginx т.е строить иерархию. Но это больше к highload относится. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.