[Berlin-wireless] Lastverteilung VPN

So Jan 25 09:26:29 CET 2015

Moins,

der Debug-Modus hat sich heute morgen wie vorgesehen beendet. Ich hab'
die quantitativen Ergebnisse mal zusammengestellt nach CN
(Personennamen-in-CNs durch Ortsangaben ersetzt):

TUN{freifunk_stuttgart1}=122
TUN{freifunk_goettingen}=131
TUN{freifunk_stuttgart2}=150
TUN{freifunk_stuttgart3}=152
TUN{freifunk_berlin1}=175
TUN{freifunk_bremen}=272
TUN{freifunk_berlin2}=566
TUN{freifunk_chemnitz}=920
TUN{freifunk_berlin3}=972
TUN{freifunk_fuerth-in-franken}=1385
TUN{freifunk_chemnitz}=1963
TUN{freifunk_oldenburg}=2262

Die Zahlen sagen: in den letzen 12 Stunden so und soviele IP-Adressen
hinter einem Tunnel gesehen. Wieviele Bytes-pro-IPv4, das steht da
nicht. Insofern identifiziert es lediglich die "Supernodes" (also
wahrscheinlich Server, die ihrerseits wieder OpenVPN-Eingänge haben oder
wo ein größeres Mesh dahinter hängt). Aber nicht, welche Tunnel wieviel
Datenverkehr verursachen.

Die Supernodes "chemniz" und "oldenburg" von vpn03a auf vpn03b
verschieben, das bringt jetzt auch nicht megaviel. Sprich: die von den
"kleineren" Tunneln ausgelöste Datenlast ist insgesamt größer. Ein zur
Hochzeit (ca. 22:00h) gemachter Übertragungstest sagt: vpn03a ca 0,4-0,6
Mb/s, vpn03b ca 3-5 Mb/s. Wobei sich vpn03a zu dieser Zeit "Jumpy"
anfühlte (will schreiben: der Bytecounter vom Wget via vpn03a zählte
Sprungweise hoch, bei vpn03b nicht). Oder "wenn das OpenVpn mal eine
Zeitscheibe für mein Test-Wget hat, dann kommen gleich mehrere Pakete
für mich". Ein "top" zeigte auf beiden VPN-Servern so um die 30% für die
UDP-OpenVpn's an.

Mir scheint: es ist ein CPU-Auslastungsproblem mindestens auf vpn03a.
Jedenfalls zu Spitzenzeiten. Vermutlich ist zudem der
CPU-Auslastungswert innerhalb eines KVM-Containers auch nur bedingt
aussagekräftig. Beide Server haben mehrere Kerne, aber OpenVPN-2.x ist
Single-Core (siehe OpenVPN-3.0-Roadmap
<https://community.openvpn.net/openvpn/wiki/RoadMap>). Zudem verbinden
sich (derzeit) mehr Clients zu vpn03a. Ich hatte in der Vergangenheit
dazu ein extra "Sleep 120" in /etc/cron.weekly/openvpn eingebaut, aber
nicht wirksam wegen eines ungeschickt formulierten Scripts. Das habe ich
jetzt nachgeholt. Zweck: beim sonntäglichen Neustart möglichst viele
Clients auf vpn03b 'rüberschubsen.

Es ist sicher möglich, am einem Server mehrere OpenVpn-Server-Instanzen
zu starten, und die sich verbindenden Clients mittels
Port-Forwarding-Regeln auf die Instanzen zu verteilen. Das würde auf
Anhieb aber nur bedingt funktionieren, denn da fehlt eine
"Iroute-Learn-Address-Kommunikation" zwischen den verschiedenen
OpenVPN-Instanzen. Diese "Iroute-Learn-Address-Kommunikation" wäre
überdies auch zwischen den VPN-Servern hilfreich.

Hintergrund: wenn hinter einem VPN-Client ein Netzwerk ist, gibt man
dies dem OpenVPN-Server per "iroute" bekannt. So eine "iroute" sagt:
"folgendes IP-Netz befindet sich hinter dem Client so-und-so". Wenn sich
so-und-so verbindet, wird auf dem Server eine Route auf das
konfigurierte Netz gelegt und das OpenVPN-interne Connection-Tracking
angepasst. Dieses statische "Hinter-einem-Client-liegt 10.x.x.x/24"
passt für uns aber nicht. Wir haben ja z.B. ein Mesh, wo für ein und
dieselbe Mesh-IP der Datenverkehr mal über den einen Tunnel und mal über
den anderen Tunnel herauspuzelt. Deswegen gibt es den
Freifunk-spezifischen "dynamic-iroute-Hack". Der funktioniert prima,
solange das alles über dieselbe OpenVPN-Instanz abgewickelt wird. Bei
mehreren Instanzen (speziell bei mehreren Instanzen auf einem Server)
gibt es bei einem Client-Instanz-Wechsel mindestens einen abgebrochenen
Download für den Client. Es fehl ein Mechanismus, der OpenVPN-Instanz
"a" sagt, dass eine bestimmte Client-IP jetzt über OpenVPN-Instanz "b"
bedient wird. Am besten über Sockets, dann könnte man auch bei mehreren
OpenVPN-Server koordinieren. Das ist eine Programmieraufgabe - wenn ich
mal viel Zeit habe ;-)

Für's erste tut: möglichst viele Clients auf Vpn03b 'rüberschieben. Und
vllt. mal gucken, warum vpn03b so asymmetrisch kommuniziert (Upload viel
schneller als Download, ca. 10:1). Sowie schauen ob die VMs auch
CPU-mäßig optimal konfiguriert sind (@basti?).

Gruß // Sven-Ola

Am 24.01.2015 um 16:10 schrieb Philipp Borgers:
> On Sat, Jan 24, 2015 at 02:03:54PM +0100, Sven-Ola Tuecke wrote:
>> Nochmal Hallo Philipp,
>>
>> so eine IPerf-Messung sagt aus, wievel "Restbandbreite" übrig ist. Zeigt
>> ggf. an, welcher Server wie gut angebunden ist. Dem nach meinem Gefühl
>> etwas besser aufgestellten Vpn03b können wir also mehr überhelfen.
>> Trotzdem werde ich den Eindruck nicht los, dass sich alle Clients
>> irgendwie auf eine Kiste einschießen. Theorie: die Mehrheit hat
>> Google-als-DNS, und Google rückt zu jeder geraden Minute einen bestimmte
>> IP zu einem DNS-Namen. Die Supernode verfälschen allerdings das Bild hier.
> Die Clients schießen sich u.a. auf eine Kiste ein, weil sie nicht mehr als eine
> kennen.
>
> Die Firmware enthält absichtlich keinen Google-DNS oder ähnlich zweifelhafte
> DNS-Server. Die README verrät mehr über die gewählten DNS-Server.
>
>> Bin nicht sicher, aber dagegen könnte z.B. helfen: beim sonntäglichen
>> Neustart für 10 Minuten eine UDP-Firewall-Regel, die jeweils gerade /
>> ungerade Einwähl-IPs blockt.
> Ich denke das löst unser Problem nicht.
>
>> Wegen iperf: Aussagekräftiger halte ich Werte wie "vieviele Routen,
>> wieviel Conntracks, wieviele Tunnel, wieviel Übertragung". Gibt bei mir
>> im /home/sven-ola/stats.sh, damit guck' ich mir das an. Jeweils einmal
>> nach Gleichzeitiger-Neustart-Openvpn-mit-Debug, Nach 'rüberschieben
>> Chemniz, nach 'rüberschieben Oldenburg.
>>
>> sven-ola at vpn03a:~$ ./stats.sh
>> 12:15:26: v4r=1916 v6r=140 ctrack=10691, last 60s eth rx=9093 kB/s tx=9118 kB/s tun rx=768 kB/s tx=7271 kB/s
>> 13:37:30: v4r=2078 v6r=139 ctrack=11443, last 60s eth rx=7918 kB/s tx=7823 kB/s tun rx=434 kB/s tx=6647 kB/s
>> 13:58:31: v4r=1887 v6r=137 ctrack=12265, last 60s eth rx=8227 kB/s tx=8239 kB/s tun rx=440 kB/s tx=7176 kB/s
>>
>> sven-ola at vpn03b:~$ ./stats.sh 
>> 12:15:37: v4r=329 v6r=3 ctrack=7109, last 60s eth rx=2797 kB/s tx=2841 kB/s tun rx=83 kB/s tx=2600 kB/s
>> 13:37:42: v4r=557 v6r=3 ctrack=7792, last 60s eth rx=3657 kB/s tx=3721 kB/s tun rx=124 kB/s tx=3391 kB/s
>> 13:58:43: v4r=811 v6r=3 ctrack=8602, last 60s eth rx=3449 kB/s tx=3511 kB/s tun rx=117 kB/s tx=3206 kB/s
>>
>> Achso. Ist erst früher Nachmittag. Abends ist mehr Daten.
> Beides hat Aussagekraft, aber der iperf Benchmark zeigt, wie Basti auch
> andeutet, das der Kernel/die VM noch Luft hat. Jetzt können wir spekulieren,
> dass openvpn irgendwas falsch macht.
>
> Es gibt z.B. noch eine ganze Reihe von Kontext-Wechseln.
>
> Weißt du welche Implikationen der Aufruf des IP-Lern-Scripts auf dem Server hat?
> Wo/wann wird das aufgerufen?
>
>> // Sven-Ola
>>
>> Am 24.01.2015 um 13:00 schrieb Philipp Borgers:
>>> Hier die iperf logs:
>>>
>>> https://gist.github.com/booo/fe29553989fb209be1cf
>>>
>>> Tests liefen parallel zu laufenden Verbindungen.
>>
>
>
>> _______________________________________________
>> Berlin mailing list
>> Berlin at berlin.freifunk.net
>> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150125/caca8a5b/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 181 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150125/caca8a5b/attachment.pgp>