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

[Александр Кунич]

03.10.2022 17:06, 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-хэшировании, конечно, порядок серверов не
> имеет значения, и так как добавляемые на круг хэширования точки
> зависят только от имени сервера, но не от его места в списке. Как
> раз отсутствие зависимости от порядка - одно из важных отличий от
> обычного хэширования.
>
Здравствуйте, Максим.

Большое спасибо Вам за быстрый и развёрнутый ответ. Теперь всё стало 
ясно. Я действительно не верно представлял себе принцип работы 
консистентного хеширования. Особенно про независимость от места в списке 
без Вашего ответа, маловероятно, что сам дошёл бы.

А подскажите ещё пожалуйста, строится ли отдельный круг ketama для 
серверов с меткой backup? Т.е. если в конфигурации будет указано 
несколько серверов с меткой backup, то запросы, приходящие на эти 
сервера будут тоже консистентными?

Ещё раз спасибо и успехов Вам в работе.


С уважением и благодарностью,
Александр Кунич.