Targeted Routing Deployment

16 Jun 2014

In out last post we uncovered a new model that enables the driver to more intelligently routing requests to mongos processes but that model requires us to use a new deployment architecture.

MongoDB Deployment Model

To enable targeted routing we need to modify the normal deployment model. In all enterprise scale deployments we have to be concerned with the placement of:

• The mongod processes for each node within the replica set.
• The three mongod processed for the configuration (config) servers.
• The 1 to N mongos processes that will be used by application to connect to the cluster.

Lets start with what a typical sharded deployment with replica sets might look like.

Typical Sharded Replica Set Deployment

In a typical sharded cluster of replica sets each replica set has two or more data holding nodes and potentially a single arbiter node for breaking ties. Each of the data nodes will be on a different server for fault tollerance.

The configuration server will also be placed on different servers and, for smaller deployments, may be corresident with a mongod process for a shard’s replica set. We often recommend placing the configuration servers with the arbiters since neither process normally requires many resources.

The mongos processes are placed on the same Machines as t he applications. All of the applications are then configured to connect to the mongos on the local machine.

Targeted Routing Deployment

For a application that will be using the targeted routing we want to make a few changes to the deployment. These are all driven but the following factors:

1. The driver is trying to send requests to a mongos that is as close to the target shard’s mongod as possible. The only way the driver can currently determine the proximity of a mongos to a mongod is, currently, to use hostnames.
2. There is still value in sending all non-targeted requests to a local mongos to minimize the first connections latency.

With those factors in mind the deployment requires that we have a mongos process on all of the servers hosting a mongod holding data and also the application servers. We do not need to deploy a mongos onto the configuration servers since the driver will read the routing information from the config database through any of the mongos servers.

Enabling Routing in the Driver

Note: This post is acurate as of the time of this writing. For the most up-to-date information on enabling routing in the driver refer to the documention on the driver’s website.

By default the extensions will not automatically enable the use of the advanced routing in sharded environments. Users must enable the specific type of routing they want to use.

• The default mode is provided by the core driver and has the driver connect to the closest mongos. As the default mode it requires no additional configuration.
• The targeted mode enables the driver to look for a mongos on the same server as the driver has determined will be used by the mongos to service the request. In the cases the driver cannot determine the appropriate shard server then the driver will fall-back to using the closest mongos it can find.

To enable targeted mode simply set either the system property mongodb.shard.connection.mode or the environment variable MONGODB_SHARDING_MODE to targeted. The comparison is case-insensitive and any other value will revert the connection to the default mode.

In our next post we get a peak at the performance improvements we can see with targeted routing.