Два дата‑центра, всего 3–5 серверов: как спроектировать актив‑актив архитектуру без избыточного железа

В российской практике всё чаще возникает запрос на размещение инфраструктуры сразу в двух дата‑центрах, но при этом реальный парк — всего 3–5 ключевых серверов. В таких условиях основная задача — не «накидать железа», а чётко определить роль каждой машины: кто отвечает за вычисления, кто — за хранилище, кто — за шлюз и логирование, и какие значения RPO и RTO действительно достижимы между двумя площадками.

1. Сначала определяем цель: какой уровень двухЦОДовой отказоустойчивости реально нужен

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

RPO: сколько данных вы готовы потерять при аварии

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

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

• RTO, стремящийся к нулю: отказ одного дата‑центра почти незаметен пользователям благодаря автоматическому переключению DNS, шлюзов и балансировщиков между площадками.
• RTO в диапазоне 1–5 минут: предприятие готово принять короткое окно недоступности при аварии, если есть отработанный сценарий полуавтоматического или ручного переключения.

Форма работы: актив‑пассив или настоящий актив‑актив

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

2. Примеры распределения ролей для 3, 4 и 5 серверов в двух ЦОДах

2.1. Три сервера: минималистичный актив‑актив с одним ведущим ЦОДом

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

При такой схеме оба ЦОДа обслуживают трафик на уровне приложений, а основная запись в базу идёт в ЦОД A. Асинхронная репликация в ЦОД B даёт RPO на уровне секунд, а в случае полного отказа A приложения и шлюзы в B могут за несколько минут принять на себя записи и критичный трафик.

2.2. Четыре сервера: вынос шлюза и логов в отдельные роли

При четырёх серверах уже есть смысл развести роли «входной шлюз» и «логирование/мониторинг» с вычислительных и базовых узлов, чтобы упростить обслуживание и повысить наблюдаемость инфраструктуры.

При таком раскладе трафик удобнее заводить через ЦОД B, но обязательно держать резервный лёгкий шлюз в A на случай потери площадки B. Логи централизуются на одном узле, а агенты на других серверах буферизуют данные локально, чтобы избежать потерь при кратковременных сбоях канала.

2.3. Пять серверов: чёткие роли и почти симметричный актив‑актив

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

Входной трафик можно распределять по A‑GW и B‑GW с помощью DNS, Anycast или внешнего L4‑балансировщика. Основные записи идут в A‑DB, часть чтений обслуживается из B‑DB по месту, а логирование и мониторинг вынесены на отдельный сервер, чтобы не конкурировать за ресурсы с бизнес‑нагрузкой.

3. Роли compute, storage, gateway и логирования: что важно зафиксировать

3.1. Вычислительные узлы (приложения)

Приложения в двухЦОДовой архитектуре целесообразно проектировать как максимально без состояния. Сессии, корзины, токены и другие данные пользователя желательно хранить во внешних хранилищах (Redis, БД, отдельный сервис), чтобы любой экземпляр в любом ЦОДе мог принять запрос.

• Узлы приложений должны быть развернуты и в A, и в B, с одинаковыми версиями и конфигурацией (через CI/CD и централизованный конфиг‑сервер), чтобы RTO при отказе площадки состоял только из переключения трафика.

3.2. Хранилище и базы данных

Для 3–5 серверов наиболее практична схема «один ведущий узел + асинхронная реплика», особенно на PostgreSQL/MySQL или совместимых системах. Полноценные распределённые СУБД с синхронным консенсусом часто оказываются избыточно сложными и ресурсоёмкими для такого масштаба.

• Важно чётко определить, в каком ЦОДе размещён ведущий узел для записи и какой максимальный лаг репликации допустим — именно он устанавливает реальное значение RPO для критичных данных.
• При требованиях, близких к RPO → 0, придётся обсуждать синхронную репликацию между ЦОДами, что чревато повышенной задержкой и усложнением архитектуры, особенно при межгородских задержках.

3.3. Входной шлюз и балансировка

В каждом дата‑центре должен быть локальный шлюз, способный обслуживать трафик автономно: Nginx, Envoy, специализированный API‑шлюз. Сверху над ними может стоять DNS‑балансировка или внешний L4‑балансировщик, который распределяет запросы между A и B и решает, куда перенаправлять трафик при аварии.

• Логика здоровья (health‑check) должна уметь распознать недоступность соседнего ЦОДа и временно исключать его из ротации, чтобы не отправлять запросы в заведомо недоступный сегмент сети.

3.4. Логи и мониторинг

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

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

4. Связь между ЦОДами, компромисс по RPO/RTO и стоимость

4.1. МежЦОДовая связь: пропускная способность и задержка

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

4.2. Реалистичные RPO/RTO для 3–5 серверов

Настоящие RPO → 0 и RTO → 0 требуют полного дублирования стека в двух ЦОДах, синхронной репликации, автоматического failover и часто третьего участка для арбитража. Для инфраструктуры на 3–5 серверах это, как правило, слишком дорого и сложно в эксплуатации. Более реалистичный подход — целиться в RPO в несколько секунд или десятков секунд и RTO в 1–5 минут, с чётко прописанным и отрепетированным сценарием переключения.

5. Какому бизнесу хватит 3–5 серверов в двух ЦОДах и как это правильно оформить

Для многих российских компаний среднего масштаба пара дата‑центров с 3–5 серверами — это уже серьёзный шаг вперёд от «один стойко‑классический ЦОД». При грамотном разделении ролей, выборе Alt Linux + Proxmox для виртуализации и чётком описании RPO/RTO такая архитектура закрывает большинство требований по высокой доступности без излишней сложности.