kraemer
Goto Top

Kann man mittels Trunking die Netzwerkgeschwindigkeit einzelner Rechner erhöhen?

Moin,

ich habe eine Frage zu einem Problem, welches ich leider nicht mal eben so durch testen beantworten kann. Vielleicht kann mir hier jemand die Frage so beantworten.

Warum kann ich nicht einfach selbst testen
Vorweg eben kurz zu Erklärung, das ich mich nicht einfach vor einem Test drücke. Die Netzwerkgerätschaften sind fest in einem Kassentresen verbaut. Der Tischler, der das Ding entworfen hat, hat sich leider keine Gedanken darüber gemacht, das man an die Gerätschaften herankommen muss. Ich habe mir von meinem Vorgänger sagen lassen - dieser musste schon einmal einen Switch tauschen - das das demontieren und montieren des Tresens zum einen nur durch den Tischler durchgeführt werden kann und das diese Arbeit einige Stunden in Anspruch nehmen. Warum die das damals nicht gleich umgebaut haben ist mir schleierhaft - ist aber so. Auf jeden Fall ist es mehr als ungünstig den Tresen über Stunden aufzureißen - sieht halt einfach scheiße aus. Kann und wird aber gemacht werden, wenn Aussicht auf Erfolg herrscht.

Die Ausgangssituation
Ich habe hier also mehre Desktoprechner als Kassenterminals:
- Windows 7 - aktuell
- Rechner BTO von einer Schrauberbude - verschiedene Onboard-Netzwerkkarten (GBit)

Die Netzwerkkarten gehen auf Cat5e Dosen - diese sind auf einem Patchfeld aufgelegt.
Das Netzwerk wird durch einen Netgear GS724T geswitcht.

Die WaWi ist eine 32bit Branchenlösung - als Backend wird eine Nexus-Datenbank genutzt.

Die Netzwerkverbindungen sind absolut stabil - keine Probleme.

Das Problem
Ich weiß nicht, ob es an der Länge der Netzwerkkabel (Patchfeld->Patchdose) liegt, oder aber an schlecht aufgelegten Leitungen - auf jeden Fall reagieren die Kassenclients im Netzwerk sehr träge. Das suchen in der Datenbank dauert schlicht zu lange. Andere Rechner (Lager etc) haben das Problem nicht. Dort sind die Kabellängen auch wesentlich kürzer.

Meine Überlegung
Da der Netgear Trunking unterstützt bin ich zu folgender Überlegung gekommen. Ich besorge mir einen kleinen managbaren Desktopswitch, nutzte zwei der ankommenden Netzwerkleitungen und trunke das ganze. Die Clients werden dann auf dem Desktopswitch aufgelegt. Da die Kassen seltenst zur selben Zeit voll genutzt werden, erhoffe ich mir dadurch einen Performanceschub.

Die Frage
Lässt sich auf diese Art und Weise mein Problem überhaupt beheben oder ist mein Verständnis vom Truinking an dieser Stelle völlig falsch.

Gruß Krämer

Content-Key: 306113

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

Ausgedruckt am: 28.03.2024 um 10:03 Uhr

Mitglied: michi1983
Lösung michi1983 03.06.2016 aktualisiert um 09:58:04 Uhr
Goto Top
Zitat von @Kraemer:

Moin,
Moin

Die Frage
Lässt sich auf diese Art und Weise mein Problem überhaupt beheben oder ist mein Verständnis vom Truinking an dieser Stelle völlig falsch.
Wenn es richtiges LACP ist, dann schon. Der Standard 802.3ad sollte unterstützt werden. Steht davon was im Handbuch?

Weil du von der Länge der Leitungen sprichst:
Von was für einer Länge reden wir hier?
Wenn es unter 100m sind (Pro Leitung), sollte das absolut kein Problem sein. Dann könnte es noch dran liegen wie die Leitungen aufgelegt wurden.
Das kann man aber recht schell mal mit einem iPerf Test feststellen was da drüber geht.

