The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

"В nginx появилась поддержка балансировки UDP-соединений "  –1 +/
Сообщение от opennews on 15-Мрт-16, 17:15 
Разработчики http-сервера nginx объявили (https://www.nginx.com/blog/announcing-udp-load-balancing/) о реализации поддержки балансировки UDP-соединений, которая дополнила собой ранее добавленный (https://www.opennet.ru/opennews/art.shtml?num=42076) балансировщик произвольных TCP-соединений, реализованный в виде модуля stream. Проброс UDP может быть полезен для распределения нагрузки между несколькими DNS-, syslog- или radius-серверами. UDP-балансировщик уже интегрирован в репозиторий (http://hg.nginx.org/nginx/?_ga=1.64647661.335129412.1443032231) с исходными текстами nginx и войдёт в состав намеченного на 23 марта выпуска 1.9.13.


Среди поддерживаемых (https://www.nginx.com/products/application-load-balancing/#l...) методов балансировки: round-robin (круговой перебор, при котором соединения равномерно распределяются среди обработчиков), least-connections (запрос перенаправляется к менее нагруженному серверу), least_time (перенаправление на сервер, демонстрирующий наиболее высокую отзывчивость) и hash (перенаправление на основе хэша от определённого пользователем параметра, например, IP). После перенаправления запроса серверу, nginx дожидается ответа и переотправляет его клиенту. Если сервер не ответил в течение таймаута, nginx помечает сервер как проблемный и прекращает отправлять на него запросы, но раз в несколько секунд проверяет не восстановился ли он, отправляя пробный клиентский запрос.

URL: https://www.nginx.com/blog/announcing-udp-load-balancing/
Новость: https://www.opennet.ru/opennews/art.shtml?num=44049

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "В nginx появилась поддержка балансировки UDP-соединений "  +5 +/
Сообщение от dkg on 15-Мрт-16, 17:15 
nginx радует. Может кто посоветовать хорошую литературу по настройки для highload?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "В nginx появилась поддержка балансировки UDP-соединений "  –1 +/
Сообщение от www2 (??) on 15-Мрт-16, 17:44 
Highload не настраивают, их пишут. При отсутствии архитектурных решений, предусматривающих масштабирование проекта на множество серверов, всякие настройки бесполезны, потому что не позволят выжать из железа больше, чем то, на что оно способно.

Если вы считаете, что Highload - это баззворды вроде Mongo, Django, Memcache и Redis, то мне кажется, что вы ошибаетесь. Всё это - костыли, которые максимально удаляют вас от наиболее эффективного решения. Нормальный проект - это многопроцессный или многопоточный демон с общей памятью, который всё своё носит с собой (не использует сторонних фреймворков или демонов, разработчики которых внезапно могут объявить нужные вам фичи устаревшими и неподдерживаемыми) и всё нужное держит при себе (сессии пользователей вместе со всеми нужными для сеанса объектами хранит в общей для всех воркеров оперативной памяти, а не грузит их при каждом чихе из базы данных, сохраняя в Memcache, "для кэширования").

И конечно, Highload - это не только веб. Чтобы написать производительное веб-приложение, нужно отбросить общепринятую в вебе шелуху и использовать подходы, которые используются вне веба. Там точно есть чему поучиться, потому там хорошо понимают, что одними баззвордами реальность не обманешь.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "микросервисы "  +/
Сообщение от anonnnn on 15-Мрт-16, 17:55 
А как же микросервисная архитектура, позволяющая легче масштабировать горизонтально?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "микросервисы "  +1 +/
Сообщение от Аноним (??) on 15-Мрт-16, 18:24 
Микросервисы к х-йлоаду относятся только как один из путей потребления вычислительных ресурсов. А так, у тебя голова прожужжаная торгашнёй со всего интернете.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

16. "микросервисы "  +/
Сообщение от Andrey (??) on 15-Мрт-16, 19:58 
Микросервисы это скорее о подходе к разработке и релизу приложений (CI). И в отличии от монолитных монстров, масштабировать их гораздо проще и приятней, потому и ассоциируются как правильный паттерн для highload-сред.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

32. "микросервисы "  +2 +/
Сообщение от www2 (ok) on 16-Мрт-16, 08:45 
> Микросервисы это скорее о подходе к разработке и релизу приложений (CI). И
> в отличии от монолитных монстров, масштабировать их гораздо проще и приятней,
> потому и ассоциируются как правильный паттерн для highload-сред.

Отличный паттерн, в котором 90% работы заключается в том, чтобы раскодировать запрос и закодировать ответ. Накладные расходы очень большие. Почему вы думаете что есть только микросервисы и монолитные сервисы? Почему монолитный с виду сервис не может оказаться модульным внутри и с разными типами воркеров? Каждый воркер может потреблять столько памяти, сколько ему нужно. Каждого типа воркеров может быть запущено столько, сколько нужно.

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

Короче - как работает настоящий Highload в его веб-ипостаси, можно увидеть массовых в онлайн-играх. Например вот:
https://habrahabr.ru/company/mailru/blog/182088/
https://habrahabr.ru/company/mailru/blog/220359/

Заметьте - нет ни слова про микросервисы, Django, Mongo, Redis, Memcache и Highload. Упоминается No-SQL в контексте "нам нужна консистентность, а No-SQL её как правило не обеспечивают". Люди думают головой и проектируют архитектуру, а не бросаются на модные слова.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

4. "В nginx появилась поддержка балансировки UDP-соединений "  +2 +/
Сообщение от Crazy Alex (ok) on 15-Мрт-16, 18:01 
Эти "баззворды" как раз и дают "общую для всех воркеров оперативную память", независимо от того, где данный воркер запущен. Ну да, кастомный демон, держащий всё в себе - гораздо эффективнее, пока помещается на один сервер. И даже тогда надо как-то обеспечивать горячую замену - но это решаемо. Но как только инстансов становится много - про общую оперативную память можно и нужно забывать, и стандартные решения с известными граблями и путями их обхода рулят.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

24. "В nginx появилась поддержка балансировки UDP-соединений "  +2 +/
Сообщение от pavlinux (ok) on 16-Мрт-16, 00:52 
Товарищи теоретики, курите Теорию автоматов, Робачевского, IPC, модели параллелизации.
В двух словах: Задача диктует модель реализации! Остальное - школьный срач.  
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

30. "В nginx появилась поддержка балансировки UDP-соединений "  +1 +/
Сообщение от www2 (ok) on 16-Мрт-16, 08:25 
> Товарищи теоретики, курите Теорию автоматов, Робачевского, IPC, модели параллелизации.
> В двух словах: Задача диктует модель реализации! Остальное - школьный срач.

Дело в том, что задача со временем меняется. Сначала это HTML-страничка со списком учеников школы, а потом оно дорастает до соцсети с миллионами активных пользователей. Почему-то есть общепринятые или хорошо раскрученные методы решения этой задачи. Элементы этого решения - микросервисная архитектура, Memcache, Redis, Mongo. Но использование этих баззвордов совсем не означает автоматически, что приложение готово к высоким нагрузкам и хорошо масштабируется.

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

37. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от pavlinux (ok) on 17-Мрт-16, 20:04 
>> Товарищи теоретики, курите Теорию автоматов, Робачевского, IPC, модели параллелизации.
>> В двух словах: Задача диктует модель реализации! Остальное - школьный срач.
> Дело в том, что задача со временем меняется. Сначала это HTML-страничка со
> списком учеников школы, а потом оно дорастает до соцсети с миллионами
> активных пользователей.

Вы предлагаете масштабировать echo Hello World на 6 лямов юзеров? :)
Не, это очень даже рационально, с точки зрения зарплаты IT-отдела.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

29. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от www2 (??) on 16-Мрт-16, 08:17 
>Эти "баззворды" как раз и дают "общую для всех воркеров оперативную память", независимо от того, где данный воркер запущен.

Ну да. Это же так удобно. Первую страницу клиент запросил у одного сервера, а следующую - у другого.

>Ну да, кастомный демон, держащий всё в себе - гораздо эффективнее, пока помещается на один сервер.

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

>Но как только инстансов становится много - про общую оперативную память можно и нужно забывать, и стандартные решения с известными граблями и путями их обхода рулят.

Эти ваши Memcache с Redis никогда не заменят мозга. Клиента нужно стараться всегда обслуживать в одном и том же месте и хранить в этом месте все его данные в оперативке. Общее хранилище - оно для хранения данных между сеансами.

Стандартные решения - это метод грубой силы. Для тех, у кого нет мозгов, но много денег на железо.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "В nginx появилась поддержка балансировки UDP-соединений "  +8 +/
Сообщение от Ivan_83 email(ok) on 15-Мрт-16, 18:58 
Хернёй страдают - тоже самое можно делать в том же PF вообще на уровне ядра, если руки прямые и хватит ума написать пару строчек правил для NAT, rdr и pass.

Пора уже разрезать nginx на куски: хттп, мыло, и вот эти всякие балансировщики.
Те проект мало того что оброс модулями по теме, так ещё там теперь всякое не относящиеся к хттп пристраивается тоннами.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "В nginx появилась поддержка балансировки UDP-соединений "  +3 +/
Сообщение от Crazy Alex (ok) on 15-Мрт-16, 19:18 
Вот да, что-то он совсем в комбайн превратился
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "В nginx появилась поддержка балансировки UDP-соединений "  –1 +/
Сообщение от Аноним (??) on 15-Мрт-16, 19:42 
> Вот да, что-то он совсем в комбайн превратился

Это было очевидно уже давно.
Например, там внутри есть собственный аналог systemd, обеспечивающий постепенный перезапуск воркеров без остановки обслуживания, посредством сокет-активации.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

26. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 16-Мрт-16, 01:55 
>> Вот да, что-то он совсем в комбайн превратился
>
> Это было очевидно уже давно.
> Например, там внутри есть собственный аналог systemd, обеспечивающий постепенный перезапуск воркеров без остановки обслуживания, посредством сокет-активации.

А ты предлагаешь через kill -9 перезапускать?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

34. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 16-Мрт-16, 17:18 
> Например, там внутри есть собственный аналог systemd,

Так бзды только собираются еще launchd начать использовать, вот и пришлось рьяным бсдшникам кодить свой вариант.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

38. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от й on 19-Мрт-16, 15:04 
это не аналог systemd. systemd может послать мастер-процессу HUP, а с воркерами пусть уже сам мастер-процесс разбирается. нормальая архитектура, в общем.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

20. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 15-Мрт-16, 23:30 
Энтерпрайзники требуют. Попробуй логи с 500 нагруженных серверов получать. То еще приключение.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

23. "В nginx появилась поддержка балансировки UDP-соединений "  –2 +/
Сообщение от pavlinux (ok) on 16-Мрт-16, 00:42 
О, йопт, админы локалхостов подтянулись... "- Логи, 500 серверов,...".
Если у тя болит живот, анализ кала и мочи будешь каждую минуту делать?


Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

27. "В nginx появилась поддержка балансировки UDP-соединений "  +3 +/
Сообщение от . on 16-Мрт-16, 03:59 
Дурак ты Паша!(С)
У ынтерпрайза живот всегда болит!
6 лет назад в одной 3-х буквенной лавке объём ежедневных гзипованных логов составлял 6ТБ.
И они щедро платили чтоб это всё долетело, застроилось и распарсилось.
Не думаю что с тех пор стало меньше :-))))
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

36. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 17-Мрт-16, 12:20 
Это же не логи :)
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

35. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 16-Мрт-16, 17:25 
> Если у тя болит живот, анализ кала и мочи будешь каждую минуту делать?

Есть разница - сделать анализ 1 человеку в год или 500 человек ежедневно. Во втором случае придется придумывать автоматизацию процессов и распределение нагрузки на группу воркеров-лаборантов.

Сходи в большую серьезную лабораторию и посмотри что из себя представляет анализатор. Это почти автоматические машины с кучей датчиков и бортовым компьютером. Лаборанты меняют пробирки, льют реактивы и иногда проверяют/калибруют датчики.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

8. "В nginx появилась поддержка балансировки UDP-соединений "  +1 +/
Сообщение от Аноним (??) on 15-Мрт-16, 19:19 
Т.е., позорище.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 15-Мрт-16, 19:41 
> Хернёй страдают - тоже самое можно делать в том же PF вообще на уровне ядра, если руки прямые и хватит ума написать пару строчек правил для NAT, rdr и pass.

Если не секрет - как при помощи PF можно обеспечить балансировку least-connections например?
Или least-time?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

22. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 15-Мрт-16, 23:44 
>Если не секрет - как при помощи PF можно обеспечить балансировку least-connections например? Или least-time?

