Change Details

**What?** 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 **Onhost memached** 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 or a UNIX socker) ** * 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 kubernetes, on the node** * Prons: reduces complexity, we already have everything setup in puppet, easy rollout, easy to test in producyion * Cons: if the service fails, all pods in the node are left without access to the memcached main cluster (almost unusuable)

**What?** 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 **Onhost memached** 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 kubernetes, on the node** * Prons: reduces complexity, we already have everything setup in puppet, easy rollout, easy to test in producyion * Cons: if the service fails, all pods in the node are left without access to the memcached main cluster (almost unusuable)

**What?** 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 **Onhost memached** 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 sockert) ** * 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 kubernetes, on the node** * Prons: reduces complexity, we already have everything setup in puppet, easy rollout, easy to test in producyion * Cons: if the service fails, all pods in the node are left without access to the memcached main cluster (almost unusuable)