The google file system--测量(二)

现实中的集群

1.存储

正如表(1)中前五个条目显示的，这两个集群都有数百个块服务器，提供数TB的硬盘空间，都已存储一定0的数据。“已用空间”部分包括所有的块副本。几乎所有的文件都被复制三次。它们分别存储了18TB和52TB的文件数据。

这两个集群有类似数量的文件，虽然集群B有大量的死文件、已经删除或者被新版本替换的文件，但是其存储空间仍旧没被回收。相比A而言，它有更多的块，因为它的文件更大。

表1 GFS的集群特性

 

2.元数据

所有块服务器一共保存了数十GB的元数据，大多数是有关用户数据的64KB的校验和。另外保存在块服务器仅有的元数据是块版本号。

保存在主服务器的元数据更小，只有数十MB，平均每个文件100个字节。这验证了我们的论断，那就是在实际中主服务器的内存大小并不是局限系统能力的主要因素。每个文件元数据最大的成分是以前缀压缩形式保存的文件名。元数据的其他部分包括，文件的拥有者和权限，文件到块的映射，每个块的当前版本。另外，我们保存每个块的当前副本位置，以及一个用来实现copy-on-write技术的引用计数。

每个单独的服务器，不管块服务器还是主服务器，都只有50到100MB的元数据。所以即便出席那问题也会恢复的很快：在服务器可以回复请求之前，只需要几秒钟去从硬盘读取这些元数据即可。然而，服务器可能会有片刻的不稳定--通常是30-60秒--直到它从所有块服务器获得块位置信息。

3.读写速度

表2展示不同时间阶段的读写速度。在测量之前，两个集群都运行了一个星期以上。

在重启后，系统平均写入速度低于30MB/s。进行测试时，集群B正处于100MB/s写数据高峰，并产生了300MB/s的网络负担，因为写入的数据要传送到三个副本。

读取速度要比写入速度高许多。正像我们预期的那样，总的负载中包括的读取比写入要多。两个集群都处在繁重的读取操作中。实际上，在之前的一个星期，集群A都保持了580MB/s的读取速度，其网络设置可以支持750MB/s的读写速度，所以它的资源使用效率很高。集群B可以支持1300MB/s的峰值读取速度，但是它的程序只使用了380MB/s。

表2 GFS集群性能对比

4. 主服务器负载

表2显示了发送志主服务器操作的速度大概是每秒钟200到500个。主服务器可以轻松的保持这个速度，所以这不算是负载中的瓶颈。

在早期版本的GFS中，主服务器偶尔会成为负载中的瓶颈。它可能花费大量的时间顺序扫描大目录（包含数万个文件）寻找某个特定的文件。由此我们改变了主服务器数据结构以提高名称空间二分搜索的效率。这样的话，现在可以轻松的支持每秒钟数千次文件访问。如果需要，我们可以通过在名称空间数据结构之前设置名称查询缓冲机制进一步提高速度。

5. 恢复时间

一个块服务器失效后，有些块的副本数量可能过低，必须进行副本克隆以恢复它们的复制水平。恢复所有这样的块需要的时间取决于资源的总量。在我们的实验中，我们关闭集群B里面的一台块服务器。这个块服务器有15000个块，包含600GB的数据。为了限制对正在运行的程序的干扰，并为一些定期任务的执行提供余地，我们的默认参数将限制集群中最多有91个并行的克隆操作（块服务器数量的40%），每个克隆操作的速度可以是6.25MB/s（50Mbps）。所有的块会将以440MB/s的复制速度在23.2分钟内恢复。

在另外的试验中，我们关闭两个块服务器，每个大概有16000个块和660GB数据。这个双倍的失效，造成266个块只有一个副本。这266个块将被优先复制，在2分钟内所有块都会恢复到至少拥有两个副本，这样就使得集群可以容忍其他块服务器失效，而不会造成数据丢失。