The minimum amount of servers for a production mongoDB cluster

The plus sides:

• you would be able to have concurrent writes, provided that the data was hashed to different shards. MongoDB locks the entire database on that instance when doing a write, so even a non-sharded replica set can only write one thing at a time
• it's a good way of learning sharding/replica sets/admin, but if you just want to do that you can achieve this with less instances
• replication would be very quick :)

The downsides:

• you would need a powerful machine (multiple CPUs but also as much memory as possible, and quick disks) to really benefit from the performance - Mongo craves RAM! For optimal performance your total index size should fit into RAM, which means if you have 2 gigs of index per shard, you would need 5 * 3 * 2 = 30 gigs of ram, plus the memory for the OS etc as well
• you may not benefit much from the slaveOK query option
• you would have no protection against hardware failure - if the box goes, all your shards and your replica sets go

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.