Что вы знаете о балансировке нагрузки виды

Что вы знаете о балансировке нагрузки виды

При проектировании любых информационных систем одной из существенных задач является планирование её производительности. Ведь всем нам хочется получать ответы на наши запросы и реакцию на наши действия быстро.

Этой цели легко достичь, применив более мощное вычислительное оборудование, но как любой ресурс оно имеет свою стоимость. Поэтому в реальных условиях стараются найти разумное соотношение между ожидаемой нагрузкой на проектируемую информационную систему и характеристиками её аппаратной части.

Поиск правильного номинального уровня производительности представляет особую трудность в случае публичных информационных систем типа социальных сетей, интернет-магазинов, досок объявлений, видеохостинга и т. д.

Например, после какой-нибудь рекламы нагрузка на эти сервисы может за считанные часы измениться даже не в разы, а на порядок. В коммерческом плане, это — очень хорошо, но если нагрузка на сайт превысить некий критический порог, он просто перестанет работать, и деньги, потраченные на рекламу, не принесут пользы. Наоборот, неработающий сайт может вызвать обратный, негативный, эффект.

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

Понимая возможность возникновения таких ситуаций, проектировщики информационных систем стараются предусмотреть в них средства масштабирования, то есть возможность изменения её производительности посредством относительно малых изменений, не нарушающих фундаментальной архитектуры системы.

Масштабирование системы

Этому вопросу посвящена наша статья «Масштабирование в облаке».

Кратко, выделяют два подхода с условными названиями: вертикальное и горизонтальное масштабирование.

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

Горизонтальное масштабирование — это применение вместо одного элемента нескольких однотипных, работающих параллельно так, чтобы суммарно обеспечить требующуюся производительность.

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

Типовая архитектура

При проектировании информационных систем уже давно применяется подход, при котором она разделяется на несколько функциональных уровней.

Чаще применяют три уровня: хранение данных, их обработка и представление.

В эту трёхуровневую архитектуру хорошо вписывается метод горизонтального масштабирования. Работу элементов на каждом из уровней можно запараллелить, объединив их в функциональную группу. Эти группы совместно работающих элементов часто называют кластерами или пулами ресурсов.

Совсем необязательно, чтобы в каждой группе было много элементов. Иногда уже два элемента могут заметно улучшить характеристики системы.

Для правильной работы элементов в группе требуется их как-то координировать, распределять между ними общую нагрузку. Такое распределение называется балансировкой нагрузки.

Существуют разные подходы к её организации.

Цели распределения нагрузки

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

Благодаря наличию в группе однотипных элементов, в неё можно добавлять новые элементы или исключать имеющиеся, чтобы привести общую производительность к желанному значению.

Использование нескольких элементов вместо одного повышает отказоустойчивость системы, так как выход из строя одного элемента не остановит работы остальных и группы, в целом.

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

Варианты балансировки нагрузки

Термины распределение нагрузки и балансировка нагрузки — близкие, но не вполне взаимозаменяемые.

Слово «балансировка» всегда предполагает динамический процесс, а распределение может быть ещё и статическим или псевдодинамическим. То есть балансировка нагрузки является частным случаем её распределения, при котором учитываются какие-то дополнительные изменяющиеся факторы.

Методов распределения нагрузки существует много.

Статическое распределение

Лучше объяснить на примерах.

Предположим, у вас имеется 1000 пользователей и два идентичных веб-сервера для обслуживания этих пользователей. Вы можете сконфигурировать подсистему аутентификации ваших пользователей так, чтобы пользователи с идентификаторами с 1 до 500 обслуживались одним сервером, а с идентификаторами от 501 до 1000 — другим. Таким образом вы направите на каждый из двух своих серверов по 50% общей нагрузки.

Серверы в группе необязательно должны быть одинаковыми. Если один из них более мощный, а другой — менее, распределение пользователей между ними может сделать неравномерным, пропорциональным производительности серверов.

Второй пример — географический. Пользователей из одного региона вы можете направлять на один сервер, а из другого — на другой.

При статическом распределении привязка пользователя к конкретному серверу постоянная, не меняющаяся не по каким условиям.

Псевдодинамическое распределение

Почему о нём зашла речь до рассмотрения динамического распределения? — Потому что алгоритмы и реализация динамического распределения более сложные.

Чем плох метод статического распределения? — Тем, что в случае изменения ситуации внутри информационной системы или вокруг неё, потребуется каким-то способом вовремя заметить перемены и вручную изменить настройки.

Рассмотрим прежние примеры. Активность пользователей из одной половины списка может оказаться заметно выше активности пользователей из другой половины. Общее число пользователей может увеличиться. Активность пользователей из разных регионов может существенно изменяться в зависимости от времени суток или дней недели.

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

