Skip to content
Branch: master
Find file History
Pull request Compare This branch is 522 commits behind Azure:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
nested
scripts
README.md
azuredeploy.json
azuredeploy.parameters.json
metadata.json

README.md

Install MongoDB Sharding Cluster

This template deploys a MongoDB Sharding Cluster on CentOS. It deploys 2 router servers, one config server replica set with 3 nodes, and 2 shards which both are replica set with 3 nodes. So it totally deploys 11 nodes.

The 2 router server nodes are exposed on public IP addresses that you can access through SSH on the standard port, also mongodb port 27017 open. You can access any one of them for MongoDB data write and read. If one router server is down, you can still access the other one.

The config server replica set stores sharding cluster metadata. MongoDB suggests to use a replica set for the metadata store in the production environment, in case one of the config server is down, there will still be other 2 config server nodes offer the service.

2 shards each is a 3 node replica set. You can shard the data on the two replica sets. You can also add more replica sets into the sharding cluster.

The nodes are under the same subnet 10.0.0.0/24. Except the 2 router server nodes, the other nodes only have private IP address.

This template also allows you to input your existing zabbix server IP address to monitor these MongoDB router servers.

##Important Notice Each VM of the shard uses raid0 to improve performance. The number and the size of data disks(setup raid0) on each shard VM are determined by yourself. However, there is number and size of data disks limit per the VM size. Before you set number and size of data disks, please refer to the link https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-sizes/ for the correct choice.

##After deployment, you can do below to verify if the sharding cluster really works or not:

  1. SSH connect to one of the router server, execute below:
$mongo -u "<mongouser>" -p "<mongopassword>" "admin"

db.runCommand( { listshards : 1 } )

exit

Upper db.runCommand( { listshards : 1 } ) command will show the sharding cluster details.

  1. You can "shard" any database and collections you want. SSH connect to one of the router server, execute below:
$mongo -u "<mongouser>" -p "<mongopassword>" "admin"

db.runCommand({enableSharding: "<database>" })

sh.status()

sh.shardCollection("<database>.<collection>", shard-key-pattern)

exit
  1. You can add more shards into this sharding cluster. SSH connect to one of the router server, execute below:
$mongo -u "<mongouser>" -p "<mongopassword>" "admin"

sh.addShard("<replica set name>/<primary ip>:27017")   

exit

Before adding your own replica set into the sharding cluster, you should enable internal authentication in your replica set first, and make sure the replica set is accessiable through this sharding cluster.

##Known Limitations

  • The MongoDB version is 3.2.
  • We expose 2 router server nodes on public addresses so that you can access MongoDB service through internet directly.
  • This cluster only has 2 shards, you can add more shards after the deployment.
  • The nodes use internal authentication. So if you want to add your own replica set into this sharding cluster, you should enable the internal authentication in your replica set first. Check any node /etc/mongokeyfile for more details.
  • The replica set is composed with 1 primary node, 2 secondary nodes.
  • More MongoDB usage details please visit MongoDB website https://www.mongodb.org/ .
You can’t perform that action at this time.