Loadbalancer ? alternativen ?

[Gelöschtes Mitglied 24898]

Hallo zusammen,
ich bräuchte mal bitte euren Rat.
Ab Ende Januar bekomme ich 2x 100mbit Down 40Mbit Up VDSL Leitungen geschaltet, genutzt werden eine AVM 3490 & eine 7490. Ich würde gerne beide Leitungen gleichzeitig für o.a Multidownloads, Steamdownload & Livestreaming via OBS nutzen.
Meine Frage wäre nun, wie ich am besten beide Leitungen nutze.

Würdet ihr die "typischen" Loadbalancer von TP-Link empfehlen ? gibt es alternativen ?
Kennt ihr noch andere Hardware die damit "ordentlich" umgehen kann ? oder solle ich auf eine VM gehen ? (kleiner Homeserver vorhanden)

Vielen dank für eure Hilfe

Gruß

 

[awehring]

In c't Heft 24/2016 ist eine Anleitung, wie man einen Loadbalancer mit pfsense selbst baut.
Bei heise.de kann man einzelne Artikel aus der c't für kleines Geld als Download kaufen.

In dem Artikel sind auch ein paar Grundlagen erläutert. Beispielsweise kann ein Loadbalancer normalerweise nicht die Geschwindigkeit von einem einzigen Download erhöhen. Es wird nur eine Leitung ausgelastet. Nur wenn zwei Downloads parallel zu unterschiedlichen Zielen stattfinden, können beide Leitungen genutzt werden.

Diese Einschränkung zu umgehen ist möglich, erfordert aber einiges zusätzlich.

 

[p4n0]

Ich würde folgendes machen:

Entweder eine Leitung kündigen und nur eine der beiden verwenden, ODER:

Nen VPN Tunnel durch beide Leitungen an nen RZ Server. Dort wird das VPN terminiert - von dort gehts dann ins WAN.
Somit hast du fast die volle Bandbreite beide Leitungen fuer alle Anwendungen zur Verfügung.

Grueße

 

[Gelöschtes Mitglied 24898]

In c't Heft 24/2016 ist eine Anleitung, wie man einen Loadbalancer mit pfsense selbst baut.
Bei heise.de kann man einzelne Artikel aus der c't für kleines Geld als Download kaufen.

In dem Artikel sind auch ein paar Grundlagen erläutert. Beispielsweise kann ein Loadbalancer normalerweise nicht die Geschwindigkeit von einem einzigen Download erhöhen. Es wird nur eine Leitung ausgelastet. Nur wenn zwei Downloads parallel zu unterschiedlichen Zielen stattfinden, können beide Leitungen genutzt werden.

Diese Einschränkung zu umgehen ist möglich, erfordert aber einiges zusätzlich.

klingt interessant, du würdest also einen "eigenbau" bevorzugen ?
das mit den einzelnen Downloads wäre kein Problem für mich bzgl mit beide Leitungen gleichzeitig nutzen meinst du wohl Bonding oder ?
werde ich mir mal angucken, danke !

Ich würde folgendes machen:

Entweder eine Leitung kündigen und nur eine der beiden verwenden, ODER:

Nen VPN Tunnel durch beide Leitungen an nen RZ Server. Dort wird das VPN terminiert - von dort gehts dann ins WAN.
Somit hast du fast die volle Bandbreite beide Leitungen fuer alle Anwendungen zur Verfügung.

Grueße

Kündigen möchte ich die Leitungen eigentlich nicht, eher beide verwenden
über die Möglichkeit habe ich auch bereits nachgedacht, die Probleme die ich aber bisher gesehen habe waren 1) der Traffic 2) der Ping, hast du Erfahrungen ?

 

[KurantRubys]

Die Konstellation die bei unseren Kunden Problemlos läuft, ist mit einem Lancom. Die zwei Anschlüsse an den Lancom hängen (1x internes und 1x externes Modem) und den das Load-Balancing machen lassen. Läuft so absolut problemlos und ist fast kein Konfigurationsaufwand.

 

