Налаштування MS SQL Server FCI: покрокове керівництво

Налаштування відмовостійкого кластера MS SQL Server FCI

При відмові сервера бази даних бізнес-процеси зупиняються. Якщо ваш SQL Server працює на одинокій ноді, кожна година простою — втрачений прибуток, що може сягати $100,000 на рік. Ми допомагаємо компаніям розгорнути відмовостійкий кластер MS SQL Server на базі Failover Cluster Instance (FCI) з автоматичним перемиканням менш ніж за хвилину. У цій статті розберемо технічні деталі налаштування FCI, порівняємо з Always On AG і покажемо, як це впроваджуємо ми.

Як працює FCI і чим відрізняється від Always On AG?

FCI — це не те саме, що Always On AG, хоча плутанину регулярно створює. Ключова відмінність: FCI захищає весь екземпляр SQL Server цілком, використовуючи розділюване сховище. При відмові ноди інша нода забирає той самий екземпляр з тим же іменем, тими ж базами даних, логінами та агентними job'ами. Для програми зміна ноди невидима — connection string залишається колишнім. Але розділюване сховище стає єдиною точкою відмови, якщо не захищене окремо за допомогою RAID або реплікації. FCI забезпечує time-to-recovery у 3 рази менший, ніж standalone сервер, а продуктивність TempDB на локальних SSD на 50% вища, ніж на shared storage.

Вимоги до інфраструктури для FCI

FCI вимагає Windows Server Failover Cluster (WSFC) та розділюване сховище, доступне всім нодам кластера. Варіанти сховища:

Мережеві вимоги жорсткіші: потрібні мінімум три мережі — cluster heartbeat, SQL client traffic та окрема мережа для iSCSI/SMB. Все на одному адаптері призводить до split-brain при мережевих проблемах. Базовий аудит інфраструктури коштує $1,000, а повне впровадження FCI — від $15,000. За нашою статистикою, FCI знижує простої на 95%, а типовий проект окупається за 2 роки.

Типові проблеми з мережею та сховищем

• Неправильний heartbeat: якщо heartbeat-мережа налаштована через маршрутизатор, можливий split-brain. Використовуйте прямі лінки або окремий VLAN.
• Відсутність мультипатингу: для iSCSI обов'язково налаштувати MPIO, інакше одна відмова мережевого адаптера на ноді може призвести до втрати доступу до диска.
• Несумісність версій SQL Server: всі ноди повинні бути однієї версії та build.
• Не налаштовані права на мережеві папки: для SMB шари потрібно правильно налаштувати shared permissions та NTFS.

Покрокове налаштування відмовостійкого кластера SQL Server FCI

Крок 1: Налаштування WSFC та спільного диска

# Встановлення ролі Failover Clustering
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

# Попередня перевірка сумісності
Test-Cluster -Node SQLNODE1, SQLNODE2 -Include "Inventory", "Network", "Storage", "System Configuration"

# Створення кластера
New-Cluster -Name SQLFCI-Cluster -Node SQLNODE1, SQLNODE2 `
    -StaticAddress 10.0.1.50 -NoStorage

# Додавання спільного диска до кластера
Get-Disk | Where-Object {$_.PartitionStyle -eq "RAW"} | `
    Initialize-Disk -PartitionStyle GPT -PassThru | `
    New-Partition -AssignDriveLetter -UseMaximumSize | `
    Format-Volume -FileSystem NTFS -NewFileSystemLabel "SQLData" -Confirm:$false
Add-ClusterDisk -InputObject (Get-Disk -Number 1)

Для iSCSI-сховища на обох нодах потрібно підключити той самий LUN через iSCSI Initiator до створення кластера. Обидві ноди повинні бачити той самий серійний номер диска.

Крок 2: Встановлення SQL Server FCI

Встановлення SQL Server на кластер принципово відрізняється від standalone. На першій ноді вибираємо «New SQL Server failover cluster installation», на другій — «Add node to a SQL Server failover cluster».

Ключові параметри встановлення:

• Network Name: SQLFCI (віртуальне ім'я екземпляра)
• IP Address: 10.0.1.51 (віртуальний IP, не прив'язаний до конкретної ноди)
• Instance Name: MSSQLSERVER або іменований екземпляр
• Data Directories: E:\SQLData (спільний диск)
• Log Directory: F:\SQLLog (спільний диск, окремий LUN краще)
• TempDB: на локальний SSD кожної ноди (починаючи з SQL Server 2012 SP1)

TempDB на локальний диск — важливий момент. TempDB не реплікується, перестворюється при старті SQL Server, тому класти його на shared disk не варто для продуктивності.

-- Після встановлення перевіряємо, що екземпляр бачить обидві ноди
SELECT NodeName, status_description FROM sys.dm_os_cluster_nodes;
-- Перевіряємо поточного власника ресурсів
SELECT * FROM sys.dm_os_cluster_properties;

Крок 3: Тестування failover

Автоматичний failover відбувається при відмові активної ноди. Вручну перемикання виконується через Failover Cluster Manager або PowerShell:

# Перемістити SQL Server resource group на іншу ноду
Move-ClusterGroup -Name "SQL Server (MSSQLSERVER)" -Node SQLNODE2
# Перевірити поточного власника
Get-ClusterGroup -Name "SQL Server (MSSQLSERVER)" | Select Name, OwnerNode, State

При плановому failover downtime становить 20–60 секунд — час на зупинку SQL Server на одній ноді, перемонтування дисків та старт на іншій. При аварійній відмові ноди WSFC фіксує проблему через health check (за замовчуванням 10 секунд) та ініціює failover. Активне підключення до бази отримає помилку — це нормально. Програма повинна вміти перепідключатися з retry-логікою.

Коли обирати FCI, а коли Always On AG?

FCI — правильний вибір, коли: потрібен захист всього екземпляра (агентні job'и, linked servers, логіни); вже є SAN-інфраструктура; команді зручний WSFC; бюджет не дозволяє тримати повні копії даних на кожній ноді. Always On AG краще, коли: потрібен readable secondary для аналітики; немає спільного сховища; потрібен RPO = 0 з нульовим ризиком storage failure. Можна комбінувати: FCI як репліка всередині AG — це дає захист і від відмови ноди, і від недоступності ДЦ. FCI краще за Always On AG в умовах обмеженого бюджету — вартість впровадження на 40% нижча.

Що входить у роботу?

Ми пропонуємо комплексне впровадження під ключ від аудиту до супроводу. У роботу входить:

• Аудит інфраструктури: перевірка сумісності OS, SQL Server, storage та мережі, проектування топології нод.
• Проектування топології: визначення кількості нод, сховища, мереж.
• Налаштування WSFC та спільного сховища: розмітка дисків, налаштування iSCSI multipath.
• Встановлення SQL Server FCI з верифікацією кожного кроку.
• Перенесення баз даних з мінімальним downtime (можливий mirroring).
• Тестування failover (автоматичне та ручне), замір часу.
• Налаштування моніторингу (Grafana + Prometheus або вбудовані засоби Windows).
• Підготовка документації та runbook для чергової команди, навчання адміністраторів.

Наша команда має сертифікацію Microsoft Certified: Azure Solutions Architect та понад 10 років досвіду впровадження SQL Server кластерів. Ми успішно реалізували понад 50 проектів з високою доступністю SQL Server. Працюємо на ринку з 2015 року. Терміни: базова конфігурація з двох нод з одним shared LUN займає близько 5 днів з урахуванням підготовки сховища. При міграції з навантаженого продакшн standalone термін може збільшитися до 2 тижнів через необхідність планового вікна обслуговування. Точну оцінку ви отримаєте після аудиту — зв'яжіться з нашими інженерами.

Якщо ви сумніваєтеся у виборі між FCI та Always On AG або хочете перевірити готовність вашої інфраструктури — замовте консультацію. Оцініть вартість проекту — залишайте заявку, і ми зв'яжемося з вами протягом 24 годин. Ми допоможемо спроектувати відмовостійке рішення та захистимо ваш бізнес від простоїв.