Gruß
Mitglied: aqui
Lösung aqui 03.06.2016 aktualisiert um 10:00:54 Uhr
Goto Top
Trunking oder Link Aggregation nach IEEE802.3ad mit LACP basiert auf einem Hashing Algorythmus. Entweder nach den letzten 4 Bits der IP Adressen oder der Mac Adressen per XOR.
Auf Basis des Hashes gibt es also eine mehr oder weniger gute Verteilung der einzelnen Mac oder IP Sessions auf die aggregierten Links.
Sprich das was du erhöhst ist immer einzig die Kapazität NICHT aber die physische Geschwindigkeit !
Ist ja auch logisch, denn das Clocking über den einzelnen Link sei es 10, 100 oder 1000Mbit/s und damit die physische Übertragungsgeschwindigkeit an sich bleibt ja immer gleich die ist Hardware bedingt ja nicht änderbar.
Du kannst schlicht und einfach nur mehr Endgeräte auf so einen aggregierten Link im Vergleich zu einem singulären geben ohne das es zu Performance Einbußen kommt.
Das ist das simple Geheimnis dahinter...
Mitglied: Kraemer
Kraemer 03.06.2016 um 10:32:02 Uhr
Goto Top
Hi aqui,

so ganz verstehe ich das noch trotz deiner sehr ausführlichen Ausführungen (danke dafür) noch nicht.

auf Basis des Hashes gibt es also eine mehr oder weniger gute Verteilung der einzelnen Mac oder IP Sessions auf die aggregierten Links.
das verstehe ich so, das auch die Daten, die von einem Client kommen, auf beide Leitungen verteilt werden

Du kannst schlicht und einfach nur mehr Endgeräte auf so einen aggregierten Link im Vergleich zu einem singulären geben ohne das es zu Performance Einbußen kommt.
Und diese Aussage scheint das eben genannte zu revidieren.

Ich hatte es bisher so verstanden, das wenn ich ankommend effektiv 1000Mbit habe, und die kommenden Leitungen nur 500 Mbit bringen, das ich mit Trunking dann aus 2 X 500 Mbit effektiv wieder soetwas wie 1000Mbit machen kann. Das scheint dann wohl eher nicht der Fall zu sein?
Mitglied: chiefteddy
chiefteddy 03.06.2016 aktualisiert um 11:20:42 Uhr
Goto Top
Hallo,

der Link zw. einem PC und einem Switch ist eine dedizierte Verbindung, dh. sie steht ausschließlich dem PC zu. Es gibt keine Kollisionen mehr (Ethernet mit CSMA/CD-Zugriff ist praktisch abgeschafft). Wenn Du also eine Gigabit-Verbindung zum Switch hast, steht die dem angeschlossenem PC ausschließlich zur Verfügung. Und das eine einfache Client-Server-DB-Abfrage einen GB-Link an seine Leistungsgrenze bringen soll, halte ich für unmöglich!

Viel interessanter ist die Anbindung des Applikationsservers, da hier ja alle Client-Kommunikation zusammen läuft. Um es mal simpel auszudrücken: wenn 10 PCs mit 1GB auf den Server arbeiten, braucht der einen 10 x 1GB = 10GB Anschluß um keinen Flaschenhals darzustellen.

Da Du nichts zur Struktur des Netzwerkes gesagt hast, sind weitergehende Empfehlungen nicht möglich.

Bevor Du also darüber nachdenkst, ob die Link-Bandbreite zw. PC und Switch "aufgebohrt" werden muß, solltest Du erst mal testen, welche Bandbreite tatsächlich verfügbar ist (simpler Netzwerk-Leistungstest), Werte die Statistik über fehlerhafte Pakete im Switch aus (Störungen auf bestmmten Links?).

Da die Anbindung der PCs im Lager und der PCs im Tresen ja sicher nicht über die gleichen Wege (Switche) erfolgt, ist so eine pauschale Aussage: "die einen sind schneller als die anderen" nicht sehr zielführend.

