Александр Кунич via nginx-ru
October 03, 2022 03:32AM
Здравствуйте.

Подскажите пожалуйста, это у меня не работает консистентное хеширование
или я не верно понимаю алгоритм его работы.

У меня в системе апстримы в конфигурации ниже являются кеширующими
прокси. Недавно понадобилось перераспределить часть нагрузки между ними
и понял, что веса работают не так, как я ожидал.

Опишу по порядку. С пол года конфигурация была такой. Кеш на прокси
апстримах прогрелся до 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?

Далее потребовалось перераспределить ещё немного нагрузку и вот тут
выявилось самое интересное.

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 ?

Заранее, большое спасибо за помощь.

С уважением,
Александр Кунич.

_______________________________________________
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-leave@nginx.org
Subject Author Posted

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

Александр Кунич via nginx-ru October 03, 2022 03:32AM

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

Maxim Dounin October 03, 2022 10:08AM

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

Александр Кунич via nginx-ru October 13, 2022 04:54AM

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

Maxim Dounin October 13, 2022 09:16AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 137
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready