Балансировка нагрузки между серверами: что это, методы и схемы для бизнеса

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

Зачем нужна балансировка

Один сервер - это и потолок по нагрузке, и единая точка отказа. Когда запросов больше, чем он тянет, пользователи получают тормоза и ошибки. А если он падает - сервис недоступен целиком. Балансировка решает обе задачи сразу:

• Масштабирование. Добавляете сервер в группу - общая ёмкость растёт. Это горизонтальное масштабирование: вместо одного большого сервера несколько поменьше.
• Отказоустойчивость. Балансировщик проверяет здоровье серверов и перестаёт слать запросы на упавший. Пользователь сбоя не замечает.
• Гибкость обслуживания. Сервер можно вывести из группы, обновить и вернуть - без остановки сервиса.

L4 и L7: на каком уровне работает балансировщик

Главное деление - по уровню модели OSI, на котором балансировщик принимает решение.

Балансировка L4 (транспортный уровень). Балансировщик смотрит только на IP-адреса и порты, не вникая в содержимое. Он быстрый и нетребовательный: просто перебрасывает соединение на один из серверов. Минус - не знает, что внутри запроса, поэтому не умеет маршрутизировать по URL или типу контента.

Балансировка L7 (прикладной уровень). Балансировщик разбирает сам запрос: видит HTTP-заголовки, URL, cookie. Это даёт гибкость - можно слать запросы к /api на одни серверы, а статику на другие, держать сессию пользователя на одном сервере, завершать на балансировщике шифрование HTTPS. Платой за это идёт чуть большая нагрузка на сам балансировщик.

Методы распределения запросов

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

Отдельно стоит привязка сессии (sticky session): балансировщик запоминает, на каком сервере «живёт» пользователь, и держит его там. Это нужно, когда сессия хранится на самом сервере, а не в общей базе. Правильнее, конечно, выносить сессии в общее хранилище - тогда привязка не нужна и любой сервер обслужит любого клиента.

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

Балансировку делают двумя путями.

Программный балансировщик - это ПО на обычном сервере: nginx, HAProxy. Гибко, дёшево (open-source), легко масштабируется. Для большинства задач бизнеса этого хватает с запасом.

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

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

Как балансировщик не стать точкой отказа

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

Классическая схема - два балансировщика в режиме «активный - резервный» с общим виртуальным IP-адресом. Запросы идут на активный; если он падает, виртуальный адрес мгновенно переезжает на резервный, и сервис продолжает работать. Так закрывается единая точка отказа на входе.

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

Балансировка и кластер - это одно и то же?

Нет, хотя их часто путают. Балансировка распределяет нагрузку. Кластер - более широкое понятие: серверы объединены для совместной работы и могут как балансировать нагрузку, так и подхватывать задачи друг друга при отказе. Балансировка нагрузки - один из механизмов, на которых строится отказоустойчивый кластер. Подробнее о кластерах - в материале про высоконагруженные системы и highload.

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

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

Коротко

Балансировка нагрузки распределяет запросы между серверами - ради масштабирования и отказоустойчивости. L4 работает по адресам и портам (быстро), L7 - по содержимому запроса (гибко, нужно для веба). Методы - от round-robin до least connections, плюс привязка сессии, где это необходимо. Для бизнеса обычно хватает nginx или HAProxy, а сам балансировщик резервируют парой «активный - резервный», чтобы не сделать из него единую точку отказа.

Частые вопросы

Чем балансировка L4 отличается от L7?

L4 распределяет соединения по IP-адресам и портам, не заглядывая внутрь запроса - это быстро и просто. L7 разбирает сам запрос (URL, заголовки, cookie) и маршрутизирует по содержимому - это гибче и нужно для веб-приложений, но чуть нагружает балансировщик.

Какой балансировщик выбрать для бизнеса?

Для большинства задач - программный: nginx или HAProxy на обычном сервере. Они бесплатны, гибки и закрывают потребности малого и среднего бизнеса. Аппаратные устройства нужны только в очень нагруженных инфраструктурах.

Балансировка нагрузки - это то же, что кластер?

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

Что такое привязка сессии (sticky session)?

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