URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 102178
[ Назад ]

Исходное сообщение
"Для nginx подготовлен балансировщик TCP-соединений"

Отправлено opennews , 21-Апр-15 12:52 
Компания 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


Содержание

Сообщения в этом обсуждении
"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено mva , 21-Апр-15 12:52 
Годнота
// Осталось 1.7.13/1.8 дождаться :)

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено shadow , 21-Апр-15 18:30 
1.8 уже дождались http://mailman.nginx.org/pipermail/nginx-announce/2015/00015...

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено CSRedRat , 22-Апр-15 08:05 
В тот же день! http://www.opennet.me/opennews/art.shtml?num=42082

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено rachok , 21-Апр-15 12:55 

Хорошая новость, нужно попробовать на тестовом кластере, а потом можна и в прод =)

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Andrey Mitrofanov , 21-Апр-15 13:14 
>на тестовом кластере, а потом можна и в прод =)

Чем haproxy не устроил?


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Anonnn , 21-Апр-15 13:23 
Устроил. Но хочется коробочное решение из nginx.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 22-Апр-15 07:41 
> коробочное решение из nginx.

Тогда купи слона^W nginx plus...


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено rachok , 22-Апр-15 13:25 
>>Чем haproxy не устроил?

Он есть просто хочется уменьшить количество прослоек


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 23-Апр-15 08:17 
Зачем? unix way же!

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Andrey Mitrofanov , 23-Апр-15 10:50 
> Зачем? unix way же!

Администрировать клубок nginx 1.8+ _намного_ легче, чем два клубочка поменьше - haproxy + nginx 0.8.4. </Элементарно, Ватсон!>


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 24-Апр-15 10:18 
> Администрировать клубок nginx 1.8+ _намного_ легче, чем два клубочка поменьше - haproxy
> + nginx 0.8.4. </Элементарно, Ватсон!>

Митрофанушка рассказывает нам почему один клубок системды скушает кучу клубочков поменьше типа инит скриптов в каждой дырке и прочая :)


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Andrey Mitrofanov , 24-Апр-15 10:45 
>> </Элементарно, Ватсон!>
> Митрофанушка рассказывает нам почему один клубок системды скушает кучу клубочков поменьше типа инит скриптов в каждой дырке и прочая :)

Обнови броузер, не модно это, тэг пропустил. Митрофанов глумится над клубищами побольше и задравв-штаны-выбегабщими за ними и их разноцветными бусами. Над тобой тоже, вдруг ты не понял.

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


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Crazy Alex , 21-Апр-15 14:32 
Я, конечно, от хайлоада последние пару лет далёк - но с каких пор этим стал заниматься веб-сервер?

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 21-Апр-15 15:13 
> пор этим стал заниматься веб-сервер?

Nginx всю жизнь был еще и реверс-прокси. В том числе и для почты, внезапно.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Crazy Alex , 21-Апр-15 17:11 
Ну так есть разница между проксёй и TCP-балансировщиком.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 21-Апр-15 18:05 
> Ну так есть разница между проксёй и 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.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Crazy Alex , 21-Апр-15 20:59 
Это, в общем-то, и из новости понятно. Непонятно на кой так чудить с TCP вместо DSR или хотя бы NAT-based решений. Ладно - HTTP - nginx его понимает и может много чего сделать. Но generic TCP?

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 21-Апр-15 21:35 
> Непонятно на кой так чудить с 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.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 22-Апр-15 01:29 
> NAT-based решения не могут делать всего того, что умеет делать nginx

Не уверен, что iptables слабее в части руления трафика.

> Удобно использовать только nginx для всех задач

Угу, только в комбайнах потом эпичные дыры находятся, даром чтоли openssl так резать активно начали.

> Теперь в список поддерживаемых добавится еще один протокол - TCP.

Еще один был бы ftp, а tcp это транспорт для всего перечисленного, то есть теперь обработка работает на другом уровне, и это рождает вполне закономерный вопрос - зачем http серверу функционал руления транспортным протоколом, таким макаром и до nginxOS можно дописаться.

nginx хорош своей легковестностью, тяжелый и мутный апач уже существует, но не получится ли в итоге тяжелого и мутного nginx'a.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 22-Апр-15 01:59 
>> 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.

