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

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

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

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

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

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

Балансировщик нагрузки (Load Balancer) — это сервис для распределения запросов между серверами кластера. Балансировщик позволяет сохранить доступность ресурса даже при аномальной нагрузке.

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

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

  • веб-приложение,
  • прокси-сервер,
  • брандмауэр,
  • DNS-сервер,
  • система DPI и др.

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

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

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

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

  • Round Robin,
  • Weighted Round Robin,
  • Least Connections,
  • Sticky Sessions.

Round Robin

Round Robin — это алгоритм распределения нагрузки, который отправляет запросы к серверам в порядке очереди.

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

Преимущества Round Robin:

  • простая логика работы,
  • низкая стоимость реализции.

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

Weighted Round Robin

Алгоритм Weighted Round Robin — это улучшенная версия Round Robin, которая позволяет назначать «вес» серверам. В Weighted Round Robin собраны преимущества стандартного Round Robin и исправлены его недостатки.

Чем хороша технология Weighted Round Robin:

  • простой настройкой,
  • дешевизной,
  • возможностью присвоить каждой машине весовой коэффициент — коэффициент допустимой нагрузки.

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

Least Connections

Least Connections — это алгоритм, который распределяет нагрузку между серверами, ориентируясь на количество подключений. Как это работает на практике?

Предположим, что в вашей сети три сервера. К первому серверу подключен один пользователь, ко второму — два, а к третьему — три. Согласно алгоритму Least Connections, входящий запрос придет к серверу с наименьшим количеством подключений, то есть к первому серверу.

Алгоритм Least Connections хорош тем, что учитывает не только нагрузку на оборудование, но и количество подключений. Благодаря этому трафик в сети распределяется «справедливо» — то есть с учетом большего числа критериев.

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

Sticky Sessions

Sticky Sessions — это алгоритм, который распределяет нагрузку не только по количеству подключений к серверам, но и по IP-адресам элементов сети.

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

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

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

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

Для двух серверов устанавливаем приоритет 1, для третьего - приоритет 2. Трафик будем балансировать по протоколу HTTP на 80 порту.

Теперь отправим 1000 запросов к балансировщику:

for((i=0;i<1000;i=i+1)); do wget -o /dev/null http://77.222.63.167/; done

Результат проверяем на конечных узлах с помощью анализа лога посещений:

Сервер 1

grep Wget /var/log/nginx/access.log |wc -l357

Сервер 2

grep Wget /var/log/nginx/access.log |wc -l285

Сервер 3

grep Wget /var/log/nginx/access.log |wc -l358

Видим, что запросы распределились равномерно согласно установленному весу.

Теперь сэмулируем аварийную ситуацию: выключим один из серверов и повторим отправку 1000 запросов на баласировщик. Смотрим распределение:

Сервер 1

grep Wget /var/log/nginx/access.log |wc -l555

Сервер 2

grep Wget /var/log/nginx/access.log |wc -l445

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

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

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

22
1 комментарий

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

Ответить