Большой гайд по настройке двух видов балансировщиков нагрузки / Хабр

Привет, Хабр! Меня зовут Андрей Гордиенко, я ведущий специалист поддержки облачных услуг в Selectel.

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

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

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

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

Предыдущие материалы по настройке сети
Как настраивать сети: определения, типовые схемы, особенности
Выделенный и облачный серверы: создание, настройка, сетевая связность
Как настраивать сети: облачные роутеры и публичные IP
Как настраивать сети: готовые решения Selectel для максимальной отказоустойчивости

В инфраструктуре Selectel для этого предусмотрено два инструмента:

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

Содержание

Облачный балансировщик нагрузки

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

Функциональность балансировщика не ограничивается одной лишь сортировкой запросов. Он берет на себя и другие задачи — например, управляет SSL-сертификатами или настраивает автоматический редирект с незащищенного HTTP на безопасный HTTPS.

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

Важный нюанс
IP-адрес облачного балансировщика по умолчанию защищен от DDoS-атак на уровнях L3–L4, что является базовой защитой сетевого уровня. Не следует путать ее с защитой веб-сайтов и доменов!
Оборона на уровне приложений L7 — отдельная и, как правило, платная услуга. В Selectel для этих целей есть решения от партнеров — Curator и DDoS-Guard. Подробности можно найти в документации или на нашей страничке защиты от DDoS‑атак.

Схематично баланс��ровщик выглядит следующим образом.

Переходим к практике.

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

Заходим в панель управления, выбираем Продукты → Облачные серверы.

Для их быстрой настройки воспользуемся User Data — специальным инструментом в нашей панели управления. Он позволяет задать сценарий конфигурации еще на этапе создания сервера. Технически за этот процесс отвечает утилита Cloud-init, которая умеет работать с обычным текстом, YAML-файлами и Bash-скриптами.

Механика проста: нужный код вставляется в поле ввода, как в примере на скриншоте ниже — система при запуске автоматически выполнит инструкции и установит необходимое ПО. Так мы заодно избавляемся от рутинной работы в консоли.

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

apt update
apt install -y apache2
systemctl start apache2
systemctl enable apache2
echo "Hello World from $(hostname) - $(hostname -I)" > /var/www/html/index.html

Для эксперимента нам не понадобятся мощные машины, поэтому ограничимся минимальными ресурсами:

ОС — Ubuntu 20,
CPU — 1 ядро,
RAM — 2 ГБ,
SSD — 10 ГБ.

Работать будем в закрытом контуре, поэтому присвоим серверам локальные IP‑адреса: 192.168.1.2 и 192.168.1.3.

В нашем распоряжении — два идентичных сервера:

Список созданных серверов. — *Список созданных серверов*.

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

Базовая настройка балансировщика

Создадим балансировщик на 80‑м порту. В скрипте User Data мы намеренно не настраивали поддержку HTTPS, и в этом нет необходимости. Поскольку наши серверы изолированы во внутренней сети, задачи шифрования и безопасности берет на себя сам балансировщик — он будет принимать внешний защищенный трафик и передавать его серверам в «чистом» виде.

Напоминание
Порт 80 используется для протокола HTTP, а 443 — для HTTPS.

При создании важно определиться с конфигурацией (флейвором). На выбор предлагается три варианта.

Базовый. Экономное решение с минимальными вычислительными ресурсами и без резервирования.
Базовый с резервированием. Обладает теми же ресурсами, что и обычный базовый, но включает реплику. Если основной узел откажет, система мгновенно переключит трафик на резервный, обеспечив бесперебойную работу сервиса.
Продвинутый с резервированием. Мощная версия балансировщика, рассчитанная на высокие нагрузки и также оснащенная репликой для надежности.

Точные технические характеристики для каждого типа можно найти в нашей документации.

Задаем имя и переходим к самому ответственному этапу — настройке сети.

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

Это значит, что он не сможет распределять нагрузку между регионами — например, связать серверы в Санкт-Петербурге и Москве. Также он не умеет использовать сети глобального роутера. Ограничение действует даже внутри одного города: если серверы разбросаны по разным дата-центрам в разных зонах доступности, то настроить связь через один балансировщик не получится. Вся архитектура должна находиться в рамках одной зоны, хотя пулы могут быть разными — например, ru‑1a, ru‑1b, ru‑1c.

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

Есть два правила размещения:

