Sticky session что это
Балансировка нагрузки: основные алгоритмы и методы
Вопрос о планировании нагрузки следует решать ещё на ранней стадии развития любого веб-проекта. «Падение» сервера (а оно всегда происходит неожиданно, в самый неподходящий момент) чревато весьма серьёзными последствиями — как моральными, так и материальными. Первоначально проблемы недостаточной производительности сервера в связи ростом нагрузок можно решать путем наращивания мощности сервера, или же оптимизацией используемых алгоритмов, программных кодов и так далее. Но рано или поздно наступает момент, когда и эти меры оказываются недостаточными.
Приходится прибегать к кластеризации: несколько серверов объединяются в кластер; нагрузка между ними распределяется при помощи комплекса специальных методов, называемых балансировкой. Помимо решения проблемы высоких нагрузок кластеризация помогает также обеспечить резервирование серверов друг на друга.
Эффективность кластеризации напрямую зависит от того, как распределяется (балансируется) нагрузка между элементами кластера.
Балансировка нагрузки может осуществляться при помощи как аппаратных, так и программных инструментов. Об основных методах и алгоритмах и балансировки мы бы хотели рассказать в этой статье.
Уровни балансировки
Процедура балансировки осуществляется при помощи целого комплекса алгоритмов и методов, соответствующим следующим уровням модели OSI:
Рассмотрим эти уровни более подробно.
Балансировка на сетевом уровне
Балансировка на сетевом уровне предполагает решение следующей задачи: нужно сделать так, чтобы за один конкретный IP-адрес сервера отвечали разные физические машины. Такая балансировка может осуществляться с помощью множества разнообразных способов.
Балансировка на транспортном уровне
Этот вид балансировки является самым простым: клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который и будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами (об этом ещё пойдёт речь ниже): путём простого кругового перебора, путём выбора наименее загруженного сервера из пула и т.п.
Иногда балансировку на транспортном уровне сложно отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого фильтра pf в BSD-системах: так, например, формально тут идет речь про балансировку трафика на конкретном порту TCP (пример для сетевого фильтра pf в BSD-системах):
Речь в нём идет о балансировке трафика на конкретном порту TCP.
Рассмотрим теперь другой пример:
В этом правиле речь о балансировке исходящего трафика на сетевом уровне. В нём не указано ни конкретного порта, ни конкретного протокола.
Различие между уровнями балансировки можно объяснить следующим образом. К сетевому уровню относятся решения, которые не терминируют на себе пользовательские сессии. Они просто перенаправляют трафик и не работают в проксирующем режиме.
На сетевом уровне балансировщик просто решает, на какой сервер передавать пакеты. Сессию с клиентом осуществляет сервер.
На транспортном уровене общение с клиентом замыкается на балансировщике, который работает как прокси. Он взаимодействует с серверами от своего имени, передавая информацию о клиенте в дополнительных данных и заголовках. Таким образом работает, например, популярный программный балансировщик HAProxy.
Балансировка на прикладном уровне
В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы оп серверам баз данных в зависимости от их содержания,: например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой. Подробнее о pgpool и специфике работы с ним можно почитать в этой статье ).
Алгоритмы и методы балансировки
Существует много различных алгоритмов и методов балансировки нагрузки. Выбирая конкретный алгоритм, нужно исходить, во-первых, из специфики конкретного проекта, а во-вторых — из целей. которые мы планируем достичь.
В числе целей, для достижения которых используется балансировка, нужно выделить следующие:
Очень желательно также, чтобы алгоритм балансировки обладал следующими свойствами:
Round Robin
Round Robin, или алгоритм кругового обслуживания, представляет собой перебор по круговому циклу: первый запрос передаётся одному серверу, затем следующий запрос передаётся другому и так до достижения последнего сервера, а затем всё начинается сначала.
Самой распространёной имплементацией этого алгоритма является, конечно же, метод балансировки Round Robin DNS. Как известно, любой DNS-сервер хранит пару «имя хоста — IP-адрес» для каждой машины в определённом домене. Этот список может выглядеть, например, так:
С каждым именем из списка можно ассоциировать несколько IP-адресов:
DNS-сервер проходит по всем записям таблицы и отдаёт на каждый новый запрос следующий IP-адрес: например, на первый запрос — xxx.xxx.xxx.2, на второй — ххх.ххх.ххх.3, и так далее. В результате все серверы в кластере получают одинаковое количество запросов.
В числе несомненных плюсов этого алгоритма следует назвать, во-первых, независимость от протокола высокого уровня. Для работы по алгоритму Round Robin используется любой протокол, в котором обращение к серверу идёт по имени.
Балансировка на основе алгоритма Round Robin никак не зависит от нагрузки на сервер: кэширующие DNS-серверы помогут справиться с любым наплывом клиентов.
Использование алгоритма Round Robin не требует связи между серверами, поэтому он может использоваться как для локальной, так и для глобальной балансировки,.
Наконец, решения на базе алгоритма Round Robin отличаются низкой стоимостью: чтобы они начали работать, достаточно просто добавить несколько записей в DNS.
Алгоритм Round Robin имеет и целый ряд существенных недостатков недостатков. Чтобы распределение нагрузки по этому алгоритму отвечало упомянутым выше критериями справедливости и эффективности, нужно, чтобы у каждого сервера был в наличии одинаковый набор ресурсов. При выполнении всех операций также должно быть задействовано одинаковое количество ресурсов. В реальной практике эти условия в большинстве случаев оказываются невыполнимыми.
Также при балансировке по алгоритму Round Robin совершенно не учитывается загруженность того или иного сервера в составе кластера. Представим себе следующую гипотетическую ситуацию: один из узлов загружен на 100%, в то время как другие — всего на 10 — 15%. Алгоритм Round Robin возможности возникновения такой ситуации не учитывает в принципе, поэтому перегруженный узел все равно будет получать запросы. Ни о какой справедливости, эффективности и предсказуемости в таком случае не может быть и речи.
В силу описанных выше обстоятельств сфера применения алгоритма Round Robin весьма ограничена.
Weighted Round Robin
Это — усовершенствованная версия алгоритма Round Robin. Суть усовершенствований заключается в следующем: каждому серверу присваивается весовой коэффициент в соответствии с его производительностью и мощностью. Это помогает распределять нагрузку более гибко: серверы с большим весом обрабатывают больше запросов. Однако всех проблем с отказоустойчивостью это отнюдь не решает. Более эффективную балансировку обеспечивают другие методы, в которых при планировании и распределении нагрузки учитывается большее количество параметров.
Least Connections
В предыдущем разделе мы перечислили основные недостатки алгоритма Round Robin. Назовём ещё один: в нём совершенно не учитывается количество активных на данный момент подключений.
Рассмотрим практический пример. Имеется два сервера — обозначим их условно как А и Б. К серверу А подключено меньше пользователей, чем к серверу Б. При этом сервер А оказывается более перегруженным. Как это возможно? Ответ достаточно прост: подключения к серверу А поддерживаются в течение более долгого времени по сравнению с подключениями к серверу Б.
Описанную проблему можно решить с помощью алгоритма, известного под названием least connections (сокращённо — leastconn). Он учитывает количество подключений, поддерживаемых серверами в текущий момент времени. Каждый следующий вопрос передаётся серверу с наименьшим количеством активных подключений.
Существует усовершенствованный вариант этого алгоритма, предназначенный в первую очередь для использования в кластерах, состоящих из серверов с разными техническими характеристиками и разной производительностью. Он называется Weighted Least Connections и учитывает при распределении нагрузки не только количество активных подключений, но и весовой коэффициент серверов.
В числе других усовершенствованных вариантов алгоритма Least Connections следует прежде всего выделить Locality-Based Least Connection Scheduling и Locality-Based Least Connection Scheduling with Replication Scheduling.
Первый метод был создан специально для кэширующих прокси-серверов. Его суть заключается в следующем: наибольшее количество запросов передаётся серверам с наименьшим количеством активных подключений. За каждым из клиентских серверов закрепляется группа клиентских IP. Запросы с этих IP направляются на «родной» сервер, если он не загружен полностью. В противном случае запрос будет перенаправлен на другой сервер (он должен быть загружен менее чем наполовину).
В алгоритме Locality-Based Least Connection Scheduling with Replication Scheduling каждый IP-адрес или группа IP-адресов закрепляется не за отдельным сервером, а за целой группой серверов. Запрос передаётся наименее загруженному серверу из группы. Если же все серверы из «родной» группы перегружены, то будет зарезервирован новый сервер. Этот новый сервер будет добавлен к группе, обслуживающей IP, с которого был отправлен запрос. В свою очередь наиболее загруженный сервер из этой группы будет удалён — это позволяет избежать избыточной репликации.
Destination Hash Scheduling и Source Hash Scheduling
Алгоритм Destination Hash Scheduling был создан для работы с кластером кэширующих прокси-серверов, но он часто используется и в других случаях. В этом алгоритме сервер, обрабатывающий запрос, выбирается из статической таблицы по IP-адресу получателя.
Алгоритм Source Hash Scheduling основывается на тех же самых принципах, что и предыдущий, только сервер, который будет обрабатывать запрос, выбирается из таблицы по IP-адресу отправителя.
Sticky Sessions
Sticky Sessions — алгоритм распределения входящих запросов, при котором соединения передаются на один и тот же сервер группы. Он используется, например, в веб-сервере Nginx. Сессии пользователя могут быть закреплены за конкретным сервером с помощью метода IP hash (подробную информацию о нём см. в официальной документации ). С помощью этого метода запросы распределяются по серверам на основе IP-aдреса клиента. Как указано в документации (см. ссылку выше), «метод гарантирует, что запросы одного и того же клиента будет передаваться на один и тот же сервер». Если закреплённый за конкретным адресом сервер недоступен, запрос будет перенаправлен на другой сервер. Пример фрагмента конфигурационного файла:
Начиная с версии 1.2.2 в Nginx для каждого сервера можно указывать вес.
Заключение
Эта статья по сути представляет собой введение в проблематику балансировки нагрузки. Обсуждение этой темы мы продолжим и в дальнейших публикациях. Если у вас есть вопросы, замечания и дополнения — добро пожаловать в комментарии. Будем также признательны, если вы поделитесь нетривиальными практическими примерами организации балансировки нагрузки для различных проектов.
Липкие и не липкие сессии
Я хочу знать разницу между липкими и нелипкими сессиями. Что я понял после прочтения из интернета:
Важно : только один объект сеанса будет там.
Non-sticky session : объект сеанса для каждого узла сервера
Когда ваш веб-сайт обслуживается только одним веб-сервером, для каждой пары клиент-сервер создается объект сеанса, который остается в памяти веб-сервера. Все запросы от клиента отправляются на этот веб-сервер и обновляют этот объект сеанса. Если некоторые данные необходимо хранить в объекте сеанса в течение периода взаимодействия, они сохраняются в этом объекте сеанса и остаются там до тех пор, пока существует сеанс.
Если подсистеме балансировки нагрузки предписано использовать липкие сеансы, все ваши взаимодействия будут происходить с одним и тем же физическим сервером, даже если присутствуют другие серверы. Таким образом, ваш объект сеанса будет одинаковым на протяжении всего вашего взаимодействия с этим сайтом.
Подводя итог, можно сказать, что в случае Sticky Sessions все ваши запросы будут направлены на один и тот же физический веб-сервер, а в случае несвязанного loadbalancer может выбрать любой веб-сервер для обслуживания ваших запросов.
В качестве примера вы можете прочитать об Amazon Elastic Load Balancer и липких сессиях здесь: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
Я сделал ответ с более подробной информацией здесь: https://stackoverflow.com/a/11045462/592477
Или вы можете прочитать это там ==>
Когда вы используете балансировку нагрузки, это означает, что у вас есть несколько экземпляров tomcat, и вам нужно разделить нагрузки.
Sticky and NON-Sticky sessions
I want to know the difference between sticky- and non-sticky sessions. What I understood after reading from internet:
Sticky : only single session object will be there.
Non-sticky session : session object for each server node
2 Answers 2
When your website is served by only one web server, for each client-server pair, a session object is created and remains in the memory of the web server. All the requests from the client go to this web server and update this session object. If some data needs to be stored in the session object over the period of interaction, it is stored in this session object and stays there as long as the session exists.
However, if your website is served by multiple web servers which sit behind a load balancer, the load balancer decides which actual (physical) web-server should each request go to. For example, if there are 3 web servers A, B and C behind the load balancer, it is possible that www.mywebsite.com is served from server A, www.mywebsite.com is served from server B and www.mywebsite.com/ are served from server C.
If the load balancer is instructed to use sticky sessions, all of your interactions will happen with the same physical server, even though other servers are present. Thus, your session object will be the same throughout your entire interaction with this website.
To summarize, In case of Sticky Sessions, all your requests will be directed to the same physical web server while in case of a non-sticky load balancer may choose any webserver to serve your requests.
As an example, you may read about Amazon’s Elastic Load Balancer and sticky sessions here : http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
I’ve made an answer with some more details here : https://stackoverflow.com/a/11045462/592477
Or you can read it there ==>
When you use loadbalancing it means you have several instances of tomcat and you need to divide loads.
Привязка сессии к серверу в Nginx. Nginx-sticky-module
Sticky session — метод балансировки нагрузки, при котором запросы клиента передаются на один и тот же сервер группы.
Самый простой способ закрепить сессии пользователя за конкретным сервером в Nginx — использовать метод ip-hash:
При использовании этого метода запросы распределяются по серверам на основе IP-адресов клиента. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер(с). Из метода балансировки следуют его минусы: проблемы поддержки сессии при использовании клиентом динамического IP; не равновесная балансировка, если большое количество запросов, например, проходит через один прокси сервер. Использование cookie решает эти проблемы.
В Nginx существует метод sticky использующий cookie для балансировки, правда только в коммерческой версии. Есть и более бесплатный путь — использование внешних модулей.
Nginx-sticky-module
Модуль создает cookie — чем делает каждый браузер уникальным — и далее использует его для переадресации запросов на один и тот же сервер. При отсутствии cookie, например при первом запросе, сервер выбирается случайным образом. Проект был разветвлен, оригинальная версия больше не поддерживается, поддерживаемое ответвление называется nginx-sticky-module-ng и находится здесь. Обе ссылки приведены т.к. при google запросе «sticky session nginx» первой в списке, после ссылок на официальный сайт nginx, оказывается ссылка именно на оригинальный сайт проекта. И если вы, как и я, не обратили внимание на едва заметный подзаголовок, написанный заглавными буквами и жирным шрифтом: DEPRECATED и ниже на ссылку на поддерживаемую версию — перед инсталляцией модуля потребуется внести в исходный код некоторые изменения. Дело в том, что начиная с версии nginx 1.5.8 поменялся API для nginx метода ngx_sock_ntop(), поэтому в файле ngx_http_sticky_misc.c архива nginx-sticky-module строку
Чтобы установить этот модуль, нужно скомпилировать Nginx с этим модулем. Для этого нужно, если нет, установить компилятор С/С++ и библиотеки, используемые nginx (для RedHat/CentOS):
скачать последнюю версию исходников Nginx, распаковать ее в не труднодоступное место, найти в распакованном папку src, распаковать в нее архив nginx-sticky-module или nginx-sticky-module-ng и далее определившись с опциями nginx, которые будут нужны, скомпилировать
init.d script можно найти здесь, который нужно скопировать в файл:
и дать ему права запуска
после чего можно использовать команды сервиса и настроить автоматический запуск после перезагрузки:
Настройка sticky session выглядит не сложнее, чем для метода ip_hash:
По умолчанию будет создаваться cookie с именем route и временем жизни 1 час. Метод может принимать несколько аргументах, о которых можно узнать на сайтах модулей.
Для любителей извращений и обходиться без сторонних модулей можно использовать настройку sticky session представленную здесь.
Липкие сессии для самых маленьких [Часть 2], или Как понять Kubernetes и преисполниться в своём познании
Липкие сессии (Sticky-session) — это особый вид балансировки нагрузки, при которой трафик поступает на один определенный сервер группы. Как правило, перед группой серверов находится балансировщик нагрузки (Nginx, HAProxy), который и устанавливает правила распределения трафика на доступные сервера.
В первой части цикла мы уже разобрали как создавать липкие сессии с помощью Nginx. Во второй части разберем создание подобной балансировки средствами Kubernetes.
Все примеры будут под систему MacOS. Установку для других систем смотрите в официальной документации.
Чтобы запустить minikube выполните команду:
Работать с кубом можно через командную строку, для этого нужно установить kubectl.
Эта утилитка ставится и для взаимодействия с реальным кубом. Чтобы посмотреть дашборд с графиками и картиночками выполните:
Только учтите, что команда заблокирует вам консоль, поэтому лучше откройте еще одно окно.
На этом установка учебного кластера завершена. Как по мне, для понимания основ kubernetes нужно разобрать всего 4 ресурса:
В таком порядке и будем рассматривать каждый ресурс по мере запуска приложения в кластере.
Использовать будем код из предыдущей статьи.
Здесь переменная uuid инициализируется вместе с FastAPI приложением. Переменная будет жить, пока работает сервер. Собственно, по значению этой переменной мы будем точно знать, что попали на тот же самый экземпляр приложения.
После сборки я запушил образ в свой публичный репозиторий docker hub:
Всё, мы готовы разворачивать приложение. Для этого нужно кубу указать ряд правил, которыми он будет руководствоваться при запуске вашего приложения. Такие правила называются конфигурацией развертывания (Deployments).
Обычно любой ресурс в Kubernetes описывается в yaml файлах. В нашем случае правил развертывания не много, поэтому обойдемся короткой командой по созданию объекта deployment.
В -–image можете указать свое приложение, которое залили в публичный репозиторий docker hub.
При создании ресурса deployment, создается так же пода (Pod) на узле. Пода это минимальная единица куба, в котором запускается контейнер или множество контейнеров докера. Deployment отслеживает состояние и работоспособность под. Если какая выйдет из строя, то он оперативно запустит новую.
Проверим, что создалось два ресурса deployment и pod.
Про «kubectl get»
kubctl довольно user friendly, например в команде get можно попросить как pod, так и pods, deployment или deployments и т.д.. Можно через запятую (без пробела) перечислить ресурсы, которые хотим получить.
Масштабируем наше приложение до двух сервисов.
И снова проверим состояние pods и deployment, вывод должен быть примерно такой:
Новая пода стала запускаться.
эксперименты с deployment
Как только две поды будут запущены, можно наглядно продемонстрировать работу deployment.
Удалим собственоручно поду pod/sticky-d-57444787d8-rdn6q:
Снова запросим текущее состояние pods и deployment:
Не успела пода *-rdn6q удалиться, на ее место пришла уже новая *-6gjmv.
Теперь давайте отправим запросы на развернутые приложения. Напрямую это сделать не удастся, для этого придумали сервис (Service).
Сервис (Service) в Kubernetes — это абстрактный объект (ресурс), который предоставляет доступ к запущенным подам. Хотя у каждого пода есть уникальный IP-адрес, эти IP-адреса не доступны за пределами кластера без использования сервиса. Сервисы позволяют приложениям принимать трафик и являются стандартным балансировщиком нагрузки на поды.
Сервисы могут по-разному открыты, в зависимости от указанного поля type:
Создадим сервис с типом LoadBalancer. Балансировка происходит по принципу random balancing (про это можно почитать в этой статье, которая ссылается сюда).
Запустить сервис можно командой:
Вывод будет примерно такой:
Отправим запросы на сервис и убедимся, что трафик поступает на разные поды:
Балансировщик не работает? Или мы добились своей цели и получили липкие сессии? Почти!
Мы получили липки сессии курильщика. Дело в том, пока открыто TCP соединение с сервером куб направляет трафик только на одну определенную поду. Но если будет обрыв соединения или мы создадим новое соединение, то можем попасть уже на другую поду. Подробнее об этом смотрите в этой отличной статье. Не такие липкие сессии нужны Готему сейчас. Чтобы обойти эту особенность необходимо убрать галочку keep-alive в Postman.
Посмотрим, что произойдет:
Ура! Мы убедились, что трафик балансируется.
Ресурс сервис довольно бедный балансировщик и умеет распределять трафик для определенного развертывания. Тут вступает ingress, который довольно сильно расширяет возможности балансировки в kubernetes.
Если просто создать ресурс ingress, то ничего не произойдет. Нужно создать ingress-controller. Для активации ingress-controller выполните:
проблемы с активацией ingress-controller?
Для macOS и Windows на момент написания статьи может произойти ошибка, чтобы это поправить нужно выполнить следующие команды:
Это приведет к стиранию всех развертываний и под. Вернитесь назад и повторите развертывание приложения и запуск сервиса.
При успешном запуске Ingress-controller запустится специальная пода, выполните команду:
Результат должен примерно таким:
Подробно на простых примерах зачем нужен ingress
Ingress позволяет балансировать трафик по имени хоста или на основе пути в запросе. Рассмотрим простой пример. Допустим у нас есть два приложения app1 и app2. После мы купили доменное имя, пусть будет awesome-company.com. И мы хотим чтобы наши сервисы были доступны по адресу:
awesome-company.com/app1
awesome-company.com/app2
app1.awesome-company.com
app2.awesome-company.com
Можно так же сделать комбинацию этих двух вариантов.
Ресурс ingress как раз и позволяет это сделать. Ingress балансирует трафик на разные сервисы, являясь такой надстройкой над ними.
Теперь создадим ресурс Ingress. Сделайте новый файлик ingress.yml и вставьте следующий текст:
Все ресурсы описанные в yml файлах применяются командой apply. Проверим, появился ли ingress объект:
Обратите внимание на адрес ресурса, если сделать запрос на 192.168.64.3:80 будет ошибка 404.
«Разрешим» локально доменное имя. Откройте файл /etc/hosts и в последней строчке через пробел запишите ip адрес ingress ресурса и доменное имя сервиса.
И попробуем отправить теперь запрос по адресу sticky.info:
Надо отметить, что балансировка работает несмотря на включенную галочку connection.
Можно схитрить и не определять локально доменное имя. Просто в заголовке запроса указать хост:
На этом завершается краткая вводная по основам kubernetes. Мы успешно развернули простенькое приложение в кластере и получили к нему доступ. Теперь можно глубже погружаться в теорию: например почитать про namespace (мы разворачивали приложение в default пространстве), почитать про остальные ресурсы куба и конечно вникнуть про создание объектов в формате yml.
Теперь наконец сделаем наш трафик липким. Добавим в Ingress.yml annotations c 4 параметрами:
Рассмотрим каждый параметр подробнее:
affinity: укажите значение “cookie”, чтобы включить липкие сессии;
affinity-mode: режим прилипания. Поддерживается два режима — persistent и balanced. При значении balanced трафик будет прилипать к определенному поду только на некоторый промежуток времени. Для вечного прилипания укажите persistent;
session-cookie-name: имя cookie, по значению которого ingress-controller будет ассоциировать трафик с определенной подой;
session-cookie-max-age: время, на которое трафик прилипает к поду, в секундах (настройка нужна если affinity-mode = balanced). После истечения заданного времени ingress-controller сгенеририт новое значение для session-cookie-name и вставит нам в cookie.
И проверим работу липких сессий в кубе:
Ответы будут приходить только от одного конкретного экземпляра приложения. Обратите внимание, что ingress-controller сам подставил нам в cookie значение для key и добавил срок годности прилипания. Через 60 секунд nginx-controller снова сгенерит значение для key, и трафик уже прилипнет к другой поде (но не факт, что к другой).
Теперь посмотрим как это выглядит в коде:
В цикле делаем запрос к приложению и выводим результат запроса и объект cookie.
Ingress-controller сгенерил key и подставил нам в cookie объект Set-Cookie. Трафик прилип на 60 секунд к определенной поде.
Готово! Мы успешно реализовали липкие сессии в Nginx и Kubernetes.
И напоследок результаты соц. опроса среди IT компаний о необходимости Kubernetes.