Компания NGINX (http://nginx.com/) перенесла (http://trac.nginx.org/nginx/changeset/61d7ae76647d/nginx) в кодовую базу свободного http-сервера nginx (http://nginx.org/) реализацию системы балансировки TCP-соединений (http://nginx.com/blog/nginx-plus-r6-released/#tcp-load-balan...), ранее поставляемой только в коммерческом продукте NGINX Plus. Новый балансировщик stream дополнил ранее доступные системы проксирования соединений с web- и почтовыми серверами.Stream в nginx реализует похожие на HAproxy средства балансировки произвольных TCP-соединений, дающие возможность (http://nginx.com/resources/admin-guide/tcp-load-balancing/) организовать проброс и распределение по нескольким узлам такого трафика, как обращения к СУБД, системам аутентификации, каталогам LDAP, RTMP-серверам, VoIP-системам или службам, применяющим SSL-шифрование. Предоставляется (http://nginx.org/en/docs/stream/ngx_stream_core_module.html) несколько методов балансировки: round-robin (круговой перебор, при котором соединения равномерно распределяются среди обработчиков), least-connections (соединение перенаправляется к серверу, у которого меньше активных соединений), least_time (перенаправление на сервер, демонстрирующий наиболее высокую отзывчивость) и hash (перенаправление на основе хэша от определённого пользователем параметра, например, IP). Для каждого сервера можно задавать максимальное число соединений и вес.
<center><a href="http://cdn.nginx.com/wp-content/uploads/2015/04/R6Blogvisual... src="http://www.opennet.me/opennews/pics_base/0_1429607536.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Кроме распределения нагрузки модуль stream также можно использоваться для создания отказоусточивых конфигураций. Присутствуют средства обеспечения высокой доступности - nginx на лету оценивает статус сервера-обработчика и на какое-то время исключает его из работы в случае выявления проблем. Доступны как пассивные (оценка сбоев соединения), так и активные (периодическая отправка специальных проверочных запросов и оценка корректности ответов) механизмы проверки работы серверов. Для только что запущенных новых серверов предусмотрена возможность медленного старта, когда нагрузка наращивается постепенно, давая возможность прогреть кэш. Имеется возможность назначения запасных серверов, обращение к которым будут осуществляться только в случае с проблем с основными серверами.URL: https://news.ycombinator.com/item?id=9408626
Новость: http://www.opennet.me/opennews/art.shtml?num=42076
Годнота
// Осталось 1.7.13/1.8 дождаться :)
1.8 уже дождались http://mailman.nginx.org/pipermail/nginx-announce/2015/00015...
В тот же день! http://www.opennet.me/opennews/art.shtml?num=42082
Хорошая новость, нужно попробовать на тестовом кластере, а потом можна и в прод =)
>на тестовом кластере, а потом можна и в прод =)Чем haproxy не устроил?
Устроил. Но хочется коробочное решение из nginx.
> коробочное решение из nginx.Тогда купи слона^W nginx plus...
>>Чем haproxy не устроил?Он есть просто хочется уменьшить количество прослоек
Зачем? unix way же!
> Зачем? unix way же!Администрировать клубок nginx 1.8+ _намного_ легче, чем два клубочка поменьше - haproxy + nginx 0.8.4. </Элементарно, Ватсон!>
> Администрировать клубок nginx 1.8+ _намного_ легче, чем два клубочка поменьше - haproxy
> + nginx 0.8.4. </Элементарно, Ватсон!>Митрофанушка рассказывает нам почему один клубок системды скушает кучу клубочков поменьше типа инит скриптов в каждой дырке и прочая :)
>> </Элементарно, Ватсон!>
> Митрофанушка рассказывает нам почему один клубок системды скушает кучу клубочков поменьше типа инит скриптов в каждой дырке и прочая :)Обнови броузер, не модно это, тэг пропустил. Митрофанов глумится над клубищами побольше и задравв-штаны-выбегабщими за ними и их разноцветными бусами. Над тобой тоже, вдруг ты не понял.
Клубочки побольше все желающие могут наблюдать в соведних новостях: про броузеры и "движки", умирающие один за одним под собственным весом и не имеюшие никакой поддержки безопасности н ив одном уважающем себя дистрибутиве. Судьбы Мира, печалька...
Я, конечно, от хайлоада последние пару лет далёк - но с каких пор этим стал заниматься веб-сервер?
> пор этим стал заниматься веб-сервер?Nginx всю жизнь был еще и реверс-прокси. В том числе и для почты, внезапно.
Ну так есть разница между проксёй и TCP-балансировщиком.
> Ну так есть разница между проксёй и TCP-балансировщиком.Nginx is an open source reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP
protocols, as well as a load balancer, HTTP cache, and a web server (origin server).Теперь в список поддерживаемых добавится еще один протокол - TCP.
Это, в общем-то, и из новости понятно. Непонятно на кой так чудить с TCP вместо DSR или хотя бы NAT-based решений. Ладно - HTTP - nginx его понимает и может много чего сделать. Но generic TCP?
> Непонятно на кой так чудить с TCP вместо DSR или хотя бы NAT-based решений.
> Ладно - HTTP - nginx его понимает и может много чего сделать.
> Но generic TCP?1) NAT-based решения не могут делать всего того, что умеет делать nginx:
http://nginx.com/blog/nginx-plus-r6-released/#tcp-load-balan...2) Удобно использовать только nginx для всех задач,
не добавляя при этом лишних сущностей в виде stunnel или haproxy.
> NAT-based решения не могут делать всего того, что умеет делать nginxНе уверен, что iptables слабее в части руления трафика.
> Удобно использовать только nginx для всех задач
Угу, только в комбайнах потом эпичные дыры находятся, даром чтоли openssl так резать активно начали.
> Теперь в список поддерживаемых добавится еще один протокол - TCP.
Еще один был бы ftp, а tcp это транспорт для всего перечисленного, то есть теперь обработка работает на другом уровне, и это рождает вполне закономерный вопрос - зачем http серверу функционал руления транспортным протоколом, таким макаром и до nginxOS можно дописаться.
nginx хорош своей легковестностью, тяжелый и мутный апач уже существует, но не получится ли в итоге тяжелого и мутного nginx'a.
>> NAT-based решения не могут делать всего того, что умеет делать nginx
> Не уверен, что iptables слабее в части руления трафика.А пойти по ссылке и почитать - лень или мешает незнание английского языка?
>> Удобно использовать только nginx для всех задач
> Угу, только в комбайнах потом эпичные дыры находятся,
> даром чтоли openssl так резать активно начали.Готов выслушать предложения о том, как нам обустроить kernel и glibc.
GNU Hurd не предлагать. :)>> Теперь в список поддерживаемых добавится еще один протокол - TCP.
> Еще один был бы ftp, а tcp это транспорт для всего перечисленного,
> то есть теперь обработка работает на другом уровне,TCP - это протокол. И в nginx он рассматривается именно в этом аспекте.
А какого именно уровня этот протокол L7 или L4 - вопрос второстепенный.> и это рождает вполне закономерный вопрос
> - зачем http серверу функционал руления транспортным протоколом1) nginx - это не только http сервер
2) я на этот вопрос уже очень подробно ответил
3) "руление транспортным протоколом" - этим занимается ядро OS.> таким макаром и до nginxOS можно дописаться.
facepalm.jpg
> nginx хорош своей легковестностью, тяжелый и мутный апач уже существует,
> но не получится ли в итоге тяжелого и мутного nginx'a.не получится.
> пойти по ссылкеНезачем, не собираюсь юзать, даже рассматривать теоритическую возможность такой сети, возить дрова на каене идиотизм.
> Готов выслушать предложения
Предложений нет, есть озвученное опасение.
> L7 или L4 - вопрос второстепенный.
Тут уже была новость о хттп в который через pcap завернут езернет.
Общность не прощупывается?
>facepalm.jpg
Сарказм не распознаем, хотя в свете предыдущего факта весьма в тему.
>не получится
Да ладно, было бы желание.
Щас наворотят всяких плагинов, а потом будут голову ломать как бы так добавить , чтото чтобы не поломать, это и рождает костыли.
Имхо было бы правильнее софт свич сделать отдельно, а не использовать хттп сервер. Поиому чио nginx это http сервер, это факт. А то что он умеет, это второстепенно
> не собираюсь юзать, даже рассматривать теоритическую возможностьВ таком случае, есть ли смысл давать разработчикам nginx
ценные указания о том, как им следует правильно поступить?>> Готов выслушать предложения
> Предложений нет, есть озвученное опасение.Все будет хорошо.
>> L7 или L4 - вопрос второстепенный.
> Тут уже была новость о хттп в который через pcap завернут езернет.
> Общность не прощупывается?
Да не было указаний, был намек на то, что нжинкс все меньше хттп сервер и все больше непонятно что.Да, я исповедую юниксвей и не испытываю оптимизма по поводу подобных извращений, но пока еще цветочки, может здравый смысл победит и они сделают хттп сервер плагином к своему софтсвичу или может это не логично?
> Да не было указаний, был намек на то, что нжинкс все меньше
> хттп сервер и все больше непонятно что.Если что-то не понятно - есть документация: http://nginx.org/en/docs/
HTTP сервер он только для статики. Есть попытки использовать его в качестве веб-сервера
для динамики, но ngx_http_perl_module экспериментальный, а ngx_lua - сторонний модуль.В новой версии в nginx будет встроен собственный интерпретатор javascript:
http://www.infoworld.com/article/2838008/javascript/nginx-ha...> Да, я исповедую юниксвей
А что такое "исповедовать юниксвей" ?
Вот например, perl - это юниксвей или нет?
А sed+awk+grep+sh - это больший юниксвей чем perl?А Emacs или vim - это тоже "юниксвей" или уже нет?
> и не испытываю оптимизма по поводу подобных извращений,
точно так же думали и инквизиторы в средневековье, - что они делают благое дело.
> но пока еще цветочки, может здравый смысл победит и они сделают
> хттп сервер плагином к своему софтсвичу или может это не логично?Линус Торвальдс тоже все делает неправильно и у него нет здравого смысла?
> Если что-то не понятно - есть документация: http://nginx.org/en/docs/Там и ru/docs есть))
> HTTP сервер он только для статики. Есть попытки использовать его в качестве
> веб-сервера
> для динамики, но ngx_http_perl_module экспериментальный, а ngx_lua - сторонний модуль.а fastcgi это что? только не надо говорить, что прокся, если настолько издали смотреть, то все прокся.
> В новой версии в nginx будет встроен собственный интерпретатор javascript:
> http://www.infoworld.com/article/2838008/javascript/nginx-ha...ну-ну. Нет я за js, я в нем одном вижу потенциал в отличии от всях перлов-пхпов-рубей-и-питонов, но нынешние движки тяжеловаты.
> А что такое "исповедовать юниксвей" ?
Вопрос риторический, но лично для меня эталон - это grep.
> точно так же думали и инквизиторы в средневековье, - что они делают
> благое дело.И что в этом плохого? не в инквизиторах, а в стремлении к благу
>> Если что-то не понятно - есть документация: http://nginx.org/en/docs/
> Там и ru/docs есть))В ru/docs может быть устаревшая или не полная информация.
>> HTTP сервер он только для статики. Есть попытки использовать его в качестве
>> веб-сервера для динамики, но ngx_http_perl_module экспериментальный,
>> а ngx_lua - сторонний модуль.
> а fastcgi это что? только не надо говорить, что прокся,
> если настолько издали смотреть, то все прокся."The ngx_http_fastcgi_module module allows passing requests to a FastCGI server".
client -> nginx -> FastCGI server
client -> nginx -> http backend
nginx - это reverse proxy, а не forward proxy, как например, squid.
>> А что такое "исповедовать юниксвей" ?
> Вопрос риторический, но лично для меня эталон - это grep.Если говорить про UNIX-way, то есть очень толковая книжка на эту тему:
The Art of Unix Programming http://www.catb.org/esr/writings/taoup/html/
И nginx всем правилам из этой классической книги полностью соответствует.>> точно так же думали и инквизиторы в средневековье,
>> - что они делают благое дело.
> И что в этом плохого? не в инквизиторах, а в стремлении к благуБлагими намерениями вымощена дорога в ад.
В случае с инквизицией - проблема была в том, что они пытались действовать
далеко за пределами своего уровня компетенции, силой навязывая другим людям
свое представление о том, что те должны думать, как должны поступать и т.п.Классический пример - запрет думать и говорить о том, что земля круглая,
и что она не является центром вселенной и что она вращается вокруг солнца.А тех кто думал и говорил иначе - сжигали на кострах или другим способом убивали.
И что самое интересное, инквизиторы при этом думали что делают благое и богоугодное дело.Потому что по их мнению только они исповедовали правильную веру,
а все кто думал иначе - это были еретики, вероотступники и агенты дьявола.
> nginx - это reverse proxy, а не forward proxy, как например, squid.Я в курсе)). Если открыть любую википедию из числа дистрибутивных или почитать описание пакета, то там будет написанно, что это http-сервер, и это первично, а прокси фукционал уже вторично, вы можете считать иначе, это из разряда полу- пустого/полного стакана.
> Благими намерениями вымощена дорога в ад.
Всегда так было.
> В случае с инквизицией - проблема была в том, что они пытались
Но это не повод не пытаться, в то время покупалось и продавалось все, включая людей, и кровожадных князьков хватало и упоротых которые верили в чудо омовения в крови девственниц.
Да, перегнули палку, сильно перегнули. Но граница дозволенного не определима, как и граница достаточного.В какой момент можно сказать, что программа готова, или машина; или хлеб, ваша бабушка готовила его так, а моя иначе, и ваш хлеб для папуаса африканского совсем не хлеб может быть.
Глобализация стирает границы, стирает разницу, обостряя проблемы, то что пишется, то что удобно для меня или кого-то сейчас, завтра станет непонятной мутью, которая едва делает то, что надо не глюкая. А теперь задачка - определить на каком участке от "ничего" до "нахрена так наворочено" находится тот же nginx, или ядро линухи, или что угодно другое.
Когда-то я пользовался апачем, но с каждым релизом он жрал все больше, а работал все медленее, медленее потому, что периодически cgi ронял его в сегфол, сначало редко, а потом на каждом втором запросе, да не вопрос я мог бы найти косяк, но зачем мне эта ерунда с левыми пакетами на предприятии, или сменить дистр, но это лишь отсрочка, поэтому апач был выпилен со всеми своими проблемами нахрен, и nginx заменил его на долгие годы. Так вот, а не пора ли искать что-то на замену ему, или покрайней мере начинать свыкаться с мыслью, что однажды придется. Вопрос риторический.
Но читая новости о успехах нжинкса меня не покидает чувство дисбаланса, с одной стороны нафига все это надо в хттп сервере, а с другой нахрена хттп сервер в таком прикольном разруливателе потоков и соединений, будь это отдельная либа я бы нашел ей применение, а как отдельный продукт в нынешнем виде его ниша довольно узка.Вы можете не согласиться. Однако, ИМХО, ipv4 современных нагрузок не тянет, ipv6 тоже не назвать идеалом, а дальше по наклонной ком проблем растет, и их пытаются решить и те и эти, но как-то вяло и не там, потому что кризис и на глобальные разработки денег нет, а там пожар, а там война, ну и имеем то, что имеем.
> Если открыть любую википедию из числа дистрибутивных или почитать
> описание пакета, то там будет написанно, что это http-сервер, и это
> первично, а прокси фукционал уже вторичноNginx is an open source reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP
protocols, as well as a load balancer, HTTP cache, and a web server (origin server).
- https://en.wikipedia.org/wiki/Nginxфункциональнось "web server" стоит на последнем месте.
> апач был выпилен со всеми своими проблемами нахрен,
> и nginx заменил его на долгие годы. Так вот, а не
> пора ли искать что-то на замену ему, или покрайней мере начинать
> свыкаться с мыслью, что однажды придется. Вопрос риторический.Не вижу причин менять nginx на что-то иное,
с каждой новой версией он становится все лучше и лучше.Как например, и ядро линукса. Хотя и в том и в другом случае
- количество строк кода увеличивается, функциональность и сложность тоже растет.для исповедующих unix-way в сети доступны первые версии юникса:
http://minnie.tuhs.org/cgi-bin/utree.pl - можно их скачать и пользоваться ими.
или - первыми версиями линукса https://www.kernel.org/pub/linux/kernel/Historic/и точно так же можно устроить флейм по поводу того, что BTRFS - это не unix way,
потому что смешивает в одном коде и менеджер томов и собственно файловую систему.
должен быть отдельный менеджер томов LVM и отдельно - файловая система ext4 или XFS.> ИМХО, ipv4 современных нагрузок не тянет,
У ipv4 есть всего один фатальный недостаток - закончились свободные IP-адреса.
>> апач был выпилен со всеми своими проблемами нахрен,
>> и nginx заменил его на долгие годы. Так вот, а неНе знаю, кого у вас там выпилил nginx и где. Разве что в мечтах...
http://news.netcraft.com/archives/2015/04/20/april-2015-web-...
И это ещё с учётом того, что добрая доля nginx в сети - фронтенды к тому же апачу.
> функциональнось "web server" стоит на последнем месте.https://ru.wikipedia.org/wiki/Nginx
nginx (англ. engine x) (по-русски произносится как э́нжин-э́кс[5] или э́нжин-и́кс[6]) — веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системахhttps://cs.wikipedia.org/wiki/Nginx
Nginx (čtěte jako "engin-x") je softwarový webový server a reverzní proxy s otevřeným zdrojovým kódem. Pracuje s protokoly HTTPЛадно проехали,
> Не вижу причин менять nginx на что-то иное,
> с каждой новой версией он становится все лучше и лучше.Господи, да не надо менять, надо разделить, мухи отдельно, хттп сервер отдельно, АПИ посередине и = счастье.
> для исповедующих unix-way в сети доступны первые версии юникса:
Торвальдс делает абсолютно правильно, мало того, что модули, так еще и на уровне компиляции можно функционал выпилить, имея относительно удобную конфигурилку.
> и точно так же можно устроить флейм по поводу того, что BTRFS
Можно.
>> ИМХО, ipv4 современных нагрузок не тянет,
> У ipv4 есть всего один фатальный недостаток - закончились свободные IP-адреса.Собственно это не его недостаток, а дибильная политика раздавания огромных пулов всем подряд, дабы экономить на НАТе, + дибильная политика - каждому корпорасту по стандарту, иначе давно бы уже нормальную автопробрасывалку портов бы придумали, но увы.
>> Не вижу причин менять nginx на что-то иное,
>> с каждой новой версией он становится все лучше и лучше.
> Господи, да не надо менять, надо разделить,
> мухи отдельно, хттп сервер отдельно, АПИ посередине и = счастье.Кому это надо? Исповедующим unix-way? Могу предложить только http://button.dekel.ru/
> Торвальдс делает абсолютно правильно, мало того, что модули, так еще и на
> уровне компиляции можно функционал выпилить, имея относительно удобную конфигурилку.Файловая система BTRFS грубо нарушает unix-way. Разве там не надо ничего исправить?
nginx - это один из веб-серверов, которых десятки, если не сотни,
и если nginx нарушает unix-way - можно просто прекратить им пользоваться
и взять другой, более правильный с идеологической точки зрения веб-сервер.А вот с ядром ситуация совершенно иная, и там нарушение unix-way гораздо более опасно,
потому что они портят ядро, котороее общее для всех, и просто так взять и поменять ядро
на другой линукс - не получится. И что в таком случае будут делать исповедующие unix-way?
У меня кожа не дымится когда не униксвей на серверах крутится, но это большой минус тому ПО и по возможности оно выпиливается.> А вот с ядром ситуация совершенно иная,
Точно такая же, я когда по молодости программированием активно занимался, меня тоже на всякие "улучшения" тянуло, как результат код состоял почти весь из этих улучшений, и иногда даже работал, но поиск проблем был кошмаром.
> Разве там не надо ничего исправить?
Нет, нужно просто закопать.
> Кому это надо?
Вы удивитесь, но это надо всем. Насколько стало проще когда железной волей запретили производителям иметь тысячи несовместих разъемов для зарядных устроиств, насколько станет проще, когда любой компонет можно будет заменить.
Юниксвей это путь к тотальной стандартизации, да многие связки работают быстрее когда заточены друг под друга, но в большенстве случаев это проблемы архитектуры, потому, что когда вы строите дом, а у вас выходит что балка должна быть меньше обычной, а нагрузку нести большую, значит вы плохой архитектор.
Это абсолютно примитивная и железобетонная логика, вы никогда не найдете в ней изъяна.
>>> надо разделить, мухи отдельно, хттп сервер отдельно, АПИ посередине и = счастье.
>> Кому это надо?
> Вы удивитесь, но это надо всем.Зачем?
> насколько станет проще, когда любой компонет можно будет заменить.
GNU Hurd пилят до сих пор. И какой-то особой простоты там не наблюдается, скорее наоборот.
> Юниксвей это путь к тотальной стандартизации
> Щас наворотят всяких плагинов, а потом будут голову ломать как бы так
> добавить , чтото чтобы не поломать, это и рождает костыли.
> хттп сервер. Поиому чио nginx это http сервер, это факт.
> А то что он умеет, это второстепенноНеа, реальность сурова. Для большинства применений nginx - это в первую очередь прокси+балансировщик, а функции http-сервера у него годны разве что для статики. Такая вот хитрая ниша. Поэтому и развивают то, в чём оный силён.
Почему же только статики, отлично он работает с фастцги, и др, хотя их не проверял, но апач уже лет 7 как выбросил, и всякие вэбморды - апачстайл в нжинксе вполне фурычат без допилов, обидно будет если сломают легковестность и простоту всякими балансировщиками, которые может и нужны на многих серверах, но не многим.
>> отлично он работает с фастцгитак он же reverse proxy и балансировщик для fastcgi
fastcgi_pass localhost:9000;
> будет если сломают легковестность и простоту всякими балансировщиками,По логике вещей, TCP-прокси делается из HTTP-прокси чуть ли не обрубанием HTTP :)
А nginx->fcgi это суть та же прокся.
> А nginx->fcgi это суть та же прокся.Согласен, но тогда любой хттп-сервер прокся для того, что генерит контент.
Идея встраемого/отдельного мультипротокольного балансировщика зависла уже давненько, есть конечно всякие имплементации ssl-ориентированные и простые, но какие-то они карявые.
> Согласен, но тогда любой хттп-сервер прокся для того, что генерит контент.apache+mod_php - тоже прокся? apache+mod_perl? apache+phusion passenger? tomcat? jboss web? node.js?
Для ликбеза: "прокся" - это по сути то, что принимает запрос, и дальше его через другой сетевой сокет отдаёт следующему обработчику где-то там. Через какой конкретно тип сокета - unix/tcp/whatever - не важно. Если сокета между фронтендом и собственно обработчиком нет, и они тесно интегрированы (форк/пайпы/прочие IPC - не суть) - это уже не прокся.
Т.е. FastCGI/FPM - прокси-стайл, CGI - нет... Различие именно в наличии сокета, а не пайпа.
> apache+mod_phpТормознутое извращение))
> Для ликбеза
а чем пайп отличается от сокета? файловый дескриптор и файловый дескриптор, через netcat можно одно завернуть в другое, а другое в первое, я недавно консоль управления повесил тем, что забыв отлючить эхо на ком-порту закольцевал управление.
По современным меркам отделять проксю от не прокси дурная работа, сейчас даже чиновники используют этот термин в отношение межведомственного документооборота.
У NAT-based решений есть одна большая проблема: они также требуют возвращать весь трафик через конкретный балансировщик, а поскольку адрес источника трафика не подменяется - балансировщик в итоге может быть только один... Определенными костылями это, конечно, решается (либо MAC-based возврат, либо синхронные таблицы между балансировщиками), но усложнение всей системы при этом колоссальное, и того не стоит.
Не совсем понял проблему, но в любом случае - я не говорил, что NAT-based - это идеально. По уму - DSR в помощь. Но если уж хочется через себя поток тянуть - логично хотя бы вюзерспейс его вытаскивать по минимуму.
DSR не всегда хорош. Иногда на балансере удобно кое-какую статистику считать попутно.
> Ну так есть разница между проксёй и TCP-балансировщиком.А в чем такая уж принципиальная разница, по большому счету?
В Nginx отличная низкоуровневая инфраструктура для эфективной работы с памятью, сетевыми соединениями, файлами, DNS и прочим. Поверх этой инфраструктуры строится отличный Web-сервер. Грех не использовать готовую инфраструктуру для чего-нибудь еще :)
этот функционал был ВСЕГДА доступен через модуль
https://github.com/yaoweibin/nginx_tcp_proxy_module\
не благодарите ...
> этот функционал был ВСЕГДА доступен через модуль
> https://github.com/yaoweibin/nginx_tcp_proxy_module\как правило у сторонних модулей гораздо хуже качество,
чем у кода из состава nginx core от разработчиков nginx
Пользуемся этим модулем уже давно, он работает, нормально работает. Точно так же как и китайский модуль для sticky, работает, just works, что еще надо?
> Пользуемся этим модулем уже давно, он работает, нормально работает.
> Точно так же как и китайский модуль для sticky, работает,
> just works, что еще надо?Если все устраивает - пользуйтесь на здоровье, никто ж не против.
Но в большинстве случаев сторонние модули к nginx кривые и глючные.
Подробнее об этом: http://habrahabr.ru/post/195742/#comment_6797402
заброщеный и год не троганый ? там правда исправляются ошибки ?
Китайский модуль это как китайские айфоны.
Супер! Отличная новость. Обязательно опробую на продакшене!
Начиная с какой версии это будет?
> Начиная с какой версии это будет?http://trac.nginx.org/nginx/roadmap
Балансировщих будет в 1.9.0 в ближайшее время.
Но никто не мешает скачать исходники уже сейчас.http://mailman.nginx.org/pipermail/nginx-ru/2015-April/05578...
хмм, ключевая фича tcp haproxy - splice, а тут его на первый взгляд -нет
Баналансить можно было и в PF и поди в иптаблес, вообще ядреная реализация.
> Баналансить можно было и в PF и поди в иптаблес, вообще ядреная
> реализация.А как насчёт двух и более балансеров с возможностью получить IP клиента для бэкэнда?
DST NAT решает проблему: на сервер от балансера придут пакеты с IP клиента.
> DST NAT решает проблему: на сервер от балансера придут пакеты с IP
> клиента.Угу. А назад как будем возвращать? Клиент-то назад ждёт IP балансера, а не сервера. Соответственно - коннтрекинг. А чтобы коннтрекинг работал - надо трафик вернуть в конкретный балансер. А IP балансера у сервера нетути, "пакет пришёл с IP клиента". В этом и проблема.
Можно, конечно, извернуться, вешая на серверы IP per balancer, и делая, например, PBR по локальному IP в обратную сторону. Или по MAC балансера приписывать трек и возвращать через PBR по треку. Но всё это из разряда извращений.
>> DST NAT решает проблему: на сервер от балансера придут пакеты с IP
>> клиента.
> Угу. А назад как будем возвращать? Клиент-то назад ждёт IP балансера, а
> не сервера. Соответственно - коннтрекинг. А чтобы коннтрекинг работал - надо
> трафик вернуть в конкретный балансер. А IP балансера у сервера нетути,
> "пакет пришёл с IP клиента". В этом и проблема.Если балансер один то он может быть роутером по дефолту для серверов.
Если балансеров много то можно через ARP анонсить мак балансера как носителя ip src клиента или пользоваться чем то вроде RIP.
Идея с уникальным IP на сервере для каждого отдельного балансера пожалуй лучше, дополнительно придётся привязать отдельную таблицу маршрутизации к слушающим на разных адресах сокетам, вроде nginx такое умел (FIB).
> Если балансер один то он может быть роутером по дефолту для серверов.Выше уже писал. Случай не рассматривается - слишком плохой. Балансер превращается в SPOF.
> Если балансеров много то можно через ARP анонсить мак балансера как носителя
> ip src клиентаЭто, простите, как? Один и тот же IP может запросто входить через все балансеры, причём даже одновременно.
> Идея с уникальным IP на сервере для каждого отдельного балансера пожалуй лучше,
> дополнительно придётся привязать отдельную таблицу маршрутизации к слушающим на разных
> адресах сокетам, вроде nginx такое умел (FIB).Угу. В линухах это делается легко и просто, и даже к сокетам ничего привязывать не надо (просто PBR по srcip). Но всё равно - из разряда извращений.
Неплохая замена haproxy, кстати. С учётом send/expect - вообще шикарно.
