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.

SSH-Loginprobleme nach manuellen Verbindungen zwischen den Knoten

Während der Einrichtung können bei manuellen SSH-Verbindungen zwischen den Nodes Loginprobleme auftreten, beispielsweise durch widersprüchliche gespeicherte Hostschlüssel. Eine manuelle Verbindung verursacht nicht grundsätzlich einen Fehler; entscheidend ist die konkrete SSH-Meldung.

Bei einem veralteten Hostschlüsseleintrag lässt sich beispielsweise so vorgehen: Zunächst den aktuellen Fingerprint auf dem Zielknoten über eine vertrauenswürdige Konsole anzeigen und mit der SSH-Meldung vergleichen:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Nur wenn der Schlüsselwechsel geklärt ist und die Fehlermeldung auf /root/.ssh/known_hosts verweist, auf dem Quellknoten die betroffenen Einträge entfernen. Beispiel für pve2:

ssh-keygen -f /root/.ssh/known_hosts -R pve2
ssh-keygen -f /root/.ssh/known_hosts -R 192.168.168.22
ssh root@pve2

Beim erneuten Verbindungsaufbau den angezeigten Fingerprint prüfen. Bei abweichendem Hostnamen oder Dateipfad die Angaben aus der tatsächlichen Fehlermeldung verwenden; nicht pauschal die gesamten Known-Hosts-Dateien löschen.

Bei veralteten Proxmox-Hostschlüsseldaten, etwa nach erneutem Beitritt eines Nodes mit gleichem Namen oder gleicher IP, kann auf dem betroffenen Zielknoten außerdem Folgendes helfen:

pvecm updatecerts

Proxmox verwendet versionsabhängig eigene Hostschlüsseldateien beziehungsweise explizites Host-Key-Pinning. Ein erfolgreicher manueller SSH-Login allein bestätigt daher nicht jede von Proxmox verwendete SSH-Verbindung. Siehe die Proxmox-Clusterdokumentation zur Rolle von SSH. Bei „Permission denied (publickey)“ stattdessen die Anmeldung mit Schlüsseln und die Zugriffsrechte prüfen; das Entfernen eines Hostschlüsseleintrags behebt diesen anderen Fehler nicht.

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.

Migrationsfehler gelöst: Shared, ZFS-Replikation und alle VM-Disks prüfen

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 Ursache wurde im weiteren Workshop-Verlauf geklärt: Für die betroffene VM war noch ein ZFS-Replikationsjob eingerichtet. Dieser verbliebene Job verursachte die fehlgeschlagene Migration. Zusätzlich war bei der Anlage des LVM-Speichers zunächst der Haken bei „Shared“ vergessen worden.

Für den Wechsel auf den gemeinsamen iSCSI-Speicher wurden deshalb folgende Punkte umgesetzt:

1. Shared aktivieren: Den tatsächlich auf allen Knoten erreichbaren LVM-Speicher als gemeinsam genutzt markieren.
2. Keine bisherigen ZFS-Replikationsjobs zurücklassen: Die für die umgestellte VM eingerichteten Jobs unter „Replication“ entfernen und deren Entfernung abwarten. Die native lokale ZFS-Replikation wird für die nun gemeinsam genutzten iSCSI-Disks nicht benötigt.
3. Alle Disks migrieren: Neben der System- und den Datenfestplatten auch die EFI-Disk und eine gegebenenfalls vorhandene TPM-State-Disk auf den gemeinsamen Speicher verschieben. Bestehende EFI- und TPM-Datenträger übernehmen, nicht neu erstellen.

Danach liefen alle Migrationen tadellos. Dieses Ergebnis wurde nachträglich aus dem Workshop bestätigt; die eingebetteten Screenshots zeigen noch die vorherigen Zwischenstände.

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 sichtbare Replikationsjob von VM 111 nach pve2 gehört noch zum aufgenommenen Zwischenstand. Der Klonabschluss ist nicht abgebildet; die anschließend fehlerfrei laufenden Migrationen wurden nachträglich bestätigt.

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.
• Shared ist aktiviert; auf allen Knoten ist tatsächlich derselbe Speicher erreichbar.
• Für die auf iSCSI umgestellten VMs sind keine bisherigen ZFS-Replikationsjobs mehr eingerichtet.
• Sämtliche VM-Disks einschließlich EFI und gegebenenfalls TPM liegen auf dem gemeinsamen Speicher.
• 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

Bewährte Konfiguration für weitere Migrationen übernehmen

1. Multipath-Dateien vereinheitlichen: Prüfe die Konfiguration und die registrierten WWIDs auf allen Hosts. Vergleiche vorhandene Inhalte, bevor Dateien überschrieben werden.
2. Shared und Replikationsjobs prüfen: Im Workshop war Shared zunächst vergessen worden; ein verbliebener ZFS-Replikationsjob verursachte den Migrationsabbruch. Bei weiteren Umstellungen Shared aktivieren und bisherige ZFS-Replikationsjobs der betroffenen VM entfernen. Bei neuen Fehlern zusätzlich das vollständige Migrationslog auswerten.
3. Alle VM-Datenträger berücksichtigen: Verschiebe neben der Systemfestplatte auch Daten-, EFI- und gegebenenfalls TPM-State-Disks auf den gemeinsamen Speicher.
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.

Round Robin aktivieren: beide gleichwertigen SAN-Pfade nutzen

Round Robin verteilt I/O reihum auf die Pfade einer aktiven Pfadgruppe. Bei gleichwertigen Verbindungen kann dies beide SAN-Links besser auslasten. Eine Verdopplung der Leistung ist nicht garantiert; service-time kann bei unterschiedlich schnellen oder belasteten Wegen günstiger sein.

Der gezeigte Stand hat je Pfad eine eigene Gruppe. Der Selektor allein genügt daher nicht. Nur wenn beide Wege gleichzeitig gleichwertig nutzbar sind, eignet sich multibus für eine gemeinsame Gruppe. Bei ALUA- oder Active/Passive-Systemen die herstellergerechte Gruppierung beibehalten.

Auf jedem Node den bestehenden Eintrag dieser LUN in /etc/multipath.conf ergänzen; übrige Konfiguration erhalten:

multipaths {
    multipath {
        wwid 36589cfc00000005cf4f3f236e1d7b5b0
        path_grouping_policy multibus
        path_selector "round-robin 0"
        rr_weight uniform
        rr_min_io_rq 1
    }
}

rr_min_io_rq 1 bewirkt bei request-basiertem Multipath einen Wechsel nach einer I/O-Anforderung. Das Beispiel verändert keinen Gerätealias.

Im Wartungsfenster zunächst die aufgelöste Konfiguration auf Fehler prüfen, dann neu laden:

multipath -t
multipathd reconfigure
multipath -ll

Erwartet: round-robin 0 und beide gesunden Pfade in derselben aktiven Gruppe. Danach Durchsatz, Latenz und Pfadausfall mit einer Test-VM prüfen. Die Option ist eine Optimierungsempfehlung, kein im Workshop belegter Änderungsschritt. Parameterreferenz: Debian-Handbuch zu multipath.conf.