Неравенство производительностей серверов в группе можно учесть, например, отправляя 30% запросов на один сервер, 50% — на второй и 20% — на третий.

Не все знают, что проще всего организовать случайное распределение запросов между несколькими серверами с помощью… DNS.

Если DNS-серверу, поддерживающему ваше доменное имя, сообщить, что этому домену соответствует несколько IP-адресов, сервер будет выдавать эти адреса в случайном или циклическом порядке. При этом нет никаких ограничений на сами адреса — каждый из серверов вашей информационной системы может находиться где угодно в интернете.

У этого метода есть недостатки.

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

Для исправления ситуации потребуется вручную подкорректировать список IP-адресов на доменном сервере.

Из-за кэширования IP-адресов в DNS изменения списка адресов прикладных серверов не сразу дойдут до клиентских приложений. Периодичность обновления данных в кэше можно сократить соответствующей настройкой. Но при этом надо понимать, что от такой настройки возрастёт нагрузка на DNS-сервер.

Кроме того, этот метод не позволяет распределить нагрузку между прикладными серверами неравномерно.

Динамическое распределение

В качестве другого средства распределения нагрузки используют специализированные программные или аппаратные балансировщики.

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

В качестве программных балансировщиков HTTP-запросов часто используют разного рода прокси-серверы, перенаправляющие запросы по установленным правилам куда следует.

Проблемы балансировки нагрузки

Распределённые системы обладают такими замечательными свойствами как высокая и адаптивная производительность, высокая отказоустойчивость, хорошая ремонтопригодность. Но при этом они порождают ряд проблем.

Хранение сессии

В большинстве информационных систем, поддерживающих аутентификацию пользователей, также требуется поддерживать пользовательские сессии — набор контекстных переменных, которые создаются на сервере при обращении пользователя к сервису.

В распределённых информационных системах разные запросы пользователя в общем случае попадают на разные серверы пула. Но нельзя же требовать от пользователя по несколько раз подряд указывать свои учётные данные. Да и контекст на разных серверах всё равно окажется разным.

Для обеспечения сессий в распределённых системах применяют несколько методов.

Сессионные переменные хранят не на каждом сервере, а в общей сетевой папке или в базе данных, одинаково доступных всем прикладным серверам.

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

Кэширование содержания

В распределённых информационных системах требуется принимать дополнительные меры для правильного размещения кэшированных данных. Ведь также как сессионные переменные, они должны быть одинаково доступны всем серверам пула. Применяется аналогичный подход: кэш размещается в сетевой папке с общим доступом со всех серверов.

Остановка сервера

По каким-то причинам сервер, входящий в кластер, может прекратить свою работу. Для сохранения нормальной работы кластера, в целом, балансировщик должен вовремя узнать об аварийной ситуации и автоматически исключить из кластера сломавшийся сервер.

Заключение

Использование несколько относительно небольших серверов вместо одного большого связано с рядом сложностей и трудностей, однако они с лихвой перекрываются преимуществами распределённой информационной системы:

Балансировка нагрузки: основные алгоритмы и методы

Вопрос о планировании нагрузки следует решать ещё на ранней стадии развития любого веб-проекта. «Падение» сервера (а оно всегда происходит неожиданно, в самый неподходящий момент) чревато весьма серьёзными последствиями — как моральными, так и материальными. Первоначально проблемы недостаточной производительности сервера в связи ростом нагрузок можно решать путем наращивания мощности сервера, или же оптимизацией используемых алгоритмов, программных кодов и так далее. Но рано или поздно наступает момент, когда и эти меры оказываются недостаточными.

Приходится прибегать к кластеризации: несколько серверов объединяются в кластер; нагрузка между ними распределяется при помощи комплекса специальных методов, называемых балансировкой. Помимо решения проблемы высоких нагрузок кластеризация помогает также обеспечить резервирование серверов друг на друга.
Эффективность кластеризации напрямую зависит от того, как распределяется (балансируется) нагрузка между элементами кластера.

Балансировка нагрузки может осуществляться при помощи как аппаратных, так и программных инструментов. Об основных методах и алгоритмах и балансировки мы бы хотели рассказать в этой статье.

Уровни балансировки

Процедура балансировки осуществляется при помощи целого комплекса алгоритмов и методов, соответствующим следующим уровням модели OSI:

• сетевому;
• транспортному;
• прикладному.

Рассмотрим эти уровни более подробно.

Балансировка на сетевом уровне

Балансировка на сетевом уровне предполагает решение следующей задачи: нужно сделать так, чтобы за один конкретный IP-адрес сервера отвечали разные физические машины. Такая балансировка может осуществляться с помощью множества разнообразных способов.

• DNS-балансировка. На одно доменное имя выделяется несколько IP-адресов. Сервер, на который будет направлен клиентский запрос, обычно определяется с помощью алгоритма Round Robin (о методах и алгоритмах балансировки будет подробно рассказано ниже).
• Построение NLB-кластера. При использовании этого способа серверы объединяются в кластер, состоящий из входных и вычислительных узлов. Распределение нагрузки осуществляется при помощи специального алгоритма. Используется в решениях от компании Microsoft.
• Балансировка по IP с использованием дополнительного маршрутизатора.
• Балансировка по территориальному признаку осуществляется путём размещения одинаковых сервисов с одинаковыми адресами в территориально различных регионах Интернета (так работает технология Anyсast DNS, о которой мы уже писали). Балансировка по территориальному признаку также используется во многих CDN (см. интересный пример реализации).

Балансировка на транспортном уровне

Этот вид балансировки является самым простым: клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который и будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами (об этом ещё пойдёт речь ниже): путём простого кругового перебора, путём выбора наименее загруженного сервера из пула и т.п.

Иногда балансировку на транспортном уровне сложно отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого фильтра pf в BSD-системах: так, например, формально тут идет речь про балансировку трафика на конкретном порту TCP (пример для сетевого фильтра pf в BSD-системах):

Речь в нём идет о балансировке трафика на конкретном порту TCP.

Рассмотрим теперь другой пример:

В этом правиле речь о балансировке исходящего трафика на сетевом уровне. В нём не указано ни конкретного порта, ни конкретного протокола.

Различие между уровнями балансировки можно объяснить следующим образом. К сетевому уровню относятся решения, которые не терминируют на себе пользовательские сессии. Они просто перенаправляют трафик и не работают в проксирующем режиме.
На сетевом уровне балансировщик просто решает, на какой сервер передавать пакеты. Сессию с клиентом осуществляет сервер.

На транспортном уровене общение с клиентом замыкается на балансировщике, который работает как прокси. Он взаимодействует с серверами от своего имени, передавая информацию о клиенте в дополнительных данных и заголовках. Таким образом работает, например, популярный программный балансировщик HAProxy.

Балансировка на прикладном уровне

При балансировке на прикладном уровне балансировщик работает в режиме «умного прокси». Он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Так работает, например, веб-сервер Nginx, распределяя запросы между фронтендом и бэкендом. За балансировку в Nginx отвечает модуль Upstream. Более подробно об особенностях балансировки Nginx на основе различных алгоритмов можно прочитать, например, здесь.

В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы оп серверам баз данных в зависимости от их содержания,: например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой. Подробнее о pgpool и специфике работы с ним можно почитать в этой статье).

Алгоритмы и методы балансировки

Существует много различных алгоритмов и методов балансировки нагрузки. Выбирая конкретный алгоритм, нужно исходить, во-первых, из специфики конкретного проекта, а во-вторых — из целей. которые мы планируем достичь.

В числе целей, для достижения которых используется балансировка, нужно выделить следующие:

• справедливость: нужно гарантировать, чтобы на обработку каждого запроса выделялись системные ресурсы и не допустить возникновения ситуаций, когда один запрос обрабатывается, а все остальные ждут своей очереди;
• эффективность: все серверы, которые обрабатывают запросы, должны быть заняты на 100%; желательно не допускать ситуации, когда один из серверов простаивает в ожидании запросов на обработку (сразу же оговоримся, что в реальной практике эта цель достигается далеко не всегда);
• сокращение времени выполнения запроса: нужно обеспечить минимальное время между началом обработки запроса (или его постановкой в очередь на обработку) и его завершения;
• сокращение времени отклика: нужно минимизировать время ответа на запрос пользователя.

Очень желательно также, чтобы алгоритм балансировки обладал следующими свойствами:

• предсказуемость: нужно чётко понимать, в каких ситуациях и при каких нагрузках алгоритм будет эффективным для решения поставленных задач;
• равномерная загрузка ресурсов системы;
• масштабирумость: алгоритм должен сохранять работоспособность при увеличении нагрузки.

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 для каждого сервера можно указывать вес.

Применение этого метода сопряжено с некоторыми проблемами. Проблемы с привязкой сессий могут возникнуть, если клиент использует динамический IP. В ситуации, когда большое количество запросов проходит через один прокси-сервер, балансировку вряд ли можно назвать эффективной и справедливой. Описанные проблемы, однако, можно решить, используя cookies. В коммерческой версии Nginx имеется специальный модуль sticky, который как раз использует cookies для балансировки. Есть у него и бесплатные аналоги — например, nginx-sticky-module.
Можно использовать метод sticky-sessions и в HAProxy — подробнее об этом можно прочитать, например, здесь.

Заключение

Эта статья по сути представляет собой введение в проблематику балансировки нагрузки. Обсуждение этой темы мы продолжим и в дальнейших публикациях. Если у вас есть вопросы, замечания и дополнения — добро пожаловать в комментарии. Будем также признательны, если вы поделитесь нетривиальными практическими примерами организации балансировки нагрузки для различных проектов.

Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем в наш блог.