строгое — обязательно на разных хостах,
мягкое — желательно на разных хостах.

Возвращаемся к нашему стенду. Для наглядности компоненты сейчас разнесены по разным подсетям:

серверы используют сеть 192.168.1.0/24 с именем Net,
балансировщик находится в сети 10.222.0.0/24 с именем Kizzy-network.

Зачем такая сложность с адресацией? Схема ниже объясняет логику взаимодействия балансировщика с серверами:

Настройка внешнего доступа

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

Через облачный роутер. Цепочка выглядит так: приватная сеть → облачный роутер → публичный IP. Схема может показаться громоздкой, но эта сложность практически не сказывается на задержках (latency).
Через публичную подсеть с размерностью минимум /29. Однако здесь кроется важный нюанс: всегда должен быть запас IP-адресов.

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

Если ваша подсеть, например /28, забита под завязку, то новому экземпляру просто не хватит места для старта, и восстановление не сработает.

Совет
Для надежной работы одного балансировщика с резервированием всегда оставляйте буфер в 3−4 свободных IP-адреса.

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

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

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

Настройка целевых групп

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

Важный нюанс архитектуры: один и тот же сервер может состоять в нескольких группах одновременно. Главное условие — разнесение по портам. Например, одна группа может стучаться к серверу по порту 80, другая — по 8080, третья — по 443.

На уровне целевой группы мы определяем три ключевых параметра:

протоколы и порты — правила приема трафика от балансировщика;
алгоритм распределения — логика, по которой запросы делятся между серверами;
проверки доступности — механизм мониторинга, который исключает из ротации «упавшие» серверы.

Для нашего текущего стенда будем использовать протокол HTTP.

Есть важный нюанс, касающийся протоколов HTTP и TCP.

На первый взгляд, выбор между профилем HTTP и TCP (порт 80) может показаться неочевидным, ведь физически трафик идет через один и тот же 80‑й порт. Однако для балансировщика это принципиально разные режимы работы.

Здесь вступает в силу модель OSI:

TCP — протокол 4‑го транспортного уровня,
HTTP — протокол 7‑го прикладного уровня.

Если выбрать режим TCP, балансировщик работает просто как «труба», пересылая пакеты данных. В таком случае будут недоступны функции более высокого уровня. Не получится настроить редиректы, подключить SSL-сертификат с терминацией через HTTPS или включить L7‑защиту от DDoS — например, для конкретного домена.

Совет
Изучите самостоятельно подробности о роли TCP для установки связи между двумя устройствами — например, компьютером и сайтом.

Когда и что выбирать:

HTTP — для веб-сайтов, API и любых сервисов, где нужно работать с заголовками запросов и доменными именами;
TCP — для «сырых» соединений по IP. Это часто используется для игровых серверов, баз данных или специфических приложений, где не нужен анализ содержимого пакетов.

С точки зрения самой балансировки (алгоритмов распределения нагрузки) разницы нет — механика идентична. Ограничения касаются только дополнительных «фич» вроде SSL и редиректов.

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

При добавлении серверов в целевую группу обратите внимание на две важные настройки.

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

Резервный — опция позволяет реализовать схему отказоустойчивости Active-Passive. Один сервер назначается основным, а второй — запасным. В штатном режиме резервный узел будет простаивать или выполнять фоновые задачи. Трафик на него пойдет только в аварийной ситуации — если основной сервер выйдет из строя.

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

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

Бесплатная миграция в Selectel

Начислим до 1 000 000 бонусов на два месяца. А наши инженеры подготовят план и поддержат на всех этапах миграции.

Подробнее →

Небольшой пример

Разберем вышесказанное на примере конкретного кейса.

Представим ситуацию: мы настраиваем балансировку для веб-сервера на стандартном порту 80. Все идет по плану. Но ради эксперимента добавим вторую целевую группу на порту 1234 (TCP), забыв предварительно открыть его на самом сервере.

Что произойдет? Балансировщик попытается достучаться до порта 1234, не получит ответа и пометит эту группу как нерабочую.

Обратите внимание на скриншот: общий статус балансировщика сменился на Error. Это происходит, даже если первая группа (порт 80) работает идеально и трафик проходит без перебоев.

Логика здесь простая: система намеренно «бьет тревогу», чтобы не проскочила проблема даже в одной из частей инфраструктуры. Увидев красную плашку, не стоит сразу писать тикет в техподдержку. Чаще всего разгадка кроется внутри карточки балансировщика. Нужно проверить статус конкретных правил, убедиться, что порты на серверах открыты, или же заглянуть в логи — там наверняка уже указана причина сбоя.

