Active-Active¶

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

¶История и предпосылки

Потребность в архитектуре Active-Active возникла с ростом требований к отказоустойчивости критически важных информационных систем — банковских, телекоммуникационных, государственных. Традиционная схема Active-Passive, хотя и обеспечивала резервирование, не позволяла эффективно утилизировать дорогостоящие ресурсы: резервные узлы простаивали большую часть времени, а переключение на них (failover) занимало от нескольких секунд до десятков минут. Кроме того, при пиковых нагрузках одного активного узла могло не хватать для обработки всех запросов.

Первые реализации Active-Active появились в 1990-х годах в сфере кластеризации баз данных и веб-серверов. Компании Oracle, IBM и Microsoft внедрили поддержку таких конфигураций в свои продукты (Oracle RAC, IBM DB2 pureScale, Microsoft SQL Server Always On). С развитием облачных технологий, микросервисной архитектуры и контейнеризации принцип Active-Active стал стандартом де-факто для большинства высоконагруженных веб-сервисов (поисковые системы, социальные сети, CDN).

¶Принцип работы и ключевые механизмы

¶Балансировка нагрузки

Для распределения запросов между активными узлами используются балансировщики нагрузки — программные (NGINX, HAProxy) или аппаратные (F5, Citrix ADC). Балансировщик анализирует текущую загрузку узлов, время отклика и доступность, направляя каждый новый запрос к наименее загруженному серверу.

¶Репликация данных

Синхронная или асинхронная репликация данных между узлами обеспечивает целостность информации. В синхронной модели (например, 5G сетях) транзакция считается завершённой только после подтверждения записи на всех узлах, что гарантирует нулевую потерю данных (RPO=0). Асинхронная репликация допускает некоторую задержку, но обеспечивает более высокую производительность и терпимость к задержкам сети.

¶Обнаружение сбоев (Failure Detection)

Каждый узел периодически отправляет сигналы «heartbeat» (сердцебиение) соседним узлам. Если от узла не поступает ответ в течение заданного тайм-аута, он считается отказавшим. В современных системах также применяются протоколы консенсуса (Raft, Paxos) для согласования состояния кластера при сбоях.

¶Автоматический фейловер

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

¶Типовые реализации

¶Кластеры баз данных

СУБД с поддержкой Active-Active (например, Oracle Real Application Clusters, MySQL Cluster, Cassandra) позволяют нескольким серверам одновременно обрабатывать записи в одну базу данных. Это даёт возможность масштабировать производительность горизонтально (добавляя новые узлы) и обеспечивать доступность при отказе одного из серверов. В таких системах критически важна синхронизация кэшей и блокировок.

¶Геораспределённые системы

Многие крупные компании размещают свои дата-центры в разных географических регионах, объединяя их в Active-Active кластер. Например, сервисы Google и Amazon обрабатывают запросы пользователей одновременно из нескольких центров обработки данных (ЦОД), что позволяет снизить задержки для удалённых клиентов и выдерживать отключение целого региона (например, из-за стихийного бедствия).

¶Сети доставки контента (CDN)

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

¶Приложения с микросервисной архитектурой

В контейнерных средах (Kubernetes, Docker Swarm) экземпляры каждого микросервиса запускаются в нескольких контейнерах на разных хостах. Оркестратор автоматически распределяет запросы между всеми экземплярами и перезапускает отказавшие поды.

¶Преимущества и недостатки

¶Преимущества

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

¶Недостатки

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

¶Критика и ограничения

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

Кроме того, в системах с Active-Active усложняется разрешение конфликтов одновременных изменений. Например, если два пользователя одновременно редактируют один и тот же документ на разных узлах, требуется либо механизм оптимистичных блокировок (с последующим разрешением коллизий), либо синхронизация на уровне приложения.

¶Примеры применения

• Google Search: обработка поисковых запросов одновременно из нескольких дата-центров по всему миру.
• Amazon Web Services (AWS): большинство облачных сервисов (EC2, S3, RDS) поддерживают развёртывание в режиме Active-Active в нескольких регионах.
• Сбербанк (Россия): ядро банковской платформы «СберТех» построено на кластерной архитектуре Active-Active.
• VK (Mail.ru Group) (организация, признанная в РФ иностранным агентом): социальные сети и мессенджеры используют Active-Active для обработки миллионов одновременных пользователей.

¶Источники и литература

• Шмидт, Д. «Архитектура высоконагруженных систем». — СПб.: Питер, 2019. — Глава 11.
• Документация Oracle Real Application Clusters (RAC) Installation Guide. — Oracle Corporation, 2022.
• «Designing Data-Intensive Applications» by Martin Kleppmann. — O'Reilly Media, 2017. — Chapter 8.
• RFC 7910 — Considerations for Active-Active Data Center Architectures. — IETF, 2016.
• Статья «Active-Active vs. Active-Passive Clustering» на портале Techopedia, 2021.