IScsi from scratch, Grundsätzliche (Verständnis) Fragen
Moin,
ich bin hier neu und würde gerne von Eurem Fachwissen profitieren. Ich habe schon ein wenig im Forum gesucht, aber keine, für mich, passenden Antworten gefunden.
Ich habe da mal ein paar, wahrscheinlich totale Anfängerfragen zu iScsi. Ich möchte ein wenig weiter in iScsi Materie eintauchen und das ganze etwas umfangreicher einsetzen. Gibt es irgendwelche "Literatur" o.ä. die man da mal zur Hilfe nehmen kann? (Das ganze soll später mal in einem Windows Server 2012 R2 (oder neuer) Umfeld laufen)
Zu meinem bisherigen Wissen: Bisher habe ich iScsi auf einer SynologyNAS (target) in Verbindung mit einem VM-Ware ESXi in der einfachsten Form verwendet.
Will sagen: Ein iScsi target und einen nutzenden iScsi-Initiator.
Mein Verständnis von iScsi bisher war immer, das iScsi im Grunde ein Scsi ist welches über (ethernet) TCP/IP angebunden wird.
Daraus würde sich dann, soweit ich bisher vermutete, ergeben, dass ich nur von einem Initiator schreibend darauf zu greifen sollte(kann), da iScsi ja ein block-level-protokoll/block-device ist?
Jetzt ist es so, dass mir immer erzählt wird, dass das seit WinServer 2012 R2 alles anders ist und iScsi von mehreren Initiatoren gleichzeitig genutz werden kann und alle parallel darauf schreiben und lesen können und zwar ohne die Verwendung von CVS oder anderen Clusterfähigen Dateisystemen! Ist das so? Gibt es iwo dazu Informationen , HowTo's o.ä,?
Alles was dann bisher dazu gesagt wurde war dann irgendwas zu SMB3 und MPIO. Und an dieser Stelle verliere ich dann iwie den Anschluß:
SMB3 ist ein sharing Protokoll, welches mit iScsi erstmal nichts zu tun hat, oder täusche ich mich da?
MPIO ist MultiPath I/O? MPIO bezeichnet doch nur ein redundante Anbindung über mehrere NICs und hat nichts mit Zugriffen von unterschiedlichen Initiatoren auf das target zu tun?
(Was ich bisher, auf unterschiedlichen InetSeiten in unterschiedlicher Form gelesen habe ist, dass es wohl möglich ist auf einem Host ein Laufwerk über einen iScsi-Initiator einzubinden und diesen dann über SMB3 freizugeben. Das erscheint mir soweit auch einleuchtend, da sich SMB3 in diesem Fall um die Konsistenz der Daten kümmern sollte.)
Vllt ist ja einer von Euch in der Lage ein wenig Struktur und Licht in das Durcheinander meines Halbwissens zu bringen.
Danke
MfG
PS: Ich hoffe, ich habe meine Frage in das richtige Thema einsortiert.
ich bin hier neu und würde gerne von Eurem Fachwissen profitieren. Ich habe schon ein wenig im Forum gesucht, aber keine, für mich, passenden Antworten gefunden.
Ich habe da mal ein paar, wahrscheinlich totale Anfängerfragen zu iScsi. Ich möchte ein wenig weiter in iScsi Materie eintauchen und das ganze etwas umfangreicher einsetzen. Gibt es irgendwelche "Literatur" o.ä. die man da mal zur Hilfe nehmen kann? (Das ganze soll später mal in einem Windows Server 2012 R2 (oder neuer) Umfeld laufen)
Zu meinem bisherigen Wissen: Bisher habe ich iScsi auf einer SynologyNAS (target) in Verbindung mit einem VM-Ware ESXi in der einfachsten Form verwendet.
Will sagen: Ein iScsi target und einen nutzenden iScsi-Initiator.
Mein Verständnis von iScsi bisher war immer, das iScsi im Grunde ein Scsi ist welches über (ethernet) TCP/IP angebunden wird.
Daraus würde sich dann, soweit ich bisher vermutete, ergeben, dass ich nur von einem Initiator schreibend darauf zu greifen sollte(kann), da iScsi ja ein block-level-protokoll/block-device ist?
Jetzt ist es so, dass mir immer erzählt wird, dass das seit WinServer 2012 R2 alles anders ist und iScsi von mehreren Initiatoren gleichzeitig genutz werden kann und alle parallel darauf schreiben und lesen können und zwar ohne die Verwendung von CVS oder anderen Clusterfähigen Dateisystemen! Ist das so? Gibt es iwo dazu Informationen , HowTo's o.ä,?
Alles was dann bisher dazu gesagt wurde war dann irgendwas zu SMB3 und MPIO. Und an dieser Stelle verliere ich dann iwie den Anschluß:
SMB3 ist ein sharing Protokoll, welches mit iScsi erstmal nichts zu tun hat, oder täusche ich mich da?
MPIO ist MultiPath I/O? MPIO bezeichnet doch nur ein redundante Anbindung über mehrere NICs und hat nichts mit Zugriffen von unterschiedlichen Initiatoren auf das target zu tun?
(Was ich bisher, auf unterschiedlichen InetSeiten in unterschiedlicher Form gelesen habe ist, dass es wohl möglich ist auf einem Host ein Laufwerk über einen iScsi-Initiator einzubinden und diesen dann über SMB3 freizugeben. Das erscheint mir soweit auch einleuchtend, da sich SMB3 in diesem Fall um die Konsistenz der Daten kümmern sollte.)
Vllt ist ja einer von Euch in der Lage ein wenig Struktur und Licht in das Durcheinander meines Halbwissens zu bringen.
Danke
MfG
PS: Ich hoffe, ich habe meine Frage in das richtige Thema einsortiert.
Please also mark the comments that contributed to the solution of the article
Content-Key: 479718
Url: https://administrator.de/contentid/479718
Printed on: April 24, 2024 at 23:04 o'clock
4 Comments
Latest comment
Hi
Grundsätzlich würde ich davon Abraten ein Windows System als iSCSI Target zu verwenden, es sei denn du brauchst nichts an Leistung, denn "Durchsatzwunder" auch mit SSD Backend sind Windows Systeme nie.
Das iSCSI Protokoll verpackt die "Blöcke" in TCP Pakete und sendet diese dann mit allen vor- und nachteilen über eine reguläre TCP Verbindung hin und her, ist zwar ähnlich einem Blocklevel-Transfer aber im Vergleich zu FibreChannel mit gleicher Bandbreite eher dürftig (Payload je Paket ist schlechter bei iSCSI wegen dem Protkoll) - aber deutlich günstiger.
MuliPass - äh MultiPath (sry 5th Element ... ) ermöglicht die redundante Anbindung mehrer Pfade, die je nach Technik und Hersteller parallel oder auch sequentiell genutzt werden können, ich konnte bisher keinen Nennenswerten Unterschied in der Geschwindigkeit feststellen, da es schlussendlich immer auf die Einzelportgeschwindigkeit ankommt 10 x 1G liefert nicht das gleiche wie 1 x 10G.
Der größte Vorteil, auch wenn man es nicht machen sollte ohne passendes Equipment, man kann das gesamte SAN über die bestehende TCP/IIP Infrastruktur betreiben und muss kein Geld für teure FibreChannel Hardware ausgeben, vor allem da die Kosten für 10/25/40/100G Equipment mittlerweile in einem Humanen Bereich ankommen und man so ggf. auch den Geschwindigkeitsvorteil von FC preisgünstig erschlagen kann.
Vom Protokoll her ist iSCSI schneller wie SMB, CIFS, NFS oder was auch immer du nutzen möchtest, ich rate allerdings zu dedizierte Netzwerkinfrastruktur wenn du kein Datacenter Switche hast die DCB können, die müssen lediglich genug Puffer haben, non-Blocking sein und Jumbo Frames unterstützen - können nahezu alle renomierten Hersteller., unter 10G Einzellinks würde ich auch nicht mehr anfangen.
Just my 2 Cent
@clSchak
Grundsätzlich würde ich davon Abraten ein Windows System als iSCSI Target zu verwenden, es sei denn du brauchst nichts an Leistung, denn "Durchsatzwunder" auch mit SSD Backend sind Windows Systeme nie.
Das iSCSI Protokoll verpackt die "Blöcke" in TCP Pakete und sendet diese dann mit allen vor- und nachteilen über eine reguläre TCP Verbindung hin und her, ist zwar ähnlich einem Blocklevel-Transfer aber im Vergleich zu FibreChannel mit gleicher Bandbreite eher dürftig (Payload je Paket ist schlechter bei iSCSI wegen dem Protkoll) - aber deutlich günstiger.
MuliPass - äh MultiPath (sry 5th Element ... ) ermöglicht die redundante Anbindung mehrer Pfade, die je nach Technik und Hersteller parallel oder auch sequentiell genutzt werden können, ich konnte bisher keinen Nennenswerten Unterschied in der Geschwindigkeit feststellen, da es schlussendlich immer auf die Einzelportgeschwindigkeit ankommt 10 x 1G liefert nicht das gleiche wie 1 x 10G.
Der größte Vorteil, auch wenn man es nicht machen sollte ohne passendes Equipment, man kann das gesamte SAN über die bestehende TCP/IIP Infrastruktur betreiben und muss kein Geld für teure FibreChannel Hardware ausgeben, vor allem da die Kosten für 10/25/40/100G Equipment mittlerweile in einem Humanen Bereich ankommen und man so ggf. auch den Geschwindigkeitsvorteil von FC preisgünstig erschlagen kann.
Vom Protokoll her ist iSCSI schneller wie SMB, CIFS, NFS oder was auch immer du nutzen möchtest, ich rate allerdings zu dedizierte Netzwerkinfrastruktur wenn du kein Datacenter Switche hast die DCB können, die müssen lediglich genug Puffer haben, non-Blocking sein und Jumbo Frames unterstützen - können nahezu alle renomierten Hersteller., unter 10G Einzellinks würde ich auch nicht mehr anfangen.
Just my 2 Cent
@clSchak
na das sind mal grundsätziche Verständnistfragen... iSCSI targets liegen normalerweise auf Storagesystemen, Windows ist dazu eher weniger in der Lage, weil Microsoft den Kram auch nur zugekauft hat. Die Synology kann
a) iSCSI bedienen, muß dafür aber auch von den Roh-Speicherplatz Speidcherplatz reservieren der am Ende als "LUN" zur Verfügung steht.
b) SMB3 bzw. CIFS nutzen, dafür wird dann halt ein weiterer Teil des Storage genutzt...
Wichtig ist nur zu verstehen, Windows ist kein Storage-OS. Um zu lernen, ok, aber um das als Server für eine größere Anzahl an Benutzer zur Verfügung zu stellen, nimmt man kein Windows... dafür haben Storagesysteme eigene, spezialiserte Betriebsyteme, selbst eine Synology DS414 kann das besser.
a) iSCSI bedienen, muß dafür aber auch von den Roh-Speicherplatz Speidcherplatz reservieren der am Ende als "LUN" zur Verfügung steht.
b) SMB3 bzw. CIFS nutzen, dafür wird dann halt ein weiterer Teil des Storage genutzt...
Wichtig ist nur zu verstehen, Windows ist kein Storage-OS. Um zu lernen, ok, aber um das als Server für eine größere Anzahl an Benutzer zur Verfügung zu stellen, nimmt man kein Windows... dafür haben Storagesysteme eigene, spezialiserte Betriebsyteme, selbst eine Synology DS414 kann das besser.