Состоялся (http://mailman.nginx.org/pipermail/nginx-announce/2018/00021...) выпуск новой основной ветки nginx 1.15.1 (http://nginx.org), в рамках которой продолжается развитие новых возможностей (в параллельно поддерживаемой стабильной ветке 1.14 (https://www.opennet.me/opennews/art.shtml?num=48454) вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей).Основные изменения (http://nginx.org/en/CHANGES):
- В блоке "upstream" реализована новая директива "random (http://nginx.org/en/docs/http/ngx_http_upstream_module.html#...)", при помощи которой можно организовать балансировку нагрузки со случайным выбором сервера для проброса соединения;
- Увеличена производительность при исопльзовании директив "hash" и "ip_hash" вместе с директивой "zone";
- Выставление параметра "reuseport" в директиве "listen" теперь приводит к установке флага SO_REUSEPORT_LB во FreeBSD 12;
- Решены проблемы с несрабатыванием операции HTTP/2 server push, если SSL-соединение прерывалось прокси, стоящим перед nginx;- Исправлена ошибка, из-за которой директива "tcp_nopush" всегда применялась при соединениях с бэкендом;
- Устранена ошибка, из-за которой могли возникать сбои при отправке буферизированного на диске тела запроса к бэкенду gRPC.URL: http://mailman.nginx.org/pipermail/nginx-announce/2018/00021...
Новость: https://www.opennet.me/opennews/art.shtml?num=48898
Не совсем понятно как будет вести себя random в upstream-е при реальных нагрузках !
Рандомно. Ван кэп.
Вопрос от неспециалиста: в чём ключевые преимущества рандома перед другими методами балансировки?
При использовании 'random two' можно добиться более ровного и предсказуемого распределения в кластере (когда используется >1 сервера nginx)
> При использовании 'random two' можно добиться более ровного и предсказуемого распределения
> в кластере (когда используется >1 сервера nginx)А round-robin чем хуже? Тоже равномерно, но проще и предсказуемее. Ниже написали, что может спасти от DDOS'а. Это на практике реально так, или это предположение?
Представьте, что у вас 10 нжинксов и 10 бекендов, на каждый из нжинксов приходит 1 запрос в секунду. И так получилось, что состояние раунд робина случайно синхронизировалось на всех нжинксах. В результате каждую секунду мы получаем 10 запросов на один бекенд, и ни одного - на оставшиеся 9. Рандом позволяет избежать такой ситуации.Про ддос как-то сомнительно, от нормального ддоса нжинксом не защититься никак.
Зачем с 10 фронтов распределять запросы по 10 бекендам? Как распределяется нагрузка на сами фронты? Для каждого фронта свой бекенд, и один как бекап.
Нагрузку на фронты обычно распределяют днс раунд робином или каким-то балансировщиком перед нжинксами. Количество фронтов и бекендов назовите сами, я привел гипертрофированный пример, чтобы показать что в кластере рандом лучше раунд робина.
Мысль о 10 Nginx'ах и распределении нагрузки ещё и по ним даже в голову не приходила. Спасибо за просвещение.
Вообще не понимаю зачем рандом нужен..
К примеру есть 2 сервера, на которые рандомно что-то распределяется..
шанс того что 5 запросов подряд прилетит на 1 сервер 2^5 = 1 к 32-мРандом это хуже чем равномерная нагрузка
Да, но если кто-то хочет гарантированно заддосить, то при равномерной нагрузке нужное количество запросов убъет обе ноды, а при рандоме одна нода умрет, а вторая может еще дышать.
SO_REUSEPORT_LB - ждал когда к нам завезут, теперь надо понять как с этим жить.
Главное подсунуть правильный генератор рандомных чисел ;)
haproxy может даже лучше в балансровку и не нужно nginx-plus за килобаксы подписки.
Наконец рандом, давно ждали. Самый эффективный вид балансировки на малом рпс, но большом количестве nginx