Cisco LAG-LACP an Synology RS3614xs+ Bonding Bandbreite zu niedrig
Guten Tag zusammen,
ich habe hier ein recht starkes Synology Gerät (32TB, 8GB RAM, Intel Xeon E3-1230v2) in mein Netzwerk eingebunden.
Die Appliance hat 4*1GBit Port welche ich mittels dynamischen LACP/LAG an einen Cisco SG500X Switch angeschlossen habe.
Das Bonding ist fehlerfrei und funktioniert. Beim Backup von einem perfomanten Dell Storage über eine 10Gbe LWL Strecke komme ich aber nicht wirklich über die 1GBit hinaus.
Vom Storage System erwarte ich aber mehrere 100MB/s.
Der Trunk zwischen den beiden Switchen läuft auf 10G. Die ESX Hosts haben ebenfalls jeweils 2 10Gbe Links (Kupfer). Die Storage Anbindung ist ebenfalls ausreichend.
Jemand eine Idee ? Danke !
ich habe hier ein recht starkes Synology Gerät (32TB, 8GB RAM, Intel Xeon E3-1230v2) in mein Netzwerk eingebunden.
Die Appliance hat 4*1GBit Port welche ich mittels dynamischen LACP/LAG an einen Cisco SG500X Switch angeschlossen habe.
Das Bonding ist fehlerfrei und funktioniert. Beim Backup von einem perfomanten Dell Storage über eine 10Gbe LWL Strecke komme ich aber nicht wirklich über die 1GBit hinaus.
Vom Storage System erwarte ich aber mehrere 100MB/s.
Der Trunk zwischen den beiden Switchen läuft auf 10G. Die ESX Hosts haben ebenfalls jeweils 2 10Gbe Links (Kupfer). Die Storage Anbindung ist ebenfalls ausreichend.
Jemand eine Idee ? Danke !
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 321837
Url: https://administrator.de/forum/cisco-lag-lacp-an-synology-rs3614xs-bonding-bandbreite-zu-niedrig-321837.html
Ausgedruckt am: 25.12.2024 um 14:12 Uhr
20 Kommentare
Neuester Kommentar
Zitat von @Ex0r2k16:
Das Bonding ist fehlerfrei und funktioniert. Beim Backup von einem perfomanten Dell Storage über eine 10Gbe LWL Strecke komme ich aber nicht wirklich über die 1GBit hinaus.
Vom Storage System erwarte ich aber mehrere 100MB/s.
Das Bonding ist fehlerfrei und funktioniert. Beim Backup von einem perfomanten Dell Storage über eine 10Gbe LWL Strecke komme ich aber nicht wirklich über die 1GBit hinaus.
Vom Storage System erwarte ich aber mehrere 100MB/s.
Moin
Wie meinen?
1GBit sind aber schon mehrere 100MB/s!
Also mir fehlt jedenfalls die kreative Vorstellungskraft wie du irgendetwas, irgendwie zusammengebastelt hast.
Wie und womit stellst du das denn fest? ... gibt es irgendwelche brauchbare Messungen!?
VG
Ashnod
Hallo zusammen,
10 GBit/s Karte für Synology RS3614xs+
Links (Ports) wie folgt benutzt bzw. genutzt;
- Alles läuft über eine Leitung (Port/Kabel) und erst wenn die voll ist wird die nächste
angefangen zu benutzen bzw. mit Daten gefüllt
- Es wird nur ein Link (Port) benutzt und wenn der ausfällt springt der nächste Link (Port)
ein und wird benutzt
Bitte schließe aus dass bei Deiner Konfiguration so gearbeitet wird oder viel mehr dass
dort alle Ports gleichzeitig benutzt und "gefüllt" werden, wie zum Beispiel mittels Round
Robin Methode.
Lass Dir das mit der 10 GbE Karte für 139 Euro einmal durch den Kopf gehen,
damit bekommt man meist im realen Einsatz so um die 2 GBit/s bis 4 GBit/s
an Durchsatz! Ich meine damit realen Durchsatz, nicht theoretischen!!!!
sind würde ich das NAS auch so anbinden und habe dann einfach alle Flaschenhälse
eliminiert!
Halte ich persönlich für die beste Idee!
- 4 x 1 GBit/s als statisches LAG mit "Round Robin" Algorithmus und alles active/active
Die Verbindung am NAS wird sich ja nicht alle drei Tage ändern wenn es einmal läuft,
oder?
- NAS und Storage an eine und den selben Switch packen
Muss nicht aber es verkürzt die Strecke und die Hopps//
Gruß
Dobby
ich habe hier ein recht starkes Synology Gerät (32TB, 8GB RAM, Intel Xeon E3-1230v2)
in mein Netzwerk eingebunden.
Ok, aber ist es denn dort auch möglich eine 10 GBit/s Karte einzubauen?in mein Netzwerk eingebunden.
10 GBit/s Karte für Synology RS3614xs+
Die Appliance hat 4*1GBit Port welche ich mittels dynamischen LACP/LAG an
einen Cisco SG500X Switch angeschlossen habe.
Soweit ich informiert bin werden bei einigen Konfigurationen die komplett verfügbareneinen Cisco SG500X Switch angeschlossen habe.
Links (Ports) wie folgt benutzt bzw. genutzt;
- Alles läuft über eine Leitung (Port/Kabel) und erst wenn die voll ist wird die nächste
angefangen zu benutzen bzw. mit Daten gefüllt
- Es wird nur ein Link (Port) benutzt und wenn der ausfällt springt der nächste Link (Port)
ein und wird benutzt
Bitte schließe aus dass bei Deiner Konfiguration so gearbeitet wird oder viel mehr dass
dort alle Ports gleichzeitig benutzt und "gefüllt" werden, wie zum Beispiel mittels Round
Robin Methode.
Das Bonding ist fehlerfrei und funktioniert. Beim Backup von einem perfomanten
Dell Storage über eine 10Gbe LWL Strecke komme ich aber nicht wirklich über
die 1GBit hinaus.
Das ist schon einmal ein Ansatz zu dem was ich weiter oben beschrieben habe.Dell Storage über eine 10Gbe LWL Strecke komme ich aber nicht wirklich über
die 1GBit hinaus.
Lass Dir das mit der 10 GbE Karte für 139 Euro einmal durch den Kopf gehen,
damit bekommt man meist im realen Einsatz so um die 2 GBit/s bis 4 GBit/s
an Durchsatz! Ich meine damit realen Durchsatz, nicht theoretischen!!!!
Vom Storage System erwarte ich aber mehrere 100MB/s.
- Theoretisches Maximum bei 1 GBit/s sind aber nun einmal 125 MB/s!Der Trunk zwischen den beiden Switchen läuft auf 10G. Die ESX Hosts
haben ebenfalls jeweils 2 10Gbe Links (Kupfer). Die Storage Anbindung
ist ebenfalls ausreichend.
Also wenn die Switche und das Storage mittels 10 GBit/s angebunden wordenhaben ebenfalls jeweils 2 10Gbe Links (Kupfer). Die Storage Anbindung
ist ebenfalls ausreichend.
sind würde ich das NAS auch so anbinden und habe dann einfach alle Flaschenhälse
eliminiert!
Jemand eine Idee ? Danke !
- 10 GBit/s Karte für das NASHalte ich persönlich für die beste Idee!
- 4 x 1 GBit/s als statisches LAG mit "Round Robin" Algorithmus und alles active/active
Die Verbindung am NAS wird sich ja nicht alle drei Tage ändern wenn es einmal läuft,
oder?
- NAS und Storage an eine und den selben Switch packen
Muss nicht aber es verkürzt die Strecke und die Hopps//
Gruß
Dobby
Aktuell ist 802.3ad samt LACP aktiv. Soweit ich gelesen habe, ist das schon
mit der beste verfügbare Modus.
Acive/active oder active/passive Modus?mit der beste verfügbare Modus.
Sicher bin ich mir aber nicht.
Ich mir auch nicht. Aber wenn man die beiden Switche zu einen Stackzusammen schließt und dann nur eine LAG Konfiguration durchgehend
benutzt sollte es sicher sein dass es keine Probleme gibt.
Ich kann gerade leider keine Lasttests fahren, da auf dem System geschult wird.
Dann ist das so schon in Ordnung denn ein LAG ist genau dafür, wenn viele Benutzerauf ein Gerät zugreifen und die Bandbreite geht in die Knie.
Gruß
Dobby
Es ist hier schon mehrfach gesagt worden aber die Crux liegt an der 802.3ad / LACP Sessionverteilung wie es der Kollege @SlainteMhath schon richtig bemerkt hat.
.ad LAGs nutzen per Standarddefinition ein Hashing um die Links zu verteilen. Das Hashing basiert immer auf den letzten 4 Bits der Mac- oder IP Adresse per XOR je nachdem ob Hashing auf L2 oder L3 Basis konfiguriert ist im Server/NAS NIC Treiber oder Switch.
Bessere Switches oder Treiber lassen zusätzlich auch noch den TCP oder UDP Port ins Hashing einfliessen um die Verteilung auf die physischen Links granularer zu machen.
Je mehr Macs und IP desto granularer die Verteilung, je weniger desto schlechter. Mathematische Logik.
Ein Optimum wird aber niemals erreicht. Ein bekannter Nachteil bei .ad LAGs
Der Hashwert zeigt dann immer fest auf den physischen Link über den diese Session dann läuft.
Der Grund dieses Hashing Verfahrens ist das der .ad Algorithmus keinerlei Packet Recovery Mechanismen besitzt. Dieses Manko verbietet dann ein per Packet Balancing weil so ggf. Laufzeiten auf den Links nicht ausgeglichen werden können und es zu einem Packet- oder Sessionverlust kommt.
Wenn dann wie bei dir jeweils nur ein einzelnes Gerät, das ja immer eine identische und feste Mac oder IP hat in Source und Destination und einen festen Application Port kommunizieren ist der Hash der dann auf den physischen Link zeigt ja immer derselbe.
Folglich wird also diese Kommunikation immer auf einem und demselben Link abgewickelt.
Das ist systembedingt durch den unterliegenden 802.3ad Standard.
Manche Treiber oder Switches supporten ein festes Round Robin Verfahren. Das aber nur bei statischen LAGs ohne LACP möglich.
Wenn deine Geräte das können kannst du das einschalten. Wenigstens einseitig würde man dann ein Round Robin hinbekommen. Bei einem Server zu Server backup bringt das aber auch wenig, denn dann hast du ja auch keine multiplen Sessions.
Eine Ausnahme sind hier moderne DCB Ethernet Switches (Data Center Bridging Standard) die mit TRILL oder SPB arbeiten. (z.B. Brocade VDX)
Diese machen dann ein Per Packet Balancing da sie Recovery Mechanisemn haben die dem .ad Standard fehlen.
Damit ist ein sauberes und vollkommen homogenes Balancing auf Packet Basis möglich.
Du hast dich ja aber mit der Kaufentscheidung dort Billigswitches einzusetzen bewusst gegen solche Optionen und Features entschieden und auf einfachste Billigtechnik gesetzt.
Folglich muss man dann auch logischerweise mit den Dingen leben die man hat. You get what you pay for !
Retten kann dich bei der HW nur eine fat pipe sprich also die 10G Karte.
Kost ja mittlerweile auch nix mehr.
.ad LAGs nutzen per Standarddefinition ein Hashing um die Links zu verteilen. Das Hashing basiert immer auf den letzten 4 Bits der Mac- oder IP Adresse per XOR je nachdem ob Hashing auf L2 oder L3 Basis konfiguriert ist im Server/NAS NIC Treiber oder Switch.
Bessere Switches oder Treiber lassen zusätzlich auch noch den TCP oder UDP Port ins Hashing einfliessen um die Verteilung auf die physischen Links granularer zu machen.
Je mehr Macs und IP desto granularer die Verteilung, je weniger desto schlechter. Mathematische Logik.
Ein Optimum wird aber niemals erreicht. Ein bekannter Nachteil bei .ad LAGs
Der Hashwert zeigt dann immer fest auf den physischen Link über den diese Session dann läuft.
Der Grund dieses Hashing Verfahrens ist das der .ad Algorithmus keinerlei Packet Recovery Mechanismen besitzt. Dieses Manko verbietet dann ein per Packet Balancing weil so ggf. Laufzeiten auf den Links nicht ausgeglichen werden können und es zu einem Packet- oder Sessionverlust kommt.
Wenn dann wie bei dir jeweils nur ein einzelnes Gerät, das ja immer eine identische und feste Mac oder IP hat in Source und Destination und einen festen Application Port kommunizieren ist der Hash der dann auf den physischen Link zeigt ja immer derselbe.
Folglich wird also diese Kommunikation immer auf einem und demselben Link abgewickelt.
Das ist systembedingt durch den unterliegenden 802.3ad Standard.
Manche Treiber oder Switches supporten ein festes Round Robin Verfahren. Das aber nur bei statischen LAGs ohne LACP möglich.
Wenn deine Geräte das können kannst du das einschalten. Wenigstens einseitig würde man dann ein Round Robin hinbekommen. Bei einem Server zu Server backup bringt das aber auch wenig, denn dann hast du ja auch keine multiplen Sessions.
Eine Ausnahme sind hier moderne DCB Ethernet Switches (Data Center Bridging Standard) die mit TRILL oder SPB arbeiten. (z.B. Brocade VDX)
Diese machen dann ein Per Packet Balancing da sie Recovery Mechanisemn haben die dem .ad Standard fehlen.
Damit ist ein sauberes und vollkommen homogenes Balancing auf Packet Basis möglich.
Du hast dich ja aber mit der Kaufentscheidung dort Billigswitches einzusetzen bewusst gegen solche Optionen und Features entschieden und auf einfachste Billigtechnik gesetzt.
Folglich muss man dann auch logischerweise mit den Dingen leben die man hat. You get what you pay for !
Retten kann dich bei der HW nur eine fat pipe sprich also die 10G Karte.
Kost ja mittlerweile auch nix mehr.
Nunja 1k€ für einen "normalen" 52Port Access Switch und 1,5 (?) für die 10G Variante würde ich nicht zwingend als "Billig-" Switch bezeichnen.
Nur mal so nebenbei: Ein entsprechender 48 mal 10G Port Switch von Cisco, Juniper oder Brocade mit den beschriebenen Fähigkeiten kostet so um die 10k.Nur damit du dich mal in deinem Preishorizont zurechtfindest was "billig" ist und was nicht.
Vermutlich sind dir aber solche Sphären des Networking schlicht unbekannt ?!
Es ist halt immer eine Frage der Perspektive was einem das RZ und die Datenverarbeitung wert sind und welchen Stellenwert das im Unternhemen hat.
falls ich gefragt werde wofür diese Karten gut sind, kann ich das eben technisch rechtfertigen.
Mit der obigen Erklärung dann umso besser ! Danke für die Blumen Ich lerne ja auch aktuell dazu und es macht mir super Spaß
Das ist die Hauptsache !!!Wir haben auf 10GBit gesetzt und wir schaufeln aktuell nach ein paar Anpassungen
ca 390MB/sec Netto rüber.
Also volle 10 GBit/s gibt es eh nicht, aber bei einer 10 GBit/s Verbindung sollte ca.ca 390MB/sec Netto rüber.
~2 GBit/s bis 4 GBit/s an realem Durchsatz drinnen sein. und mit 3120 MBit/s
liegst Du genau dazwischen, passt doch!
Nunja 1k€ für einen "normalen" 52Port Access Switch und 1,5 (?) für die 10G
Variante würde ich nicht zwingend als "Billig-" Switch bezeichnen. Zumal wir
jetzt auch keine Riesen Firma sind. Im Vergleich zu vorher ist das schon
absolute solide Hardware und auch ausreichend.
Das kommt ja auch immer auf den Einzelfall an, manchen reicht es ebenVariante würde ich nicht zwingend als "Billig-" Switch bezeichnen. Zumal wir
jetzt auch keine Riesen Firma sind. Im Vergleich zu vorher ist das schon
absolute solide Hardware und auch ausreichend.
und manchen nicht, da kann man nichts groß zu sagen aus unserer Sicht
wir sind nicht vor Ort und wir kennen die Anforderungen ja auch gar nicht.
Gruß
Dobby
und mit 3120 MBit/s liegst Du genau dazwischen, passt doch !
Würde stimmen und auch noch zeigen das das LAG Balancing dann aber doch irgendwie funktionieren würde, denn diesen Durchsatz würde man bei einem 1G Einzellink niemals hinbekommen !!!Der Cisco und das NAS können sicher SNMP. Sieh dir den Durchsatz über Tag doch mal grafisch an mit einem kleinen SNMP Tool:
http://leonidvm.chat.ru
Das Tool startest du 4mal für jeden Link einzeln und kannst dann wunderbar die einzelne Auslastung sehen der 4 Links sowohl in Sende- wie Empfangsrichtung.
Zitat von @Ex0r2k16:
Cool! Kannst du mir vielleicht dein Setup verraten?
Grundsätzlich habe ich mit LAG im Cisco Bereich eher gute Erfahrungen gemacht. Das könnte bei mir vielleicht auch ein Protokoll Problem sein, da CIF als Backup Ziel genutzt wird. Welches Protkoll benutzt du für die >300MB/s ? iSCSI? NFS?
Meine Backup Software ist da leider nicht allzu flexibel. Ich hoffe für nächstes Jahr wird mir Veeam genehmigt :o)
Cool! Kannst du mir vielleicht dein Setup verraten?
Grundsätzlich habe ich mit LAG im Cisco Bereich eher gute Erfahrungen gemacht. Das könnte bei mir vielleicht auch ein Protokoll Problem sein, da CIF als Backup Ziel genutzt wird. Welches Protkoll benutzt du für die >300MB/s ? iSCSI? NFS?
Meine Backup Software ist da leider nicht allzu flexibel. Ich hoffe für nächstes Jahr wird mir Veeam genehmigt :o)
Hi ,
also das NAS ist eine Synology RackStation RS3617xs+ mit Hexacore und 8GB Ram.
Platten sind aktuell 6x 8TB Seagate ST8000VX0002 im Raid 10
Redundant angebunden per 10G Kupfer an 2 Netgear Switche.
Daten werden dann mittels Backupserver(Veeam ) vom Hyper-V Cluster geholt und dann mit CIFS auf das NAS geschrieben.
Meine Backup Software kann leider auch nur eine Netzwerkkarte benutzen.
Wie ist das gemeint ???Eine Applikation nutzt doch immer den OS internen TCP Stack. Wenn du unter Winblows und auch Linux ein Bonding, sprich LAG machst hast du ja ein virtuelles Bonding Interface.
Der Treiber darunter macht dann die physische Verteilung auf die einzelnen Links.
In so fern hast du IMMER nur ein Interface. Logisch das man dann natürlich das Bonding Interface wählt in der App !