Memcached is a crucial component in our Mediawiki installation. Right now MediaWiki interacts (via mcrouter) with two memcached instances.
- Onhost, an instance running in with in the same application server where specific keys are stored with a max TTL of 10s
- Main memcached cluster, a set of 18 servers per DC where mcrouter shards all keys.
Nutcracker is a component we would like to relieve of its duties. Nutcracker shards keys to a redis cluster that resides with in the memcached servers. Whatever solution we choose for mcrouter, makes sense to use for nutcracker too, if nutcracker is still around. T277183
It makes sense to have one onhost memcached instance running in each node where MediaWiki pods will run:
- either outside k8s, as a service running on a node
- as a daemonset
Where should mcrouter reside?
1) Run mcrouter as part of the mediawiki pod (via a TCP port or a UNIX socket)
- Prons: rollout will be similar to mediawiki
- Cons: harder to test changes in production (eg push a change o a single node and monitor), # of connections towards the memcached main cluster will multiply
2) Run mcrouter as daemonset
- prons: easy rollout
- cons: some unavailability might happen during rollout , if the damonset fails, all pods in the node are left without access to the memcached main cluster
3) Run mcrouter outside of kubernetes, on the node
- Prons: reduces complexity, we already have everything setup in puppet, easy rollout, easy to test changing in production, easy to control changes (by eg using feature flags in puppet)
- Cons: if the service fails, all pods in the node are left without access to the memcached main cluster (almost unusuable)