The objective it's making a single Tor Relay and using on the machine many daemons on a multicore server. I hope someone can give me a feedback if this kind of configuration can be problematic for Tor network before test in a real environment.
Many Tor daemon, with X from 0..n, binded on different port, all advertise the same ORPort/DirPort. An IPVS load balancing at kernel level.
Tor Config:
SocksPort 0 Nickname superrelay Address superrelay.net ORPort 443 NoListen
ORPort 127.0.0.1:100X NoAdvertise DirPort 80 NoListen
DirPort 127.0.0.1:200X NoAdvertise DataDirectory /var/lib/tor/childX
All daemon have the same SocksPort, Nickname, Address, MyFamily. All daemon point to different DataDirectory, but each of them have the 'keys' directory identical. All daemon advertise the ORPort 443 and DirPort 80, but bind on other ports.
IPVS configuration:
# Clear ipvsadm -C
# Add a virtual server (-A) for ORPort. ipvsadm -A -t superrelay.net:443 -s sh
# Add a virtual server (-A) for DirPort. ipvsadm -A -t superrelay.net:80 -s sh
# Add all real servers/daemons (-a) for ORPort ipvsadm -a -t superrelay.net:443 -r localhost:1000 -m ipvsadm -a -t superrelay.net:443 -r localhost:1001 -m ... ipvsadm -a -t superrelay.net:443 -r localhost:100X -m
# Add all real servers/daemons (-a) for DirPort ipvsadm -A -t superrelay.net:80 -s sh ipvsadm -a -t superrelay.net:80 -r localhost:2000 -m ipvsadm -a -t superrelay.net:80 -r localhost:2001 -m ... ipvsadm -a -t superrelay.net:80 -r localhost:200X -m
Note the scheduling method: sh - Source Hashing: assigns jobs to servers through looking up statically assigned hash table by their source IP addresses. Any source-ip will be always binded to the same daemon.
I think 'Advertised Bandwidth' on onionoo/atlas can be inexact.
I can experiment a relay like that, or can be problematic/unexpected for Tor network? Thanks for any feedback.