johannes219
Mar 02, 2015, updated at May 06, 2015 (UTC)
view3956
view37
0
Goto Top

XenServer, NetApp, Cisco - Storage Design, maximale Nutzung der Netzwerkbandbreite

GermansolvedQuestionLAN, WAN, WirelessNetworks
Hallo,

das hier ist mein erster Post, ich hoffe es gibt hier kein falschen oder richtigen Bereich, wenn doch dann bitte ich um Nachsicht face-wink
Ich bin momentan bei der Implementierung des folgenden Designs:

fdd4add089e1c54e214409ec43415098

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:

back-to-topCisco Switch (Stacked) Konfiguration:
back-to-topXenServer 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
!

back-to-topStorage 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
!

back-to-topNetApp 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

back-to-topXenServer Interface Konfiguration:
64d471e7691cf3def56f138ff703998e


back-to-topNetzwerk 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
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 264977

Url: https://administrator.de/contentid/264977

Printed on: April 19, 2024 at 22:04 o'clock

37 Comments
Latest comment
Goto Top
Member: michi1983
michi1983 Mar 02, 2015 at 10:42:42 (UTC)
Goto Top
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
Member: aqui
aqui Mar 02, 2015 updated at 13:33:46 (UTC)
Goto Top
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 face-wink !
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- ...
Member: Johannes219
Johannes219 Mar 02, 2015 at 14:11:29 (UTC)
Goto Top
Zitat von @aqui:
Klein mb = mbit Groß Mb = Mbyte !!

Danke, ich werd's mir merken face-wink

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.
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
wird mir verweigert. D.h. es sollte wohl meine Aussage bestätigen.

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.
Member: michi1983
michi1983 Mar 02, 2015 at 14:48:40 (UTC)
Goto Top
Laut Datenblatt ist der von dir erwähnte Switch ein Layer 3 Switch.

Gruß
Member: aqui
aqui Mar 02, 2015 updated at 20:53:04 (UTC)
Goto Top
Sry - das habe ich schlichtweg vergessen zu posten
Hinterher kann das jeder sagen face-wink
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 !
Member: Johannes219
Johannes219 Mar 03, 2015 updated at 14:25:25 (UTC)
Goto Top
@aqui:
Der Befehl für die Layer 3 Konfiguration der Port-channels mit
Uuuhhhh...jetzt kommt aber der freie Fall nach unten beim Syntax raten !
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 ;-p

> und ich vermute die Option ist nur für Cisco Router vorgesehen.
WAS bitte für eine "Option" meinst du ???
Die Option Switchport.

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:
e93039b199558156f87cf213350a54c2

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?
Member: aqui
aqui Mar 03, 2015 updated at 21:49:00 (UTC)
Goto Top
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 face-wink
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 face-sad
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... face-wink

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 !)
Member: Johannes219
Johannes219 Mar 04, 2015 updated at 12:10:35 (UTC)
Goto Top
Ich habe die Bedingungen doch nochmal vereinfacht - auf beiden XenServern läuft das Tool iperf. (Ergebnisse s. unten.)

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:
back-to-topMAC-Basierend:
back-to-topTCP:
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

back-to-topUDP:
[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

back-to-topUDP 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..
Member: aqui
aqui Mar 04, 2015 at 15:35:56 (UTC)
Goto Top
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 !
Member: Johannes219
Johannes219 Mar 05, 2015 at 14:27:11 (UTC)
Goto Top
Ich habe mal noch weitere Recherchen betrieben - und bin auf folgende interessante Citrix Dokumentation zum Thema LACP gestoßen:


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.

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..
Member: aqui
aqui Mar 05, 2015 at 14:43:25 (UTC)
Goto Top
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.
Member: Johannes219
Johannes219 Mar 05, 2015 updated at 15:38:42 (UTC)
Goto Top
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 !!

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.
Member: aqui
aqui Mar 05, 2015 updated at 16:11:01 (UTC)
Goto Top
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 face-wink
Member: Johannes219
Johannes219 Mar 06, 2015 at 12:53:32 (UTC)
Goto Top
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 face-wink

Ich werde mal weiter recherieren - ggf. iSCSI austesten.

Aber bis hierhin - erstmal danke vielmals um die tatkräftige Unterstützung, besonders von dir aqui face-wink 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.
Mitglied: 119944
119944 Mar 06, 2015 at 15:00:25 (UTC)
Goto Top
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
Member: aqui
aqui Mar 06, 2015 updated at 17:50:31 (UTC)
Goto Top
Jein face-wink
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.
heart1
Member: Johannes219
Johannes219 Mar 18, 2015 at 06:30:39 (UTC)
Goto Top
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 face-wink

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?
Member: aqui
aqui Mar 18, 2015 at 12:50:39 (UTC)
Goto Top
Aqui, du kannst mich auch hier gerne korrigieren, wenn ich da wieder einen falschen Ansatz verfolge
Ne ist schon alles gut face-wink
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 ?)
Member: Johannes219
Johannes219 Mar 20, 2015 at 12:35:24 (UTC)
Goto Top
Sry - genau, das virtuelle Laufwerk meinte ich mit der VHD face-wink

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.
Member: aqui
aqui Mar 20, 2015 at 13:23:35 (UTC)
Goto Top
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... face-smile
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.
Member: Johannes219
Johannes219 Mar 30, 2015 at 07:15:21 (UTC)
Goto Top
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.

