17
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 212777
Url: https://administrator.de/contentid/212777
Printed on: April 25, 2024 at 19:04 o'clock
17 Comments
Latest comment
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
Hallo Dani,
gerade das soll ja angeblich nichts bringen.
Es heißt immer, Teaming/Bonding/Link Aggregation bringt nichts i.S. des Geschwindigkeitszuwachses, wenn es sich um eine Verbindung zwischen 2 Rechnern dreht - wenn Rechner B auf Rechner A (der die Ressource bereitstellt) zugreift - es aber keine Rechner C bis Z gibt, die ebenfalls auf die Ressourcen zugreifen.
Im letzteren Fall würden die Zugriffe verteilt werden, im ersteren Fall gibt es aber keinen Vorteil zu einer einzigen Verbindung. Ist eine Socket-Geschichte oder so.
Ich wollte hier fragen, ob das auch für iSCSI-Verbindungen gilt, oder ob iSCSI-Verbindungen, im Gegensatz zu "normalen" Verbindungen mehrere Sockets gleichzeitig öffnen können - ich denke mal, das mit den Sockets ist eine TCP/IP-Geschichte und daher unterscheidet sich es nicht zu anderen Verbindungstypen (SMB oder so).
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.
IP-Subnetz bilden. Durch Aktivieren von MPIO und Round Robin könntest du die Last im iSCSI - Bereich verteilen.
gerade das soll ja angeblich nichts bringen.
Es heißt immer, Teaming/Bonding/Link Aggregation bringt nichts i.S. des Geschwindigkeitszuwachses, wenn es sich um eine Verbindung zwischen 2 Rechnern dreht - wenn Rechner B auf Rechner A (der die Ressource bereitstellt) zugreift - es aber keine Rechner C bis Z gibt, die ebenfalls auf die Ressourcen zugreifen.
Im letzteren Fall würden die Zugriffe verteilt werden, im ersteren Fall gibt es aber keinen Vorteil zu einer einzigen Verbindung. Ist eine Socket-Geschichte oder so.
Ich wollte hier fragen, ob das auch für iSCSI-Verbindungen gilt, oder ob iSCSI-Verbindungen, im Gegensatz zu "normalen" Verbindungen mehrere Sockets gleichzeitig öffnen können - ich denke mal, das mit den Sockets ist eine TCP/IP-Geschichte und daher unterscheidet sich es nicht zu anderen Verbindungstypen (SMB oder so).
Ich glaube, meine Frage ist hier beantwortet:
Wie stelle ich einen echten 2 Gigabit Link her?
Also keine Lösung für nur 2 beteiligte Rechner.
Wie stelle ich einen echten 2 Gigabit Link her?
Also keine Lösung für nur 2 beteiligte Rechner.
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
Zitat von @Dani:
Moin,
mit zwei Rechnern in deiner jetztigen Konfiguration ist mehr nicht drin. Du wirst aber nicht nur zwei Rechner via iSCSI verbunden
haben?
Moin,
mit zwei Rechnern in deiner jetztigen Konfiguration ist mehr nicht drin. Du wirst aber nicht nur zwei Rechner via iSCSI verbunden
haben?
Doch, es ist ein Debian als iSCSI-Target und ein Windows Server 2008 R2, der die LUNs einbindet und dann Freigaben im Netzwerk bereitstellt, die auf den diesen Volumes liegen. Selbst wenn mehrere Rechner auf die Windows-Freigaben zugreifen, so ist ja die Verbindung zwischen Windows Server und Debian-Target immer nur die eine.
Hallo Netman,
Genau das ist die Frage: Was genau ist eine (neue) Verbindung?
Bedeutet eine "Verbindung" die gesamte Kommunikation zwischen Rechner A und Rechner B (solange die Sitzung geht), oder handelt es sich bei einer "Verbindung" um Versand und Empfand eines "Pakets" (z.B. eines Dateisegments oder einer kompletten Datei)? Im letzteren Fall wäre die gleichzeitige Eröffnung vieler "Verbindungen" ja möglich und demnach würden sich diese Verbindungen auf die einzelnen NICs eines Teamings verteilen.
Prinzipiell wird ansonsten jeden neue Verbindung auf einem anderen Interface, einer anderen NIC aufgemacht.
Genau das ist die Frage: Was genau ist eine (neue) Verbindung?
Bedeutet eine "Verbindung" die gesamte Kommunikation zwischen Rechner A und Rechner B (solange die Sitzung geht), oder handelt es sich bei einer "Verbindung" um Versand und Empfand eines "Pakets" (z.B. eines Dateisegments oder einer kompletten Datei)? Im letzteren Fall wäre die gleichzeitige Eröffnung vieler "Verbindungen" ja möglich und demnach würden sich diese Verbindungen auf die einzelnen NICs eines Teamings verteilen.
Sers,
sagmal, warum nimmst du dann nicht gleich nen Windows Storage Server 2012 ran? Sparst dir den extra Server, hast Dedup, SMB3, etc, und brauchst nicht mal CALs dafür. Den Storage Server gibts auch als OEM um die 500€ und er ist CAL-frei.
Nur mal so als Idee...
Grüße,
Philip
sagmal, warum nimmst du dann nicht gleich nen Windows Storage Server 2012 ran? Sparst dir den extra Server, hast Dedup, SMB3, etc, und brauchst nicht mal CALs dafür. Den Storage Server gibts auch als OEM um die 500€ und er ist CAL-frei.
Nur mal so als Idee...
Grüße,
Philip
1
Hallo Philip,
das mag ja alles sein. Hier ging's vorrangig um Verständnisfragen. Kannst du sie beantworten? (s.o.)
Was genau ist eine "Verbindung"? Wenn wir die Definition der "Verbindung" haben, können wir beantworten, ob mehrere Verbindungen zwischen 2 Rechnern möglich sein sollten oder nicht.
Zitat von @psannz:
Sers,
sagmal, warum nimmst du dann nicht gleich nen Windows Storage Server 2012 ran? Sparst dir den extra Server, hast Dedup, SMB3, etc,
und brauchst nicht mal CALs dafür. Den Storage Server gibts auch als OEM um die 500€ und er ist CAL-frei.
Nur mal so als Idee...
Grüße,
Philip
Sers,
sagmal, warum nimmst du dann nicht gleich nen Windows Storage Server 2012 ran? Sparst dir den extra Server, hast Dedup, SMB3, etc,
und brauchst nicht mal CALs dafür. Den Storage Server gibts auch als OEM um die 500€ und er ist CAL-frei.
Nur mal so als Idee...
Grüße,
Philip
das mag ja alles sein. Hier ging's vorrangig um Verständnisfragen. Kannst du sie beantworten? (s.o.)
Was genau ist eine "Verbindung"? Wenn wir die Definition der "Verbindung" haben, können wir beantworten, ob mehrere Verbindungen zwischen 2 Rechnern möglich sein sollten oder nicht.
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
1
Vielen Dank, Dani.
Das ist für mich die Antwort.
Das ist für mich die Antwort.
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 !!
2
Hallo aqui,
Danke für deine Antwort.
Ich habe diese Seite gefunden, die - denke ich - den Sachverhalt auch nochmal schön erklärt - sofern es den Tatsachen entspricht: http://blog.open-e.com/bonding-versus-mpio-explained/
Wie auch @Dani ausgeführt hat, ist wohl das Mittel der Wahl, um den Durchsatz zwischen 2 Rechnern (iSCSI-Target und iSCSI-Initiator) zu erhöhen MPIO. Ich kannte MPIO schon vorher, aber ich hatte es immer nur als Redundanz-Lösung gesehen. Mir war nicht klar, dass sich damit auch der Durchsatz erhöhen lässt.
Danke für deine Antwort.
Ich habe diese Seite gefunden, die - denke ich - den Sachverhalt auch nochmal schön erklärt - sofern es den Tatsachen entspricht: http://blog.open-e.com/bonding-versus-mpio-explained/
Wie auch @Dani ausgeführt hat, ist wohl das Mittel der Wahl, um den Durchsatz zwischen 2 Rechnern (iSCSI-Target und iSCSI-Initiator) zu erhöhen MPIO. Ich kannte MPIO schon vorher, aber ich hatte es immer nur als Redundanz-Lösung gesehen. Mir war nicht klar, dass sich damit auch der Durchsatz erhöhen lässt.
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.
1
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.
