Простой 1С стоил миллионы: отказоустойчивый кластер для бухгалтерской фирмы

Вот что вошло в архитектуру кластера, которую мы спроектировали для этого клиента:

• Узлы кластера (Nodes): 2 идентичных физических сервера Dell PowerEdge R740 — основной и резервный. Идентичность конфигурации здесь принципиальна
• Общее хранилище (Shared Storage): iSCSI-хранилище на отдельном сервере с дисковой полкой — доступно обоим узлам одновременно
• Кластерная сеть (Cluster Network): выделенные 10 Гбит/с сетевые адаптеры для heartbeat-трафика между узлами
• Кворум (Quorum): механизм голосования с disk witness — определяет, какой узел управляет кластером при разделении сети
• Кластерные роли (Clustered Roles): файловый сервер, Hyper-V для виртуальных машин с 1С, SQL Server
• Свидетель (Witness): выделенный диск — даёт третий голос в кворуме и помогает кластеру принять решение при разделении сети

Под этот проект мы подбирали железо аккуратно — с запасом по производительности, но без излишеств. Вот что в итоге получилось:

Серверы (2 шт.):

• Dell PowerEdge R740 с идентичной конфигурацией на обоих узлах
• Windows Server 2022 Datacenter edition — только она даёт все возможности кластеризации
• Оба сервера введены в домен Active Directory
• 4 сетевых адаптера на каждом узле: клиентская сеть, heartbeat, iSCSI и управление — всё разнесено по разным интерфейсам

Хранилище:

• Отдельный сервер с iSCSI Target и дисковой полкой
• 3 LUN: данные (500 ГБ SSD), файлы (2 ТБ HDD), свидетель кворума (1 ГБ)

Сеть:

• Выделенная 10 Гбит/с подсеть для heartbeat — смешивать с клиентским трафиком категорически не стоит
• Выделенная iSCSI-сеть
• Статические IP-адреса для всех узлов — с DHCP в кластере лучше не экспериментировать

На каждом узле — четыре сетевых интерфейса, каждый под свою задачу. Смешивать трафик в одну кучу мы не стали. Конфигурация получилась такая:

# На каждом узле мы выполнили:

# 1. Переименование сетевых адаптеров
Rename-NetAdapter -Name 'Ethernet 1' -NewName 'Production'
Rename-NetAdapter -Name 'Ethernet 2' -NewName 'Heartbeat'

# 2. Настройка IP-адресов
# Узел 1 - Production
New-NetIPAddress -InterfaceAlias 'Production' -IPAddress 10.0.1.11 `
    -PrefixLength 24 -DefaultGateway 10.0.1.1
Set-DnsClientServerAddress -InterfaceAlias 'Production' `
    -ServerAddresses 10.0.1.5, 10.0.1.6

# Узел 1 - Heartbeat (без шлюза и DNS!)
New-NetIPAddress -InterfaceAlias 'Heartbeat' -IPAddress 192.168.100.11 `
    -PrefixLength 24

# 3. Отключение регистрации DNS для heartbeat-сети
Set-DnsClient -InterfaceAlias 'Heartbeat' -RegisterThisConnectionsAddress $false

# 4. Настройка приоритета адаптеров
Set-NetIPInterface -InterfaceAlias 'Production' -InterfaceMetric 10
Set-NetIPInterface -InterfaceAlias 'Heartbeat' -InterfaceMetric 20

Схема сети, которую мы реализовали:

  [500 пользователей 1С]     [DNS/AD]
      |                         |
  ----+---Production Network (10.0.1.0/24)---+---
      |                                       |
  [Node1: 10.0.1.11]                  [Node2: 10.0.1.12]
      |                                       |
  ----+---Heartbeat Network (192.168.100.0/24)+---
      |                                       |
  ----+--------iSCSI Network (172.16.0.0/24)--+---
                        |
                  [iSCSI Storage]
                  [SSD + HDD JBOD]

Для общего хранилища выбрали iSCSI — надёжно, доступно по цене, хорошо знакомо нашим инженерам. Настраивали в два этапа: сначала Target на сервере хранения, потом Initiator на каждом узле.

На сервере хранения (iSCSI Target):

# Установка роли iSCSI Target Server
Install-WindowsFeature FS-iSCSITarget-Server -IncludeManagementTools

# Создание iSCSI Target
New-IscsiServerTarget -TargetName 'ClusterTarget' `
    -InitiatorIds @(
        'IQN:iqn.1991-05.com.microsoft:node1.company.ru',
        'IQN:iqn.1991-05.com.microsoft:node2.company.ru'
    )

