fox_m Опубликовано 23 мая, 2022 · Жалоба Всем привет! Подскажите, есть у LVS/IPVS какой-то встроенный механизм мониторинга бэкэндов и вывода их из пула, есть что-то не так? Если, нет, то есть какое-то внешнее решение? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 24 мая, 2022 · Жалоба В общем нашел. ldirectord называется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rover-lt Опубликовано 11 июня, 2022 · Жалоба haproxy, если балансировать только tcp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 11 июня, 2022 · Жалоба @fox_m а какая у него вообще сфера применения? почему не nginx/haproxy? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 11 июня, 2022 · Жалоба почитал немного, в режиме nat выглядит как недо-haproxy, затянутый в ядро (недо- потому, что требует ldirectord); в режиме dr работает только в пределах l2 сегмента сети; в режиме tun слишком много телодвижений. ИМХО не так уж много случаев, когда оно нужно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 21 июня, 2022 · Жалоба В 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/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 22 июня, 2022 · Жалоба @fox_m да я понял как оно работает. но nginx (haproxy, etc по вкусу) даёт больше взможностей. можно добавить http-заголовок с изначальным ip клиента. можно завернуть http в https (или голый tcp в tls). если апстрим, на который изначально ушёл запрос, лёг, то этот же запрос уйдёт на другой апстрим. и т. п. да, ipvs теоретически должен быть производительнее. но я пока не упирался в производительность nginx в роли тупого балансировщика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 23 июня, 2022 · Жалоба В 23.06.2022 в 01:56, edo сказал: @fox_m да я понял как оно работает. но nginx (haproxy, etc по вкусу) даёт больше взможностей. можно добавить http-заголовок с изначальным ip клиента. можно завернуть http в https (или голый tcp в tls). если апстрим, на который изначально ушёл запрос, лёг, то этот же запрос уйдёт на другой апстрим. и т. п. да, ipvs теоретически должен быть производительнее. но я пока не упирался в производительность nginx в роли тупого балансировщика. Кстати можно комбинировать ipvs+nginx т.е строить иерархию. Но это больше к highload относится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...