Solaris & iSCSI

[besterino]

Hallo zusammen! Vielleicht etwas zu speziell für den ZFS-Sammler, daher meine Frage mal separat hier:

Ausgangslage:
Solaris 11.3 Storage Server
2 Pools (Pool1 / Pool2)

Ziel:
Ich möchte auf beiden Pools jeweils ein iSCSI-"Share" anlegen, die aber jeweils mit dem Windows iSCSI-Initiator von verschiedenen PCs aus getrennt und auch nur einzeln ansprechbar sind.

Geht das, ohne komplizierte Anmeldeverfahren einsetzen zu müssen?

Hintergrund:
Wenn ich aktuell mit dem iSCSI-Initiator von Windows eine Verbindung herstelle, tauchen beide Shares auf beiden Rechnern als Laufwerke in der Datenträgerverwaltung auf. Wahrscheinlich würde es reichen, wenn ich jeweils die auf einem Rechner nicht benötigten Laufwerke auf offline stelle - das ist mir aber irgendwie zu heikel. Ich hätte daher gerne, dass ich jeweils ein bestimmtes Target auswähle, dem dann auch (ausschließlich) nur ein iSCSI-Share (LUN?) zugewiesen ist.

Hab jetzt schon Verschiedenes ausprobiert, aber irgendwie gelingt es mir nicht. Erreiche eher ein fröhliches Kuddelmuddel und zwischenzeitlich hatte ich sogar eine LUN (?) dreifach in der Datenträgerverwaltung... (nach reboot dann immerhin nur noch 1x).

Vor allem bin ich mir noch nicht sicher, ob ich dafür jetzt verschiedene Host Groups und/oder Target Groups brauche oder ob/wie ich nicht einfach stumpf eine Lun->einem Target-->einer View zuordnen könnte?

 

[besterino]

Hmm... sieht so aus, als käme ich um host groups und target groups nicht herum:

Making SCSI Logical Units Available - Managing Devices in Oracle® Solaris 11.3

How to Make a Logical Unit Available to All Systems How to Restrict Logical Unit Access to Selected Systems

docs.oracle.com

 

[gea]

Mehrere Host Groups wird der Schlüssel sein.
Einer Host Group kann man einzelne Rechner (iqn) hinzufügen.

Dann ein oder mehrere Logical Unit erstellen, und mit einem View entweder auf die eine oder andere Gruppe versehen. Die Rechner sehen dann nur die Lun der Logical Unit(s) die ihrer Host Group zugewiesen ist.

 

[besterino]

Jupp. Ich hatte noch gehofft, nicht die iqns der Clients verwalten zu müssen...

Mal schauen, ob ich das mach oder nicht doch einfach die Disks jeweils offline nehme.

 

[gea]

Nunja, wenn zwei Clients ohne Kontrolle einer Clustersoftware gleichzeitig auf ein LUN zugreifen, ist ein korruptes LUN garantiert. Das händisch zu verwalten führt sicher irgendwann zum Crash.

Neben den Host Groups die den Zugriff basierend auf der Client iqn regeln, gäbe es noch Target Portal Groups. Damit kann man festlegen auf welcher ip ein Lun zur Verfügung gestellt wird, ist aber sicher noch aufwändiger.

Dritte Option wäre es wenigstens ein chap Passwort zu vergeben das man am Host zusätzlich für den Zugriff auf ein Target einstellen muss, eventuell mit je einem Target per Client.

Host Groups wäre aber die sicherste Methode. Man muss halt zum Switchen die View (Logical Unit -> Host Group) umschalten. Das Einstellen ist ja mehr oder weniger ein Copy and Paste zwischen Client und z.B. napp-it Menü Comstar > Host Groups.

 

[besterino]

Keine Ahnung ob's jetzt daran lag oder nicht der ebenfalls gerade erfolgte Crash einer VM mit verbundenem iSCSI-Share daran schuld war: musste jedenfalls ein iSCSI-Share neu formatieren, dass mit zwei Clients verbunden aber bei einem offline gesetzt war.

Hab's jetzt also in der Tat sauber(er) über die Host Groups und Target Groups gelöst:

Zwei LU erstellt LUN1 für Client1 und LUN2 für Client2 und für jede LUN ein eigenes Target.

