upstream priority

[Nikita Koshikov]

Еще раз спасибо за ответ и хороших выходных

On Fri, Nov 6, 2020 at 1:53 PM Maxim Dounin <mdounin на mdounin.ru> wrote:
>
> Hello!
>
> On Fri, Nov 06, 2020 at 11:28:16AM -0800, Nikita Koshikov wrote:
>
> > Спасибо больше, Максим
> >
> > Хотелось бы уточнить насчет перехешированных ключей
> > Вот конфигурация
> >   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)
>
> Сколько в данном примере было попыток рехэширования - мы не знаем,
> так как при рехэшировании никто не гарантирует, что мы попадём на
> работающий бэкенд.  Если мы снова попадаем на неработающий и/или
> испробованныый в рамках конкретного запроса бэкенд - происходит
> ещё одно рехэширование.
>
> В приведённом примере конфигурации после смерти бэкендов 81 и 82
> вероятность попасть на "живой" бэкенд при очередном рехэшировании
> около 1 процента, а с вероятностью 99% нам потребуется делать
> рехэширование снова.  Поскольку ограничение сработает на 20
> попытках рехэширования - с вероятностью около 80% мы в это
> ограничение уткнёмся и выбор бэкенда будет делаться с помощью
> round-robin балансировки.
>
> Резюмируя вышесказанное: нет, это не баг, это ровно то, про что
> было сказано в предыдущем письме - устанете подбирать.  Ибо с
> одной стороны надо обеспечить нужную последовательнось выбора
> бэкендов, а с другой - не выйти за ограничение в 20 попыток
> рехэширования.
>
> Если хочется всё-таки развлекаться - я бы смотрел в сторону
> алгоритма "сделать десяток/сотню фиктивных серверов, посмотреть,
> куда попадает запрос, и вписать нужные бэкенды на соответствующие
> места".  Но, повторюсь, гораздо более прямой способ задать порядок
> явно - через error_page.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru