Microsoft SQL Server Always On

Microsoft SQL Server Always On — это набор технологий и решений для обеспечения высокой доступности (High Availability, HA) и аварийного восстановления (Disaster Recovery, DR) для экземпляров и баз данных Microsoft SQL Server. Always On объединяет несколько функциональных возможностей, основными из которых являются отказоустойчивые кластеры экземпляров (Failover Cluster Instances, FCI) и группы доступности (Availability Groups, AG). Технология позволяет минимизировать время простоя при плановом обслуживании, аппаратных сбоях или сбоях программного обеспечения, а также обеспечивает защиту данных на уровне отдельных баз данных.

История и развитие

Технология Always On была впервые представлена корпорацией Microsoft в составе SQL Server 2012. До этого основным средством обеспечения высокой доступности в SQL Server были отказоустойчивые кластеры (SQL Server Failover Cluster), которые работали на уровне экземпляра и не обеспечивали гибкого управления отдельными базами данных. С появлением Always On корпорация предложила более продвинутое решение — группы доступности, которые позволяют реплицировать данные на уровне отдельных баз данных на несколько серверов (реплик) и выполнять отказоустойчивое переключение как на уровне экземпляра (FCI), так и на уровне базы данных (AG).

В последующих версиях SQL Server (2014, 2016, 2017, 2019, 2022) функциональность Always On постоянно расширялась. В SQL Server 2016 были добавлены распределенные группы доступности (Distributed Availability Groups), позволяющие создавать географически распределенные решения. В SQL Server 2017 появилась поддержка групп доступности в контейнерах Linux. В SQL Server 2019 была улучшена производительность синхронной репликации и добавлена возможность создания групп доступности без использования доменных служб Active Directory. В SQL Server 2022 были внедрены функции, такие как автоматическое переключение при сбое с использованием кворума в облачных сценариях и улучшенная поддержка Azure SQL Managed Instance.

Основные компоненты и архитектура

Отказоустойчивый кластер экземпляров (Failover Cluster Instance, FCI)

FCI — это решение на уровне экземпляра SQL Server, которое использует технологию отказоустойчивой кластеризации Windows Server (Windows Server Failover Cluster, WSFC). В FCI один экземпляр SQL Server устанавливается на нескольких узлах (серверах) кластера, но в каждый момент времени активен только один узел. Все узлы совместно используют общее хранилище (например, SAN или SMB-файловый сервер). При сбое активного узла кластерная служба автоматически переключает управление на другой узел, который подключается к тому же общему хранилищу и запускает SQL Server. Для клиентов это выглядит как перезапуск службы, но с минимальным временем простоя.

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

Группы доступности (Availability Groups, AG)

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

• Первичная реплика (Primary replica): Обрабатывает все операции чтения и записи. Клиенты подключаются к ней через специальный прослушиватель (listener).
• Вторичные реплики (Secondary replicas): Получают копии данных с первичной реплики. В зависимости от настроек, вторичные реплики могут быть доступны только для чтения (readable secondary) или могут использоваться для резервного копирования. В случае сбоя первичной реплики одна из вторичных реплик может быть переведена в роль первичной (ручное или автоматическое переключение).

• Преимущества: Высокая гибкость, возможность географического распределения, поддержка чтения с вторичных реплик (разгрузка первичной), отсутствие единого хранилища.
• Недостатки: Более сложная настройка и управление, требует лицензирования Enterprise Edition для использования более одной вторичной реплики (в Standard Edition — только две реплики: одна первичная и одна вторичная), ограниченная поддержка некоторых функций SQL Server (например, распределенных транзакций).

Режимы репликации

В группах доступности поддерживаются два основных режима репликации:

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

Прослушиватель (Listener)

Прослушиватель — это виртуальное сетевое имя (DNS-имя) и IP-адрес, которые клиенты используют для подключения к группе доступности. Прослушиватель автоматически перенаправляет запросы на текущую первичную реплику. При переключении (failover) прослушиватель обновляет свою привязку к новой первичной реплике, что делает процесс переключения прозрачным для клиентов.

