Налаштування 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 з 2 хвилин до 30 секунд завдяки оптимізації кворуму та налаштуванню ліснера. Якщо ви зіткнулися з проблемами failover або хочете спроєктувати відмовостійку архітектуру, замовте аудит інфраструктури.

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