Poste doch mal eine Zeichnung der Netzwerkstruktur.

Jürgen
Mitglied: Kraemer
Kraemer 03.06.2016 um 11:42:29 Uhr
Goto Top
Moin,

Zitat von @chiefteddy:
Da die Anbindung der PCs im Lager und der PCs im Tresen ja sicher nicht über die gleichen Wege (Switche) erfolgt,
das habe ich nirgends geschrieben. Ganz im Gegenteil. Ich habe lediglich erwähnt, das die Kabellängen verschieden sind!

Poste doch mal eine Zeichnung der Netzwerkstruktur.
Und mit verlaub, ich denke nicht, das die Zeichnung einer wie im Eröffnungspost geschilderten Sternverkabelung, die auf einem Switch landet, irgend etwas bringt oder verdeutlicht.

Ich wollte lediglich wissen, ob ich die Geschwindigkeitseinbußen, die definitiv vorhanden sind, durch Trunking kompensieren kann.
Mitglied: chiefteddy
chiefteddy 03.06.2016 aktualisiert um 12:06:19 Uhr
Goto Top
Hallo,

Du sprachst davon, dass bereits einmal ein Switch im Tresen gewechselt wurde. Ich ging davon aus, dass der Haupt-Switch, die Patch-Panele usw. nicht im Tresen verbaut sind. Deshalb meine Vermutung, dass der "Flaschenhals" woanders zu suchen ist.

Aber nochmal: Ob ein Link 10, 50, oder 95m lang ist, das hat keinen signifikanten Einfuß auf die Datenrate einer Punkt-zu-Punkt-Ethernetverbindung. (Voraussetzung: der Link entspricht in seinen Übertragungparametern den in der Norm geforderten Mindestwerten --> Meßprotokoll).

Wenn ein 4k Full HD Video-Stream einen GB-Link nicht zum "schwitzen" bringt, wie soll das bei einer simplen Client-Server-DB-Abfrage, bei der ein paar ASCI-Zeichen hin und her geschickt werden, passieren?

Da die Kabellänge nicht die Ursache sein kann, hilft nur Messen (Netzwerk-Last-Test, Anzahl der fehlerhaften Pakete usw.), um den Flaschenhals zu finden.

Jürgen

PS: Erlaube den Antwortenden bitte, dass sie Dich auch auf einen falschen Denkansatz bei Deiner Problemlösung hinweisen. Die Kabellänge hat bei einer Cu-Verkabelung keinen signifikanten Einfluß auf die Datenrate!
Mitglied: Kraemer
Kraemer 03.06.2016 um 12:09:13 Uhr
Goto Top
Zitat von @chiefteddy:
Du sprachst davon, dass bereits einmal ein Switch im Tresen gewechselt wurde. Ich ging davon aus, dass der Haupt-Switch, die Patch-Panele usw. nicht im Tresen verbaut sind. Deshalb meine Vermutung, dass der "Flaschenhals" woanders zu suchen ist.
Stimmt - das war missverständlich formuliert - sorry. Es gibt da noch einen weiteres Netzwerk was ausschließlich Beleuchtung, Musik und ähnliches Steuert. Das läuft völlig autark.

Ich habe gerade noch folgendes gefunden und damit macht die Ausführung von aqui für mich jetzt auch Sinn - sprich ich verstehe das nun

Der Datenverkehr wird frameweise über die physischen Links verteilt.
Alle Frames, die zu einer bestimmten Datenkommunikation gehören, werden aber über dieselbe physische Verbindung (Kabel) übertragen. Das gewährleistet die Zustellung der einzelnen Frames einer Datenkommunikation in der richtigen Reihenfolge (verhindert mis-ordering).

Das heißt also für mich, das wenn für verschiedene Datenbankabfragen auch wirklich verschiedene Verbindungen aufgebaut werden, das ich dann durchaus einen Geschwindigkeitsvorteil herausholen kann. Wenn das ganze aber nur über eine Verbindung läuft, dann kann ich trunken so viel wie ich will - es wird nichts schneller.

Vielen dank soweit.
Mitglied: chiefteddy
chiefteddy 03.06.2016 um 12:20:06 Uhr
Goto Top
Hallo,

das ändert aber nichts daran, dass Dein Denkansatz, die subjektive gefühlte "Langsamkeit" einiger DB-Clients an der Länge des Ethernet-Links zum Switch liegt oder ein GB-Link von einem DB-Client überfordert wird, in die falsche Richtung geht.

Die Ursache der "Langsamkeit" liegt woanders.

Jürgen
Mitglied: Kraemer
Kraemer 03.06.2016 um 12:33:21 Uhr
Goto Top
Wie ich selbst schon schrieb:
Ich weiß nicht, ob es an der Länge der Netzwerkkabel (Patchfeld->Patchdose) liegt, oder aber an schlecht aufgelegten Leitungen
Also wird es wohl eher an letzterem liegen. Ist in diesem konkreten Fall auch völlig egal - austauschen kann ich die Leitungen eh nicht. Neu ziehen auch nicht. An die Dosen komme ich nicht heran. Wlan ist keine Alternative. Auch wenn es ätzend ist - ich kann keinen ganzen Verkaufsraum auseinander reißen, solange die Leitungen funktionieren. Der Kosten / Nutzeneffekt stimmt dabei einfach nicht.
Mitglied: michi1983
michi1983 03.06.2016 aktualisiert um 12:35:56 Uhr
Goto Top
Zitat von @Kraemer:
Also wird es wohl eher an letzterem liegen. Ist in diesem konkreten Fall auch völlig egal - austauschen kann ich die Leitungen eh nicht. Neu ziehen auch nicht. An die Dosen komme ich nicht heran. Wlan ist keine Alternative. Auch wenn es ätzend ist - ich kann keinen ganzen Verkaufsraum auseinander reißen, solange die Leitungen funktionieren. Der Kosten / Nutzeneffekt stimmt dabei einfach nicht.
Der Test mit iPerf kostet dich geschätzt 10 Minuten Aufwand.
Danach weißt du, was an Speed über die Leitungen geht und ob sie korrekt aufgelegt sind.

Gruß
Mitglied: Kraemer
Kraemer 03.06.2016 um 12:43:44 Uhr
Goto Top
Zitat von @michi1983:
Der Test mit iPerf kostet dich geschätzt 10 Minuten Aufwand.
Danach weißt du, was an Speed über die Leitungen geht und ob sie korrekt aufgelegt sind.
Wird auf jeden Fall gemacht. Das eigentliche Problem wird bei der nächsten Neugestaltung des Verkaufsraumes auch definitiv behoben.

Gruß Krämer
Mitglied: chiefteddy
chiefteddy 03.06.2016 um 13:09:47 Uhr
Goto Top
Hallo,

wenn es an "schlecht aufgelegten" Kabeln in den Dosen liegen sollte, müßten überproportion viele Datenpakete als fehlerhaft vom Switch aussortiert werden und noch einmal angefordert werden. Das würde sich nach "außen" als geringere Bandbreite manifestieren. Hier würde aber auch einfach mal ein Blick in das Log des Switches helfen. Der müßte eigentlich für jeden Port eine Statistik über gesendete, empfangene und verworfene Pakete führen.

Jürgen
Mitglied: Spirit-of-Eli
Spirit-of-Eli 04.06.2016 um 15:52:40 Uhr
Goto Top
Jip, da gebe ich dir recht.

Ansonsten mal die Strecke an sich checken // entweder messen o. Daten manuell drüber schieben.

Wer Geld ausgeben möchte kann für sowas auch Systeme wie "XNereus" verwende. Das nutzen wir für so einen Fall.