<html><head></head><body><div class="ydpdca200f0yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div><div>Hi Roger,</div><div><br></div><div>I've found the secret to effectively loadbalancing Tor Relay Nodes is as follows:</div><div><br></div><div>1. Use the same version of Tor on all Upstream Servers</div><div><br></div><div>2. Start/Stop all Upstream Tor Nodes at the same time to keep in sync</div><div><br></div><div>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</div><div><br></div><div>4. Configure Upstream Tor Nodes to deliver return packets to the Loadbalancer</div><div><br></div><div>5. Configure all Upstream Tor Nodes to use the same DirAuthority and FallbackDir (This is how centralization of statistics is addressed)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Please provide your email address and I'll be happy to message you directly with the name of my Tor Meta Relay.</div><div><br></div><div>Respectfully,</div><div><br></div><div><br></div><div>Gary</div><div class="ydpdca200f0signature">—<br>This Message Originated by the Sun.<br>iBigBlue 63W Solar Array (~12 Hour Charge)<br>+ 2 x Charmast 26800mAh Power Banks<br>= iPhone XS Max 512GB (~2 Weeks Charged)</div></div>
<div><br></div><div><br></div>
<div id="ydpdca200f0yahoo_quoted_0051889501" class="ydpdca200f0yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Tuesday, December 14, 2021, 3:39:44 AM PST, Roger Dingledine <arma@torproject.org> wrote:
</div>
<div><br></div>
<div><br></div>
<div>On Sun, Dec 12, 2021 at 03:42:12PM +0000, Gary C. New via tor-relays wrote:<br clear="none">> I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always interested in knowledge sharing related to Tor Loadbalancing.<br clear="none">> 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?<br clear="none"><br clear="none">Hi Gary,<br clear="none"><br clear="none">One of the big downsides to trying to create one "meta" relay out of<br clear="none">many independent relays is that each independent relay will make and<br clear="none">maintain its own TLS connections with other relays.<br clear="none"><br clear="none">So while running a fast Tor relay the normal way might end up with<br clear="none">roughly one connection to each other relay in the network (which could<br clear="none">already be many thousands of connections), doing it the way you describe<br clear="none">could result in many times that number of open connections. And even<br clear="none">if your local router and systems can handle that many open connections,<br clear="none">you're increasing the load on every other relay by forcing them to handle<br clear="none">more connections.<br clear="none"><br clear="none">There will also be more bandwidth use, since each separate TLS connection<br clear="none">will use its own keepalive packets to try to stay connected in the<br clear="none">face of firewall and NAT timeouts, and also to try to foil rudimentary<br clear="none">netflow-based traffic analysis attacks. And because circuits are spread<br clear="none">out over many TLS connections, they won't get the privacy protections<br clear="none">from being all bundled on a single TLS connection, i.e. a network observer<br clear="none">will have an easier time distinguishing which circuit a given cell is for.<br clear="none"><br clear="none">Which relays are you running in this way? How do you aggregate all of<br clear="none">the statistics/etc into a central Tor that publishes a unified relay<br clear="none">descriptor? I would expect your meta-relay to have some kind of bizarre<br clear="none">breakage, so we should check it out and see if that's true in practice.<br clear="none"><br clear="none">Thanks,<br clear="none">--Roger<div class="ydpdca200f0yqt5099361755" id="ydpdca200f0yqtfd51664"><br clear="none"><br clear="none">_______________________________________________<br clear="none">tor-relays mailing list<br clear="none"><a shape="rect" href="mailto:tor-relays@lists.torproject.org" rel="nofollow" target="_blank">tor-relays@lists.torproject.org</a><br clear="none"><a shape="rect" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="nofollow" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br clear="none"></div></div>
</div>
</div></div></body></html>