（2）Config Server：用来存储所有shard节点的配置信息、每个chunk的shard key范围、chunk在各shard的分布情况、该集群中所有DB和collection的sharding配置信息。
（3）Route Process：这是一个前端路由，客户端由此接入，然后询问Config Servers需要到哪个shard上查询或保存记录，再连接相应的shard进行操作，最后将结果返回给客户端，而这一切对客户端是透明的，客户端不用关心所操作的记录存储在哪个shard上。
为了测试方便，下面在同一台物理机器上构建一个简单的Sharding Cluster，如下图3所示。
图3 简单的Sharding Cluster架构图
配置测试环境如下：
模拟2个Shard服务器和1个Config服务器，均运行在本机127.0.0.1上，只是端口不同：
（1）Shard Server1：127.0.0.1：27020。
（2）Shard Server2：127.0.0.1：27021。
（3）Config Server：127.0.0.1：27022。
（4）Route Process：127.0.0.1：27017。
启动相关服务进程：
c:\mongodb 2.0.0\bin>mongod --shardsvr --dbpath "c:\mongodb 2.0.0\db" --port 27020
d:\mongodb 2.0.0\bin>mongod --shardsvr --dbpath "d:\mongodb 2.0.0\db" --port 27021
e:\mongodb 2.0.0\bin>mongod --configsvr --dbpath "e:\mongodb 2.0.0\db" --port 27022
e:\mongodb 2.0.0\bin>mongos --configdb 127.0.0.1:27022
配置Sharding：
(1)e:\mongodb 2.0.0\bin>mongo
(2)use admin
(3)db.runCommand( { addshard : "127.0.0.1:27020", allowLocal : 1,
maxSize:2 , minKey:1, maxKey:10 } )
(4)db.runCommand( { addshard : "127.0.0.1:27021", allowLocal : 1, minKey:100 } )
(5)config =connect("127.0.0.1:27022")
(6)config = config.getSisterDB("config")
(7)ecDocs=db.getSisterDB("ecDocs")
(8)db.runCommand({enablesharding:"ecDocs"})
(9)db.runCommand( { shardcollection : "ecDocs.filedocs.chunks", key : { files_id : 1 } } )
(10)db.runCommand( { shardcollection : "ecDocs.filedocs.files", key : { _id : 1 } } )
以上的ecDocs是指数据库名，filedocs是指用户自定义的GridFS的文件集合名，系统默认文件集合名为fs。
使用官方提供的C#驱动,需要在程序中引用MongoDB.Driver.dllMongoDB.Bson.dll，循环添加同一文件到GridFS示例代码，如下图4所示。
图4 循环添加同一文件到GridFS代码
测试配置环境如下：
操作系统：WindowsXP专业版32位SP3。
处理器(CPU)：英特尔Xeon(至强)W3503@2.40GHz。
内存：3567MB(DDR31333MHz/FLASH)。
硬盘：希捷ST3250318AS(250GB/7200转/分)。
由于本机是32位操作系统，因此单个服务实例只支持GridFS的文件容量大小为0.9G左右，由于采用了两台Shard服务实例，可以支持存储的文件总容量大小为1.8G左右，如果是64位操作系统就没有此限制。
本文主要测试GridFS采用循环插入大容量文件的性能和分片容量大小,测试结果，如下图5所示。