форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для nginx подготовлен балансировщик TCP-соединений"	+/–
Сообщение от opennews (??) on 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.dev/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.dev/opennews/art.shtml?num=42076
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Для nginx подготовлен балансировщик TCP-соединений"	+4 +/–
Сообщение от mva (??) on 21-Апр-15, 12:52
Годнота // Осталось 1.7.13/1.8 дождаться :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от shadow (??) on 21-Апр-15, 18:30
	1.8 уже дождались http://mailman.nginx.org/pipermail/nginx-announce/2015/00015...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	49. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от CSRedRat (ok) on 22-Апр-15, 08:05
	В тот же день! http://www.opennet.dev/opennews/art.shtml?num=42082
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
Сообщение от rachok (ok) on 21-Апр-15, 12:55
Хорошая новость, нужно попробовать на тестовом кластере, а потом можна и в прод =)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Для nginx подготовлен балансировщик TCP-соединений"	+2 +/–
	Сообщение от Andrey Mitrofanov on 21-Апр-15, 13:14
	>на тестовом кластере, а потом можна и в прод =) Чем haproxy не устроил?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Для nginx подготовлен балансировщик TCP-соединений"	+3 +/–
	Сообщение от Anonnn on 21-Апр-15, 13:23
	Устроил. Но хочется коробочное решение из nginx.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	45. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Аноним (??) on 22-Апр-15, 07:41
	> коробочное решение из nginx. Тогда купи слона^W nginx plus...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	57. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от rachok (ok) on 22-Апр-15, 13:25
	>>Чем haproxy не устроил? Он есть просто хочется уменьшить количество прослоек
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	76. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 08:17
	Зачем? unix way же!
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	78. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от Andrey Mitrofanov on 23-Апр-15, 10:50
	> Зачем? unix way же! Администрировать клубок nginx 1.8+ _намного_ легче, чем два клубочка поменьше - haproxy + nginx 0.8.4. </Элементарно, Ватсон!>
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	83. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Аноним (??) on 24-Апр-15, 10:18
	> Администрировать клубок nginx 1.8+ _намного_ легче, чем два клубочка поменьше - haproxy > + nginx 0.8.4. </Элементарно, Ватсон!> Митрофанушка рассказывает нам почему один клубок системды скушает кучу клубочков поменьше типа инит скриптов в каждой дырке и прочая :)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	84. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от Andrey Mitrofanov on 24-Апр-15, 10:45
	>> </Элементарно, Ватсон!> > Митрофанушка рассказывает нам почему один клубок системды скушает кучу клубочков поменьше типа инит скриптов в каждой дырке и прочая :) Обнови броузер, не модно это, тэг пропустил. Митрофанов глумится над клубищами побольше и задравв-штаны-выбегабщими за ними и их разноцветными бусами. Над тобой тоже, вдруг ты не понял. Клубочки побольше все желающие могут наблюдать в соведних новостях: про броузеры и "движки", умирающие один за одним под собственным весом и не имеюшие никакой поддержки безопасности н ив одном уважающем себя дистрибутиве. Судьбы Мира, печалька...
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