Балансировщики нагрузки для высоконагруженных систем

Балансировщики нагрузки для высоконагруженных систем

Серверы подвергаются большим нагрузкам. Во избежание выхода их из строя используется метод балансировки. Он позволяет оптимизировать эксплуатацию ресурсами, способствует увеличению продуктивности сервисов и снижает длительность обработки запросов.

Функция балансировщика в персональном компьютере заключается в недопущении перегруза систем ПК путем раздела нагрузки между дисками, процессорами и сетями. Результатом станет повышение скорости отзыва программ устройства.

Балансировка на сетевом уровне

Если интернет-каналы либо иное цифровое оборудование испытывает сверхсильное напряжение и не в состоянии его выдержать, то веб-сервер выходит из строя, приходит в негодность. Не допустить подобного падения сайтам помогает использование виртуального распределителя нагрузки.

Сигналом к тому, что web-сервер работает на грани своих возможностей, является падение скорости при переработке запросов. Игнорировать такие вещи не стоит, надлежит сразу разделить объем работы на несколько устройств.

Иногда проблему стараются решить с помощью добавления к старому маршрутизатору нового, но такая комбинация не сработает, если балансировщик не настроить на нужные параметры. В противном случае львиная доля загруженности так и останется на старом приборе, а новый будет функционировать в штатном режиме. Чтобы этого не произошло, необходимо сбалансировать нагрузку на программном уровне.

Для уравнивания напряжения существует ряд тактик:

• наращивание пропускной способности;
• модернизация и оптимизация программных алгоритмов;
• установка мощного сетевого оборудования;
• задействовать облачные серверы;
• воспользоваться кэшированием или репликацией.

Процесс уравновешивания включает присоединение нескольких серверов в единую систему – кластер. По специальному алгоритму напряжение в равных долях делится на все web-субъекты. Кластером может быть server с наименьшей загруженностью в текущий период времени или тот, что лучше подходит территориально.

Принимая в расчет алгоритм балансировщика, задачи на него возложены следующие:

• поддержание надлежащего уровня работоспособности при сверхнагрузках;
• равномерно распределять виртуальные ресурсы;
• быстро откликаться на требования юзеров;
• мониторить наполнение серверов и не допускать простаивания некоторых устройств, если другие перенапряжены.

Не менее важно – простота использования. Клиент должен ориентироваться в сроках обработки требований и способах перераспределения нагрузки.

Принципы работы балансировщика

Группирование объема заданий происходит по устойчивым алгоритмам. Популярные среди них:

• Round Robin;
• Round Robin Weight;
• Sticky;
• проксирование.

Round Robin – бюджетный алгоритм, круговой. Его суть заключается в перебирании клиентов по кругу. Запросы обрабатываются в зависимости от последовательности сервера. Используется с любым DNS маршрутизатором и протоколом. Способ не берет во внимание наполнение прокси-серверов в настоящий промежуток времени и не нуждается в привязки к другим аппаратам.

Алгоритм Round Robin Weight оценивает «вес» и потом отправляет запрос на менее занятый сервер. Он считается более гибким вариантом предыдущего.

При использовании Sticky-метода вопросы каждого IP направляются на конкретный сервер. Такой порядок действий сохраняется постоянно. В случае возникновения неполадок с закрепленным устройством запрос перенаправляется на иной server.

Проксирование – это та же балансировка. Применение данного метода подразумевает распределение задач на 2 уровнях – 4 (TCP) и 7 (HTTP). Информационные запросы от пользователя расходятся по разным маршрутам, что и определяет сходство проксирования с балансировкой.

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

Виды уравнения балансировки

Существует некая схема, от места расположения в ней балансировщика зависит его функционал. Выглядит он следующим образом: бэкенд – балансировщик – клиент.

1. Размещение балансировки посередине – самое простое уравнение. Топология включает чистые и облачные программы либо работает через приборный балансировщик.
2. Если схема уравновешивания находится с краю, то достаточно интернет-подключения, чтобы его задействовать.
3. Компьютерный модуль встраивается напрямую через библиотеку. В таком случае отказ невозможен, чем не могут похвастаться предыдущие виды.

Для удобства пользования библиотечным подходом был создан прокси-сервер sidecar. Он избавляет от потребности в программном обновлении библиотеки и совершенствовании на всевозможных языках.

Особенности глобальной балансировки

Часто компании пытаются нарастить производственную мощность и сконцентрировать серверы в конкретном месте. Но у такого подхода прослеживаются существенные минусы:

• доступность уменьшается через точку отказа в одном и том же месте;
• пользователи, находящиеся территориально далеко, будут дольше ждать ответа.

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

