multiple mongoDB on shared Mongo cluster

[eak]

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!


==Original message below=============================
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.

[Eliot Horowitz]

I think that will work - but why do many environments?
Most people generally use a smaller number (3) and make them all
highly available (multiple app servers, etc...)

> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>

[eak]

 
Hi Eliot!

We are building a new application and are building multiple environments, Development, Systems Integration Testing, QA, performance testing , etc.

It is an effort to build a set of infrastructure with a common purpose that can be shared across multiple environments that also gives us the ability, if required to quickly create an HA environment(s) to replicate issues if needed without having to spin up new additional virtual machines. Performance isn't a concern until we get to the performance testing and production environments. Production will obviously NOT be shared but we won't be regularly performing performance tests so building a large set of infrastructure for occaisional performance testing only to have it sit idle a majority of the time doesn't make sense.

Thanks!

Eric

[eak]

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