Выбор протоколов и маршрутизация

На финальном этапе настройки нам нужно определить схему маршрутизации: по какому протоколу балансировщик примет запрос и по какому передаст его дальше на серверы.

TCP → TCP и UDP → UDP. Классическая схема: пакеты передаются «как есть», без изменения уровня протокола.
HTTP → HTTP. Стандартная передача веб-трафика без шифрования.
TCP → PROXY. Этот режим нужен, если вам важно видеть реальные IP-адреса посетителей. В обычном режиме сервер видит в логах только внутренний IP самого балансировщика. Протокол PROXY «пробрасывает» адрес клиента сквозь балансировщик, что критично для аналитики и безопасности.
HTTPS → HTTP. Именно эту связку мы будем использовать в нашем примере.

В последнем случае работает механизм SSL-терминации (SSL Offloading). Балансировщик берет на себя тяжелую работу по шифрованию и расшифровке трафика HTTPS, а внутрь сети к серверам отправляет уже «чистые» HTTP-запросы. Это удобно: не нужно возиться с настройкой сертификатов на каждом отдельном сервере — достаточно установить один сертификат на входе.

Правила балансировщика

Правило — это инструкция, которая объясняет системе, что делать с входящим трафиком. Оно принимает поток на конкретном порту и по заданному протоколу перенаправляет его на нужную группу серверов.

В настройках правила мы определяем:

входные параметры: протоколы и порты, которые «слушает» балансировщик;
маршрутизацию: выбор целевой группы серверов;
логику: HTTP-политики для более гибкого управления HTTP-трафиком;
детали соединения — например, параметры сессий и таймауты.

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

Если все же критически необходимо развести потоки на одном и том же порту, единственное решение — второй балансировщик. Однако у него будет другой, отличный от первого, публичный IP-адрес.

Переходим к настройке. Сконфигурируем балансировщик так, чтобы он принимал внешний трафик по защищенному HTTPS, но внутри сети передавал его на серверы через обычный 80‑й порт.

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

Настройка правил балансировщика. — Настройка п*равил балансировщика.*

Подключение сертификата и целевой группы

Указываем целевую группу, которую подготовили на предыдущем этапе. Выбираем SSL-сертификат, здесь два пути:

загрузить свой, если он уже куплен или сгенерирован;
выпустить новый через Let’s Encrypt прямо в панели управления.

Второй вариант удобен тем, что процесс полностью автоматизирован. Let’s Encrypt — это глобальный центр сертификации, который бесплатно выдает криптографические сертификаты X.509. Именно благодаря им работает шифрование HTTPS, а в браузере появляется заветный «замочек».

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

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

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

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

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

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

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

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

через консоль: отправить curl-запрос на внешний адрес;
через браузер: просто вбить публичный IP-адрес балансировщика в адресную строку.

curl https://5.35.29.105 
Hello World from web-server1 - 192.168.1.2 

curl https://5.35.29.105 
Hello World from web-server2 - 192.168.1.3

Следующая простая команда — ключевой элемент для тестирования балансировки. Она перезаписывает стандартную страницу веб-сервера и добавляет в нее данные о самом сервере.

echo "Hello World from $(hostname) - $(hostname -I)" > /var/www/html/index.html

Разбор переменных:

$(hostname) — автоматически подставит имя хоста — например, web-server-01;
$(hostname -I) — подставит IP-адрес сервера.

Как видим, механизм балансировки работает исправно: запросы поступают на разные серверы по очереди.

Такое же поведение наблюдаем и в браузере. Если обновлять страницу, балансировщик будет перенаправлять нас то на первый, то на второй сервер:

*Проверка работоспособности первого сервера в браузере.*

Ошибки

1. Недоступность порта

Самая распространенная проблема — порт, который должен слушать балансировщик, не доступен с сервера.

Особенно часто с этим сталкиваются при интеграции с Kubernetes. Там действуют свои специфические правила назначения и проброса портов, из-за чего легко запутаться. Эту глубокую тему я планирую подробно разобрать в одной из будущих статей.

Диагностика: в случае ошибки, правило балансировки, в котором указан проблемный порт, перейдет в статус ERROR и подсветит соответствующее уведомление в интерфейсе.

2. Путаница в протоколах