Классификация и сценарии использования

По типу отказоустойчивости

• Автоматическое переключение (Automatic failover): Происходит без вмешательства администратора при сбое первичной реплики. Требуется синхронный режим репликации и наличие не менее двух реплик (включая первичную).
• Ручное переключение (Manual failover): Выполняется администратором вручную, например, для планового обслуживания. Может быть как с потерей данных (forced failover, для асинхронных реплик), так и без потери данных (planned failover, для синхронных реплик).

По географическому расположению

• Локальные решения (On-premises): Все реплики находятся в одном дата-центре или на одной площадке. Обычно используются для обеспечения высокой доступности в пределах одного здания.
• Географически распределенные решения (Geo-distributed): Реплики расположены в разных регионах или странах. Используются для аварийного восстановления при катастрофах (например, отключение электроэнергии, пожар, наводнение). В таких сценариях часто применяется асинхронный режим репликации.

По версии SQL Server

• Enterprise Edition: Поддерживает до 8 вторичных реплик (в SQL Server 2012 — до 4, в SQL Server 2016 — до 8), а также распределенные группы доступности, чтение с вторичных реплик и другие расширенные функции.
• Standard Edition: Поддерживает только одну вторичную реплику (так называемая «базовая группа доступности»). Ограничена в функциональности (например, нет поддержки распределенных групп доступности и автоматического переключения в некоторых сценариях).

Применение и значение

Технология Always On широко используется в корпоративных средах, где требуется высокая доступность баз данных. Основные сценарии применения:

• Банковские и финансовые системы: Обеспечение непрерывности операций, защита от потери данных.
• Электронная коммерция: Обеспечение доступности интернет-магазинов и платежных систем.
• ERP и CRM системы: Поддержка работы критически важных бизнес-приложений (например, Microsoft Dynamics 365, SAP).
• Географически распределенные компании: Обеспечение доступа к данным из разных регионов и аварийное восстановление.

Ограничения и критика

Несмотря на широкие возможности, Always On имеет ряд ограничений:

• Лицензирование: Для использования всех функций (более одной вторичной реплики, распределенные группы доступности) требуется лицензия SQL Server Enterprise Edition, которая значительно дороже Standard Edition.
• Сложность настройки: Настройка групп доступности требует глубоких знаний в области кластеризации Windows Server, сетевой инфраструктуры и управления SQL Server.
• Зависимость от сети: Для синхронной репликации требуется низкая задержка и высокая пропускная способность сети. В географически распределенных сценариях это может быть проблемой.
• Ограничения на уровне базы данных: Некоторые функции SQL Server (например, распределенные транзакции, Service Broker, FILESTREAM) не полностью поддерживаются в группах доступности.
• Потеря данных при асинхронной репликации: В случае сбоя первичной реплики при асинхронном режиме возможна потеря данных, что неприемлемо для некоторых критически важных систем.

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

• Технология Always On была разработана как ответ на решения конкурентов, такие как Oracle Data Guard и PostgreSQL Streaming Replication.
• В SQL Server 2016 была добавлена поддержка распределенных групп доступности, что позволило создавать каскадные конфигурации с несколькими уровнями репликации.
• Начиная с SQL Server 2017, Always On доступен также в версии для Linux, что расширяет возможности развертывания в гетерогенных средах.
• В SQL Server 2022 была внедрена функция «Contained Availability Groups», которая упрощает управление группами доступности в облачных сценариях, таких как Azure Arc.

Источники

• Microsoft Docs: «Always On Availability Groups (SQL Server)»
• Microsoft Docs: «Failover Cluster Instances (SQL Server)»
• «SQL Server 2012 AlwaysOn» — книга авторов Paul S. Randal, Robert Davis и др.
• «Pro SQL Server Always On Availability Groups» — книга автора Uttam Parui
• Технические блоги корпорации Microsoft (SQL Server Team Blog)