Стоимость отказоустойчивости по уровням: от одного сервера до кластера

MAATRIX

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

Что вообще считаем уровнем отказоустойчивости

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

• RTO (Recovery Time Objective) — сколько времени пройдёт от момента аварии до момента, когда сервис снова отвечает пользователям.
• RPO (Recovery Point Objective) — сколько данных вы готовы потерять, то есть какой промежуток времени между последней сохранённой копией и моментом сбоя.

Уровень 0 — отсутствие плана: сервер упал, вы узнали об этом от пользователей в поддержке, дальше действуете по ситуации. Уровни 1-3 — возрастающая инвестиция в сокращение RTO и RPO. Дальше по каждому уровню: что он физически представляет, во сколько раз дороже базовой цены сервера обходится (без привязки к конкретным тарифам — соотношения зависят от провайдера и конфигурации, ориентируйтесь на порядок величин) и какие грабли на нём поджидают.

Уровень 0: один сервер без резерва

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

Что это значит на практике:

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

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

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

Стоимость: 1x (базовая цена сервера)
RTO: часы-сутки (в худшем случае — недели, если бэкапов нет)
RPO: от суток до "бесконечность"

Уровень 1: регулярные бэкапы и план восстановления

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

Что входит в этот уровень:

• Автоматическое резервное копирование по расписанию — базы данных через pg_dump/mysqldump или инструменты вроде BorgBackup, Percona XtraBackup, UrBackup, файловая система — снапшотами или rsync на отдельное хранилище.
• Копии хранятся вне основного сервера — на отдельном диске, в объектном хранилище или на другом сервере. Бэкап, лежащий на том же диске, что и данные, не бэкап.
• Проверенный план восстановления: не просто «есть дамп», а расписанные шаги — на каком сервере разворачивать, сколько это займёт, кто это делает.
• Периодическая проверка (хотя бы раз в квартал) — реально ли из бэкапа поднять рабочую копию, а не только «файл существует».

Пример простого cron-задания для регулярного дампа PostgreSQL с ротацией:

#!/bin/bash
# /opt/scripts/backup-db.sh
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR=/mnt/backup-storage/postgres
pg_dump -U app_user -Fc mydb > "$BACKUP_DIR/mydb_$DATE.dump"
# храним последние 14 копий, остальное чистим
find "$BACKUP_DIR" -name "mydb_*.dump" -mtime +14 -delete

Стоимость этого уровня — это дополнительное хранилище под копии (обычно в разы дешевле полноценного сервера — нужны только диски, а не CPU/RAM) плюс время на настройку и периодическую проверку. Реального failover при этом не происходит: если основной сервер недоступен, всё равно нужно поднять новый и развернуть на него бэкап.

RTO — от часа до нескольких часов, в зависимости от того, насколько отработан процесс разворачивания с нуля. RPO — от нескольких минут (дампы раз в 15-30 минут) до суток (раз в день), частоту выбираете сами под терпимость к потере данных.

Это разумный минимум для любого сервиса, где данные представляют ценность — от небольшого магазина до внутренней CRM.

Стоимость: 1.1x-1.3x (доп. хранилище + время на настройку/проверку)
RTO: 1-6 часов (разворачивание бэкапа на новом сервере)
RPO: минуты-сутки (зависит от частоты дампов)

Уровень 2: резервный сервер (тёплый или холодный)

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

Холодный резерв — сервер существует (арендован, оплачен), но не запущен или запущен с минимальной конфигурацией, без актуальных данных. При аварии вы включаете его, разворачиваете последний бэкап, переключаете DNS или балансировщик. RTO — от получаса до нескольких часов, в зависимости от объёма данных и скорости их разворачивания.

Тёплый резерв — сервер постоянно работает, данные реплицируются на него в фоне (потоковая репликация PostgreSQL/MySQL, rsync по расписанию каждые несколько минут), но он не принимает боевой трафик. При аварии переключение — это смена записи DNS/балансировщика и, возможно, промоушен реплики в мастер. RTO — минуты, RPO — минуты (задержка репликации).

