4

We want to create a MongoDB shard (v. 2.4). The official documentation recommends to have 3 config servers.

However, the policies of our company won't allow us to get 3 extra servers for this purpose. Since we have already 3 application servers (1 web node, 2 process nodes) we are considering to put the configuration servers in the same application servers, with the mongos. Availability is not critical for us.

What do you think about this configuration? Can we face some problem or is it discouraged for some reason?

Thang Pham
  • 71
  • 3
Pablo Torrecilla
  • 77
  • 1
  • 11
  • 1
    What is the reason of using such old version of mongoDB? – user1700494 Feb 24 '16 at 13:31
  • @user1700494 we want to keep that version for the moment since it's a part of our standard stack. However, with the new MongoDB version we will face a similar problem: the config servers should be configured as a replica set, so we will still need extra nodes for them (unless we use only a configuration node, which is not recommended) – Pablo Torrecilla Feb 24 '16 at 14:37

1 Answers1

5

The term "server" is unfortunately overloaded in this context: it may refer to either the config server daemon process or a physical/virtual server.

For a production sharded cluster running MongoDB 2.4, you should definitely have three config server processes (i.e. mongod --configsvr). There is no strict requirement for these processes to be separately hosted, so you can potentially colocate config server mongod processes within your existing server environments to save on hosting costs.

Config servers are generally reasonably lightweight in terms of storage and CPU/memory usage, as the metadata for a sharded cluster is significantly smaller than the actual cluster data. If you do choose to colocate the config servers, mongos will be a much better neighbour than data-bearing mongod shard servers.

Some key considerations when colocating sharded cluster components include:

  • Resilience: a single server/instance failure can now cause multiple components to be unavailable.

  • Resource usage: multiple components will be competing for the same resources (RAM, CPU, I/O, ...).

  • Future scaling: you should use CNAMEs for the config servers to allow them to potentially be moved to separate hosts in future without downtime.

You will also find that the first config server listed in your mongos --configdb string will receive a larger percentage of network traffic than the other two config servers. This may influence whether you colocate the first config server with your web node or a processing node; you probably want to choose whichever currently has more available network bandwidth.

Stennie
  • 1,250
  • 7
  • 12