Meine Aussage bezog sich hier in erster Linie auf iSCSI (speziell das Mounten eines iSCSI Volumes, nicht um LAG's face-wink

> 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.

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.
Member: aqui
aqui Mar 30, 2015 at 07:33:02 (UTC)
Goto Top
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.
Member: Johannes219
Johannes219 Mar 31, 2015 at 13:25:43 (UTC)
Goto Top
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..
Member: aqui
aqui Mar 31, 2015 at 13:42:39 (UTC)
Goto Top
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.
Member: Johannes219
Johannes219 Apr 01, 2015 at 08:12:24 (UTC)
Goto Top
Aqui, ich glaube wir reden im Moment komplett aneinander vorbei face-wink

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:

4a31f1750409f8ac6aeb437cdd7054f6

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
!
Member: aqui
aqui Apr 01, 2015 at 17:52:13 (UTC)
Goto Top
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 face-sad
Ein Bild sagt mehr als 1000 Worte face-wink

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.
Member: Johannes219
Johannes219 Apr 10, 2015 at 11:54:49 (UTC)
Goto Top
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? ^^
Member: aqui
aqui Apr 10, 2015 updated at 15:54:48 (UTC)
Goto Top
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.
Mitglied: 108012
108012 Apr 10, 2015 at 17:42:31 (UTC)
Goto Top
Hallo zusammen,

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 klar
LACP 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 an
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 statischem
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.

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 LAGs
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?

49262a5828daf0871c255a14271d0ced

Gruß
Dobby
Member: Johannes219
Johannes219 Apr 13, 2015 at 14:27:05 (UTC)
Goto Top
@108012:

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 klar
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.

Binde den Server und die NetApp einfach via LAG an beiden Switche an
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:

db6c77cb463c9b1330fa4fda536b7a0c
Switch1 & Switch2 wären in meinem Fall die 4 unterschiedlichen VLANs, da ich ja vier NICs statt zwei zur Verfügung habe.

Mein Ziel ist die Ausnutzung aller Interface des Bonds.
Hier schon wieder , ein Bond ist die Bezeichnung eines LAGs
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 face-confused

@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.

Aber wenn dem so ist, wozu dann der Aufwand iSCSI über verschiedene Subnetze zu konfigurieren, wenn ich nur eine Leitung benutzten kann?
Member: aqui
aqui Apr 14, 2015 at 07:03:53 (UTC)
Goto Top
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.
Member: Johannes219
Johannes219 Apr 21, 2015 updated at 09:27:06 (UTC)
Goto Top
Ich poste mal noch das aktuelle Bild einer eingehangenen LUN im XenCenter:
166eca437e3b701ca5b80026f35029d3

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?
Member: aqui
Solution aqui Apr 22, 2015, updated at May 06, 2015 at 06:09:01 (UTC)
Goto Top
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.
Member: Johannes219
Johannes219 May 06, 2015 at 06:08:26 (UTC)
Goto Top
Guten morgen,

Aqui, Du hast mich auf die Lösung gebracht face-wink

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:
57719db6b4f2acc92aca45b6de5cd89d

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 face-smile


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 face-wink
Member: aqui
aqui May 06, 2015 at 06:20:32 (UTC)
Goto Top
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 ?
Member: Johannes219
Johannes219 May 06, 2015 at 07:13:39 (UTC)
Goto Top
Ich denke, auf folgender Seite werden hoffentlich alle deiner Fragen beantwortet.

Leider ist das Tool ausschließlich für Cisco Geräte vorgesehen face-confused
Member: aqui
aqui May 06, 2015 at 07:23:20 (UTC)
Goto Top
Und sogar ne Mac Version ! Lads grad mal runter....
Mal sehen wenn es Standard MIBS verwendet gehts auch mit anderen Herstellern...mal testen face-wink
Ansonsten ist STG oben ja immer das Universalwerkzeug face-wink
GermansolvedQuestionLAN, WAN, WirelessNetworks
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 3 CommentsAlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment