Deploy a Sharded Cluster¶
This tutorial involves creating a new sharded cluster that consists of a
mongos, the config server replica set, and two shard replica sets.
Each member of a sharded cluster must be able to connect to all other members in the cluster. This includes all shards and config servers. Ensure that network and security systems, including all interface and firewalls, allow these connections.
CloudManager and OpsManager¶
If you are currently using or are planning to use Cloud Manager or Ops Manager, consider using their built-in features for deploying a sharded cluster.
This tutorial does not include the required steps for configuring Internal Authentication or Role-Based Access Control. See Deploy Sharded Cluster with Keyfile Access Control for a tutorial on deploying a sharded cluster with a keyfile.
In production environments, sharded clusters should employ at minimum x.509 security for internal authentication and client access.
For details on using x.509 for internal authentication, see Use x.509 Certificate for Membership Authentication.
For details on using x.509 for client authentication, see Use x.509 Certificates to Authenticate Clients.
Enabling internal authentication also enables Role-Based Access Control.
If you use either
127.0.0.1 as the hostname portion of
any host identifier, you must use that identifier as the host setting
for any other MongoDB component in the cluster.
For example, the
sh.addShard() method takes a
host parameter for
the hostname of the target shard. If you set
must then use
localhost as the host for all other shards in the cluster.