Конечно, это секрет. Пишешь демон, который чекает бэкенды, далее заполняешь таблицы в pf. Смысл, ну вот один в один как в nginx. Ну, е*та, это ж не хайлоад, да.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "В nginx появилась поддержка балансировки UDP-соединений "  +3 +/
Сообщение от Аноним (??) on 15-Мрт-16, 19:50 
> тоже самое можно делать в том же PF вообще на уровне ядра, если руки прямые и хватит ума

Ага, а ещё можно на ассемблере написать модуль ядра и тоже самое сделать вообще в командах микропроцессора, если руки прямые и хватит ума.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

14. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 15-Мрт-16, 19:52 
> Ага, а ещё можно на ассемблере написать модуль ядра

Лучше на баше, там более прозрачно® и юниксвейно™. Главное, не забыть включить в ядро интерпретатор баша...

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от rshadow (ok) on 15-Мрт-16, 20:46 
Да все правильно он делает. Хорошее решение для реальных задач. Все остальное теория.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

18. "В nginx появилась поддержка балансировки UDP-соединений "  +1 +/
Сообщение от Аноним (??) on 15-Мрт-16, 21:39 
от баша у него фрибсд осквернится, тычо
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

28. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от . on 16-Мрт-16, 04:01 
> от баша у него фрибсд осквернится, тычо

