37
XenServer, NetApp, Cisco - Storage Design, maximale Nutzung der Netzwerkbandbreite
Hallo,
das hier ist mein erster Post, ich hoffe es gibt hier kein falschen oder richtigen Bereich, wenn doch dann bitte ich um Nachsicht
Ich bin momentan bei der Implementierung des folgenden Designs:
Ich weiß - gerade im Netzwerkbereich hat man in Kombination von verschiedenen Herstellersystemen oft die meisten Probleme bei der Konfiguration. Ich hoffe aber, jemand kann mir bei meinem Problem helfen.
Hier erstmal nachfolgend meine Konfigurationen:
Soweit erstmal dazu. Die Verbindungstest zwischen XenServer und NetApp verliefen erfolgreich.
Nun kann man sich zurücklehnen und sagen dass man jetzt fertig ist - jetzt aber beginnt aber der interessante Teil, nämlich das Testen des Netzwerks bzgl. der Bandbreite.
Und da gehen meine Probleme los.
Zum Testen habe ich folgendes Szenario erstellt:
- ich habe vier Netwerkfreigaben (ISO-Librarys) vol_Test, vol_Test2, vol_Test3, vol_Test4 auf der Seite von NetApp erstellt.
- jedes dieser Freigaben habe ich über ein eigenes VLAN per NFS Freigabe im XenServer gemountet, einfach deshalb, dass jeder gestartete Kopiervorgang über eine eigene Source- und einer Destination Adresse verfügt.
- auf jeder dieser Freigaben befindet sich eine ausreichend große Datei zum testen.
- die Kopiervorgänge starte ich auf der Konsole des XenServers, um weitere Fehlerquellen zu vermeiden.
- Kopiervorgang1 von volTest nach volTest2
- Kopiervorgang2 von volTest3 nach volTest4
Wenn ich nun ein Kopiervorgang starte, habe ich meine ca. 120 mb/s, was so 1 gbit/s entspricht. Bis hierher ist alles i.O., da eine Sitzung nur ein Interface (also 1 gbit/s) des Bonds nutzen kann.
Wenn ich aber dazu den zweiten Kopiervorgang starte, teilen sich beide das erste Interface und laufen beide so bei 60 mb/s. Warum wird der zweite Kopiervorgang nicht auf ein anderes Interface des Bonds gelegt?
Mein Ziel ist die Ausnutzung aller Interface des Bonds.
Habe ich einen Denkfehler in meinen Überlegungen?
Ich bin für jede Hilfe dankbar!
Gruß Johannes219
das hier ist mein erster Post, ich hoffe es gibt hier kein falschen oder richtigen Bereich, wenn doch dann bitte ich um Nachsicht
Ich bin momentan bei der Implementierung des folgenden Designs:
Ich weiß - gerade im Netzwerkbereich hat man in Kombination von verschiedenen Herstellersystemen oft die meisten Probleme bei der Konfiguration. Ich hoffe aber, jemand kann mir bei meinem Problem helfen.
Hier erstmal nachfolgend meine Konfigurationen:
Cisco Switch (Stacked) Konfiguration:
XenServer Konfiguration:
interface Port-channel18
description Storage XenServer
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
!
interface GigabitEthernet1/0/31
description Storage XenServer ETH4
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 18 mode active
!
interface GigabitEthernet1/0/32
description Storage XenServer ETH5
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 18 mode active
!
interface GigabitEthernet2/0/31
description Storage XenServer ETH6
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 18 mode active
!
interface GigabitEthernet2/0/32
description Storage XenServer ETH7
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 18 mode active
!
Storage NetApp Konfiguration:
interface Port-channel14
description Storage NetApp
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
!
interface GigabitEthernet1/0/25
description Storage NetApp e0a
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 14 mode active
!
interface GigabitEthernet1/0/26
description Storage NetApp e0b
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 14 mode active
!
interface GigabitEthernet2/0/25
description Storage NetApp e0c
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 14 mode active
!
interface GigabitEthernet2/0/26
description Storage NetApp e0d
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
channel-protocol lacp
channel-group 14 mode active
!
NetApp Interface Konfiguration:
NetApp>rdfile /etc/rc
ifgrp create lacp Team-C1 -b ip e0a e0b e0c e0d
vlan create Team-C1 5
vlan add Team-C1 3
vlan add Team-C1 8
vlan add Team-C1 9
ifconfig e0M `hostname`-e0M netmask 255.255.255.0 mtusize 1500
ifconfig Team-C1-5 `hostname`-Team-C1-5 netmask 255.255.255.0 partner 172.17.255.5 mtusize 1500 trusted wins up
ifconfig Team-C1-3 `hostname`-Team-C1-3 netmask 255.255.255.240 mtusize 1500 trusted wins up
ifconfig Team-C1-8 `hostname`-Team-C1-8 netmask 255.255.255.0 mtusize 1500 trusted wins up
ifconfig Team-C1-9 `hostname`-Team-C1-9 netmask 255.255.255.0 mtusize 1500 trusted wins up
route add default 172.17.2.1 1
routed off
options dns.domainname SR-Node03-C1.osps.telekom.de
options dns.enable on
options nis.enable off
options interface.blocked.mgmt_data_traffic on
savecore
XenServer Interface Konfiguration:
Netzwerk Tests
Soweit erstmal dazu. Die Verbindungstest zwischen XenServer und NetApp verliefen erfolgreich.Nun kann man sich zurücklehnen und sagen dass man jetzt fertig ist - jetzt aber beginnt aber der interessante Teil, nämlich das Testen des Netzwerks bzgl. der Bandbreite.
Und da gehen meine Probleme los.
Zum Testen habe ich folgendes Szenario erstellt:
- ich habe vier Netwerkfreigaben (ISO-Librarys) vol_Test, vol_Test2, vol_Test3, vol_Test4 auf der Seite von NetApp erstellt.
- jedes dieser Freigaben habe ich über ein eigenes VLAN per NFS Freigabe im XenServer gemountet, einfach deshalb, dass jeder gestartete Kopiervorgang über eine eigene Source- und einer Destination Adresse verfügt.
- auf jeder dieser Freigaben befindet sich eine ausreichend große Datei zum testen.
- die Kopiervorgänge starte ich auf der Konsole des XenServers, um weitere Fehlerquellen zu vermeiden.
- Kopiervorgang1 von volTest nach volTest2
- Kopiervorgang2 von volTest3 nach volTest4
Wenn ich nun ein Kopiervorgang starte, habe ich meine ca. 120 mb/s, was so 1 gbit/s entspricht. Bis hierher ist alles i.O., da eine Sitzung nur ein Interface (also 1 gbit/s) des Bonds nutzen kann.
Wenn ich aber dazu den zweiten Kopiervorgang starte, teilen sich beide das erste Interface und laufen beide so bei 60 mb/s. Warum wird der zweite Kopiervorgang nicht auf ein anderes Interface des Bonds gelegt?
Mein Ziel ist die Ausnutzung aller Interface des Bonds.
Habe ich einen Denkfehler in meinen Überlegungen?
Ich bin für jede Hilfe dankbar!
Gruß Johannes219
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 264977
Url: https://administrator.de/contentid/264977
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
37 Kommentare
Neuester Kommentar
Hallo Johannes,
ich kann dir (wahrscheinlich) damit nicht weiterhelfen, aber oft sieht man die Gabel im Heuhaufen einfach nicht.
Ich hab hier ein kleines Tutorial gefunden, eventuell hilft dir das ja bei der Fehlersuche weiter.
Ansonsten einfach abwarten, hier melden sich bestimmt noch Profis ;)
Beste Grüße
ich kann dir (wahrscheinlich) damit nicht weiterhelfen, aber oft sieht man die Gabel im Heuhaufen einfach nicht.
Ich hab hier ein kleines Tutorial gefunden, eventuell hilft dir das ja bei der Fehlersuche weiter.
Ansonsten einfach abwarten, hier melden sich bestimmt noch Profis ;)
Beste Grüße
Im Netzwerkbereich hat man in Kombination von verschiedenen Herstellersystemen oft die meisten Probleme bei der Konfiguration.
Nein, das ist eigentlich Unsinn wenn man weiss was man tut und hat auch nix mit Gabel und Heuhaufen zu tun !120 mb/s, was so 1 gbit/s entspricht.
Na ja...wenn du es noch richtig dargestellt hättest in üblicher Notation, hätte man es auch gleich verstanden. Klein mb = mbit Groß Mb = Mbyte !!das 120 mbit/s = 1000 mbit/s ist wäre ja sonst auch Blödsinn.
Aber kommen wir mal zum Wesentlichen...
Du schreibst oben das deine LACP Hashing Algorythmen "IP based" sind !! WO bitte hast du das definiert ?! Die Cisco Konfig ist syntaktisch absolut korrekt und richtig aber im Default ist die Hash Berechnug Mac Adress basierend so wie es der Standard vorgibt. IP Adress basiertes Hashing musst du entsprechend in der Konfig aktivieren und das dann auch auf BEIDEN Seiten. In der geposteten Cisco Konfig fehlt das port-channel load-balance xyz Kommando dafür !
Ferner solltest du auch mal mit show lacp neigbor checken ob die LACP Verbindung wirklich aktiv ist ?! Jedenfalls auf der Switchseite.
Wie die Serverseite und auch die NetAPP Seite die Hashing Berechnung konfiguriert musst du im Handbuch nachlesen. Default ist hier mit Sicherheit auch ein einfaches XOR der Mac Adressen wie der Standard es vorgibt. Sinnvoll wäre hier natürlich IP und am besten noch der Port zusätzlich wie es auf dem Cisco Catalyst eingestellt werden kann. Erst dann wird auch ein IP basiertes Hashing gemacht.
teilen sich beide das erste Interface und laufen beide so bei 60 mb/s. Warum wird der zweite Kopiervorgang nicht auf ein anderes Interface des Bonds gelegt?
Genau das ist der Punkt und zeigt das dein Hashing fehlerhaft ist !Bedenke das beide Seiten das NICHT negotiaten !! Jeder macht sein Hashing für sich und muss auch jeder für sich konfiguriert werden !
Tip: Sinnvoller ist ein Test mit IPerf, denn damit kannst du verschiedene Source Ports erzwingen und den Hashing Algorythmus besser testen:
IPerf Server:
iperf -s –u
IPerf Client:
iperf -c <IP address> -u -P 10
Erzeugt dir z.B. 10 parallele Test Streams mit 10 unterschiedlichen Source Ports und zeigt ob es sauber funktioniert.
OK, natürlich nur wenn der Port in die Hashberechnung mit einfliesst. Der Cisco kann das wenigstens wenn du ihm das in der Konfig auch sagst !
Vermutlich hast du wenig Mac Adressen und das Hashing endet bei all denen auf einem Link mit dem Ergebnis was du dann siehst !
Fazit: LACP Links checken das die auch wirklich aktiv sind (show prt channel x, show lacp neig) und den Balancing Algorythmus konfigurieren auf beiden Seiten Switch und Server/Storage !
Unter Linux ist das in der Regel immer mode 4.
https://kb.netapp.com/support/index?page=content&id=3013774&impr ...
https://glazenbakje.wordpress.com/2012/02/14/cisco-to-netapp-configurati ...
http://blog.scottlowe.org/2007/06/13/cisco-link-aggregation-and-netapp- ...
Danke, ich werd's mir merken
Du schreibst oben das deine LACP Hashing Algorythmen "IP based" sind !! WO bitte hast du das definiert ?!
Sry - das habe ich schlichtweg vergessen zu posten - hier der entsprechende Eintrag in meiner Running Config:
!
port-channel load-balance src-dst ip
!
Wie die Serverseite und auch die NetAPP Seite die Hashing Berechnung konfiguriert musst du im Handbuch nachlesen.
Das ist ja schon umgestellt und in meinem ersten Beitrag gepostet. Natürlich kann ich auch da nicht zu 100% ausschließen, ob die Konfiguration läuft. Ich habe mich an entsprechende Best-Practises der Hersteller gehalten.Tip: Sinnvoller ist ein Test mit IPerf, denn damit kannst du verschiedene Source Ports erzwingen und den Hashing Algorythmus
besser testen:
Das Tool klingt nicht schlecht - muss aber auf beiden Seiten funktionieren. Leider wird es nicht von NetApp unterstützt.besser testen:
Momentan nutze ich rsync - zumindest zum testen der Bandbreite reicht es aus.
Hier noch die entsprechenden show Befehle:
cisco# show lacp neigbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 14 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi1/0/25 SA 0 02a0.9852.f9b6 2s 0x0 0x1 0x3 0x3D
Gi1/0/26 SA 0 02a0.9852.f9b6 2s 0x0 0x1 0x4 0x3D
Gi2/0/25 SA 0 02a0.9852.f9b6 1s 0x0 0x1 0x1 0x3D
Gi2/0/26 SA 0 02a0.9852.f9b6 2s 0x0 0x1 0x2 0x3D
Channel group 18 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi1/0/31 SA 65535 2c44.fd8b.a574 18s 0x0 0x1 0x1 0x3D
Gi1/0/32 SA 65535 2c44.fd8b.a574 18s 0x0 0x1 0x4 0x3D
Gi2/0/31 SA 65535 2c44.fd8b.a574 13s 0x0 0x1 0x2 0x3D
Gi2/0/32 SA 65535 2c44.fd8b.a574 10s 0x0 0x1 0x3 0x3D
Ciscok#show etherchannel 14 summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
14 Po14(SU) LACP Gi1/0/25(P) Gi1/0/26(P) Gi2/0/25(P)
Gi2/0/26(P)
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
18 Po18(SU) LACP Gi1/0/31(P) Gi1/0/32(P) Gi2/0/31(P)
Gi2/0/32(P)
Zumindest ist mir hier eines aufgefallen - Die Port-channel arbeiten hier im Status SU, jetzt weiß ich nicht genau, ob ein Cisco 3750 Layer 3 unterstützt. Ist ja eigentlich ein normaler Layer2 Switch und ich vermute die Option ist nur für Cisco Router vorgesehen.
Der Befehl für die Layer 3 Konfiguration der Port-channels mit
cisco {config-if}#no switchport
Wie dem auch sei - an dem Ergebnis ändert sich nichts. Hab auch Src-Dst Mac auf allen Instanzen konfiguriert - gleiches Ergebnis..
Für weitere Anregungen bin ich sehr dankbar.
Sry - das habe ich schlichtweg vergessen zu posten
Hinterher kann das jeder sagen Leider wird es nicht von NetApp unterstützt.
Ist ja egal, dann klemmst du mal einen PC dran. Geht ja nur darum zu zeigen das beide Seiten mit dem Hashing umgehen können.ob ein Cisco 3750 Layer 3 unterstützt. Ist ja eigentlich ein normaler Layer2 Switch
Alles was vorne ne 3 hat kann auch L3 wenn man es konfiguriert. Ist aber für dein Szenario ja vollkommen irrelevant, denn du routest ja nicht mit dem Switch.Dir gehts ja einzig und allein im eine reine L2 Anwendung was Link Aggreagtion ja nunmal ist !!
und ich vermute die Option ist nur für Cisco Router vorgesehen.
WAS bitte für eine "Option" meinst du ???Der Befehl für die Layer 3 Konfiguration der Port-channels mit
Uuuhhhh...jetzt kommt aber der freie Fall nach unten beim Syntax raten !Bitte wirf erstmal einen Blick in Ciscos IOS Command Reference und lies nach was das Kommando switchport wirklich macht bevor du hier sinnfrei weiterrätst, sorry !
wird mir verweigert.
Ist ja auch kein Wunder wenn die physischen Ports zum Portchannel eine vollkommen andere Konfig haben und du so einen Mismatch erzwingst. Kein IOS Switch der Welt kann das !Fazit: Command Reference lesen !
Hab auch Src-Dst Mac auf allen Instanzen konfiguriert - gleiches Ergebnis..
Du hast aber schon in Betracht gezogen das du nur einfach zu wenigs Adressen hast um ein granularers Hashing Ergebnis zu erzielen oder...Kann auch sein das alles OK ist. 802.3ad macht eben aus dem Grund KEIN round Robin per Paket Balancing !
@aqui:
Switchport
Das was ich schon erwähnt habe. Warum ich die Layer 3 Konfiguration überhaupt in Betracht gezogen habe ist, dass LACP Src-Dst-IP per default für Layer 3 Interfaces vorgesehen ist. Das LACP eine reine Layer 2 Link Aggregation ist war mir schon klar.
Ich habe deinen Rat bzgl. Iperf mal soweit umgesetzt und mir folgendes Testszenario erstellt:
Kurz zum Überblick:
XenServer1:
- CentOSTest1 IP:172.17.255.10
XenServer2:
- CentOSTest2 IP:172.17.255.11
Beide XenServer sind mit oben genannter Konfiguration an dem Cisco Switch angeschlossen; die VMs sind jeweils mit 1 gb/s am Storage Netz angebunden.
Hier noch der Hinweis: Der VM-Verkehr ist zwar im Storage Netz, geht aber nicht über die physikalischen Storage Bonds der XenServer, sondern über einen extra Bond mit jeweils 2 physikalischen Interfaces raus. Die sind identisch (XenServer- und Switchseitig) wie das Storage LAN gebondet.
Hatt etwas mit der Traffic Priorisierung zwischen VM-traffic und Storage Traffic der XenServer zu tun.
Ich hoffe das kam jetzt irgendwie verständlich rüber. ^^
Hier die Ergebnisse:
Berauschend sind die Ergebnisse nicht. Ich habe die Anzahl der Client Prozesse variiert; das Ergebnis bleibt gleich.
Natürlich kann auch die Virtualisierungsschicht die Netzwerkperformance beeinflussen.
Habe ich dabei noch etwas nicht beachtet?
Der Befehl für die Layer 3 Konfiguration der Port-channels mit
Ich gebe zu - und den Schuh muss ich mir wohl anziehen, dass ich von der Syntax her manchmal nicht korrekt bin. Politisch korrekt sollte ich wohl Etherchannel sagen ;-pUuuhhhh...jetzt kommt aber der freie Fall nach unten beim Syntax raten !
> und ich vermute die Option ist nur für Cisco Router vorgesehen.
WAS bitte für eine "Option" meinst du ???
Die Option Switchport.WAS bitte für eine "Option" meinst du ???
Bitte wirf erstmal einen Blick in Ciscos IOS Command Reference und lies nach was das Kommando switchport wirklich macht bevor du hier sinnfrei weiterrätst, sorry !
Switchport
Das was ich schon erwähnt habe. Warum ich die Layer 3 Konfiguration überhaupt in Betracht gezogen habe ist, dass LACP Src-Dst-IP per default für Layer 3 Interfaces vorgesehen ist. Das LACP eine reine Layer 2 Link Aggregation ist war mir schon klar.
Ich habe deinen Rat bzgl. Iperf mal soweit umgesetzt und mir folgendes Testszenario erstellt:
Kurz zum Überblick:
XenServer1:
- CentOSTest1 IP:172.17.255.10
XenServer2:
- CentOSTest2 IP:172.17.255.11
Beide XenServer sind mit oben genannter Konfiguration an dem Cisco Switch angeschlossen; die VMs sind jeweils mit 1 gb/s am Storage Netz angebunden.
Hier noch der Hinweis: Der VM-Verkehr ist zwar im Storage Netz, geht aber nicht über die physikalischen Storage Bonds der XenServer, sondern über einen extra Bond mit jeweils 2 physikalischen Interfaces raus. Die sind identisch (XenServer- und Switchseitig) wie das Storage LAN gebondet.
Hatt etwas mit der Traffic Priorisierung zwischen VM-traffic und Storage Traffic der XenServer zu tun.
Ich hoffe das kam jetzt irgendwie verständlich rüber. ^^
Hier die Ergebnisse:
Berauschend sind die Ergebnisse nicht. Ich habe die Anzahl der Client Prozesse variiert; das Ergebnis bleibt gleich.
Natürlich kann auch die Virtualisierungsschicht die Netzwerkperformance beeinflussen.
Habe ich dabei noch etwas nicht beachtet?
Politisch korrekt sollte ich wohl Etherchannel sagen ;-p
Na ja das können wir noch unterscheiden ob Trunk oder Etherchannel...nur rätst du hier ja wild rum was das Kommando switchport anbetrifft Die Option Switchport.
Das ist keineswegs eine "Option" sondern eins der wichtigsten Grundkommandos was dem Port eine Tagged oder untagged Funktion zuweist !Warum ich die Layer 3 Konfiguration überhaupt in Betracht gezogen habe ist
Du machst doch gar keinen L3 Konfiguration ?! Jedenfalls ist in deiner Konfig keiner solche ersichtlich oder routest du über den Switch und hast den Teil der Konfig oben gar nicht gepostet ??In deiner Konfig ist keinerlei L3 Konfig zu sehen ! Wäre es das, dann würde man dort jede Menge interface vlan x Kommandos mit IP Adressen usw. sehen....sieht man aber nicht
Deine beiden XEN Server befinden sich ja auch im gleichen IP Netz...auch da also kein L3. Oder ist dein Storage in einem anderen IP Netz ?
sondern über einen extra Bond mit jeweils 2 physikalischen Interfaces raus.
lieber mal einen Traceroute machen um zu checken ob das wirklich so ist... Problem ist das du nicht "sehen" kannst was die VMs bzw. die Storage Treiber da so machen bei deren Hash Berechnung ob die nun wirklich IP Adressen nehmen oder doch wieder die Macs.
Letzteres wäre solltest du wirklich irgendwo L3 Switching machen fatal, denn der Router hat ja immer nur eine einzige Mac was dann ein Balancing verhindern würde.
Gerade NetApp hat da in der Vergangenheit eher mit groben Schnitzern im Treiber geglänzt. Hier solltest du also unbedingt drauf achten das du da die wirklich aktuellste Firmware verwendest !
Was noch ganz hilfreich ist um beim Cisco Switch (und ggf. auch beim Storage oder XEN sofern dort SNMP aktiv ist !) ist ein kleines Tool was die Auslastung der Einzellinks im LAG grafisch anzeigt:
http://leonidvm.chat.ru
Das kannst du 4 mal starten auf dem Desktop und siehst die Verteilung grafisch auf den 4 einzelnen Links. (SNMP auf dem Switch aktivieren !)
Ich habe die Bedingungen doch nochmal vereinfacht - auf beiden XenServern läuft das Tool iperf. (Ergebnisse s. unten.)
Definitiv auf XenServer Seite (Bild s. oben) in dem jetzigem Szenario betrachte ich das NetApp erstmal nicht. Nur die Verbindung zwischen den beiden XenServern über den Cisco Switch wird betrachtet.
Auf Cisco Seite habe ich nur die oben genannte Konfiguration und IP-Src-Dest aktiviert..
Zzgl. habe ich komplett auf LACP mac-basierend umgestellt (Server und Switch)
Ich bekomme immer das gleiche Ergebnis wie im Bild oben..
Hier die Tests:
IP-Basierendes LACP liefert die gleichen Werte.
Damit zeigt es, dass er noch immer nur einen physikalischen Port nutzt und bei mehreren parallelen Tests die Bandbreite aufteilt.
Keine Spur von LACP und Round-Robin..
Du machst doch gar keinen L3 Konfiguration ?!
Definitiv auf XenServer Seite (Bild s. oben) in dem jetzigem Szenario betrachte ich das NetApp erstmal nicht. Nur die Verbindung zwischen den beiden XenServern über den Cisco Switch wird betrachtet.
Auf Cisco Seite habe ich nur die oben genannte Konfiguration und IP-Src-Dest aktiviert..
Zzgl. habe ich komplett auf LACP mac-basierend umgestellt (Server und Switch)
Ich bekomme immer das gleiche Ergebnis wie im Bild oben..
Hier die Tests:
MAC-Basierend:
TCP:
root@XenServer01]# iperf -s
root@XenServer02]# iperf -c 172.17.255.7 -t 60 -i 10
------------------------------------------------------------
Client connecting to 172.17.255.7, TCP port 5001
TCP window size: 21.9 KByte (default)
------------------------------------------------------------
[ 3] local 172.17.255.8 port 35340 connected with 172.17.255.7 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
[ 3] 10.0-20.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 20.0-30.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 30.0-40.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 40.0-50.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 50.0-60.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 0.0-60.0 sec 6.57 GBytes 941 Mbits/sec
+++++ TCP mit 2 Threads:
[root@XenServer01# iperf -s
[root@XenServer02]# iperf -c 172.17.255.7 -t 60 -i 10 -P2
------------------------------------------------------------
Client connecting to 172.17.255.7, TCP port 5001
TCP window size: 21.9 KByte (default)
------------------------------------------------------------
[ 4] local 172.17.255.8 port 35391 connected with 172.17.255.7 port 5001
[ 3] local 172.17.255.8 port 35390 connected with 172.17.255.7 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 557 MBytes 467 Mbits/sec
[ 3] 0.0-10.0 sec 566 MBytes 475 Mbits/sec
[SUM] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
[ 4] 10.0-20.0 sec 527 MBytes 442 Mbits/sec
[ 3] 10.0-20.0 sec 595 MBytes 499 Mbits/sec
[SUM] 10.0-20.0 sec 1.10 GBytes 941 Mbits/sec
[ 4] 20.0-30.0 sec 512 MBytes 429 Mbits/sec
[ 4] 0.0-30.0 sec 1.56 GBytes 446 Mbits/sec
[ 3] 20.0-30.0 sec 610 MBytes 512 Mbits/sec
[SUM] 20.0-30.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 0.0-30.0 sec 1.73 GBytes 495 Mbits/sec
[SUM] 0.0-30.0 sec 3.29 GBytes 941 Mbits/sec
UDP:
[root@XenServer01# iperf -s -u
[root@XenServer02# iperf -c 172.17.255.7 -u -b 4000M -t 60 -i 10
------------------------------------------------------------
Client connecting to 172.17.255.7, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 172.17.255.8 port 49018 connected with 172.17.255.7 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 967 MBytes 811 Mbits/sec
[ 3] 10.0-20.0 sec 966 MBytes 811 Mbits/sec
[ 3] 20.0-30.0 sec 966 MBytes 811 Mbits/sec
[ 3] 30.0-40.0 sec 967 MBytes 811 Mbits/sec
[ 3] 40.0-50.0 sec 966 MBytes 811 Mbits/sec
[ 3] 50.0-60.0 sec 966 MBytes 811 Mbits/sec
[ 3] 0.0-60.0 sec 5.66 GBytes 811 Mbits/sec
[ 3] Sent 4136366 datagrams
[ 3] Server Report:
[ 3] 0.0-60.0 sec 5.66 GBytes 810 Mbits/sec 0.047 ms 1757/4136365 (0.042%)
[ 3] 0.0-60.0 sec 1 datagrams received out-of-order
UDP mit 2 parallelen Threads:
[root@XenServer01]# iperf -s -u
[root@XenServer02]# iperf -c 172.17.255.7 -u -b 4000M -t 30 -i 10 -P2
------------------------------------------------------------
Client connecting to 172.17.255.7, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default
[ 3] local 172.17.255.8 port 43540 connected with 172.17.255.7 port 5001
[ 4] local 172.17.255.8 port 35196 connected with 172.17.255.7 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 585 MBytes 491 Mbits/sec
[ 4] 0.0-10.0 sec 555 MBytes 466 Mbits/sec
[SUM] 0.0-10.0 sec 1.11 GBytes 957 Mbits/sec
[ 4] 10.0-20.0 sec 596 MBytes 500 Mbits/sec
[ 3] 10.0-20.0 sec 544 MBytes 457 Mbits/sec
[SUM] 10.0-20.0 sec 1.11 GBytes 957 Mbits/sec
[ 3] 0.0-30.0 sec 1.71 GBytes 489 Mbits/sec
[ 3] Sent 1247356 datagrams
[ 4] 20.0-30.0 sec 521 MBytes 437 Mbits/sec
[ 4] 0.0-30.0 sec 1.63 GBytes 468 Mbits/sec
[ 4] Sent 1192828 datagrams
[SUM] 0.0-30.0 sec 3.34 GBytes 957 Mbits/sec
[ 4] Server Report:
[ 4] 0.0-30.0 sec 1.63 GBytes 467 Mbits/sec 0.106 ms 599/1192827 (0.05%)
[ 4] 0.0-30.0 sec 140 datagrams received out-of-order
[ 3] Server Report:
[ 3] 0.0-30.0 sec 1.71 GBytes 489 Mbits/sec 0.039 ms 585/1247355 (0.047%)
[ 3] 0.0-30.0 sec 144 datagrams received out-of-order
IP-Basierendes LACP liefert die gleichen Werte.
Damit zeigt es, dass er noch immer nur einen physikalischen Port nutzt und bei mehreren parallelen Tests die Bandbreite aufteilt.
Keine Spur von LACP und Round-Robin..
Hier machst du aber einen Denkfehler und vermutlich einen Verständnisfehler.
LACP hat NICHTS mit der Hash basierten Verteilung auf die Links zu tun ! LACP erkennt lediglich ob der Port ein Aggregation fähiger Port ist mehr nicht.
Roud Robin ist völlig utopisch und bei 802.3ad basierten LAGs niemals möglich, das ist oben ja auch schon mehrfach gesagt worden.
LAGs nach 802.3ad verwenden ausschliesslich ein Hash basiertes Verteilverfahren und machen niemals Round Robin, der Standard gibt das nicht vor und technisch geht das auch gar nicht.
Es wird lediglich einen XOR Verknüpfung der letzten 4 Bits der Mac oder eben der IP Adresse gemacht und daraus ein Hash berechnet der auf einen einzigen physischen Link zeigt über den dann diese Session physisch übertragen wird.
Diesen Algorithmus bestimmt der 802.3ad Standard nicht LACP ! Also bitte nichts wild durcheinanderbingen hier !
Letztlich bestimmt also nur die Adressierung der Clients den Weg. Bessere Hersteller rechnen in den Hash noch den Port mit hinein. Ob Cisco UND auch deinen XEN Server das können musst du in deren Dokumentation checken !
Können sie das nämlich nicht dann bestimmt einzig und allein die Adresspaarung egal ob Mac oder IP über den physischen Link der Datenübertragung.
Da ist es also dann auch sinnfrei ob du mit IPerf den Port wechselst. Das greift nur wenn der Port ins Hashing mit einberechnet wird.
Vermutlich kann dein XEN NIC Kartentreiber das nicht und dann fürht der IPerf Test zu nichts...klar.
Kläre das also wasserdicht vorher sonst misst und suchst du dir einen Wolf.
Wenn du wirklichen Round Robin willst, dann must du DCB oder Fabric Switches verwenden wie z,B. Brocade VDX 6740er die können sowas. Stinknormale Campus Switches aber können nur 802.3ad und da regiert der Hash und kein Round Robin !
Bei Linux macht man z.B. immer ein Bundling mit mode 4 und dann wird auch ein sauberes Balancing gemacht !
LACP hat NICHTS mit der Hash basierten Verteilung auf die Links zu tun ! LACP erkennt lediglich ob der Port ein Aggregation fähiger Port ist mehr nicht.
Roud Robin ist völlig utopisch und bei 802.3ad basierten LAGs niemals möglich, das ist oben ja auch schon mehrfach gesagt worden.
LAGs nach 802.3ad verwenden ausschliesslich ein Hash basiertes Verteilverfahren und machen niemals Round Robin, der Standard gibt das nicht vor und technisch geht das auch gar nicht.
Es wird lediglich einen XOR Verknüpfung der letzten 4 Bits der Mac oder eben der IP Adresse gemacht und daraus ein Hash berechnet der auf einen einzigen physischen Link zeigt über den dann diese Session physisch übertragen wird.
Diesen Algorithmus bestimmt der 802.3ad Standard nicht LACP ! Also bitte nichts wild durcheinanderbingen hier !
Letztlich bestimmt also nur die Adressierung der Clients den Weg. Bessere Hersteller rechnen in den Hash noch den Port mit hinein. Ob Cisco UND auch deinen XEN Server das können musst du in deren Dokumentation checken !
Können sie das nämlich nicht dann bestimmt einzig und allein die Adresspaarung egal ob Mac oder IP über den physischen Link der Datenübertragung.
Da ist es also dann auch sinnfrei ob du mit IPerf den Port wechselst. Das greift nur wenn der Port ins Hashing mit einberechnet wird.
Vermutlich kann dein XEN NIC Kartentreiber das nicht und dann fürht der IPerf Test zu nichts...klar.
Kläre das also wasserdicht vorher sonst misst und suchst du dir einen Wolf.
Wenn du wirklichen Round Robin willst, dann must du DCB oder Fabric Switches verwenden wie z,B. Brocade VDX 6740er die können sowas. Stinknormale Campus Switches aber können nur 802.3ad und da regiert der Hash und kein Round Robin !
Bei Linux macht man z.B. immer ein Bundling mit mode 4 und dann wird auch ein sauberes Balancing gemacht !
Ich habe mal noch weitere Recherchen betrieben - und bin auf folgende interessante Citrix Dokumentation zum Thema LACP gestoßen:
Quelle: CTX135690
Okay - so wie ich das jetzt verstanden habe, empfiehlt Citrix bei Storage Traffic auf LACP zu verzichten und stattdessen iSCSI zu verwenden.
Wollte eigentlich auf iSCSI verzichten, werde wohl aber nicht drum herum kommen..
Load balancing
Outgoing packets are distributed between active links. Both sides of the link — the switch and the server — are responsible for balancing their respective outgoing traffic. In XenServer, load balancing between links can be described as follows.
A hashing algorithm assigns a hash number (0-255) to each packet, based on a mix of MAC, IP and TCP/UDP port as required.
Each hash is assigned to one of the NICs on the bond, which means packets with the same hash are always sent through the same NIC.
If a new hash is found, it is assigned to the NIC that currently has the lowest utilization.
Rebalancing occurs at a regular interval — hashes are redistributed between the NICs to ensure all NICs are utilized to approximately the same extent.
Hashing algorithm
The hashing algorithm is chosen independently on both switch and server side, as each device balances its outgoing traffic. Rather than using the same method on both sides, hashing algorithm choice should reflect traffic patterns in each direction.
On the server side, vSwitch provides two hashing algorithms to choose from:
tcpudp_ports (default), based on source and destination IP, TCP/UDP ports and source MAC.
src_mac, based on source MAC address — this is the same mechanism as the one used already in balance-slb mode (traffic to/from a guest is not split).
On the switch side, the hashing algorithms depend on the switch brand and can have different names.
Use of TCP/IP parameters for hashing should provide load balancing for management traffic as well as improve it for the case of a low number of guest, as it allows packets from the same guest to be distributed over different NICs at the same time. However, neither of the hashing algorithms presents benefits for storage traffic, as in a typical configuration large amounts of data are sent using the same source and destination IP and ports, and while the endpoints remain the same, all packets will have the same hash assigned and so will be sent through the same NIC. Consider using multipathing rather than bonding for storage traffic.
In the case of src_mac hashing, there is a non-negligible probability that two different MAC addresses will get the same hash number assigned — and when such “MAC clash” occurs, the two VIFs will be always using the same link. In general, src_mac hashing cannot provide even traffic distribution over the links if the number of VIFs is smaller than the number of NICs.
Outgoing packets are distributed between active links. Both sides of the link — the switch and the server — are responsible for balancing their respective outgoing traffic. In XenServer, load balancing between links can be described as follows.
A hashing algorithm assigns a hash number (0-255) to each packet, based on a mix of MAC, IP and TCP/UDP port as required.
Each hash is assigned to one of the NICs on the bond, which means packets with the same hash are always sent through the same NIC.
If a new hash is found, it is assigned to the NIC that currently has the lowest utilization.
Rebalancing occurs at a regular interval — hashes are redistributed between the NICs to ensure all NICs are utilized to approximately the same extent.
Hashing algorithm
The hashing algorithm is chosen independently on both switch and server side, as each device balances its outgoing traffic. Rather than using the same method on both sides, hashing algorithm choice should reflect traffic patterns in each direction.
On the server side, vSwitch provides two hashing algorithms to choose from:
tcpudp_ports (default), based on source and destination IP, TCP/UDP ports and source MAC.
src_mac, based on source MAC address — this is the same mechanism as the one used already in balance-slb mode (traffic to/from a guest is not split).
On the switch side, the hashing algorithms depend on the switch brand and can have different names.
Use of TCP/IP parameters for hashing should provide load balancing for management traffic as well as improve it for the case of a low number of guest, as it allows packets from the same guest to be distributed over different NICs at the same time. However, neither of the hashing algorithms presents benefits for storage traffic, as in a typical configuration large amounts of data are sent using the same source and destination IP and ports, and while the endpoints remain the same, all packets will have the same hash assigned and so will be sent through the same NIC. Consider using multipathing rather than bonding for storage traffic.
In the case of src_mac hashing, there is a non-negligible probability that two different MAC addresses will get the same hash number assigned — and when such “MAC clash” occurs, the two VIFs will be always using the same link. In general, src_mac hashing cannot provide even traffic distribution over the links if the number of VIFs is smaller than the number of NICs.
Quelle: CTX135690
Okay - so wie ich das jetzt verstanden habe, empfiehlt Citrix bei Storage Traffic auf LACP zu verzichten und stattdessen iSCSI zu verwenden.
Wollte eigentlich auf iSCSI verzichten, werde wohl aber nicht drum herum kommen..
auf LACP zu verzichten und stattdessen iSCSI zu verwenden.
Oh oh oh...du stürzt schon wieder im freien Fall ab !! Bitte lese vorher WAS LACP ist und was iSCSI ist.Beides hat rein GAR NIX miteinander zu tun !!
Bitte keine Halbwahrheiten ohne Sinn und Verstand raushauen hier.
LACP detektiert Aggregation fähige Ports nicht mehr und nicht weniger !! iSCSI ist simpler IP Traffic und überträgt über TCP Frames Block Storage. Beides hat miteinander soviel zu tun wie ein Fisch mit einem Fahrrad !
Einem LACP Link der 802.3ad Link Aggreagtion macht ist es ziemlich egal ob über ihn HTTP, VoIP, FTP, iSCSI, SMB, NFS oder was für IP Traffic auch immer drüberfliesst.
Warum sollte ihn das auch irgendwie interessieren ??
Dem LAG ist es nur wichtig aus den Paket Daten die Adressen und sofern supportet den Port zu lesen um dann zu entscheiden WELCHES Adresspärchen über welchen physischen Link am Switch oder NIC Team geforwardet wird.
Alles was oben in den zitierten Erklärungen steht ist richtig.
Jede Seite macht für sich unabhängig die Hash Berechnung und forwardet unabhängig.
Und JA, wenn die IP Adressen der Endgeräte immer dieselben sind und auch die Ports ändert sich ja am Hash nicht das Geringste und der physische Link ist immer derselbe über den physisch übertragen wird.
Alles bekannte Binsenweisheiten die da stehen !
Aus dem Grunde nutzen viele RZ Betreiber auch Fabric sprich DCB basierte Switches, die diese Limitierung des 802.3ad Balancing Algorithmus eben nicht mehr haben.
Mit deinen Campus Switches musst du aber damit leben...die können nichts anderes ebensowenig deine Teaming Algorithmen in den Servern.
Oh oh oh...du stürzt schon wieder im freien Fall ab !! Bitte lese vorher WAS LACP ist und was iSCSI ist.
Beides hat rein GAR NIX miteinander zu tun !!
Beides hat rein GAR NIX miteinander zu tun !!
Ich gebe gerne zu, dass ich gerade bei dem Thema LACP nur oberflächliches Wissen habe. Und ich bin sehr gerne bereit mich eines besseren belehren zu lassen. Aber durcheinander hauen tue ich die beiden Themen LACP und iSCSI nun nicht. Ist schon klar dass die beiden Sachen nix miteinander zu tun haben, auch wenn ich theroetisch iSCSI über LACP laufen lassn kann, was mir faktisch aber genauso nix bringt.
Eben weil es beim Storage Traffic in der Regel nur eine Source- und eine Destination gibt (z.B. XenServer und NetApp), kann LACP, (unabhängig vom load-balance / hashing Verfahren) hier wohl nicht für Bandbreitenoptimierung verwendet werden.
Deswegen sagt ja hier Citrix auch, dass sich hier MultiPathing über iSCSI mehr lohnt, da, wie Du schon sagtest, iSCSI IP-Traffic über verschiedene IP Subnetze zum Ziel leitet.
Mit den 3750er Switchen muss ich leben. Die wurden mir so vorgesetzt und muss die Möglichkeiten nutzen, die mir die Switche bieten.
auch wenn ich theroetisch iSCSI über LACP laufen lassn kann,
Nein ! Sorry aber entweder hast oder willst du es nicht verstehen. Das ist jetzt nicht böse gemeint aber LACP ist ein Punkt zu Punkt Protokoll und hat mit dem iSCSI Transport nicht das Geringste zu tun.LACP erkennt nur automatisch ob Links Aggregation fähig sind oder nicht ! Kein bischen mehr...
Deine Formulierung ist technisch falach oder unglücklich, sorry.
Wenn überhaupt müsstest du sagen zu schickst iSCSI über ein 802.3ad LAG das wäre halbwegs korrekt.
Es gibt ja auch statische LAGs die du auf dem Switch konfigurierst ! Die machen kein LACP aber dennoch eine statische Link Aggreagtion auch wieder auf Basis des 802.3ad Algorithmuses.
Statische LAGs würden dann deine Formulierung komplett ad absurdum führen, deshalb nochmal die Erinnerung das LACP nix mit irgendwelchen IP Diensten oder Protokollen zu tun hat die über einen LAG übertragen werden.
Faktisch aber genauso nix bringt ein Fisch und ein Fahrrad zu verheiraten, deshalb ist es evident das das nix bringt.
Eben weil es beim Storage Traffic in der Regel nur eine Source- und eine Destination gibt (z.B. XenServer und NetApp), kann LACP, (unabhängig vom load-balance / hashing Verfahren) hier wohl nicht für Bandbreitenoptimierung verwendet werden.
Das ist genau richtig !Hier hilft dir nur ein Fabric oder DCB Switch, der andere Mechanismen nutzt.
Die wurden mir so vorgesetzt und muss die Möglichkeiten nutzen, die mir die Switche bieten.
Schreib nen Investitionsantrag für was Neues. Genug Gründe hast du ja jetzt Nein ! Sorry aber entweder hast oder willst du es nicht verstehen. Das ist jetzt nicht böse gemeint aber LACP ist ein Punkt zu Punkt Protokoll und hat mit dem iSCSI Transport nicht das Geringste zu tun.
Du unterstellst mir jetzt aber auch etwas, dass ich beides durcheinander werfe, nur weil ich in Hinblick der Bandbreitenoptimierung LACP/LAG und iSCSI zusammen in einem Satz erwähne
Ich werde mal weiter recherieren - ggf. iSCSI austesten.
Aber bis hierhin - erstmal danke vielmals um die tatkräftige Unterstützung, besonders von dir aqui
Und bitte weise mich auch weiterhin auf Unzulänglichkeiten meinerseits hin - denn das hilft mir auch zum Verständnis falls man doch mal etwas nicht richtig verstanden hat.Ich melde mich, wenn es etwas neues gibt. Kann auch etwas dauern, da ich nächste Woche nicht zu weiteren Tests kommen werde.
Hallo ihr beiden,
Bitte nochmal kurz zu meinem Verständis:
Bei 802.3ad wird pro LAG nur eine MAC Adresse, IP und damit auch der selbe Hash-Wert verwendet, deshalb hat läuft der Traffic bei allen 3 Geräten immer über die gleiche Leitung.
Würden sich hingegen mehrere Clients mit verschiedenen IP sowie MAC Adressen Daten von der NetApp holen, würde die Lastverteilung wie gewünscht funktionieren.
Hab ich das so richtig verstanden?
VG
Val
Bitte nochmal kurz zu meinem Verständis:
Bei 802.3ad wird pro LAG nur eine MAC Adresse, IP und damit auch der selbe Hash-Wert verwendet, deshalb hat läuft der Traffic bei allen 3 Geräten immer über die gleiche Leitung.
Würden sich hingegen mehrere Clients mit verschiedenen IP sowie MAC Adressen Daten von der NetApp holen, würde die Lastverteilung wie gewünscht funktionieren.
Hab ich das so richtig verstanden?
VG
Val
Jein
Generell ja, denn der XOR Hash des 802.3ad Verfahrens zeigt immer auf den physischen Link auf dem dieses Pärchen bzw. Session dann geforwardet wird.
Bei vielen Switches und Teaming oder Bonding Treibern (Server) kann man die Hash Berechnung konfigurieren. IP Adressen, Mac Adressen mit oder ohne TCP und UDP Port.
Sinn macht natürlich so viel wie möglich Parameter in die Berechnung zu bringen um die Verteilung granularer zu bekommen. Es wird aber niemals ein homogenes fifty fifty Verhältnis erreicht, denn das ist ja von der Struktur der im Netz verwendeten Mac oder IP Adressen bzw. Ports abhängig.
Wenn du Pech hast und alle deine 3 Geräte den gleichen Hash Wert ergeben bleiben die alle auf einem Link. Je mehr Geräte desto größer die Chance das einige einen anderen Link benutzen (anderer Hash)
Deshalb kann man die Frage nicht genau beantworten.
Der große Pluspunkt ist die TCP oder UDP Ports mit in die Berechnung zu bringen, denn der Source Port ist ein Random Port. Das erhöht dann die Wahrscheinlichkeit einer besseren Verteilung erheblich.
Es gibt aber viele Fussfallen die lauern und die man beachten muss.
Rennt der Traffic z.B. über einen Router oder L3 Switch dann ist die Destination Mac immer eine feste Mac (die des Routers) so kann es niemals eine Verteilung über einen LAG geben. Hier MUSS man also auf IP Adressen umstellen um wieder Granularität zu erreichen.
Fazit: 802.3ad LAGs erfordern etwas "Design" in einem komplexeren Netzwerk.
In dummen flachen und reinen L2 Netzen ist es natürlich einfacher, denn dort funktioniert es meist ohne Konfig aber dann mit anderen Nachteilen die solche flachen Layer 2 Strukturen ohne Segmentierung mit sich bringen.
Ein sehr gutes Testtool um LAG 802.3ad Verteilung grafisch sichtbar zu machen ist das obern bereits gepostete STG:
http://leonidvm.chat.ru/
mit einem SNMP Switch oder aktiviertem SNMP auf Server NICs "sieht" man sehr schön die Auslastung einzelner Links mit inbound und outbound Traffic.
Generell ja, denn der XOR Hash des 802.3ad Verfahrens zeigt immer auf den physischen Link auf dem dieses Pärchen bzw. Session dann geforwardet wird.
Bei vielen Switches und Teaming oder Bonding Treibern (Server) kann man die Hash Berechnung konfigurieren. IP Adressen, Mac Adressen mit oder ohne TCP und UDP Port.
Sinn macht natürlich so viel wie möglich Parameter in die Berechnung zu bringen um die Verteilung granularer zu bekommen. Es wird aber niemals ein homogenes fifty fifty Verhältnis erreicht, denn das ist ja von der Struktur der im Netz verwendeten Mac oder IP Adressen bzw. Ports abhängig.
Wenn du Pech hast und alle deine 3 Geräte den gleichen Hash Wert ergeben bleiben die alle auf einem Link. Je mehr Geräte desto größer die Chance das einige einen anderen Link benutzen (anderer Hash)
Deshalb kann man die Frage nicht genau beantworten.
Der große Pluspunkt ist die TCP oder UDP Ports mit in die Berechnung zu bringen, denn der Source Port ist ein Random Port. Das erhöht dann die Wahrscheinlichkeit einer besseren Verteilung erheblich.
Es gibt aber viele Fussfallen die lauern und die man beachten muss.
Rennt der Traffic z.B. über einen Router oder L3 Switch dann ist die Destination Mac immer eine feste Mac (die des Routers) so kann es niemals eine Verteilung über einen LAG geben. Hier MUSS man also auf IP Adressen umstellen um wieder Granularität zu erreichen.
Fazit: 802.3ad LAGs erfordern etwas "Design" in einem komplexeren Netzwerk.
In dummen flachen und reinen L2 Netzen ist es natürlich einfacher, denn dort funktioniert es meist ohne Konfig aber dann mit anderen Nachteilen die solche flachen Layer 2 Strukturen ohne Segmentierung mit sich bringen.
Ein sehr gutes Testtool um LAG 802.3ad Verteilung grafisch sichtbar zu machen ist das obern bereits gepostete STG:
http://leonidvm.chat.ru/
mit einem SNMP Switch oder aktiviertem SNMP auf Server NICs "sieht" man sehr schön die Auslastung einzelner Links mit inbound und outbound Traffic.
1
Guten morgen,
ich will mal einen kurzen aktuellen Stand der Dinge abgeben.
iSCSI ist installiert und funktioniert soweit auch. Für eine LUN, die auf der Seite von NetApp konfiguriert und über XenCenter bekannt gemacht wurde, werden mir auch 4 aktive Pfade zu der LUN angenzeigt.
Soweit die Theorie. Zum richtigen Test stehe ich momentan wieder am Anfang. Auf eine LUN per iSCSI über die Konsole von Xenserver zuzugreifen ist nicht ganz so trivial wie auf ein NFS Volume zuzugreifen. Aqui, du kannst mich auch hier gerne korrigieren, wenn ich da wieder einen falschen Ansatz verfolge
iperf funktioniert auf NetApp leider nicht, so kann ich das Tool zum Testen leider nicht verwenden.
D.h. ich müsste wieder eine große Datei von einer Seite auf die andere schieben. Und da muss ich aber auf die besagte LUN per Konsole des Xenservers zugreifen können.
Jetzt bin ich noch einen anderen Gedanken zum Testen nachgegangen: Das testen der VHD auf einer VM. Dabei kamen folgende Werte heraus:
Ich glaube aber, mein Ansatz ist schon falsch. Denn die Werte unterscheiden sich kaum voneinander.
Habt ihr noch irgendwelche Vorschläge?
ich will mal einen kurzen aktuellen Stand der Dinge abgeben.
iSCSI ist installiert und funktioniert soweit auch. Für eine LUN, die auf der Seite von NetApp konfiguriert und über XenCenter bekannt gemacht wurde, werden mir auch 4 aktive Pfade zu der LUN angenzeigt.
Soweit die Theorie. Zum richtigen Test stehe ich momentan wieder am Anfang. Auf eine LUN per iSCSI über die Konsole von Xenserver zuzugreifen ist nicht ganz so trivial wie auf ein NFS Volume zuzugreifen. Aqui, du kannst mich auch hier gerne korrigieren, wenn ich da wieder einen falschen Ansatz verfolge
iperf funktioniert auf NetApp leider nicht, so kann ich das Tool zum Testen leider nicht verwenden.
D.h. ich müsste wieder eine große Datei von einer Seite auf die andere schieben. Und da muss ich aber auf die besagte LUN per Konsole des Xenservers zugreifen können.
Jetzt bin ich noch einen anderen Gedanken zum Testen nachgegangen: Das testen der VHD auf einer VM. Dabei kamen folgende Werte heraus:
VHD liegt auf dem Local Storage des XenServers:
Results for timespan 1:
*******************************************************************************
actual test time: 60.00s
thread count: 1
proc count: 1
CPU | Usage | User | Kernel | Idle
-------------------------------------------
0| 100.00%| 9.72%| 90.28%| 0.00%
-------------------------------------------
avg.| 100.00%| 9.72%| 90.28%| 0.00%
Total IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 49628602368 | 12116358 | 788.85 | 201946.12 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 49628602368 | 12116358 | 788.85 | 201946.12
Read IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 24791736320 | 6052670 | 394.07 | 100881.24 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 24791736320 | 6052670 | 394.07 | 100881.24
Write IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 24836866048 | 6063688 | 394.78 | 101064.88 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 24836866048 | 6063688 | 394.78 | 101064.88
VHD liegt auf einem NFS Volume:
Results for timespan 1:
*******************************************************************************
actual test time: 60.04s
thread count: 1
proc count: 1
CPU | Usage | User | Kernel | Idle
-------------------------------------------
0| 100.00%| 9.22%| 90.78%| 0.00%
-------------------------------------------
avg.| 100.00%| 9.22%| 90.78%| 0.00%
Total IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 40845832192 | 9972127 | 648.76 | 166083.18 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 40845832192 | 9972127 | 648.76 | 166083.18
Read IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 20405473280 | 4981805 | 324.10 | 82970.67 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 20405473280 | 4981805 | 324.10 | 82970.67
Write IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 20440358912 | 4990322 | 324.66 | 83112.51 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 20440358912 | 4990322 | 324.66 | 83112.51
VHD liegt auf einer LUN:
Results for timespan 1:
*******************************************************************************
actual test time: 60.03s
thread count: 1
proc count: 1
CPU | Usage | User | Kernel | Idle
-------------------------------------------
0| 100.00%| 9.46%| 90.54%| 0.00%
-------------------------------------------
avg.| 100.00%| 9.46%| 90.54%| 0.00%
Total IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 41826422784 | 10211529 | 664.51 | 170113.74 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 41826422784 | 10211529 | 664.51 | 170113.74
Read IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 20894625792 | 5101227 | 331.96 | 84981.28 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 20894625792 | 5101227 | 331.96 | 84981.28
Write IO
thread | bytes | I/Os | MB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 20931796992 | 5110302 | 332.55 | 85132.46 | c:\Test.dat
(1024KB)
------------------------------------------------------------------------------
total: 20931796992 | 5110302 | 332.55 | 85132.46
Ich glaube aber, mein Ansatz ist schon falsch. Denn die Werte unterscheiden sich kaum voneinander.
Habt ihr noch irgendwelche Vorschläge?
Aqui, du kannst mich auch hier gerne korrigieren, wenn ich da wieder einen falschen Ansatz verfolge
Ne ist schon alles gut Aber so schwer ists ja nun auch wieder nicht:
Netzwerk Management Server mit Raspberry Pi
iperf funktioniert auf NetApp leider nicht, so kann ich das Tool zum Testen leider nicht verwenden.
Kannst denn einen Testrechner statt NetApp anschliessen oder parallel mit gleichen Bedingungen ?Wenn du nicht Server oder VM Leuten noch kurz sagst was sich hinter "VHD" verbirgt wäre das hilfreich (Virtual Hard Disk ?)
Sry - genau, das virtuelle Laufwerk meinte ich mit der VHD
Ganz so trivial mit dem Einbinden ist das nicht, aqui. Der XenServer unterscheidet sich da wohl ganz erheblich von einem normalem Linux. Ich kann auf der Konsole nicht auf das iSCSI zugreifen. Das wird mir nur auf dem XenCenter ermöglicht.
Ich möchte auch nicht für das NetApp ein anderes System verwenden. Ich möchte ja eben gerade die jetztige Konfiguration bzw. die Kommunikation zw. NetApp und XenServer testen.
Momentan liegt es eher an der Zeit, die mir zum Testen fehlt. Aber ich bin noch an den Storage Tests auf den jeweiligen VMs dran.
Wenn ich beweisen kann, dass bei zeitgleichen Tests auf mehreren VMs die Performance bei einem NFS Volume einbricht, und auf einem iSCSI Volume nicht, dann habe ich meinen Beweis, dass iSCSI wie gewünscht funktioniert.
Ganz so trivial mit dem Einbinden ist das nicht, aqui. Der XenServer unterscheidet sich da wohl ganz erheblich von einem normalem Linux. Ich kann auf der Konsole nicht auf das iSCSI zugreifen. Das wird mir nur auf dem XenCenter ermöglicht.
Ich möchte auch nicht für das NetApp ein anderes System verwenden. Ich möchte ja eben gerade die jetztige Konfiguration bzw. die Kommunikation zw. NetApp und XenServer testen.
Momentan liegt es eher an der Zeit, die mir zum Testen fehlt. Aber ich bin noch an den Storage Tests auf den jeweiligen VMs dran.
Wenn ich beweisen kann, dass bei zeitgleichen Tests auf mehreren VMs die Performance bei einem NFS Volume einbricht, und auf einem iSCSI Volume nicht, dann habe ich meinen Beweis, dass iSCSI wie gewünscht funktioniert.
Der XenServer unterscheidet sich da wohl ganz erheblich von einem normalem Linux.
Dann hast du aber ein XEN Problem und kein Netzwerk Problem. Wäre aber verwunderlich denn alle relevanten Hypervisor am Markt nutzen ausnahmslos 802.3ad LAGs bzw. können mit diesen konfiguriert werden.Müssen sie ja auch, denn das ist weltweiter Standard.
Ich möchte ja eben gerade die jetztige Konfiguration bzw. die Kommunikation zw. NetApp und XenServer testen.
OK, das ist ja auch kein Problem. Du musst dann nur mit anderen Tools arbeiten und dir die Port Auslastung ansehen.Beim Switch sind das die bekannten show Kommandos auf dem CLI oder du machst das grafisch per SNMP mit kleinen Tools wie snmpwalk oder dem STP Grapher:
http://leonidvm.chat.ru
SNMP wird auch dein NetApp supporten so das du da kein Problem hast. XEN kann das auch SNMP muss man aber aktivieren dort.
Momentan liegt es eher an der Zeit, die mir zum Testen fehlt.
Das können wir vom Forum natürlich auch nicht ändern... 
bei einem NFS Volume einbricht, und auf einem iSCSI Volume nicht,
Lässt du NFS mit TCP oder UDP Encapsulation laufen ??NFS mit UDP wird iSCSI vermutlich nicht toppen können.
Zitat von @aqui:
> Der XenServer unterscheidet sich da wohl ganz erheblich von einem normalem Linux.
Dann hast du aber ein XEN Problem und kein Netzwerk Problem. Wäre aber verwunderlich denn alle relevanten Hypervisor am Markt
nutzen ausnahmslos 802.3ad LAGs bzw. können mit diesen konfiguriert werden.
Müssen sie ja auch, denn das ist weltweiter Standard.
> Der XenServer unterscheidet sich da wohl ganz erheblich von einem normalem Linux.
Dann hast du aber ein XEN Problem und kein Netzwerk Problem. Wäre aber verwunderlich denn alle relevanten Hypervisor am Markt
nutzen ausnahmslos 802.3ad LAGs bzw. können mit diesen konfiguriert werden.
Müssen sie ja auch, denn das ist weltweiter Standard.
Meine Aussage bezog sich hier in erster Linie auf iSCSI (speziell das Mounten eines iSCSI Volumes, nicht um LAG's
> bei einem NFS Volume einbricht, und auf einem iSCSI Volume nicht,
Lässt du NFS mit TCP oder UDP Encapsulation laufen ??
NFS mit UDP wird iSCSI vermutlich nicht toppen können.
Lässt du NFS mit TCP oder UDP Encapsulation laufen ??
NFS mit UDP wird iSCSI vermutlich nicht toppen können.
Auf dem NetApp (FAS2220) kann ich weder TCP noch UDP einstellen.. Per Default wird aber doch UDP verwendet und das sollte auch bei dem NetApp der Fall sein.
Ich habe jetzt mal das Windows-eigene Tool WinSat zum Testen der Disk Performance verwendet und folgende Tests durchgeführt.
- ein Test mit einer VM
- ein Test mit drei VMs gleichzeitig
- erst ein Lese- dann ein Schreibtest
- Test auf Local Store, NFS Volume, iSCSI LUN
NFS Test - 1 VM (read):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 101.58 MB/s 7.1
> Gesamtausführungszeit 00:01:11.73
##################################################################################
NFS Test - 3 VMs (read):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 51.73 MB/s 6.5
> Gesamtausführungszeit 00:02:10.67
##################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 49.05 MB/s 6.5
> Gesamtausführungszeit 00:02:17.20
##################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 50.48 MB/s 6.5
> Gesamtausführungszeit 00:02:20.31
##################################################################################
##################################################################################
NFS Test - 1 VM (write):
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 88.49 MB/s
> Gesamtausführungszeit 00:01:09.58
##################################################################################
NFS Test - 3 VMs (write):
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 41.09 MB/s
> Gesamtausführungszeit 00:02:27.73
##################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 44.85 MB/s
> Gesamtausführungszeit 00:02:43.10
##################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000' count 50
> Disk Random 16.0 Write 41.25 MB/s
> Gesamtausführungszeit 00:02:38.33
##################################################################################
##################################################################################
Local Storage - 1 VM (read):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 5.98 MB/s 5.1
> Gesamtausführungszeit 00:11:59.46
#################################################################################
Local Storage - 3 VMs (read):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 6.26 MB/s 5.1
> Gesamtausführungszeit 00:11:56.67
##################################################################################################<
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 5.10 MB/s 5.1
> Gesamtausführungszeit 00:14:56.44
##################################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 10.93 MB/s 5.4
> Gesamtausführungszeit 00:06:34.34
##################################################################################
##################################################################################
Local Storage - 1 VM (write):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 4.24 MB/s 5.1
> Gesamtausführungszeit 00:11:59.46
#################################################################################
Local Storage - 3 VMs (write):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 3.16 MB/s 5.1
> Gesamtausführungszeit 00:11:56.67
##################################################################################################<
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 5.16 MB/s 5.1
> Gesamtausführungszeit 00:14:56.44
##################################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 4.95 MB/s 5.4
> Gesamtausführungszeit 00:06:34.34
##################################################################################
##################################################################################
LUN Volume - 1 VM (read):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 154.50 MB/s 7.5
> Gesamtausführungszeit 00:00:57.41
#################################################################################
LUN Volume - 3 VMs (read):
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 114.98 MB/s 7.2
> Gesamtausführungszeit 00:01:22.98
#################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 100.45 MB/s 7.1
> Gesamtausführungszeit 00:01:39.75
#################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -read -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Read 94.99 MB/s 7.1
> Gesamtausführungszeit 00:01:45.63
#################################################################################
#################################################################################
LUN Volume - 1 VM (write):
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 87.29 MB/s
> Gesamtausführungszeit 00:01:10.53
#################################################################################
LUN Volume - 3 VMs(write):
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 43.50 MB/s
> Gesamtausführungszeit 00:02:41.20
#################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 41.20 MB/s
> Gesamtausführungszeit 00:02:47.95
#################################################################################
> Wird ausgeführt: Speicherbewertung '-ran -write -drive c -iocount 5000 -count 50'
> Disk Random 16.0 Write 44.72 MB/s
> Gesamtausführungszeit 00:02:46.50
Die Performance mit iSCSI ist zwar besser - aber einbrechen tut diese dennoch, wenn ich drei gleichzeitige Tests starte.
Mich wundert nur, warum der test auf dem local Store des XenServers so grottig ist..
Mein Hauptproblem ist - ich muss es leider ehrlich gestehen: ich kann alle Komponenten installieren, konfigurieren und verwalten, aber über die tiefgreifenden Funktionsweisen der einzelnen Komponenten habe ich eher rudimentären Wissen. Ich muss mich da fachlich noch weiter einarbeiten.
Das System soll zwar "nur" als Backup Standort eingerichtet werden, aber trotzdem muss ich mich noch tiefer in die Thematiken (und deren Kombinationen) SAN, Windows, Netzwerk, Firewall und Virtualisierung einarbeiten.
Gibt es Geschwindigkeitsunterschiede auf der Infrastruktur Verbindung ? Hast du z.B. 100Mbit Anschlüsse und 1Gig im Mix oder ist die Stecke Server-Netzwerk-Storage durchgängig 1 Gig ??
Sinn der Frage: Wenn du Speed Differenzen hast brauchst du zwingend gute Switches mit viel Buffer ansonsten kann es auch zu solchen Effekten kommen wie bei dir.
Sinn der Frage: Wenn du Speed Differenzen hast brauchst du zwingend gute Switches mit viel Buffer ansonsten kann es auch zu solchen Effekten kommen wie bei dir.
Die Verbindung über den Switch zwischen XenServer und NetApp ist pro Verbindung durchgängig 1 Gbit/s.
Sowohl NetApp als auch XenServer sind mit jeweils 4 Verbindungen an dem Switch angeschlossen, bei der jede Verbindung sich in einem eigenem Subnetz befindet. Auch das sollte korrekt konfiguriert sein, da jede angebundene LUN im XenCenter über 4 aktive Pfade verfügt.
Testen tue ich übrigens mit drei VMs die auf einem XenServer laufen und deren virtuelle Festplatten auf einer angebundenen LUN liegen.
Eigentlich sollte das Testszenario stimmig sein. Aber wenn dem so ist, dürften die Testwerte bei parallelen Schreib- /Lesetests nicht einbrechen.
So ist eigentlich mein Verständnis..
Sowohl NetApp als auch XenServer sind mit jeweils 4 Verbindungen an dem Switch angeschlossen, bei der jede Verbindung sich in einem eigenem Subnetz befindet. Auch das sollte korrekt konfiguriert sein, da jede angebundene LUN im XenCenter über 4 aktive Pfade verfügt.
Testen tue ich übrigens mit drei VMs die auf einem XenServer laufen und deren virtuelle Festplatten auf einer angebundenen LUN liegen.
Eigentlich sollte das Testszenario stimmig sein. Aber wenn dem so ist, dürften die Testwerte bei parallelen Schreib- /Lesetests nicht einbrechen.
So ist eigentlich mein Verständnis..
Auch das sollte korrekt konfiguriert sein,
Hilfreich wäre es wenn du dafür mal ein show link-aggregate oder show etherchannel oder show int portchannel mindestens aber ein show lacp mal posten kannst nur damit man wasserdicht sehen kann das die LAGs auch wirklich up and running sind.Das ganze hat aber einen gewaltigen Haken:
Dadurch das beide Anschlüsse in unterschiedlichen IP Netzen sind und du über den Switch routest kannst du keine Hash Berechnung über die Mac Adressen machen, denn die Mac Pärchen sind ja immer Server Mac und NetApp Mac.
Folglich wird der Hash immer und immer wieder nur auf einen einzelnen Link zeigen und damit physisch immer nur einen einzelnen Link benutzen.
Auch eine Hash Berechnung über IP Adressen und Port wird nichts bringen wenn du nur Traffic zwischen Server und NetApp hast, da das ja immer und ewig die gleichen IP Adressen benutzt.
Folglich wird also auch über einen IP Hash immer nur ein einziger Link benutzt. Aus Sicht der Netzwerk Infrastruktur bringt es also gar nichts einen 4er LAG zu machen wenn du nur zw. Server und NetApp Daten schaufeln willst.
Da macht es dann mehr Sinn auf 10 GiG zu gehen, denn Link Aggregation bringt dich da nicht weiter.
Aqui, ich glaube wir reden im Moment komplett aneinander vorbei
Ich bin momentan bei der Umsetzung des Storage-LANs über iSCSI. Die Konfiguration ist komplett unterschiedlich zu LAGs.
Ich habe mal eine vereinfachte Übersicht erstellt:
D.h. es gibt switchseitig keine Link Aggregation. iSCSI wird softwareseitig von den Endgeräten (also NetApp und XenServer) implementiert.
Anbei mal die Konfiguration des Switches bzgl. des Storage LAN:
Switch Global Config:
Switch NetApp Konfig):
Switch (XenServer Konfig):
Ich bin momentan bei der Umsetzung des Storage-LANs über iSCSI. Die Konfiguration ist komplett unterschiedlich zu LAGs.
Ich habe mal eine vereinfachte Übersicht erstellt:
D.h. es gibt switchseitig keine Link Aggregation. iSCSI wird softwareseitig von den Endgeräten (also NetApp und XenServer) implementiert.
Anbei mal die Konfiguration des Switches bzgl. des Storage LAN:
Switch Global Config:
no ip http server
ip http secure-server
no cdp run
Switch NetApp Konfig):
interface GigabitEthernet1/0/25
description Storage NetApp03-C1 e0a
switchport access vlan 1
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
interface GigabitEthernet1/0/26
description Storage NetApp03-C1 e0b
switchport access vlan 2
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
!
!
interface GigabitEthernet2/0/25
description Storage NetApp03-C1 e0c
switchport access vlan 3
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
interface GigabitEthernet2/0/26
description Storage NetApp03-C1 e0d
switchport access vlan 4
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
Switch (XenServer Konfig):
interface GigabitEthernet1/0/31
description Storage XS-Node01 ETH4
switchport access vlan 1
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
interface GigabitEthernet1/0/32
description Storage XS-Node01 ETH5
switchport access vlan 2
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
!
!
interface GigabitEthernet2/0/31
description Storage XS-Node01 ETH6
switchport access vlan 3
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
interface GigabitEthernet2/0/32
description Storage XS-Node01 ETH7
switchport access vlan 4
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard loop
!
Aqui, ich glaube wir reden im Moment komplett aneinander vorbei
Ooops, sorry.... ja sehe ich schon. Deine 4 Links sind keine Trunks sondern 4 separate IP Netze. Sorry missverstanden Ein Bild sagt mehr als 1000 Worte
OK, dann ist der Switch quasi gar nicht existent, denn der reicht ja im L2 nur durch. Du jast dann quasi 4 parallele IP Netze.
Da hängts dann nun einzig und allein davon ab welche NIC in der Bindungsreihenfolge die erste ist.
Ein ist aber klar: Damit lässt sich keinerlei Art von Loadbalancing oder Load Sharing erreichen ! In so einem Design ist das aussichtslos aber das weisst du sicher auch selber.
Mein Ziel ist es bei großen Datenmengen alle vier Verbindungen nutzen zu können.
Und so wie ich iSCSI verstanden habe, wird z.B. NIC 1 für ein Datenstrom genutzt, bis dieser voll ausgelastet ist. Wenn das passiert, wird NIC 2 hinzugeschaltet. Die Prozedur geht bei meiner Konfiguration bis zu NIC 4.
So ist zumindest mein Verständnis - oder habe ich da wieder etwas außer acht gelassen? ^^
Und so wie ich iSCSI verstanden habe, wird z.B. NIC 1 für ein Datenstrom genutzt, bis dieser voll ausgelastet ist. Wenn das passiert, wird NIC 2 hinzugeschaltet. Die Prozedur geht bei meiner Konfiguration bis zu NIC 4.
So ist zumindest mein Verständnis - oder habe ich da wieder etwas außer acht gelassen? ^^
Das ist so in dieser Konstellation mit 4 parallelen IP Netzen niemals möglich. Der iSCSI Prozess ist ja nur an ein IP Netz gebunden, da er sich da immer an der Ziel IP und der lokalen Routing Tablelle orientiert !
Mit separaten IP Netzen ist das völlig unmöglich.
Machbar nur mit Link Aggreagtion im Layer 2 aber auch da bekommst du keine granulare Verteilung aus den oben genanten Gründen (Mac und IP Hashberechnung)
Wenn du es wasserdicht lösen willst das du einen wirkliche per Paket Distribution über die 4 Links hast mit einer absoluten gleichmässigen Verteilung bekommst du das nur mit Fabric Switches hin.
Cisco Nexus oder Brocade VDX sind da die Klassiker. Die benutzen allesamt ein paketbasierendes Roud Robin Verfahren auf multiplen Links die einen gleichmässige Verteilung garantieren.
In IP Storage basierten Netzen sind die mehr oder minder eh Pflicht heutzutage, da sie ein identisches Verhalten abbilden wie man das aus Fibre Channel Storage Netzen kennt. Portieren das also quasi in den IP Bereich und Ethernet.
Das wäre die Ideallösung !
Ansonsten ist simples Link Aggregation 802.3ad mit LACP dein Weg zum Ziel.
Mit separaten IP Netzen ist das völlig unmöglich.
Machbar nur mit Link Aggreagtion im Layer 2 aber auch da bekommst du keine granulare Verteilung aus den oben genanten Gründen (Mac und IP Hashberechnung)
Wenn du es wasserdicht lösen willst das du einen wirkliche per Paket Distribution über die 4 Links hast mit einer absoluten gleichmässigen Verteilung bekommst du das nur mit Fabric Switches hin.
Cisco Nexus oder Brocade VDX sind da die Klassiker. Die benutzen allesamt ein paketbasierendes Roud Robin Verfahren auf multiplen Links die einen gleichmässige Verteilung garantieren.
In IP Storage basierten Netzen sind die mehr oder minder eh Pflicht heutzutage, da sie ein identisches Verhalten abbilden wie man das aus Fibre Channel Storage Netzen kennt. Portieren das also quasi in den IP Bereich und Ethernet.
Das wäre die Ideallösung !
Ansonsten ist simples Link Aggregation 802.3ad mit LACP dein Weg zum Ziel.
Hallo zusammen,
LACP reingeschrieben und je 4 Verbindungen von dem Server und der NetApp zu
den beiden Switchen gezeichnet!
und dann richte iSCSI auf den beiden Geräten ein.
LAG (WRR = Weighted round robin) an die beiden Switche anbinden und dann
das iSCSI auf den beiden Geräten einrichten, und in wie vielen VLANs die beiden
Geräte später Mitglied sind sollte keine Rolle spielen.
und wenn man die Kabel alle ausnutzen möchte sollte man immer
ein LAG anlegen bei dem auch alle Kabel mit in Benutzung sind!
Und nicht das erst ein Kabel defekt sein muss damit das nächste
in Benutzung kommt. Alternativ kann man sich sicherlich bei zu großen
Datenmengen auch einmal Gedanken über eine SFP+ oder 10 GbE
Anbindung machen, was mehr Durchsatz ermöglicht und zum
anderen Ports an den Switchen spart und zusätzlich noch mittels
iSCSI gut umzusetzen ist, die @Dani hier im Forum hat das auch so
bei sich umgesetzt;
- 10 GBit/s
- iSCSI
- LAG (statisch) WRR
Und das läuft gut so wie sie hier berichtet hat, wäre ja mal ein Denkanstoß oder nicht?
Gruß
Dobby
Aqui, ich glaube wir reden im Moment komplett aneinander vorbei
Das ist dann aber auch nicht @aqui´s Schuld denn im ersten Bild hast Du ganz klarLACP reingeschrieben und je 4 Verbindungen von dem Server und der NetApp zu
den beiden Switchen gezeichnet!
Ich bin momentan bei der Umsetzung des Storage-LANs über iSCSI.
Die Konfiguration ist komplett unterschiedlich zu LAGs.
Binde den Server und die NetApp einfach via LAG an beiden Switche anDie Konfiguration ist komplett unterschiedlich zu LAGs.
und dann richte iSCSI auf den beiden Geräten ein.
Ich habe mal eine vereinfachte Übersicht erstellt:
Die NetApp und den Server via dynamischen LAG (LACP) oder aber statischemLAG (WRR = Weighted round robin) an die beiden Switche anbinden und dann
das iSCSI auf den beiden Geräten einrichten, und in wie vielen VLANs die beiden
Geräte später Mitglied sind sollte keine Rolle spielen.
Mein Ziel ist die Ausnutzung aller Interface des Bonds.
Habe ich einen Denkfehler in meinen Überlegungen?
Hier schon wieder , ein Bond ist die Bezeichnung eines LAGsHabe ich einen Denkfehler in meinen Überlegungen?
und wenn man die Kabel alle ausnutzen möchte sollte man immer
ein LAG anlegen bei dem auch alle Kabel mit in Benutzung sind!
Und nicht das erst ein Kabel defekt sein muss damit das nächste
in Benutzung kommt. Alternativ kann man sich sicherlich bei zu großen
Datenmengen auch einmal Gedanken über eine SFP+ oder 10 GbE
Anbindung machen, was mehr Durchsatz ermöglicht und zum
anderen Ports an den Switchen spart und zusätzlich noch mittels
iSCSI gut umzusetzen ist, die @Dani hier im Forum hat das auch so
bei sich umgesetzt;
- 10 GBit/s
- iSCSI
- LAG (statisch) WRR
Und das läuft gut so wie sie hier berichtet hat, wäre ja mal ein Denkanstoß oder nicht?
Gruß
Dobby
@108012:
LACP reingeschrieben und je 4 Verbindungen von dem Server und der NetApp zu
den beiden Switchen gezeichnet!
Die Überschrift lautet aber "XenServer, NetApp, Cisco - Storage Design, maximale Nutzung der Netzwerkbandbreite". Das heißt nicht, dass ich mich von Anfang an auf LAG über LACP festgelegt habe.
Du hast recht - am Anfang hielt ich LACP für die beste Option für die Umsetzung des Storage LANs - bis mich @aqui eines Besseren belehrt hat.
Ich habe dann auf iSCSI über Multipathing geschwenkt, das steht auch so oben. Vielleicht ist das aber untergegangen.
Ich habe mich an die Best Practises von
https://support.citrix.com/servlet/KbServlet/download/33310-102-696318/x ...
gehalten. Und ich denke nachfolgendes Bild erklärt meine jetzige Konfguration:
Switch1 & Switch2 wären in meinem Fall die 4 unterschiedlichen VLANs, da ich ja vier NICs statt zwei zur Verfügung habe.
und wenn man die Kabel alle ausnutzen möchte sollte man immer
ein LAG anlegen bei dem auch alle Kabel mit in Benutzung sind!
...
Alternativ kann man sich sicherlich bei zu großen
Datenmengen auch einmal Gedanken über eine SFP+ oder 10 GbE
Anbindung machen
...
Du beziehst dich auf meinen ersten Post - dort war ich ja noch bei der Umsetzung von LACP.
Und ich sagte ja bereits - leider muss ich mit der vorhandenen Hardware leben, die mir zur Verfügung steht
@aqui
Aber wenn dem so ist, wozu dann der Aufwand iSCSI über verschiedene Subnetze zu konfigurieren, wenn ich nur eine Leitung benutzten kann?
Aqui, ich glaube wir reden im Moment komplett aneinander vorbei
Das ist dann aber auch nicht @aqui´s Schuld denn im ersten Bild hast Du ganz klarLACP reingeschrieben und je 4 Verbindungen von dem Server und der NetApp zu
den beiden Switchen gezeichnet!
Die Überschrift lautet aber "XenServer, NetApp, Cisco - Storage Design, maximale Nutzung der Netzwerkbandbreite". Das heißt nicht, dass ich mich von Anfang an auf LAG über LACP festgelegt habe.
Du hast recht - am Anfang hielt ich LACP für die beste Option für die Umsetzung des Storage LANs - bis mich @aqui eines Besseren belehrt hat.
Ich habe dann auf iSCSI über Multipathing geschwenkt, das steht auch so oben. Vielleicht ist das aber untergegangen.
Binde den Server und die NetApp einfach via LAG an beiden Switche an
und dann richte iSCSI auf den beiden Geräten ein.
und dann richte iSCSI auf den beiden Geräten ein.
Ich habe mich an die Best Practises von
https://support.citrix.com/servlet/KbServlet/download/33310-102-696318/x ...
gehalten. Und ich denke nachfolgendes Bild erklärt meine jetzige Konfguration:
Mein Ziel ist die Ausnutzung aller Interface des Bonds.
Hier schon wieder , ein Bond ist die Bezeichnung eines LAGsund wenn man die Kabel alle ausnutzen möchte sollte man immer
ein LAG anlegen bei dem auch alle Kabel mit in Benutzung sind!
...
Alternativ kann man sich sicherlich bei zu großen
Datenmengen auch einmal Gedanken über eine SFP+ oder 10 GbE
Anbindung machen
...
Du beziehst dich auf meinen ersten Post - dort war ich ja noch bei der Umsetzung von LACP.
Und ich sagte ja bereits - leider muss ich mit der vorhandenen Hardware leben, die mir zur Verfügung steht
@aqui
Das ist so in dieser Konstellation mit 4 parallelen IP Netzen niemals möglich. Der iSCSI Prozess ist ja nur an ein IP Netz gebunden, da er sich da immer an der Ziel IP und der lokalen Routing Tablelle orientiert !
Mit separaten IP Netzen ist das völlig unmöglich.
Mit separaten IP Netzen ist das völlig unmöglich.
Aber wenn dem so ist, wozu dann der Aufwand iSCSI über verschiedene Subnetze zu konfigurieren, wenn ich nur eine Leitung benutzten kann?
OK, das Konzept oben in der Zeichnung ist schlüssig wenn man mit IP Multipathing arbeitet. In so einem Umfeld macht es Sinn.
Hier ist aber essentiell wichtig das sowohl Storage als auch Server IP Multipathing supporten, denn sonst geht das in die Hose wenn es nicht beidseitig supportet ist.
Hier ist aber essentiell wichtig das sowohl Storage als auch Server IP Multipathing supporten, denn sonst geht das in die Hose wenn es nicht beidseitig supportet ist.
Ich poste mal noch das aktuelle Bild einer eingehangenen LUN im XenCenter:
Alle 4 Pfade der LUN am XenServer sind aktiv.
Dennoch ist immer noch nicht geklärt, warum bei gleichzeitigem Trafficverkehr von mehreren VMs die Übertragungsperformance einbricht (Tests s. oben).
Sollte doch nach meinem Verständnis nicht passieren. Wenn die Maximallast des 1. Pfades erreicht wird, sollte er den/die nächsten Pfade hinzuschalten, richtig?
Alle 4 Pfade der LUN am XenServer sind aktiv.
Dennoch ist immer noch nicht geklärt, warum bei gleichzeitigem Trafficverkehr von mehreren VMs die Übertragungsperformance einbricht (Tests s. oben).
Sollte doch nach meinem Verständnis nicht passieren. Wenn die Maximallast des 1. Pfades erreicht wird, sollte er den/die nächsten Pfade hinzuschalten, richtig?
Das ist in der Tat schon sehr merkwürdig und ungewöhnlich und würde dann eher auf ein Fehler des Treibers oder des Balancing Algorythmusses hinweisen !
Um ganz sicher das Netzwerk auszuschliessen solltest du dir die Lastverteilung auf den 4 Links mal grafisch ansehen wenn du da Daten schaufelst.
Am allereinfachsten geht das mit dem STG Tool:
http://leonidvm.chat.ru
Das kanst du 4mal öffnen (je einen Grafik pro Link) auf deinem Rechner und beobachten. So kannst du wunderbar grafisch sehen ob die Links entsprechend ausgelastet werden oder ob das Endgerät gar kein Balancing macht und weiterhin nur einen Link aktiv nutzt.
SNMP musst du dann natürlich aktivieren auf dem Switch.
Um ganz sicher das Netzwerk auszuschliessen solltest du dir die Lastverteilung auf den 4 Links mal grafisch ansehen wenn du da Daten schaufelst.
Am allereinfachsten geht das mit dem STG Tool:
http://leonidvm.chat.ru
Das kanst du 4mal öffnen (je einen Grafik pro Link) auf deinem Rechner und beobachten. So kannst du wunderbar grafisch sehen ob die Links entsprechend ausgelastet werden oder ob das Endgerät gar kein Balancing macht und weiterhin nur einen Link aktiv nutzt.
SNMP musst du dann natürlich aktivieren auf dem Switch.
Guten morgen,
Aqui, Du hast mich auf die Lösung gebracht
Ich habe statt dem STG Tool einfach das Cisco Hauseigene Tool CNA (Cisco Network Assistant) verwendet, um mir den Traffic der einzelnen Links anzeigen zu lassen.
Zum Testen ist mir einfach folgende Idee gekommen: Ich verschiebe die virtuellen Datenträger der VMs vom lokalen Storage des XenServers auf die LUN des NetApps bzw. umgekehrt - so umgehe ich, dass die Virtualisierungsebene der XenServer den Traffic beschränkt und ich somit die volle Bandbreite der Links ausnutzen kann.
So schaut das Ganze dann aus:
Zum Verständnis: Jeder Link zeigt die Summe der Bandbreite aller Mitglieder des iSCSI-Multipathing an.
Der Durchschnitt beträgt ca. 500.000 kbytes/s = 4.000.000 kbit/s = 4 gbit/s was die volle Bandbreite aller vier verwendeten Interfaces darstellt
Ich bedanke mich für eure Unterstützung und besonders dir Aqui. Vor allen, dass du zum Verständnis der einen oder anderen Sache, die ich offensichtlich noch nicht richtig verstanden hatte, beigetragen hast
Aqui, Du hast mich auf die Lösung gebracht
Ich habe statt dem STG Tool einfach das Cisco Hauseigene Tool CNA (Cisco Network Assistant) verwendet, um mir den Traffic der einzelnen Links anzeigen zu lassen.
Zum Testen ist mir einfach folgende Idee gekommen: Ich verschiebe die virtuellen Datenträger der VMs vom lokalen Storage des XenServers auf die LUN des NetApps bzw. umgekehrt - so umgehe ich, dass die Virtualisierungsebene der XenServer den Traffic beschränkt und ich somit die volle Bandbreite der Links ausnutzen kann.
So schaut das Ganze dann aus:
Zum Verständnis: Jeder Link zeigt die Summe der Bandbreite aller Mitglieder des iSCSI-Multipathing an.
Der Durchschnitt beträgt ca. 500.000 kbytes/s = 4.000.000 kbit/s = 4 gbit/s was die volle Bandbreite aller vier verwendeten Interfaces darstellt
Ich bedanke mich für eure Unterstützung und besonders dir Aqui. Vor allen, dass du zum Verständnis der einen oder anderen Sache, die ich offensichtlich noch nicht richtig verstanden hatte, beigetragen hast
Hört sich gut an.
Fragenoch zum Schluss: Wo kann man das CNA Tool runterladen und ist das SNMP basierend, so das man es ggf. auch für andere Hersteller verwenden kann ?
Fragenoch zum Schluss: Wo kann man das CNA Tool runterladen und ist das SNMP basierend, so das man es ggf. auch für andere Hersteller verwenden kann ?
Ich denke, auf folgender Seite werden hoffentlich alle deiner Fragen beantwortet.
Leider ist das Tool ausschließlich für Cisco Geräte vorgesehen
Leider ist das Tool ausschließlich für Cisco Geräte vorgesehen
Und sogar ne Mac Version ! Lads grad mal runter....
Mal sehen wenn es Standard MIBS verwendet gehts auch mit anderen Herstellern...mal testen
Ansonsten ist STG oben ja immer das Universalwerkzeug
Mal sehen wenn es Standard MIBS verwendet gehts auch mit anderen Herstellern...mal testen
Ansonsten ist STG oben ja immer das Universalwerkzeug
