upstream priority

[Nikita Koshikov]

Спасибо больше, Максим

Хотелось бы уточнить насчет перехешированных ключей
Вот конфигурация
  upstream backend {
    hash 'balance';
    server [::1]:81 weight=100 fail_timeout=60;
    server [::1]:82 weight=100 fail_timeout=60;
    server [::1]:83 weight=1 fail_timeout=60;
    server [::1]:84 weight=1 fail_timeout=60;
  }

Ключ статический, соответственно все запросы должны повторять цепочку
отказов, однако на практике происходит так:
81->82 или 82->81 - пока кто-нибудь из них жив. Когда оба недоступны
один и тот же запрос балансирует 83/84/83/84...
Количество в данном примере 4 и не должно попадать под критерий 20+.
Это баг или мое недопонимание как должен работать hash в данном
конкретном примере ? (nginx/1.16.1)

On Fri, Nov 6, 2020 at 10:49 AM Maxim Dounin <mdounin на mdounin.ru> wrote:
>
> Hello!
>
> On Fri, Nov 06, 2020 at 09:40:14AM -0800, Nikita Koshikov wrote:
>
> > Доброго всем времени суток
> >
> > Подскажите как можно сделать что-то максимально подобное для выбора
> > backend сервера по приоритету, в идеале нужно что-то
> >
> >   upstream backend {
> >     server [::1]:81 priority=1;
> >     server [::1]:82 priority=2;
> >     server [::1]:83 priority=3;
> >     server [::1]:84 priority=4;
> >     server [::1]:85 priority=5;
> >   }
> > т.е. пока жив хоть один с более высоким приоритетом - слать запросы на него ?
> >
> > Из того что пробовал
> >   upstream backend {
> >     server [::1]:81 weight=1;
> >     server [::1]:83 backup;
> >   }
> > Так работает - однако не поддерживает 2+ бекенда
>
> Если хочется строгий порядок перебора бэкендов, то стоит
> посмотреть в сторону перенаправления по error_page.  E.g.:
>
>     location / {
>         proxy_pass http://[::1]:81;
>         error_page 502 504 @second;
>         recursive_error_pages on;
>     }
>
>     location @second {
>         proxy_pass http://[::1]:82;
>         error_page 502 504 @third;
>         recursive_error_pages on;
>     }
>
>     location @third {
>         proxy_pass http://[::1]:82;
>     }
>
> В зависимости от конкретных потребностей можно добавить
> proxy_intercept_errors и соответственно другие error_page по
> вкусу.
>
> > Из самого близкого что удалось сделать - через hash со статичным ключом
> >   upstream backend {
> >     hash 'http_balance';
> >     server [::1]:81 weight=1 fail_timeout=60;
> >     server [::1]:82 weight=2 fail_timeout=60;
> >     server [::1]:83 weight=3 fail_timeout=60;
> >   }
> > Проблема только что веса не всегда работают, - в данной конфигурации
> > выбирается server:82, хотя у 83 более высокий weight. Полная цепочка
> > при отказах - 82->83->81
> > Учитывается ли вес в такой конфигурации ?
> > С более высокими весами начинает работать как нужно 83->82->81
> >   upstream backend {
> >     hash 'http_balance';
> >     server [::1]:81 weight=1 fail_timeout=60;
> >     server [::1]:82 weight=10 fail_timeout=60;
> >     server [::1]:83 weight=100 fail_timeout=60;
> >   }
> > Хотелось бы понимать это совпадение или веса принимаются в расчет при
> > выборе hash-а?
>
> Вес - это не приоритет, а ручка для управления долей запросов,
> которые пойдут на конкретный бэкенд.  Вес, естественно, при выборе
> бэкенда учитывается, но в том смысле, что на бэкенд с весом 10 - в
> среднем, в предположении случайных ключей - будет отправлено в 10
> раз больше запросов, чем на бэкенд с весом 1.
>
> В случае ошибок - происходит перехэширования запроса с другим
> ключом, с добавлением к ключу количества перехэширований.  И
> соответственно для конкретного ключа - последовательность бэкендов
> будет фиксированная, но для каждого ключа при этом своя.  Но есть
> нюанс: если за 20 перехэширований nginx не найдёт бэкенд, на
> который ещё не ходил - он сдастся и переключится на round-robin
> балансировку, где живой бэкенд, если он есть, можно гарантировано
> выбрать за фиксированное количество операций.
>
> Соответственно подобрать такой статический ключ и такое
> распределение весов, при котором для данного ключа будет нужная
> вам последовательность перебора бэкендов - в принципе можно.  Но
> это не то, как должена работать hash-балансировка, и скорее всего
> для сложных случаев вы просто устанете подбирать.  Ну и, понятно,
> поддерживать это будет непросто.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru