Konfiguration Multipathing mit Windows Server (Initiator) und Linux iscsitarget (iet)
Hallo Forum,
habe ein Multipathing-Setup mit Windows Server 2008 R2 als Initiator mit MPIO und einem Debian Squeeze Target mit iet.
Die Initiator-Einrichtung erfolgte anhand dieses Guides: http://www.server-log.com/blog/2011/7/26/setting-up-an-microsoft-iscsi- ...
Das Microsoft-Modul MSFT2005iSCSIBusType_0x9 wurde auch hinzugefügt und die Multipfade entsprechend der Anleitung eingerichtet. Es gibt beim Windows Server zwei dedizierte NICs für das iSCSI-Setup mit unterschiedl. IP-Adressen aus unterschiedl. Subnetzen und auf dem Debian Target zwei dedizierte NICs mit IP-Adressen aus korrespondierenden Subnetzen.
Die Kontrolle der Multipfad-Einrichtung im Windows iSCSI-Initiator Manager entsprechend der o.g. Anleitung, deutet darauf hin, dass alles ordnungsgemäß konfiguriert ist.
Zum Vergleich wurde auf dem Windows Server vom gleichen Debian Target eine LUN ohne MPIO eingebunden.
Das Problem:
Ich wollte nun Durchsatztests durchführen, um zu sehen, welchen Performancevorteil die Multipath-Anordnung bringt. Während die Kopieraktion auf die LUN ohne Multipath-Anbindung funktioniert, startet die Dateiübertragung beim Multipath-Setup laut Windows Explorer - und zwar ungefähr mit dem gleichen Durchsatz lt. Anzeige - bleibt aber kurz darauf stehen und bewegt sich dann nicht mehr. Es scheint einzufrieren. Selbst nach 20minüter Wartezeit ändern sich die Größenangaben bei den (angeblich) bereits übertragenen Daten nicht mehr.
Ich habe den Eindruck, die beiden Pfade behindern sich gegenseitig.
Hat jemand schonmal MPIO mit einem Linux-Target aufgesetzt?
Hier z.B. http://www.synology.com/support/tutorials_show.php?lang=enu&q_id=55 ... steht folgendes:
<quote>
MPIO has wider support, as it's supported by various technologies, including disk controllers, iSCSI Protocol, Fibre Channel. It also has wider support by various software companies, including Linux, VMware, and Microsoft.
</quote>
Kann es sein, dass es eben doch nur mit Devices funktioniert, die ein DSM (Device Specific Module) mitbringen?
Vielen Dank schonmal für eure antworten.
Gruß,
schlurfi
P.S.:
Bei Anleitungen zum Multipathing-Setup in einer reinen Linux-Umgebung - hier wird dann bspw. Open-iSCSI als Initiator verwendet - werden auch keine speziellen Konfigurationsschritte für ein Multipathing-Setup seitens des Targets beschrieben. Zwei NICs mit unterschiedl. IP-Adressen (korrespondierend mit denen des Initiators) sollten ausreichen. Das Mapping an alle NICs des Systems findet nach der Definition der LUNs in der iet.conf ja automatisch statt - und funktioniert ja auch lt. iSCSI-Initiator-Manager).
habe ein Multipathing-Setup mit Windows Server 2008 R2 als Initiator mit MPIO und einem Debian Squeeze Target mit iet.
Die Initiator-Einrichtung erfolgte anhand dieses Guides: http://www.server-log.com/blog/2011/7/26/setting-up-an-microsoft-iscsi- ...
Das Microsoft-Modul MSFT2005iSCSIBusType_0x9 wurde auch hinzugefügt und die Multipfade entsprechend der Anleitung eingerichtet. Es gibt beim Windows Server zwei dedizierte NICs für das iSCSI-Setup mit unterschiedl. IP-Adressen aus unterschiedl. Subnetzen und auf dem Debian Target zwei dedizierte NICs mit IP-Adressen aus korrespondierenden Subnetzen.
Die Kontrolle der Multipfad-Einrichtung im Windows iSCSI-Initiator Manager entsprechend der o.g. Anleitung, deutet darauf hin, dass alles ordnungsgemäß konfiguriert ist.
Zum Vergleich wurde auf dem Windows Server vom gleichen Debian Target eine LUN ohne MPIO eingebunden.
Das Problem:
Ich wollte nun Durchsatztests durchführen, um zu sehen, welchen Performancevorteil die Multipath-Anordnung bringt. Während die Kopieraktion auf die LUN ohne Multipath-Anbindung funktioniert, startet die Dateiübertragung beim Multipath-Setup laut Windows Explorer - und zwar ungefähr mit dem gleichen Durchsatz lt. Anzeige - bleibt aber kurz darauf stehen und bewegt sich dann nicht mehr. Es scheint einzufrieren. Selbst nach 20minüter Wartezeit ändern sich die Größenangaben bei den (angeblich) bereits übertragenen Daten nicht mehr.
Ich habe den Eindruck, die beiden Pfade behindern sich gegenseitig.
Hat jemand schonmal MPIO mit einem Linux-Target aufgesetzt?
Hier z.B. http://www.synology.com/support/tutorials_show.php?lang=enu&q_id=55 ... steht folgendes:
<quote>
MPIO has wider support, as it's supported by various technologies, including disk controllers, iSCSI Protocol, Fibre Channel. It also has wider support by various software companies, including Linux, VMware, and Microsoft.
</quote>
Kann es sein, dass es eben doch nur mit Devices funktioniert, die ein DSM (Device Specific Module) mitbringen?
Vielen Dank schonmal für eure antworten.
Gruß,
schlurfi
P.S.:
Bei Anleitungen zum Multipathing-Setup in einer reinen Linux-Umgebung - hier wird dann bspw. Open-iSCSI als Initiator verwendet - werden auch keine speziellen Konfigurationsschritte für ein Multipathing-Setup seitens des Targets beschrieben. Zwei NICs mit unterschiedl. IP-Adressen (korrespondierend mit denen des Initiators) sollten ausreichen. Das Mapping an alle NICs des Systems findet nach der Definition der LUNs in der iet.conf ja automatisch statt - und funktioniert ja auch lt. iSCSI-Initiator-Manager).
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 213366
Url: https://administrator.de/forum/konfiguration-multipathing-mit-windows-server-initiator-und-linux-iscsitarget-iet-213366.html
Ausgedruckt am: 06.05.2025 um 00:05 Uhr
14 Kommentare
Neuester Kommentar
Multipathing bezieht sich nur auf L3 Multipathing aber nicht auf L2 Multipathing, also muss dein obiges Design scheitern, es sei denn das Target arbeitet mit einem LAG nach 802.3ad / LACP, denn dort hast du ja 2 NICs in einem gemeinsamen L2 IP Netzwerk. Das wäre in diesem Netzwerk Design dann am Target zwingend erforderlich auf NIC und Switch Seite.
Die Frage die sich dann stellt ob das eigentliche L3 Multipathing dann noch greift, denn auf Target Seite wird es dann zwingend über das Hash basierte Sessionhandling beim dortigen 802.3ad LAG wieder konterkariert.
Wenn beide NICs in einer gemeinsamen L2 Domain sind, dann greifen hier wieder die Klassiker wie Link Aggregation mit 802.3ad und LACP, was natürlich dann auch entsprechend auf dem Switch eingerichtet sein muss.
Die Frage die sich dann stellt ob das eigentliche L3 Multipathing dann noch greift, denn auf Target Seite wird es dann zwingend über das Hash basierte Sessionhandling beim dortigen 802.3ad LAG wieder konterkariert.
Wenn beide NICs in einer gemeinsamen L2 Domain sind, dann greifen hier wieder die Klassiker wie Link Aggregation mit 802.3ad und LACP, was natürlich dann auch entsprechend auf dem Switch eingerichtet sein muss.
1
moin,
durchsatztests mit dem Windows Explorer? Vielleicht sind ja auch deine Platten im iSCSI Target viel zu langsam?
durchsatztests mit dem Windows Explorer? Vielleicht sind ja auch deine Platten im iSCSI Target viel zu langsam?
Hallo aqui,
verstehe nicht, was das Multipathing mit Link Aggregation oder Trunking zu tun hat. Es wird ja in vielen MP-Anleitungen - in denen es freilich in erster Linie um die Redundanz geht - sogar mit einem Setup über verschiedene Switches (eben redundante) gearbeitet. Die NICs des Targets sind m.E. nicht in einer gemeinsamen Domain, wenn sie IP-Adressen aus unterschiedl. Netzen haben, oder?
verstehe nicht, was das Multipathing mit Link Aggregation oder Trunking zu tun hat. Es wird ja in vielen MP-Anleitungen - in denen es freilich in erster Linie um die Redundanz geht - sogar mit einem Setup über verschiedene Switches (eben redundante) gearbeitet. Die NICs des Targets sind m.E. nicht in einer gemeinsamen Domain, wenn sie IP-Adressen aus unterschiedl. Netzen haben, oder?
Multipathing kann so nur in einem L3 Umfeld funktionieren und macht auch nur da Sinn. In einem L2 Umfeld funktioniert es logischerweise nicht, da es keine multiplen Pfade gibt zum Target, jedenfalls nicht aus Layer 3 Sicht.
Im reinen Layer 2 kann es so deshalb nicht funktionieren oder ist mehr oder weniger sinnlos. Der Sinn von Multipathing ist ja gerade multiple Routing Pfade zu nutzen. Redundante Switches in einem L2 Umfeld sind zwar redundant aber die redundanten Links sind durch Spanning Tree deaktiviert, übertragen also aktiv keine Daten. So kann ein Multipathing aus MS Sicht dort niemals klappen.
Im reinen Layer 2 kann es so deshalb nicht funktionieren oder ist mehr oder weniger sinnlos. Der Sinn von Multipathing ist ja gerade multiple Routing Pfade zu nutzen. Redundante Switches in einem L2 Umfeld sind zwar redundant aber die redundanten Links sind durch Spanning Tree deaktiviert, übertragen also aktiv keine Daten. So kann ein Multipathing aus MS Sicht dort niemals klappen.
1
Hallo Knorki,
Es geht ja erstmal darum, dass die Kopieraktion sauber durchgeführt wird. Die tatsächliche Messung erfolgt dann mit besseren Tools.
Wie würde man dann erklären, dass die Übertragung auf die hardwaremäßig gleichartige LUN, die ohne MPIO angebunden ist, ca. 11min. dauert, während die Übertragung auf die LUN per MPIO eingefroren zu sein scheint?
Es geht ja erstmal darum, dass die Kopieraktion sauber durchgeführt wird. Die tatsächliche Messung erfolgt dann mit besseren Tools.
Vielleicht sind ja auch deine Platten im iSCSI Target viel zu langsam?
Wie würde man dann erklären, dass die Übertragung auf die hardwaremäßig gleichartige LUN, die ohne MPIO angebunden ist, ca. 11min. dauert, während die Übertragung auf die LUN per MPIO eingefroren zu sein scheint?
Ich habe in dem Test-Setup die beiden NICs vom Initiator kommend und die beiden NICs vom Target kommend alle in einen dummen Hub gesteckt - der nichts von LACP o.ä. weiß. Jumbo-Frames funktionieren.
Sollte ich es mal mit zwei getrennten dummen Hubs versuchen und jeweils die zugehörigen NICs miteinander verbinden?
Sollte ich es mal mit zwei getrennten dummen Hubs versuchen und jeweils die zugehörigen NICs miteinander verbinden?
Moin,
es funktioniert wenn du zwei seperate L2 Switches nimmst und zwei getrennte Subnetze (192.168.1.0/24 und 192.168.2.0/24).
Und von Hubs lassen wir die Finger. Bitte nur noch Switches nutzen.
Grüße,
Dani
es funktioniert wenn du zwei seperate L2 Switches nimmst und zwei getrennte Subnetze (192.168.1.0/24 und 192.168.2.0/24).
Und von Hubs lassen wir die Finger. Bitte nur noch Switches nutzen.
Grüße,
Dani
1
Hallo Dani,
ich habe dieses Modell: http://www.tp-link.com.de/products/details/?categoryid=224&model=TL ...
Wohl eher kein L2-Switch, oder? Es steht jedenfalls nirgends in der Produktbeschreibung etwas von L2.
ich habe dieses Modell: http://www.tp-link.com.de/products/details/?categoryid=224&model=TL ...
Wohl eher kein L2-Switch, oder? Es steht jedenfalls nirgends in der Produktbeschreibung etwas von L2.
Das mit den Hubs ist ja nun denkbar unsinnig. Falscher kann mans ja kaum noch machen.
Wenn das dann ein ARP gibt auf eine IP die im selben IP Netz aber in der gleichen L2 Doamin liegt kommt ja immer nur ein Repy einer einzigen NIC.
In so einem konstrukt kann niemals ein Multipathing oder auch nur Link Aggregation zustandekommen.
Sowas ist ja nichtmal in eine reinen "normalen" TCP/IP Umgebung supported.
Falscher hätt mans nicht machen können... Da fehlen wohl generell schon die Grundlagen des Networking an sich
Wenn das dann ein ARP gibt auf eine IP die im selben IP Netz aber in der gleichen L2 Doamin liegt kommt ja immer nur ein Repy einer einzigen NIC.
In so einem konstrukt kann niemals ein Multipathing oder auch nur Link Aggregation zustandekommen.
Sowas ist ja nichtmal in eine reinen "normalen" TCP/IP Umgebung supported.
Falscher hätt mans nicht machen können... Da fehlen wohl generell schon die Grundlagen des Networking an sich
Sorry, ich meinte einen 0815 Switch.
Nach der Verwendung zweier dummer Hubs o.g. Fabrikats (ich nenne es halt Hubs, weil diese Desktop-Switches ja nicht wirklich was können), kommt das "Einfrieren" nicht mehr vor. (Wie sich nach längerer Wartezeit herausgestellt hatte, fror die Dateiübertrgaung bei Verwendung nur eines dummen Hubs nicht wirklich ein, es dauerte aber ca. 5mal so lange, bis die Dateien übertragen waren).
Kontrollier bitte ob MPIO auch aktiviert ist und funktioniert. Du müsstest im Initiator zwei aktive Sessions sehen.
Grüße,
Dani
Grüße,
Dani
Zitat von @Dani:
Kontrollier bitte ob MPIO auch aktiviert ist und funktioniert. Du müsstest im Initiator zwei aktive Sessions sehen.
Grüße,
Dani
Kontrollier bitte ob MPIO auch aktiviert ist und funktioniert. Du müsstest im Initiator zwei aktive Sessions sehen.
Grüße,
Dani
Ist alles kontrolliert. Wie ich eingangs schrieb, habe ich auch die Verifizierung wie in der Microsoft-Anleitung beschrieben durchgeführt und es deutet alles auf ein ordnungsgemäß konfiguriertes MPIO hin.
Das Fazit ist:
Das Multipathing im Testsetup funktioniert i.S. der Ausfallsicherheit - deaktiviert man einen Pfad (Kabel zeihen oder NIC deaktivieren) übernimmt der andere Pfad die volle Last. Steckt man das Kabel wieder, verteilt sich die Last wieder auf beide Pfade.
Durchsatzgewinn gab es leider nicht - was allerdings auch an den LUNs liegen könnte, bei denen es sich um interne HDDs des Targets handelt, und die hier mglw. den limitierenden Faktor darstellen. Das muß ein weiterer Test mit einem Diskarray als Target-LUN zeigen.
Ich glaube, hier gab es ganz zu Anfang ein Missverständnis, was das IP-Konfigurations-Setup anbelangt und zu der L2/L3-Diskussion und dazu führte, dass hier Trunking ins Spiel gebracht wurde: "Korrespondierende Subnetze" beim Target bedeutete, dass je eine NIC des Targets korrespondierend zu je einer NIC des Initiators konfiguriert ist und nicht miteinander korrespondierend. Oder mit weniger Wörtern beschrieben:
Target NIC1: 10.201.21.101/24 <-> Initiator NIC1: 10.201.21.38/24
Target NIC2: 10.201.22.101/24 <-> Initiator NIC2: 10.201.22.38/24
Der Fehler im Testsetup lag schließlich daran, alle NICs mit einem einzigen primitiven Desktop-Switch miteinander zu verbinden. Mit je einem primitiven Desktop-Switch pro Subnet-Paar (Target/Initiator) funktioniert das Multipathing.
Das Multipathing im Testsetup funktioniert i.S. der Ausfallsicherheit - deaktiviert man einen Pfad (Kabel zeihen oder NIC deaktivieren) übernimmt der andere Pfad die volle Last. Steckt man das Kabel wieder, verteilt sich die Last wieder auf beide Pfade.
Durchsatzgewinn gab es leider nicht - was allerdings auch an den LUNs liegen könnte, bei denen es sich um interne HDDs des Targets handelt, und die hier mglw. den limitierenden Faktor darstellen. Das muß ein weiterer Test mit einem Diskarray als Target-LUN zeigen.
Ich glaube, hier gab es ganz zu Anfang ein Missverständnis, was das IP-Konfigurations-Setup anbelangt und zu der L2/L3-Diskussion und dazu führte, dass hier Trunking ins Spiel gebracht wurde: "Korrespondierende Subnetze" beim Target bedeutete, dass je eine NIC des Targets korrespondierend zu je einer NIC des Initiators konfiguriert ist und nicht miteinander korrespondierend. Oder mit weniger Wörtern beschrieben:
Target NIC1: 10.201.21.101/24 <-> Initiator NIC1: 10.201.21.38/24
Target NIC2: 10.201.22.101/24 <-> Initiator NIC2: 10.201.22.38/24
Der Fehler im Testsetup lag schließlich daran, alle NICs mit einem einzigen primitiven Desktop-Switch miteinander zu verbinden. Mit je einem primitiven Desktop-Switch pro Subnet-Paar (Target/Initiator) funktioniert das Multipathing.
