что такое round robin

Что такое round robin

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов на просторах рунета Pyatilistnik.org. Продолжаем с вами усовершенствовать свои навыки и знания в сфере системного администрирования. В предыдущей статье мы с вами разобрали основные понятия DNS сервера и его компонентов. Сегодня мы более подробно разберем, одну из его полезнейших вещей, которую очень часто используют, например на RDS фермах, или различных балансировщиках. Речь пойдет про функционал DNS Round Robin, рассмотрим его настройку и его применение.

Теория

Статья описывает одну из технологий балансировки нагрузки, которая может быть реализована средствами DNS. Для перевода имени хоста в IP-адрес клиент DNS направляет серверу DNS рекурсивный запрос (т.е. запрос, на который сервер DNS возвращает клиенту либо ответ с IP адресом, либо ответ с ошибкой).

В подавляющем большинстве случаев в зонах DNS содержится только один IP адрес, соответствующий тому или иному имени хоста. А какой IP адрес будет возвращать клиенту сервер DNS, если зона содержит несколько записей типа A для одного и того же имени? Ответ простой: сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д.

Предположим, у меня есть несколько зеркальных веб-сайтов по имени www.gorbunov.pro, расположенных на разных площадках и имеющих IP адреса 20.0.0.1, 30.0.0.1 и 40.0.0.1.

В ответ на рекурсивный запрос клиента об имени www.gorbunov.pro сервер DNS вернет клиенту весь набор записей из зоны:

www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1

Поскольку адрес 20.0.0.1 идет первым в списке, клиент всегда будет пытаться связаться именно с сайтом по адресу 20.0.0.1. Получается, что сайты 30.0.0.1 и 40.0.0.1 используются только как пассивный резерв. До тех пор, пока «жив» сайт по адресу 20.0.0.1, сайты 30.0.0.1 и 40.0.0.1 не получат от клиента ни одного запроса.

Как сделать, чтобы запросы “доставались” всем хостам? Ответ простой: настроить на сервере DNS функцию Round robin.

При включенной функции Round robin сервер DNS постоянно «перемешивает» ответы клиентам, поэтому на первый запрос клиента DNS об имени www.gorbunov.pro сервер DNS вернет ответ

www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1

На второй запрос от клиента или от другого сервера DNS будет возвращен ответ

www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1

На третий запрос будет ответ
www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1

В результате мы получаем динамическую балансировку запросов клиентов между несколькими хостами.

Практика
____________________________________________________________________________________

Проверка работы DNS Round robin

В Windows Server опция Enable round robin включена по умолчанию. Достаточно в консоли DNS Manager открыть свойства DNS сервера и посмотреть вкладку Advanced.

Что такое DNS Round robin и как он работает-01

Для практической проверки функционала DNS Round robin создаем зону gorbunov.pro и добавляем в нее три записи для хоста www.

Что такое DNS Round robin и как он работает-02

Если вы попробуете теперь “попинговать” хост www.gorbunov.pro, то с удивлением обнаружите, что клиент все время отправляет пакеты на адрес 20.0.0.1 (выделено красным). Понятно, что ответа от хоста нет, но и DNS Round robin не работает!

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping www.gorbunov.pro

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
Анализ кэша DNS на стороне клиента дает следующий результат:
C:\>ipconfig /displaydns

Windows IP Configuration

Теперь становится понятно, почему мы “пингуем” один и тот же хост 20.0.0.1. Сервер DNS возвращает клиенту все записи из зоны с указанием времени кэширования, равным по умолчанию 1 часу (или 3600 секундам). Поэтому до истечения времени кэширования (TTL – Time To Live) клиент больше не направляет к серверу DNS никаких новых запросов.

Сброс кэша командой ipconfig / flushdns и новая команда
ping www.gorbunov.pro приводят, наконец к желаемому результату.C:\>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

C:\>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.

Теперь ясно, что для правильной работы DNS Round robin потребуется изменение параметров кэширования, чтобы клиенты постоянно получали обновленный список с “перемешанными” записями.
Настройка времени кэширования ответов DNS

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

