Network load balancingnetwork load balancing

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

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

Общие принципы

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

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

Round Robin

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

Weighted Round Robin

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

Это не идеальный подход, но он значительно лучше обычного Round Robin.

Least Connections

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

Sticky Sessions

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

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

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

Допустим, один из серверов перегружен и он отдает неправильные ответы. То есть он жив, отвечает, но ответы нам не подходят. Балансировщик будет считать, что все в порядке, запросы на проблемный сервер будут продолжать идти. Nginx исключит его из списка бэкендов только тогда, когда он полностью перестанет отвечать. Но это лишь малая часть проблем, которые могут приключиться. По моему опыту, чаще всего сервера не отваливаются полностью, а начинают тупить или отдавать, к примеру 502 ошибку. В бесплатной версии nginx будет считать, что все в порядке.

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

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

• proxy_connect_timeout — задаёт таймаут для установления соединения с проксированным сервером. При отсутствии ответа за указанное время сервер будет считаться неработающим. Дефолтное значение 60 секунд. Это очень много, если у вас большие нагрузки. За минуту скопится огромное количество висящих соединений, которые мог бы обработать другой бэкенд.
• proxy_read_timeout — задаёт таймаут при чтении ответа проксированного сервера. Дефолт тоже 60 секунд. Чаще всего имеет смысл уменьшить значение.

Load balancing in the cloud

Load balancing can either refer to the process of balancing cloud-based workloads or load balancers that are themselves based in the cloud. In a cloud environment, cloud balancing functions much the same as in other environments, except that it has to do with traffic related to a company’s cloud-based workloads and their distribution across multiple resources, such as server groups and networks.

Balancing cloud workloads is just as important as balancing loads in any other context. The objective ultimately is high availability and performance. The better the workloads perform as a result of even traffic distribution, the less likely the environment is to suffer an outage.

Cloud-based load balancers are usually offered in a pay-as-you-go, as-a-service model that supports high levels of elasticity and flexibility. They offer a number of functions and benefits, such as health checks and control over who can access which resources. This depends on the vendor and the environment in which you use them. Cloud load balancers may use one or more algorithms—supporting methods such as round robin, weighted round robin, and least connections—to optimize traffic distribution and resource performance.

Why do I need a load balancer?

There are many reasons why your business may need a load balancer, including:

For high availability

If your business depends on web applications for sales or customer services, a load balancer will help to ensure that these critical apps are up and running 99.999% of the time. Downtime will be prevented, avoiding lost revenues and poor customer satisfaction.

For consistent performance

By directing traffic to the optimal servers, load balancers can provide consistent and fast app performance for thousands of concurrent users. Response times will improve, enabling employees to work more productively and customers to have a more enjoyable online experience.

For business growth

With a load balancer, organizations can dynamically add more servers to respond to growing user numbers or anticipated peaks in demand – and they can do this quickly and easily, without interrupting their services or having to reconfigure the other servers in the cluster.

For IT flexibility

In a load balanced network environment, IT technicians can disconnect, patch, upgrade and reconnect servers without any disruption for users. It’s more cost effective, as there is no need to pay overtime for teams to undertake routine maintenance at night or at weekends.

Solution Features & Benefits

Depending on your organizational needs — such as network workload and strain on your IT infrastructure – your  solution should account for a wide range of vital processes. From protecting against threats to increasing response time, additional functions of an effective suite include:

• Traffic Management: An agile solution handles both inbound and outbound requests. Whether connecting to the Internet or your organization’s intranet, it’s vital that the workload is distributed between servers that are prepared to balance user traffic.
• Security: When facing distributed denial of service (DDOS) attacks, unwanted visitors, or other elements that compromise networks – balancing load appliances can be invaluable. Gain an industry advantage with firewalls, VPN solutions, and other  features.
• Connectivity: Sprawled IT architectures and data centers in multiple locations make fragmented networks more common than ever. This can lead to a variety of problems, including limited communication between your server farms. Global solutions should account for all IP traffic so user requests are sent to the proper location.

