|
Октябрь 24, 2006
03:08 pm - зачем нужен nginx
Меня периодически спрашивают зачем нужен nginx и зачем вообще нужна схема фронтенд-бэкенд
Писать полноценную статью пока времени(желания) нету, поэтому приведу здесь выдержки из обсуждения этого вопроса в mstu.unix (в сильно переработанном виде)
Для начала хочу заметить что главная причина использование схемы фронтенд-бэкенд - эффективное использование ресурсов. Актуально это прежде всего для веб-порталов с большим количеством посетителей. Если на вашем сервере меньше 10 http-запросов в секунду, то можно продолжать использовать apache без фронтенда и не тратить силы и время на построение схемы фронтенд-бэкенд.
Q: а нафиг нужен nginx, есть же апач?
A: nginx и apache это совершенно разные сервера для разных задач, и сравнивать их некорректно. nginx предназначен для раздачи статики и использования в качестве фронтендов. Apache при этом можно использовать в качестве бэкенда для генерации динамического контента.
Если клиентов пускать напрямую к бэкенду (например apache+mod_perl) без фронтенда, то серверов под бэкенды потребуется в несколько раз больше.
Q: Почему nginx работает эффективнее чем apache при раздаче статического контента.
A: Для того, чтобы было понятно о чем пойдет речь ниже нужно понимать какие модели сетевых серверов бывают и чем они отличаются. Читать тут: RU.UNIX.PROG FAQ - приложение 1: как писать сервера
A:
1. apache 1.3 использует preforked модель (чем плох apache2 отдельная тема), а nginx для обработки соединений использует FSM, причем для обработки соединений могут использоваться очень эффективные методы kqueue (BSD), epoll (Linux).
2. Для отдачи файлов используется sendfile()
3. Автор nginx уделяет большое значение оптимизации. На обработку одного http-запроса делается заметно меньше системных вызовов, чем в других серверах (для примера сравните truss nginx и thttpd, при раздаче статических файлов - thttpd делает больше вызовов, хотя в остальном похож). Надеюсь не надо объяснять что каждый системный вызов это переключение контекста и чем их меньше, тем лучше.
Q: Зачем нужно разделение на фронтенд-бэкенд, почему нельзя запросы к динамическим страницам сразу раздавать apache+mod_perl (или что там используется для генерации динамики)
A: Проще объяснить на примере:
Представим себе такую ситуацию - у нас 1000 клиентов, которые медленно
забирают странички.
В случае апаче - мы имеем 1000 процессов httpd и кучу переключений контекста с этим связанных. Плюс каждый httpd кушает кучу памяти из за того, что обрабатывает php/perl скрипты, а все вместе 1000 процессов будут кушать нереально большое количество памяти.
И при этом каждый процесс будет заниматься 0.1 секунду генерацией ответа, а 10 секунд тем, что будет отдавать ответ клиенту. В итоге мы имеем очень низкий КПД и большую нагрузку на сервер.
Теперь поставим прослойку в виде nginx перед апачем. Допустим у нас есть один рабочий процесс, для проксирования этого вполне хватит.
Приходит запрос клиента. nginx сначала его дожидается (это тоже может быть долго), потом максимально быстро передает запрос бэкенду (апачу) и максимально быстро читает ответ. В итоге апач на каждый запрос занят не 10 секунд, а 0.1 секунду и процессов httpd у нас будет не 1000 а 10.
Ответ при этом буферезируется в nginx но объем ответа обычно в несколько раз меньше чем объем процесса на бэкенде (httpd+perl,php или даже java), который этот ответ создал, поэтому память будет очень заметно экономится.
Разумеется это не нужно если все клиенты подключены каналом 100 Мбит или быстрее, но на практике это не встречается. Обычно у клиентов достаточно медленные каналы. Если не dial-up, то в лучшем случае 128 - 256 Кбит. А при такой скорость ответ веб-сервером генерируется быстрее чем его успевает забрать клиент.
Может возникнуть вопрос почему nginx может использовать один процесс для обслуживания тысяч клиентских подключений, а бэкенд (сервер которые генерит динамику, например apache+mod_perl) не может. nginx для обработки клиентских соединений использует FSM (конечный автомат) - это очень эффективная модель, но она имеет ряд ограничений. Нельзя использовать системные/библиотечные вызовы которые надолго блокируются или надолго требуют много CPU (т. е. любые операции которые по разным причинам требуют много времени). Генерация динамического контента таким образом не может быть выполнена с использованием FSM. Поэтому для этого используется Prefork или потоки. apache13 использует prefork - на каждую клиентскую коннекцию по процессу, а процесс как говорилось выше это тяжелый объект. В apache2 можно использовать треды но у них свои проблемы. В первую очередь php/perl в тредовом режиме работают очень ненадежно, если вообще работают...
Q: Почему для проксирования запросов на бэкенд стоит использовать nginx, а не squid
A:
1. nginx это не только proxy, он может часть запросов (на статику) обслуживать сам, а часть проксировать. Причем те uri, которые (не)нужно проксировать могут заданы по regexp.
2. nginx имеет большие возможностей по конфигурированию, характерные для веб-серверов, но отсутствующие в обычных proxy-серверах.
3. nginx использует эффективную FSM и хорошо оптимизирован (в плане экономии системных вызовов).
|
Comments:
![[User Picture]](http://l-userpic.livejournal.com/13703899/1896181) | | From: | ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) nuclight |
|---|
| Date: | Октябрь 25, 2006 01:47 pm none (UTC) |
|---|
| | | (Link) |
|
1) Тема тараканов апача 2.х была бы интересна
2) Ждем статью-таки :)
![[User Picture]](http://l-userpic.livejournal.com/76798715/5654716) | | From: | zerg85 |
|---|
| Date: | Октябрь 25, 2006 02:09 pm none (UTC) |
|---|
| | | (Link) |
|
+1
| | From: | nuclight |
|---|
| Date: | Ноябрь 4, 2006 05:01 pm none (UTC) |
|---|
| | | (Link) |
|
Хм. Там в основном возражения против тредов вообще. Это правильно, но я ожидал чего-то более специфичного для апача.
| | From: | nuclight |
|---|
| Date: | Ноябрь 4, 2006 08:47 pm none (UTC) |
|---|
| | | (Link) |
|
Хм. Там в основном возражения против тредов вообще. Это правильно, но я ожидал чего-то более специфичного для апача
![[User Picture]](http://l-userpic.livejournal.com/83396990/932552) | | From: | iskatel |
|---|
| Date: | Декабрь 26, 2006 02:24 pm none (UTC) |
|---|
| | | (Link) |
|
А light httpd / thttpd не лучше nginx ?
Они все же стабильны , в отличие от постоянно совершенствующегося nginx..
![[User Picture]](http://l-userpic.livejournal.com/27644895/340434) | | From: | deka |
|---|
| Date: | Декабрь 26, 2006 05:07 pm none (UTC) |
|---|
| | | (Link) |
|
nginx молодой ещё до "развивающегося". Скорее "в процессе подготовке релиза". Да, пугает, но пока зарекомендовал себя весьма стабильно. Что касается lhttpd и thttpd, боюсь соврать, но первый активно гонится за фичами, рискуя превратится в "апач1.3 номер 2", так было по крайней мере некоторое время назад, после чего я потерял к нему интерес (так меня и апач13 устраивает вполне), а второй кроме как раздавать статику и CGI ничего не умеет. Одно отсутствие https уже исключает его из списка юзабельных программ ;)
| | From: | iskatel |
|---|
| Date: | Декабрь 26, 2006 07:22 pm none (UTC) |
|---|
| | | (Link) |
|
ТАк нет у nginx стабильных веток.. Вообще нет. Постоянное добавление нового и исправления в одном флаконе. Что плохо. ( Меня и апач 2, и апач 2.2 устраивают, когда они в виде стабильных веток (типа веток в RHEL).)
Поддержание отдельно стабильной ветки и отдельно девелоперской требует дополнительных ресурсов. В целом nginx работает достаточно стабильно. Просто перед переходом на новую версию (если это действительно нужно и в новой версии появилось что то полезное), надо протестировать в условиях максимально приближенных к рабочим. Для этого можно, например запустить новую версию nginx с отдельным конфигом на другом ip или порту и немного погонять. Даже если проблемы после обновления обнаружатся только в продакшене легко вернуться к старой версии (если при обновлении не убивать старый процесс а оставить его висеть в памяти) - http://sysoev.ru/nginx/docs/control.html#upgradeНовые баги как правило находятся когда кто то начинает использовать nginx в такой конфигурации, которая ранее не использовалась. И стоит заметить ошибки достаточно оперативно исправляются.
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 08:58 am none (UTC) |
|---|
| | | (Link) |
|
Пока нет. Да, немного неприятно, но всему своё время. Тем не менее его стабильность меня вполне устраивает, а о производительности я и не говорю -- апач отдыхает. Даже апач13. Что до апача-2, я вполне согласен с приведёнными выше доводами -- треды есть зло, а если пользовать префорк -- апача-13 более чем достаточно, а апач2 жрёт больше ресурсов.
| | From: | iskatel |
|---|
| Date: | Декабрь 27, 2006 12:09 pm none (UTC) |
|---|
| | | (Link) |
|
Треды есть правильное решение, но не везде они сделаны хорошо.
FSM работает эффективнее тредов. Другое дело что некоторые задачи очень сложно либо совсем нельзя реализовать в виде FSM. Тредовое приложение написать значительно проще чем FSM, но сложное тредовое приложение без багов это что то из области фантастики.
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 12:44 pm none (UTC) |
|---|
| | | (Link) |
|
На мой взгляд основная сложность FSM в том, что очень тяжело подобрать оптимальный таймаут с учётом производительности системы и её загрузки. Но по сравнению с проблемами тред-ориентированного кода это семечки.
| | From: | iskatel |
|---|
| Date: | Декабрь 27, 2006 01:53 pm none (UTC) |
|---|
| | | (Link) |
|
совсем без багов не бывает 8=)
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 12:41 pm none (UTC) |
|---|
| | | (Link) |
|
Они:
- Далеко не везде сделаны хорошо. Кроме солярки я вобщем-то никого (из тех, у кого с тредами "хорошо") и не назову, линух вот чуть-чуть подтягивается, но отстаёт, как телега от феррари. Про *BSD вообще молчу.
- Тредовые приложения народ писать не умеет.
Поскольку, как было замечено, префорк лучше тредов хотя б потому, что крэш чайлда срубает одну сессию, а крэш треда роняет всю задачу, и с учётом вышесказанного мной, повторюсь: треды есть зло. Меня в этом никто не переубедит в ближайшее время ;)
У FSM есть такая сложность. Нельзя использовать никакие операции
которые надолго блокируются. Например общение в Memcached идет через tcp-сокеты которые в принципе могут работать в неблокирующемся режиме. Но если использовать libmemcached то с точки зрения того, кто использует её API все операции будут блокирующимися. Поэтому для использования memcached в nginx Игорь писал свою библиотеку для работы с Memcached в рамках FSM. И так практически со всем - если в рамках FSM захочется делать запросы к mysql придется писать свою асинхронную libmysql, что есть задача очень непростая.
Операции требующие длительной работы CPU тоже использовать нельзя - их нужно вручную разбивать на небольшие "кусочки", чтобы между выполнении отдельных "кусочков" приложение успевало работать с сокетами - читать/писать данные.
Из за этого вместо использования готовых библиотек приходится во всем изобретать велосипед. Возможно со временем появятся библиотеки заточенные на использование в рамках FSM но это маловероятно.
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 04:44 pm none (UTC) |
|---|
| | | (Link) |
|
Строго говоря, одна из проблем тредовых аппликаций похожа на эту: не так много библиотек действительно thread-safe.
- thttpd - имеет значительно меньшую функциональность чем
nginx. Главным образом он не поддерживает проксирование. Ну и кучу
других фич таких как SSL, SSI, Rewrite и т. п. И на сколько я помню он
не поддерживает keep-alive соединения (хотя могу и ошибаться, в
рамках архитектуры thttpd это возможно реализовать). И даже на раздаче
статики он работает немного хуже nginx. Игорь уделяет очень большое
внимание оптимизации, на счету буквально каждый системный вызов - на
запрос к статическому файлу thttpd трати больше системных вызовов, чем
nignx. Плюс еще nginx один из немногих веб-серверов, который не
перестает работать (под большой нагрузкой) если заканчивается место на
разделе с логами.
- lighttpd - фичь в нем не много, а очень много, но насколько
знаю пока не умеет таких вещи как сжатие ответов через deflate и
перекодировка ответов из одной кодировки в другую. Что касается
перекодировки остановлюсь поподробнее. Внутри проектов удобно иметь
кодировку UTF-8, поскольку в ней можно отобразить почти все
необходимые символы. Но при передаче по сети текста (если не учитывать
сжатия через deflate которое принимают не все клиенты) в кодировке UTF-8
он имеет объем почти в два раза больше чем в кодировке cp1251 или
koi8-r. Большинство клиентов используют кодировку cp1251 и если
выбирать из koi8-r и cp1251 отдавать клиенту лучше в cp1251. Вот тут
то и нужен nginx - он получает ответ от бэкенда в UTF-8 и на лету
перекодирует его в cp1251, при этом символы которых нет в UTF-8
заменяются на html-entities, поэтому ничего не теряется.
И еще есть тесты, которые показывают, что nginx немного быстрее чем lighttpd
| | From: | iskatel |
|---|
| Date: | Декабрь 26, 2006 08:04 pm none (UTC) |
|---|
| | | (Link) |
|
была б еще стабильная ветка nginx - было бы прекрасно. Но её нет.
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 09:04 am none (UTC) |
|---|
| | | (Link) |
|
Дык будет. Сысоев же пока один в основном над ней работает. Насколько я знаю. Как возникнет некий комьюнити разработчиков -- так и дело пойдёт пошустрее ;) А меня не очень пугает, что апдейты и фичи в одной ветке -- так практически у всех.
| | From: | iskatel |
|---|
| Date: | Декабрь 27, 2006 12:07 pm none (UTC) |
|---|
| | | (Link) |
|
>> Сысоев же пока один в основном над ней работает.
Это-то и плохо.
В общем, для не-SSL статики выбор решений по-любому широк..
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 12:37 pm none (UTC) |
|---|
| | | (Link) |
|
Ага, только спектр применения не-SSL статики с каждым днём всё уже и уже...
| | From: | iskatel |
|---|
| Date: | Декабрь 27, 2006 01:51 pm none (UTC) |
|---|
| | | (Link) |
|
да ну? все публичные сайты без логинов-паролей. нагрузка велика, ssl нету.
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 02:29 pm none (UTC) |
|---|
| | | (Link) |
|
Очень сильно ошибаешься.
| | From: | iskatel |
|---|
| Date: | Декабрь 27, 2006 03:02 pm none (UTC) |
|---|
| | | (Link) |
|
В чём именно?
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 03:09 pm none (UTC) |
|---|
| | | (Link) |
|
В оценке значимости статического контента, если сразу к делу ;)
| | From: | deka |
|---|
| Date: | Декабрь 29, 2006 01:53 pm none (UTC) |
|---|
| | Вот появилось время ответить развёрнуто. | (Link) |
|
Итак, по порядку.
1. Логины-пароли к динамическому контенту никакого отношения не имеют. Начнём с того, что логины-пароли могут и броузером запрашиваться, и вообще процедура авторизации может находиться в скрипте, но это может быть единственное активное server-side приложение. Но это так, штрих к.
2. Я уже писал об отношении к не-SSL серверам. С моей точки зрения их полезность бесконечнго мало отличается от нуля.
3. Единственное, для чего может быть полезен thttpd -- это для передачи охрененно больших файлов. Тут оно как: есть вебовое приложение, которое в частности тебе должно отдавать файлы. Если отдавать файл им же -- ты нагрузишь сервак дурной работой, с которой вполне может справиться мелкий сервачок. Ну разве что после какой-то идентификации. Пример -- всякие рапид-шары и проч: тебе генерят тикет для съёма файла и перекидывают на очень dumb сервак, который проверяет тикет, и если всё ок, высылает тебе файл. В своей работе похожее было, когда у нас сервер приложений был на Zope, и надо было отдавать крупные файлы -- трейлеры к фильмам. Помимо того, что если всё делалось зопом, он эти файлы кидал в свою базу, так ещё и при отдаче грузил объект из базы в память, что, разумеется, не шло на пользу. Тогда мы решили проблему отдельно построенным апачем (из которого было исключено всё ненужное). Почему не thttpd? А потому что ребята тогда на него не наткнулись, а я про него забыл ;)
4. Что касается "публичных сайтов" -- сейчас сайтов типа "визиток" практически нет. Разве что промоушновые какие-нить, да и то там что-нибудь типа форума или гостевой вставлено. Причина? А всё просто -- сайт, он как ПК. одним он нужен для игрушек, другим как инструмент в профессиональной деятельности. Первый случай рассмотрим отдельно, разберёмся со вторым. Если сайт -- это инструмент, он должен каким-то образом привлекать посетителей. Это можно сделать только двумя способами: чисто промо-сайт, завлекающий своей красотой и оригинальностью, или завлекать сервисами и контентом. Во втором случае разговор как раз о динамическом контенте и веб-приложениях различного масштаба. В первом разговор об оригинальном дизайне, чаще всего авторском, это очень дорого, и позводить себе такое могут далеко не все. И вот именно во втором варианте сайт может быть без всяких выкрутасов прикладного характера.
5. Теперь -- почему я отдельно остановился на сайтах "ПК-игрушка". Это категория всякого рода домашних страничек "чисто для себя". Нагрузка на каждый отдельный такой сайт действительно мизерная, но и размещаются такого типа сайты чаще всего на масс-хостинговых площадках, и суммарная загрузка там может быть очень велика, особенно с учётом того, что на такого рода сайтах не только персональные странички, но и вполне себе релевантные сайты. Хостинговая площадка -- это целый кластер различных серверов, и чаще всего тоже делается по схеме "фронт+бэк" -- реальный контент лежит на бэке (ещё иногда и на разных бэках в зависимости от требуемых сайту сервисов), а фронт работает либо как прокси, либо комбинированно -- часть проксируется на бэк, часть работает как передатчик статики. И вот именно для такого комбинированного режима хорошо идёт nginx.
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 09:02 am none (UTC) |
|---|
| | | (Link) |
|
Ну лично я считаю, что выбор нутряной кодировки, внешней и процедура перекодирования всё же задача сервера приложений. А если проект в статике голимой, можно перекодировать вручную перед деплойментом. Задача же фронд-энда -- донести контент без потерь от клиента к серверу приложений (сиречь бэкэнду) и обратно. Упаковка на лету -- да, вполне полезно. Это я не против nginx-а, а так, штрих к портрету ;)
| From: | ospf_ripe |
|---|
| Date: | Декабрь 27, 2006 12:38 pm none (UTC) |
|---|
| | перекодировка: frontend vs backend | (Link) |
|
На бэкенде как правило используются такие языки как perl, php, ruby, phyton - на них перекодировка текста требует определенных ресурсов. В приложении на Си (nginx) это можно сделать эффективнее в плане расхода памяти и CPU. Для perl это подтверждается практикой, да и другие перечисленные языке в плане эффективного использования ресурсов AFAIK не намного лучше.
Даже когда перекодировка в perl происходит с использованием XS модуля под данные резервируется память которая после перекодировки висит мертвым грузом и используется только при последующих вызовов этой функции (у перлового аллокатора памяти несколько странные оптимизации имеются).
Вообще на бэкендах используются языки более "высокого" уровня чем C/C++ потому что там нужна гибкость - этот софт непрерывно развивается.
А перекодировка это такая задача, которую один раз написал, отладил и потом можно долго использовать без каких либо изменений. Поэтому для такой задачи хорошо подходит Си.
| | From: | deka |
|---|
| Date: | Декабрь 27, 2006 12:56 pm none (UTC) |
|---|
| | Re: перекодировка: frontend vs backend | (Link) |
|
Если бэкэнд написан на перечисленных языках -- да. Однако же время, когда более или менее серьёзные бэкэнды писались на них, заканчивается. У той же жабы, насколько помню, специально ничего перекодировать не надо -- достаточно "настроить" свойства входящего и отдаваемого потоков. К тому же сложное бэкэнд-приложение может использовать разные источники данных с разными свойствами (одна БД отдаётся юникодом, другая, например, вин1251, часть кода страницы генерится третьим приложением и внедряется в основной исходящий поток и так далее), и в этом случае "рулить" всеми нюансами на фронте, у которого, как справедливо замечено, задача быстро схватить, передать, получить ответ от бэка и отдать юзарю, по дороге обвешав статическими рюшечками, уже может оказаться весьма затруднительно. Так что, согласившись в частности, настою на своей версии как более общей ;)
| | From: | iskatel |
|---|
| Date: | Декабрь 27, 2006 01:56 pm none (UTC) |
|---|
| | | (Link) |
|
Отдача в чем-то , отличном от юникода - извращение. Пора, давно уже пора всё делать на utf-8. А не извращаться с наборами символов.
В конце концов, разница на том html мизерна, на общем потоке данных (графика и тд.), особенно с учетом сжатия html.
![[User Picture]](http://l-userpic.livejournal.com/11097853/707405) | | From: | al3x |
|---|
| Date: | Апрель 17, 2007 04:21 am none (UTC) |
|---|
| | можно вопросик? | (Link) |
|
Что автор имеет сказать по поводу nginx vs mod_accel того же Сысоева?
*очень итересная тема дискуссии - думаю сейчас на чем построить ферму с предполагаемой нагрузкой 2000запросов/сек (1 фронт + 2 бэк, в последствии 3) и пока топчусь на месте - что же делать на фронтенде - haproxy - достаточно взрослый, но какой-то мутноватый, apache+mod_accel - весьма перспективно, но префорки смущают, apache+mod_backhand (инстинктивно мне не не приятный, поэтому даже смотреть не буду, но тоже вариант), или все-таки nginx? При возможности отдачи статики подцеплю к нему контент и пускай отдает графику тоже...
| From: | ospf_ripe |
|---|
| Date: | Апрель 17, 2007 04:57 am none (UTC) |
|---|
| | Re: можно вопросик? | (Link) |
|
Поскольку mod_accel это моудль апача то он в состоянии поддерживать 100-200 одновременных коннекций (или больше, зависит от железа). Но не в состоянии поддерживать 100-200 коннекций (включая keep-alive) как это делает nginx. Главное преимущество mod_accel перед текущей версией nginx это кеширование на уровне http. В nginx оно тоже рано или поздно будет, но пока его там нет. Если очень нужно кеширование именно на уровне http, то можно организовать схему nginx -> apache+mod_accel -> backend (apache or fastcgi) Если код разрабатывается самостоятельно, то эффективнее кешировать на других уровнях. Например если страница состоит из нескольких частей из которых одна меняется часто, а остальные реже, то кеширование на уровне http работать не будет. Но можно редко изменяемые части положить в виде файлов на фронтенд в виде фалов и включать в страницу чрез ssi. Другие части можно положить в memcached и использовать из скриптов на бэкенде. И т. п. Гибкая система кешированя объектов в memcached заточенная под специфику системы работает эффективнее чем кеширование на уровне http. Страница в которой все части статичны может просто сохраняться на диск в виде файла. А если хотя бы один элемент меняется то кешировать её целиком уже нельзя. И еще у меня есть сомнения что два бэкенда потянут 2000 запросов в секунду. Хотя это сильно зависит от специфики задачи. На Hello World и больше потянет. Впрочем это легко определяется нагрузочным тестированием
| From: | ospf_ripe |
|---|
| Date: | Апрель 17, 2007 04:59 am none (UTC) |
|---|
| | Re: можно вопросик? | (Link) |
|
Плюс при изменении кешируемых данных, кеш в memcached легко инвалидировать из тех же скриптов, которые их изменяют. Так что проблема с отдачей устаревших данных легко решается.
| | From: | al3x |
|---|
| Date: | Апрель 17, 2007 04:49 pm none (UTC) |
|---|
| | Re: можно вопросик? | (Link) |
|
к сожалению (к счастью?) контент не мой и влиять на его дизайн я не могу - вопрос еше и в том чтобы выработать какое-то "унифицированное решение". В этом отношении haproxy выглядит как-то более привлекательно по отношению к nginx - хотя бы потому что позволяет потенциально за-loadbalanc-ить все остальное - типа smtp,imap,mysql?, ftp (последнее несколько сомнительно но можно поиграться)... связываться с IPVS-оподобными вещами не хочется...может прийдется в конце-концов делать связку ->haproxy->nginx->apache...
| From: | ospf_ripe |
|---|
| Date: | Апрель 17, 2007 07:31 pm none (UTC) |
|---|
| | Re: можно вопросик? | (Link) |
|
Проксирование pop3/imap в nginx поддерживается, более того тут есть своя специфика и haproxy насколько я понимаю тут не поможет. Аналогичную nginx-у функциональность по проксированию имеет perdition. Но perdition работает ужасно неэффективно и серверов на него нужно раз в 10 (если не в 100) больше чем для nginx.
Ставить haproxy перед nginx для http смысла никакого не вижу. Ничего нового и полезного он в схему не добавить. Только лишнее звено.
Разумеется если проект большой, то для надежности нужно будет поставить два фронтенда с nginx (когда это нужно будет потому что один сервер упрется в современный CPU, вы наверно войдете в десятку крупнейших российских порталов :). Возникает вопрос как балансировать трафик между двумя этими серверами и обеспечить отказоустойчивость (failover).
Варианта два:
1. DNS round robin для балансировки и CARP (для BSD) для отказоустойчивости. Допустим у нас есть два фронтенда с nginx. Нужно 4 IP ардеса. По одному прописывается на физических интерфейсах для управления серверами (ssh) и их мониторинга, трафик клиентов на них идти не должен. Еще два IP прописываются на CARP-интерфейсах, т. е. являются разделяемыми между этими двумя машинами. Когда все работает один на одной машине, второй на другой и через DNS round robin нагрузка на них делится примерно пополам. Если один из серверов падает, то оба IP собираются на одной машине и пользователи по двум этим IP все равно будут получать ответы.
(+) Хорош тем, что не требует дополнительных серверов. Простая и надежная схема.
(-) При падении одного сервера все текущие tcp которые шли на него рвутся. Второй сервер не сможет их перехватить, он будет отвечать только на новые запросы. Но это неизбежно. Недостатком по сравнению со 2-м вариантом является то, что когда упавший сервер поднимается и забирает свой IP обратно, то половина коннекций снова рвутся. Поднявшийся сервер ничего не знает о тех коннекциях, которые были установлены пока IP был на другом сервере (2-й вариант это лечит). Но если фронтенды падают не каждый день, это вполне можно пережить.
При использовании DNS round robin надо еще помнить о таком моменте, что TTL должен быть достаточно большим. Если он будет маленьки, то из за особенности bind 9.3 на меньший IP будет идти больше запросов.
2. Балансировщик на базе pf и pfsync+carp для резервирования. Более подробно схема рассмотрена тут. Есть сервер, который баланисрует трафик между фронтендами с nginx средствами pf. Помимо этого есть демон, который занимается мониторингом фронтендов и если нужно меняет правила pf так, чтобы на упавший сервер запросы не шли. Если фронтенд после падения снова включается, то это никак не влияет на текущие запросы - они продолжают идти туда же куда были установлены. На поднявшийся сервер попадут только новые соединения. У балансировщика есть горячий резерв. С помощью pfsync он синхронизирует состояние pf и при падении мастера прозрачно перехватывает работу мастера. Установленные соединения при этом не рвутся.
(+) Падения серверов (а это почти неизбежное явление) создают минимум неудобств клиентам.
(-) Нужно два дополнительных сервера, работу которых нужно тщательно продумать и протестировать, чтобы схема работала надежно. Если этого не сделать, то дополнительное звено в цепочке только понизит надежность системы.
Работа одного сервера с pf будет похожа на работу haproxy (балансировка на уровне tcp), но с haproxy нельзя обеспечить плавный failover - перенос установленных коннекций с одной машины на вторую без их обрыва. А если мы смирились с тем, что они могут изредка рваться, то лучше использовать 1-й вариант, а не haproxy. К тому же haproxy работает в userspace и данные копируются сначала из ядра в userspace, потом обратно в ядро. При балансировке через pf данные живут в пределах ядра и лишних копирований нет.
| | From: | al3x |
|---|
| Date: | Апрель 18, 2007 07:12 am none (UTC) |
|---|
| |  Re: можно вопросик?
| (Link) |
|
отвечаю строго в беспорядке:
...*BSD нету и не будет - прийдется делать ucarp - в userspace это не так красиво, но и не так сложно...
...перенос соединений при наличии сессии врядли возможен, так что на такой уровень непрерывности обслуживания можно не настраиваться изначально...
..."в десятку российских порталов" не войду ибо а) не в Росси б) контент - дело не мое.
... К вопросу о редизайне контента для повышения производительности - из всех клиентов (200+ серверов) у меня есть
... С DNS roundrobin связываться тоже не охота - хотелось бы сделать что-то что будет минимально зависеть от внешних воздействий, а то вокруг ходит слишком много народа с шаловливыми руками...
... буду пробовать делать связку front = nginx -> back = apache + ucarp, который в случае падения балансера свалит адрес на бекенд. Static (а может даже и dynamic) content попробую раздать через NFS...и посмотрю что получится - все ж думаю будет побыстрее чем тянуть контент с дургого провайдера...;)
... haproxy действительно лишний ...
Спасибо за интересные идеи, было очень приятно вас читать.
| From: | ospf_ripe |
|---|
| Date: | Апрель 18, 2007 08:41 am none (UTC) |
|---|
| | Re: можно вопросик? | (Link) |
|
> Static (а может даже и dynamic) content попробую раздать через NFS
NFS обычно плохо живет под нагрузкой. Если нет возможности разнести статику и динамику по разным машинам, то лучше держать nginx и apache для динамики на одной машине, IMHO.
| From: | chexonte |
|---|
| Date: | Апрель 20, 2007 11:12 am none (UTC) |
|---|
| | Re: можно вопросик? | (Link) |
|
NFS используется для раздачи статики, динамика лежит на каждой из нод,
работает без проблем: OpenSolaris 10, ZFS, nfsd.
PS. nfsd очень хорошо кеширует данные, поэтому не жалейте ОЗУ
| From: | ospf_ripe |
|---|
| Date: | Апрель 17, 2007 07:34 pm none (UTC) |
|---|
| | Re: можно вопросик? | (Link) |
|
> к сожалению (к счастью?) контент не мой и влиять на его дизайн я не могу
Для производительности системы это минус. Потому что эффективное кеширование обычно можно сделать только внутри системы.
![[User Picture]](http://l-userpic.livejournal.com/47866301/599667) | | From: | bolk |
|---|
| Date: | Февраль 13, 2008 12:30 pm none (UTC) |
|---|
| | | (Link) |
|
Лично мне тут больше всего интересно для чего нужен Апач и что мешает раздавать всё через nginx — и динамику и статику.
Внезапно, аналогичный интерес. Почему плохо использовать nginx для отдачи и статики и динамики?
Автор нам поведал о механизме конечных автоматов и о том, что нельзя надолго занимать процессор. Однако и nginx и lighttpd для обработки динамики используют fastcgi-интерфейс и PHP-шный, например, код обрабатывается в отдельном процессе. А с fastcgi, я уверен, вполне можно работать в асинхронном режиме (и, кстати, распределять нагрузку по нескольким серверам тоже очень удобно с fastcgi). По сути, модель nginx + fastcgi/php крайне близка к апачевской модели обработки динамики.
nginx + fastcgi/php в целом работоспособен, но те кто его используют наступают на разные баги php, которых нет в mod_php. Плюс php запущенный в режиме fastcgi AFAIK умеет работать только с фиксированным числом процессов и не форкает их динамически как апач - это подходит не всем. А разница в производительности между nginx+apache+mod_php и ngnix+php/fastcgi небольшая (если вообще есть).
Тут мне недавно рассказали умные люди, что любой cgi - это лишний exec.
А с mod_php этого exec'а нету.
Я то понимаю, что по памяти врядли выиграешь, т.к. количество процессов и так, и так одно и то же, но на быстродействии это сказывается.
Хотя сказанное мною больше применимо к апачам, нежели к nginx+fastcgi. |
|
|
