iSCSI Target per Powershell skript regelmäßig neu verbinden (Synology + Server 2016)

[taeddyyy]

Hallo Zusammen,

ich stehe vor folgendem Problem.
Zuerst mal die Config:

Ein NAS hat 1 eingerichtetes LUN, auf welches 2 iSCSI Targets zeigen. Target 1 mit Rechten Lesen/Schreiben, Target 2 nur lesen.
1. Server Windows Server 2016, Target 1 verbunden, um von dort Daten auf das LUN zu schreiben.
2. Server Windows Server 2016, Target 2 verbunden, um von dort Daten vom LUN zu lesen.
Hintergrund ist, dass Benutzer auf Server 2 Daten einsehen sollen, aber aus Sicherheitsgründen nicht schreiben dürfen. Bestimmte Personen sollen von Server 1 aus das Laufwerk mit Daten füllen.

Auf beiden Servern sind weitere Targets verbunden, die auf andere Luns zeigen. Diese sollen dauerhaft verbunden bleiben.

Wenn ich nun Daten von Server 1 auf das LUN schreibe, werden die Daten auf Server 2 erst angezeigt, wenn ich das iSCSI Target auf Server 2 neu verbinde.
Ich würde gerne, dass dieser Vorgang vom Server 2 automatisch vorgenommen wird. Wäre es möglich, dies über ein Powershell Skript zu lösen, und wäre es überhaupt sinnvoll?
Eine Freigabe auf dem NAS fällt raus, es muss zwingend über iSCSI geschehen. mit regelmäßig meine ich, das im Abstand von bspw 10 Minuten neu verbunden wird. Eine "realtime" Lösung ist nicht notwendig.
Kann es durch das ständige aus und einhängen zu Nachteilen kommen?

Würde mich über Lösungsansätze freuen, im Rahmen auch alternative Lösungen.

Gruß

 

[taeddyyy]

Folgendes Miniscript:

Get-IscsiTarget | where {$_.NodeAddress -like "Name"} | Disconnect-IscsiTarget -confirm:$false
Start-Sleep -s 10
Get-IscsiTarget | where {$_.NodeAddress -like "Name"} | Connect-IscsiTarget

damit erreiche ich den gewünschten Effekt, würde es irgendwie zu Nachteilen kommen, wenn dieses Script alle 10 Minuten ausgeführt wird?

 

[Gelöschtes Mitglied 184103]

Ist das nicht reichlich kompliziert? Wäre es nicht einfacher die Sache über NTFS Berechtigungen zu regeln?
Ich weiß ja nicht was für Daten darauf liegen aber wenn ggf. eine Applikation gerade eine Datei im Zugriff hat und dein Skript das Volume unterm Popo weg zieht wäre das unter Umständen nicht so toll.

 

[taeddyyy]

Es werden nur Dokumentationen abgelegt, die dann von Nutzern über Server2 abgerufen und angeschaut werden, sprich .pdf und .docx formate, die Nutzer können bis auf lesen wie gesagt nichts mit dem Laufwerk anfangen.
Keine weiteren Anwendungen werden das Laufwerk benutzen. Das Laufwerk ist im Server als Schreibgeschützt markiert.
Was wäre im Worstcase möglich? Beispiel User1 hat eine .pdf mit Acrobat Reader geöffnet, User2 eine .docx in Word
Das Skript wird in diesem Moment ausgeführt, Target wird entfernt (ca 10 sek. Dauer), Target wird neu hinzugefügt (ca. 10 sek. Dauer)
Mögliche Folgen?

 

[Gelöschtes Mitglied 184103]

Naja ich denke die meisten Probleme werden wohl auftreten wenn Dateien in dem Moment geöffnet werden wenn das Skript durch läuft.
Das fängt bei blöden Meldungen für den Benutzer an, kann zu Hängern im Explorer führen, ggf. läuft das Skript nicht durch weil irgendein Handle auf die Datei ein unmounten verhindert u.s.w.
Da fällt mir ein stink normales NTFS auf einer LUN zu nutzen, auf die von mehreren Servern zugegriffen wird, kann auch zu Problemen führen.

Alles in allem halte ich den Ansatz für einigermaßen Banane.

 

[besterino]

iSCSI ist eigentlich kein Protokoll für "shared access", egal ob einer von zweien nur lesend zugreift.

Wenn eine Freigabe vom NAS ausgeschlossen ist (sinnvoll), was spricht denn gegen eine SMB-Freigabe von dem Server, dem die LUN primär gehört (also der schreiben darf)? Das wäre jedenfalls normal & supported, wenn nicht sogar "best practice".

Oder wenn's denn unbedingt "nur" iSCSI sein muss: Vielleicht kannst Du auch einen cluster aus Server1 + Server2 bauen und das iSCSI-Ding als cluster shared volume (CSV) definieren, da haste dann die nötige Logik an Bord... (ich finde, das sollte einen Bonus-Punkt für kreatives Denken geben...)

 

[taeddyyy]

Danke für die Ansätze und Meinungen. Die server haben keine Verbindung zum selben Netz, arbeiten auch in ganz anderen IP-Adress bereichen, sie sind lediglich jeweils per ethernet direkt an das NAS angeschlossen, hauptsächlich als Backup Ziel und eben auch für oben genannten Zweck. Ich widme mich am Mittwoch nochmal dem Problem, morgen gibts erstmal nen kleinen.

 

[besterino]

Ok, da scheidet SMB von Server 1 und Cluster auch aus. Schade.

Trotzdem würde ich iSCSI „Freigaben“ für sowas lieber vermeiden. Dann - falls sich die Datenmenge in Grenzen hält - lieber eine zusätzliche SMB-Share auf dem NAS einrichten und per rsync o.ä. die zu teilenden Daten dahin einfach im gewünschten Intervall vom Hauptserver (iSCSI-Share) zum SMB-Share re- bzw. duplizieren (Zeitverzögerung ist ja für Dich kein Thema).

Ist aber auch nur eine unausgegorene Idee.