Использования в телекоммуникационных сетях

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

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

Кратчайший Путь Преодоления

Стандарт IEEE утвердил стандарт IEEE 802.1 р-р стандартный мая 2012 года также известно и задокументировано в большинстве книг в качестве Кратчайшего пути преодоления (КПП). КПП позволяет всем ссылкам, чтобы быть активными через несколько путей равной значимости, обеспечивает более быструю сходимость сокращая время простоя и упрощает использование балансировки нагрузки в сети ячеистой топологии (частично и/или полностью подключеной), позволяя трафику распределять нагрузку для всех путей сети. КПП призвана практически исключить влияние человеческого фактора в процессе настройки и сохраняет природу «plug-and-play» подключи-и-играй, что создаёт Ethernet в качестве де-факто протокола во втором слое.

Маршрутизация

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

Другой способ использования балансировки нагрузки в сети с мониторингом деятельности. Балансировщики нагрузки могут быть использованы для разбиения огромных потоков данных на несколько суб-потоков и использовать несколько сетевых анализаторов, где каждый читает часть исходных данных. Это очень полезно для мониторинга быстрых сетей, таких как порта 10gbe или STM64, где комплекс обработки данных может быть невозможен на скорости проводного соединеия.

Methods

Each load balancing method relies on a set of criteria to determine which of the servers in a server farm gets the next request. There are five common load balancing methods:

• Round Robin: This is the default method, and it functions just as the name implies. The load balancer directs requests in a rotating fashion, with the first server in the group fielding a request and then moving to the bottom, where it awaits its turn to be called upon again. This technique ensures each server handles about the same number of connections.
• Weighted Round Robin: With this method, each server is assigned a weight (or preference), usually commensurate with its capacity. The higher the weight, the more requests a server receives. For instance, a server assigned a weight value of two receives double the requests of a server assigned a value of one.
• Sticky Session: Also known as session persistence, this method links specific clients and servers for the duration of a session. The load balancer identifies a user attribute either through a cookie or by tracking the user’s IP address to make the link. Once the link is established, all requests from the user are sent to the same server until the session is over. This improves the user experience while also optimizing network resources.
• Least Connections: This method assumes all requests generate an equal amount of server load. As such, the server handling the lowest number of requests receives the next request that comes in.
• IP Hash: This algorithm creates a unique hash key based on both the source and destination IP address of the client and the server. The key is used to route the request and enables a dropped connection to be reestablished with the same server.

How does the load balancer choose the backend server?

Load balancers choose which server to forward a request to based on a combination of two factors. They will first ensure that any server they can choose is actually responding appropriately to requests and then use a pre-configured rule to select from among that healthy pool.

Health Checks

Load balancers should only forward traffic to “healthy” backend servers. To monitor the health of a backend server, health checks regularly attempt to connect to backend servers using the protocol and port defined by the forwarding rules to ensure that servers are listening. If a server fails a health check, and therefore is unable to serve requests, it is automatically removed from the pool, and traffic will not be forwarded to it until it responds to the health checks again.

Load Balancing Algorithms

The load balancing algorithm that is used determines which of the healthy servers on the backend will be selected. A few of the commonly used algorithms are:

Round Robin — Round Robin means servers will be selected sequentially. The load balancer will select the first server on its list for the first request, then move down the list in order, starting over at the top when it reaches the end.

Least Connections — Least Connections means the load balancer will select the server with the least connections and is recommended when traffic results in longer sessions.

Source — With the Source algorithm, the load balancer will select which server to use based on a hash of the source IP of the request, such as the visitor’s IP address. This method ensures that a particular user will consistently connect to the same server.

The algorithms available to administrators vary depending on the specific load balancing technology in use.

How do load balancers handle state?

Some applications require that a user continues to connect to the same backend server. A Source algorithm creates an affinity based on client IP information. Another way to achieve this at the web application level is through sticky sessions, where the load balancer sets a cookie and all of the requests from that session are directed to the same physical server.

Полный конфиг балансировщика nginx

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

