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