AlexKMK Feb 22 2019 at 17:08

Direct routing и балансировка с помощью NFT vs Nginx

6 min

Configuring Linux*Network technologies*

From sandbox

+15

Comments 14

ky0 Feb 22 2019 at 18:05

Ставить за нгинксом мамонтячий PHP и на этом мерять rps — ну такое.

kolu4iy Feb 22 2019 at 19:31

А я наоборот — спасибо скажу. За фронтом почти всегда кто-то мамонтячий, от того и балансируют. Конечно, обычно нужен https, но вот за nftables в подобном примере (да ещё и с тестами) — спасибо.

ky0 Feb 22 2019 at 19:45

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

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

AlexKMK Feb 24 2019 at 11:09

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

Сетевой стек не трогался вообще. Когда дойду до leastconn — буду крутить крутилки.

Manitou Feb 22 2019 at 19:54

Тема интересная, результаты любопытные, спасибо. Смущает только то, что статью Вы начали с упоминания IPVS, как классического средства L4 балансировки, но в тестах в пару к NFT почему-то решили поставить Nginx, хотя логичнее было бы сравнивать именно с IPVS. Всё таки задачи, которые решаются балансировкой на IPVS\NFT, принципиально отличаются от тех, в которых применяется Nginx\HAproxy\любой другой L7 балансировщик.

AlexKMK Feb 24 2019 at 11:08

Дело в том, что последний релиз ipvs был 7 лет назад, и на него забыли/забили. В наше время, обычно ставят nginx и не заморачиваются. NFT в данном случае — возможная альтернатива почившему ipvs.

slimlv Feb 26 2019 at 14:48

ipvs живее всех живых и отлично работает с DR с различными типами балансировки.
Гонять трафик через прокси в обе стороны глуповато в случае преобладания отдачи

rzerda Feb 22 2019 at 20:18

Популярным инструментом проброски пакетов был IPVS

Не был, а есть для тех, кто не может себе позволить XDP и прочие свежести в ядре. Джентельмены из Huawei даже притащили его в k8s, натурально устав ждать, пока изменения в iptables применятся в их кластерах на тысячу нод.

slimlv Feb 26 2019 at 16:36

Как Xdp может заменить ipvs если работает в пределах одного интерфейса?

rzerda Feb 26 2019 at 20:26

У меня прямо сейчас есть балансировщики на IPVS с одним интерфейсом (не считая lo), поэтому я не понял вопроса.

slimlv Feb 27 2019 at 15:36

Я быстро глянул презентацию по XDP — на сколько я понял схема распределения нагрузки выглядит так: рутер шлет трафик на все воркеры а XDP скидывает лишний. Это несколько… ммм… глупо?
Или есть другая схема?

rzerda Feb 27 2019 at 17:23

Я не очень в XDP, но в katran, по-моему, не так.

Но это всё не нужно подавляющему большинству. 10 Gbit двудульная карта стоит 250 долларов и обслуживается буквально человеком из интернета после прочтения двух статей.

slimlv Mar 3 2019 at 11:39

Спасибо за ссылку!

vadimfedorenko May 9 2020 at 14:18

Популярным инструментом проброски пакетов был IPVS. Он выполнял задачи балансировки через тоннель и Direct Routing.

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

Вот тут не совсем честно. У IPVS есть 3 метода доставки трафика до обслуживающих нод:

Gatewaying, он же Direct Routing — пересылка пакетов в пределах одного броадкаст сегмента.
Tunneling — туннелирование, работает в маршрутизируемых сетях, инкапсулирует пакеты в IPv4/IPv6.
Masquerading — классический DNAT.

Так вот обратный трафик идет через балансер только в случае Masquerading. В остальных двух случаях настройки на облуживающих нодах позволяют возвращать трафик клиенту без задействования балансировщика.

Show the best of all time