log_format upstream '$remote_addr - $host  "$request" '
    'request_length=$request_length '
    'status=$status bytes_sent=$bytes_sent '
    'body_bytes_sent=$body_bytes_sent '
    'referer=$http_referer '
    'user_agent="$http_user_agent" '
    'upstream_status=$upstream_status '
    'request_time=$request_time '
    'upstream_response_time=$upstream_response_time '
    'upstream_connect_time=$upstream_connect_time '
    'upstream_header_time=$upstream_header_time';


upstream cache-api {
    ip_hash;
    server 10.32.18.7:8080 max_fails=2 fail_timeout=10s;
    server 10.32.18.6:8080 max_fails=2 fail_timeout=10s;
    server 10.32.18.8:8080 max_fails=2 fail_timeout=10s;
}

server {
    listen 443 ssl http2;
    server_name cache-api.sample.com;
    access_log /var/log/nginx/cache-api-access.log upstream;
    error_log /var/log/nginx/cache-api-error.log;

    ssl_certificate /etc/ssl/sample.com.crt;
    ssl_certificate_key /etc/ssl/sample.com.key;

    root /var/www/html;

    location / {
    proxy_pass http://cache-api/;
    proxy_read_timeout 15;
    proxy_connect_timeout 3;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    }
}

За подробностями параметров секции с proxy_pass переходите в отдельную статью на эту тему.

Docker Swarm load balancing

If you are running an environment with multiple Docker containers, you can benefit from applying load balancing to the containers. Docker is an open source development platform that uses containers to package applications for portability across systems running Linux. Docker Swarm is a clustering and scheduling tool employed by developers and administrators to create or manage a cluster of Docker nodes as a single virtual system.

In a Docker Swarm, load balancing balances and routes requests between nodes from any of the containers in a cluster. Docker Swarm has a native load balancer set up to run on every node to handle inbound requests as well as internal requests between nodes.

Depending on topology, you can set up a load balancer outside the Docker Swarm on its own single-node swarm to route requests that originate outside the cluster. The native Docker Swarm balancer is a basic Layer 4 version. As such, it may not provide all the features you require, such as SSL/TLS termination, access control, and authorization, content‑based routing, as well as rewrites and redirects. Adding a balancer outside the cluster helps solve that problem.

For a deeper dive on Docker Swarm and how it compares to Kubernetes, see «Docker Swarm vs. Kubernetes: A Comparison.»

Заключение

Мне не приходилось пробовать в деле никаких других балансировщиков, кроме Nginx. Знаю, что есть haproxy, но попробовать так и не дошли руки. Бесплатная версия nginx очень слабо подходит для полноценной балансировки крупного проекта, либо я просто не понимаю, как его правильно использовать. Реально не хватает тех фич, которые есть в Nginx Plus. До того момента, как не начал использовать балансировщик, не понимал толком, что там такого в платной версии. Теперь прекрасно понимаю 🙂

Готовые примеры балансировки с использованием фич Nginx Plus приведены в этой статье

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

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

Онлайн курс «Сетевой инженер»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные сети, рекомендую познакомиться с онлайн-курсом «Сетевой инженер» в OTUS. Это авторская программа в сочетании с удалённой практикой на реальном оборудовании и академическим сертификатом Cisco! Студенты получают практические навыки работы на оборудовании при помощи удалённой онлайн-лаборатории, работающей на базе партнёра по обучению — РТУ МИРЭА: маршрутизаторы Cisco 1921, Cisco 2801, Cisco 2811; коммутаторы Cisco 2950, Cisco 2960.

Особенности курса:

• Курс содержит две проектные работы.;
• Студенты зачисляются в официальную академию Cisco (OTUS, Cisco Academy, ID 400051208) и получают доступ ко всем частям курса «CCNA Routing and Switching»;
• Студенты могут сдать экзамен и получить вместе с сертификатом OTUS ещё сертификат курса «CCNA Routing and Switching: Scaling Networks»;

Проверьте себя на вступительном тесте и смотрите программу детальнее по .