TrueNAS кластер: полное руководство по развертыванию и управлению

Представь, что твоя инфраструктура хранения данных должна работать 24/7 без единой точки отказа. Один сервер TrueNAS — это хорошо, но кластер TrueNAS — это профессиональное решение для бизнес-критичных нагрузок. Давай разберем, как построить отказоустойчивую систему хранения на базе TrueNAS.

Что такое TrueNAS кластер и зачем он нужен

TrueNAS кластер — это группа серверов TrueNAS, объединенных в единую систему хранения данных с высокой доступностью (HA). В отличие от одиночного инстанса, кластер TrueNAS обеспечивает:

• Отказоустойчивость — при выходе одного узла из строя, другой автоматически берет на себя его функции
• Масштабируемость — можно добавлять узлы для увеличения производительности и емкости
• Бесперебойность обслуживания — обновление ПО без остановки сервисов
• Распределенную нагрузку — балансировку запросов между узлами

Архитектура TrueNAS кластера: как это работает

Кластер TrueNAS обычно состоит из:

Типы кластеризации в TrueNAS

Существует несколько подходов к созданию кластера TrueNAS:

1. TrueNAS Enterprise HA — проприетарное решение iXsystems с автоматическим failover
2. TrueNAS SCALE + Gluster — распределенная файловая система поверх ZFS
3. TrueNAS SCALE + Kubernetes — для контейнерных workloads с CSI драйверами
4. Репликация ZFS + Pacemaker/Corosync — кастомное решение на базе open-source

Пошаговое руководство: развертывание кластера TrueNAS SCALE

Давай создадим простой двухузловой кластер на базе TrueNAS SCALE с репликацией ZFS и виртуальным IP.

Шаг 1: Подготовка оборудования и сети

Для нашего кластера TrueNAS потребуется:

• 2 идентичных сервера с TrueNAS SCALE (минимум 32GB RAM каждый)
• Две сетевые карты на каждом узле (1 для клиентов, 1 для репликации)
• Общий свитч для сети репликации
• Поддержка виртуальных IP (VRRP или аналоги)

# Проверяем сетевые интерфейсы на узле 1
ip addr show
# enp1s0: клиентская сеть (192.168.1.10/24)
# enp2s0: сеть репликации (10.0.0.1/30)

# Аналогично на узле 2
# enp1s0: 192.168.1.11/24
# enp2s0: 10.0.0.2/30

Шаг 2: Настройка ZFS репликации

Создаем пул ZFS на каждом узле и настраиваем периодическую репликацию:

# На узле 1 создаем пул
zpool create tank raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd
zfs create tank/data

# Настраиваем снапшоты
zfs set com.sun:auto-snapshot=true tank/data

# Создаем SSH ключи для репликации
ssh-keygen -t ed25519 -f ~/.ssh/replication_key
ssh-copy-id -i ~/.ssh/replication_key.pub root@10.0.0.2

# Конфиг для автоматической репликации (/root/replicate.sh)
#!/bin/bash

SOURCE_POOL="tank"
TARGET_HOST="10.0.0.2"
TARGET_POOL="tank"
SSH_KEY="/root/.ssh/replication_key"

# Создаем снапшот с timestamp
SNAPSHOT="replica-$(date +%Y%m%d-%H%M%S)"
zfs snapshot -r ${SOURCE_POOL}@${SNAPSHOT}

# Отправляем инкрементальные изменения
LAST_SNAPSHOT=$(zfs list -t snapshot -o name -s creation | grep ${SOURCE_POOL} | tail -2 | head -1)

zfs send -R -I ${LAST_SNAPSHOT} ${SOURCE_POOL}@${SNAPSHOT} | \
  ssh -i ${SSH_KEY} root@${TARGET_HOST} zfs receive -Fdu ${TARGET_POOL}

# Очищаем старые снапшоты (храним последние 24)
zfs list -t snapshot -o name | grep ${SOURCE_POOL}@replica- | head -n -24 | xargs -n1 zfs destroy

Шаг 3: Виртуальный IP и failover

Настраиваем keepalived для управления виртуальным IP:

# /etc/keepalived/keepalived.conf на узле 1 (MASTER)
vrrp_instance VI_1 {
    state MASTER
    interface enp1s0
    virtual_router_id 51
    priority 100
    advert_int 1
    
    virtual_ipaddress {
        192.168.1.100/24 dev enp1s0
    }
    
    track_script {
        chk_truenas
    }
}

vrrp_script chk_truenas {
    script "/usr/bin/systemctl is-active --quiet middlewared"
    interval 2
    weight -20
}

# /etc/keepalived/keepalived.conf на узле 2 (BACKUP)
vrrp_instance VI_1 {
    state BACKUP
    interface enp1s0
    virtual_router_id 51
    priority 90
    advert_int 1
    
    virtual_ipaddress {
        192.168.1.100/24 dev enp1s0
    }
    
    track_script {
        chk_truenas
    }
}

Шаг 4: Настройка общих ресурсов (SMB/NFS)

Конфигурируем идентичные шары на обоих узлах:

# WebUI или через midclt на обоих узлах
# Создаем SMB share с одинаковыми настройками

# Через CLI (пример):
midclt call smb.share.create '{
  "path": "/mnt/tank/data",
  "name": "cluster_share",
  "purpose": "DEFAULT_SHARE",
  "comment": "TrueNAS Cluster Share",
  "guestok": false,
  "hostsallow": ["192.168.1.0/24"],
  "aapl_name_mangling": false,
  "durablehandle": true
}'

Мониторинг и управление кластером TrueNAS

После развертывания кластера TrueNAS важно настроить мониторинг:

# Скрипт проверки состояния кластера
#!/bin/bash

NODE1="192.168.1.10"
NODE2="192.168.1.11"
VIP="192.168.1.100"

check_node() {
    local node=$1
    if ping -c 2 -W 1 $node > /dev/null 2>&1; then
        echo "✅ Узел $node доступен"
        return 0
    else
        echo "❌ Узел $node недоступен"
        return 1
    fi
}

check_service() {
    local node=$1
    if ssh root@$node "systemctl is-active middlewared" | grep -q active; then
        echo "✅ Сервис TrueNAS на $node работает"
        return 0
    else
        echo "❌ Сервис TrueNAS на $node не работает"
        return 1
    fi
}

echo "=== Проверка кластера TrueNAS ==="
echo "Время: $(date)"
echo""

check_node $NODE1
check_node $NODE2

# Проверяем, где находится VIP
if ip addr show | grep -q $VIP; then
    echo "✅ VIP находится на локальном узле"
else
    echo "⚠️  VIP находится на удаленном узле"
fi

echo""
echo "=== Статус репликации ==="
zfs list -t snapshot -o name,creation,used | grep replica- | tail -5

Сравнение подходов к кластеризации TrueNAS

Частые вопросы (FAQ) по TrueNAS кластерам

Можно ли создать кластер из разных версий TrueNAS?

Нет, для стабильной работы кластера TrueNAS все узлы должны работать на одинаковой версии ПО. Разные версии могут иметь несовместимые функции ZFS или протоколы репликации.

Какая задержка репликации допустима?

Для синхронной репликации рекомендуется задержка не более 5ms. Для асинхронной — зависит от RPO (Recovery Point Objective) вашего приложения. Используйте dedicated 10GbE или быстрее сеть для репликации.

Как добавить третий узел в существующий кластер?

Процесс зависит от типа кластера. В случае с ZFS репликацией — настройте репликацию с существующих узлов на новый, затем добавьте его в keepalived конфиг с более низким приоритетом.

Что делать при расщеплении мозга (split-brain)?

1. Определите узел с наиболее актуальными данными (последние снапшоты).
2. На втором узле отмонтируйте пулы.
3. Выполните полную ресинхронизацию с актуального узла.
4. Настройте кворум-устройство для предотвращения в будущем.

Поддерживает ли TrueNAS кластер распределенные транзакции?

TrueNAS Enterprise HA поддерживает синхронную репликацию с гарантией консистентности. В кастомных решениях используйте приложения с поддержкой распределенных транзакций или настройте NFSv4 с lease времени.

Заключение: когда нужен кластер TrueNAS

Кластер TrueNAS — это не просто «хорошо иметь», а необходимость для:

• Продакшен сред с требованием 99.99% доступности
• Виртуализации, где хранилище — единая точка отказа
• Бизнес-приложений с жесткими SLA
• Постепенного масштабирования инфраструктуры хранения

Начните с простой схемы ZFS репликации + keepalived, как мы рассмотрели выше. Это даст понимание работы кластера TrueNAS без значительных инвестиций. Когда потребуется enterprise-уровень — рассматривайте TrueNAS Enterprise HA или распределенные решения на SCALE.