Аббревиатурой GSLB обозначается глобальная банансировка. Что она собой представляет? Разные центры по обработке данных объединяются в единую группу. География расположения центров разная. При получении запроса от пользователя группа перенаправляет его к ближайшему и наименее загруженному серверу. Таким образом процесс обработки происходит непрерывно.

Вывод

Без балансировки нагрузки обойтись в системах распределения невозможно. Выбирать балансировщика следует, исходя из его функционала и способности выполнять определенные задачи. Гнаться за мощностью в этом случае нецелесообразно.

что помогает увеличить скорость отклика и предупредить их перегрузку.

Балансировщик сетевой нагрузки

Все хоть раз слышали выражение: «сайт упал» или «сервер упал», по причине того, что интернет-канал или оборудование не выдержали оказываемую на них нагрузку. Чтобы таких ситуаций не происходило, используется сетевой балансировщик нагрузки.

Когда нагрузка на web сервер возрастает, скорость обработки запросов сильно падает, очевидным решением является распределить нагрузку на несколько серверов. При этом даже при установке нового сервера, если забыть настроить балансировщик трафика между ними, после его запуска часто можно столкнуться с ситуацией, что на новый сервер нагрузка нормальная, а на старый по-прежнему зашкаливает. Поэтому появляется необходимость балансировки нагрузки на уровне сети.

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

Это может быть специальный алгоритм, при помощи коего происходит объединение нескольких серверов в кластер , между которыми распределяется нагрузка или использование функции, распределяющую нагрузку на Веб-сервера равномерно (это может быть наименее загруженный на текущий момент сервер или сервер, выбранный по территориальному признаку).

Каким бы не был алгоритм балансировщика нагрузки серверов, он должен выполнять следующие функции:

1. Уменьшить время отклика на запросы пользователей.
2. Гарантировать равномерное распределение сетевых ресурсов
3. Не допускать простаивание одного или нескольких серверов при высокой нагрузке на другие.
4. Не терять уровень работоспособности при увеличении нагрузки .
5. Простым в использовании, пользователь должен четко понимать, как и когда будут обработаны запросы и будет происходить распределение нагрузки.

Как работает балансировщик нагрузки

Алгоритмы работы балансировщиков:

Чтобы выбрать наиболее подходящий, рассмотрим самые популярные алгоритмы настройки балансировки:

1. Так называемый «Round Robin» (круговой): клиенты перебираются по круговому циклу и очередность запросов соответствует очередности сервера, так до перехода к последнему, затем все начинается заново.

Для воплощения такого метода подходит почти любой DNS сервер .

Здесь может быть использован любой протокол, при котором обращение к серверу идет по имени. Абсолютно все отмечают основной плюс – дешевизна данного метода . Алгоритм не требует связи между серверами и не учитывает загруженности того или иного сервера в настоящий момент времени.

2. Round Robin Weight: балансировщик выбирает «по весу» куда направить запрос в зависимости от загруженности серверов и на текущий момент времени выбирает тот, который меньше всего загружен.

Это более гибкая версия первого метода.

3. Sticky (липкий) хэш: клиент соотносится с конкретным сервером на основании IP и все запросы данного клиента будут направляться на один и тот же сервер.

При данном методе гарантируется, что запросы клиента, который «закреплен» за конкретным сервером, будут передаваться именно на этот сервер . Если по какой-то причине сервер окажется недоступен, то тогда уже запрос будет перенаправлен на другой сервер.

4. Проксирование: иногда балансировку нагрузки еще называют проксированием. По своей сути, такое сравнение является уместным, так как прокси – сервер считается «посредником» между ПК и веб-ресурсом, который перенаправляет информацию по запросу пользователя от своего имени, для этого прокси перехватывает и проверяет сообщения.

При таком способе работы серверу приходится работать на двух уровнях: 7 (HTTP) и 4 (TCP) «Умные» прокси – серверы, которые работают на l7 – «уровне приложений» поверх l4, позволяют использовать несколько способов маршрутизации данных, что можно рассматривать как балансировку нагрузки.

Метод проксирования позволяет кэшировать ответы на сервере , менять запросы и ответы и распределять разные запросы разным серверам, что позволяет уменьшить время отклика. Однако этот метод требует огромного потребления ресурсов и использования протоколов высокого уровня, чтобы справляться с поставленными задачи.

Типы топологий балансировки:

В зависимости от местоположения балансировщика в схеме клиент – балансировщик – бэкенд, может меняться функциональность его работы.

1. Схема балансировки посередине между пользователем и бэкендом. Самая простая и популярная топология, которая может включать облачные и чистые программы (самые популярные – HAProxy, балансировщик нагрузки nginx, NLB и т.д.) или работать через аппаратный балансировщик (например, LM Server Balancer, Cisco, Kemp LoadMaster, Big Ip от F5).
2. Топология балансировщика с краю. При такой схеме балансировщик доступен через интернет – подключение, в остальном краевая топология схожа со схемой балансировки посередине.
3. Топология встроенной библиотеки. Балансировка через встроенную библиотеку подразумевает встраивание балансировщика нагрузки напрямую через библиотеку, для того чтобы избежать проблемы отказа, которые присущи топологии посередине.