# Создание виртуальных дисков
New-IscsiVirtualDisk -Path 'D:\iSCSI\ClusterData.vhdx' -SizeBytes 500GB
New-IscsiVirtualDisk -Path 'D:\iSCSI\ClusterWitness.vhdx' -SizeBytes 1GB

# Подключение дисков к Target
Add-IscsiVirtualDiskTargetMapping -TargetName 'ClusterTarget' `
    -Path 'D:\iSCSI\ClusterData.vhdx' -Lun 0
Add-IscsiVirtualDiskTargetMapping -TargetName 'ClusterTarget' `
    -Path 'D:\iSCSI\ClusterWitness.vhdx' -Lun 1

На каждом узле кластера (iSCSI Initiator):

# Запуск службы iSCSI Initiator
Start-Service MSiSCSI
Set-Service MSiSCSI -StartupType Automatic

# Подключение к iSCSI Target
New-IscsiTargetPortal -TargetPortalAddress 172.16.0.100
Connect-IscsiTarget -NodeAddress 'iqn.1991-05.com.microsoft:clustertarget' `
    -IsPersistent $true

# Проверка подключения
Get-IscsiSession | Format-Table -AutoSize
Get-Disk | Where-Object BusType -eq iSCSI | Format-Table

Инициализация дисков (только на первом узле!):

# Определяем iSCSI-диски
$disks = Get-Disk | Where-Object { $_.BusType -eq 'iSCSI' -and $_.PartitionStyle -eq 'RAW' }

# Инициализация и форматирование диска данных
$dataDisk = $disks | Sort-Object Size -Descending | Select-Object -First 1
Initialize-Disk -Number $dataDisk.Number -PartitionStyle GPT
New-Partition -DiskNumber $dataDisk.Number -UseMaximumSize -AssignDriveLetter |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'ClusterData' -Confirm:$false

# Инициализация диска свидетеля
$witnessDisk = $disks | Sort-Object Size | Select-Object -First 1
Initialize-Disk -Number $witnessDisk.Number -PartitionStyle GPT
New-Partition -DiskNumber $witnessDisk.Number -UseMaximumSize -AssignDriveLetter |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Witness' -Confirm:$false

На обоих узлах установили компонент Failover Clustering. Без этого дальше идти некуда:

# Установка на обоих узлах через Invoke-Command
$nodes = @('NODE1', 'NODE2')
Invoke-Command -ComputerName $nodes -ScriptBlock {
    Install-WindowsFeature Failover-Clustering -IncludeManagementTools
}

# Перезагрузка узлов
$nodes | ForEach-Object { Restart-Computer -ComputerName $_ -Force }

Перед созданием кластера — обязательная полная валидация. Это не формальность. Microsoft прямо говорит: нет валидации — нет поддержки:

# Полная валидация конфигурации
Test-Cluster -Node NODE1, NODE2 -Include 'Storage','Network','Inventory','System Configuration'

# Отчёт сохраняется в C:\Windows\Cluster\Reports
# Все тесты прошли со статусом "Passed"!

Важно: если что-то пойдёт не так и вы обратитесь в Microsoft, первое, что они спросят — результаты Test-Cluster. Кластеры без пройденной валидации просто не поддерживаются. Мы прогнали все тесты до единого и убедились, что всё чисто.

Кластер создавали через PowerShell — так воспроизводимо и без сюрпризов:

# Создание кластера
New-Cluster -Name 'CLUSTER01' `
    -Node NODE1, NODE2 `
    -StaticAddress 10.0.1.20 `
    -NoStorage

# Проверка создания
Get-Cluster | Format-List *
Get-ClusterNode | Format-Table Name, State, NodeWeight

# Добавление дисков в кластер
Get-ClusterAvailableDisk | Format-Table Name, Size
Get-ClusterAvailableDisk | Add-ClusterDisk

# Проверка кластерных дисков
Get-ClusterResource | Where-Object ResourceType -eq 'Physical Disk' |
    Format-Table Name, State, OwnerNode

Для двух узлов выбрали режим Node and Disk Majority. Каждый узел голосует, диск-свидетель добавляет третий голос — итого нечётное число, кластер всегда может принять решение:

# Настройка кворума с диск-свидетелем
Set-ClusterQuorum -DiskWitness 'Cluster Disk 2'

# Проверка настроек кворума
Get-ClusterQuorum | Format-List *

Windows Server 2022 поддерживает четыре режима кворума — под каждую конфигурацию свой:

• Node Majority: голосуют только узлы — работает, если их нечётное количество
• Node and Disk Majority: голоса узлов плюс диск-свидетель — именно этот режим мы выбрали для схемы из 2 узлов
• Node and File Share Majority: голоса узлов плюс файловый ресурс в качестве свидетеля
• Node and Cloud Majority (Azure): голоса узлов плюс облачный свидетель — актуально, если часть инфраструктуры уже в Azure

Бухгалтерия накапливает горы документов: сканы договоров, квартальные отчёты, шаблоны. Для всего этого мы подняли кластерный файловый сервер:

# Создание роли файлового сервера
Add-ClusterFileServerRole -Name 'FS-CLUSTER' `
    -Storage 'Cluster Disk 1' `
    -StaticAddress 10.0.1.21

# Создание общей папки на кластерном диске
$clusterDisk = Get-ClusterResource 'Cluster Disk 1' |
    Get-ClusterParameter DiskPath | Select-Object -ExpandProperty Value

New-Item -Path "$clusterDisk\Shared" -ItemType Directory
New-SmbShare -Name 'Shared' -Path "$clusterDisk\Shared" `
    -FullAccess 'COMPANY\Domain Admins' `
    -ChangeAccess 'COMPANY\Domain Users' `
    -CachingMode None `
    -ScopeName 'FS-CLUSTER'

# Проверка доступности
Get-SmbShare -ScopeName 'FS-CLUSTER'

Виртуальным машинам 1С нужно кое-что особенное. Мы подняли отдельный Scale-Out File Server — он отдаёт хранилище сразу нескольким узлам Hyper-V без конфликтов:

# Создание Scale-Out File Server
Add-ClusterScaleOutFileServerRole -Name 'SOFS-CLUSTER'

# Создание Cluster Shared Volume
Add-ClusterSharedVolume -Name 'Cluster Disk 1'

# Диск доступен на всех узлах: C:\ClusterStorage\Volume1

New-SmbShare -Name 'VMDATA' `
    -Path 'C:\ClusterStorage\Volume1\VMDATA' `
    -FullAccess 'COMPANY\Domain Admins' `
    -ScopeName 'SOFS-CLUSTER'

Сам сервер 1С:Предприятие живёт внутри виртуальной машины Hyper-V с высокой доступностью. Live Migration работает — обслуживаем узел, пользователи ничего не замечают:

# Установка Hyper-V на обоих узлах
Invoke-Command -ComputerName NODE1, NODE2 -ScriptBlock {
    Install-WindowsFeature Hyper-V -IncludeManagementTools -Restart
}

# Настройка Hyper-V после перезагрузки
Invoke-Command -ComputerName NODE1, NODE2 -ScriptBlock {
    New-VMSwitch -Name 'Production' -NetAdapterName 'Production' `
        -AllowManagementOS $true

    Set-VMHost -VirtualMachinePath 'C:\ClusterStorage\Volume1\VMs' `
              -VirtualHardDiskPath 'C:\ClusterStorage\Volume1\VHDs'
}

# Создание ВМ для сервера 1С
$vmName = '1C-SERVER-01'
New-VM -Name $vmName -ComputerName NODE1 `
    -MemoryStartupBytes 16GB `
    -NewVHDPath "C:\ClusterStorage\Volume1\VHDs\$vmName.vhdx" `
    -NewVHDSizeBytes 200GB `
    -SwitchName 'Production' `
    -Generation 2

Set-VM -Name $vmName -ComputerName NODE1 `
    -ProcessorCount 8 `
    -DynamicMemory -MemoryMinimumBytes 8GB -MemoryMaximumBytes 32GB

# Добавление ВМ в кластер — включение HA
Add-ClusterVirtualMachineRole -VMName $vmName

# Проверка кластеризованных ВМ
Get-ClusterGroup | Where-Object GroupType -eq VirtualMachine |
    Format-Table Name, State, OwnerNode

# Live Migration — перемещение без простоя
Move-ClusterVirtualMachineRole -Name $vmName -Node NODE2 -MigrationType Live

База данных 1С — это SQL Server Failover Cluster Instance (FCI). Здесь цена ошибки максимальная, поэтому готовились основательно:

Подготовка, которую мы провели:

• Установили .NET Framework 4.8 на каждом узле — без этого установщик SQL просто не пойдёт дальше
• Создали в AD сервисные учётки COMPANY\svc-sql и COMPANY\svc-sqlagent — под каждую службу своя, никакого «всё под одним пользователем»
• Под Data, Log и TempDB — отдельные кластерные диски. Смешивать их на одном LUN мы не стали: производительность и изоляция отказов важнее экономии на дисках