Еще раз напомню про важное различие, которое часто упускают из виду: TCP-трафик на 80-м порту и HTTP-трафик — не одно и то же.

Хотя технически передача данных будет работать в обоих случаях, функциональность получится различной. Если выбрать TCP вместо HTTP, то балансировщик будет работать как простая «труба». Потеряется доступ к функциям 7‑го уровня (L7): перестанут работать редиректы и, что критично для веба, окажется невозможно загрузить SSL-сертификат прямо на балансировщик.

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

3. Выбор тарифа и оценка нагрузки

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

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

4. Ручное создание балансировщика для Kubernetes

Есть неочевидный нюанс при работе с готовым кластером — Managed Kubernetes. Если вы создать балансировщик вручную через панель управления, а не через манифесты K8s, может ждать неприятный сюрприз: в один момент он просто исчезнет.

Почему так происходит? Работа Kubernetes строится на декларативном принципе: «желаемое состояние» системы описано в манифестах. У каждого кластера есть окно обслуживания. В это время система проводит синхронизацию — приводит реальность тому, что зафиксировано в конфигурации.

Если ресурс, к примеру балансировщик, добавлен вручную, но отсутствует в манифесте, система посчитает это «отклонением» и принудительно приведет кластер к исходному виду — то есть удалит «лишний» балансировщик.

Отказоустойчивый балансировщик нагрузки

Главное ограничение стандартного облачного балансировщика, которое мы обсуждали ранее, — его «локальность». Он не умеет распределять трафик между разными регионами.

Но что делать, если нужно настроить балансировку между Москвой и Санкт-Петербургом? Или объединить в одну сеть облачные и выделенные серверы?

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

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

Важный нюанс: у этого инструмента нет графического интерфейса для самостоятельной настройки. Любые изменения — от создания правила до смены весов — вносятся инженерами технической поддержки по запросу. Да, увеличивается время внесения правок, но взамен — профессионально настроенная, действительно «неубиваемая» инфраструктура.

Заказать услугу можно в соответствующем разделе панели управления.

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

Подготовка

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

Санкт-Петербург — новые облачный и выделенный серверы;
Москва — серверы из предыдущего примера с перенастройкой сетевой части.

Чтобы объединить эти разрозненные сегменты в единое целое, первым делом понадобится глобальный роутер. Логика настройки будет следующей:

создаем сам роутер,
подключаем к нему уже существующую сеть в зоне ru‑2,
создаем и подключаем дополнительную сеть в зоне ru‑1 — для новых участников балансировки,
завершаем контур добавлением сети в зоне СПБ‑3 — для выделенного сервера.

Итак. Создаем глобальный роутер и сразу подключаем к нему нашу текущую сеть из зоны ru-2.

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

Настраиваем IP‑адресацию

Следуя инструкции, нам нужно зарезервировать свободные IP-адреса в уже существующей сети. В моем примере я выбрал диапазон 192.168.1.252−192.168.1.254. При этом сам глобальный роутер получит адрес 192.168.1.254.

Далее расширяем географию сети.

Зона ru-1 в облаке — создаем сеть через меню Подключить новую сеть.
Подсеть: 192.168.0.0/24.
IP глобального роутера: 192.168.0.254.
Зона spb-3 с выделенным сервером — создаем сеть согласно инструкции.
Подсеть: 172.16.0.0/24.
IP Глобального роутера: 172.16.0.1 — возьмем первый адрес в диапазоне для разнообразия схемы.

Для настройки веб-сервера на выделенной машине используем тот же скрипт, что и для облачных. Здесь есть два пути:

вставить код в поле User Data на этапе создания сервера, как мы делали ранее;
ввести те же команды вручную после запуска системы:

#!/bin/bash
apt update
apt install -y apache2
systemctl start apache2
systemctl enable apache2
echo "Hello World from $(hostname) - $(hostname -I)" > /var/www/html/index.html

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

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

Зона ru-1 в облаке
Сеть: 192.168.0.0/24
IP глобального роутера: 192.168.0.254
Сервер: 192.168.0.2
Зона ru-2 в облаке
Сеть: 192.168.1.0/24
IP глобального роутера: 192.168.1.254
Сервер 1: 192.168.1.2
Сервер 2: 192.168.1.3
Зона spb-3 с выделенными серверами
Сеть: 172.16.0.0/24
IP глобального роутера: 172.16.0.1
Сервер: 172.16.0.2