Для устранения необходимости регулярного обновления библиотеки и ее реализации на различных языках была реализована идея прокси-сервера sidecar . Она позволяет получать плюсы библиотечного подхода без программирования.

Глобальная балансировка:

Многие компании стараются увеличивать масштабируемость и производственные мощности серверов в одном месте. Такой подход ограничивает возможности высокой доступности из-за централизации точки отказа в едином месте. Запросы пользователей, географически удаленных от локации сервера, будут иметь большие задержки при обработке. Для решения подобных проблем существует глобальная балансировка нагрузки.

Глобальная балансировка нагрузки (GSLB) – группа центров обработки данных, которая находится в разных географических точках , перенаправляющая запросы к ближайшему, наименее загруженному серверу в зависимости от расположения, что позволяет делать обработку высоко доступной и непрерывной.

Заключение:

Балансировка нагрузки является неотъемлемой частью современных систем распределения, однако под различные задачи подходят разные балансировщики, вследствии чего нет необходимости всегда стараться использовать самые мощные.

Балансировка нагрузки в распределенных системах

Балансировка нагрузки ( Load Balancing ) применяется для оптимизации выполнения распределённых (параллельных) вычислений с помощью распределённой (параллельной) ВС . Балансировка нагрузки предполагает равномерную нагрузку вычислительных узлов (процессора многопроцессорной ЭВМ или компьютера в сети). При появлении новых заданий программное обеспечение , реализующее балансировку, должно принять решение о том, где (на каком вычислительном узле) следует выполнять вычисления, связанные с этим новым заданием. Кроме того, балансировка предполагает перенос ( migration – миграция) части вычислений с наиболее загруженных вычислительных узлов на менее загруженные узлы.

Следует различать декомпозицию задач и проблему отображения задач на вычислительную среду. Декомпозиция задачи является этапом процесса создания параллельной программы. Декомпозиция предназначена для разделения приложения на модули (задачи). Задачи исполняются на отдельных процессорах. В результате декомпозиции распределенного приложения появляется набор задач, которые параллельно решают задачу. Эти задачи могут быть независимыми или связанными друг с другом посредством обмена данными. Отображение (или «распределение задач») является отдельным этапом, позволяющим распределить задания, полученные на этапе декомпозиции, между процессорами.

Итак, будем считать, что распределенное приложение представляет собой совокупность логических процессов, которые взаимодействуют друг с другом, посылая друг другу сообщения. Логические процессы распределяются по разным вычислительным узлам и могут функционировать параллельно. При распределении логических процессоров по вычислительным узлам их стараются распределять так, чтобы загрузка вычислительных узлов была равномерной.

Однако при выполнении распределенного приложения возникает конфликт между сбалансированным распределением объектов по процессорам и низкой скоростью обменов сообщениями между процессорами. Если логические процессы распределены между процессорами таким образом, что издержки на коммуникацию между ними сведены к нулю, то некоторые процессоры (компьютеры) могут простаивать, в то время как остальные будут перегружены. В другом случае, «хорошо сбалансированная» система потребует больших затрат на коммуникацию. Следовательно, стратегия балансировки должна быть таковой, чтобы вычислительные узлы были загружены достаточно равномерно, но и коммуникационная среда не должна быть перегружена.

Реализация распределённой системы имитации требует разработки алгоритмов синхронизации объектов (или процессов), функционирующих на различных узлах ВС . Алгоритмы синхронизации мы уже обсуждали ранее. Эффективность реализации этих алгоритмов, в свою очередь , зависит от равномерности распределения (балансировки) вычислительной нагрузки по узлам ВС во время функционирования распределённой программной системы, каковой является, в частности, распределённая система имитации.

Балансировка вычислительной нагрузки

Причины возникновения несбалансированной нагрузки

Проблема балансировки вычислительной нагрузки распределённого приложения возникает по той причине, что:

• структура распределенного приложения неоднородна, различные логические процессы требуют различных вычислительных мощностей;
• структура вычислительного комплекса (например, кластера), также неоднородна, т.е. разные вычислительные узлы обладают разной производительностью;
• структура межузлового взаимодействия неоднородна, т.к. линии связи, соединяющие узлы, могут иметь различные характеристики пропускной способности.

Статическая и динамическая балансировки

Следует различать статическую и динамическую балансировки.

Статическая балансировка выполняется до начала выполнения распределенного приложения. Очень часто при распределении логических процессов по процессорам используется опыт предыдущих выполнений, применяются генетические алгоритмы . Однако предварительное размещение логических процессов по процессорам (компьютерам) не даёт эффекта.