[awehring]

klingt interessant, du würdest also einen "eigenbau" bevorzugen ?
das mit den einzelnen Downloads wäre kein Problem für mich bzgl mit beide Leitungen gleichzeitig nutzen meinst du wohl Bonding oder ?
werde ich mir mal angucken, danke !

Was DU bevorzugst ist wohl wichtiger. Ich habe keinen Bedarf, meine Leitung ist schnell genug

Eigenbau ist kostenlos (wenn man die Hardware hat), aber mehr Konfigurationsaufwand. Jedenfalls sollte man schon eine gute Grundlage an Netzwerkkenntnissen mitbringen. Mit dem Eigenbau lernt man noch etwas dazu.

Bonding erfordert, dass die Gegenstelle, also der ISP, das unterstützt. Das ist wohl kaum zu finden, schon gar nicht, wenn die Leitungen von 2 verschiedenen ISPs sind.

Die von @p4n0 vorgeschlagene VPN-Lösung ist eine der Lösungen. Sie erfordert aber einen eigenen Server in einem Rechenzentrum mit schneller Internetleitung und auch einigen Konfigurationsaufwand.

 

[p4n0]

Dafuer gibts bei meiner Loesung - sofern korrekt umgesetzt - keinerlei schwierigkeiten was wechselnde Sessions etc betrifft.
Und man kann fast vollstaendig auf die 200/80 Bandbreite zurueckgreifen, ganz egal was man da durch schiebt.

Daher denke ich.. Entweder richtig oder gar nicht.
Einfach 'nur' n round-robin LB fuer die beiden Leitungen bringt halt nix außer aerger. Und den gewuenschten Effekt dass man dadurch 'mehr' Bandbreite erhaelt
hat man halt nicht.

Grueße

 

[Gelöschtes Mitglied 24898]

also das Bonding via VPN / RZ klingt schon sehr interessant, ist aber aufgrund der nachfolgenden Kosten allzu Wirtschaftlich, oder kennt jemand nen "ordentlichen" Anbieter der auch mind. 200Mbit (am vserver?) angebunden hat und recht günstig ist ?
Ich denke, das diese Kombi wohl aufgrund des Pings nicht sehr für Zocker geeignet ist oder ?

Die Leitungen sind beide vom gleichen Anbieter, aber wie bereits leider erwähnt -> kein Bonding beim Provider möglich

 

[p4n0]

Was genau erhoffst Du dir denn von den beiden Leitungen, wenn dir nen zwanni im Monat zusaetzlich zuviel wird?

Wie gesagt - du kannst die Dinger nicht so 'sinnvoll' zusammenfassen wie du's dir warscheinlich vorgestellt hast.
Daher wuerde ich einfach sagen schmeiß eine Leitung weg und spar dir die Kohle.

100/40 sind vollkommen ausreichend.

 

[awehring]

@BigSmoke:
Eigentlich ist mir nicht klar, was du genau willst. Oben schreibst du:

das mit den einzelnen Downloads wäre kein Problem für mich

Dann kommst du mit einem simplen Loadbalancing aus und Pings sind kein Problem.

Wenn du doch die beiden Leitungen zu einer logischen kombinieren willst um auch einen einzelnen Download zu beschleunigen, empfiehlt sich die aufwendigere VPN Lösung.
Wenn du da die niedrigsten Pings fürs Spielen erziehlen willst, kannst du den Spiele-Traffic am VPN vorbei schleusen. Er würde dann direkt über eine der beiden DSL Leitungen laufen.

Alles nur eine Frage der richtigen Konfiguration

Je nach deinen Vorkenntnissen ist das eine Frage von Stunden oder Wochen

- - - Updated - - -

Am einfachsten (für das simple Loadbalancing) ist es mit einem gekauften professionellen Router, wie zum Beispiel dem oben erwähnten Lancom. Dafür musst du einige hundert Euro einplanen. Ein Netzwerkneuling muss ich da aber auch erst durch die Konfiguration durchkämpfen.

 

[Gelöschtes Mitglied 24898]

also der zwanni ist mir sicher nicht zuviel, ich finde nur keinen "ordentlichen" Anbieter der mir eine Bandbreite von mind. 200Mbit garantiert außer bei Root-Servern und vor allem ab einem gewissen Traffic nicht auf 100/10Mbit drosselt. Die zweite Leitung ist für umme, deshalb bleibt die definitiv

Den Spieletraffic sollte ich ja via DiffServ geroutet bekommen oder ?

Habe leider Bonding via VPN noch nie eingerichtet, kennt ihr da vielleicht eine kleine Anlaufstelle bzgl. der Einrichtung ? würde das mal ausprobieren

 

[Seratio]

@p4n0 hast du soetwas denn schonmal gebaut? Denn meiner Erfahrung nach kann sowas nicht richtig funktionieren.

Zunächst erstmal hast du in der Theorie das Problem, dass die Leitungen unterschiedlichen Latenzen aufweisen werden. Wenn z.B. eine TCP Verbindung über 2 Leitungen läuft, kommt es zu massig reorderings in den Paketen. Ggf. müssen Pakete sogar erneut gesendet werden.

Des weiteren wäre mir nicht klar, dass soetwas überhaupt funktioniert. Nimmt man z.B. eine Link Aggregation nach 802.3ad, so wie es zwischen Switchen verwendet wird, wird ein einzelner TCP Stream nie über mehrere Leitungen gehen. Die Bandbreite ist immer auf die Größe eine Leitung limitiert. Dabei spielt die Anzahl der Leitungen keine Rolle. Erst mehrere Verbindungen werden auf mehrere Links aufgeteilt.

Das Linux bonding Modul scheint zwar paketbasiertes Loadbalancing zu unterschützen, aber nutzen würde ich sowas nicht.


Bei z.B. 4x 40Mbit, wirst du je TCP Verbindung nur maximal 40Mbit hinbekommen und nicht 160.


Im übrigen kannst du bei einem VPN Tunnel noch mal 5-10% Protokoll Overhead draufrechnen. Dir gehen praktisch bei 40Mbit 2-4Mbit nur für VPN Header, Verschlüsselung etc drauf. Nicht, dass es relevant wäre, aber ich wollte es erwähnt haben.

 

[p4n0]

@p4n0 hast du soetwas denn schonmal gebaut? Denn meiner Erfahrung nach kann sowas nicht richtig funktionieren.

Zunächst erstmal hast du in der Theorie das Problem, dass die Leitungen unterschiedlichen Latenzen aufweisen werden. Wenn z.B. eine TCP Verbindung über 2 Leitungen läuft, kommt es zu massig reorderings in den Paketen. Ggf. müssen Pakete sogar erneut gesendet werden.

Des weiteren wäre mir nicht klar, dass soetwas überhaupt funktioniert. Nimmt man z.B. eine Link Aggregation nach 802.3ad, so wie es zwischen Switchen verwendet wird, wird ein einzelner TCP Stream nie über mehrere Leitungen gehen. Die Bandbreite ist immer auf die Größe eine Leitung limitiert. Dabei spielt die Anzahl der Leitungen keine Rolle. Erst mehrere Verbindungen werden auf mehrere Links aufgeteilt.

Das Linux bonding Modul scheint zwar paketbasiertes Loadbalancing zu unterschützen, aber nutzen würde ich sowas nicht.


Bei z.B. 4x 40Mbit, wirst du je TCP Verbindung nur maximal 40Mbit hinbekommen und nicht 160.


Im übrigen kannst du bei einem VPN Tunnel noch mal 5-10% Protokoll Overhead draufrechnen. Dir gehen praktisch bei 40Mbit 2-4Mbit nur für VPN Header, Verschlüsselung etc drauf. Nicht, dass es relevant wäre, aber ich wollte es erwähnt haben.

