1. Netzwerk und IP-Adressen für Proxmox und TrueNAS

Das Managementnetz und die beiden Speichernetze sind getrennt. SAN1 verwendet das Netz 172.16.1.0/24, SAN2 das Netz 172.16.2.0/24. Die Managementadressen liegen im Netz 192.168.168.0/24.

Auf TrueNAS übernimmt enp2s0f0 das Management, ens1f0np0 SAN1 und enp2s0f1 SAN2. Die SAN-Adressen von pve2 und pve3 werden durch die später sichtbaren iSCSI-Verbindungen bestätigt; ihre vollständigen finalen Schnittstellendateien sind nicht abgebildet.

SAN-Schnittstellen auf Proxmox konfigurieren

Die spätere Konfiguration von pve1 verwendet nic1 für SAN1 und nic2 für SAN2. Das Standardgateway 192.168.168.1 bleibt am Managementnetz über vmbr0. Für die SAN-Schnittstellen ist kein Gateway eingetragen.

auto nic1
iface nic1 inet static
    address 172.16.1.21/24

auto nic2
iface nic2 inet static
    address 172.16.2.21/24

Ein früher Ping scheitert mit „Destination Host Unreachable“. Nach den Anpassungen sind erfolgreiche Antworten von beiden TrueNAS-SAN-Adressen auf pve1 und pve2 sichtbar. Auch pve3 erreicht dokumentierte SAN-Ziele. Diese kurzen Tests bestätigen die Erreichbarkeit, aber noch keine Leistung oder Stabilität unter Last.

2. TrueNAS-Pool und iSCSI-LUN erstellen

ZFS-Mirror aus zwei SSDs anlegen

Unter Storage → Create Pool wird der Pool Mirror erstellt. Er besteht aus einem Mirror-VDEV mit zwei als SSD erkannten Laufwerken von jeweils 931,51 GiB. Eine Verschlüsselung ist in der gezeigten Konfiguration nicht aktiviert.

Die Poolerstellung löscht die ausgewählten Datenträger. Vor einer Wiederholung müssen deshalb Laufwerksauswahl und vorhandene Daten geprüft werden.

Nach der Erstellung zeigt TrueNAS etwa 899,25 GiB nutzbare Kapazität und den Zustand „Online, no errors“. Ein Scrub ist sonntags um 00:00 Uhr geplant. Auto TRIM ist ausgeschaltet; Temperaturdaten sind nicht verfügbar.

Dataset und Zvol mit 512 GiB erstellen

Unter Shares → Block (iSCSI) Shares Targets → Wizard wird ein neues Target vorbereitet. Im Pool entsteht das Dataset Mirror/iscsi. Der Assistent erstellt darin ein neues Blockgerät mit 512 GiB.

Das Profil zeigt eine Extent-Blockgröße von 4 KiB. Diese Angabe ist nicht mit der ZFS-Eigenschaft volblocksize gleichzusetzen. Der später sichtbare Gerätepfad lautet zvol/Mirror/iscsi/iscsi.

3. iSCSI-Portale und Initiatoren konfigurieren

Das TrueNAS-Target wird über 172.16.1.67 und 172.16.2.67 erreichbar gemacht. Beide Portal-Adressen führen zur selben LUN. Mehrere Portal-Adressen bilden die Grundlage für die späteren Multipath-Verbindungen.

Die eindeutigen Initiator-Namen der Proxmox-Knoten lassen sich auf jedem Host auslesen:

cat /etc/iscsi/initiatorname.iscsi

Im Workshop werden alle drei Initiatoren im TrueNAS-Assistenten hinterlegt. Danach wird der iSCSI-Dienst gestartet; die Option für den automatischen Start ist ausgewählt.

Die spätere Übersicht zeigt das Target iscsi mit LUN-ID 0, Authentifizierung NONE und sechs Verbindungen: jeweils eine Verbindung pro Host und SAN-Netz. Es sind keine zusätzlichen „Authorized Networks“ eingetragen; die Initiatorliste ist davon getrennt zu betrachten.

