Comments 33
А почему не попробовали tengine? Это форк nginx от alicloud, и он умеет многие фичи nginx+, в том числе мониторить живость апстримов.
Это уже вопрос доверия к кодовой базе и её сопровождению. Все проблемы с тем же haproxy (там был сложный период большого рефакторинга, после которого появился рабочий nbthreads) мейнтейнеры решали в пределах недели после баг репорта. Один раз даже сообщил о баге в пятницу вечером, а в субботу уже был патч. И это без платного контракта.
Были ли у вас прецеденты решения проблем с авторами tengine? Есть ли какая-то статистика?
https://angie.software/ выглядит привлекательнее tengine, как мне кажется, да и API у него имеется.
Кстати интервью с разработчиками сегодня опубликовали: "Интервью с Валентином Бартеневым: как бывшие сотрудники Nginx разрабатывают отечественный веб-сервер Angie"
Я бы такое сделал на Nginx + Consul + Consul Template. Это позволит еще и онлайн управлять списком апстримов.
В сети 127.0.0.1/8 около 16млн. адресов, IPv6 вам не был нужен. Адреса навешивать на lo интерфейс не обязательно, просто биндитесь к 127.0.0.2, 127.0.0.3 и пр., и заносите их в /etc/hosts, если нужно.
Тут есть интересный момент. Так как на lo-интерфейсе висит адрес 127.0.0.1 (с маской /8), то при подключении к 127.0.0.2, например, будет образовано соединение между 127.0.0.1:клиентский_порт и 127.0.0.2:серверный _порт. Что все равно ограничивает доступное количество клиентских портов. С отдельным /128 адресом на lo-интерфейсе такого уже не произойдет, так как соединение будет с того же адреса.
Ну и бардак с адресами, как я писал, в случае 127.0.0.2 и т.д. будет редкостный. Ipv6 позволяет лучше все упорядочить.
Посмотрите на angie, это форк nginx с большим количеством полезных доделок. Статистика, к примеру
Чуть выше отвечал про tengine – форки интересные есть, но очень много вопросов возникает при "промышленном" использовании:
* А если протестированная под nginx конфигурация под angie поведет себя как-то иначе?
* А тестировали ли они свой проект под теми нагрузками, которые нас интересуют? А вытянет сто бекендов, а тысячу?
* А как там с аудитом кода на безопасность?
* А как быстро ответят на вопрос о проблеме и починят найденный баг?
* А будет ли проект поддерживаться через год-другой?
Если брать широко используемые инструменты всё становится несколько проще. Ну или уже писать своё, если есть ресурсы.
Большая часть вопросов должна отпасть, если учесть, что Angie разрабатывает та же команда, что до этого 10 лет разрабатывала nginx.
@VBart Уже ответил. Уверен что если для Вас действительно важны все эти вопросы, то парни из Angie с удовольствием продадут вам платную поддержку. Как я понимаю, весь смысл Angie в том, чтобы можно было покупать платную поддержку "nginx" в России. Плюс появление тех фич, которые F5 не хотят делать по причине конкуренции с их платными фичами. Соответственно те, кто платит за Angie, опосредованно платят за разработку открытой версии. Можете присоединиться =)
nginx и haproxy надо местами поменять и всё будет хорошо.
А что, конкретно, вы считаете улучшится?
это было бы бессмысленно. Тогда уж haproxy убрать, если в нем нет нужды.
ты точно читал причину появления haproxy?
прочитал еще раз, и не по диагонали. Я думал что haproxy первым стоял, а там nginx первым, еще и на том же хосте. Мне бы такое в голову не пришло, это использование haproxy не по назначению. Поддерживаю - поменять их местами, а еще лучше nginx с этого хоста убрать (или вообще его убрать, он же только проксирует?), если нагрузка такая значительная.
PS ТЫ пиши в следующий раз нормально, чтобы было понятно что ты имеешь в виду.
У меня сложилось впечатление, что nginx там ещё что то делает. Типа статику раздаёт. Если это не так то...
Всё перепуталось :)
* Начальный вариант: есть хост с nginx который работает с бекендами на других хостах. На Nginx довольно сложные конфиги с кучей locations, рерайтов, редиректов, зависимостей от заголовков и прочих фронтендных радостей. Там же секции upstream со всеми бекендами. Это все, конечно, можно попотеть и перенести на haproxy. Но потом это все еще и придется поддерживать. А, к сожалению, "читабельность" сложных конфигураций у haproxy значительно ниже, чем у nginx.
* Конечный вариант: nginx с прежними сложными конфигами и теми же владельцами, но с upstream, по сути из одной строчки, смотрящей на haproxy, который живет на том же хосте, что и nginx. Конечные бекенды по прежнему удаленные и о них знает только haproxy.
По итогу мы можем править бизнес-логику на nginx и логику распределения на haproxy. Каждый продукт занимается своим делом.
Кто-нибудь уже предложил использовать kubernetes вместо RHEL 5 для комплексного решения проблем? Сервисы на ipvs явно производительнее haproxy, есть хэлсчеки и все что надо для счастья, внешний nginx на ingress controller и внутренние - с костылями дополнительной логикой.
Angie, к слову, вынес в коммерческую версию всё ровно то, что есть в Nginx Plus
А почему такой взлет ошибок на 1МБ ответе в режиме "все бэкенды доступны"? Работа без кэша, что ли?
Максим, а можете, пожалуйста, немножко развернуть мотивацию такого бутерброда? В предисловии к статье я вижу три пункта:
Коммерческая версия Nginx предлагает решение в виде проверок работоспособности из модуля ngx_http_upstream_hc_module: периодически запрашивается какой-то URL (или просто пытается открыть порт), и, если тот или иной бэкенд не отвечает, его временно исключают из рабочего списка.
tengine предоставляет модуль активных хелсчеков: https://github.com/alibaba/tengine/tree/master/modules/ngx_http_upstream_check_module
ограничение на количество одновременных запросов к бэкенду, а точнее — помещение запросов, превышающих лимиты, в очередь для последующей обработки.
Это решается и в опенсорсной версии в ngx_http_limit_req_module: limit_req zone=... burst=... без ключа nodelay.
Вы знаете его пределы и, например, не хотите пускать больше ста пользователей за раз
Если же подразумевалось, что инстансы nginx должны иметь синхронизированные счетчики - то не проще ли не решать это вовсе, а воспользоваться рейтлимитером на стороне приложения? Тем более, что известны его пределы. Причем в качестве примера приведено вообще единомоментное количество пользователей, а не rps - то есть вообще другой домен, который с ограничением rps связан слабо.
отсутствие встроенного способа получения вменяемой статистики по распределению трафика по бэкендам
Это же решается с https://github.com/vozlt/nginx-module-vts
Т.е. вижу что, но не могу понять зачем
VTS тоже не совсем настоящие метрики экспортирует, к примеру данные о запросе можно получить только после того, как он будет завершён, а сколько запросов обрабатывается в данный момент непонятно. Это почти тоже самое, что и логи парсить...
У Angie есть модуль prometheus который позволяет экспортировать более точные метрики.
Спасибо за интересный вопрос, на "почему не XXX" всегда сложно отвечать, так как вариантов много, они все замечательные и можно долго спорить :) Пройдемся по пунктам:
* Проверки работоспособности бекендов. На мой взгляд, tengine, как и любой другой форк, это уже не совсем nginx. Можно доверять проекту и использовать его, но кодовая база – иная и развиваемая в интересах одного конкретного клиента. В нашем случае – это было важно. О причинах я писал в комментариях выше (поддержка, аудит кода, совместимость, и т.д.). Впрочем, agent_check и возможности динамического изменения весов в tengine кажется все равно нет (выкручусь я). Или есть?
* Одновременные запросы к бекенду. limit_req прекрасен, но он все таки, как вы верно заметили про RPS, а не про одновременное количество запросов, которое сервер выдержит. К примеру, если сервер отвечает за 10 мс, но умирает по памяти на 101 одновременном клиенте, то при 200 запросах в секунду мы можем как выжить, так и не выжить – как повезет. С другой стороны, если мы гарантируем, что больше 100 запросов на сервер не будут переданы еодиномоментно – 10000 RPS вполне могут быть обслужены. Всё зависит от сценария и иметь обе возможности в доступности – вдвойне замечательно.
* "синхронизированные счетчики". Я, извините, не очен понял – это вопрос про agent_check и веса? Или про встроенные в haproxy распределенно-синхронизируемые счетчики?
* Про VTS уже за меня ответили – haproxy все-таки тут более открыт для анализа. Да я и говорил "отсутствие встроенного способа получения вменяемой статистики", т.е. внешние существуют, но на них придется завязываться, а тот же VTS даже сейчас в версии 0.2.2, что нисколько не умаляет его заслуг, но несколько лишает уверенности.
А теперь попробую ответить на "зачем". Главный плюс, который мы получили от такого бутерброда, если убрать в сторону тактические преймущества конкретных продуктов, – разделение зон ответственности. Мы растащили собственно работу с бекендами и бизнес-логику сайтов. В результате, все тот же nginx можно было легко заменить на любой другой подходящий прокси-сервис, если того требовала задача (и мы так делали), а доставка трафика от бекендов при этом никак не менялась. И наоборот – различные конфигурации бекендов для различных локаций никак не отражались на конфигурации nginx, что очень упрощало и делало более безопасной его настройку.
Да, хороший бутерброд, работает. Использовали такой лет пять, сейчас перешли на кубернетсовский ингресс nginx
Вероятно, я не совсем корректно понял введение в статью, но тем не менее, почему nginx+haproxy? Почему бы не оставить просто haproxy, если он так же может проксировать? Также, было бы не плохо добавить в графики результаты тестов с одним лишь haproxy.
Для сложной бизнес логики haproxy сложно конфигурировать и этому придется учить людей, тогда как конфиги nginx умеют делать в том, или ином виде многие. Можно разделить зоны ответственности и взять лучшее от двух продуктов.
Вот об этом хотелось рассказать и о том, чего это будет стоить. А лобовых сравнений nginx и haproxy по производительности довольно много. Спойлер: они зависят от того, кто и как тестирует :) Но, в целом, если усреднить, результаты близки и выбирать нужно по каким-то другим факторам.
Улучшаем возможности Nginx без затрат на коммерческую подписку (спойлер: с помощью Haproxy)