Gateway Virtualisierung: Mehrkern CPU sinnvoll ausnutzen


#1

Hey FFer,

bei uns ist es Zeit die Gw aufzurüsten, daher wird nun ein Server basierend auf einem i7 angeschafft.

Auf dem Server sollen mehrere GWs untergebracht werden. Ursprünglich waren 2 GWs angedacht. @MPW hat jedoch einen Denkanstoss gegeben, indem er nochmal auf die nötige single core Performance hinwies. Auch die fehlende Mehrkernunterstützung von BATMAN ist naturlich ein wichtiges Thema.

Daher nun meine Frage, macht es Sinn in einem Rutsch gleich 8 GWs auf dem Server zu virtualisieren um die Last gleichmäßig zu verteilen?

@MPW hat das zwar schon in einem anderen Thread bejat, ich würde jedoch gern noch ein paar mehr Meinungen lesen, vielleicht gibt es ja noch ein paar weitere gute inputs zu dem Thema.

Danke schon mal.

Gruß
Tarnatos


FF Gateway: Opteron 1381 VS. Celeron G530
#2

Sinn macht das nur, wenn Ihr Batman Compat 15 verwendet,
denn der fackelt bei SMP das System ab bei vielen Nodes.

Wir benutzen mit Compat14 und L2TP hauptsächlich das direkte Blech und lassen
5-8 Batman Instanzen dort verteilt auf den Kernen laufen.
Die einzelnen Broker und Instanz Spez. Dienste werden per “taskset -c 0|1|2|3…”
auf die Kerne verteilt. Das macht dann bei ca. 350 L2TP Verbindungen und
ca. 130-180Mbit/s RX/TX eine Load von 0.3 - 0.5 auf einem i7 920 :smile:
Das Ganze kann man aber auch mit fastd so verteilen.

Gruß vom Camacho :stuck_out_tongue_closed_eyes:


#3

Wir verwenden noch batman14 in Zusammenarbeit mit fastd.

Ist ein interessante Ansatz die Last so zu verteilen …


#4

Ich pushe hier nochmal ein wenig.

Wie machen das denn die ganzen anderen Communitys? Gibt doch noch mehr Serveradmins hier…

Aktuell planen wir, mittels proxmox zu virtualisieren. Ich finde deinen Vorschlag @comacho zwar sehr interessant, da müsste ich mich jedoch zunächst reinarbeiten und Grundlagen schaffen. Dafür fehlt mir die nötige Freizeit.


#5

Hey,

in unserem neuen “Hood” Setup statten wir die Maschinen, die MultiCore haben mit mehreren FastD Instanzen aus. Dadurch verteilt sich die Last auf die Kerne.


#6

Ich denke, dass es schlicht kein Universalrezept gibt, um alle angesprochenen zu einem Verfahren zusammenzufassen.
Eine Richtung lautet: Konzentrationen und viele kleine Einzeldomains mit jeweils einer VM und einem Kern.


#7

…weil es einfach Verschwendung ist ein Blech ohne Virtualisierung zu betreiben…selbst beim fastd schon, jetzt mit l2tp ein Supergau…


#8

Wir nutzen auch bereits L2TP und haben dort im moment sogar mit 1 Supernode keine Probleme was Last angeht. Der eine SN macht im moment im schnitt 50-80Mbit bei 150 Nodes und hat ne Load von 0.3

Wir haben uns desswegen dazu entschieden immer nur 1 unserer Supernodes Laufen zu haben. Der andere ist im IDLE und Pingt den Aktiven Supernode über seine FFRL Adresse an. Wenn er merkt das diese nicht mehr da ist, oder das kein Gateway mehr im Mesh ist schaltet er seine Dienste an und übernimmt. Immer zum 15. des Monats wechselt der Aktive Supernode bei uns.

Solange einer die Last packt war das für uns die beste lösung. Die maschienen sind aber beide mit nur einem Kern ausgestattet


#9

Bei der Konzentration von vielen GW-VMs auf einem Blech, darf man allerdings die Bandbreite nicht außer Acht lassen. Gerade beim CPU-schonenden L2TP ist Bandbreite eher der Flaschenhals.


#10

Das stimmt. Bei uns wird die Bandreite auf jeden vall VOR der CPU am limit sein. Da die Kisten aber Gigabit haben ist da noch ein bisschen platz


#11

Hi,
also bei Freifunk Ingolstadt gibts so nen “schönen” Hack um Fastd multithreaded zu machen

https://build.opensuse.org/package/view_file/home:fusselkater:freifunk/fastd-multiproc/fastd-17-reuseport.patch?expand=1

damit kann man dann z.B. $(nproc)-1 Instanzen von Fastd starten :wink:


#12