Это объясняется тем, что:

• Может измениться вычислительная среда, в которой происходит выполнение приложения, какой либо вычислительный узел может выйти из строя.
• Вычислительный узел, на котором выполняется распределенное приложение, занят ещё и другими вычислениями, доля которых со временем может возрасти.

Так или иначе, выигрыш от распределения логических процессов по компьютерам с целью выполнения параллельной обработки становится неэффективным.

Динамическая балансировка предусматривает перераспределение вычислительной нагрузки на узлы во время выполнения приложения. Программное обеспечение, реализующее динамическую балансировку, определяет:

• загрузку вычислительных узлов;
• пропускную способность линий связи;
• частоту обменов сообщениями между логическими процессами распределенного приложения и др.

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

Постановка задачи динамической балансировки

Цель балансировки загрузки может быть сформулирована следующим образом:

Исходя из набора задач, включающих вычисления и передачу данных, и сети компьютеров определенной топологии, найти такое распределение задач по компьютерам, которое обеспечивает примерно равную вычислительную загрузку компьютеров и минимальные затраты на передачу данных между ними.

Представим распределенное приложение в виде графа. Пусть G_p = , V –множество вершин (задачи распределенного приложения), E – множество дуг графа – связи между задачами распределенного приложения. Пусть TM – множество моделей распределенных приложений,

Типы балансировщиков нагрузки

Теперь, когда мы знаем, что такое балансировщики нагрузки и зачем они нам нужны, давайте обсудим типы балансировщиков нагрузки. Существует несколько конкретных типов балансировщиков нагрузки, которые вам, возможно, придется учитывать в своей сети. Балансировщики нагрузки можно условно разделить на следующие:

1. Балансировка сетевой нагрузки

Функция балансировки сетевой нагрузки (NLB) распределяет трафик между несколькими серверами с использованием сетевого протокола TCP / IP. Объединяя два или более компьютеров, на которых выполняются приложения, в один виртуальный кластер, NLB обеспечивает надежность и производительность для веб-серверов и других критически важных серверов.

Балансировка сетевой нагрузки считается самым быстрым типом балансировки нагрузки. Однако, когда дело доходит до балансировки распределения трафика между серверами, он, как правило, терпит неудачу.

2. Балансировка нагрузки HTTP (S)

Одна из самых старых форм балансировки нагрузки — это балансировка нагрузки HTTP (S). В отличие от балансировщика сетевой нагрузки, этот балансировщик работает на уровне приложения, поскольку он полагается на сетевой уровень 7. Балансировку нагрузки HTTP часто называют наиболее гибким балансировщиком нагрузки, поскольку она позволяет формировать решения о распределении на основе любой информации, поступающей с HTTP. адрес.

3. Внутренняя балансировка нагрузки

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

Алгоритмы балансировки нагрузки

>> Случайный

Случайное назначение — это, безусловно, наименее организованный алгоритм балансировки нагрузки, и он делает именно то, что говорит. Он случайным образом назначает рабочую нагрузку каждому серверу. Базовый алгоритм — это генератор случайных чисел. Случайное назначение звучит сложнее, чем есть на самом деле. Обычно он хорошо работает в кластерах, где узлы имеют схожую конфигурацию ЦП, ОЗУ и т. Д.

›› Круговая система (и круговая система с взвешиванием)

Циклическая балансировка нагрузки — один из самых простых и наиболее часто используемых алгоритмов балансировки нагрузки. Запросы рассылаются на серверы приложений по очереди. Weighted Round Robin — это слегка импровизированный алгоритм, в котором системные администраторы присваивают вес каждому серверу в зависимости от его структуры и эффективности, чтобы отразить его способность обрабатывать трафик.

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

›› Наименьшее количество подключений (и взвешенное минимальное количество подключений)

Наименьшее соединение — это алгоритм динамической балансировки нагрузки, при котором клиентские запросы направляются на сервер приложений с наименьшим количеством активных соединений на момент получения клиентского запроса. Этот алгоритм наиболее полезен при наличии постоянных соединений. Подобно алгоритму Weighted Round Robin, алгоритм Weighted Least Connections добавляет вес на основе соответствующих мощностей каждого сервера. Теперь алгоритм распределяет нагрузку на основе веса / емкости каждого сервера и текущего количества активных клиентов на каждом сервере.

›› Хэш исходного IP-адреса

Алгоритм хеширования исходного IP-адреса генерирует хеш-ключ, используя исходный и целевой IP-адреса клиента и сервера. Этот ключ определяет, какой сервер получит запрос. Поскольку ключ может быть повторно сгенерирован после разрыва сеанса, он полезен для клиентов, которые должны подключиться к сеансу, который все еще активен после отключения. IP-хеширование может быть невероятно полезным, но есть загвоздка. Когда с одних и тех же IP-адресов идет тонна трафика, отдельные серверы могут быть перегружены.

›› Хеширование URL-адресов

URL Hash — это алгоритм балансировки нагрузки для равномерного распределения записей между несколькими сайтами и отправки всех операций чтения на сайт, владеющий объектом.

* Другими алгоритмами балансировки нагрузки являются наименьшее время отклика и наименьшая пропускная способность.

Как и многие другие масштабные вещи, балансировка нагрузки кажется простой на первый взгляд, но может стать сложной и сложной в зависимости от варианта использования. Пришло время поработать руками, внедрив балансировщик нагрузки с использованием обычных балансировщиков нагрузки, таких как HAProxy и Nginx.

Ранняя балансировка нагрузки и частая балансировка нагрузки ⚖️

Балансировка нагрузки: как перераспределяют нагрузку между серверами

Представим, что вы сделали некое приложение, им пользуется много людей, и один сервер не справляется с той нагрузкой, которая на него приходится. Тогда вы распределяете приложение между несколькими серверами — и теперь нужно распределить между ними нагрузку, чтобы запросы поступали на все серверы, а не падали на один, выводя его строя. Разберемся, как это происходит.

Технологии выравнивания нагрузки и зачем они нужны

Для распределения нагрузки используют технологии балансировки нагрузки (server load balancing), с их помощью разделяют запросы по разным серверам. В общем и целом концепция балансировки выглядит просто — запросы от пользователей поступают в некое централизующее приложение, которое направляет их дальше на обработку в другие приложения.

Также балансировка повышает скорость ответа — если запросов слишком много, их можно раздать на большее количество других серверов. В среднем поток нагрузки на каждую машину станет меньше, мы как бы «размазываем» нагрузку более тонким слоем по всей инфраструктуре. Это значит, что каждый сервер может отвечать на запросы чуть быстрее.

Как же реализуют балансировку нагрузки на практике?

Балансировка нагрузки на домене

Самый простой способ — балансировать запросы клиентов через ваше доменное имя. Допустим, ваш бэкенд крутится на адресе домена api.kotyatki.com. Ему соответствует публичный IP-адрес ХХХ.ХXХ.ХXX.ХXX, по которому находится сервер бэкенда.

Можно попробовать на уровне DNS-сервера добавить к домену api.kotyatki.com второй адрес — YYY.YYY.YYY.YYY. Это приведет к тому, что часть запросов на домен api.kotyatki.com попадет на наш первый адрес XXX.XXX.XXX.XXX, а часть — на второй YYY.YYY.YYY.YYY.

Какая часть запросов попадет на первый адрес и какая на второй? Мы не знаем. Никто не знает. Это зависит от различных переменных, так что наверняка сказать невозможно, и, по сути, такая балансировка будет неуправляемой.

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

Ставим балансировщик

Вариант номер два — на ваш домен api.kotyatki.com мы ставим специальный сервер, который умеет принимать запросы от клиентов, распределять и передавать их дальше. Это простая и быстрая операция, она дает возможность отвечать клиентам почти мгновенно.

Такой сервер принимает клиентские запросы и передает их серверам, на которых работает ваш бэкенд. Эти рабочие серверы сами на запросы клиентов не отвечают. Так мы получаем десятки серверов, работающих по одному адресу и прячущихся за сервером-посредником.

Этот посредник и называется балансировщиком. В качестве примера можно привести HAProxy, Envoy, nginx. Load balancing с помощью nginx считается одним из самых популярных решений, так как этот веб-сервер очень функциональный и гибкий в настройке.

Упрощенная схема работы балансировщика

Как балансировщик решает, кому отдать запросы от клиентов? Тут могут быть разные варианты. Можно отдавать задачи по кругу — каждому серверу бэкенда по очереди. У вас тысяча машин и один балансировщик, к вам приходит тысяча запросов — каждая машина получит по одному. Это самый простой алгоритм балансировки, он зовется Round Robin.

Можно измерять среднее время отклика каждой машины за балансировщиком и заносить это время в специальную таблицу. А когда прилетает очередной запрос — отдавать его серверу с наименьшим временем ответа. Чем быстрее сервер отвечает — тем меньше на нем нагрузки.

Комбинируем два вида балансировки

Этот способ балансировки нужен компаниям с очень большим числом клиентов. Мы, по сути, комбинируем первые два способа. На ваш домен api.kotyatki.com ставят несколько балансировщиков, например: 172.30.1.1, 172.30.1.2, 172.30.1.3 и 172.30.1.4. И за каждым балансировщиком-посредником стоят по две тысячи серверов бэкенда.

Так мы получаем невероятно мощную способность вашей инфраструктуры отвечать на запросы.