не получится.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 22-Апр-15 04:58 
> пойти по ссылке

Незачем, не собираюсь юзать, даже рассматривать теоритическую возможность такой сети, возить дрова на каене идиотизм.

> Готов выслушать предложения

Предложений нет, есть озвученное опасение.

> L7 или L4 - вопрос второстепенный.

Тут уже была новость о хттп в который через pcap завернут езернет.

Общность не прощупывается?

>facepalm.jpg

Сарказм не распознаем, хотя в свете предыдущего факта весьма в тему.

>не получится

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


Имхо  было бы правильнее софт свич сделать отдельно, а не использовать хттп сервер. Поиому чио nginx  это http сервер, это факт. А то что он умеет, это второстепенно


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 22-Апр-15 05:12 
> не собираюсь юзать, даже рассматривать теоритическую возможность

В таком случае, есть ли смысл давать разработчикам nginx
ценные указания о том, как им следует правильно поступить?

>> Готов выслушать предложения
> Предложений нет, есть озвученное опасение.

Все будет хорошо.

>> L7 или L4 - вопрос второстепенный.
> Тут уже была новость о хттп в который через pcap завернут езернет.
> Общность не прощупывается?

https://www.youtube.com/watch?v=h0jB5dB3gNo


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 22-Апр-15 12:39 
Да не было указаний, был намек на то, что нжинкс все меньше хттп сервер и все больше непонятно что.

Да, я исповедую юниксвей и не испытываю оптимизма по поводу подобных извращений, но пока еще цветочки, может здравый смысл победит и они сделают хттп сервер плагином к своему софтсвичу или может это не логично?


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 22-Апр-15 15:34 
> Да не было указаний, был намек на то, что нжинкс все меньше
> хттп сервер и все больше непонятно что.

Если что-то не понятно - есть документация: 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 - это тоже "юниксвей" или уже нет?

> и не испытываю оптимизма по поводу подобных извращений,

точно так же думали и инквизиторы в средневековье, - что они делают благое дело.

> но пока еще цветочки, может здравый смысл победит и они сделают
> хттп сервер плагином к своему софтсвичу или может это не логично?

Линус Торвальдс тоже все делает неправильно и у него нет здравого смысла?


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 23-Апр-15 01:50 
> Если что-то не понятно - есть документация: 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.

> точно так же думали и инквизиторы в средневековье, - что они делают
> благое дело.

И что в этом плохого? не в инквизиторах, а в стремлении к благу


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 23-Апр-15 02:24 
>> Если что-то не понятно - есть документация: 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 подготовлен балансировщик TCP-соединений"
Отправлено cmp , 23-Апр-15 08:32 
> nginx - это reverse proxy, а не forward proxy, как например, squid.

Я в курсе)). Если открыть любую википедию из числа дистрибутивных или почитать описание пакета, то там будет написанно, что это http-сервер, и это первично, а прокси фукционал уже вторично, вы можете считать иначе, это из разряда полу- пустого/полного стакана.

> Благими намерениями вымощена дорога в ад.

Всегда так было.

> В случае с инквизицией - проблема была в том, что они пытались

Но это не повод не пытаться, в то время покупалось и продавалось все, включая людей, и кровожадных князьков хватало и упоротых которые верили в чудо омовения в крови девственниц.
Да, перегнули палку, сильно перегнули. Но граница дозволенного не определима, как и граница достаточного.

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

Глобализация стирает границы, стирает разницу, обостряя проблемы, то что пишется, то что удобно для меня или кого-то сейчас, завтра станет непонятной мутью, которая едва делает то, что надо не глюкая. А теперь задачка - определить на каком участке от "ничего" до "нахрена так наворочено" находится тот же nginx, или ядро линухи, или что угодно другое.

