Hi Roger, I've found the secret to effectively loadbalancing Tor Relay Nodes is as follows: 1. Use the same version of Tor on all Upstream Servers 2. Start/Stop all Upstream Tor Nodes at the same time to keep in sync 3. Loadbalance using IP Transparency Mode (This was discovered while tirelessly combing through mountains of Tor debug logs) and use Sticky Sessions based on Source IP Addresses 4. Configure Upstream Tor Nodes to deliver return packets to the Loadbalancer 5. Configure all Upstream Tor Nodes to use the same DirAuthority and FallbackDir (This is how centralization of statistics is addressed) This configuration has been working well for the past six months. The only dow downsides that I've seen are if an Upstream Tor Node goes down, I have to leave it down or restart all the Upstream Tor Nodes to keep in sync. Occasionally, if a medium-term key is updated, I can see circuits migrate to a single Upstream Tor Node; however, that can be easily discerned and addressed by reviewing centralized syslogs and copying the updated .tordb directory to the other Upstream Tor Nodes with a synced restart. In terms of metrics, the written/read bytes per second is only reported for a single Upstream Tor Node, but that's not a big deal. It would be helpful if metrics were pulled remotely instead pushed. Please provide your email address and I'll be happy to message you directly with the name of my Tor Meta Relay. Respectfully,
Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)
On Tuesday, December 14, 2021, 3:39:44 AM PST, Roger Dingledine arma@torproject.org wrote:
On Sun, Dec 12, 2021 at 03:42:12PM +0000, Gary C. New via tor-relays wrote:
I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always interested in knowledge sharing related to Tor Loadbalancing. What are your thoughts on the Pros & Cons of dedicating resources to a Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor Operator? Perhaps, a Hybrid approach?
Hi Gary,
One of the big downsides to trying to create one "meta" relay out of many independent relays is that each independent relay will make and maintain its own TLS connections with other relays.
So while running a fast Tor relay the normal way might end up with roughly one connection to each other relay in the network (which could already be many thousands of connections), doing it the way you describe could result in many times that number of open connections. And even if your local router and systems can handle that many open connections, you're increasing the load on every other relay by forcing them to handle more connections.
There will also be more bandwidth use, since each separate TLS connection will use its own keepalive packets to try to stay connected in the face of firewall and NAT timeouts, and also to try to foil rudimentary netflow-based traffic analysis attacks. And because circuits are spread out over many TLS connections, they won't get the privacy protections from being all bundled on a single TLS connection, i.e. a network observer will have an easier time distinguishing which circuit a given cell is for.
Which relays are you running in this way? How do you aggregate all of the statistics/etc into a central Tor that publishes a unified relay descriptor? I would expect your meta-relay to have some kind of bizarre breakage, so we should check it out and see if that's true in practice.
Thanks, --Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays