Эксперты в подборе IT-оборудования
Балансировка нагрузки - это распределение запросов между несколькими серверами, чтобы ни один не перегружался, а сервис оставался доступным, даже когда один из серверов вышел из строя. Перед группой серверов ставят балансировщик: он принимает входящие запросы и раздаёт их по выбранному правилу. В итоге сайт или приложение держит больше пользователей и не падает целиком из-за одного сбоя. Ниже - какие бывают методы, чем отличаются L4 и L7, и как это собирают на практике.
Один сервер - это и потолок по нагрузке, и единая точка отказа. Когда запросов больше, чем он тянет, пользователи получают тормоза и ошибки. А если он падает - сервис недоступен целиком. Балансировка решает обе задачи сразу:
Главное деление - по уровню модели OSI, на котором балансировщик принимает решение.
Балансировка L4 (транспортный уровень). Балансировщик смотрит только на IP-адреса и порты, не вникая в содержимое. Он быстрый и нетребовательный: просто перебрасывает соединение на один из серверов. Минус - не знает, что внутри запроса, поэтому не умеет маршрутизировать по URL или типу контента.
Балансировка L7 (прикладной уровень). Балансировщик разбирает сам запрос: видит HTTP-заголовки, URL, cookie. Это даёт гибкость - можно слать запросы к /api на одни серверы, а статику на другие, держать сессию пользователя на одном сервере, завершать на балансировщике шифрование HTTPS. Платой за это идёт чуть большая нагрузка на сам балансировщик.
Внутри балансировщика работает алгоритм, по которому он выбирает сервер для очередного запроса.
| Метод | Как работает | Когда подходит |
|---|---|---|
| Round-robin (по кругу) | Запросы раздаются серверам по очереди | Серверы примерно одинаковые, запросы однотипные |
| Weighted (с весами) | Мощным серверам - больше запросов | Серверы разной мощности |
| Least connections | Запрос идёт на сервер с наименьшим числом активных соединений | Запросы разной длительности |
| IP hash | Сервер выбирается по адресу клиента - один клиент всегда на одном сервере | Нужна привязка сессии без cookie |
Отдельно стоит привязка сессии (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 распределяет соединения по IP-адресам и портам, не заглядывая внутрь запроса - это быстро и просто. L7 разбирает сам запрос (URL, заголовки, cookie) и маршрутизирует по содержимому - это гибче и нужно для веб-приложений, но чуть нагружает балансировщик.
Для большинства задач - программный: nginx или HAProxy на обычном сервере. Они бесплатны, гибки и закрывают потребности малого и среднего бизнеса. Аппаратные устройства нужны только в очень нагруженных инфраструктурах.
Нет. Балансировка распределяет запросы, а кластер объединяет серверы для совместной работы и отказоустойчивости. Балансировка - один из механизмов кластера, а не синоним.
Это режим, когда балансировщик держит одного пользователя на одном сервере, чтобы не терялась сессия, хранящаяся локально. Если сессии вынесены в общее хранилище, привязка не нужна.
