ISCSI-NIC-Teaming: Link Aggregation sinnlos für Geschwindigkeitserhöhung bei Einzelverbindung?
Liebes Forum,
habe folgendes Setup:
- Debian-Rechner als iSCSI-Target. An dem Rechner hängen 2 Diskarrays, die je 2 LUNs bereitstellen. Der Debian-Rechner stellt diese LUNs per iSCSI zur Verfügung.
- Windows Server, der diese LUNs mit dem Microsoft iSCSI-Initiator einbindet. Dieser Windows Server ist der einzige Initiator, der auf das Debian-Target zugreift. Der Windows Server ist mit einer 10Gbps-NIC an das Produktivnetzwerk (LAN) angeschlossen.
- Verbindung zwischen dem Windows Server und dem Debian Target ist eine 1Gbps-Verbindung.
Wenn der Windows Server nun die LUNs beschreibt, ist die iSCSI-Verbindung zum Debian-Target oft maximal ausgelastet, die 10Gbps-Verbindung ins Produktivnetzwerk nicht so sehr.
Habe nun recherchiert und dabei oft gelesen, dass die Link Aggregation mehrerer NICs für Einzelverbindungen nichts bringt - im Sinne des "Geschwindigkeitszuwachses". Es bringt nur was, wenn mehrere unterschiedliche Rechner auf das Ziel zugreifen, das per Link Aggregation auf einen Switch geht. Weil dann eben die einzelnen Verbindungen der Rechner verteilt werden.
1. Trifft das für iSCSI genauso zu? (Kann auch iSCSI nicht mehrere Verbindungen zwischen Rechner A und Rechner B oder zwischen Rechner A und Switch C gleichzeitig betreiben?)
2. Trifft das für eine direkte Verbindung zwischen iSCSI-Target und Windows Server auch zu (sprich: Teaming auf dem Windows Server konfigurieren und damit direkt - ohne Switch dazwischen - mit teamed Debian Target NICs verbinden)?
Ich bin mir ziemlich sicher, dass es auch hier nichts bringt, wollte aber nochmal zur Bestätigung nachfragen.
Vielen Dank für eure Antworten!
Gruß
schlurfi
habe folgendes Setup:
- Debian-Rechner als iSCSI-Target. An dem Rechner hängen 2 Diskarrays, die je 2 LUNs bereitstellen. Der Debian-Rechner stellt diese LUNs per iSCSI zur Verfügung.
- Windows Server, der diese LUNs mit dem Microsoft iSCSI-Initiator einbindet. Dieser Windows Server ist der einzige Initiator, der auf das Debian-Target zugreift. Der Windows Server ist mit einer 10Gbps-NIC an das Produktivnetzwerk (LAN) angeschlossen.
- Verbindung zwischen dem Windows Server und dem Debian Target ist eine 1Gbps-Verbindung.
Wenn der Windows Server nun die LUNs beschreibt, ist die iSCSI-Verbindung zum Debian-Target oft maximal ausgelastet, die 10Gbps-Verbindung ins Produktivnetzwerk nicht so sehr.
Habe nun recherchiert und dabei oft gelesen, dass die Link Aggregation mehrerer NICs für Einzelverbindungen nichts bringt - im Sinne des "Geschwindigkeitszuwachses". Es bringt nur was, wenn mehrere unterschiedliche Rechner auf das Ziel zugreifen, das per Link Aggregation auf einen Switch geht. Weil dann eben die einzelnen Verbindungen der Rechner verteilt werden.
1. Trifft das für iSCSI genauso zu? (Kann auch iSCSI nicht mehrere Verbindungen zwischen Rechner A und Rechner B oder zwischen Rechner A und Switch C gleichzeitig betreiben?)
2. Trifft das für eine direkte Verbindung zwischen iSCSI-Target und Windows Server auch zu (sprich: Teaming auf dem Windows Server konfigurieren und damit direkt - ohne Switch dazwischen - mit teamed Debian Target NICs verbinden)?
Ich bin mir ziemlich sicher, dass es auch hier nichts bringt, wollte aber nochmal zur Bestätigung nachfragen.
Vielen Dank für eure Antworten!
Gruß
schlurfi
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 212777
Url: https://administrator.de/contentid/212777
Ausgedruckt am: 21.09.2024 um 01:09 Uhr
17 Kommentare
Neuester Kommentar
Moin schlurfi,
um die Last zwischen Server A und Server B zu verteilen, müsstest du jeweils zwei Nezwerkkarten einbauen, die ein eigenes IP-Subnetz bilden. Durch Aktivieren von MPIO und Round Robin könntest du die Last im iSCSI - Bereich verteilen.
Hier ein Auszug zum Beispiel von Intel:
Quelle: http://www.intel.com/support/motherboards/server/sb/CS-027892.htm
Außerdem gibt es dazu einen interessanten Artikel im Microsoft-Blog.
Grüße,
Dani
um die Last zwischen Server A und Server B zu verteilen, müsstest du jeweils zwei Nezwerkkarten einbauen, die ein eigenes IP-Subnetz bilden. Durch Aktivieren von MPIO und Round Robin könntest du die Last im iSCSI - Bereich verteilen.
Hier ein Auszug zum Beispiel von Intel:
Adapter Teaming using Intel's ANS is not supported for those ports transferring iSCSI traffic. This is due to limitations of the third-party iSCSI target/initiator software.
For load balancing and failover support in Microsoft Windows* operating systems, you can use Microsoft's* MPIO (MultiPath I/O). Check the Microsoft Initiator User Guide on how to setup MPIO.
If you are planning to use Microsoft MPIO on an Intel® Storage System, please ensure that your firmware supports multi path I/O.
Außerdem gibt es dazu einen interessanten Artikel im Microsoft-Blog.
Grüße,
Dani
Moin,
mit zwei Rechnern in deiner jetztigen Konfiguration ist mehr nicht drin. Du wirst aber nicht nur zwei Rechner via iSCSI verbunden haben?
Wenn du aber z.B. Windows Server 2012 nutzen würdest könntest du mit SMB 3.0 und den neuen Features (Mutlichannel, Teaming) mehr rausholen. Ist natürlich auch eine Preisfrage...
Grüße,
Dani
mit zwei Rechnern in deiner jetztigen Konfiguration ist mehr nicht drin. Du wirst aber nicht nur zwei Rechner via iSCSI verbunden haben?
Wenn du aber z.B. Windows Server 2012 nutzen würdest könntest du mit SMB 3.0 und den neuen Features (Mutlichannel, Teaming) mehr rausholen. Ist natürlich auch eine Preisfrage...
Grüße,
Dani
Hi Schlurfi,
das kommt darauf an.
Wenn du natürlich Gigabit Gegenstellen hast können die nur mit mehreren gemeinsam den Channel auslasten.
Aber 10 Gigabit kann man gut mit einem Channel/Trunck verbinden. Ob das dann wirklich eine höhere Performance im täglichen Betrieb bringt, hängt von der Art der Last ab. Große Dateien können den Link stärker auslasten. Prinzipiell wird ansonsten jeden neue Verbindung auf einem anderen Interface, einer anderen NIC aufgemacht. Wenn die auf dem selben Switch, der selben Karte sind, sollte das Maximum deutlich höher liegen als jetzt. Aber dann kommt es auch noch auf deinen Switch an.
Für dich wäre das dann so, dass ein 2GBit Server mit 2x2GBit LUNs verbunden ist. Der Server ist da immer noch im Nachteil gegenüber der theoretischen LUN-Bandbreite. Außerdem kann man in solchen Fällen auf den NICs/Switchports größere Pakete, Jumbo-packets einstellen.
Gruß
Netman
das kommt darauf an.
Wenn du natürlich Gigabit Gegenstellen hast können die nur mit mehreren gemeinsam den Channel auslasten.
Aber 10 Gigabit kann man gut mit einem Channel/Trunck verbinden. Ob das dann wirklich eine höhere Performance im täglichen Betrieb bringt, hängt von der Art der Last ab. Große Dateien können den Link stärker auslasten. Prinzipiell wird ansonsten jeden neue Verbindung auf einem anderen Interface, einer anderen NIC aufgemacht. Wenn die auf dem selben Switch, der selben Karte sind, sollte das Maximum deutlich höher liegen als jetzt. Aber dann kommt es auch noch auf deinen Switch an.
Für dich wäre das dann so, dass ein 2GBit Server mit 2x2GBit LUNs verbunden ist. Der Server ist da immer noch im Nachteil gegenüber der theoretischen LUN-Bandbreite. Außerdem kann man in solchen Fällen auf den NICs/Switchports größere Pakete, Jumbo-packets einstellen.
Gruß
Netman
Um nochmal zusammen zufassen:
Mit einer Netzwerkverbindung kannst du genau eine iSCSI-Verbindung und somit eine iSCSI-Session aufbauen. Diese ist permanent und das siehst du im iSCSI - Initator schön. Wenn du zwei Netzwerkverbindungen zwischen Server A und Server B hast (Subnetz: 192.168.1.0/30, 192.168.2.0/30) hast du zwei Verbindungen. Mit Aktivierung von MPIO solltest du den Datendurchsatz erhöhen können.
Mit MC/S ist es möglich innerhalb einer iSCSI-Verbindung mehere iSCSI-Sessions aufzubauen. Soweit ich weiß wird das seitens Microsoft unterstützt aber Linux macht dir einen Strich durch die Rechnung.Fällt also in deinem Fall raus.
Grüße,
Dani
Mit einer Netzwerkverbindung kannst du genau eine iSCSI-Verbindung und somit eine iSCSI-Session aufbauen. Diese ist permanent und das siehst du im iSCSI - Initator schön. Wenn du zwei Netzwerkverbindungen zwischen Server A und Server B hast (Subnetz: 192.168.1.0/30, 192.168.2.0/30) hast du zwei Verbindungen. Mit Aktivierung von MPIO solltest du den Datendurchsatz erhöhen können.
Mit MC/S ist es möglich innerhalb einer iSCSI-Verbindung mehere iSCSI-Sessions aufzubauen. Soweit ich weiß wird das seitens Microsoft unterstützt aber Linux macht dir einen Strich durch die Rechnung.Fällt also in deinem Fall raus.
Grüße,
Dani
Geht es hier nicht generell um die Frage ob ein Teaming bzw. Link Aggregation mit 2 NICs die Geschwindigkeit pro Session erhöht ??
Die Antwort darauf lautet NEIN.
Und das ist völlig egal ob man Winblows oder Linux für ein iSCSI Storage benutzt.
Bei einem Teaming / Link Aggreagtion Szenario wird aufgrund eines Hash Wertes der aus den letzten 4 Bits der Mac Adresse der Endgeräte gerechnet wird die einzelnen Session auf den physischen Link verteilt.
Ein Mac Pärchen was kommuniziert bekommt also immer nur einen physischen Link zugeteilt.
Wenn du also 2 Stationen hast kann im worst Case der Hash für beide auf den gleichen Link zeigen und dann hast du nichts gewonnen.
Man geht davon aus das in der Praxis die Mac Adress Verteilung eben so granular ist das eine gewisse Lastverteilung auf die beiden Links stattfindet.
Wahr ist das diese Verteilung nie 50:50 ist sondern immer verschoben. Einige Hersteller rechnen in den Hash noch die TCP/UDP Ports mit ein um die Verteilung zu optimieren.
Wie gesagt das ist ein weltweiter Standard (IEEE 802.3ad mit LACP) an den sich alle halten.
Deshalb speilt es keine Rolle ob TCP, UDP Winblows oder Linux oder iSCSI oder Telnet oder was auch immer.
Es zählt einzig die Mac Adresse !!
Die Antwort darauf lautet NEIN.
Und das ist völlig egal ob man Winblows oder Linux für ein iSCSI Storage benutzt.
Bei einem Teaming / Link Aggreagtion Szenario wird aufgrund eines Hash Wertes der aus den letzten 4 Bits der Mac Adresse der Endgeräte gerechnet wird die einzelnen Session auf den physischen Link verteilt.
Ein Mac Pärchen was kommuniziert bekommt also immer nur einen physischen Link zugeteilt.
Wenn du also 2 Stationen hast kann im worst Case der Hash für beide auf den gleichen Link zeigen und dann hast du nichts gewonnen.
Man geht davon aus das in der Praxis die Mac Adress Verteilung eben so granular ist das eine gewisse Lastverteilung auf die beiden Links stattfindet.
Wahr ist das diese Verteilung nie 50:50 ist sondern immer verschoben. Einige Hersteller rechnen in den Hash noch die TCP/UDP Ports mit ein um die Verteilung zu optimieren.
Wie gesagt das ist ein weltweiter Standard (IEEE 802.3ad mit LACP) an den sich alle halten.
Deshalb speilt es keine Rolle ob TCP, UDP Winblows oder Linux oder iSCSI oder Telnet oder was auch immer.
Es zählt einzig die Mac Adresse !!
Hallo!
Nochmal in Kürze:
Wie Aqui schrieb: LACP-Bonding bringt nichts.
Grundsätzlich bringt Round-Robin-Bonding einen kleinen Vorteil, aber wird mit Switchen problematisch bis unmöglich.
Der Weg der Wahl ist Multipathing bei iSCSI. Hier wird der Traffic auch zwischen zwei Systemen über beide Links verteilt und Du erhälst wirklich fast x-fache Geschwindigkeit!
Gruß
Phil
Nochmal in Kürze:
Wie Aqui schrieb: LACP-Bonding bringt nichts.
Grundsätzlich bringt Round-Robin-Bonding einen kleinen Vorteil, aber wird mit Switchen problematisch bis unmöglich.
Der Weg der Wahl ist Multipathing bei iSCSI. Hier wird der Traffic auch zwischen zwei Systemen über beide Links verteilt und Du erhälst wirklich fast x-fache Geschwindigkeit!
Gruß
Phil
Na ja die Betonung liegt auf dem Wort "verteilt" ! Denn das Clocking auf den Einzellinks wird ja nicht erhöht. Bei 2 mal 1 GiG Ethernet werden die Daten immer nur auch mit 1 GiG übertragen mitnichten natürlich mit 2 GiG.
Link Aggreagtion ist also immer nur einen Kapazitätserhöhung nicht aber eine Geschwindigkeits Erhöhung.
Das wäre physikalisch unmöglich.
Was auch immer das "Multipathing" ist aus Sicht eines Servers, sowie es über ein Switch geht greift immer IEEE802.3ad mit oder ohne LACP.
Link Aggreagtion Mechanismen auf Netzwerk Infrastruktur haben keine Paket Recovery Verfahren, deshalb ist eine Roud Robin Paketverteilung generell von vorn herein technisch ausgeschlossen und das egal bei welchem Protokoll.
Ausnahmen bilden da nur sog. DCB (Data Center Bridging) fähige Ethernet Switches (Cisco Nexus, Brocade VDX usw.) die eine sog. Ethernet Fabric bilden.
Die haben Hersteller proprietäre Round Robin Mechanismen die eine wirkliche genaue Verteilung gewährleisten auf per Paket Basis und damit für Storage Traffic (iSCSI, NFS, FCoE) predestiniert sind.
Normale Ethrnet Switches können das aber nicht und machen rein eine Session basierte verteuling nach Source und Destination Mac Adresse der Endgeräte.
Link Aggreagtion ist also immer nur einen Kapazitätserhöhung nicht aber eine Geschwindigkeits Erhöhung.
Das wäre physikalisch unmöglich.
Was auch immer das "Multipathing" ist aus Sicht eines Servers, sowie es über ein Switch geht greift immer IEEE802.3ad mit oder ohne LACP.
Link Aggreagtion Mechanismen auf Netzwerk Infrastruktur haben keine Paket Recovery Verfahren, deshalb ist eine Roud Robin Paketverteilung generell von vorn herein technisch ausgeschlossen und das egal bei welchem Protokoll.
Ausnahmen bilden da nur sog. DCB (Data Center Bridging) fähige Ethernet Switches (Cisco Nexus, Brocade VDX usw.) die eine sog. Ethernet Fabric bilden.
Die haben Hersteller proprietäre Round Robin Mechanismen die eine wirkliche genaue Verteilung gewährleisten auf per Paket Basis und damit für Storage Traffic (iSCSI, NFS, FCoE) predestiniert sind.
Normale Ethrnet Switches können das aber nicht und machen rein eine Session basierte verteuling nach Source und Destination Mac Adresse der Endgeräte.
Das wäre dann in der Tat die Lösung, denn das wäre ein Round Robin über parallele Wege. Fragt sich mit wieviel Overhead das verbunden ist ?! Bei 60 Gig 52 Gig Durchsatz wäre ja schon legendär.
Wie gesagt in modernen DCB fähigen Fabric Ethernet Switches gibt es sowas schon heute....da ist das ein alter Hut.
Wie gesagt in modernen DCB fähigen Fabric Ethernet Switches gibt es sowas schon heute....da ist das ein alter Hut.