4. TrueNAS-iSCSI-Speicher in Proxmox einbinden

Unter Datacenter → Storage → Add → iSCSI wird die Verbindung hinzugefügt:

• ID: iscsi-portal
• Portal: 172.16.1.67
• Target: iqn.2005-10.org.freenas.ctl:iscsi
• Nodes: alle Knoten
• Enable: aktiviert
• Use LUNs directly: deaktiviert

Nach der Einrichtung ist iscsi-portal aktiv. Der Inhaltstyp none passt zur Nutzung als Basis für LVM. Vor der Multipath-Einrichtung erscheinen zwei Geräte mit jeweils 512 GiB. Sie stellen zwei Wege zu derselben LUN dar und dürfen nicht als unabhängige Datenträger verwendet werden.

5. iSCSI-Multipath auf den Proxmox-Knoten einrichten

Multipath-Werkzeuge installieren und Sitzungen prüfen

Auf allen drei Hosts wird die Installation der Multipath-Werkzeuge angestoßen:

apt-get install multipath-tools -y

Auf pve1 und pve2 ist der Installationsabschluss sichtbar. Auf pve3 bestätigen die späteren Abfragen die Verfügbarkeit. Die iSCSI-Sitzungen werden mit folgendem Befehl geprüft:

iscsiadm -m session

Auf pve3 sind Verbindungen zu beiden Portalen über TCP-Port 3260 sichtbar.

Dieselbe LUN über ihre WWID identifizieren

Im gezeigten Beispiel heißen die beiden Pfadgeräte auf pve3 /dev/sdd und /dev/sde. Ihre Identität wird so abgefragt:

/lib/udev/scsi_id -g -u -d /dev/sdd
/lib/udev/scsi_id -g -u -d /dev/sde

Beide liefern die WWID 36589cfc00000005cf4f3f236e1d7b5b0. Die Gerätenamen können auf anderen Hosts oder nach einem Neustart abweichen. Vor einer Übernahme der Befehle müssen die tatsächlich vorhandenen Geräte geprüft werden.

WWID registrieren und Multipath kontrollieren

multipath -a 36589cfc00000005cf4f3f236e1d7b5b0
multipath -r
multipath -ll

Vergleichbare abschließende Ausgaben sind auf allen drei Hosts sichtbar. Eine aktive und eine weitere verfügbare Pfadgruppe sind dokumentiert. Ein praktischer Ausfalltest wurde damit noch nicht nachgewiesen.

Wichtige Korrektur: Konfiguration und WWID-Datei trennen

Im Workshop wird zwischenzeitlich ein multipaths { … }-Block mit einem Alias in /etc/multipath/wwids eingetragen. Ein solcher Block gehört in die Multipath-Konfiguration, üblicherweise /etc/multipath.conf. Die WWID-Datei dient der Registrierung der Geräte und wird über die Multipath-Werkzeuge gepflegt.

Später wird die WWID erneut hinzugefügt und die Datei zwischen Hosts kopiert. Obwohl die abschließenden Geräteausgaben erfolgreich sind, ist der endgültige Dateiinhalt nicht sichtbar. Die Bereinigung muss deshalb vor einer Abnahme geprüft werden.

iSCSI-Timeouts auf tatsächliche Wirksamkeit prüfen

Auf pve3 wird in /etc/iscsi/iscsid.conf folgende Einstellung gezeigt:

node.session.timeo.replacement_timeout = 15

Eine spätere Sitzungsdetailansicht zeigt weiterhin Recovery Timeout: 120. Das deutet darauf hin, dass die geänderte Vorgabe in der betrachteten Sitzung noch nicht wirksam war. Konfigurationsdatei, gespeicherte Verbindungseinträge und aktive Sitzungen müssen gemeinsam geprüft werden.

6. Gemeinsamen LVM-Speicher auf der iSCSI-LUN hinzufügen

Unter Datacenter → Storage → Add → LVM wird der Speicher truenas angelegt. Als Basisspeicher dient iscsi-portal, als Basisvolume die LUN 0. Die Volume Group erhält im Workshop den Namen pve. Zugelassen sind VM-Festplatten und Container.

