ISCSI Target auf Linux

[MisterY]

Hi,

Ich habe hier zwei Proxmox-Nodes in einem Cluster und eine Workstation. Weiterhin habe ich noch einen Fileserver, wo OMV 3 mit mergerfs und Snapraid läuft. Hier soll noch ein ZFS-RaidZx hinzugefügt werden, das ist aber erstmal irrelevant.

Ich möchte gerne auf dem Fileserver neben der SMB und NFS-Freigabe, noch eine ISCSI Freigabe erstellen, sodass ich a) dies in Proxmox einbinden kann um dort VMs/LXCs zu speichern und b) dies direkt in meine Win10 Workstation einbinden kann um dort per 10GBe Programme zu installieren.

Jedoch gibt es keine gescheite Anleitung, da ISCSI wohl irgendwie veraltet zu sein scheint. Das OMV-ISCSI Plugin z.B. funktioniert auch nicht (mehr) und NAS4Free/FreeNAS möchte ich nicht verwenden, da ich nicht alle Platten in ein ZFS verwandeln möchte. Unraid kann nativ auch kein ISCSI.

Habt ihr Tipps/Anleitungen?

grüße

 

[besterino]

...ich hab das vor einiger Zeit mal mit Ubuntu hingefrickelt aber echt nur bedingt Vergnügen damit gehabt. Es gibt wie immer mehrere Wege nach Rom, ich hatte mich damals für die Einrichtung mit targetcli entschieden. iSCSI verhält sich eben völlig anders als SMB/NFS shares - du musst da in targetcli u.a. Targets, LUNs und Berechtigungen setzen (siehe Beispiel hier). Da muss man sich wirklich etwas reinfuxxen, bis es dann läuft.

Hatte das zwar dann irgendwie am laufen, aber iSCSI war ein weiterer Grund, warum ich zu Solaris gewechselt bin. Da muss man sich zwar auch ein wenig einarbeiten, das beschränkt sich aber im Prinzip auf ein bisserl Netzwerk-Konfig und dann geht alles irgendwie "einfach so" (mit napp-it).

 

[MisterY]

kann ich nicht einen kompletten Pool als ISCSI einbinden? Oder muss ich dafür so eine "virtuelle Disk" erstellen mit einer bestimmten Größe?

 

[gea]

Ein ISCSI Target ist ein Blockdevice wie eine Festplatte. Es wird auch wie eine lokale Festplatte eingebunden und verhält sich auch wie eine Festplatte, hat damit immer eine Größe. Ohne eine zusätzliche Clustersoftware kann auf ein Target auch immer nur von einem Computer zugegriffen werden.

Ein iSCSI Target basiert auf einer Datei oder einer physikalischen Festplatte, im Fall von ZFS auch auf einem Zvol mit bestimmter Größe (Ein Zvol ist ein ZFS Dateisystem das als Blockdevice wie eine Platte angesprochen wird.)

Ein Pool hat keine bestimmte Größe und kann damit nicht Grundlage eines iSCSI Targets sein.

 

[MisterY]

Danke für die Erklärung.
Was wäre denn eine Clustersoftware, die das könnte?

Wäre es alternativ möglich auch mehrere zvols zu erstellen und diese dann als je ein Target zu nehmen?

Und ist es möglich die Daten auch am Host auszulesen, bspw mit midnight command?

 

[gea]

1.
Für ZFS z.B. RSF-1 von high-availabilty.com
Die regelt dass nur ein HA Node darauf zugreift

2.
Ja, werden einfach als mehrere Platten genutzt
Wozu?

3.
Ja, der Host könnte das Target (exclusiv) per Initiator mounten.
Er müsste halt das Dateisystem lesen können. Das Target ist ja
wie eine lokale Platte. Windows packt da z.B. ntfs drauf.

 

[besterino]

Wenn ich das so lese, stellt sich aus meiner Sicht erst einmal die Frage, was Du eigentlich erreichen willst.

Grundidee: iSCSI=exklusiver-primär-Storage für "eine Kiste", also eben NICHT zum "Teilen" mit mehreren Nutzern (im Sinne von physischen Kisten oder VMs, einschließlich Host) gedacht.

