Под лж-катом — красивая картинка внутренней сетки ЖЖ (как устроены все сервера и как они между собой общаются). Если что-то непонятно или интересно, можно спрашивать.
BigIP - firewall, load balancer (его главная функция).
2. Практически везде Debian Linux, stable. Исключение - NetApp и BigIP, на которых бежит их специальный софт (что не NetApp, я не знаю, а на BigIP старая сильно модифицированная BSDi, если не ошибаюсь).
3. apache+mod_ssl. Вообще этот сервер простаивает, он практически только для платежей и используется пока что. В будущем, наверное, будет secure login итп.
4. proxy web - apache + mod_proxy + mod_rewrite . Эти машины ничего не кэшируют, они работают как reverse proxy: получают запрос, выбирают один из свободных веб-серверов (раньше этот выбор шёл через load balancing BigIP, но недавно я написал rewriter balancer, демон, который бежит на них и получает нотификации от апачей на веб-серверах насчёт их занятости. apache на proxy-web машине обращается (через mod_rewrite) к rewrite balancer'у и тот переписывает ему URL на один свободных веб-серверов), пересылают запрос ему, получают полностью ответ, и после этого отсылают юзеру. Смысл их существования в сокращении времени работы тяжёлых mod_perl-овских веб-серверов: они принимают на себя общение с end-юзером на его относительно медленной скорости. Этих машин сейчас три или четыре штуки, не помню точно.
5. apache+mod_perl. Всё дерево сайта (htdocs, перловские библиотеки итп.) они видят через NFS с одного центрального места. Статики на сайте очень мало, в основном всякие мелкие иконки (юзерпики не считаем, они особь статья). Вся эта статика есть в рабочем дереве, так что веб-серверы её видят и могут выдавать, но на практике статика напрявляется на отдельный сервер (здесь не указанный ради экономии места) на уровне BigIP.
Не знаю, а чем он так лучше mod_proxy? Я с ним не знаком, но вот сейчас посмотрел немного - все его улучшения типа busy locks или ограничения числа подключений нам не нужны. У нас главное именно load balancing бэкенда, а он в этом смысле ничего нового не даёт.
Вот умеет ли он делать transparent redirect? Скажем, если бэкенд возвращает 301 (или какой-то кастомный код, неважно), он не пересылает его юзеру, а сам внутри идёт по новому адресу, берёт оттуда то, что надо, и посылает юзеру как ответ на первоначальный запрос? Вот такая штука нам нужна, а mod_proxy её не поддерживает; если не найдём что-то готовое, я буду в mod_proxy это добавлять.
rewrite balancer - использует что-то вроде mod_backhand, но не сам mod_backhand, он нам не подходил. На веб-серверах бежит модуль Apache::SendStats (custom, тоже мной написан), который броадкастит в UDP количество свободных детей данного сервера в конце каждого запроса. rewrite balancer-ы, бегущие на машинах mod_proxy, слушают эту статистику и выбирают для передачи mod_rewrite один из свободных серверов по weighted average.
(вместо броадкаста надо, наверное, по-хорошему сделать мультикаст, но мы не собрались пока).
>> У нас главное именно load balancing бэкенда, а он в этом смысле ничего нового не даёт.
Очень даже дает. Тут (http://sysoev.ru/mod_accel/readme.html#mod_proxy) есть описание, в чем mod_proxy лажает при работе с backend'ом.
Возможностей performance tuning'а гораздо больше чем с mod_proxy. Опять же хорошо обрабатывает авторизацию по cookies и можно тонко управлять expires.
В тему - с mod_deflate же контент очень хорошо жмется (автор тот же). Все pitfalls учтены.
Насчет transparent redirect - самому надо. В mod_accel есть hook - note "accel_rewrite_response". Т.о. пишется нехитрый модуль и все. Лично у меня руки как-то не доходят.
Мы внимательно посмотрим на mod_accel и, возможно, будем пользоваться именно им. Я действительно не знал о недостатках mod_proxy в вопросе ускорения бэкенда.
Как уже было замечено, для транспарент редиректа можно использовать accel_rewrite_response - в обработчике делать sub_request.
Примитивный (на основе dns) load-balancing и fault-tolerance есть. Более умный можно прикрутить через hook open_backend.
Можно кэшировать ответ с учётом куки, то есть, обычные и залогиненые пользователи получат разные ответы. Не знаю, правда, даст ли что-нибудь в вашем случае кэширование.
В общем, вопросы - welcome.
Но должен заметить, что mod_accel - это вчерашний день. Я сейчас пишу веб и прокси-сервер, который работает на select/kqueue/etc Так вот, там будет фич по-более посравнению с mod_accel.
Большое спасибо. Я, видимо, буду пристально изучать mod_accel на следующей неделе. Если будут вопросы, напишу.
Кэширование в нашем случае бесполезно. Очень важна совместимость с mod_rewrite, но, насколько я понял, она есть.
Веб-сервер мы вряд ли будем менять, т.к. основная работа у нас происходит в Перле, и всё завязано на mod_perl ;)
Если Вы пишете аппликации на select/kqueue, возможно, стоит взглянуть на epoll (select в Линуксе начинает тормозить с большим количеством подключений). Есть неплохая библиотека libevent, которая абстрагирует разные методы оповещения в общий интерфейс; я воспользовался ей при написании memcached, которым мы сейчас пользуемся в больших масштабах.
2. Практически везде Debian Linux, stable. Исключение - NetApp и BigIP, на которых бежит их специальный софт (что не NetApp, я не знаю, а на BigIP старая сильно модифицированная BSDi, если не ошибаюсь).
Человек, от которого мы унаследовали наш NetApp, говорил, что на нём FreeBSD (естественно сильно переделанная), но доказательств у меня нет. Мне кажется, lj тоже раньше были не на Дебиане, если это так, почему на него перешли?
Когда-то очень давно LJ был на FreeBSD, но это было в очень древние времена (когда всего было 3-4 сервера. Меня тогда в ЖЖ не было, конечно). Из-за проблем со скоростью TCP-стэка (не знаю, были эти проблемы вызваны реальными недостатками FreeBSD, или плохим драйвером/плохой конфигурацией. Брэд, по-моему, и сам это не помнит) было решено перейти на Линукс, и сначала поставили RedHat. Но потом, примерно два года назад или чуть больше, Брэд решил перейти с RedHat на Дебиан, в основном потому что ему очень нравится дебиановская система package management. Ну и во всём остальном Дебиан себя оправдала.
Не пойму, Линукс вроде он? Дебиан я бы тоже сказал он? Или всё-таки она, т.к. операционная система? Или имеется в виду Дебора, которая первая в названии Дебиан? Вот про FreeBSD явно хочется сказать "она".
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2003-11-11 07:30 am (UTC)2. Практически везде Debian Linux, stable. Исключение - NetApp и BigIP, на которых бежит их специальный софт (что не NetApp, я не знаю, а на BigIP старая сильно модифицированная BSDi, если не ошибаюсь).
3. apache+mod_ssl. Вообще этот сервер простаивает, он практически только для платежей и используется пока что. В будущем, наверное, будет secure login итп.
4. proxy web - apache + mod_proxy + mod_rewrite . Эти машины ничего не кэшируют, они работают как reverse proxy: получают запрос, выбирают один из свободных веб-серверов (раньше этот выбор шёл через load balancing BigIP, но недавно я написал rewriter balancer, демон, который бежит на них и получает нотификации от апачей на веб-серверах насчёт их занятости. apache на proxy-web машине обращается (через mod_rewrite) к rewrite balancer'у и тот переписывает ему URL на один свободных веб-серверов), пересылают запрос ему, получают полностью ответ, и после этого отсылают юзеру. Смысл их существования в сокращении времени работы тяжёлых mod_perl-овских веб-серверов: они принимают на себя общение с end-юзером на его относительно медленной скорости. Этих машин сейчас три или четыре штуки, не помню точно.
5. apache+mod_perl. Всё дерево сайта (htdocs, перловские библиотеки итп.) они видят через NFS с одного центрального места. Статики на сайте очень мало, в основном всякие мелкие иконки (юзерпики не считаем, они особь статья). Вся эта статика есть в рабочем дереве, так что веб-серверы её видят и могут выдавать, но на практике статика напрявляется на отдельный сервер (здесь не указанный ради экономии места) на уровне BigIP.
no subject
Date: 2003-11-11 07:46 am (UTC)а rewrite/load balancer - просто тупо по кругу выдает очередной сервер или используется что-то вроде mod_backhand?
no subject
Date: 2003-11-11 08:04 am (UTC)Вот умеет ли он делать transparent redirect? Скажем, если бэкенд возвращает 301 (или какой-то кастомный код, неважно), он не пересылает его юзеру, а сам внутри идёт по новому адресу, берёт оттуда то, что надо, и посылает юзеру как ответ на первоначальный запрос? Вот такая штука нам нужна, а mod_proxy её не поддерживает; если не найдём что-то готовое, я буду в mod_proxy это добавлять.
rewrite balancer - использует что-то вроде mod_backhand, но не сам mod_backhand, он нам не подходил. На веб-серверах бежит модуль Apache::SendStats (custom, тоже мной написан), который броадкастит в UDP количество свободных детей данного сервера в конце каждого запроса. rewrite balancer-ы, бегущие на машинах mod_proxy, слушают эту статистику и выбирают для передачи mod_rewrite один из свободных серверов по weighted average.
(вместо броадкаста надо, наверное, по-хорошему сделать мультикаст, но мы не собрались пока).
no subject
Date: 2003-11-11 08:30 am (UTC)Очень даже дает. Тут (http://sysoev.ru/mod_accel/readme.html#mod_proxy) есть описание, в чем mod_proxy лажает при работе с backend'ом.
Возможностей performance tuning'а гораздо больше чем с mod_proxy. Опять же хорошо обрабатывает авторизацию по cookies и можно тонко управлять expires.
В тему - с mod_deflate же контент очень хорошо жмется (автор тот же). Все pitfalls учтены.
Насчет transparent redirect - самому надо. В mod_accel есть hook - note "accel_rewrite_response". Т.о. пишется нехитрый модуль и все. Лично у меня руки как-то не доходят.
no subject
Мы внимательно посмотрим на mod_accel и, возможно, будем пользоваться именно им. Я действительно не знал о недостатках mod_proxy в вопросе ускорения бэкенда.
no subject
Date: 2003-11-17 05:42 am (UTC)Примитивный (на основе dns) load-balancing и fault-tolerance есть. Более умный можно прикрутить через hook open_backend.
Можно кэшировать ответ с учётом куки, то есть, обычные и залогиненые пользователи получат разные ответы. Не знаю, правда, даст ли что-нибудь в вашем случае кэширование.
В общем, вопросы - welcome.
Но должен заметить, что mod_accel - это вчерашний день.
Я сейчас пишу веб и прокси-сервер, который работает на select/kqueue/etc
Так вот, там будет фич по-более посравнению с mod_accel.
no subject
Date: 2003-11-22 02:38 pm (UTC)Я, видимо, буду пристально изучать mod_accel на следующей неделе. Если будут вопросы, напишу.
Кэширование в нашем случае бесполезно. Очень важна совместимость с mod_rewrite, но, насколько я понял, она есть.
Веб-сервер мы вряд ли будем менять, т.к. основная работа у нас происходит в Перле, и всё завязано на mod_perl ;)
Если Вы пишете аппликации на select/kqueue, возможно, стоит взглянуть на epoll (select в Линуксе начинает тормозить с большим количеством подключений). Есть неплохая библиотека libevent, которая абстрагирует разные методы оповещения в общий интерфейс; я воспользовался ей при написании memcached, которым мы сейчас пользуемся в больших масштабах.
no subject
Date: 2003-11-11 01:35 pm (UTC)Человек, от которого мы унаследовали наш NetApp, говорил, что на нём FreeBSD (естественно сильно переделанная), но доказательств у меня нет.
Мне кажется, lj тоже раньше были не на Дебиане, если это так, почему на него перешли?
no subject
Date: 2003-11-11 01:41 pm (UTC)оффтопик
Date: 2003-11-11 01:54 pm (UTC)Не пойму, Линукс вроде он? Дебиан я бы тоже сказал он? Или всё-таки она, т.к. операционная система? Или имеется в виду Дебора, которая первая в названии Дебиан? Вот про FreeBSD явно хочется сказать "она".
Re: оффтопик
Date: 2003-11-11 01:56 pm (UTC)Я и про FreeBSD скажу она, и про Дебиан.
no subject
Date: 2006-11-07 11:23 pm (UTC)нужно просту увеличисть радиус кривизны рук :)