Когда-то я пользовался апачем, но с каждым релизом он жрал все больше, а работал все медленее, медленее потому, что периодически cgi ронял его в сегфол, сначало редко, а потом на каждом втором запросе, да не вопрос я мог бы найти косяк, но зачем мне эта ерунда с левыми пакетами на предприятии, или сменить дистр, но это лишь отсрочка, поэтому апач был выпилен со всеми своими проблемами нахрен, и nginx заменил его на долгие годы. Так вот, а не пора ли искать что-то на замену ему, или покрайней мере начинать свыкаться с мыслью, что однажды придется. Вопрос риторический.
Но читая новости о успехах нжинкса меня не покидает чувство дисбаланса, с одной стороны нафига все это надо в хттп сервере, а с другой нахрена хттп сервер в таком прикольном разруливателе потоков и соединений, будь это отдельная либа я бы нашел ей применение, а как отдельный продукт в нынешнем виде его ниша довольно узка.

Вы можете не согласиться. Однако, ИМХО, ipv4 современных нагрузок не тянет, ipv6 тоже не назвать идеалом, а дальше по наклонной ком проблем растет, и их пытаются решить и те и эти, но как-то вяло и не там, потому что кризис и на глобальные разработки денег нет, а там пожар, а там война, ну и имеем то, что имеем.



"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 23-Апр-15 21:45 
> Если открыть любую википедию из числа дистрибутивных или почитать
> описание пакета, то там будет написанно, что это 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 подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 23-Апр-15 23:59 
>> апач был выпилен со всеми своими проблемами нахрен,
>> и nginx заменил его на долгие годы. Так вот, а не

Не знаю, кого у вас там выпилил nginx и где. Разве что в мечтах...
http://news.netcraft.com/archives/2015/04/20/april-2015-web-...
И это ещё с учётом того, что добрая доля nginx в сети - фронтенды к тому же апачу.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 24-Апр-15 05:38 
> функциональнось "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 подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 24-Апр-15 10:02 
>> Не вижу причин менять nginx на что-то иное,
>> с каждой новой версией он становится все лучше и лучше.
> Господи, да не надо менять, надо разделить,
> мухи отдельно, хттп сервер отдельно, АПИ посередине и = счастье.

Кому это надо? Исповедующим unix-way? Могу предложить только http://button.dekel.ru/

> Торвальдс делает абсолютно правильно, мало того, что модули, так еще и на
> уровне компиляции можно функционал выпилить, имея относительно удобную конфигурилку.

Файловая система BTRFS грубо нарушает unix-way. Разве там не надо ничего исправить?

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

А вот с ядром ситуация совершенно иная, и там нарушение unix-way гораздо более опасно,
потому что они портят ядро, котороее общее для всех, и просто так взять и поменять ядро
на другой линукс - не получится. И что в таком случае будут делать исповедующие unix-way?


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 25-Апр-15 11:08 
У меня кожа не дымится когда не униксвей на серверах крутится, но это большой минус тому ПО и по возможности оно выпиливается.

> А вот с ядром ситуация совершенно иная,

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

> Разве там не надо ничего исправить?

Нет, нужно просто закопать.

> Кому это надо?

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

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

Это абсолютно примитивная и железобетонная логика, вы никогда не найдете в ней изъяна.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 25-Апр-15 18:06 
>>> надо разделить, мухи отдельно, хттп сервер отдельно, АПИ посередине и = счастье.
>> Кому это надо?
> Вы удивитесь, но это надо всем.

Зачем?

> насколько станет проще, когда любой компонет можно будет заменить.

GNU Hurd пилят до сих пор. И какой-то особой простоты там не наблюдается, скорее наоборот.

> Юниксвей это путь к тотальной стандартизации

https://en.wikipedia.org/wiki/Unix_wars


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 22-Апр-15 08:53 
> Щас наворотят всяких плагинов, а потом будут голову ломать как бы так
> добавить , чтото чтобы не поломать, это и рождает костыли.
> хттп сервер. Поиому чио nginx  это http сервер, это факт.
> А то что он умеет, это второстепенно

Неа, реальность сурова. Для большинства применений nginx - это в первую очередь прокси+балансировщик, а функции http-сервера у него годны разве что для статики. Такая вот хитрая ниша. Поэтому и развивают то, в чём оный силён.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 22-Апр-15 12:30 
Почему же только статики, отлично он работает с фастцги, и др, хотя их не проверял, но апач уже лет 7 как выбросил, и всякие вэбморды - апачстайл в нжинксе вполне фурычат без допилов, обидно будет если сломают легковестность и простоту всякими балансировщиками, которые может и нужны на многих серверах, но не многим.