Ich selbst habe das noch nicht gebaut, nein.

Aber es funktioniert. Sogar ueber DSL / UMTS und sonstigen Leitungen gemischt.

--> https://www.viprinet.com/de

Grueße

 

[underclocker2k4]

@p4n0 hast du soetwas denn schonmal gebaut? Denn meiner Erfahrung nach kann sowas nicht richtig funktionieren.

Zunächst erstmal hast du in der Theorie das Problem, dass die Leitungen unterschiedlichen Latenzen aufweisen werden. Wenn z.B. eine TCP Verbindung über 2 Leitungen läuft, kommt es zu massig reorderings in den Paketen. Ggf. müssen Pakete sogar erneut gesendet werden.

Des weiteren wäre mir nicht klar, dass soetwas überhaupt funktioniert. Nimmt man z.B. eine Link Aggregation nach 802.3ad, so wie es zwischen Switchen verwendet wird, wird ein einzelner TCP Stream nie über mehrere Leitungen gehen. Die Bandbreite ist immer auf die Größe eine Leitung limitiert. Dabei spielt die Anzahl der Leitungen keine Rolle. Erst mehrere Verbindungen werden auf mehrere Links aufgeteilt.

Das Linux bonding Modul scheint zwar paketbasiertes Loadbalancing zu unterschützen, aber nutzen würde ich sowas nicht.


Bei z.B. 4x 40Mbit, wirst du je TCP Verbindung nur maximal 40Mbit hinbekommen und nicht 160.


Im übrigen kannst du bei einem VPN Tunnel noch mal 5-10% Protokoll Overhead draufrechnen. Dir gehen praktisch bei 40Mbit 2-4Mbit nur für VPN Header, Verschlüsselung etc drauf. Nicht, dass es relevant wäre, aber ich wollte es erwähnt haben.

Nicht immer alles in Frage stellen. Sowas ist in der "richtigen" Welt Kindergartenanwendung, seit 20 Jahren.
MLPPP heißt das Zauberwort. Es macht prinzipiell genau das, was er beschrieben hat. Und das schon seit ISDN.

EDIT:
In der Neuzeit angekommen ist das MultiPathTCP.

Es gibt etliche Wege, allerdings muss im Moment eine Gegenseite existieren. (Hybrid von der Telekom ist nichts anderes)

Für den TE reicht aber nen 0815 LB aus.

 

[Seratio]

Das bei ISDN so etwas möglich ist, weiß ich. Auch, dass es MultiPathTCP gibt(Was nur vermutlich noch niemand so wirklich produktiv einsetzt).

Vll denke ich nur zu groß und zu standardorientiert... Als Netzwerker eines ISPs stellt man gern mal Sachen in Frage :P

 

[underclocker2k4]

Das ist alles ISP-Technologie, nicht in Frage stellen, sondern pushen!
Gerade weil es (beide) IETF-Standards sind, solltest du dich mal damit "beschäftigen". Alle Mal besser als das, was die Anbieter mit ihren proprietären "Standards" verbocken.

MLPPP geht auch mit DSL. Es kommt nur aus der Zeit von ISDN und wurde dann ~2000 adaptiert.
Es wird nur leider zu wenig (in .de) angeboten.

MutlipathTCP ist noch recht jung. Wie immer dauert es etwas, bis das implementiert ist. Es gibt wohl schon passende kernel.
Das Interessante ist ja, dass es eigentlich vom Provider unabhängig ist, da es im Stack sehr weit oben angesiedelt ist.
Hybrid von der Telekom nutzt es aber bereits.

 

[dirk11]

MLPPP geht auch mit DSL. Es kommt nur aus der Zeit von ISDN und wurde dann ~2000 adaptiert.

Jau. Meine seligen US-Robotics Courier I-Modem konnten das. Hach, das waren noch Zeiten...