In Wupper werden um die 12 Broadcast-Domänen auf 4 Kernen und 4 vServern mittels fastd gefahren. Mit L2TP stürzt das ganze ab. Je nach CPU (und Nutzerverhalten) kann man um die 300 Knoten auf einem Kern bedienen.

Aus deinem Beitrag ist nicht ersichtlich, ob Ihr L2TP oder fastd einsetzt.

Bei fastd kann man mehrere fastd-Instanzen aufsetzen und verschiedene Ports einstellen. Diese kann man in der Nutzerzahl begrenzen. In Batman kann man mehrere dieser Schnittstellen einbinden, so hat man eine Broadcast-Domäne auf vielen CPUs.


#13

Wir haben inzwischen pro Supernode 7 batman Segmente mit eignem fastd und können dadurch gut mehrere Kerne belasten. Zudem reduziert sich der Overhead massiv.

Ein schneller hack ist auch für IPv6 und IPv4 verschiedenen fastd Instanzen laufen zu lassen, das sorgt zumindest für etwas Lastverteilung.


#14

kannst du erklären, was man alles anpassen muss um mehrere fastd instanzen laufen zu lassen?

Oder wo sind eure configs


#15

Was soll da so schwer sein? Zweite Konfigurationsdatei mit einem neuen Port, der dann natürlich in der Site.conf drin stehen muss, ansonsten alles wie beim ersten Fastd. Im Ruhrgebiet liefen früher dutzende so ^^

http://manpages.ubuntu.com/manpages/bionic/de/man1/taskset.1.html


#16

Das Problem besteht mehr darin , dass nicht korrekt geroutet wird.

Wir kriegen eine 2. Fastd Instanz zwar online, ein Node sieht auch sein Batman gw jedoch bekommen wir keine Route ins Internet.

Vermutlich liegt es an der iptables Config.


#17

Das klingt auch so als wäre es etwas Richtung Iptables/Iprules.
Hab mal kurz reingeguckt, aber mir ist eurer Puppet Setup zu wuselig :wink:
Vermutlich fehlt hier die Übergabe eines weiteren Mesh Devices.
Tip: iptables-save/restore module für Puppet ist übersichtlicher :slight_smile:


#18

Ich habe hier nochmal unsere IPTables cfg

