ПРОЕКТЫ 


  АРХИВ 


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 Tue, 4 Jan 2005, Kpoxa KpoIIIkin wrote:

> Есть ли доступный архив списка рассылки? Есть некоторое количество
> вопросов, которые скорее всего уже кто-нибудь задавал. Да и в челом там
> наверняка
> есть полезная информация для пользователей nginx.

Пока архива нет. Похоже, пора публиковать на сайте хотя бы выдержки.

> 1.Предполагается использовать nginx  в качестве фронт энда на
> виртуальном хостинге,
> число виртуальных хостов может измеряться тысячами, все запросы,
> приходящие на
> 1 определенный адрес:порт надо перенаправить на другой определенный
> адрес:порт,
> при этом заголовок host оставив изначальными, как это указать nginx'у?

proxy_preserve_host  [on|off];

> 2. Предполагается ли включить в nginx что-то наподобие балансировщика
> нагрузки, но не
> методом запроса к DNS при новом запросе, а по какому-нибудь алгоритму,
> хотя бы
> round-robin с весами? Конечно при этом надо бы еще и определение сбойных
> нодов сделать
> но это уже мечты. Конечно включение функций content switch в такой
> продукт сильно бы
> увеличило привлекательность продукта для хостеров и крупных web
> проектов, но скорее всего
> это только мое личное мнение, которое может идти в разрез с мнением
> уважаемого автора nginx.

Это вопрос обсуждался буквально перед тем, как вы подписалиcь на список.
Дублирую ответ.

Сейчас proxy_pass резолвит бэкенд при каждой переконфигурации и, если
у бэкенда несколько адресов, то используются все. У всех адресов одинаковый
вес и они последовательно перебираются. Если при работе с бэкендом
произошла ошибка, то бэкенд исключается из списка работающих на 60 секунд.

Кроме того, есть директива proxy_next_upstream, которая задаёт условия,
при которых nginx будет пробовать работать с другим адресами прежде, чем
вернуть ошибку. Директива задаётся на уровне http, server и location.
По умолчанию параметры такие:

proxy_next_upstream   error timeout invalid_header http_500;

Полный список параметров:

error - ошибка при соединении, при передаче запроса или при чтении заголовка
        и первой части ответа.
timeout - таймаут при соединении, при передаче запроса или при чтении
        заголовка и первой части ответа.
invalid_header - неправильный или пустой заголовок ответа.
http_500 - 500 ответ.
http_404 - 404 ответ.

Нужно учесть, что переход к следующему бэкенду возможен только до начала
передачи ответа клиенту. Если ошибка произойдёт уже после того, как
начата передача ответа клиенту, то переход невозможен и соедиение с
клиентом просто закрывается.

Параметр http_404 позволяет хранить какие-то файлы только на одном из
бэкендов. В этом случае nginx будут перебирать все бэкенды, пока не получит
другой ответ или же бэкенды не закончатся - в этом случае клиенту будет
передан ответ 404.

Что будет сделано ещё: будет возможность задавать явные адреса и веса
бэкендов, число ошибок и время исключения бэкенда из работы. Примерно так:

     server {
         location / {
             proxy_pass   http://some_backend/;
         }
     }

     upstream some_backend {
         server   backend0           w=10  f=5   t=60;
         server   backend1:8080      w=5   f=1;
         server   unix:/tmp/socket   w=1;
     }

Кстати, когда будет кэширование, то подобно директиве proxy_next_upstream
будет директива proxy_use_stale - если все бэкенды оказались недоступны
по указанным параметрам, а в кэше есть старый ответ, то он будет отдан
клиенту.


Игорь Сысоев
http://sysoev.ru




 




Copyright © Lexa Software, 1996-2009.