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, то запросы, приходящие на эти
сервера будут тоже консистентными?
Ещё раз спасибо и успехов Вам в работе.
С уважением и благодарностью,
Александр Кунич.
_______________________________________________
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
