Re: Не понятна логика работы hash consistent
Hello! On Thu, Oct 13, 2022 at 11:52:42AM +0300, Александр Кунич via nginx-ru wrote: [...] > А подскажите ещё пожалуйста, строится ли отдельный круг ketama для > серверов с меткой backup? Т.е. если в конфигурации будет указано > несколько серверов с меткой backup, то запросы, приходящие на эти > сервера будут тоже консистентными? Формально backup-сервера вообще не поддерживаются при использовании методов балансировки hash, ip_hash и random, см. тут: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#backup И если сначала задать метод балансировки, а потом уже описывать сервера, то использовать флаг "backup" nginx не разрешит. Если же сервера уже описаны к тому моменту, как задан метод балансировки, и соответственно известно, что backup-сервера не поддерживаются, в текущей реализации nginx такое пропускает. При этом, опять же в текущей реализации, при hash-балансировке nginx пытается делать до 20 попыток перехэширования для выбора сервера, и если за эти 20 попыток он не смог найти работающий сервер - то nginx переключается в режим round-robin-балансировки для выбора хоть какого-то сервера из оставшихся (если хотя бы что-то осталось). И уже в этом режиме срабатывают backup-сервера, если они вдруг были заданы. Соответственно, если вы задали backup-сервера при hash-балансировке, то они будут использоваться только в рамках перехода к round-robin-балансировке при невозможности выбрать сервер с помощью hash-балансировки, и для выбора из backup-серверов будет использоваться round-robin-балансировка. Но по хорошему так делать не надо, это особенность реализации, а не гарантированное поведение. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
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, то запросы, приходящие на эти сервера будут тоже консистентными? Ещё раз спасибо и успехов Вам в
Re: Не понятна логика работы hash consistent
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/ ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Не понятна логика работы hash consistent
Здравствуйте. Подскажите пожалуйста, это у меня не работает консистентное хеширование или я не верно понимаю алгоритм его работы. У меня в системе апстримы в конфигурации ниже являются кеширующими прокси. Недавно понадобилось перераспределить часть нагрузки между ними и понял, что веса работают не так, как я ожидал. Опишу по порядку. С пол года конфигурация была такой. Кеш на прокси апстримах прогрелся до 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-le...@nginx.org