cat /etc/iptables.d/*
set_value /sys/module/nf_conntrack/parameters/hashsize 32768
# Reset all prior rules
ip46tables -F
ip46tables -t mangle -F
ip4tables -t nat -F
ip46tables -X
# Chains for package processing

# Default Input Chains

ip46tables -N input
ip46tables -N bat-input
ip46tables -N mesh-input
ip46tables -N wan-input

# Default Forward Chains

ip46tables -N forward
ip46tables -N bat-forward
ip46tables -N mesh-forward
ip46tables -N wan-forward

# Helper Chains

ip46tables -N DROP-log
# Initial processing of input chain on filter table
# Packages which are not directly ACCEPTed or DROPed are pushed to the forward chain

# connection tracking
ip46tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip46tables -A FORWARD -m conntrack --ctstate INVALID -j DROP

# icmp handling, TODO icmp border handling
ip4tables -A FORWARD -p icmp -j ACCEPT
ip6tables -A FORWARD -p icmpv6 -j ACCEPT

# udp specific connection tracking
ip46tables -A FORWARD -p udp -m conntrack --ctstate NEW -j forward
ip4tables -A FORWARD -p udp -j REJECT --reject-with icmp-port-unreachable
ip6tables -A FORWARD -p udp -j REJECT --reject-with icmp6-port-unreachable

# tcp specific connection tracking
ip46tables -A FORWARD -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j forward
ip46tables -A FORWARD -p tcp -j REJECT --reject-with tcp-reset
# Initial processing of input chain on filter table
# Packages which are not directly ACCEPTed or DROPed are pushed to the input chain

# Accept all packages for loopback device
ip46tables -A INPUT -i lo -j ACCEPT
# Accept all icmp packages
ip4tables -A INPUT -p icmp -j ACCEPT
ip6tables -A INPUT -p icmpv6 -j ACCEPT

# Connection Tracking
ip46tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip46tables -A INPUT -m conntrack --ctstate INVALID -j DROP

# udp specific connection tracking
ip46tables -A INPUT -p udp -m conntrack --ctstate NEW -j input
ip4tables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
ip6tables -A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable

# tcp specific connection tracking
ip46tables -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j input
ip46tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
# Process packages from device bat-ffnord
ip46tables -A input -i bat-ffnord -j bat-input
ip46tables -A forward -i bat-ffnord -j bat-forward
ip46tables -A input -i bat-client1312 -j bat-input
ip46tables -A forward -i bat-client1312 -j bat-forward
    
# Process packages from device br-ffnord
ip46tables -A input -i br-ffnord -j mesh-input
ip46tables -A forward -i br-ffnord -j mesh-forward
    # Process packages from device eth0
ip46tables -A input -i eth0 -j wan-input
ip46tables -A forward -i eth0 -j wan-forward
    # Process packages from device icvpn
ip46tables -A input -i icvpn -j mesh-input
ip46tables -A forward -i icvpn -j mesh-forward
    ## Implement the Best Current Practices
# for defending against Denail of Service Attacks
# BCP38 ingress filters

# ipv4
# TODO implement also for vpn?
block4 wan-input 127.0.0.0/8
block4 wan-input 0.0.0.0/8       # RFC 1700
block4 wan-input 240.0.0.0/4     # RFC 5745
block4 wan-input 192.0.2.0/24    # RFC 5737
block4 wan-input 198.51.100.0/24 # RFC 5737
block4 wan-input 203.0.113.0/24  # RFC 5737
block4 wan-input 192.168.0.0/16  # RFC 1918
block4 wan-input 10.0.0.0/8      # RFC 1918
block4 wan-input 172.16.0.0/12   # RFC 1918
block4 wan-input 169.254.0.0/16  # RFC 3927

# ipv6 
# TODO implement for uplink
block6 wan-input 2001:DB8::/32   # example network
block6 wan-input fc00::/7        # ula
block6 wan-input fec0::/10       # site-local
block6 wan-input ::ffff/96       # v6mapped
block6 wan-input 2001:10::/28    # orchid (rfc 4843)
block6 wan-input 3ffe::/16       # 6bone
block6 wan-input ff00::/8        # multicast
## Block incoming request from defined ipv{4,6} ranges.
# This file is created by puppet, but will not be overwritten.
# Example:
# block4 wan-input 192.168.0.0/24
# Allow Service bird
ip46tables -A mesh-input -p tcp -m tcp --dport 179 -j ACCEPT -m comment --comment 'bird'
    # Allow Service dhcpd
ip46tables -A mesh-input -p udp -m udp --dport 67 -j ACCEPT -m comment --comment 'dhcpd'
ip46tables -A mesh-input -p udp -m udp --dport 68 -j ACCEPT -m comment --comment 'dhcpd'
    # Allow Service fastd-ffnord
ip46tables -A wan-input -p udp -m udp --dport 10050 -j ACCEPT -m comment --comment 'fastd-ffnord'
ip46tables -A wan-input -p udp -m udp --dport 10051 -j ACCEPT -m comment --comment 'fastd-1312'
    
# Allow Service named
ip46tables -A mesh-input -p udp -m udp --dport 53 -j ACCEPT -m comment --comment 'named'
ip46tables -A mesh-input -p tcp -m tcp --dport 53 -j ACCEPT -m comment --comment 'named'
    # Allow Service ntpd
rate_limit46 "ntpd" 3600 10 -A mesh-input -p udp -m udp --dport 123
ip46tables -A mesh-input -p udp -m udp --dport 123 -j ACCEPT -m comment --comment 'ntpd'
    # Allow ssh on wan and mesh
rate_limit46 "sshd" 60 3 -A wan-input -p tcp -m tcp --dport 55522
rate_limit46 "sshd" 60 3 -A mesh-input -p tcp -m tcp --dport 55522
ip46tables -A wan-input -p tcp -m tcp --dport 55522    -j ACCEPT
ip46tables -A mesh-input -p tcp -m tcp --dport 55522    -j ACCEPT
# Allow Service tincd
ip46tables -A wan-input -p tcp -m tcp --dport 655 -j ACCEPT -m comment --comment 'tincd'
    # Process packages from device br-ffnord
ip46tables -A mesh-forward -o br-ffnord -j ACCEPT
ip4tables -A mesh-forward -o eth0 -j ACCEPT
# Process packages from device icvpn
ip46tables -A mesh-forward -o icvpn -j ACCEPT
# Drop all packages which are not ACCEPTed to this point
ip46tables -A FORWARD -j DROP
ip46tables -A forward -j DROP
ip46tables -A bat-forward  -j DROP
ip46tables -A mesh-forward -j DROP
ip46tables -A wan-forward  -j DROP
# Drop all packages not ACCEPTed to this point
ip46tables -A INPUT -j DROP
ip46tables -A input -j DROP
ip46tables -A bat-input -j DROP
ip46tables -A mesh-input -j DROP
ip46tables -A wan-input -j DROP
ip46tables -A DROP-log ! -p tcp  -j LOG --log-ip-options --log-uid
ip46tables -A DROP-log -p tcp -j LOG --log-tcp-sequence --log-tcp-options --log-ip-options --log-uid
ip46tables -A DROP-log -j DROP
ip4tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE