Always On группы доступности

Always On группы доступности — это технология обеспечения высокой доступности и аварийного восстановления на уровне экземпляра базы данных, реализованная в Microsoft SQL Server. Она представляет собой решение для отказоустойчивой кластеризации, которое позволяет объединить несколько физических или виртуальных серверов (узлов, или реплик) в группу, обеспечивающую автоматическое переключение (failover) при сбое основного узла, а также распределение нагрузки чтения и создание резервных копий без простоев. Технология впервые появилась в SQL Server 2012 и с тех пор является основным инструментом для обеспечения непрерывности бизнеса в корпоративных средах.

История

До появления Always On групп доступности основным способом обеспечения отказоустойчивости в SQL Server были кластеры отказоустойчивости (Failover Cluster Instance, FCI), основанные на общем дисковом хранилище (SAN). Однако FCI имели существенные недостатки: единая точка отказа в хранилище, невозможность использования реплик для чтения и сложность создания резервных копий без остановки работы.

В ответ на эти ограничения в SQL Server 2012 корпорация Microsoft представила технологию Always On Availability Groups (AG). Она была разработана на основе технологии зеркалирования баз данных (Database Mirroring), но значительно расширила её возможности. В последующих версиях (2014, 2016, 2017, 2019, 2022) функциональность AG была существенно улучшена: добавлена поддержка распределённых групп доступности, возможность чтения с вторичных реплик, автоматическое переключение при сбое, а также интеграция с облачными платформами, включая Microsoft Azure.

Архитектура и принцип работы

Основные компоненты

• Группа доступности (Availability Group) — логический контейнер, объединяющий одну или несколько баз данных, которые реплицируются на разные узлы.
• Первичная реплика (Primary Replica) — узел, на котором базы данных находятся в режиме чтения-записи. Все изменения данных сначала вносятся на первичной реплике.
• Вторичные реплики (Secondary Replicas) — узлы, на которые реплицируются изменения с первичной реплики. Вторичные реплики могут быть настроены для чтения, создания резервных копий или для аварийного восстановления.
• Прослушиватель (Listener) — виртуальное сетевое имя (DNS-имя) и IP-адрес, который обеспечивает прозрачное подключение клиентов к группе доступности. Клиент всегда подключается к прослушивателю, а не к конкретному узлу.
• Кворум (Quorum) — механизм голосования между узлами, определяющий, какая реплика должна стать первичной в случае сбоя. В AG используется кворум на основе кластера Windows Server (WSFC) или на основе облачных узлов.

Режимы синхронизации

Always On группы доступности поддерживают два основных режима синхронизации данных между первичной и вторичными репликами:

• Синхронный режим (Synchronous-commit mode) — транзакция считается завершённой только после того, как изменения записаны как на первичной, так и на вторичной реплике. Этот режим обеспечивает нулевую потерю данных (zero data loss) при сбое, но увеличивает задержки записи. Используется для реплик, расположенных в одном дата-центре.
• Асинхронный режим (Asynchronous-commit mode) — транзакция завершается сразу после записи на первичной реплике, без ожидания подтверждения от вторичной. Этот режим снижает задержки, но при сбое возможна потеря части данных. Используется для реплик, расположенных в удалённых дата-центрах (георезервирование).

Автоматическое переключение (Failover)

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

• Вторичная реплика должна быть настроена в синхронном режиме.
• Должен быть настроен автоматический кворум.
• На вторичной реплике должна быть включена роль для автоматического переключения.

Если эти условия не выполнены, переключение выполняется вручную администратором (плановое или внеплановое).

Виды групп доступности

Базовая группа доступности (Basic Availability Group)

Введена в SQL Server 2016 Standard Edition. Поддерживает только одну базу данных и две реплики (одна первичная, одна вторичная). Не поддерживает чтение с вторичной реплики и автоматическое переключение в синхронном режиме. Предназначена для небольших приложений или для замены зеркалирования баз данных.

Расширенная группа доступности (Advanced Availability Group)

Доступна в SQL Server Enterprise Edition. Поддерживает до 9 реплик (одна первичная и до 8 вторичных), из которых до 3 могут быть синхронными. Включает все возможности: чтение с вторичных реплик, автоматическое переключение, распределённые группы доступности, резервное копирование с вторичных реплик.

Распределённая группа доступности (Distributed Availability Group)

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

Применение

Обеспечение высокой доступности (HA)

Основная цель AG — минимизировать время простоя базы данных при сбоях оборудования, операционной системы или самого SQL Server. При сбое первичной реплики переключение на вторичную происходит в течение нескольких секунд (при синхронном режиме) или минут (при асинхронном). Клиентские приложения, подключённые через прослушиватель, автоматически перенаправляются на новую первичную реплику.

Аварийное восстановление (DR)

Использование асинхронных вторичных реплик, расположенных в удалённом дата-центре или облаке, позволяет восстановить работу базы данных в случае катастрофы (пожар, наводнение, отключение электроэнергии). В таких сценариях потери данных обычно допустимы (RPO — несколько минут), но время восстановления (RTO) минимально.

Распределение нагрузки чтения (Read-scale)

Вторичные реплики могут быть настроены для обработки запросов только на чтение. Это позволяет разгрузить первичную реплику, перенаправив на вторичные реплики отчёты, аналитические запросы, резервное копирование и другие операции, не требующие записи. Для этого клиентские приложения должны использовать параметр ApplicationIntent=ReadOnly в строке подключения.

Резервное копирование

AG позволяет выполнять резервное копирование баз данных с вторичных реплик, не создавая нагрузки на первичную реплику. Это особенно важно для больших баз данных, где резервное копирование может занимать часы.

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

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

• Нулевая потеря данных при синхронном режиме и автоматическом переключении.
• Отсутствие единой точки отказа на уровне хранилища (в отличие от FCI).
• Возможность чтения с вторичных реплик — снижение нагрузки на первичную реплику.
• Гибкость — поддержка различных топологий (локальные, географические, гибридные).
• Интеграция с облаком — возможность создания реплик в Microsoft Azure или Amazon AWS.

Недостатки

• Сложность настройки и администрирования — требует глубоких знаний SQL Server, Windows Server, сетевых технологий и кластеризации.
• Зависимость от кворума — при неправильной настройке кворума возможна потеря доступности.
• Ограничения по версиям — расширенные возможности доступны только в Enterprise Edition.
• Задержки записи — в синхронном режиме увеличивается время выполнения транзакций.
• Требования к сети — низкая пропускная способность или высокая задержка между репликами могут сделать технологию неэффективной.

Критика

Основные критические замечания в адрес Always On групп доступности связаны с их сложностью. Для небольших организаций или проектов с ограниченным бюджетом на лицензирование (Enterprise Edition) и администрирование AG могут оказаться избыточными. В таких случаях более простыми и дешёвыми альтернативами являются зеркалирование баз данных (устаревшая технология) или репликация на уровне приложений.

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

Интересные факты

• Технология Always On групп доступности не является частью SQL Server Express Edition.
• В SQL Server 2017 и 2019 появилась поддержка AG в контейнерах Docker и Kubernetes.
• Распределённые группы доступности могут использоваться для миграции баз данных между версиями SQL Server без длительного простоя.
• В 2020 году Microsoft объявила, что Always On группы доступности будут поддерживаться в облачной службе Azure SQL Managed Instance.

Источники

• Microsoft Docs: Always On Availability Groups (SQL Server)
• SQL Server 2012 AlwaysOn Availability Groups: A Practical Guide — Microsoft Press
• Books Online for SQL Server 2019: Always On Availability Groups
• TechNet: Understanding Always On Availability Groups
• SQL Server 2022: What's New in Always On Availability Groups