[tor-relays] Load balancing (with IPVS) multiple Tor daemons

[Clodo]

> Tor uses multithreaded crypto already: depending on the speed of your
> processor, you can get up to 400 Mbps per instance (250 Mbps is
> typical).

Here i see a pending project:
https://trac.torproject.org/projects/tor/ticket/1749
and plans about that:
https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto#Parallelizingcellcrypto
are stalled from years because of complex implementation (and the
current possibility
of running multiple daemon lower the priority, of course).

Maybe Tor uses multithread for some activity, but actually it's not
a real/full multithread implementation from what i understand.
Otherwise, what are the reason to run multiple daemon on the same server
like a lot of people do with high-capacity 1gbit/s server does?

If i have a 10gbit/s unmetered port with a 24-core CPU, i'm forced to
run multiple-daemons on multiple ip to use it at maximum.
And the world see a lots of relay (within the same Family, of course).
This is a wrong approach for me:
- overhead OONION/Atlas. I know a guy that run over 30 relay on
  3/4 physical machine (so for OONION/Atlas, 30 relay to track, collect
stats and so on).
- requirement to Tor relay volunteers to obtain many IP address   to run
high-capacity servers.
- configuration issue, for example about running multiple-daemon with
systemd.

so i'm thinking if can exists a better, easy solution.
I just want to be constructive, i'm a open-source tools developer in my
spare time.

> These things will break:
> * if multiple tor daemons update the same onion keys at the same time,
>   the key files may get corrupted or the cross-certification may not
>   refer to the keys being used. This would break all Tor instances for
>   any circuits after a week or a month (depending on the tor version).
> * your relays will place additional load on the directory authorities
>   by uploading multiple identical descriptors
> * if these descriptors ever get out of sync, they will replace each
>   other, causing unpredictable behaviour
>
> Because clients expect to access the same process with the same identity:
> * your relay will not be usable as an HSDir
> * your relay will not be usable as an Introduction Point
> * your relay will not be usable as a Rendezvous Point
>
Honestly i don't know well this kind of details. It's the reason of this
discussion with people like you.
Maybe it's possibile to simply develop or patch specific options to
obtain the objective to "made easy" an high-capacity server. Probably
more easy than the works linked above about the Parallelizingcellcrypto.
For example, "uploading multiple identical descriptors" maybe be simply
avoided with an option that identify the 'master' daemon, other daemons
simply skip the descriptors upload phase.
Or some kind of syncronization channel between daemons, which currently
do not communicate with each other.

Anyway, thanks for your feedback, i will study your details.
Ciao!
Fabrizio