Rootconf2016 nginx-lua-balancing

Умная балансировка
нагрузки на базе Nginx и
Lua
Андрей Кононов, Solution architect at EPAM systems

Disclaimer
Чем больше мы познаём неизменные законы природы,
тем всё более невероятными становятся для нас чудеса.
Чарльз Дарвин.
Все используемые технологии – опенсорс
Все совпадения с реальными компаниями и
брендами случайны.

Какая балансировка бывает
• L7 (DNS, http)
• L4 (TCP)
• L3 (BGP)
TCP/HTTP
VRRP
DNS
BGP

Стартовая позиция
• Нет балансировки
• Всё работает
• Фичи пилятся

Надо быть защищёнными, но…
1. Поддержки SSl нет
2. Надо разработать

Надо что-то придумать
Появился Nginx

Ничто не предвещало…

НО пришла корпорация добра!
TIME
RESPONSE TIME, MS

• DNS балансировка

0
500
1000
1500
2000
2500
3000
3500
requests
time
requests/server
app1 app2

Жизнь продолжается

Балансировка курильщика
0
1000
2000
3000
4000
5000
6000
7000
8000
Requests /server
app1 app2 app3 app4 app5

Основные проблемы с DNS балансировкой
• Постоянные выигрыши в лотерею

• UDP не безграничен (512 bytes)

• Само по себе распределение не ровное

• Само по себе распределение не ровное
• Нужен другой балансировщик

Вендорский Балансировщик!

Балансировка нормального человека
2200
2300
2400
2500
2600
2700
2800
2900
3000
3100
requests/server

НО Вендоры не без греха!
• Vendor lock

• Vendor lock
• ELB на L4 не отправляет клиенту нотификации
о разрыве соединения

• Vendor lock
• Нет поддержки SNI (один сертификат - один IP)

• Vendor lock
• На L7 нет возможности реализовать хотелки

• Vendor lock
• На L7 нет возможности реализовать хотелки
• Не нулевая вероятность получить на свои
сервера чужой трафик.

Подоспели новые требования.
• Новое требование от бизнеса –
всегда показывать пиксел

• Появился полноценный
балансировщик

• Появился полноценный
балансировщик
• Нужно быть ближе к пользователю
• КАК бы CDN

GDNSD
• DNS балансировщик
• 100% opensource
• Авторитативный днс сервер
• Геобазы нескольких провайдеров
• Встроенные проверки состояния приложения

Rootconf2016 nginx-lua-balancing

Никто не ждал но…..
• Взрыв мониторинга.

• 100 gb за 2 часа error log
• LA > 8 (8 cores instance)
used space

• 100 gb за 2 часа error log
• LA > 8 (8 cores instance)
main.all.http_1xx = 0

Продолжаем развиваться !
• Бизнес хочет странного, а именно - что то типа сессий

• Ограничения – никакого сессионного хранилища
• Минимальное перераспределение пользователей
при добавление ноды.

• Ограничения – никакого сессионного хранилища
Включаем Ip_hash method в nginx

• Бизнес хочет странного, а именно - что то типа сессий.
• Ограничения – никакого сессионного хранилища.
Включаем Ip_hash method в nginx
0
1000
2000
3000
4000
5000
6000
7000
8000

Балансировка - не только балансировка
SSL offload

SSL offload
Pixel

SSL offload
Pixel
Redundancy

SSL offload
Pixel
Redundancy
Geo distribution

SSL offload
Pixel
Redundancy
Geo distribution
Easy configuration

SSL offload
Pixel
Redundancy
Geo distribution
Automatic add/remove nodes

SSL offload
Pixel
Redundancy
Geo distribution
Automatic add/remove nodes
oStickiness

• Consistent Hash !
https://en.wikipedia.org/wiki/Consistent_hashing
David Karger

Мозговой штурм, выбор не велик
• 1. Компилируемый модуль

Мозговой штурм, выбор не велик
• 1. Компилируемый модуль
2. Логика на LUA

Забег по граблям
• Генерили много точек по умолчанию - начала кончаться память

Решение – динамическая генерация количества точек

• 1 worker отказ в обслуживании при добавлении

• 1 worker отказ в обслуживании при добавлении
Решение “cpu_count-2” workers на балансировщик

Продолжаем бежать
• Fallback не фолбечит

• Fallback не фолбечит
Решение – перенос в отдельный процесс нджинкс

• Внутренний хелфчек не способен
добавить много хостов (массовый
деплой например), полная
деградация целиком сервиса
запросы становятся в очередь, вот
это всё

• Внутренний хелфчек не способен
добавить много хостов (массовый
деплой например), полная
деградация целиком сервиса
запросы становятся в очередь, вот
это всё
Решение – инкрементальный
пересчёт consistent hash

Пример конфигурации nginx
location / {
...
proxy_pass http://$best_upstream;
...
}
upstream app1 {
…
server app1 max_fails=n fail_timeout=k;
server unix:/var/run/nginx_fallback.sock backup;
}
upstream app2 {
…
server app2 max_fails=n fail_timeout=k;
server unix:/var/run/nginx_fallback.sock backup;
}

Итоговая архитектура.

Выводы
• Хорошая балансировка всегда знает о приложении довольно
много
• Нагрузочное тестирование
• Ну и конечно здравый смысл

Links
1. http://luajit.org
2. http://nginx.org
3. https://github.com/openresty/lua-nginx-module
4. https://github.com/openresty/lua-upstream-nginx-module
5. https://github.com/goldenclone/nginx-sla
6. http://gdnsd.org
GDNSD

Всем Спасибо!
akononov.job@gmail.com

Rootconf2016 nginx-lua-balancing

More Related Content

What's hot (20)

Similar to Rootconf2016 nginx-lua-balancing (20)

Rootconf2016 nginx-lua-balancing