10. "Для nginx подготовлен балансировщик TCP-соединений"	+2 +/–
Сообщение от Crazy Alex (ok) on 21-Апр-15, 14:32
Я, конечно, от хайлоада последние пару лет далёк - но с каких пор этим стал заниматься веб-сервер?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Для nginx подготовлен балансировщик TCP-соединений"	+4 +/–
	Сообщение от Аноним (??) on 21-Апр-15, 15:13
	> пор этим стал заниматься веб-сервер? Nginx всю жизнь был еще и реверс-прокси. В том числе и для почты, внезапно.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	30. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Crazy Alex (ok) on 21-Апр-15, 17:11
	Ну так есть разница между проксёй и TCP-балансировщиком.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	32. "Для nginx подготовлен балансировщик TCP-соединений"	–2 +/–
	Сообщение от csdoc (ok) on 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.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	38. "Для nginx подготовлен балансировщик TCP-соединений"	–1 +/–
	Сообщение от Crazy Alex (ok) on 21-Апр-15, 20:59
	Это, в общем-то, и из новости понятно. Непонятно на кой так чудить с TCP вместо DSR или хотя бы NAT-based решений. Ладно - HTTP - nginx его понимает и может много чего сделать. Но generic TCP?
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	39. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 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.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Для nginx подготовлен балансировщик TCP-соединений"	+2 +/–
	Сообщение от cmp (ok) on 22-Апр-15, 01:29
	> NAT-based решения не могут делать всего того, что умеет делать nginx Не уверен, что iptables слабее в части руления трафика. > Удобно использовать только nginx для всех задач Угу, только в комбайнах потом эпичные дыры находятся, даром чтоли openssl так резать активно начали. > Теперь в список поддерживаемых добавится еще один протокол - TCP. Еще один был бы ftp, а tcp это транспорт для всего перечисленного, то есть теперь обработка работает на другом уровне, и это рождает вполне закономерный вопрос - зачем http серверу функционал руления транспортным протоколом, таким макаром и до nginxOS можно дописаться. nginx хорош своей легковестностью, тяжелый и мутный апач уже существует, но не получится ли в итоге тяжелого и мутного nginx'a.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	41. "Для nginx подготовлен балансировщик TCP-соединений"	–1 +/–
	Сообщение от csdoc (ok) on 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. не получится.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	43. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от cmp (ok) on 22-Апр-15, 04:58
	> пойти по ссылке Незачем, не собираюсь юзать, даже рассматривать теоритическую возможность такой сети, возить дрова на каене идиотизм. > Готов выслушать предложения Предложений нет, есть озвученное опасение. > L7 или L4 - вопрос второстепенный. Тут уже была новость о хттп в который через pcap завернут езернет. Общность не прощупывается? >facepalm.jpg Сарказм не распознаем, хотя в свете предыдущего факта весьма в тему. >не получится Да ладно, было бы желание. Щас наворотят всяких плагинов, а потом будут голову ломать как бы так добавить , чтото чтобы не поломать, это и рождает костыли. Имхо  было бы правильнее софт свич сделать отдельно, а не использовать хттп сервер. Поиому чио nginx  это http сервер, это факт. А то что он умеет, это второстепенно
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	44. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 22-Апр-15, 05:12
	> не собираюсь юзать, даже рассматривать теоритическую возможность В таком случае, есть ли смысл давать разработчикам nginx ценные указания о том, как им следует правильно поступить? >> Готов выслушать предложения > Предложений нет, есть озвученное опасение. Все будет хорошо. >> L7 или L4 - вопрос второстепенный. > Тут уже была новость о хттп в который через pcap завернут езернет. > Общность не прощупывается? https://www.youtube.com/watch?v=h0jB5dB3gNo
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	55. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от cmp (ok) on 22-Апр-15, 12:39
	Да не было указаний, был намек на то, что нжинкс все меньше хттп сервер и все больше непонятно что. Да, я исповедую юниксвей и не испытываю оптимизма по поводу подобных извращений, но пока еще цветочки, может здравый смысл победит и они сделают хттп сервер плагином к своему софтсвичу или может это не логично?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	61. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 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 - это тоже "юниксвей" или уже нет? > и не испытываю оптимизма по поводу подобных извращений, точно так же думали и инквизиторы в средневековье, - что они делают благое дело. > но пока еще цветочки, может здравый смысл победит и они сделают > хттп сервер плагином к своему софтсвичу или может это не логично? Линус Торвальдс тоже все делает неправильно и у него нет здравого смысла?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	71. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от cmp (ok) on 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. > точно так же думали и инквизиторы в средневековье, - что они делают > благое дело. И что в этом плохого? не в инквизиторах, а в стремлении к благу
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	73. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 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 всем правилам из этой классической книги полностью соответствует. >> точно так же думали и инквизиторы в средневековье, >> - что они делают благое дело. > И что в этом плохого? не в инквизиторах, а в стремлении к благу Благими намерениями вымощена дорога в ад. В случае с инквизицией - проблема была в том, что они пытались действовать далеко за пределами своего уровня компетенции, силой навязывая другим людям свое представление о том, что те должны думать, как должны поступать и т.п. Классический пример - запрет думать и говорить о том, что земля круглая, и что она не является центром вселенной и что она вращается вокруг солнца. А тех кто думал и говорил иначе - сжигали на кострах или другим способом убивали. И что самое интересное, инквизиторы при этом думали что делают благое и богоугодное дело. Потому что по их мнению только они исповедовали правильную веру, а все кто думал иначе - это были еретики, вероотступники и агенты дьявола.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	77. "Для nginx подготовлен балансировщик TCP-соединений"	–1 +/–
	Сообщение от cmp (ok) on 23-Апр-15, 08:32
	> nginx - это reverse proxy, а не forward proxy, как например, squid. Я в курсе)). Если открыть любую википедию из числа дистрибутивных или почитать описание пакета, то там будет написанно, что это http-сервер, и это первично, а прокси фукционал уже вторично, вы можете считать иначе, это из разряда полу- пустого/полного стакана. > Благими намерениями вымощена дорога в ад. Всегда так было. > В случае с инквизицией - проблема была в том, что они пытались Но это не повод не пытаться, в то время покупалось и продавалось все, включая людей, и кровожадных князьков хватало и упоротых которые верили в чудо омовения в крови девственниц. Да, перегнули палку, сильно перегнули. Но граница дозволенного не определима, как и граница достаточного. В какой момент можно сказать, что программа готова, или машина; или хлеб, ваша бабушка готовила его так, а моя иначе, и ваш хлеб для папуаса африканского совсем не хлеб может быть. Глобализация стирает границы, стирает разницу, обостряя проблемы, то что пишется, то что удобно для меня или кого-то сейчас, завтра станет непонятной мутью, которая едва делает то, что надо не глюкая. А теперь задачка - определить на каком участке от "ничего" до "нахрена так наворочено" находится тот же nginx, или ядро линухи, или что угодно другое. Когда-то я пользовался апачем, но с каждым релизом он жрал все больше, а работал все медленее, медленее потому, что периодически cgi ронял его в сегфол, сначало редко, а потом на каждом втором запросе, да не вопрос я мог бы найти косяк, но зачем мне эта ерунда с левыми пакетами на предприятии, или сменить дистр, но это лишь отсрочка, поэтому апач был выпилен со всеми своими проблемами нахрен, и nginx заменил его на долгие годы. Так вот, а не пора ли искать что-то на замену ему, или покрайней мере начинать свыкаться с мыслью, что однажды придется. Вопрос риторический. Но читая новости о успехах нжинкса меня не покидает чувство дисбаланса, с одной стороны нафига все это надо в хттп сервере, а с другой нахрена хттп сервер в таком прикольном разруливателе потоков и соединений, будь это отдельная либа я бы нашел ей применение, а как отдельный продукт в нынешнем виде его ниша довольно узка. Вы можете не согласиться. Однако, ИМХО, ipv4 современных нагрузок не тянет, ipv6 тоже не назвать идеалом, а дальше по наклонной ком проблем растет, и их пытаются решить и те и эти, но как-то вяло и не там, потому что кризис и на глобальные разработки денег нет, а там пожар, а там война, ну и имеем то, что имеем.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	79. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 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-адреса.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	80. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 23-Апр-15, 23:59
	>> апач был выпилен со всеми своими проблемами нахрен, >> и nginx заменил его на долгие годы. Так вот, а не Не знаю, кого у вас там выпилил nginx и где. Разве что в мечтах... http://news.netcraft.com/archives/2015/04/20/april-2015-web-... И это ещё с учётом того, что добрая доля nginx в сети - фронтенды к тому же апачу.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	81. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от cmp (ok) on 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-адреса. Собственно это не его недостаток, а дибильная политика раздавания огромных пулов всем подряд, дабы экономить на НАТе, + дибильная политика - каждому корпорасту по стандарту, иначе давно бы уже нормальную автопробрасывалку портов бы придумали, но увы.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	82. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 24-Апр-15, 10:02
	>> Не вижу причин менять nginx на что-то иное, >> с каждой новой версией он становится все лучше и лучше. > Господи, да не надо менять, надо разделить, > мухи отдельно, хттп сервер отдельно, АПИ посередине и = счастье. Кому это надо? Исповедующим unix-way? Могу предложить только http://button.dekel.ru/ > Торвальдс делает абсолютно правильно, мало того, что модули, так еще и на > уровне компиляции можно функционал выпилить, имея относительно удобную конфигурилку. Файловая система BTRFS грубо нарушает unix-way. Разве там не надо ничего исправить? nginx - это один из веб-серверов, которых десятки, если не сотни, и если nginx нарушает unix-way - можно просто прекратить им пользоваться и взять другой, более правильный с идеологической точки зрения веб-сервер. А вот с ядром ситуация совершенно иная, и там нарушение unix-way гораздо более опасно, потому что они портят ядро, котороее общее для всех, и просто так взять и поменять ядро на другой линукс - не получится. И что в таком случае будут делать исповедующие unix-way?
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	85. "Для nginx подготовлен балансировщик TCP-соединений"	–1 +/–
	Сообщение от cmp (ok) on 25-Апр-15, 11:08
	У меня кожа не дымится когда не униксвей на серверах крутится, но это большой минус тому ПО и по возможности оно выпиливается. > А вот с ядром ситуация совершенно иная, Точно такая же, я когда по молодости программированием активно занимался, меня тоже на всякие "улучшения" тянуло, как результат код состоял почти весь из этих улучшений, и иногда даже работал, но поиск проблем был кошмаром. > Разве там не надо ничего исправить? Нет, нужно просто закопать. > Кому это надо? Вы удивитесь, но это надо всем. Насколько стало проще когда железной волей запретили производителям иметь тысячи несовместих разъемов для зарядных устроиств, насколько станет проще, когда любой компонет можно будет заменить. Юниксвей это путь к тотальной стандартизации, да многие связки работают быстрее когда заточены друг под друга, но в большенстве случаев это проблемы архитектуры, потому, что когда вы строите дом, а у вас выходит что балка должна быть меньше обычной, а нагрузку нести большую, значит вы плохой архитектор. Это абсолютно примитивная и железобетонная логика, вы никогда не найдете в ней изъяна.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	87. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 25-Апр-15, 18:06
	>>> надо разделить, мухи отдельно, хттп сервер отдельно, АПИ посередине и = счастье. >> Кому это надо? > Вы удивитесь, но это надо всем. Зачем? > насколько станет проще, когда любой компонет можно будет заменить. GNU Hurd пилят до сих пор. И какой-то особой простоты там не наблюдается, скорее наоборот. > Юниксвей это путь к тотальной стандартизации https://en.wikipedia.org/wiki/Unix_wars
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	51. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от AlexAT (ok) on 22-Апр-15, 08:53
	> Щас наворотят всяких плагинов, а потом будут голову ломать как бы так > добавить , чтото чтобы не поломать, это и рождает костыли. > хттп сервер. Поиому чио nginx  это http сервер, это факт. > А то что он умеет, это второстепенно Неа, реальность сурова. Для большинства применений nginx - это в первую очередь прокси+балансировщик, а функции http-сервера у него годны разве что для статики. Такая вот хитрая ниша. Поэтому и развивают то, в чём оный силён.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	54. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от cmp (ok) on 22-Апр-15, 12:30
	Почему же только статики, отлично он работает с фастцги, и др, хотя их не проверял, но апач уже лет 7 как выбросил, и всякие вэбморды - апачстайл в нжинксе вполне фурычат без допилов, обидно будет если сломают легковестность и простоту всякими балансировщиками, которые может и нужны на многих серверах, но не многим.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	56. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от IvAnZ on 22-Апр-15, 13:03
	>> отлично он работает с фастцги так он же reverse proxy и балансировщик для fastcgi fastcgi_pass  localhost:9000;
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	59. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Аноним (??) on 22-Апр-15, 13:34
	> будет если сломают легковестность и простоту всякими балансировщиками, По логике вещей, TCP-прокси делается из HTTP-прокси чуть ли не обрубанием HTTP :)
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	64. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 22-Апр-15, 19:40
	А nginx->fcgi это суть та же прокся.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	69. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от cmp (ok) on 23-Апр-15, 00:01
	> А nginx->fcgi это суть та же прокся. Согласен, но тогда любой хттп-сервер прокся для того, что генерит контент. Идея встраемого/отдельного мультипротокольного балансировщика зависла уже давненько, есть конечно всякие имплементации ssl-ориентированные и простые, но какие-то они карявые.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	70. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 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 - нет... Различие именно в наличии сокета, а не пайпа.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	72. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от cmp (ok) on 23-Апр-15, 02:03
	> apache+mod_php Тормознутое извращение)) > Для ликбеза а чем пайп отличается от сокета? файловый дескриптор и файловый дескриптор, через netcat можно одно завернуть в другое, а другое в первое, я недавно консоль управления повесил тем, что забыв отлючить эхо на ком-порту закольцевал управление. По современным меркам отделять проксю от не прокси дурная работа, сейчас даже чиновники используют этот термин в отношение межведомственного документооборота.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	50. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 22-Апр-15, 08:49
	У NAT-based решений есть одна большая проблема: они также требуют возвращать весь трафик через конкретный балансировщик, а поскольку адрес источника трафика не подменяется - балансировщик в итоге может быть только один... Определенными костылями это, конечно, решается (либо MAC-based возврат, либо синхронные таблицы между балансировщиками), но усложнение всей системы при этом колоссальное, и того не стоит.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	60. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Crazy Alex (ok) on 22-Апр-15, 14:56
	Не совсем понял проблему, но в любом случае - я не говорил, что NAT-based - это идеально. По уму - DSR в помощь. Но если уж хочется через себя поток тянуть - логично хотя бы вюзерспейс его вытаскивать по минимуму.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	65. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 22-Апр-15, 19:43
	DSR не всегда хорош. Иногда на балансере удобно кое-какую статистику считать попутно.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	46. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Аноним (??) on 22-Апр-15, 07:42
	> Ну так есть разница между проксёй и TCP-балансировщиком. А в чем такая уж принципиальная разница, по большому счету?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	24. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от жопка3 on 21-Апр-15, 16:03
	В Nginx отличная низкоуровневая инфраструктура для эфективной работы с памятью, сетевыми соединениями, файлами, DNS и прочим. Поверх этой инфраструктуры строится отличный Web-сервер. Грех не использовать готовую инфраструктуру для чего-нибудь еще :)
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

25. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
Сообщение от ihorman on 21-Апр-15, 16:06
этот функционал был ВСЕГДА доступен через модуль https://github.com/yaoweibin/nginx_tcp_proxy_module\ не благодарите ...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Для nginx подготовлен балансировщик TCP-соединений"	+1 +/–
	Сообщение от csdoc (ok) on 21-Апр-15, 16:32
	> этот функционал был ВСЕГДА доступен через модуль > https://github.com/yaoweibin/nginx_tcp_proxy_module\ как правило у сторонних модулей гораздо хуже качество, чем у кода из состава nginx core от разработчиков nginx
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	62. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от ihorman on 22-Апр-15, 17:02
	Пользуемся этим модулем уже давно, он работает, нормально работает. Точно так же как и китайский модуль для sticky, работает, just works, что еще надо?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	63. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 22-Апр-15, 18:05
	> Пользуемся этим модулем уже давно, он работает, нормально работает. > Точно так же как и китайский модуль для sticky, работает, > just works, что еще надо? Если все устраивает - пользуйтесь на здоровье, никто ж не против. Но в большинстве случаев сторонние модули к nginx кривые и глючные. Подробнее об этом: http://habrahabr.ru/post/195742/#comment_6797402
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	29. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Аноним (??) on 21-Апр-15, 17:09
	заброщеный и год не троганый ? там правда исправляются ошибки ?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	42. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от geektime on 22-Апр-15, 02:16
	Китайский модуль это как китайские айфоны.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
