Page MenuHomeMiraheze

Deploy Apache Traffic Server
Closed, DeclinedPublic

Description

The Wikimedia Foundation have replaced the varnish backend with Apache Traffic Server. We should have a look at Apache Traffic Server to see if it would benefit us performance wise (and to see if we could get rid of the need for stunnel).

The Wikimedia Foundation still use varnish for the frontend though but we wouldn't do that if we were to switch.

Apache Traffic Server is also proven to be very performant.

Below we have a checklist of things to do before this task is resolved:

  • Request a vm T7037
  • Deploy vm
  • Puppitise a basic apache traffic server module. Basic being a workable module. Wikimedia have a good module we can reuse https://github.com/wikimedia/puppet/tree/production/modules/trafficserver.
  • Apply our varnish stuff to ATS
  • Security Review (@Southparkfan)
  • Create a custom healthchecker. (Because of the limitations in ats we have to create our own healthchecker that depools.)
  • Performance review. Compare Varnish and ATS performance data.

Event Timeline

Which benefits do you expect?

SSL termination firstly so less layers for traffic to travel.

Paladox triaged this task as Normal priority.Apr 19 2019, 18:59

Bookmarking https://github.com/shukitchan/ats_lua_scripts/blob/master/cache_tags.lua (will need to see if that will be useful for us and also ask what the license of the file is).

John lowered the priority of this task from Normal to Low.May 7 2019, 23:47
Joaquinito01-GMX claimed this task.
This comment was removed by Paladox.

Reopening after not realising a troll closed it.

Plan would be:

Setup varnish and apache traffic server on test3 and try to measure performance.

Paladox renamed this task from Experiment with Apache Traffic Server to Deploy Apache Traffic Server.Mar 25 2021, 22:20
Paladox updated the task description. (Show Details)
Universal_Omega raised the priority of this task from Low to Normal.Mar 26 2021, 16:08

In order to do proper backend verification in the certificate (CN), we have tested using ENFORCE. However, the Host header from the client (e.g. allthetropes.org) is used for the CN check at the backend. Therefore, the allthetropes.org certificate would still be mandatory at the backend, even though I prefer to remove all certificates (including our wildcard one) but a single domain (such as ats-internal.miraheze.wiki) from the MediaWiki servers.

Remapping (remap.config) the internal hostname to ats-internal.miraheze.wiki is possible (Wikimedia does this for appservers-rw.discovery.wmnet), but only works if DNS load balancing is used, e.g. bypassing our DNS cache.

As of ATS 9.1.x, we can decide on our own which hostname to use, e.g. ats-internal-miraheze.wiki. However, Debian 10 and 11 only come with a version of ATS 8.x.x. Compiling a newer version is theoretically possible, but apparently 9.0.x is the latest version, even though 9.1.x should have been released in January 2021.

Paladox updated the task description. (Show Details)

Discussed; handing over some of the tasks to me (see subtasks), we won't delay this.

John added a subscriber: Paladox.

Spoken with @Paladox, he still wishes to pursue this.

He is going to continue testing and get the config to be a similar level as of Varnish. This is also being goaled for this half.

John moved this task from Long Term to Goals on the Infrastructure (SRE) board.
John moved this task from Backlog to Infrastructure on the Goal-2021-Jul-Dec board.

I'll be declining this for now - don't have too much of a benefit to pursue this.