"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено IvAnZ , 22-Апр-15 13:03 
>> отлично он работает с фастцги

так он же reverse proxy и балансировщик для fastcgi
fastcgi_pass  localhost:9000;


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 22-Апр-15 13:34 
> будет если сломают легковестность и простоту всякими балансировщиками,

По логике вещей, TCP-прокси делается из HTTP-прокси чуть ли не обрубанием HTTP :)


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 22-Апр-15 19:40 
А nginx->fcgi это суть та же прокся.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 23-Апр-15 00:01 
> А nginx->fcgi это суть та же прокся.

Согласен, но тогда любой хттп-сервер прокся для того, что генерит контент.

Идея встраемого/отдельного мультипротокольного балансировщика зависла уже давненько, есть конечно всякие имплементации ssl-ориентированные и простые, но какие-то они карявые.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 23-Апр-15 00:04 
> Согласен, но тогда любой хттп-сервер прокся для того, что генерит контент.

apache+mod_php - тоже прокся? apache+mod_perl? apache+phusion passenger? tomcat? jboss web? node.js?

Для ликбеза: "прокся" - это по сути то, что принимает запрос, и дальше его через другой сетевой сокет отдаёт следующему обработчику где-то там. Через какой конкретно тип сокета - unix/tcp/whatever - не важно. Если сокета между фронтендом и собственно обработчиком нет, и они тесно интегрированы (форк/пайпы/прочие IPC - не суть) - это уже не прокся.

Т.е. FastCGI/FPM - прокси-стайл, CGI - нет... Различие именно в наличии сокета, а не пайпа.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено cmp , 23-Апр-15 02:03 
> apache+mod_php

Тормознутое извращение))

> Для ликбеза

а чем пайп отличается от сокета? файловый дескриптор и файловый дескриптор, через netcat можно одно завернуть в другое, а другое в первое, я недавно консоль управления повесил тем, что забыв отлючить эхо на ком-порту закольцевал управление.

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


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 22-Апр-15 08:49 
У NAT-based решений есть одна большая проблема: они также требуют возвращать весь трафик через конкретный балансировщик, а поскольку адрес источника трафика не подменяется - балансировщик в итоге может быть только один... Определенными костылями это, конечно, решается (либо MAC-based возврат, либо синхронные таблицы между балансировщиками), но усложнение всей системы при этом колоссальное, и того не стоит.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Crazy Alex , 22-Апр-15 14:56 
Не совсем понял проблему, но в любом случае - я не говорил, что NAT-based - это идеально. По уму - DSR в помощь. Но если уж хочется через себя поток тянуть - логично хотя бы вюзерспейс его вытаскивать по минимуму.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 22-Апр-15 19:43 
DSR не всегда хорош. Иногда на балансере удобно кое-какую статистику считать попутно.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 22-Апр-15 07:42 
> Ну так есть разница между проксёй и TCP-балансировщиком.

А в чем такая уж принципиальная разница, по большому счету?


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено жопка3 , 21-Апр-15 16:03 
В Nginx отличная низкоуровневая инфраструктура для эфективной работы с памятью, сетевыми соединениями, файлами, DNS и прочим. Поверх этой инфраструктуры строится отличный Web-сервер. Грех не использовать готовую инфраструктуру для чего-нибудь еще :)

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено ihorman , 21-Апр-15 16:06 
этот функционал был ВСЕГДА доступен через модуль
https://github.com/yaoweibin/nginx_tcp_proxy_module\
не благодарите ...

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 21-Апр-15 16:32 
> этот функционал был ВСЕГДА доступен через модуль
> https://github.com/yaoweibin/nginx_tcp_proxy_module\

как правило у сторонних модулей гораздо хуже качество,
чем у кода из состава nginx core от разработчиков nginx


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено ihorman , 22-Апр-15 17:02 
Пользуемся этим модулем уже давно, он работает, нормально работает. Точно так же как и китайский модуль для sticky, работает, just works, что еще надо?

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 22-Апр-15 18:05 
> Пользуемся этим модулем уже давно, он работает, нормально работает.
> Точно так же как и китайский модуль для sticky, работает,
> just works, что еще надо?

