Настройка Hetzner Cloud Load Balancer под ключ за 1 день

Настройка Hetzner Cloud Load Balancer: где рвётся отказоустойчивость

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

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

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

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

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

Измеримый эффект: время восстановления, простои, отказоустойчивость

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

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

Что стоит сверить в отчёте после сдачи:

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

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

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

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

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

Порядок внедрения: от аудита схемы до передачи в эксплуатацию

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

1. Аудит инфраструктуры. Собираем текущую схему: какие сервисы опубликованы наружу, как распределяются адреса, где лежат сертификаты и как сейчас проверяется доступность узлов. Отдельно выписываем точки отказа — одиночный узел без резерва, ручные переключения, отсутствие контроля состояния серверов приложений.
2. Проектирование схемы балансировки. Определяем размещение балансировщика относительно зон, состав целевых групп, алгоритм распределения, интервалы и пороги проверок состояния, поведение при отказе узла. Здесь же решаем, где обрабатывается защищённый трафик и какие правила переадресации нужны.
3. Подготовка сети и доступов. Приватные сети, правила фильтрации, права инженеров и системы мониторинга — всё закрываем до того, как пойдёт боевой трафик.
4. Конфигурация контура. Настраиваем Hetzner Cloud Load Balancer, целевые группы, проверки состояния, сертификаты и журналирование. Конфигурация хранится как код: изменение проходит проверку и откатывается одной операцией.
5. Проверка под нагрузкой. Прогоняем сценарии роста одновременных соединений, отказа одного узла, деградации сервиса и всплеска трафика. Смотрим, за какое время распределение перестраивается и как ведут себя задержки.
6. Ввод в эксплуатацию. Переключаем трафик поэтапно, с возможностью вернуться на прежнюю схему. Метрики задержек и ошибок снимаем до и после — чтобы видеть эффект, а не предполагать его.
7. Передача документации. Отдаём схему, инструкцию по эксплуатации и откату, описание алертов и порядок действий при отказе, чтобы инженер заказчика мог разобрать инцидент без нас.

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

Конфигурации, правила проверок и документация на передачу

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

• Конфигурация балансировщика в декларативном виде, в вашем репозитории: правила маршрутизации, целевые группы, лимиты подключений. Изменение проходит ревью и разворачивается одной командой, а не правкой в панели.
• Правила проверки состояния сервисов: путь, интервал, порог неудачных попыток, таймаут. Рядом — обоснование значений под ваш профиль трафика: за какое время узел выводится из ротации и почему именно за такое.
• Схема сети: приватный сегмент, подсети, зоны доступности, точки входа, связи балансировщика с серверами приложений и базой. На ней видно, что открыто извне, а что закрыто.
• Права доступа и сетевые правила: роли инженеров, доступ по ключам, изоляция контура сборки от промышленного. Понятно, кто и что может менять и где это фиксируется.
• Регламент эксплуатации и действий при аварии: как вывести узел из балансировки, как откатить конфигурацию к предыдущей, в какой последовательности действовать и кого подключать.
• Мониторинг: метрики по задержкам, доле ошибок и числу живых узлов с порогами срабатывания. Уведомление приходит раньше, чем жалоба пользователя.

Кейс: убрали просадку при отказе узла и ручные переключения

Как было до работ

У заказчика — два облачных сервера, трафик между ними распределялся на уровне DNS с коротким сроком жизни записи. При отказе узла часть клиентов продолжала обращаться к мёртвому адресу: срок жизни записи истекает не мгновенно, а кэши промежуточных резолверов держат старый адрес минутами. Дежурный узнавал о проблеме из жалоб, поднимал замену и вручную правил записи — 6-8 операций за инцидент и до 20 минут просадки под нагрузкой.

Что меняли

Точку входа перенесли с DNS на Hetzner Cloud Load Balancer, узлы объявили в целевую группу и настроили проверки здоровья по прикладному обработчику, а не по открытому порту. Порог — две неудачные проверки подряд, вывод узла из ротации до остановки сервиса, чтобы активные соединения доходили до конца. Добавили шаблон развёртывания нового узла и автоматическое подключение его к группе.

Что стало

• Переключение при отказе узла — 12-15 секунд вместо 20 минут и без участия человека.
• Доля успешных запросов в момент инцидента — 99,9% против 96%; обрывов пользовательских сессий на переключении не осталось.
• Ручных операций дежурного на инцидент — ноль вместо 6-8: алерт приходит, когда ротация уже выполнена.

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

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

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

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

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

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

Технические сомнения: проверки, лимиты, переезд без простоя

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

Что с лимитами по соединениям?

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

Можно ли переехать без простоя?

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

Обсудим задачу и вернёмся с оценкой и планом работ

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

• Исходные данные. Список сервисов за балансировщиком, их порты и протоколы, домены, требования к TLS, ожидаемая и пиковая нагрузка — этого хватает, чтобы понять объём.
• Доступы для разбора. Чтение проекта в облаке или экспорт конфигурации: правила межсетевого экрана, приватные сети, целевые группы, параметры проверок доступности.
• Разбор текущей схемы. Показываем, как трафик идёт сейчас, где точка отказа, почему нельзя поднять вторую копию сервиса без ручной правки адресов.
• Перечень рисков. Отдельным списком: обрыв соединений при деплое, отсутствие отката, открытые наружу порты, сроки жизни сертификатов, один узел приложения.
• План внедрения. По шагам: сеть и целевые группы, проверки доступности, TLS-терминация, переключение трафика, проверка под нагрузкой, регламент отката.
• Сроки работ. Оценка по этапам и общий срок: базовая настройка под ключ укладывается в один рабочий день, перенос живого трафика — отдельным пунктом с окном.
• Что остаётся у вас. Конфигурации, схема прохождения трафика, чек-лист переключения и набор метрик, по которым видно состояние балансировщика.