Cluster Proxmox + TrueNAS SCALE

Contexte & Problématique

Dans mon KOMI.LAB, j'exploite 3 nœuds Proxmox VE pour la virtualisation. Le problème initial : chaque nœud avait son propre stockage local, rendant impossible la migration live des VMs entre nœuds et la haute disponibilité réelle.

L'objectif est de déployer un stockage partagé via TrueNAS SCALE, exposé en iSCSI pour les datastores VMs et en NFS pour les sauvegardes Proxmox Backup Server (PBS). Cela permettra le Live Migration et le failover automatique via Corosync/Pacemaker.

ℹ️

Environnement KOMI.LAB 3× Proxmox VE 8.1.4 · TrueNAS SCALE 23.10 · Réseau storage dédié 10.0.99.0/24 · Interconnexion 1Gbps (LAG futur 10G)

Ce lab a ensuite été adapté pour la production SGMT avec des ajustements réseau (VLAN storage isolé, jumbo frames 9000 MTU) et une redondance des chemins iSCSI via MPIO.

Architecture cible

Chaque nœud Proxmox se connecte au TrueNAS via deux protocoles distincts : iSCSI pour les disques VM (performances bloc) et NFS pour les sauvegardes PBS (simplicité fichier).

Topologie — Cluster Proxmox + TrueNAS

  ┌─────────┐    ┌─────────┐    ┌─────────┐
  │  pve01  │    │  pve02  │    │  pve03  │
  │10.0.99.1│    │10.0.99.2│    │10.0.99.3│
  └────┬────┘    └────┬────┘    └────┬────┘
       │              │              │
       └──────────────┴──────────────┘
                  Storage VLAN
                  10.0.99.0/24
                       │
              ┌────────▼────────┐
              │  TrueNAS SCALE  │
              │  10.0.99.10     │
              │                 │
              │  iSCSI :3260    │ ← Datastores VMs
              │  NFS   :2049    │ ← Sauvegardes PBS
              │  SMB   :445     │ ← Partages optionnels
              │                 │
              │  Pool: ZFS Mirror│
              │  4TB usable     │
              └─────────────────┘

  Cluster Corosync (ring0: MGMT, ring1: STORAGE)
  HA Manager → failover automatique VMs critiques

Prérequis

Composant	Version testée	Rôle
Proxmox VE	8.1.4	Hyperviseur cluster (×3 nœuds)
TrueNAS SCALE	23.10.2	NAS partagé iSCSI + NFS
Corosync	3.1.7	Clustering et quorum
open-iscsi	2.1.8	Initiateur iSCSI Linux
Réseau storage	1GbE dédié	Isolation trafic storage

⚠️

Sauvegarde préalable obligatoire Avant toute manipulation cluster, exporter les VMs critiques ou s'assurer d'un snapshot récent. Le quorum cluster peut rendre des VMs indisponibles si mal configuré.

Étapes de déploiement

1

Configurer le pool ZFS sur TrueNAS SCALE

Créer un pool ZFS Mirror avec les disques disponibles. Activer la compression LZ4 et les snapshots automatiques.

TrueNAS CLI / Shell

# Vérifier les disques disponibles
lsblk -d -o NAME,SIZE,MODEL

# Créer le pool ZFS Mirror (via interface TrueNAS ou CLI)
zpool create -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  tank mirror /dev/sdb /dev/sdc

# Vérifier l'état du pool
zpool status tank
zpool list tank

2

Créer et exposer le target iSCSI sur TrueNAS

Depuis l'interface web TrueNAS → Shares → iSCSI. Créer un Portal, un Initiator Group, un Extent (zvol), puis le Target.

bash — TrueNAS Shell

# Créer le zvol pour les VMs Proxmox (via CLI ou WebUI)
zfs create -V 2T -o volblocksize=16K tank/proxmox-vms

# Vérifier le zvol
zfs list -t volume tank/proxmox-vms

# Tester que le service iSCSI écoute
ss -tlnp | grep 3260

3

Installer et configurer open-iscsi sur chaque nœud Proxmox

Sur les 3 nœuds Proxmox, installer l'initiateur iSCSI, découvrir le target TrueNAS et se connecter.

bash — Sur chaque nœud Proxmox (pve01, pve02, pve03)

# Installer open-iscsi
apt update && apt install -y open-iscsi

# Activer le service
systemctl enable --now iscsid

# Découverte du target TrueNAS
iscsiadm -m discovery -t sendtargets -p 10.0.99.10:3260

