Active/Passive vs Active/Active: в чем разница для высокодоступной инфраструктуры
2026-05-29 11:55
Active/passive напоминает магазин с одной кассой и кассиром в подсобке: основной устал, резервный встал на смену. Параллельная схема active/active работает как две кассы одновременно — пропускная способность вдвое выше, однако если одна закрылась, очередь к другой удваивается. Сама аналогия простая, а выбор между этими двумя архитектурами для бизнеса — нет. От этого решения зависит, во сколько обойдется отказоустойчивая связка, насколько она сложна в эксплуатации и какой SLA реально удастся гарантировать. Дальше разберем обе схемы по полочкам: устройство, сценарии, утилизация, риски, цена. А в конце соберем чек-лист — когда выбрать одну, а когда другую.
Что такое active/passive и active/active в одном предложении
Если предельно коротко, обе схемы решают задачу высокой доступности (high availability, HA), но по-разному распределяют нагрузку между узлами.
Active/passive: один работает, второй ждет
В схеме active passive один узел обслуживает трафик, а второй держит реплику и стоит в горячем резерве. При сбое основного резерв принимает нагрузку и становится новым primary. Это классический failover-сценарий с RTO 5–60 секунд и понятной логикой работы.
Active/active: оба работают одновременно
В архитектуре active active оба узла одновременно обрабатывают запросы клиентов через балансировщик (load balancer). Нагрузка делится между ними, а при сбое одного его трафик мгновенно уходит на оставшийся. RTO здесь близко к нулю, потому что переключения как такового не происходит — клиента просто отправляют на живой узел.
Где терминология совпадает, а где расходится у вендоров
Здесь есть существенный нюанс. У Microsoft пассивную схему часто называют Failover Cluster Instance (FCI), а параллельную — Availability Groups (AG) с readable secondary. У Oracle есть Real Application Clusters (RAC) — это полноценный режим работы с двумя primary. У PostgreSQL чаще встречается архитектура с одним активным узлом через Patroni primary/standby, а параллельная схема реализуется через шардинг или multi-master надстройки. Перед сравнением конкретных продуктов всегда уточняйте, что именно вендор называет «активной парой»: иногда речь идет лишь о чтении с реплик, тогда как полноценная запись все равно идет на один узел.
Active/Passive: устройство и сценарии
В пассивной связке один узел в любой момент времени остается primary, а остальные — standby. Дальше различия идут по степени готовности резерва.
Hot standby: горячий резерв с актуальными данными
Hot standby — самый быстрый вариант. Резерв принимает синхронную или почти синхронную репликацию с минимальным лагом и в случае отказа поднимает сервис за секунды. RPO здесь близок к нулю при синхронной репликации, RTO — 5–30 секунд. Так работают Patroni для PostgreSQL и MS SQL AlwaysOn FCI.
Warm standby: резерв с задержкой репликации
Warm standby отстает от primary на секунды или минуты — репликация асинхронная. Зато проще по сети и дешевле в эксплуатации. RPO составляет 1–15 минут, RTO — 30–120 секунд. Подходит для систем, где допустима потеря последних транзакций.
Cold standby: резерв включается из бэкапа вручную
Cold standby — это даже не классический HA, а скорее регламентное восстановление. Резервный сервер выключен или развернут как «холодная» копия из последнего бэкапа. RTO измеряется часами, а RPO равен интервалу бэкапа. Применяется такая схема для некритичных систем и архивных контуров.
Типичные продукты: MS SQL AlwaysOn FCI, Patroni primary/standby
В Windows-стеке стандарт — MS SQL AlwaysOn FCI на базе Windows Server Failover Cluster (WSFC) c общим хранилищем. В Linux-мире — Patroni плюс etcd или Consul для PostgreSQL и Pacemaker плюс Corosync для общих ресурсов. На уровне виртуализации задачу решает VMware vSphere HA с автоматическим перезапуском ВМ на свободном хосте. Для серьезных проектов разумно сразу планировать кластер из 3 узлов — это минимум, при котором кворум работает надежно.
Active/Active: устройство и сценарии
Параллельная схема устроена принципиально иначе. Здесь обе ноды работают одновременно, а данные синхронизируются между ними в реальном времени.
Балансировка нагрузки между обоими узлами
Перед парой узлов всегда стоит балансировщик: HAProxy, Nginx, F5 BIG-IP, Citrix ADC или Microsoft NLB. Он распределяет трафик по алгоритмам round-robin, least connections, source IP hash. Для приложений с состоянием (корзины, сессии) используется sticky session — клиент привязывается к одному узлу на время сессии. А для stateless-API подходит любой простой алгоритм.
Общие данные: shared storage или distributed state
Дальше начинается главная сложность. Обе ноды должны видеть одни и те же данные, иначе клиент увидит расхождение. Подходов существует два. Первый — shared storage: общий SAN или iSCSI, к которому подключены оба узла через кластерную файловую систему (CSV в Windows, OCFS2 или GFS2 в Linux). Второй — distributed state: каждая нода держит свою копию, а синхронизация (data sync) идет на уровне приложения или СУБД. Между узлами должна быть низкая латентность — до 1 мс для синхронной репликации, иначе производительность проседает.
В мире СУБД полноценная параллельная архитектура — это Oracle Real Application Clusters (RAC) с общим хранилищем на ASM и InfiniBand между узлами. Из открытых решений — Galera Cluster (MariaDB или Percona XtraDB) с синхронной репликацией и MySQL InnoDB Cluster плюс ProxySQL. У NoSQL такую же модель по записи дают MongoDB sharded cluster и Cassandra ring. А самый простой и массовый сценарий — HAProxy и два stateless web-узла перед базой данных. Если задача предполагает серьезную нагрузку, имеет смысл подобрать сервер баз данных под профиль рабочей нагрузки еще на этапе проектирования.
Сравнение по утилизации железа
С устройством мы разобрались, теперь переходим к экономике. Главная разница между двумя схемами видна именно тут.
Active/passive: половина железа простаивает
В резервной схеме реально работает только один узел, а резервный простаивает. Получается, что utilization колеблется около 50%. Бизнес платит за две машины, а пользу извлекает с одной. Минус прямой, но он компенсируется простотой эксплуатации и предсказуемостью при сбое.
Active/active: оба узла загружены, но каждый должен тянуть 2× нагрузку при отказе
В параллельной схеме обе машины нагружены — кажется, что utilization выше. Однако есть подвох: каждый узел должен быть способен в одиночку держать 100% нагрузки. То есть в штатном режиме нельзя загружать его выше 40–50%, иначе при сбое оставшийся захлебнется. По факту полезной утилизации те же 50%, просто железо нагружено симметрично.
Парадокс: active/active не всегда дешевле
Получается интересная картина. На бумаге параллельная схема выглядит выгоднее — все железо в работе. На практике запас под отказ съедает разницу. А если добавить стоимость лицензий на параллельные СУБД (Oracle RAC требует отдельной лицензии Real Application Clusters), сложного балансировщика и распределенного хранилища — итоговая сумма нередко обгоняет резервный вариант. Получается, что выбор «дешевле или дороже» не очевиден и решается расчетом TCO под конкретную нагрузку.
Сравнение по сложности и риску
Утилизация — это деньги, а вот сложность — это риски. И здесь разрыв между схемами огромный.
Active/passive: проще в проектировании и эксплуатации
В резервной модели один источник истины. Репликация направлена в одну сторону, конфликтов записей нет, отладка инцидентов понятна: смотрим primary и standby, видим лаг репликации. Команда среднего уровня поднимает такой кластер за день-два.
Active/active: сложнее — синхронизация данных, конфликты записей
Параллельная архитектура требует на порядок больше внимания. Запись идет на оба узла, поэтому нужна логика разрешения конфликтов (последняя запись побеждает, vector clocks, слияние на стороне приложения). Любая ошибка в коде приложения или сети приводит к расхождению данных. Управление shared state (общими сессиями, блокировками, кешами) превращается в отдельную инженерную задачу. И не все приложения вообще готовы работать в режиме параллельной записи без переписывания.
Split-brain в active/active гораздо опаснее
Главная угроза — split-brain. Если между узлами рвется heartbeat, оба считают себя живыми и продолжают принимать запись. В резервной схеме проблема решается через quorum и witness, тогда как в параллельной последствия тяжелее: данные расходятся в обе стороны, и потом их не свести без потерь. Поэтому здесь критичны и кворум, и STONITH, и регулярное тестирование разрыва сети.
Когда выбирать active/passive
Резервная схема — выбор по умолчанию для систем со сложной транзакционной логикой и записью на один узел.
1С:ERP с высокой записью и сложной транзакционной логикой
1С на 100+ пользователей с тяжелыми проводками — это active/passive по факту. Платформа от «1С» спроектирована под одну активную базу, и попытки разнести запись на два узла приводят к коллизиям и потере данных. Стандарт здесь — Patroni для PostgreSQL Pro с синхронной репликацией.
MS SQL и PostgreSQL без шардинга
Обе СУБД хорошо живут в режиме «один primary, один standby» — у MS SQL это AlwaysOn FCI, у PostgreSQL — Patroni primary/standby. Параллельная запись в обеих требует либо отдельных продуктов (MS SQL AG с readable secondary дает только чтение), либо шардинга, что усложняет архитектуру в разы.
Файловые серверы, контроллеры доменов с FSMO-ролями
Active Directory с FSMO-ролями, файловые серверы с CIFS/SMB, любые сервисы с состоянием на диске — все они работают по схеме «один primary». При сбое резерв берет роль на себя, но запустить одновременно два таких сервиса невозможно по логике.
Когда выбирать active/active
С другой стороны, есть классы задач, где параллельная схема дает прямой выигрыш в производительности и доступности.
Web-фронт с stateless-сервисами
Веб-приложение без серверного состояния — идеальный кандидат. Все сессии в Redis или JWT, все данные в БД, на самих веб-узлах ничего постоянного нет. HAProxy раскидывает трафик между двумя-четырьмя нодами, и при сбое любого клиент даже не замечает.
Высоконагруженные API за HAProxy / Nginx
API-шлюзы и микросервисы работают по той же логике. Здесь масштабирование решается добавлением узлов, а параллельная схема обеспечивает и горизонтальный рост, и отказоустойчивость в одной конфигурации. Это самый распространенный сценарий в современных архитектурах.
CDN, кэширующие узлы, прокси
Кэши и CDN-узлы по природе stateless. Любой запрос можно обслужить на любом узле, и потеря одного никак не влияет на корректность ответа. Параллельная схема тут — естественная архитектура.
NoSQL с шардингом (MongoDB sharded, Cassandra)
MongoDB sharded cluster и Cassandra ring — настоящая параллельная схема по записи. Важно: Cassandra использует eventual consistency — данные реплицируются с задержкой, что недопустимо для финансовых транзакций. Каждый узел отвечает за свой диапазон ключей (шард), запись и чтение распределяются по всему кольцу. Линейное масштабирование работает, пока правильно подобран shard key.
Гибридные сценарии
На практике чисто резервная или чисто параллельная схема встречается редко. Большинство реальных систем — гибриды.
Active/active web + active/passive БД за ним
Распространённый паттерн 2026 года. Веб-фронт работает в параллельном режиме за HAProxy, а под ним стоит классическая резервная связка PostgreSQL или MS SQL. Такая комбинация дает горизонтальное масштабирование чтения и стабильность записи на одной базе. Подобрать сетевое оборудование с LACP и MLAG под этот контур — задача того же уровня важности.
Дальше идет разнесение чтения и записи. Запись принимает primary в резервном режиме, а чтение раздается по двум-пяти read-only репликам. Так устроен MS SQL AlwaysOn AG с readable secondary и стандартная связка PostgreSQL с pgpool или pgcat.
Active/passive в одном ЦОД + active/active между ЦОД
Geo-связка. В каждом дата-центре локально работает резервная схема для базы данных, а между ЦОД действует параллельная схема на уровне web и балансировки. Если падает целый ЦОД, трафик уходит на второй за секунды. Главные ограничения — стоимость канала между ЦОД и латентность. Под виртуализацию таких контуров часто берется сервер виртуализации с двумя сокетами и большим объемом RAM.
Что выбрать под типовые задачи бизнеса
Сведем рекомендации в чек-лист — что и где разумно ставить.
Интернет-магазин: web active/active, БД active/passive
Для e-commerce это золотой стандарт. Веб-фронт в параллельном режиме за HAProxy легко масштабируется при пиковых нагрузках, а база данных работает с одним primary и синхронной репликацией. Так получается и высокая доступность, и предсказуемая производительность.
1С на 100+ пользователей: active/passive с реплицирующимся PostgreSQL
Для крупного 1С — только резервная схема. Patroni с двумя нодами Postgres Pro Enterprise и witness-сервером дает RTO 10–30 секунд и RPO около нуля. Параллельная запись в 1С на текущей платформе не реализуется.
Видеонаблюдение: active/active серверы записи с edge-NVR
Видеосерверы пишут потоки параллельно с разных камер — это типовая параллельная нагрузка. При сбое одного его камеры мгновенно переключаются на свободный сервер по схеме N+1. Архивное хранилище подключается как общий SAN.
Не уверены, нужна ли вам резервная или параллельная архитектура? Наши инженеры рассчитают TCO обеих под вашу нагрузку, подберут серверы, балансировщики и СХД, спроектируют схему репликации и тестирования. Закажите подбор сервера под задачу — после расчета будет понятна реальная стоимость и сроки внедрения.
Сравнительная таблица
Сравнение Active/Passive и Active/Active
Критерий
Active/Passive
Active/Active
Утилизация железа
~50%
~50% (запас под отказ)
RTO
5–60 секунд
0–10 секунд
RPO
0 (синхронная репликация)
0
Сложность проектирования
Низкая
Высокая
Сложность эксплуатации
Низкая
Высокая
Риск split-brain
Управляемый через quorum
Высокий, требует STONITH
Стоимость лицензий
Стандартные
Часто отдельные (Oracle RAC)
Типовые продукты
MS SQL FCI, Patroni, VMware HA
Galera, Oracle RAC, MongoDB sharded
Подходит для
СУБД, файловые серверы, 1С
Web, API, кэши, NoSQL
Масштабирование записи
Нет
Да (с шардингом)
Часто задаваемые вопросы (FAQ)
Чем active/passive отличается от active/active?
В резервной схеме один узел работает, второй держит реплику и ждет отказа. В параллельной обе ноды одновременно принимают трафик через балансировщик. Первая модель проще и предсказуемее, вторая дает лучшую отказоустойчивость и масштабирование, но требует синхронизации данных и защиты от split-brain.
Что дешевле — active/passive или active/active?
Часто кажется, что параллельная связка выгоднее — все железо нагружено. На практике запас под отказ съедает экономию, а сложные лицензии (Oracle RAC) и балансировщики добавляют расходов. По TCO на 3–5 лет резервная схема обычно сопоставима или дешевле, особенно для СУБД.
Что выбрать для базы 1С на 100 пользователей?
Резервную связку с Patroni и Postgres Pro Enterprise. Платформа 1С спроектирована под одну активную базу, поэтому параллельная запись не работает. Достаточно двух нод плюс witness-сервер, RTO составит 10–30 секунд при синхронной репликации.
Подходит ли active/active для MS SQL Server?
Частично. MS SQL AlwaysOn AG поддерживает до 8 secondary replicas с возможностью чтения (readable secondary) — это параллельная схема на чтение. А вот запись все равно идет только на primary, то есть полноценной параллельной записи в MS SQL нет.
Можно ли построить active/active между двумя ЦОД?
Да, на уровне web и балансировки — без проблем. На уровне базы данных сложнее: латентность между ЦОД для синхронной репликации должна быть до 1–5 мс, что реалистично только в одном городе. Для разнесенных ЦОД обычно делают резервную схему с асинхронной репликацией и автоматическим failover.
Как защититься от split-brain в active/active?
Обязательны три механизма: кворум через witness (или нечетное число узлов), STONITH для принудительного отключения зависшего узла и регулярные тесты разрыва сети между узлами. Без этих компонентов риск порчи данных при инциденте слишком высок.
Сколько узлов минимум для active/active кластера?
Технически — два, но безопасный минимум — три (с witness или третьей нодой для кворума). На двух машинах любой разрыв heartbeat приводит к риску split-brain. Для критичных систем планируется сразу 3–5 узлов с равными правами.
Нужен ли балансировщик для active/passive?
Не обязателен. В резервной схеме обычно используется виртуальный IP (VIP), который автоматически переезжает на резервный узел при отказе — клиенты ходят по одному адресу. Полноценный балансировщик (HAProxy, Nginx) нужен только если хочется добавить проверки здоровья, журналирование или подготовиться к переходу на параллельную архитектуру в будущем.
Итоги
Сравнение active/passive и active/active в 2026 году сводится к простой формуле. Резервная схема — это надежная база для систем с записью на один узел: 1С, MS SQL, PostgreSQL без шардинга, файловые серверы, контроллеры доменов. Параллельная архитектура — выбор для web, API, кэшей, NoSQL с шардингом и любых stateless-сервисов. А самый массовый сценарий — гибрид: параллельный веб-фронт плюс резервная база за ним. Утилизация железа в обеих схемах фактически около 50% из-за запаса под отказ, поэтому решающим фактором становятся сложность эксплуатации, стоимость лицензий и риски split-brain. Когда выбрать одну схему, а когда другую — диктует природа приложения, а не общие соображения о современности архитектуры.