Ohne weitere Infos zum Einsatzzweck wage ich einmal zu bezweifeln, dass sich das Einlesen in bzw. Einsatz eines Cluster-FS lohnt. Kenne natürlich Deinen Background nicht. Aber ich (als "enthusiastischer Laie" ) habe damit mal angefangen und es dann aber auch sehr schnell wieder verworfen. Zu komplex für zu wenig Mehrwert - außerhalb eines eher überschaubaren Einsatzes wie bei Hyper-V's Cluster-Volume (da managed Windows eben die Zugriffe und Syncs mit allen Nodes, je nach Konfig mit einer sog. Witness Disk).

Um auf Deine Frage zurück zu kommen: ob Dein Host das "lesen" kann, hängt davon ab, dass er a) überhaupt das iSCSI-Target verarbeiten kann und b) das Filesystem da drauf/drin lesen kann. Im Prinzip muss man sich das wie eine physische Platte vorstellen: kommst Du nicht drauf (weil gar nicht im System angeschlossen=eingebunden), kommste nicht weiter und ist sie "physisch" da aber das OS versteht das Filesystem nicht (Ext4/ZFS unter Windows), kommst Du auch nicht weiter.

Grundsätzlich kannst Du also ein iSCSI-Share von System A trennen und in System B einhängen und dann dort bearbeiten, wie als würdest Du eben eine Festplatte in A ausbauen und in B einbauen.

EDIT: gea war schneller.

Nur eine kleine Ergänzung: Mehrere iSCSI-Targets/LUNs ist wohl sogar der klassische Weg. Auch die dicken SANs von EMC stellen eben gerne zig iSCSI-Targets für die Serverfarm bereit, die dann die einzelnen Server eben für Ihre Dienste benutzen. Da überlässt die hardcore Fileserver-Aufgaben (caching, performance tuning, deduplication usw.) eben lieber dedizierter Hardware.

Ein fetter Exchange bekommt dann eben seinen Speicher auf der SAN als iSCSI-Target wie auch z.B. ein billiger Windows-Fileserver.

Ganz gute Einführung zum Quorum in Clustern: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731739(v=ws.11)

 

[MisterY]

Erstmal danke für eure Ausführungen

Was ich machen möchte:
Der Fileserver soll als Speicherort für fast alles dienen: mergerfs und snapraid für Mediendateien und backups, zfs für Installation von Programmen der Workstation und vms, um diese ggf zwischen zwei nodes hin und her zu verschieben.

Die Workstation, ebenfalls in einem 19" Gehäuse, soll nur SSDs haben. Ich möchte die Daten halt so gut es geht zentralisieren. Backups der wichtigen Daten werden natürlich sowohl @home als auch außerhalb gespeichert.

 

[jdl]

Ein ISCSI Target ist ein Blockdevice wie eine Festplatte. Es wird auch wie eine lokale Festplatte eingebunden und verhält sich auch wie eine Festplatte, hat damit immer eine Größe. Ohne eine zusätzliche Clustersoftware kann auf ein Target auch immer nur von einem Computer zugegriffen werden.

Das ist nicht korrekt. iSCSI erlaubt den Zugriff von mehreren Computern, wenn man das geeignete Filesystem darauf nutzt. Für Linux gibt es das GFS2 was für solche gesharten Volumes geeignet ist. Die iSCSI Targets auf dem Server können Dateien fester Größe sein oder echte Partitionen, letzteres ist Performanter. Ein ClusterFS ist eine ganz andere Baustelle und dient in erster Linie dazu die Performance anzuheben.

- - - Updated - - -

Was wäre denn eine Clustersoftware, die das könnte?

Das Hauptproblem bei allen diesen Überlegungen ist es, dass man ein FS braucht was von allen Betriebssystemen verarbeitet werden kann. Was nützt Dir auf Linux ein GFS2, wenn das kein anderes OS lesen kann für das Du iSCSI nutzen willst? Analog verhält es sich so, wenn man Lustre, GlusterFS, ExtreemFS, BeeGFS, … denn nur Clients mit dem passenden Treiber können auf die Volumes zugreifen. Wenn es sich rein um Linux handelt ist das üblicherweise kein Problem. Wenn man zwischen verschiedenen OS Daten teilen muss, läuft das üblicherweise auf SMB oder NFS hinaus.

 

[Digi-Quick]

Das ist nicht korrekt. iSCSI erlaubt den Zugriff von mehreren Computern, wenn man das geeignete Filesystem darauf nutzt. Für Linux gibt es das GFS2 was für solche gesharten Volumes geeignet ist. Die iSCSI Targets auf dem Server können Dateien fester Größe sein oder echte Partitionen, letzteres ist Performanter. Ein ClusterFS ist eine ganz andere Baustelle und dient in erster Linie dazu die Performance anzuheben.

