ПРОЕКТЫ 


  АРХИВ 


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 Mar 7, 2013, at 2:15 PM, Валентин Бартенев <vbart@xxxxxxxxx> wrote:

> 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-а
>> или деплоить статику на балансировщик?
>> 
> 
> У каждого решения есть свои плюсы и минусы, нужно смотреть конкретно в вашем 
> случае, что будет удобнее. И вообще, что является узким местом на текущий 
> момент. Возможно даже нужно пробовать и смотреть.
> 
> Я бы стремился сократить количество звеньев в системе с одной стороны, и 
> уменьшить количество единых точек отказа - с другой, децентрализовать.
> 

да, абсолютно согласен, уменьшить SPoF - это, пожалуй, главная моя задача,
даже если это будет менее эффективно с точки зрения производительности.

Идея с каскадными Nginx-ами мне нравится потому что:
- Nginx-A делает только проксирование всех запросов на массив серверов из 
Nginx-B
- Nginx-A осуществляется SSL-offload
- при обновлении SSL-xсертификата надо будет обновить его только на Nginx-A
- массив Nginx-B - самостоятельные сервера, на каждом из них точная копия кода 
и статики
- имея 2 Nginx-A можно сделать перекрестную балансировку из 4-серверов, 
получаем 0 SPoF 
  в данной случае с приложением (балансировку базы я не затрагиваю, это 
отдельный вопрос)

Есть ли какие-то особенности в настройках keepalive на upstream, proxy_pass и 
на самих серверах?
В среднем между запросами одного клиента проходит 1-20 секунд. Что думаете о 
такой конфигурации:

[Nginx-A]
  http { 
    ssl ?
    # no gzip settings
    keepalive_timeout 70;

    upstream backend {
      server 10.0.0.1:8080; # Nginx-B
      server 10.0.0.2:8080; # Nginx-B
      keepalive 70;
    }

    server {
      location / {
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  X-Forwarded-Proto $scheme;
        proxy_set_header  Host $http_host;
        proxy_redirect    off;
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
      }
    }
  }


[Nginx-B]
  http {
    gzip ?
    # no ssl settings
    keepalive_timeout 70;

    upstream unicorn {
      server              unix:/tmp/unicorn.production.main.sock fail_timeout=0;
      # no timeout here, because Unicorn is stateless itself
    }

    server {
      location / {
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  X-Forwarded-Proto $scheme;
        proxy_set_header  Host $http_host;
        proxy_redirect    off;
        proxy_pass        http://unicorn;
      }
      location ~ ^/(assets|images|javascripts|stylesheets|swfs|system)/ {
        # settings to serve static assets
      }
    }
  }




Анатолий

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

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.