В классической архитектуре отказоустойчивого кластера на Windows Server в состав кластера входит два или более хостов (нод) с Windows Server, которые подключены к общему хранилищу (не обязательно требование сейчас). Такие кластеры используются для обеспечения высокой доступности и отказоустойчивости различных сервисов:
- Виртуальных машин Hyper-V
- Баз данных MS SQL Server
- Файловых (SMB) серверов и серверов печати
- Отказоустойчивости баз данных почтовых ящиков Exchange Server (Database Availability Group, DAG)
- Программно-определяемых хранилищ Storage Spaces Direct (S2D)
В этой статье мы рассмотрим, как настроить простой двух-нодовый кластер высокой доступности на базе роли Failover Clustering (WSFC) в Windows Server 2025/2022/2019 и запустим на нем простой файловый сервер в отказоустойчивом режиме.
Базовая настройка Failover Cluster в Windows Server
Базовые требовании при планировании кластера:
- Обе ноды должны иметь одинаковую версию Windows Server с одинаковым набором обновлений
- Для большинства кластеризуемых сервисов достаточно редакции Standard. Перед развертыванием нужно проверить требования сервиса, который нужно кластеризовать. Например, для S2D нужен Datacenter.
- Сервера должны быть схожи по аппаратной конфигурации
- Сервера должны быть подключены к общему хранилищу (не обязательно для некоторых конфигураций): это могут быть диски (LUN), подключенные по FC (через SAN сеть), iSCSI диски, RDM или shared VMDK в VMware ESXi и т.д.
- Рекомендуется использовать отдельные сетевые адаптеры для клиентского (производственного) трафика, для кластерных коммуникаций (heartbeat), iSCSI/SAN сети (если общее хранилище подключено по Ethernet). Для удобства идентификации сетевых адаптеров кластера, переименуйте их в соответствии с профилем использования. Например:
Get-NetAdapter
Rename-NetAdapter -Name "Ethernet0" -NewName "Domain0"
Rename-NetAdapter -Name "Ethernet1" -NewName "iSCSI" - Используйте статические IP адреса на всех узлах кластера. Для сетевых адаптеров, которые не используются клиентами напрямую, отключите регистрацию в DNS
- Должно быть одинакое время на всех хостах кластера (в случае AD хосты автоматически синхронизируют время с источников времени на DC).
В этом примере мы используем два хоста с Windows Server 2025, добавленные в домен Active Directory (начиная с Windows Server 2016 для некоторых сценариев можно создавать кластер между серверами в рабочей группе, без домена):
Node1: w-fs01.winitpro.ru – Windows Server 2025, IP: 192.168.158.100
Node2: w-fs02.winitpro.ru — Windows Server 2025, IP: 192.168.158.101
К обоим серверам подключены общие диски (LUNы) – один LUN это диск-свидетель для кворума, второй LUN с данными файлового сервера (в целях упрощения демонстрации это iSCSI диски с другого хоста Windows Server).
Предполагаем, что кластерный диск, который будет использоваться для Disk Witness (достаточно 1 Гб диска) уже презентован обоим хостам. Откройте консоль управления дисками (
diskmgmt.msc
) на одном из узлов, инициализируйте диск, создайте раздел.
На второй ноде этот диск должен быть виден, но оставаться в офлайне.
На обоих нодах добавляем роль Failover Clustering из PowerShell или через Server Manager:
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Также установите компонент Multipath I/O (MPIO): MPIO позволяет использовать несколько физических путей для доступа к одному устройству хранения, например, SAN или iSCSI (может потребоваться дополнительная настройка):
Install-WindowsFeature Multipath-IO
Запускаем консоль управления кластером Failover Cluster Manager (
cluadmin.msc
), выбираем что хотим создать кластер и добавляем ноды, из которых будет состоять кластер.
При первом запуске желательно выполнить валидацию кластера. Мастер создания кластера выполнит ряд тестов на готовность указанных хостов к добавлению в Failover Cluster. Дождитесь окончания тестирования, изучите ошибки и предупреждений в отчете (поправьте конфигурацию хостов, если нужно).
Также проверить, готовы ли хосты для добавления в кластер, можно из PowerShell:
Test-Cluster -Node w-fs01,w-fs02
Если валидация прошла успешно, укажите имя для кластера и его IP адрес (адрес должен быть свободен).
Либо вы можете собрать кластер из двух нод с помощью PowerShell:
New-Cluster -Name w-cl01 -Node w-fs01,w-fs02 -StaticAddress 192.168.158.50
В консоли Failover Cluster Manager должен появится ваш кластер. Разверните секцию Nodes и проверьте, что оба хоста активы и запущены.
В нашем случае в кластере всего два узла. В WSFC с четным количеством узлов нужно добавить кластерный ресурс – свидетель. Это нужно, чтобы кластер при отказе одного или нескольких узлов мог продолжить работы за счет кворума голосов и избегания ситуации split-brain.
Щелкаем по кластеру и выбираем More Actions -> Configure Cluster Quorum Settings.
Выбираем тип свидетеля кворумы – disk witness.
Выбираем ранее презентованный небольшой диск.
Теперь в описании кластера видно, что в качестве свидетеля используется Cluster Disk 1 (переименуйте его в Quorum диск для удобства).
После этого вы можете добавлять в кластер роли высокой доступности. Например, файловый сервер, SQL Server, DNS, виртуальные машины Hyper-V, другие службы, которые автоматически будут переходить на другой узел при сбое первого.
Запускаем файловый сервер (SMB) в кластере
Теперь добавим в кластер роль File Server, чтобы создать простой отказоустойчивый файловый сервер общего назначения.
Добавляем в кластер диск, на котором будут хранится файлы файлового сервера (диск должен быть презентован/доступен всем нодам).
Устанавливаем на ноды роль файлового сервера (если еще не сделали ранее). Быстрее всего установить компоненты Windows Server с помощью PowerShell:
Install-WindowsFeature FS-FileServer -IncludeManagementTools
Затем создаем роль файлового сервера в кластере и собственно сетевые папки:
- В Failover Cluster Manager выберите Roles -> Configure Role
- В качестве кластерной роли добавьте File Server
- В WS2025 доступно два типа кластеризованного файлового сервиса – файловый сервер для общего использования и Scale-Out File Server (SOFS). Последний в основном предназначен для приложения и виртуальных машин. Выбираем File Serer for General use
- Осталось указать имя файлового кластера и его IP (будут использоваться для доступа к файлам клиентами).
- Добавляем в файловый кластер диск, где будут хранится файлы.
После этого в кластерном файловом сервере можно создавать сетевые папки. Однако в консоли видно, что кластерный ресурс не запускается с ошибками:
Cluster resource 'cl-FS' of type 'Network Name' in clustered role 'cl-FS' failed. The error code was '0x5' ('Access is denied.'). Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it. Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.
Причина в том, что мастер не может создать для файлового сервера учетную запись в AD. Поэтому открываем консоль ADUC (
dsa.msc
) и создает объект типа computer с именем файлового кластера вручную.
Затем в настройках аккаунта на вкладке безопасность даем полные права на аккаунт компьютера кластерной учетной записи.
После этого роль файлового сервера в кластере можно запустить вручную (Start role).
Теперь моно создать сетевую папку в кластере:
- Щелкаете по кластеру и выбираете Add File Share
- Тип файлового ресурса — SMB Share Quick
- Укажите имя сетевой папки
- Далее можно настроить права доступа. Все как с настройкой обычной сетевой папки в Windows.
- В настройках папки можно включить дополнительные опции Access based enumaration, офлайн кэширование файлов (автономные файлы) и continious availability (возможность прозрачного переподключения SMB 3.0 клиентов к папке при перезде службы файлового сервера между нодами; не поддерживается в более старых версиях SMB)
После того, как вы создали файловую шару, проверьте что она доступа с клиентов по UNC пути. Например
\\cl-FS\public
Теперь если выключить одну из нод, или перевести в режим Drain, файловая служба автоматически перезапускается на оставшейся ноде и подключение к ней не теряется у клиентов.
Насколько я знаю, режим Node + Disk Majority для кворума это устаревший в 2025 году вариант. Лучше Node + File Share Majority (с witness в виде папке на любом сервере за пределом кластера). тупо проще администрируется.