No Sir.
SCSI ist seit jeher eine exklusive Punkt zu Punkt Verbindung zwichen Initiator und Target.
Multipathing ist eine Erweiterung.

 

[jdl]

No Sir.
SCSI ist seit jeher eine exklusive Punkt zu Punkt Verbindung zwichen Initiator und Target.
Multipathing ist eine Erweiterung.

Und was hat das nun mit meiner Aussage zu tun? SCSI erlaubte schon immer mehrere Initiators an einem Bus.

 

[gea]

Ich denke doch, das entscheidende Merkmal ist dass iSCSI selbst keinerlei Schutz davor bieten dass beim mehrfachen Zugriff immer der letzte Zugriff gewinnt oder dass beim gleichzeitigem Zugriff das Target-Dateisystem geschrottet sein könnte.

Damit simultaner Zugriff funktioniert muss der gleichzeitige Zugriff auf Ebene der Initiatoren untereinander geregelt werden (Cluster Software). Lediglich Multi-User Services wie SMB oder NFS regeln das eigenständig.

 

[bigghost]

Habe die Tage selber mit Proxmox und ISCSI gespielt.
Wenn man ein Storage hat was ISCSI vernünftig bereit stellt ist das in 5min erledigt.
ISCSI unter Linux mounten – Thomas-Krenn-Wiki
Aber nur Software wie nappit,nas4free/freenas finde ich vernünftig.Weil man hier problemlos das Blockdevice vergrößern und verwalten kann.
Bei Proxmox im Cluster mit mehreren Nodes kann man ganz gut das Blockdevice per ISCSI ranholen und per LVM nutzen ohne Filesysteme.
ISCSI ist schneller als SMB/NFS etc. aber wie ich finde nur für separierte Anwendungen gut nutzbar.
Jede Art von Clusterfilesytem bedeutet Aufwand. Da ist es einfacher NFS einzusetzen.

 

[jdl]

Ich denke doch, das entscheidende Merkmal ist dass iSCSI selbst keinerlei Schutz davor bieten dass beim mehrfachen Zugriff immer der letzte Zugriff gewinnt oder dass beim gleichzeitigem Zugriff das Target-Dateisystem geschrottet sein könnte.

Der Punkt ist, dass das über eine spezielle Protokollerweiterung (es kommt eine Netzwerkversion eines LVM zum Einsatz) für GFS2 die Synchronisierung erfolgt. D.h. es wird eben kein spezielles iSCSI benötigt. Wie gesagt schon bei allerersten SCSI für Computer konnte man mehr als einen HBA an einem Bus haben. Nur wurde das de facto von keinem Anbieter wirklich unterstützt. Bei SAS wird genau das gemacht, d.h. man kann JBODs so verkabeln, dass sie von zwei Hosts parallel angesteuert werden können. Es braucht dazu ein spezielles FS und die notwendige Synchronisation zwischen den Hosts. IBM nutzt das für das eigene ClusterFilesystem aus. Wenn ein Server ausfällt, dann verliert man nur Bandbreite und der komplette Storage ist weiterhin verfügbar.

Damit simultaner Zugriff funktioniert muss der gleichzeitige Zugriff auf Ebene der Initiatoren untereinander geregelt werden (Cluster Software). Lediglich Multi-User Services wie SMB oder NFS regeln das eigenständig.

Nein, die bekommen das in der Regel eben nicht hin. Bei NFS bis zur Version 4.1 mit der pNFS Erweiterung kann nur immer ein NFS-Server aktiv sein und auf die Storage Devices zugreifen. Selbst wenn man ein GFS2 Blockdevice hat und zwei Server anhängt, darf der NFS Server nur auf einem der beiden aktiv sein, sonst zerstört NFS den Datenbestand, obwohl GFS2 die Daten ordentlich synchronisiert.

Ein echtes ClusterFS hat mit so etwas keinerlei Probleme, wenn da ein Server ausfällt verliert man üblicherweise nur Performance. Bei den ClusterFS wird aber bereits im Client der Datenstrom auf die verschiedenen MDSs und OSSs verteilt, das geschieht bei GFS2 nicht.

 

[gea]

Wir sprechen über unterschiedliche Dinge.
bei meinem Beitrag ging es nicht um Clusterlösungen sondern um einen simplen NFS Datastore für mehrere VMs vs einem simplen Datastore für mehrere VMs auf einen iSCSI Target - jeweils auf ZFS.