ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: каскад проксирующих серверов



On Thursday 07 March 2013 16:26:03 Anatoly Mikhailov wrote:
> On Mar 7, 2013, at 11:41 AM, Валентин Бартенев <vbart@xxxxxxxxx> wrote:
> > On Thursday 07 March 2013 15:03:59 Anatoly Mikhailov wrote:
> >> On Mar 7, 2013, at 9:54 AM, Валентин Бартенев <vbart@xxxxxxxxx> wrote:
> >>> On Wednesday 06 March 2013 23:35:04 Anatoly Mikhailov wrote:
> >>>> добрый день,
> >>>> 
> >>>> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока
> >>>> склоняюсь к использованию Nginx в роли балансировщика. Таким образом
> >>>> будет каскад Nginx - (Nginx - Unicorn) x 5.
> >>>> 
> >>>> У нас связка Nginx+Unicorn на нескольких независимых серверах разного
> >>>> назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей
> >>>> нагрузки, есть необходимость основное (Main) приложение поставить за
> >>>> балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно
> >>>> Nginx-B), которые и будут непосредственно проксировать на Unicorn.
> >>> 
> >>> [...]
> >>> 
> >>> А в чем необходимость Nginx-B стоять перед Unicorn-ом?
> >>> Почему бы не проксировать с Nginx-A на Unicorn напрямую?
> >> 
> >> Ребята из Github не советуют так делать:
> >> http://stackoverflow.com/questions/14082243/unicorn-multiple-machines-se
> >> tu p А если серьезно, то как в этом случае отдавать статику, если она не
> >> на CDN?
> > 
> > Дополнительный промежуточный nginx тоже добавляет оверхэда, и тут вопрос
> > скорее в том, какой из них больше (от установки соединения между
> > nginx-ом и unicorn по сети, или от дополнительного nginx-а с keepalive).
> 
> оверхэд будет в любом случае, поэтому и нужна ваша помощь, как все
> правильно сделать
> 
> > А в чём проблема отдавать статику? Мне казалось, что создание помойки из
> > кода и статики - это исключительно черта php-программистов, и у рубистов
> > должно быть с этим всё в порядке, в том смысле, что отличить запрос к
> > статике можно ещё на балансировщике без stat() (и проксировать далее,
> > либо на nginx, либо на unicorn).
> 
> помойки из кода и статики никакой нет, вся статика лежит отдельно как у
> всех рубистов :) вопрос в том, как правильно ее отдавать - через 2 nginx-а
> или деплоить статику на балансировщик?
> 

У каждого решения есть свои плюсы и минусы, нужно смотреть конкретно в вашем 
случае, что будет удобнее. И вообще, что является узким местом на текущий 
момент. Возможно даже нужно пробовать и смотреть.

Я бы стремился сократить количество звеньев в системе с одной стороны, и 
уменьшить количество единых точек отказа - с другой, децентрализовать.

--
Валентин Бартенев
http://nginx.org/en/donation.html
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.