Если все устраивает - пользуйтесь на здоровье, никто ж не против.
Но в большинстве случаев сторонние модули к nginx кривые и глючные.
Подробнее об этом: http://habrahabr.ru/post/195742/#comment_6797402


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 21-Апр-15 17:09 
заброщеный и год не троганый ? там правда исправляются ошибки ?

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено geektime , 22-Апр-15 02:16 
Китайский модуль это как китайские айфоны.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено jOKer , 21-Апр-15 16:22 
Супер! Отличная новость. Обязательно опробую на продакшене!

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 21-Апр-15 17:51 
Начиная с какой версии это будет?

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено csdoc , 21-Апр-15 18:49 
> Начиная с какой версии это будет?

http://trac.nginx.org/nginx/roadmap

Балансировщих будет в 1.9.0 в ближайшее время.
Но никто не мешает скачать исходники уже сейчас.

http://mailman.nginx.org/pipermail/nginx-ru/2015-April/05578...


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Аноним , 21-Апр-15 18:37 
хмм, ключевая фича tcp haproxy - splice, а тут его на первый взгляд -нет

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Ivan_83 , 21-Апр-15 19:50 
Баналансить можно было и в PF и поди в иптаблес, вообще ядреная реализация.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 22-Апр-15 08:58 
> Баналансить можно было и в PF и поди в иптаблес, вообще ядреная
> реализация.

А как насчёт двух и более балансеров с возможностью получить IP клиента для бэкэнда?


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Ivan_83 , 22-Апр-15 22:37 
DST NAT решает проблему: на сервер от балансера придут пакеты с IP клиента.

"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 22-Апр-15 23:34 
> DST NAT решает проблему: на сервер от балансера придут пакеты с IP
> клиента.

Угу. А назад как будем возвращать? Клиент-то назад ждёт IP балансера, а не сервера. Соответственно - коннтрекинг. А чтобы коннтрекинг работал - надо трафик вернуть в конкретный балансер. А IP балансера у сервера нетути, "пакет пришёл с IP клиента". В этом и проблема.

Можно, конечно, извернуться, вешая на серверы IP per balancer, и делая, например, PBR по локальному IP в обратную сторону. Или по MAC балансера приписывать трек и возвращать через PBR по треку. Но всё это из разряда извращений.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено Ivan_83 , 23-Апр-15 03:29 
>> DST NAT решает проблему: на сервер от балансера придут пакеты с IP
>> клиента.
> Угу. А назад как будем возвращать? Клиент-то назад ждёт IP балансера, а
> не сервера. Соответственно - коннтрекинг. А чтобы коннтрекинг работал - надо
> трафик вернуть в конкретный балансер. А IP балансера у сервера нетути,
> "пакет пришёл с IP клиента". В этом и проблема.

Если балансер один то он может быть роутером по дефолту для серверов.
Если балансеров много то можно через ARP анонсить мак балансера как носителя ip src клиента или пользоваться чем то вроде RIP.
Идея с уникальным IP на сервере для каждого отдельного балансера пожалуй лучше, дополнительно придётся привязать отдельную таблицу маршрутизации к слушающим на разных адресах сокетам, вроде nginx такое умел (FIB).


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 23-Апр-15 07:57 
> Если балансер один то он может быть роутером по дефолту для серверов.

Выше уже писал. Случай не рассматривается - слишком плохой. Балансер превращается в SPOF.

> Если балансеров много то можно через ARP анонсить мак балансера как носителя
> ip src клиента

Это, простите, как? Один и тот же IP может запросто входить через все балансеры, причём даже одновременно.

> Идея с уникальным IP на сервере для каждого отдельного балансера пожалуй лучше,
> дополнительно придётся привязать отдельную таблицу маршрутизации к слушающим на разных
> адресах сокетам, вроде nginx такое умел (FIB).

Угу. В линухах это делается легко и просто, и даже к сокетам ничего привязывать не надо (просто PBR по srcip). Но всё равно - из разряда извращений.


"Для nginx подготовлен балансировщик TCP-соединений"
Отправлено AlexAT , 21-Апр-15 19:58 
Неплохая замена haproxy, кстати. С учётом send/expect - вообще шикарно.