На всех четырех серверах установлен и запущен веб-сервер Apache.

Заказ отказоустойчивого балансировщика

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

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

*Форма заказа отказоустойчивого балансировщика.*

Переходим к оформлению заявки. Разберем каждый пункт подробно, чтобы избежать ошибок.

1. Скорость

Пропускная способность — выбирается нужная ширина канала: 20, 50, 100 или 1 000 Мбит/с.

Примечание
Если задача нестандартная — например, требуется 10 Гбит/с или специфический лимит облака в 3 Гбит/с, — выбирается пункт Другое.

2. Глобальный роутер

Указывается название или UUID роутера. В примере выше — это Gordienko 014e7c79-cf0e-44cd-9b8b-bcbb0b291868.

3. Приватная подсеть

Этот пункт часто вызывает вопросы. Поле Приватная подсеть /16 для подключения балансировщика — это техническая сеть, в которой будет «жить» сам балансировщик.

По умолчанию предлагается 10.128.0.0/16 — из‑за редкого использования. Однако на практике чаще берут сети 192.168.xx.xx или 10.10.xx.xx.

Если инфраструктура использует подсеть, которая пересекается с 10.128.x.x, нужно обязательно изменить значение в заявке, чтобы избежать конфликта IP-адресов.

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

В глобальном роутере каждая сеть должна быть уникальной. Мы об этом говорили в статье «Как настраивать сети», где тоже подготавливали инфраструктуру

4. Алгоритмы балансировки

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

Round Robin — круговая очередь. Запросы раздаются серверам строго по порядку. (Мы выберем этот вариант для наглядности тестов).
Weighted Round Robin — взвешенная очередь, то есть каждому серверу присваивается некоторый условный вес. «Тяжелым» серверам отдается больше запросов, «легким» — меньше.
Source IP hash — в зависимости от HTTP-заголовка или IP-адреса выбирается предпочтительный сервер для получения запроса.
Least Connections — отправка запроса на сервер с наименьшим количеством активных соединений.
Sticky-session — опция, которая «приклеивает» пользователя к конкретному серверу на время сессии. Как правило, перед группой серверов находится дополнительный балансировщик нагрузки, скажем Nginx или HAProxy, который и устанавливает правила распределения трафика между доступными узлами. Не будем включать её сейчас, чтобы не мешать тестированию переключения между городами.

5. Целевые серверы

В поле списка серверов нужно подробно расписать топологию сети. Укажим протокол, в нашем случае HTTP, и перечислим всех участников:

Группа: ru-1 (Москва, Облако):
Сеть: 192.168.0.0/24
IP глобального роутера: 192.168.0.254
Сервер: http://192.168.0.2
Группа: ru-2 (Санкт-Петербург, Облако):
Сеть: 192.168.1.0/24
IP глобального роутера: 192.168.1.254
Сервер 1: http://192.168.1.3
Сервер 2: http://192.168.1.2
Группа: SPB-3 (Санкт-Петербург, Выделенный сервер):
VLAN: 2779
Сеть: 172.16.0.0/24
IP глобального р��утера: 172.16.0.1
Сервер: http://172.16.0.2

Не копируйте слепо идентификаторы и IP-адреса из примера. Подставьте данные конкретной инфраструктуры, которую подготовили на предыдущих этапах.

6. SSL и дополнительные комментарии

Так как у нас нет интерфейса для загрузки сертификатов, мы используем поле Комментарий для передачи инструкций инженерам.

Пример заполнения
Требуется настроить редирект HTTP -> HTTPS. Сертификат находится в Менеджере секретов (проект 6c92bd...). ID секрета: 3d87a862-dfec-4d7a-a238-f6ddda875705. Домен: gordienkoand.ru.

После проверки всех полей нажимаем кнопку Подключить балансировщик.

Настройка инфраструктуры для работы с балансировщиком

Перед тем как все заработает, нам нужно решить задачу связности. Необходимо, чтобы выделенный и облачные серверы, а также новый балансировщик «увидели» друг друга.

Здесь кроется фундаментальное отличие двух типов балансировщиков.

Облачный балансировщик создает виртуальный порт (интерфейс) в каждой из подключенных сетей. Ему не нужны маршруты — он физически присутствует в той же подсети, что и серверы. Но, как мы помним, он не умеет работать с глобальным роутером.
Отказоустойчивый балансировщик — более сложный инструмент. У него есть только один порт, который находится в служебной сети — той самой, которую мы выбрали при заказе. Работает он исключительно через глобальный роутер. Сети же, которые мы хотим задействовать, нужны для настройки связанности и балансировки трафика.

Что это значит для нас? В облачном варианте магия происходила автоматически. Здесь же автоматизации пока нет: нам нужно вручную «построить мосты» между сетью балансировщика и сетями серверов. Для этого требуется настроить статические маршруты на глобальном роутере.

Настройка выделенного сервера

На выделенном сервере надо выполнить три операции.

1. Настройка веб‑сервера

Если мы воспользовались User data с скриптом, то у нас уже все создано.

#!/bin/bash
apt update
apt install -y apache2
systemctl start apache2
systemctl enable apache2
echo "Hello World from $(hostname) - $(hostname -I)" > /var/www/html/index.html

#!/bin/bash
apt update
apt install -y apache2
systemctl start apache2
systemctl enable apache2
echo "Hello World from $(hostname) - $(hostname -I)" > /var/www/html/index.html

Проверяем работу. В примере IP сервера — 84.38.187.171.

curl http://84.38.187.171
Hello World from Web-server-ded - 84.38.187.171 172.16.0.2

Все отлично!

2. Связность с глобальным роутером

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

автоматический — указать параметры сети прямо в интерфейсе (панели управления) в момент заказа сервера;
ручной — прописать настройки в конфигурационных файлах ОС уже после создания сервера.

В примере используется Ubuntu 22 и первый, более простой способ — добавление сети через панель заказа.

Небольшое примечание по скриншоту
За сервером закреплен IP-адрес 172.16.0.2. Видно, что на скриншоте нижнее поле подсвечено красным. Это не ошибка конфигурации. Дело в том, что скриншот делался уже после фактического определения адресов. Система просто предупреждает, что адрес уже занят.

Все подробности настройки сети можно найти в нашей документации.

3. Связность между облачными серверами и балансировщиком

Нас интересует секция routes в конфигурационном файле Netplan — в Ubuntu это стандартный инструмент настройки сети.

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

routes:
    - to: 10.128.0.0/16
      via: 172.16.0.1
    - to: 192.168.1.0/24
      via: 172.16.0.1
    - to: 192.168.0.0/24
      via: 172.16.0.1

Разберем, что именно мы добавляем.

to: 10.128.0.0/16 — это самый важный маршрут к сети балансировщика. Без него сервер получит запрос от балансировщика, но не будет знать, куда отправить ответ, и соединение не установится.
to: 192.168.1.0/24 и 192.168.0.0/24 — маршруты к нашим облачным сетям в Санкт-Петербурге и Москве.
via: 172.16.0.1 — во всех случаях мы указываем один и тот же шлюз. Это IP-адрес той части глобального роутера, которая смотрит в сторону нашего выделенного сервера.

root@Web-server-ded:~# cat /etc/netplan/50-cloud-init.yaml 
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        id0:
            addresses:
            - 84.38.187.171/24
            match:
                macaddress: ac:1f:6b:81:e5:5a
            nameservers:
                addresses:
                - 188.93.17.19
                - 188.93.16.19
            optional: true
            routes:
            -   to: 0.0.0.0/0
                via: 84.38.187.1
        id1:
            addresses:
            - 172.16.0.2/24
            routes:
            - to: 10.128.0.0/16
              via: 172.16.0.1
            - to: 192.168.1.0/24
              via: 172.16.0.1
            - to: 192.168.0.0/24
              via: 172.16.0.1
            match:
                macaddress: ac:1f:6b:81:e5:5b
            optional: true
    renderer: networkd
    version: 2

Применяем параметры и проверяем маршруты:

root@Web-server-ded:~# netplan try
root@Web-server-ded:~# netplan apply
root@Web-server-ded:~# ip r
default via 84.38.187.1 dev eth0 proto static 
10.128.0.0/16 via 172.16.0.1 dev eth1 proto static 
84.38.187.0/24 dev eth0 proto kernel scope link src 84.38.187.171 
172.16.0.0/24 dev eth1 proto kernel scope link src 172.16.0.10 
192.168.0.0/24 via 172.16.0.1 dev eth1 proto static 
192.168.1.0/24 via 172.16.0.1 dev eth1 proto static

Все на местах! Проверяем доступность при помощи ping:

root@Web-server-ded:~# ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_seq=1 ttl=63 time=8.84 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=63 time=8.81 ms
^C
--- 192.168.1.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 8.813/8.827/8.842/0.014 ms

root@Web-server-ded:~# ping 192.168.0.254
PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
64 bytes from 192.168.0.254: icmp_seq=1 ttl=63 time=26.2 ms
64 bytes from 192.168.0.254: icmp_seq=2 ttl=63 time=2.28 ms
^C
--- 192.168.0.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.275/14.216/26.158/11.941 ms

Все отлично! Шлюз глобального роутера как в ru-1 так и в ru-2 доступны.

С настройкой выделенного сервера закончено.

Настройка облачных серверов

Возвращаемся к нашим облачным серверам. Ситуация следующая:

в зоне ru-2 у нас работают два сервера — они продолжают обслуживать старый облачный балансировщик, мы их не трогаем;
в зоне ru-1 мы создали новый сервер.

Теперь наша задача — связать их всех в единую сеть и научить «общаться» с новым отказоустойчивым балансировщиком.

Вариант 1. Ручная правка конфигов (сложный путь)

Можно по старинке прописать маршруты вручную через консоль. Важно помнить, что пути к конфигурационным файлам зависят от версии ОС. В примере выше с Ubuntu 22 мы использовали Netplan. На серверах с Ubuntu 20, настройки часто лежат в другом месте:

/etc/network/interfaces.d/50-cloud-init.cfg

Подробнее о настройке маршрутов — в нашей инструкции.

Вариант 2. Автоматизация через панель (рекомендуемый путь)

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

Она работает через утилиту cloud-init, которая есть на большинстве UNIX-образов. Главное условие: в настройках сервера в панели управления должна быть включена опция «Автоматическая настройка портов». Если галочка стоит, система сама «протолкнет» нужные маршруты на сервер, и связность появится автоматически.

1. Поиск нужной сети

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

Почему нет прямой ссылки? В URL содержится уникальный идентификатор UUID проекта. У каждого этот свой — ссылка попросту не откроется.

Вместо этого ориентируйтесь на скриншот ниже — он покажет точное расположение нужного раздела.

2. Добавление статических маршрутов

Теперь переходим к самому действию. В настройках выбранной подсети находим раздел Автоматические сетевые настройки, раскрываем вкладку Статические маршруты и нажимаем кнопку Добавить маршрут.

Здесь нужно заполнить два поля:

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

Пример настройки для сети в ru-1 В нашем случае для московской сети шлюзом выступает адрес 192.168.0.254. Также нужно добавить маршруты ко всем остальным участникам инфраструктуры:

к балансировщику: 10.128.0.0/16 —> next-hop 192.168.0.254
к выделенному серверу: 172.16.0.0/24 —> next-hop 192.168.0.254
к сети в ru-2 (СПб): 192.168.1.0/24 —> next-hop 192.168.0.254

Важно!
Эту процедуру нужно повторить и для сети в ru-2, но там в качестве шлюза (next-hop) — ее локальный адрес роутера (192.168.1.254), а в списке сетей назначения — соответствующие удаленные сети.

3. Применение настроек

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

Во время загрузки служба cloud-init свяжется с метаданными облака и автоматически добавит новые маршруты в конфигурацию системы. Не нужно ничего прописывать в консоли вручную.

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

После перезагрузки необходимо зайти на сервер и проверить таблицу маршрутизации командой ip route (можно сокращенно ip r). Должны быть видны новые строки с адресами подсетей.

Эту же процедуру — настройка в панели и перезагрузка — повторяем для всех остальных облачных серверов в нашей инфраструктуре — например, в зоне ru-2.

Проверка связи

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

Почему именно его? Причина чисто утилитарная: у этого сервера настроен внешний публично доступный IP-адрес — можно подключиться напрямую через удобный SSH-клиент.

root@Web-server-ded:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=62 time=3.18 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=62 time=1.95 ms
^C
--- 192.168.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.952/2.563/3.175/0.611 ms

root@Web-server-ded:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=62 time=8.79 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=62 time=8.59 ms
^C
--- 192.168.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 8.590/8.691/8.793/0.101 ms

root@Web-server-ded:~# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=62 time=10.7 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=62 time=9.33 ms
^C
--- 192.168.1.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 9.332/10.028/10.724/0.696 ms

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

К этому моменту техническая поддержка уже обработала нашу заявку и настроила отказоустойчивый балансировщик. В нашем примере балансировщику присвоен публичный IP-адрес 94.26.255.90.

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

Теперь самое интересное — проверим, как распределяется трафик. Сделать это можно двумя способами:

через консоль — используя утилиту curl, что является предпочтительным вариантом по причине наглядности, так как можно быстро делать много запросов;
через браузер — просто перейдите по адресу https://94.26.255.90.

gordienko@Selectel ~ % curl https://94.26.255.90
Hello World from web-server3 - 192.168.0.2 

gordienko@Selectel ~ % curl https://94.26.255.90
Hello World from web-server2 - 192.168.1.3 

gordienko@Selectel ~ % curl https://94.26.255.90
Hello World from web-server1 - 192.168.1.2 
gordienko@Selectel ~ % curl https://94.26.255.90
Hello World from Web-server-ded - 84.38.187.171 172.16.0.2

Итак, видно, что трафик распределяется по всем серверам равномерно: как по облачным, так и по выделенным.

Дополнительные возможности балансировщика

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

Но что делать, если для аналитики, сбора статистики или настроек безопасности критически важно знать реальный IP-адрес клиента?

Выручит технология Proxy Protocol — она позволяет балансировщику передавать информацию об исходном IP-адресе клиента дальше по цепочке, прямо на серверы.

Поскольку у Отказоустойчивого балансировщика нет панели управления настройками, эта опция активируется через тикет-систему. Просто создайте запрос в поддержку с просьбой включить Proxy Protocol.

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

Ошибки при работе с отказоустойчивым балансировщиком

В завершение разберем «грабли», на которые чаще всего наступают пользователи при работе с этим инструментом.

1. Несоответствие IP-адресов

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

2. Забытые маршруты

По статистике поддержки, 80% обращений связаны с отсутствием маршрутизации. Главная ловушка в том, что служебная сеть балансировщика (10.128.0.0/16) не отображается в панели управления. О ней легко забыть.

Симптом: серверы работают, балансировщик активен, но трафик не идет.

Решение: обязательно прописывать маршруты не только между серверами, но и обратно к сети балансировщика.

Совет: вести собственную документацию и сохранять схемы инфраструктуры — в панели таких подсказок не будет.

3. Закрытые порты и межсетевые экраны

Банально, но факт: сервис может быть недоступен, потому что его блокирует файрвол — iptables, ufw. Может и само приложение просто не запущено или упало. Всегда проверяйте доступность порта локально — с помощью telnet или curl — с самого сервера перед тем, как искать проблему в сети.

4. Неверный выбор алгоритма

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

Пример
Если используется облако как резерв для выделенного сервера, то нужен Weighted Round Robin — взвешенный алгоритм. Так можно отдавать на мощное железо 90% трафика, а в облако — только остатки.

5. Ошибки планирования тарифа

Балансировщик часто подключают, когда проект уже вырос. Важно трезво оценить трафик. Базовый тариф — 20 Мбит/с. Если реальный поток выше, проблемами неизбежны.

Пакеты начнут вставать в очередь. Сначала появятся странные «тормоза» — увеличение времени отклика даже при низкой нагрузке на CPU. Со временем запросы начнут «отваливаться» по таймауту.

Поскольку графиков мониторинга в панели пока нет, диагностировать это самостоятельно сложно. Придется писать в поддержку.

6. Просроченный SSL-сертификат

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

Совет
Используйте интеграцию с нашим менеджером сертификатов — как это сделано в примере. Бесплатные сертификаты Let's Encrypt будут обновляться автоматически, избавляя от головной боли.

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Логи и графики

Облачный балансировщик — полный контроль

Для базового облачного балансировщика логирование включ��ется еще на этапе создания. Но одними текстовыми логами дело не ограничивается. Можно выстроить полноценную систему визуализации метрик, используя популярные инструменты:

Мы предоставляем инструкции по экспорту метрик, что позволяет видеть картину в реальном времени. Что попадает в логи:

HTTP-запросы;
TCP-соединения;
административные события — например, изменение статуса сервера в целевой группе.

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

Отказоустойчивый балансировщик — нюансы

С отказоустойчивым решением все строже. Поскольку это managed-сервис без панели управления, подход иной:

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

На сегодняшний день функционал ограничен этими рамками. Однако сервис активно развивается, и в ближайшем будущем мы планируем внедрить новые удобные «фишки» для мониторинга, о чем обязательно сообщим в новостях.