Там в портах (по умолчанию) баш свежее твоего в линуксе :)

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

19. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Nas_tradamus (ok) on 15-Мрт-16, 22:52 
Можно написать демон (хоть на шеле), который будет измерять счетчики pf по sport и dport и добавлять/удалять правила в rdr.
Я anti-ddos такой видел :)

Не знаю, есть ли в линуксовом iptables/netfilter что-то вроде round-robin.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

21. "В nginx появилась поддержка балансировки UDP-соединений "  +1 +/
Сообщение от Аноним (??) on 15-Мрт-16, 23:40 
> Не знаю, есть ли в линуксовом iptables/netfilter что-то вроде round-robin.

Там много чего есть, один только список модулей на два экрана.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

39. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от loskiq (ok) on 24-Мрт-16, 18:21 
Классно было бы, если б сайт мог работать через UDP, а не через TCP.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

40. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Andrey Mitrofanov on 24-Мрт-16, 18:43 
> Классно было бы, если б сайт мог работать через UDP, а не через TCP.

Не отвлекаться, http/2 вам в дышло!

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

41. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от loskiq (ok) on 24-Мрт-16, 20:09 
>> Классно было бы, если б сайт мог работать через UDP, а не через TCP.
> Не отвлекаться, http/2 вам в дышло!

Он не поддерживает UDP =/

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

25. "В nginx появилась поддержка балансировки UDP-соединений "  +/
Сообщение от Аноним (??) on 16-Мрт-16, 01:51 
Был неплохой вебсервер, теперь убогий комбайн.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "В nginx появилась поддержка балансировки UDP-соединений "  +2 +/
Сообщение от Какаянахренразница (ok) on 16-Мрт-16, 08:27 
> Был неплохой вебсервер, теперь убогий комбайн.

Никто не заставляет нацеплять все цацки сразу.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

33. "В nginx появилась поддержка балансировки UDP-соединений "  –1 +/
Сообщение от Аноним (??) on 16-Мрт-16, 11:39 
Был неплохой веб-сервер который решал одну очень узкоспецифическую задачу, а для остального приходилось городить зоопарк. Теперь есть неплохой веб-сервер, который решает все задачи - красота.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру