multiple mongodb instances on a single server

[eak]

We are building a number of pre-production environments to support the
development process for a new application. We are considering taking 3
servers each running config-svr, mongos and mongod and configuring a
multi-node instance for each pre-production environment (development,
system integration, user acceptance, performance testing, etc).

What kinds of challenges, road blocks, issues would be ahead of us if
we want to try and have multiple, seperate database instances for
different applications running on a shared set of mongo database
servers?

Thank you!

EAK

[Adam C]

Can you elaborate a little in terms of the set up you intend to have for each environment?

Some pointers:

• Is virtualization an option to help with partitioning of resources?
  
• Do you need to test sharding for every environment, or would a replica set be sufficient?
• Could you run a single mongod cluster, but just have different databases and collections instead of separate instances?

As general advice, if your application servers have more spare resources than your DB servers, think about having the mongos processes on the application servers, That at least removes some small burden from the DB hosts.

If this is truly a non-production environment, and you can live with a complete loss, then you can also cut down on the config server requirement by running just one.  It has to be configDB x 1 or configDB x 3 - but whatever you do, always run 3 if the shard is in any way precious/valuable/hard to recreate, for production *always* use 3.

If I assume that the answers to my questions above are: No, no virtualization possible, yes we want to use sharding everywhere because that is the intended production environment, and yes we can run with different DBs, separate instances are not required, then a recommended set up given 3 physical hosts would look like this:

To simulate a full sharded environment you will likely want to go with a replica set for each shard (the minimum for functional testing is 1 primary per shard, but that is not representative of a production environment).  The minimum for a replica set (that functions correctly) is 1 x Primary, 1 x Secondary and 1 x Arbiter (to avoid non-majority issues if one of the primaries is lost).  The arbiters are generally light-weight, the secondaries next, with the primaries having the heaviest load.  So, you could do something like this with just 3 actual machines:

host 1: Primary(shard1); Arbiter(shard2);

host 2: Primary(shard2); Arbiter(shard1);

host 3: Secondary(shard1); Secondary(shard2); ConfigDB

host 3 would also be the candidate for a mongos process if not running on your app servers.  This leaves the primaries largely unimpeded by other processes, gives you a decent approximation of a production environment and (as long as nothing fails) should not overload a single host.

Adam.

[eak]

I accidentally posted this as a new thread.

Hi!

We are trying to build a "shared cluster" of Mongo servers. Given
something like this:

Environment1                  Environment2             Environment3
Appserver1                       AppServer2                 Appserver3
mongos                            mongos                       mongos
config-svr                          config-svr                    config-svr

We will have a mongos and a configserver for each individual
environment.
We will have a shared cluster of mongo servers.

host 1: Primary(shard1);Primary(shard4);Primary(shard7))

host 2: Primary(shard2);Primary(shard5);Secondary(shard7);Arbiter(shard7);
host 3: Primary(shard3);Primary(shard6);Secondary(shard7);Arbiter(shard7);

The intent is to start with 3 environments, then grow to 6 environments, none of which will have high availability. They are just
small pre-production environments to use for multiple projects. Environment 4-6 will look just like 1-3.

Then add a 7th environment that will be very close to production state with high availability with a Shard with Replicas. Environment 7 will
look like 1-3 but will all be running the same app and sharing an HA shard/replica DB instance across all 3 nodes of the cluster.

Does this make sense? Is it possible? What problems will we have trying to manage and maintain it?

Thank you!

[Adam C]

There seems to be some confusion between "Shard" and "Environment" in the example you give.

There are 7 shards listed below, which implies that all 7 are part of one environment.  That is a very large number of shards if you are just looking to test - is that intentional?

Or, do you mean for each environment to have (for example), 2 shards each?

Env1 = Shard1, Shard2, ConfigDB, mongos

Env2 = Shard3, Shard4, ConfigDB, mongos

Env3 = Shard5, Shard6, ConfigDB, mongos

In any case, I would not recommend running so many primaries on a single host, unless you are using VMs and can properly segregate resources.  The potential for problems are many and varied - it would not be a very valid test, and the first advice if you did run into problems would be to drop the number of mongod instances on the host.

Additionally you are not using replication until you get to Shard7.  Not only does that mean you are not seeing the performance impact that replication might have (it's a must for a production deployment), it also means that the likelihood of a shard dying in a non-recoverable way is greatly increased.

Adam

[eak]

The intent is to have 7 seperate environments. Every environment (1-6) are single no, single point of failure. Environment 7 is multi-node HA with replicas.

This type of configuration is "normally acceptable" within any rdbms cluster. My assumption was that something similar should be possible with a mongo cluster, leveraging a single set of deployed servers for multiple pre-production environments.

Is this not the case? I know it is possible with Oracle's nosql server.

Thank you!

Eric

[eak]

https://groups.google.com/d/topic/mongodb-user/JpSgJkKi3tY/discussion

On Friday, March 16, 2012 10:35:40 AM UTC-4, eak wrote:

[Adam C]

I'm not saying it won't work - there is nothing to stop you from deploying this way, but performance will be essentially meaningless with so much potential for resource contention.  If all you want to do is prove functionality, then fine, but if you plan on using this for any kind of benchmarking, resource forecasting etc. it's not going to be relevant.  Hence I was making a recommendation for a less intensive deployment.

Adam