[WLANtalk] Netcup als möglicher Host Provider für Freifunk Exit Nodes?

[Kai 'wusel' Siering]

Moin,

on 10/05/15 09:08, Bernd Kalbfuss-Zimmermann wrote:
> Am 06.05.2015 um 12:56 schrieb Kai 'wusel' Siering:
> > Hmm, welche Werte habt Ihr denn bei anderen (v)Servern? Da fastd
> > singlethreaded ist, hilft eine etwaige 2. CPU ja "nur" beim
> > Weiterleiten des Mesh-Verkehrs gen Exit; Stand heute würde ich aus
> > dem Grund auch 2 (v)CPU und 1 GB als sinnvolles Minimum ansetzen
> > (bislang haben wir 1/1 benutzt).
>
> Ok. Das ist doch mal eine konkrete Angabe mit der ich arbeiten kann.
> Also 2 CPUs und wenigstens 1 GB RAM.

FTR, im Forum gibt's einen Thread dazu (im FFRL-Bereich ..., in dem sich auch
@netcup beteiligt und diese und ähnliche Fragen gestellt hat. Ich habe dort
von 2 CPUs, 2 GB gesprochen, da unsere HW je Core 2 GB RAM hat und
ich davon ausgehe, daß dieses Verhältnis auch sonst bei Servern typischer
ist. Mit fastd, named, OpenVPN, bird ist das 1 GB unserer bisherigen VMs
zu ca. 70% in Benutzung, ohne Swap imho schon grenzwertig. (Und Swap
und VMs, naja, Dauerdiskussion ;))

> Bzgl. fastd: Weißt du zufällig, ob Neoraider daran arbeitet den fastd
> multithread-fähig zu machen?

IIRC ja.

> Eventuelle Zwischenlösung: Mehr als eine fastd-Instanz auf mehreren
> Ports betreiben. Diese dann separate in die site.conf aufnehmen und
> alle fastd-Netzwerkschnittstellen mit der batman-adv-Schnittstelle
> verbinden. Würde das funktionieren? Hat das schon mal jemand ausprobiert?

Das besser abzudecken, dazu dienen IIRC Änderungen in v17 und der site.conf
für 2015.1.

Wir fahren experimentell ein separates fastd (mit 1400er MTU) zwischen einigen
GWs, um nicht in die limitierung für Peer-Verbindungen zu laufen, die wir wegen
der Ungleichverteilung auf die GWs einführen mußten. In einem zukünftigen FW-
Release werden wir die MTU generell auf 1400 (von 1426 jetzt) senken; oder evtl.
doch auf das Fragmentationsfeature von fastd (v18?) warten. Insofern: die Kopp-
lung per batman tut. Bei mehreren fastds auf dem gleichen Host war bislang IIRC
tricky, fastd dazu zu bringen, nicht beide Verbindungen zu 1 Host aufzumachen.

> > 50 Tunnel zu je 8 MBit/sec (841er fastd-Maximum) sind ja schon
> > satte 400 MBit/sec; also 800 MBit/sec, die durch die Kiste
> > geschleust werden müssen (bei nicht-lokalem Exit): 400 rein in den
> > fastd-, 400 raus in den OpenVPN-Tunnel. Wie haben bei 70 Tunneln,
> > die bei weitem nicht ausge- lastet waren, die Reißleine ziehen
> > müssen (lies: fastd-Zugang limitiert), da fastd bei 90+% CPU lag.
> > Das sowohl auf eigenen KVM-VMs auf eigener HW (2,5 GHz QC-Xeons)
> > als auch auf extern gehosteten VMs (3,3 GHz lt. cpuinfo).
>
> Wie Aussagekräftig ist den heutzutage noch der Takt der CPU? Wie
> sollte man für einen Server die Leistung messen?

Ich nehme als Anhaltspunkt i. d. R. Benchmarks, so ist der 3,1 GHz X5460
in unserer DL380G5 mit 1340 bewertet, ein "etwas" aktuellerer E5-1620 mit
3,6 GHz erzielt 1923 Zähler in der Single-Thread-Performance (als v3 mit
3,5 GHz 1997; und die E5420, 2,5 GHz, in meinen DL360G5 1074). Da hier
primär die Single-Thread-Performance von fastd & OpenVPN relevant ist,
AES hingegen keine große Rolle spielt, würde ich schätzen, daß ein aktueller
E5-1620 v3 ca. 50% mehr fastd-Verkehr verkraftet als ein Core meiner E5420.

Aber da mir die Mittel fehlen, das wirklich auszutesten (die verschienenen Ser-
ver an einem Switch, und dann entsprechend viele "Clients" mit unterschiedlichen
synthetischen Lasten), bleibt da nur try & error ;) Chris' Aussage im Forums-
Thread ist: "In sofern die Bandbreite erreichbar ist, lasten 8 VPN Gateways eine
moderne Maschine (E5-1620) komplett aus und fabrizieren dabei 500 Mbit/s."
Ein E5-1620 hat nur 4 Kerne und kann lt. Datenblatt auch nur in single-socket-
Systemen betrieben werden; unsere Xeon-Quadcores kommen immer in Pär-
chen, da haben wir also 8 echte Kerne -- die lt. Benchmark dann ca. halb so
schnell sind ...
Insofern würde ich auch mit abgeschriebenem Netcup-Blech zufrieden sein
(an Netcups Stelle würde ich je vermietetem Freifunk-Blech 1 identische Karre
"daneben" stellen als Standby-/Ersatzsystem; groß Teile zu tauschen rechnet
sich da nicht. Platten umstecken oder, noch besser, Ersatzblech mit alter IP-
Config in Rescue-System booten und Community restauriert sich ihr System
selbst; mit github & puppet geht's kaum noch einfacher).

MfG,
-kai

-- 
Freifunk-Initiative Gütersloh
℅ Kai Siering
Schalückstraße 107
33332 Gütersloh
 
info at guetersloh.freifunk.net
Tel.: (05241) 96 46 269