Что такое Active/Passive HA в TrueNAS Scale и зачем это нужно
Active/Passive High Availability в TrueNAS Scale - это конфигурация из двух идентичных серверов-контроллеров, подключенных к общему дисковому массиву (JBOD). В любой момент времени только один узел, активный, обслуживает все запросы к данным и предоставляет файловые сервисы (SMB, NFS, iSCSI). Второй узел находится в режиме ожидания и непрерывно отслеживает состояние активного контроллера через выделенный канал heartbeat.
При обнаружении сбоя - отказа питания, зависания ОС, потери сетевой связности - пассивный узел забирает управление общим пулом ZFS, поднимает виртуальный IP-адрес и берет на себя все сервисы. Для клиентов этот переход выглядит как кратковременная пауза в доступе к данным, обычно от 15 до 90 секунд, после которой работа продолжается без вмешательства администратора.
Механизм опирается на три компонента: общее хранилище с дисками, доступными обоим контроллерам по SAS; синхронную репликацию состояния ZFS между узлами; виртуальный IP (VIP), который всегда привязан к активному узлу. Такая архитектура устраняет единую точку отказа на уровне контроллера и критична для сред, где простой файлового сервера или блочного устройства означает остановку бизнес-процессов - баз данных, виртуализации, систем видеонаблюдения.
От других HA-решений, например Ceph или GlusterFS, связка TrueNAS Scale + ZFS отличается простотой настройки и меньшими требованиями к количеству узлов. Ceph требует минимум три монитора и несколько OSD для стабильной работы, тогда как Active/Passive кластер TrueNAS обходится двумя серверами и одной дисковой полкой. Это снижает стоимость внедрения и упрощает эксплуатацию, сохраняя при этом целостность данных благодаря транзакционной природе ZFS.
Требования к оборудованию и подготовка среды
Перед началом настройки убедитесь, что аппаратная платформа соответствует минимальным критериям. Оба сервера должны быть идентичны по компонентам: модель материнской платы, версия BIOS, объем и тип оперативной памяти, сетевые адаптеры, HBA-контроллеры. Расхождения в ревизиях железа - частая причина нестабильной работы failover и трудноуловимых ошибок синхронизации.
Минимальные характеристики одного узла: процессор с 8 ядрами x86-64, 64 ГБ ECC-памяти, два SSD по 120 ГБ для зеркала загрузочного тома, два порта 10GbE SFP+ для передачи данных и один порт 1GbE для управления. Рекомендуемая конфигурация для production-среды: 16 ядер, 128 ГБ ECC RAM, отдельный HBA-контроллер в IT-режиме (LSI SAS3008 или аналогичный), три сетевых интерфейса - для клиентского трафика, для heartbeat и для IPMI-управления.
Дисковый массив подключается через SAS-экспандер к обоим контроллерам одновременно. Каждый диск должен быть виден с каждого узла как отдельное блочное устройство. TrueNAS Scale использует резервирование SCSI-3 Persistent Reservation для предотвращения одновременной записи с двух контроллеров. Это штатный механизм, не требующий ручной настройки, но он предъявляет жесткое требование к поддержке PR дисками и HBA. Проверенные модели HBA: LSI 9300-8e, LSI 9400-8e, Dell HBA330.
Аппаратная совместимость и рекомендуемые компоненты
Выбор материнской платы критичен. Плата должна поддерживать IPMI для удаленного управления питанием и мониторинга - это основной способ, которым пассивный узел определяет зависание активного. Проверенные модели: Supermicro X11SPH-nCTF, X12SPi-TF, ASRock Rack EPC621D8A. Избегайте плат без выделенного BMC-чипа: программные watchdog-таймеры недостаточно надежны для HA-сценариев.
Синхронизация времени между узлами обязательна. Расхождение часов более чем на 5 секунд может привести к ложному срабатыванию failover или отказу в переключении. Настройте NTP на обоих контроллерах до начала конфигурации кластера, используя минимум три внешних источника и peer-связь между узлами. В интерфейсе TrueNAS Scale это делается через System → General → NTP Servers.
Сетевые адаптеры для heartbeat-канала должны поддерживать Jumbo Frames (MTU 9000) и быть соединены напрямую, без коммутатора. Это исключает точку отказа в виде свитча и снижает задержку. Рекомендуемые чипсеты: Intel X710, Mellanox ConnectX-4 Lx. Для клиентского трафика используйте LACP-агрегацию двух портов на коммутатор с поддержкой MLAG или стекирования - это обеспечит бесшовное переключение при отказе одного из физических линков.
Пошаговая настройка Active/Passive кластера
Установка и начальная конфигурация узлов
Загрузите ISO-образ TrueNAS Scale версии 24.10 или новее с официального сайта. Версия должна быть строго одинаковой на обоих узлах - расхождение даже в минорном билде блокирует создание HA-пары. Установите систему на зеркало из двух SSD, выделив под системный раздел не менее 64 ГБ. Оставшееся пространство на этих дисках не используйте под данные - оно зарезервировано для системных датасетов и логов.
После установки на первом узле задайте hostname, например tn-ha-01, и настройте три IP-адреса:
- Management: 192.168.1.11/24 на интерфейсе, подключенном к сети управления
- Data: 10.0.0.11/24 на интерфейсе клиентского трафика
- Heartbeat: 172.16.0.1/30 на прямом линке между узлами
На втором узле (tn-ha-02) задайте зеркальные адреса: Management 192.168.1.12, Data 10.0.0.12, Heartbeat 172.16.0.2/30. Проверьте связность ping-ом по всем трем сетям. Heartbeat-интерфейс должен отвечать с задержкой менее 0.5 мс - если пинг выше, проверьте кабель и настройки MTU.
На этом этапе также настройте DNS и шлюз по умолчанию. Оба узла должны разрешать имена друг друга. Добавьте записи в /etc/hosts через веб-интерфейс Network → Global Configuration → Host Name Database, если DNS-сервер недоступен при старте системы.
Создание и настройка общего пула ZFS
Подключите дисковый массив к обоим контроллерам. Убедитесь, что все диски видны в Storage → Disks на каждом узле. Имена устройств могут различаться (da0 на одном узле, da4 на другом) - это нормально, TrueNAS Scale идентифицирует диски по серийным номерам, а не по путям.
Создание пула выполняется один раз с активного узла. Перейдите в Storage → Create Pool. Выберите топологию, соответствующую вашим требованиям к отказоустойчивости и производительности:
- Mirror - для максимальной производительности чтения и быстрой ресинхронизации после сбоя
- RAID-Z2 - для экономии дискового пространства при сохранении устойчивости к отказу двух дисков
Присвойте пулу имя, например ha-pool. Критичный параметр для HA - sync=always. Он гарантирует, что каждое синхронное подтверждение записи будет сброшено на постоянное хранилище до ответа клиенту. Без этого при отказе активного узла данные, находящиеся в оперативной памяти, будут потеряны. Установите sync=always сразу после создания пула:
zfs set sync=always ha-poolДля ускорения синхронной записи добавьте в пул устройство SLOG - отдельный SSD с высокой выносливостью и низкой задержкой (например, Intel Optane P1600X или Radian RMS-200). Без SLOG-устройства производительность синхронной записи упадет до скорости самого медленного диска в пуле.
Настройка синхронной репликации данных
Синхронная репликация в TrueNAS Scale HA работает на уровне ZFS и обеспечивает идентичность данных между узлами в реальном времени. Она не требует ручного создания задач репликации - механизм встроен в подсистему failover и активируется автоматически при создании HA-пары.
Для включения HA-режима перейдите в System → Failover. Нажмите «Configure Failover» и заполните поля:
- Hostname второго узла: tn-ha-02
- IP второго узла (management): 192.168.1.12
- Heartbeat Interface: выберите интерфейс, подключенный к сети 172.16.0.0/30
- Virtual IP: 10.0.0.10/24 - адрес, который будет всегда указывать на активный узел
После сохранения система выполнит начальную синхронизацию. Она может занять от нескольких минут до часов в зависимости от объема данных. Отслеживайте прогресс через уведомления в веб-интерфейсе и командой:
zpool status ha-poolСостояние «ONLINE» на обоих узлах и отсутствие ошибок в выводе команды подтверждают успешную синхронизацию. Проверьте целостность данных скрабом пула:
zpool scrub ha-poolСкраб сравнит контрольные суммы всех блоков и выявит расхождения, если они есть. Запускайте его на активном узле - операция прозрачно отработает и на пассивном.
Конфигурация виртуального IP и автоматического переключения
Виртуальный IP-адрес - это точка входа для всех клиентов. Настройте его в том же разделе System → Failover, указав интерфейс для клиентского трафика и маску подсети. VIP должен находиться в той же подсети, что и физические IP-адреса узлов на клиентском интерфейсе.
Привязка VIP к активному узлу происходит через протокол CARP (Common Address Redundancy Protocol). Активный узел отправляет heartbeat-пакеты с заданным интервалом (по умолчанию 1 секунда). Если пассивный узел не получает три пакета подряд, он инициирует переключение: повышает свой приоритет, активирует VIP, импортирует пул и запускает сервисы.
Протестируйте ручное переключение кнопкой «Initiate Failover» в разделе System → Failover. Активный узел должен освободить пул и VIP, пассивный - подхватить их в течение 30-60 секунд. Затем выполните обратное переключение. Оба теста должны пройти без ошибок и потери подключенных клиентских сессий (допустима кратковременная пауза ввода-вывода).
Настройте оповещения о событиях failover через System → Alert Settings. Добавьте email-адреса администраторов и включите уведомления для категорий «Failover» и «Storage». При срабатывании переключения система отправит письмо с указанием причины, времени и нового активного узла.
Тестирование отказоустойчивости и типичные сценарии сбоев
Имитация отказа активного узла
Самый показательный тест - жесткое отключение питания активного контроллера. Подготовьте клиентскую машину с непрерывной записью на SMB-шару или iSCSI-устройство, размещенное на HA-пуле. Используйте утилиту, которая логирует таймауты, например ioping с ключом -C или скрипт с dd и временными метками.
Отключите питание активного узла через IPMI или физически. Наблюдайте за поведением:
- Клиентская запись должна замереть на 15-90 секунд
- Пассивный узел обнаружит пропажу heartbeat-пакетов через 3 секунды
- Еще 10-30 секунд уйдет на импорт пула и активацию сервисов
- VIP переедет на второй узел
- Запись возобновится без потери уже подтвержденных данных
Проверьте логи на пассивном узле: System → Audit Log и /var/log/messages. Записи с меткой «failover» и «carp» должны показать последовательность событий без ошибок импорта пула. Если пул не импортировался, проверьте состояние SCSI-резервирований: отказавший узел должен был их освободить, а новый - захватить.
Восстановление узла после сбоя
Включите отказавший узел. Он загрузится и обнаружит, что пул уже импортирован на другом контроллере. Система автоматически перейдет в режим пассивного узла и начнет ресинхронизацию данных. Этот процесс идет в фоне и не влияет на производительность активного узла.
Отслеживайте статус ресинхронизации:
zpool status ha-poolСтрока «resilvered» с процентом выполнения покажет прогресс. После завершения ресинхронизации кластер вернется в исходное состояние: один узел активен, второй в режиме ожидания. Обратное переключение ролей не происходит автоматически - это предотвращает oscillation (циклические переключения) при нестабильной работе восстановленного узла. Принудительно вернуть роли можно кнопкой «Initiate Failover».
Обрыв сети на клиентском интерфейсе активного узла - еще один сценарий для проверки. Отключите кабель от data-порта. Ожидаемое поведение: пассивный узел не должен инициировать failover, если heartbeat-канал исправен и активный узел продолжает работать. Это правильное поведение, предотвращающее split-brain. Клиенты потеряют доступ к данным через этот интерфейс, но данные останутся целостными. Для защиты от таких ситуаций используйте LACP-агрегацию на клиентских портах.
Распространенные проблемы и их решение
Heartbeat-канал не поднимается. Проверьте физическое соединение и MTU. Интерфейсы heartbeat должны быть в одной подсети /30 без шлюза. Диагностика: ping по heartbeat-адресам, проверка firewall-правил (разрешены ли протоколы CARP и SSH между узлами). TrueNAS Scale использует SSH для обмена конфигурацией между узлами - ключи генерируются автоматически при настройке failover, но блокировка 22-го порта на heartbeat-интерфейсе нарушит синхронизацию.
Ошибка импорта пула при failover. Самая частая причина - диски не видны с обоих узлов одновременно. Проверьте sas2ircu list или sas3ircu list на каждом контроллере. Все диски должны отображаться в выводе. Если часть дисков видна только с одного узла, проблема в SAS-кабелях, экспандере или зонировании. Другая причина - активное SCSI-резервирование, не снятое отказавшим узлом. Команда sg_persist -d /dev/daX -o -G -S покажет текущего держателя резервирования. Принудительно снять его можно с выжившего узла через sg_persist -d /dev/daX -o -L -K -T 5.
Расхождение версий TrueNAS Scale. При попытке создать HA-пару с разными версиями система выдаст ошибку несовместимости. Решение: обновите оба узла до одинаковой версии. Перед обновлением выполните ручной failover на узел, который будет обновляться вторым, чтобы минимизировать простой. Обновление на пассивном узле безопасно - он не обслуживает клиентский трафик. После обновления пассивного узла инициируйте переключение, обновите второй узел и верните роли.
Производительность синхронной записи ниже ожидаемой. Без SLOG-устройства каждая синхронная запись требует физического подтверждения от дисков пула. Добавьте SLOG на базе SSD с задержкой менее 100 микросекунд и выносливостью от 10 DWPD. Проверьте, что sync=always установлен на пуле. Измерьте latency дисковой подсистемы утилитой fio до и после добавления SLOG - разница должна быть кратной.
Заключение: ваш HA-кластер TrueNAS Scale готов к работе
Вы выполнили полный цикл настройки отказоустойчивого кластера: установили идентичные узлы, создали общий пул ZFS с sync=always, активировали синхронную репликацию и сконфигурировали автоматический failover с виртуальным IP. Кластер способен пережить отказ любого из контроллеров с потерей не более 90 секунд доступности и нулевой потерей подтвержденных данных.
Для долгосрочной стабильной работы включите в регламент три обязательные процедуры. Первая - ежемесячное тестирование failover вручную, чтобы убедиться в исправности механизма переключения. Вторая - настройка мониторинга через встроенные алерты и внешние системы по SNMP, с обязательным контролем состояния heartbeat-канала и загрузки CPU на пассивном узле (высокая загрузка может указывать на фоновую ресинхронизацию). Третья - регулярное резервное копирование конфигурации через System → General → Save Config. Файл конфигурации содержит все настройки кластера и критичен для восстановления после двойного отказа.
Если вы только планируете внедрение TrueNAS Scale, изучите руководство по сборке массива хранения с критериями выбора HBA-контроллера и расчетом емкости ZFS-пула. Для настройки сетевого доступа к созданному HA-хранилищу используйте инструкцию по SMB, NFS и FTP с акцентом на безопасность и производительность. Полный цикл развертывания от установки до мониторинга описан в пошаговом руководстве по TrueNAS Scale 2026.