Die Ausgabe von pvs auf pve1 ordnet die Volume Group dem Multipath-Gerät unter /dev/mapper/… zu. Proxmox zeigt etwa 549,75 GB Gesamtkapazität, entsprechend ungefähr 512 GiB.

Später werden Shared und Wipe Removed Volumes aktiviert. Die Option Allow Snapshots as Volume-Chain bleibt eingeschaltet.

Shared stellt keine Speicherverbindung her. Die Einstellung beschreibt einen bereits von mehreren Knoten erreichbaren Speicher. Alle Hosts müssen dieselbe LUN und Volume Group erkennen.

Die Oberfläche kennzeichnet Volume-Chain-Snapshots als Technology Preview. QCOW2 auf LVM ist in diesem Zusammenhang nicht automatisch falsch: Das Proxmox-Administrationshandbuch beschreibt diese Funktion für neuere Versionen. Bei bereits vorhandenen abhängigen Volumes darf die Option nicht unvorbereitet deaktiviert werden.

7. VM-Festplatte auf TrueNAS verschieben und Migration prüfen

Als Beispiel dient VM 100 (TRMM) mit 8 GiB RAM, vier CPU-Kernen, CPU-Typ host, OVMF/UEFI und einer 32-GiB-Systemfestplatte. Die VM verwendet einen VirtIO-SCSI-single-Controller und ein VirtIO-Netzwerkgerät an vmbr0.

Systemfestplatte auf den LVM-Speicher verschieben

In der Hardwareansicht wird für scsi0 die Aktion zum Verschieben des Speichers geöffnet. Ausgewählt sind das Ziel truenas, das Format qcow2 und das Löschen der Quelle nach dem Verschieben.

Das Zielvolume lautet truenas:vm-100-disk-0.qcow2. Die spätere Aufgabenliste bestätigt den Verschiebevorgang mit OK. Um 16:48 Uhr liegt die EFI-Disk noch auf local-zfs. Ein weiterer erfolgreicher Verschiebetask ist sichtbar, dessen betroffenes Volume jedoch nicht eindeutig belegt ist.

Warum die VM-Migration noch offen ist

Mehrere Offline-Migrationen von pve1 nach pve2 enden mit Error: migration aborted. Frühere Dialoge warnen vor lokalen Datenträgern. Nach dem Aktivieren von „Shared“ zeigt der abgebildete Dialog diese Warnungen nicht mehr.

Die konkrete Abbruchursache lässt sich aus den Screenshots nicht bestimmen. Dafür ist die vollständige Ausgabe eines fehlgeschlagenen Migrationstasks erforderlich. Eine bestimmte Multipath-, CPU- oder VM-Einstellung als Ursache zu benennen, wäre ohne dieses Log spekulativ.

Letzter dokumentierter Stand: Klonvorgang läuft

Der letzte Screenshot um 16:55 Uhr zeigt einen laufenden Klonvorgang von VM 111 mit etwa 21 Prozent Fortschritt. Das Zielvolume gehört zu VM 101 auf truenas. Ein Abschluss ist nicht abgebildet. Der im Hintergrund erfolgreiche Replikationsjob von VM 111 nach pve2 bestätigt weder den Klonabschluss noch die Migration von VM 100.

8. Prüfliste für die Abnahme des gemeinsamen Speichers

• Auf jedem Proxmox-Knoten sind beide TrueNAS-Portale verbunden.
• Alle Knoten erkennen dieselbe WWID und zwei fehlerfreie Multipath-Pfade.
• Die gemeinsame Volume Group ist über das Multipath-Gerät erreichbar.
• Multipath-Konfiguration und WWID-Registrierung sind korrekt getrennt.
• Die gewünschten iSCSI-Timeouts sind in den verwendeten Verbindungen wirksam.
• Die Speicherorte sämtlicher VM-Disks einschließlich EFI sind dokumentiert.
• Eine Offline-Migration endet mit OK; die VM startet und funktioniert auf dem Zielhost.
• Ein kontrollierter Test bestätigt den Weiterbetrieb beim Ausfall eines einzelnen SAN-Pfads.
• Nach einem Host-Neustart sind Speicher und beide Verbindungen automatisch verfügbar.
• Ein unabhängiges Backup wurde erfolgreich wiederhergestellt und geprüft.

