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
--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.