Для настройки индивидуального времени кэширования в консоли DNS Manager требуется сначала включить режим View –> Advanced. Затем последовательно открываем свойства записей (в нашем примере это три записи www) и ставим время кэширования, равное нулю.

Что такое DNS Round robin и как он работает-03

Проверка работы дает в конце концов желаемый результат!

C:\>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 30.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [40.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 40.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Файл зоны на сервере DNS при этом будет выглядеть так:
;
; Database file gorbunov.pro.dns for gorbunov.pro zone.
; Zone version: 7
;

@ IN SOA dc01.contoso.com. hostmaster.contoso.com. (
7 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL

www 0 A 20.0.0.1
0 A 30.0.0.1
0 A 40.0.0.1

Добавления нуля в записи типа A можно сделать и вручную непосредственно в файле зоны.

В настройках сервера DNS по умолчанию включена и опция Enable netmask ordering. Смысл опции заключаются в том, что при наличии нескольких IP адресов для одного и того же имени хоста сервер DNS анализирует из какой сети пришел запрос от клиента. Если IP сеть клиента совпадает с номером сети одного из IP адресов хоста, то такой IP всегда возвращается первым. Проще говоря, если в нашем примере клиент с адресом 30.67.98.123 будет запрашивать имя www.gorbunov.pro, то ему всегда первым в списке будет возвращаться адрес 30.0.0.1. В серверах Windows опция Enable netmask ordering перебивает опцию Enable round robin. Т.е. клиентам DNS первым всегда возвращается адрес ближайшего хоста, даже несмотря на правильно настроенную функцию DNS Round robin.

Технология DNS Round robin часто применяется для динамической балансировки нагрузки между зеркальными хостами. Она значительно проще в реализации, чем вариант настройки для тех же целей кластера NLB. При настройке DNS Round robin на серверах Windows не забывайте, что настройки по умолчанию для сервера DNS не позволяют в полной мере реализовать балансировку запросов и требуется ручная конфигурация сервера.

Источник

21) Круглый алгоритм планирования Робина

Что такое циклическое планирование?

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

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

Из этого руководства по операционной системе вы узнаете:

Характеристики кругового планирования

Вот важные характеристики кругового планирования:

Пример циклического планирования

Рассмотрим следующие три процесса

Шаг 1) Выполнение начинается с процесса P1, который имеет время пакета 4. Здесь каждый процесс выполняется в течение 2 секунд. P2 и P3 все еще находятся в очереди ожидания.

Шаг 2 ) В момент времени = 2 P1 добавляется в конец очереди, и P2 начинает выполнение

Шаг 3) В момент времени = 4 P2 выгружается и добавляется в конец очереди. P3 начинает выполнение.

Шаг 4) В момент времени = 6 P3 выгружается и добавляется в конец очереди. P1 начинает выполнение.

Шаг 5) В момент времени = 8, P1 имеет время пакета 4. Он завершил выполнение. P2 начинает выполнение

Шаг 6) У P2 есть время пакета 3. Это уже выполнено в течение 2 интервалов. В момент времени = 9 P2 завершает выполнение. Затем P3 начинает выполнение до его завершения.

Шаг 7) Давайте посчитаем среднее время ожидания для приведенного выше примера.

Преимущество кругового планирования

Вот преимущества / преимущества метода планирования в циклическом порядке:

Недостатки кругового планирования

Вот недостатки / недостатки использования циклического планирования:

Наихудший случай задержки

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

Источник

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

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

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

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

Как работает

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

Какие проблемы решает

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

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

Три уровня балансировки

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

Сетевой

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

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

На сетевом уровне можно настроить распределение нагрузки на сервер такими методами:

Транспортный

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

В чем принципиальная разница между сетевыми и транспортными методами? Первые просто перенаправляют запросы. Затем выбранный сервер напрямую обменивается данными с клиентом. Транспортные методы работают как прокси — они сами обмениваются данными с сервером, а не связывают клиента и сервер напрямую.

Прикладной

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

Для прикладного и транспортного методов подходят как физические, так и виртуальные серверы. Оптимальный вариант — зарезервировать виртуальный VDS сервер под эти нужды.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Источник