# Проверка дисков для SQL Server
Get-ClusterResource | Where-Object ResourceType -eq 'Physical Disk' |
    Get-ClusterParameter DiskPath |
    Format-Table ClusterObject, Value

Как мы устанавливали SQL Server FCI — шаг за шагом:

• Шаг 1. На NODE1 запускаем setup.exe и выбираем New SQL Server failover cluster installation — именно эту ветку, не обычную установку
• Шаг 2. Имя экземпляра: SQL-CLUSTER, виртуальный IP: 10.0.1.22 — клиенты 1С будут ходить именно на него
• Шаг 3. Назначаем кластерные диски: Data, Log и TempDB на свои тома
• Шаг 4. Дожидаемся завершения установки на первом узле — не торопимся, смотрим лог
• Шаг 5. На NODE2 выбираем Add node to SQL Server failover cluster — и второй узел подхватывает экземпляр

Прогнали все сценарии, которые реально случаются в жизни:

# 1. Плановое перемещение роли между узлами
Move-ClusterGroup -Name 'FS-CLUSTER' -Node NODE2

# 2. Имитация отказа узла
Stop-ClusterNode -Name NODE1

# Проверяем, что роли переехали на NODE2
Get-ClusterGroup | Format-Table Name, State, OwnerNode

# Возвращаем NODE1
Start-ClusterNode -Name NODE1

# 3. Тестирование Live Migration для ВМ с 1С
$vms = Get-ClusterGroup | Where-Object GroupType -eq VirtualMachine
foreach ($vm in $vms) {
    $targetNode = if ($vm.OwnerNode -eq 'NODE1') {'NODE2'} else {'NODE1'}
    Write-Host "Мигрируем $($vm.Name) на $targetNode..."
    Move-ClusterVirtualMachineRole -Name $vm.Name -Node $targetNode -MigrationType Live
    Start-Sleep -Seconds 5
}

# 4. Проверка журналов кластера
Get-ClusterLog -Destination C:\Temp\ClusterLogs -TimeSpan 60

Что получили по итогам: файловый сервер переключился за 12 секунд. Live Migration виртуалки с 1С — пользователи вообще не почувствовали. SQL Server FCI — 45 секунд, клиенты 1С переподключились автоматически.

Из нашей практики: раз в квартал, в плановое окно обслуживания, гоняйте failover руками и записывайте время переключения. Если оно начало расти — что-то меняется в инфраструктуре, и лучше разобраться до реального инцидента.

Настроили скрипт, который постоянно смотрит на состояние кластера и сигналит раньше, чем проблема дорастёт до инцидента:

# Скрипт мониторинга кластера — разработан АйТи Фреш
$clusterName = 'CLUSTER01'

Write-Host '--- Узлы кластера ---' -ForegroundColor Cyan
Get-ClusterNode -Cluster $clusterName |
    Format-Table Name, State, NodeWeight, DynamicWeight

Write-Host '--- Кластерные роли ---' -ForegroundColor Cyan
Get-ClusterGroup -Cluster $clusterName |
    Format-Table Name, State, OwnerNode, Priority

Write-Host '--- Ресурсы с проблемами ---' -ForegroundColor Cyan
Get-ClusterResource -Cluster $clusterName |
    Where-Object State -ne 'Online' |
    Format-Table Name, State, ResourceType, OwnerNode

Write-Host '--- Кластерные сети ---' -ForegroundColor Cyan
Get-ClusterNetwork -Cluster $clusterName |
    Format-Table Name, State, Role, Address

Write-Host '--- Кворум ---' -ForegroundColor Cyan
Get-ClusterQuorum -Cluster $clusterName | Format-List

Write-Host '--- Последние события ---' -ForegroundColor Cyan
Get-WinEvent -LogName 'Microsoft-Windows-FailoverClustering/Operational' `
    -MaxEvents 20 | Where-Object Level -le 3 |
    Format-Table TimeCreated, LevelDisplayName, Message -Wrap

Грабли, на которые наступают чаще всего — предупредили клиента заранее:

• Узел в состоянии «Down»: первым делом — сетевая связность, потом служба ClusSvc, потом журналы событий. Именно в таком порядке
• Ресурс «Failed»: смотрим зависимости — обычно упал зависимый ресурс, а не сам сервис. Пробуем перезапуск, но сначала понимаем причину
• Split-brain: классика при потере heartbeat — оба узла считают себя владельцем ресурсов. Именно поэтому мы с самого начала вынесли heartbeat в отдельную сеть и поставили disk witness
• Медленный failover: почти всегда дело в таймаутах ресурсов — смотрим настройки, часто там стоят значения по умолчанию, которые никто не трогал