Dann für jeden Client eine eigene Host Group (z.B. HG1 mit dann nur einem Member, z.B. iqn.Client1) und vorsichtshalber auch eine eigene Target Group (z.B. TG1 mit ebenfalls nur einem Target, z.B. Target1-für-Client1) erstellt.

Schließlich dann eine View für jedes Target und dabei dann die entsprechende Host und Target Group ausgewählt (z.B. LUN1 mit HG1 und TG1).

Funktioniert wohl: die verschiedenen Targets erscheinen direkt im Windows iSCSI-Initiator und bei Auswahl taucht dann auch artig nur eine LUN (und die richtige ) in der Datenträgerverwaltung des jeweiligen Clients auf. Gegenprobe: Selbst wenn ich den "falschen" Client mit dem "falschen" Target verbinde, taucht die LUN nicht als Laufwerk in der Datenträgerverwaltung auf. So soll's sein!

Ich liebe Solarish.

 

[Ceiber3]

Wie ist der Speed so ?

 

[besterino]

Ausreichend für meine Zwecke:

Kopiervorgang 20GB-File von iSCSI-Share auf "lokale" m.2 (Intel 660p) (max. ca. 1,5GB/s):
Anhang anzeigen 487666

Kopiervorgang 20GB-File von "lokaler" m.2 (Intel 660p) auf iSCSI-Share (max. echtes Schreiben ca. 510MB/s):

Anhang anzeigen 487668

 

[Ceiber3]

Hmm wie kommen solche Werte zusammen ? 40G Lan ? Läuft beim lesen alles im Cache ? Warum sind die Schreibwerte 5x schlechter ?

 

[Trambahner]

Ich vermute mal AIO-ESXI. Oder via MCX456A-ECAT aus dem Deal.

 

[besterino]

Server: Solaris Storage VM auf ESXi
Client: Windows10 VM auf ESXi

Client und Server verbunden über Verbindung 100Gbit (keine Jumbo-Frames oder sonstiges Tuning), allerdings muss ich mangels Solaris-Mellanox-Treiber für SR-IOV NICs auf VMXNET3 ausweichen und das limitiert im besten Fall bei ~20-25Gbit - iperf sogar schon früher.

Storage selbst ist ein gemischter Pool aus 2x1TB SATA SSD Samsung 860 und 1x1TB Samsung SSD 840 zusammen im "Raid0" (simple). Sync-writes auf "standard".

Allerdings konnte ich - wieder mangels funktionierender Solaris-Treiber - den HBA nicht per passthrough in die Storage-VM kleben, sondern musste die Disks per RDM an die VM geben.

Da ist bestimmt noch Luft drin, aber als Storage für Games und anderen unwichtigen Krempel keine Priorität.

 

[gea]

Sync write = standard bedeutet mit NFS Sync = always.
Das erklärt die geringere Schreibperformance vs Leseperformance.

RDM bei einem SAS HBA bringt nahezu keinen Performanceverlust.

 

[besterino]

Ist aber keine NFS-Freigabe, sondern iSCSI. Gilt das da auch?

 

[gea]

Es dreht sich darum, ob sync write aktiviert ist.
Bei ESXi und NFS ist das mit sync=default oder sync=always der Fall.

Bei iSCSI ist das etwas komplizierter denn da kann man einerseits für das zvol auf dem die locical unit basiert sync erzwingen (sync=always) oder abschalten (sync=disabled)

Mit der sync=default Einstelung kommt es auf die writeback cache Einstellung des logical unit an. Ist writeback cache enabled so wird kein sync aktiviert. Ist der cache disabled so ist sicheres aber langsames sync write angesagt.

 

[besterino]

Ok, dann sollte das grds. passen und bereits "flott" sein:

LU Name: 600144F079540B0000005E17BF270002
    Operational Status     : Online
    Provider Name          : sbd
    Alias                  : (...)
    View Entry Count       : 1
    Data File              : (...)
    Meta File              : not set
    Size                   : 2791728742400
    Block Size             : 512
    Management URL         : not set
    Vendor ID              : SUN
    Product ID             : COMSTAR
    Serial Num             : not set
    Write Protect          : Disabled
    Write Cache Mode Select: Enabled
    Writeback Cache        : Enabled
    Access State           : Active

 

[gea]

400 MB/s mit aktiviertem sync write sind mit einem schnellen Pool und einer Optane Slog gerade so noch möglich.