Не понятна логика работы hash consistent

[Maxim Dounin]

Hello!

On Mon, Oct 03, 2022 at 10:30:17AM +0300, Александр Кунич via nginx-ru wrote:

> Здравствуйте.
> 
> Подскажите пожалуйста, это у меня не работает консистентное хеширование 
> или я не верно понимаю алгоритм его работы.
> 
> У меня в системе апстримы в конфигурации ниже являются кеширующими 
> прокси. Недавно понадобилось перераспределить часть нагрузки между ними 
> и понял, что веса работают не так, как я ожидал.
> 
> Опишу по порядку. С пол года конфигурация была такой. Кеш на прокси 
> апстримах прогрелся до 95% попаданий.
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 backup max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> Затем понадобилось часть нагрузки перенести на 192.168.1.2. Снял метку 
> backup  с 192.168.1.2 , готовился к тому, что попадания в кеш на 
> 192.168.1.1 и 192.168.1.3 снизятся, но этого не произошло. Просто 
> нагрузка на 192.168.1.2 существенно выросла. Тут первый вопрос - почему? 
> Т.е. как ketama должен обрабатывать метку backup?

При consistent-хэшировании, как и при прочей балансировке, 
backup-сервера используются только в случае, если от основных 
серверов ответа получить не удалось из-за ошибок.  Соответственно 
в вашем случае в конфигурацию, фактически, был добавлен сервер 
192.168.1.2.

Для consistent-хэширования добавление нового сервера означает, что 
часть нагрузки с существующих серверов будет перенесена на 
добавленный.  Больше никаких изменений не будет.  Соответственно 
то, что процент попаданий в кэш на ранее использовавшихся серверах 
не поменялся - это вполне нормально, так как исключены ситуации, 
когда запрос ранее попадал на 192.168.1.1, а теперь стал попадать 
на 192.168.1.3 (или наоборот).

При этом часть кэша на 192.168.1.1 и 192.168.1.3 стала не нужна 
(так как соответствующие запросы уехали на 192.168.1.2), но на 
процент попаданий в кэш оставшихся запросов это влиять никак не 
должно.

> Далее потребовалось перераспределить ещё немного нагрузку и вот тут 
> выявилось самое интересное.
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 weight=13 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 weight=7 max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> В этой конфигурации ожидалось, что 192.168.1.3 останется на прежнем 
> месте круга хеширования кетама и промахов кеша у него не добавится. Но 
> оказалось вовсе не так. Промахи добавились везде и существенно. Далее я 
> попробовал у всех серверов выставить последовательно одинаковые веса. 
> Сначала всем weight=1 - попадания в кеш восстановились, затем всем 
> выставил weight=10 - попадания с 95% упали почти до 50%.
> 
> До этого я полагал, что в алгоритме хеширования кетама играет роль 
> пропорциональность весов и порядковое место сервера в списке. Согласно 
> этого понимания, две приведённые ниже конфигурации должны быть 
> равнозначны в плане попаданий кеш.
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 weight=1 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 weight=1 max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 weight=1 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 weight=10 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 weight=10 max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> На практике у меня это не работает. С весом 10 попадания сильно 
> уменьшаются. Это я что-то не так понимаю или у меня не работает ketama ?

При consistent-хэшировании вес реализован с помощью добавления 
дополнительных точек для данного сервера.  То есть, фактически, 
увеличение веса сервера с 1 до 2 эквивалентно добавлению ещё 
одного сервера.  Соответственно изменение весов трёх серверов с 1 
на 10 эквивалентно добавлению 27 новых серверов, и ожидаемо 
приводит к сильной ребалансировке существующих запросов между 
серверами.

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

-- 
Maxim Dounin
http://mdounin.ru/