9. Optimierungstipps für Proxmox, TrueNAS und iSCSI-Multipath

Zuerst Konfiguration und Migration abschließen

1. Multipath-Dateien vereinheitlichen: Prüfe die Konfiguration und die registrierten WWIDs auf allen Hosts. Vergleiche vorhandene Inhalte, bevor Dateien überschrieben werden.
2. Migrationslog auswerten: Sichere die vollständige Task-Ausgabe und behebe die dort genannte Ursache. Wiederholte Versuche ohne Logauswertung liefern wenig zusätzliche Erkenntnis.
3. Alle VM-Datenträger berücksichtigen: Prüfe neben der Systemfestplatte auch EFI-, gegebenenfalls TPM- und weitere Disks.
4. Timeouts kontrolliert übernehmen: Kläre die Abweichung zwischen den konfigurierten 15 Sekunden und den sichtbaren 120 Sekunden. Änderungen an bestehenden Speicherverbindungen gehören in ein Wartungsfenster.

Ausfallsicherheit praktisch nachweisen

5. Unabhängige SAN-Wege verwenden: Getrennte Subnetze sollten durch geeignete physische Wege ergänzt werden. Prüfe Adapter, Verkabelung und Switches auf gemeinsame Ausfallpunkte. Die TrueNAS-Netzwerkempfehlungen erläutern die Verwendung zusätzlicher iSCSI-Portale.
6. Pfadwechsel testen: Unterbrich mit einer Test-VM und laufenden Ein-/Ausgaben jeweils nur einen SAN-Pfad. Prüfe anschließend auch dessen Wiederkehr und einen Host-Neustart.
7. TrueNAS-Ausfall einplanen: Mirror und Multipath schützen gegen unterschiedliche Teilfehler. Der vollständige Ausfall eines einzelnen TrueNAS-Systems erfordert weiterhin einen Wiederanlaufplan und unabhängige Sicherungen.

Leistung, Wartung und Sicherheit verbessern

8. Vorschaufunktionen gezielt testen: Prüfe bei Volume-Chain-Snapshots insbesondere Erstellung, Löschen, Backup, Restore und Migration mit der eingesetzten Version.
9. Eindeutige Namen wählen: Bei künftigen Einrichtungen lässt sich eine Volume Group wie vg_truenas_iscsi leichter zuordnen als pve. Bestehende Gruppen nicht ohne Prüfung ihrer Referenzen umbenennen.
10. Leistung messen: Erfasse Durchsatz, IOPS und Latenz in einer Test-VM, bevor MTU, Pfadverteilung oder ZFS-Parameter geändert werden. Jumbo Frames benötigen eine durchgängig passende Netzwerkkonfiguration.
11. SSD-Wartung ergänzen: Prüfe TRIM-Unterstützung und Laufwerksüberwachung. Im dokumentierten Stand ist Auto TRIM ausgeschaltet; Temperaturdaten fehlen. Überwache außerdem Poolkapazität, Speicherfehler und ausgefallene Pfade.
12. Zugriffe begrenzen: Behalte eindeutige Initiatorlisten bei und beschränke die SAN-Erreichbarkeit auf die vorgesehenen Hosts. Prüfe CHAP oder Mutual CHAP als zusätzliche Authentifizierung. CHAP verschlüsselt den Datenverkehr nicht. Weitere Informationen enthält die TrueNAS-iSCSI-Dokumentation.
13. Backups unabhängig speichern: Sichere VMs außerhalb der produktiven LUN und dokumentiere einen erfolgreichen Restore mit VM-Start und Anwendungstest. Mirror, Snapshots und Replikation ersetzen dieses Backup nicht.