# Connexion au target (remplacer IQN par celui de TrueNAS)
iscsiadm -m node \
  --targetname iqn.2005-10.org.freenas.ctl:proxmox-vms \
  --portal 10.0.99.10:3260 \
  --login

# Vérifier la connexion
iscsiadm -m session
lsblk | grep sd

4

Ajouter le stockage iSCSI dans Proxmox

Depuis l'interface Proxmox → Datacenter → Storage → Add → iSCSI. Puis ajouter un LVM sur le LUN iSCSI.

bash — Proxmox Shell (pve01)

# Identifier le device iSCSI connecté
ls -la /dev/disk/by-path/ | grep iscsi

# Créer le VG LVM sur le LUN iSCSI
pvcreate /dev/sdb
vgcreate pve-iscsi /dev/sdb

# Ajouter via pvesm (Proxmox Storage Manager)
pvesm add lvm komilab-shared \
  --vgname pve-iscsi \
  --shared 1 \
  --content images

# Ajouter le NFS TrueNAS pour les backups PBS
pvesm add nfs komilab-backups \
  --server 10.0.99.10 \
  --export /mnt/tank/proxmox-backups \
  --content backup \
  --options vers=4

# Vérifier les storages
pvesm status

5

Configurer la Haute Disponibilité (HA)

Ajouter les VMs critiques au groupe HA. Configurer les politiques de failover automatique via le HA Manager.

bash — Proxmox Shell

# Créer un groupe HA
ha-manager groupadd production \
  --nodes pve01,pve02,pve03 \
  --nofailback 0 \
  --restricted 0

# Ajouter une VM au groupe HA (ex: VMID 100 = AD Controller)
ha-manager add vm:100 \
  --group production \
  --state started \
  --max_restart 3 \
  --max_relocate 1

# Vérifier le statut HA
ha-manager status
pvecm status

Points critiques & Erreurs rencontrées

🔴

Erreur #1 — iSCSI non persistant après reboot Symptôme : Après reboot d'un nœud, le LUN iSCSI n'était pas reconnecté automatiquement.
Cause : Le service iscsid démarrait avant que l'interface réseau storage soit active.
Résolution : Ajouter network-online.target dans la dépendance systemd de iscsid, et activer la connexion persistante : iscsiadm -m node --op update -n node.startup -v automatic

⚠️

MTU — Jumbo Frames obligatoire en production En KOMI.LAB, la MTU 1500 suffit. En production, configurer MTU 9000 sur l'interface storage pour les performances iSCSI. Vérifier que le switch supporte les jumbo frames end-to-end.

⚠️

Quorum — 3 nœuds minimum impératif Avec 2 nœuds, la perte d'un nœud bloque le cluster (pas de quorum). Toujours maintenir un nombre impair de nœuds ou ajouter un QDevice externe.

Résultats & Métriques

<30s

Failover HA

900MB/s

Débit iSCSI lu

99.9%

Dispo cluster

✅

Validation complète Test de failover : extinction forcée de pve01 → VMs HA redémarrées sur pve02 en 28 secondes. Live Migration testée sans interruption de service. Sauvegardes PBS fonctionnelles vers NFS TrueNAS.

Recommandations production

Activer les snapshots ZFS automatiques sur TrueNAS (toutes les heures, rétention 7 jours) avant toute maintenance cluster
Dédier une interface réseau physique exclusivement au trafic storage (pas de partage avec le réseau VM)
Configurer MPIO (MultiPath I/O) avec 2 chemins iSCSI redondants pour éliminer le SPOF réseau storage
Monitorer les métriques ZFS (ARC hit ratio, I/O latency) via Prometheus + node_exporter sur TrueNAS
Planifier les mises à jour Proxmox en mode maintenance HA (drainer le nœud avant mise à jour)

🏭

KOMI.LAB vs Production SGMT En production SGMT, j'ai ajouté : VLAN storage isolé (VLAN 99), MTU 9000 sur tous les équipements, MPIO avec 2 liens physiques dédiés, et une supervision des sessions iSCSI via Zabbix avec alerte si déconnexion.

Références

Proxmox VE — Storage Documentation — Documentation officielle des types de storage
TrueNAS SCALE — iSCSI Configuration — Guide officiel iSCSI TrueNAS
Proxmox HA Manager — Configuration Haute Disponibilité
OpenZFS Documentation — Référence ZFS complète

Cluster Proxmox VE + TrueNAS SCALEvia iSCSI & NFS

Contexte & Problématique

Architecture cible

Prérequis

Étapes de déploiement

Points critiques & Erreurs rencontrées

Résultats & Métriques

Recommandations production

Références

Cluster Proxmox VE + TrueNAS SCALE
via iSCSI & NFS