При отказе сервера базы данных бизнес-процессы останавливаются. Если ваш SQL Server работает на одиночной ноде, каждый час простоя — потерянная прибыль. Мы помогаем компаниям развернуть отказоустойчивый кластер 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
FCI требует Windows Server Failover Cluster WSFC и разделяемое хранилище, доступное всем нодам кластера. Варианты хранилища:
| Тип хранилища | Подходит для FCI | Примечание |
|---|---|---|
| Shared SAS / iSCSI SAN | Да | Классика, требует SAN-инфраструктуры |
| SMB 3.0 File Share | Да (с SQL 2012+) | Scale-Out File Server или NetApp CIFS |
| Azure Shared Disks | Да (в Azure VM) | Premium SSD v2 или Ultra Disk |
| Storage Spaces Direct (S2D) | Да | Встроенное в Windows Server 2016+ |
| Локальные диски разных нод | Нет | Не разделяемые — не работает |
Сетевые требования жёстче, чем кажутся: нужны минимум три сети — cluster heartbeat, SQL client traffic и отдельная сеть для iSCSI/SMB. Всё на одном адаптере приводит к split-brain при сетевых проблемах.
Типичные проблемы с сетью и хранилищем
- Неправильный heartbeat: если heartbeat-сеть настроена через маршрутизатор, возможен split-brain. Используйте прямые линки или отдельный VLAN.
- Отсутствие мультипаттинга: для iSCSI обязательно настроить MPIO, иначе один отказ сетевого адаптера на ноде может привести к потере доступа к диску.
- Несовместимость версий SQL Server: все ноды должны быть одной версии и build.
- Не настроены права на сетевые папки: для SMB шары нужно правильно настроить shared permissions и NTFS.
Настройка 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 до создания кластера. Обе ноды должны видеть один и тот же серийный номер диска.
Установка 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, поэтому класть его на общий диск бессмысленно и вредно для производительности.
-- После установки проверяем, что экземпляр видит обе ноды
SELECT NodeName, status_description FROM sys.dm_os_cluster_nodes;
-- Проверяем текущего владельца ресурсов
SELECT * FROM sys.dm_os_cluster_properties;Как тестировать 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 | Always On AG |
|---|---|---|
| Защита всего экземпляра | Да | Нет (только выбранные БД) |
| Требование shared storage | Да | Нет |
| Readable secondary | Нет | Да |
| RPO при отказе хранилища | Зависит от storage | 0 (с синхронной репликой) |
| Сложность настройки | Средняя | Высокая |
FCI — правильный выбор, когда: нужна защита всего экземпляра (агентные job’ы, linked servers, логины); уже есть SAN-инфраструктура; команде удобен WSFC; бюджет не позволяет держать полные копии данных на каждой ноде. Always On AG лучше, когда: нужен readable secondary для аналитики; нет общего хранилища; требуется RPO = 0 с нулевым риском storage failure. Можно комбинировать: FCI как реплика внутри AG — это даёт защиту и от отказа ноды, и от недоступности ДЦ.
Как мы внедряем FCI: процесс и гарантии
Наши инженеры имеют 10+ лет опыта в развёртывании кластеров SQL Server. Мы гарантируем RTO не более 60 секунд и RPO=0 для данных на общем хранилище. Внедрение включает:
- Аудит инфраструктуры: проверяем совместимость OS, SQL Server, storage и сети, проектируем топологию нод.
- Подготовку shared storage: размечаем диски, настраиваем iSCSI multipath.
- Установку WSFC и SQL FCI с верификацией каждого шага.
- Перенос баз данных с минимальным downtime (возможен mirroring).
- Тестирование failover (автоматическое и ручное), замер времени.
- Настройку мониторинга (Grafana + Prometheus или встроенные средства Windows).
- Подготовку документации и runbook для дежурной команды, обучение администраторов.
Сроки: базовая конфигурация из двух нод с одним shared LUN занимает около 5 дней с учётом подготовки хранилища. При миграции с нагруженного продакшн standalone срок может увеличиться до 2 недель из-за необходимости планового окна обслуживания. Точную оценку вы получите после аудита — свяжитесь с нашими инженерами.
Если вы сомневаетесь в выборе между FCI и Always On AG или хотите проверить готовность вашей инфраструктуры — закажите консультацию. Мы поможем спроектировать отказоустойчивое решение и защитим ваш бизнес от простоев.
