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 localhost or 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 host to localhost, you must then use localhost as the host for all other shards in the cluster.