Настройка MS SQL Server Always On Availability Groups

Мы проектируем и внедряем Always On AG для клиентов с нуля. На практике первая проблема при самостоятельной настройке: кластер WSFC поднят, SQL Server установлен на обеих нодах, AG создана — но автоматического failover не происходит. Причина чаще всего в неправильно настроенных кворумных голосах или в том, что SQL Server Agent на secondary реплике не следит за health state листенера. А потом оказывается, что приложение использует connection string с именем сервера напрямую. Мы гарантируем, что после нашего внедрения таких сюрпризов не будет. Получите консультацию инженера для аудита вашей инфраструктуры.

Почему failover не работает? — настройка ms sql

Самые частые причины: кворум не настроен (не хватает witness), secondary реплика не в синхронном режиме, или листенер не добавлен. WSFC ожидает голоса от всех участников, и при потере одной ноды кластер может остановиться, если witness отсутствует. Решение — используйте Cloud Witness (Azure Blob Storage) или file share witness.

Как настроить кворум и листенер?

Сначала создаём WSFC с параметром -NoStorage, затем добавляем witness. Cloud Witness настраивается через Set-ClusterQuorum. После этого листенер создаётся как виртуальный IP с DNS-записью — приложение подключается к нему, а не к ноде напрямую. Connection string для .NET клиентов обязательна с MultiSubnetFailover=True. Подробнее об архитектуре можно прочитать в документации по Always On Availability Groups.

Синхронный режим даёт zero data loss, но асинхронный быстрее на 30–50% — подходит для географически удалённых реплик.

Что такое direct seeding и как он упрощает инициализацию?

Direct seeding — автоматическая инициализация secondary реплики без ручного бэкапа и восстановления. SQL Server сам переносит данные через endpoint. Это удобно для небольших баз (до 200–300 ГБ), но для больших БД может потребоваться время. В таких случаях лучше использовать ручной seed через SMB или бэкап/восстановление.

Как работает AG под капотом?

Always On AG работает поверх WSFC. Каждая нода получает голос, witness добавляет третий голос для кворума. На уровне баз данных AG использует группы доступности с одной primary и несколькими secondary репликами. Для автоматического failover реплики должны быть в синхронном режиме, а WSFC — работоспособен.

Подготовка WSFC и SQL Server

Перед созданием кластера проверьте совместимость нод: одинаковые версии Windows, один домен AD, отдельные сетевые адаптеры для heartbeat, SQL и клиентского трафика. Создание кластера без общего хранилища:

Test-Cluster -Node SQL01, SQL02 -Include "Inventory","Network","Storage"
New-Cluster -Name SQLCLUSTER -Node SQL01, SQL02 -StaticAddress 10.0.1.10 -NoStorage
Set-ClusterQuorum -CloudWitness -AccountName "sqlwitness" -AccessKey "base64key=="

Включите Always On на каждой ноде:

Enable-SqlAlwaysOn -ServerInstance "SQL01" -Force Enable-SqlAlwaysOn -ServerInstance "SQL02" -Force 

Создание Availability Group

База данных перед добавлением должна быть в FULL recovery model и иметь полный бэкап. Используйте direct seeding для автоматической инициализации:

CREATE AVAILABILITY GROUP [AG_Production]
WITH
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    FAILURE_CONDITION_LEVEL = 3,
    HEALTH_CHECK_TIMEOUT = 30000
FOR DATABASE [AppDB], [AuditDB]
REPLICA ON
    N'SQL01' WITH
        ENDPOINT_URL = N'TCP://SQL01.corp.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = NO),
    N'SQL02' WITH
        ENDPOINT_URL = N'TCP://SQL02.corp.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY);
ALTER AVAILABILITY GROUP [AG_Production]
ADD LISTENER N'AG-Listener' (WITH IP ((N'10.0.1.20', N'255.255.255.0')), PORT = 1433);

На secondary выполните:

ALTER AVAILABILITY GROUP [AG_Production] JOIN; ALTER AVAILABILITY GROUP [AG_Production] GRANT CREATE ANY DATABASE; 

Read-scale routing

Для аналитики на secondary настройте routing list:

ALTER AVAILABILITY GROUP [AG_Production] MODIFY REPLICA ON N'SQL01' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = (N'SQL02')));
ALTER AVAILABILITY GROUP [AG_Production] MODIFY REPLICA ON N'SQL02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL02.corp.local:1433'));

Типичные проблемы при эксплуатации

• Дрейф синхронизации: если secondary показывает SYNCHRONIZING, проверьте sys.dm_hadr_database_replica_states. Поле log_send_queue_size укажет отставание. Причины — перегрузка сети или тяжёлые транзакции.
• Failout без переключения: приложение держит пул подключений к SQL01 — после failover запросы падают. Решение — только листенер и MultiSubnetFailover=True.
• Backup на secondary: настройте job'ы с проверкой sys.fn_hadr_backup_is_preferred_replica(), иначе бэкап будет на всех нодах или ни на одной.

Что входит в работу?

• Аудит текущей инфраструктуры и проектирование топологии AG.
• Развёртывание WSFC с кворумом (witness) и включение Always On.
• Создание AG с direct seeding, настройка листенера и read-scale routing.
• Тестирование failover под нагрузкой с замером RTO (обычно менее 30 сек).
• Документация runbook'ов и обучение вашей команды.
• Гарантия настройки и сопровождение в течение месяца после внедрения.

Наш опыт — более 8 лет в DevOps и SQL Server, более 50 проектов по Always On AG. Если вы столкнулись с проблемами failover или хотите спроектировать отказоустойчивую архитектуру, закажите аудит инфраструктуры.

Сроки: от 3 до 5 дней для стандартной конфигурации (2 ноды, до 10 БД). При DR-реплике в другом ЦОДе — до 2 недель. Стоимость рассчитывается индивидуально после аудита. Получите отказоустойчивость на уровне enterprise — свяжитесь с нами для консультации.