[tor-dev] [Question to sysadmins and HS operators:] How should Hidden Services scale?

[George Kadianakis]

Also forwarding George's message. The original thread had a wrong address
for tor-dev, and all their messages are not posted in tor-dev...

George Kargiotakis said:
> On Fri, 20 Dec 2013 11:58:27 -0500
> andrew at torproject.org wrote:
>
> > On Fri, Dec 20, 2013 at 03:08:01AM -0800, desnacked at riseup.net wrote
> > 1.7K bytes in 0 lines about: : For this reason we started wondering
> > whether DNS-round-robin-like : scalability is actually worth such
> > trouble. AFAIK most big websites : use DNS round-robin, but is it
> > necessary? What about application-layer : solutions like HAProxy? Do
> > application-layer load balancing solutions : exist for other
> > (stateful) protocols (IRC, XMPP, etc.)?
> >
> > In my experience in running large websites and services, we didn't use
> > DNS round-robin. If large sites do it themselves, versus outsourcing
> > it to a content delivery network, they look into anycast, geoip-based
> > proxy servers, or load balancing proxy servers (3DNS/BigIP,
> > NetScalar, etc) DNS round-robin is for smaller websites which want to
> > simply spread the load across redundant servers--this is what tor
> > does now.
> >
> > If scaling hidden services is going to be a large challenge and
> > consume a lot of time, it sounds like making HS work more reliably
> > and with stronger crypto is a better return on effort. The simple
> > answer for scaling has been to copy around the private/public keys
> > and host the same HS descriptors on multiple machines. I'm not sure
> > we have seen a popular enough hidden service to warrant the need for
> > massive scaling now.
> >
> > Maybe changing HAProxy to support .onion links is a fine option too.
> >
>
> Hello all,
>
> >> For a while we've been told that "hidden services don't scale" and
> >> "there is a max number of clients that a hidden service can handle"
> >> so we decided to also consider hidden service scalability as part of
> >> the upcoming redesign. Unfortunately, we are not experienced in
> >> maintaining busy hidden services so we need some help here.
>
> to solve a problem you need to strictly define it first. Where exactly
> is the bottleneck here ? I've never run a .onion that "couldn't scale"
> because of many clients visiting, so I don't have a first hand
> experience with such issues. If it's because it's slow to open many
> connections to hidden services then imho simply adding an .onion-aware
> HAProxy/varnish won't solve these problems in the long run. There will
> be a time where one HAProxy/varnish won't be enough and it will always
> be a SPOF.
>
> Most big websites do geoip (to distribute the load between DCs in
> different regions), then they do something like HAProxy/LVS to
> spread the load across multiple workers in the same DC, and of course
> they put static files on CDNs.
>
> Each of the above serves quite a different purpose. Reducing latency
> through geoip, load-balancing and graceful fail-over with LVS/HAProxy
> and CDNs are doing both at the same time but for different types of
> requests.
>
> Since geoip does not make sense in the Tor world, maybe making
> multiple hosts advertise the same .onion address at the same time in
> the database would make some sense. If that were true, people could also
> implement .onion CDN services. I'm not so sure what can be done for an
> LVS-like setup in the Tor world though.
>
> I hope this helps a tiny bit.
>
> Regards,
> --
> George Kargiotakis
> https://void.gr
> GPG KeyID: 0x897C03177011E02C