20
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 !
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: 321837
Url: https://administrator.de/contentid/321837
Ausgedruckt am: 24.11.2024 um 15:11 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
Hi,
mit mehreren 100MB/s meine ich deutlich über 200 MB/s wenn nicht sogar 300 bis 500, da der Quell Storage auch SSDs verbaut hat. Ich als Monitoring Software Cacti im Einsatz und sehe die Geschwindigkeit aber auch an der Backup VM auf einem der ESX Hosts sowieso am NAS selber. Als Backup Software ist HPE vmexplorer im Einsatz.
Ich sichere also von einem perfomanten ESX Host über 10Gbe auf die Synology. Eigentlich nichts kompliziertes
mit mehreren 100MB/s meine ich deutlich über 200 MB/s wenn nicht sogar 300 bis 500, da der Quell Storage auch SSDs verbaut hat. Ich als Monitoring Software Cacti im Einsatz und sehe die Geschwindigkeit aber auch an der Backup VM auf einem der ESX Hosts sowieso am NAS selber. Als Backup Software ist HPE vmexplorer im Einsatz.
Ich sichere also von einem perfomanten ESX Host über 10Gbe auf die Synology. Eigentlich nichts kompliziertes
Moin,
LACP kann nicht einen Stream/eine TCP-Session über mehrere Interfaces verteilen. Entweder du sagst deiner Backup Software, dass sie mehre parallele Streams aufmacht, oder du spendierst der NAS eine 10G NIC
lg,
Slainte
LACP kann nicht einen Stream/eine TCP-Session über mehrere Interfaces verteilen. Entweder du sagst deiner Backup Software, dass sie mehre parallele Streams aufmacht, oder du spendierst der NAS eine 10G NIC
lg,
Slainte
Ah okay. Sprich wenn ich mehrere Backups parallel starte krieg ich mehr Bandbreite?
Kann sein. Keine Ahnung was du für Software einsetzt und die wie funktioniert bzw. sich verhällt. Ggfs. mal einen Blick in die Doku werfen oder mit dem Support reden.
ouh ne HP Support...da teste ich lieber selber :D Aber danke für die Info. Ich dachte mir schon sowas, war mir aber nicht sicher.
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
Danke für deine Antwort. Die 10G Karte ist natürlich eine gute und günstige Option.
Für dieses Jahr habe ich aber kein Budget mehr. Und ich will mich selber auch mit der Materie auseinander setzen.
Dass Gbit so an die 125MB/s kommt ist mir bewusst. Da steht ja auch "mehrere" hundert MBs ;)
Mein NAS kann mehrere Modi:
Aktuell ist 802.3ad samt LACP aktiv. Soweit ich gelesen habe, ist das schon mit der beste verfügbare Modus. Sicher bin ich mir aber nicht. Ich kann gerade leider keine Lasttests fahren, da auf dem System geschult wird.
Für dieses Jahr habe ich aber kein Budget mehr. Und ich will mich selber auch mit der Materie auseinander setzen.
Dass Gbit so an die 125MB/s kommt ist mir bewusst. Da steht ja auch "mehrere" hundert MBs ;)
Mein NAS kann mehrere Modi:
Mode descriptions:
-Adaptive Load Balancing: This mode optimizes the network traffic received and sent by your Synology NAS whether or not the switch supports Link Aggregation. To avoid unexpected errors, please do not enable Link Aggregation on the switch even when it is supported.
IEEE 802.3ad Dynamic Link Aggregation: This mode optimizes the network traffic received and sent by your Synology NAS, and requires IEEE
-802.3ad (Dynamic) Link Aggregation (LACP, 802.1AX) to be enabled on the switch(es). If multiple switches are used, these switches have to be stackable and properly configured.
-Balance XOR: This mode balances the network traffic received and sent by your Synology NAS, and requires Static Link Aggregation to be enabled on the switch(es). If multiple switches are used, these switches have to be stackable and properly configured. If Link Aggregation is not supported by the switch, the traffic sent by your Synology NAS can still be balanced. With this mode, the lost links can be detected but not the cause (e.g., when the Ethernet cables are unplugged or the switch is misconfigured).
-Active/Standby: This mode provides your Synology NAS with network fault tolerance. That is, when the active network interface goes down, one of the other LAN ports will take over to maintain the network connection. You can choose this mode without configuring the switch or with a switch that supports IEEE 802.3ad Link Aggregation.Aktuell ist 802.3ad samt LACP aktiv. Soweit ich gelesen habe, ist das schon mit der beste verfügbare Modus. Sicher bin ich mir aber nicht. Ich kann gerade leider keine Lasttests fahren, da auf dem System geschult wird.
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
Zitat von @108012:
Acive/active oder active/passive Modus?
Acive/active oder active/passive Modus?
Das kann ich nicht auswählen. Aktiv/Standby ist ein eigener Modus im NAS. Das heißt bedeutet dann aber nur Failover für jeden Port.
Ich mir auch nicht. Aber wenn man die beiden Switche zu einen Stack
zusammen schließt und dann nur eine LAG Konfiguration durchgehend
benutzt sollte es sicher sein dass es keine Probleme gibt.
zusammen schließt und dann nur eine LAG Konfiguration durchgehend
benutzt sollte es sicher sein dass es keine Probleme gibt.
Nein. Ich möchte die beiden Geräte nicht stacken. Es sind auch keine baugleichen Geräte.
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.
Ähm erneut nein ;) Grundsätzlich hast du zwar Recht aber in diesem Fall brauche ich die Bandbreite. Und zwar Nachts. Ich habe LAGs für normale Trunk Strecken ja auch im Einsatz und da ist dieses "Load Balancing" Verhalten auch ok. Nur hängen da auch keine 10G Clients drann.
Hab dasselbe gerade selber durch .
Trotz Bonding etc keine wirkliche Performance gehabt . Hat wie schon oben beschrieben mit den Streams zu tun .
Wir haben auf 10GBit gesetzt und wir schaufeln aktuell nach ein paar Anpassungen ca 390MB/sec Netto rüber.
Trotz Bonding etc keine wirkliche Performance gehabt . Hat wie schon oben beschrieben mit den Streams zu tun .
Wir haben auf 10GBit gesetzt und wir schaufeln aktuell nach ein paar Anpassungen ca 390MB/sec Netto rüber.
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)
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)
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. Zumal wir jetzt auch keine Riesen Firma sind Im Vergleich zu vorher ist das schon absolute solide Hardware und auch ausreichend.
Ich mecker ja auch nicht weil es nicht geht sondern weil ich Administrator bin und das Thema verstehen will Daher vielen Dank für deinen Beitrag. Top erklärt!
Es wird ja auch auf die Karte hinaus laufen. Nur haben wir dieses Gerät 3 mal im Einsatz und falls ich gefragt werde wofür diese Karten gut sind, kann ich das eben technisch rechtfertigen.
Es macht für ein kleines mittelständisches Unternehmen halt nicht immer unbedingt Sinn die fettesten Catalysten und Nexusse zu verbauen. Der Mehrwert und Nutzen ist einfach nicht da. Ich meine ich habe in kurzer Zeit den Durchsatz an 50% der Clients verzehnfacht (100mbit => 1G) und die Anbindung aller Server komplett auf links (links...verstehste? Achtung Wortwitz höhö) gedreht, selbst das merkt der 0815 User kaum bis gar nicht.
Ich lerne ja auch aktuell dazu und es macht mir super Spaß
Im Vergleich zu vorher ist das schon absolute solide Hardware und auch ausreichend.Ich mecker ja auch nicht weil es nicht geht sondern weil ich Administrator bin und das Thema verstehen will
Daher vielen Dank für deinen Beitrag. Top erklärt!Es wird ja auch auf die Karte hinaus laufen. Nur haben wir dieses Gerät 3 mal im Einsatz und falls ich gefragt werde wofür diese Karten gut sind, kann ich das eben technisch rechtfertigen.
Es macht für ein kleines mittelständisches Unternehmen halt nicht immer unbedingt Sinn die fettesten Catalysten und Nexusse zu verbauen. Der Mehrwert und Nutzen ist einfach nicht da. Ich meine ich habe in kurzer Zeit den Durchsatz an 50% der Clients verzehnfacht (100mbit => 1G) und die Anbindung aller Server komplett auf links (links...verstehste? Achtung Wortwitz höhö) gedreht, selbst das merkt der 0815 User kaum bis gar nicht.
Ich lerne ja auch aktuell dazu und es macht mir super Spaß
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.
Das ist vom Setup her ja auch ziemlich ähnlich. Ich konnte eben nochmal testen. Also das "propertiere" Synology Bonding ist von der Performance her ein Stück schlechter als die Cisco LAG. Mit zwei Clients und LAG/LACP zieh ich weit über 200MB/s auf 2 Streams. Die 10G Strecke ist also okay Meine Backup Software kann leider auch nur eine Netzwerkkarte benutzen. Nunja wieder was gelernt. Danke an alle!
Meine Backup Software kann leider auch nur eine Netzwerkkarte benutzen. Nunja wieder was gelernt. Danke an alle!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 !