Настройка потоковой репликации PostgreSQL для тёплого резерва в общих чертах выглядит так:

# на мастере, postgresql.conf
wal_level = replica
max_wal_senders = 3
wal_keep_size = 1GB

# на реплике, восстановление из базового бэкапа мастера
pg_basebackup -h master_ip -D /var/lib/postgresql/16/main -U replicator -P -R

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

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

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

Стоимость: 1.8x-2.5x (второй сервер + репликация/синхронизация)
RTO: холодный — 30 мин-неск. часов; тёплый — минуты
RPO: холодный — часы (по расписанию синхронизации); тёплый — минуты (лаг репликации)

Уровень 3: полноценный кластер с автоматическим failover

Верхняя ступень — кластер из нескольких нод с автоматическим обнаружением сбоя и переключением трафика без участия человека. Здесь появляются балансировщик нагрузки (HAProxy или nginx перед несколькими бэкендами), кворумный механизм для базы данных (Patroni + etcd/Consul для PostgreSQL, Galera Cluster для MySQL), и мониторинг здоровья каждой ноды, который триггерит переключение автоматически.

Схематично устройство:

                   ┌─────────────┐
        Клиенты →  │ HAProxy/nginx│  (балансировщик, сам может быть
                   └──────┬───────┘   зарезервирован через keepalived)
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
     ┌─────────┐    ┌─────────┐     ┌─────────┐
     │ Node 1  │    │ Node 2  │     │ Node 3  │
     │ (primary)│   │(replica)│     │(replica)│
     └─────────┘    └─────────┘     └─────────┘
          └───────────────┴───────────────┘
                Patroni + etcd (кворум,
                автоматический promote реплики)

Ключевое отличие от уровня 2 — переключение не требует ручного действия администратора: Patroni сам обнаруживает недоступность мастера через кворум etcd и промоутит реплику, HAProxy перенаправляет трафик на неё. При грамотной настройке RTO измеряется секундами-минутами, RPO стремится к нулю при синхронной репликации (ценой снижения производительности записи).

За что вы платите на этом уровне:

• Минимум 3 ноды базы данных (кворум требует нечётного числа участников для консенсуса) вместо одной-двух.
• Отдельные ноды или как минимум резервированная конфигурация под балансировщик.
• Ноды для etcd/Consul (можно совмещать с нодами базы при небольшой нагрузке, но это добавляет риски).
• Существенно возросшая сложность эксплуатации: настройка, тестирование failover, мониторинг кворума, разбор split-brain — это постоянная нагрузка на команду, а не разовая настройка.

Про выбор между HAProxy и nginx для балансировки перед такой схемой и про типовые ошибки настройки самой балансировки мы писали отдельно — это сравнение HAProxy и nginx для балансировки и пошаговая настройка балансировки нагрузки на VPS полезны, если строите кластер с нуля.

Множитель стоимости здесь самый неопределённый, потому что сильно зависит от конфигурации: минимум — 3-4 сервера сопоставимой мощности вместо одного, то есть кратный рост инфраструктурных расходов, плюс скрытая, но реальная статья расходов — время команды на проектирование, тестирование и последующую поддержку кластера. Этот уровень оправдан там, где минута простоя стоит дороже, чем разница в инфраструктурных расходах — крупные интернет-магазины в высокий сезон, финтех-сервисы, платформы с SLA перед клиентами, где просадка доступности означает штрафы или отток.

Стоимость: 3x-5x+ (3-4+ сервера + эксплуатационная сложность)
RTO: секунды-минуты (автоматический failover)
RPO: near-zero при синхронной репликации (ценой задержки записи)

Сводная таблица по уровням

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

Как выбрать свой уровень: считаем от цены простоя, а не от страха

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

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

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

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