performance - Hardware for a sharded + redundant MongoDB-environment -

i'm trying plan new database-environment scratch , i'm wondering how many servers needed , how performance should provide.

since want fast, i'm considering using ssd-memory , loads of ram. however, flash-memory expensive , makes biggest part of cost of server. thus, entire system should set horizontal scaling start, can add more nodes when need more storage/performance.

to started i'm thinking of using 2 shards, each consisting of master , replica-slave redundancy. mongodb-documentation suggests using 1 master , 2 slaves, i'm afraid won't in available budget, since each of these servers equipped 200 gb of ram , 6x400 gb ssd raid 10.

when using shards, suggested using 3 config-servers failsafe/high-availability. same above, i'm thinking 1 master , 1 slave start.

• what sort of hardware recommend put config-servers on? should equally performant shard-nodes in terms of cpu/memory/harddisk? or can put them on virtualization or on cheaper hardware?
• does setup described make sense? how ratio of ram vs. harddisk on shard-nodes? @ moment easier , cheaper put twice number of discs 1 shard (1 master, 1 slave) , skip sharding until need it. (as mentioned above) - system should ready sharding beginning, because storage-needs can change overnight. or possible set up, have running on 1 shard now?
• since i'm planning use 2 instead of 3 servers high-availability/failsafe need arbiters well. need dedicated hardware well? or can use 1 arbiter in virtual-mashine serves config-servers , shard-nodes? or using 3 seperate servers redundancy absolute must in opinion?

rock on. sounds awesome setup. given configuration choices, not imagine budget limit choices much.

• you not need dedicated physical server config servers. these run lightly. need low latency between mongos , config servers. want make sure hosts reliable, , prepared disaster. ensure double check backup procedures sharded environment. backups require coordination among moving pieces of sharded cluster. if possible, run config servers on virtual servers in same datacenter.

• yes, hardware described makes sense if going run multiple shards on single machine. single mongodb on powerful machine leave machine idle. single mongod process cannot use ram, i/o, or cpu. want "core shard" host. @ mongohq, running each mongod in container, can isolate other instances on same machine. specifications, can run many 10 shards on single host, or more if want stretch hosts.

• you can start single shard , migrate sharded cluster later. our recommended approach sharding: don't shard until must. delaying sharding, increase flexibility make changes system. when sharding in place, have committed particular path, no flexibility (which okay when know future). delaying sharding, have no tradeoffs.

• the arbiters not need dedicated hardware. can run on virtual machines. these not require same level of backup requirements, should have uptimes.

• using 3 servers not requirement solid uptime. however, when 1 data host goes down few hours, relegated single data host. while relegated single data host, single host work fine. because have 1 second of data running, run higher risk of having outage. being said, 2 nodes plus arbiter okay use cases, , remain if 1 of data nodes fails.

hope helps! run similar configurations @ mongohq, , happy level of performance hosts.