Сообщение от jOKer (ok) on 21-Апр-15, 16:22
Супер! Отличная новость. Обязательно опробую на продакшене!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
Сообщение от Аноним (??) on 21-Апр-15, 17:51
Начиная с какой версии это будет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от csdoc (ok) on 21-Апр-15, 18:49
	> Начиная с какой версии это будет? http://trac.nginx.org/nginx/roadmap Балансировщих будет в 1.9.0 в ближайшее время. Но никто не мешает скачать исходники уже сейчас. http://mailman.nginx.org/pipermail/nginx-ru/2015-April/05578...
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Для nginx подготовлен балансировщик TCP-соединений"	+2 +/–
Сообщение от Аноним (??) on 21-Апр-15, 18:37
хмм, ключевая фича tcp haproxy - splice, а тут его на первый взгляд -нет
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
Сообщение от Ivan_83 on 21-Апр-15, 19:50
Баналансить можно было и в PF и поди в иптаблес, вообще ядреная реализация.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 22-Апр-15, 08:58
	> Баналансить можно было и в PF и поди в иптаблес, вообще ядреная > реализация. А как насчёт двух и более балансеров с возможностью получить IP клиента для бэкэнда?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	67. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Ivan_83 on 22-Апр-15, 22:37
	DST NAT решает проблему: на сервер от балансера придут пакеты с IP клиента.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	68. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 22-Апр-15, 23:34
	> DST NAT решает проблему: на сервер от балансера придут пакеты с IP > клиента. Угу. А назад как будем возвращать? Клиент-то назад ждёт IP балансера, а не сервера. Соответственно - коннтрекинг. А чтобы коннтрекинг работал - надо трафик вернуть в конкретный балансер. А IP балансера у сервера нетути, "пакет пришёл с IP клиента". В этом и проблема. Можно, конечно, извернуться, вешая на серверы IP per balancer, и делая, например, PBR по локальному IP в обратную сторону. Или по MAC балансера приписывать трек и возвращать через PBR по треку. Но всё это из разряда извращений.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	74. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от Ivan_83 on 23-Апр-15, 03:29
	>> DST NAT решает проблему: на сервер от балансера придут пакеты с IP >> клиента. > Угу. А назад как будем возвращать? Клиент-то назад ждёт IP балансера, а > не сервера. Соответственно - коннтрекинг. А чтобы коннтрекинг работал - надо > трафик вернуть в конкретный балансер. А IP балансера у сервера нетути, > "пакет пришёл с IP клиента". В этом и проблема. Если балансер один то он может быть роутером по дефолту для серверов. Если балансеров много то можно через ARP анонсить мак балансера как носителя ip src клиента или пользоваться чем то вроде RIP. Идея с уникальным IP на сервере для каждого отдельного балансера пожалуй лучше, дополнительно придётся привязать отдельную таблицу маршрутизации к слушающим на разных адресах сокетам, вроде nginx такое умел (FIB).
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	75. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
	Сообщение от AlexAT (ok) on 23-Апр-15, 07:57
	> Если балансер один то он может быть роутером по дефолту для серверов. Выше уже писал. Случай не рассматривается - слишком плохой. Балансер превращается в SPOF. > Если балансеров много то можно через ARP анонсить мак балансера как носителя > ip src клиента Это, простите, как? Один и тот же IP может запросто входить через все балансеры, причём даже одновременно. > Идея с уникальным IP на сервере для каждого отдельного балансера пожалуй лучше, > дополнительно придётся привязать отдельную таблицу маршрутизации к слушающим на разных > адресах сокетам, вроде nginx такое умел (FIB). Угу. В линухах это делается легко и просто, и даже к сокетам ничего привязывать не надо (просто PBR по srcip). Но всё равно - из разряда извращений.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

37. "Для nginx подготовлен балансировщик TCP-соединений"	+/–
Сообщение от AlexAT (ok) on 21-Апр-15, 19:58
Неплохая замена haproxy, кстати. С учётом send/expect - вообще шикарно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема