Цена второго узла: сколько стоит переход от 99% к 99,9%

MAATRIX

Когда на одном сервере лежит всё — сайт, база, очередь задач — доступность держится на честном слове: сервер не падает месяцами, а потом падает на три часа посреди рабочего дня, и вы объясняете клиентам, почему. Разговор «а давайте поднимем второй узел» обычно начинается с вопроса «сколько будет стоить ещё один такой же сервер» — и это неверный вопрос. Второй сервер сам по себе не поднимает доступность ни на процент; поднимает её схема вокруг него, а схема стоит заметно дороже одной лишней аренды.

От 99% до 99,9%: почему это не «в десять раз реже падаем», а другая архитектура

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

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

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

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

Второй сервер сам по себе ничего не даёт

Возьмём прямую стоимость: если основной сервер стоит X в месяц, то второй такой же — плюс X. Удвоение. На этом менеджерская логика часто останавливается: «резервирование стоит в два раза дороже». На практике два независимых сервера без остальной обвязки — это не отказоустойчивая схема, а два отдельных единых узла (single point of failure), которые просто оба существуют.

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

• Кто направляет трафик на живой узел, если основной отказал — вручную оператор меняет DNS-запись или автоматически срабатывает балансировщик.
• Откуда второй узел берёт актуальные данные — если это просто пустой сервер с тем же образом системы, при переключении вы получите старую версию данных или вовсе пустую базу.
• Как деплоится код — обновляете ли вы оба узла одной командой, рискуя положить оба одновременно, или у вас есть последовательность без полного простоя.
• Кто следит за состоянием обоих узлов — простое «мониторю сервер А» превращается в «мониторю А, Б, канал между ними и сам механизм переключения».

Каждый из этих пунктов — отдельная статья расходов, встроенная в ежемесячную стоимость эксплуатации. Именно здесь прячется разница между «в два раза дороже» и «непропорционально дороже».

Балансировщик нагрузки: новая точка отказа, которую тоже нужно резервировать

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

Во-первых, сам балансировщик — это либо ещё один сервер (nginx, HAProxy, Traefik), либо управляемая услуга у провайдера. Выбор между самостоятельной установкой и готовым инструментом определяет цену владения: nginx и HAProxy решают частично разные задачи, и конфигурация каждого требует своего набора навыков.

Во-вторых — и это часто упускают на старте — сам балансировщик становится новой единой точкой отказа. Если два узла приложения стоят за одним балансировщиком, а балансировщик один, проблема просто передвинулась: раньше падал сервер, теперь падает балансировщик, и оба дорогих резервных узла остаются недостижимы. Честная схема на 99,9% требует резервирования и самого балансировщика — либо через отдельную услугу L4-балансировки у хостинг-провайдера, либо через связку keepalived с плавающим IP между двумя инстансами. Это дополнительный узел сверх двух серверов приложения — третий компонент в смете, который редко фигурирует в первоначальной прикидке «сервер плюс сервер».

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

Синхронизация данных: самая дорогая часть перехода

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

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

Синхронная репликация. Каждая запись подтверждается только после того, как её получили оба узла. Это даёт нулевую потерю данных при переключении (RPO близко к нулю), но платит за это задержкой каждой транзакции — запись ждёт подтверждения от второго узла, а если узлы разнесены географически, к задержке добавляется сетевой RTT между дата-центрами. При росте нагрузки синхронная схема упирается в пропускную способность канала между узлами раньше, чем в мощность самих серверов. Экономика и компромиссы синхронной репликации подробно разобраны в статье про цену надёжности синхронной репликации.

Асинхронная репликация. Запись подтверждается сразу на основном узле, а на резервный уходит с небольшой задержкой. Быстрее под нагрузкой, дешевле по требованиям к каналу, но при отказе основного узла в момент до синхронизации последних записей вы теряете именно эти секунды или минуты данных.

В обоих случаях синхронизация — не бесплатная опция, включаемая галочкой в панели:

• дополнительная нагрузка на сеть между узлами (а если узлы в разных локациях — оплата исходящего трафика или выделенного канала);
• дополнительная нагрузка на диск и CPU обоих серверов, которая раньше не требовалась вообще;
• инженерное время на настройку, тестирование failover-сценариев и разбор ситуаций, когда репликация отстаёт или обрывается — а она обрывается.

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

# postgresql.conf на основном узле
wal_level = replica
max_wal_senders = 5
wal_keep_size = 1GB
synchronous_standby_names = 'standby1'   # для синхронной схемы, для async — не указывается

# pg_hba.conf на основном узле
host    replication     replicator      10.0.0.20/32     scram-sha-256

# postgresql.auto.conf на резервном узле
primary_conninfo = 'host=10.0.0.10 port=5432 user=replicator password=... application_name=standby1'

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

Деплой без даунтайма: обновление двух узлов вместо одного

На одном сервере деплой — это git pull, рестарт сервиса, готово. Секунды простоя никто не замечает, потому что сайт и так недоступен на это время у всех одновременно — и это приемлемо, если вы уже смирились с 99%.

На двух узлах цель другая: обновить оба, ни разу не оставив систему полностью недоступной. Это меняет саму процедуру деплоя:

1. Вывести узел А из-под балансировщика (перестать слать на него новый трафик, дождаться завершения активных запросов).
2. Обновить код и перезапустить сервис на узле А.
3. Проверить, что узел А отвечает корректно (health-check, smoke-тест).
4. Вернуть узел А под балансировщик.
5. Повторить шаги 1–4 для узла Б.

Это называется rolling-деплой, и звучит несложно, пока не столкнётесь с тем, что между шагом 4 (узел А уже новой версии) и шагом 2 для узла Б (ещё старой) система обслуживает трафик смешанной версией кода. Это требование обратной совместимости изменений в базе данных и API — которое на одном сервере просто не существует как проблема, а на двух становится правилом для каждого релиза.

Более консервативный подход — canary-деплой, когда новая версия сначала выкатывается на малую долю трафика и только после подтверждения стабильности — на оставшуюся часть. Это ещё один слой процесса поверх и так усложнившегося релизного цикла: скрипты, которые раньше выполняли вручную за пять минут, превращаются в оркестрацию, которую либо пишете сами, либо покупаете как часть CI/CD-платформы.

Стоимость этого пункта редко выражена в отдельном счёте — она выражена в часах инженера на написание и поддержку деплой-скриптов, и в риске: неправильно написанный rolling-деплой способен положить оба узла одновременно, если скрипт не дожидается полной готовности узла А перед обновлением узла Б.

Мониторинг: не x2, а сложнее

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

• Состояние репликации — отстаёт ли резервный узел от основного, и на сколько. Отдельная метрика с отдельным порогом алерта, а не производная от «сервер жив/мёртв».
• Состояние балансировщика и health-check'ов — балансировщик может быть жив, но неверно определять, какой узел живой.
• Расхождение состояния — ситуация, когда оба узла считают себя основным (split-brain) или ни один не считает себя готовым принимать трафик. Класс инцидентов, физически не существующий при одном сервере.
• Синтетические проверки доступности всей схемы снаружи, а не изнутри — оба узла по отдельности могут отвечать на внутренний health-check, но пользователь снаружи всё равно получает ошибку из-за проблемы в балансировщике или DNS.

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

Полная смета: во сколько раз дороже на самом деле

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

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

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

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

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