Chunk 的大小是关键的设计参数之一。我们选择了 64MB,这个尺寸远远大于一般文件系
统的 Block size。每个 Chunk 的副本都以普通 Linux 文件的形式保存在 Chunk 服务器上,
只有在需要的时候才扩大。惰性空间分配策略避免了因内部碎片造成 的空间浪费,内部碎
片或许是对选择这么大的 Chunk 尺寸最具争议一点。
选择较大的 Chunk 尺寸有几个重要的优点。首先,它减少了客户端和 Master 节点通讯的
需求,因为只需要一次和 Mater 节点的通信就可以 获取 Chunk 的位置信息,之后就可以对
同一个 Chunk 进行多次的读写操作。这种方式对降低我们的工作负载来说效果显著,因为
我们的应用程序通常是连续 读写大文件。即使是小规模的随机读取,采用较大的 Chunk
尺寸也带来明显的好处,客户端可以轻松的缓存一个数 TB 的工作数据集所有的 Chunk 位
置信 息。其次,采用较大的 Chunk 尺寸,客户端能够对一个块进行多次操作,这样就可
以通过与 Chunk 服务器保持较长时间的 TCP 连接来减少网络负载。第 三,选用较大的
Chunk 尺寸减少了 Master 节点需要保存的元数据的数量。这就允许我们把元数据全部放在
内存中,在 2.6.1 节我们会讨论元数据全部 放在内存中带来的额外的好处。
另一方面,即使配合惰性空间分配,采用较大的 Chunk 尺寸也有其缺陷。小文件包含较少
的 Chunk,甚至只有一个 Chunk。当有许多的客户 端对同一个小文件进行多次的访问时,
存储这些 Chunk 的 Chunk 服务器就会变成热点。在实际应用中,由于我们的程序通常是
连续的读取包含多个 Chunk 的大文件,热点还不是主要的问题。
然而,当我们第一次把 GFS 用于批处理队列系统的时候,热点的问题还是产生了:一个可
执行文件在 GFS 上保存为 single-chunk 文件, 之后这个可执行文件在数百台机器上同时
启动。存放这个可执行文件的几个 Chunk 服务器被数百个客户端的并发请求访问导致系统
局部过载。我们通过使用更大 的复制参数来保存可执行文件,以及错开批处理队列系统程
序的启动时间的方法解决了这个问题。一个可能的长效解决方案是,在这种的情况下,允
许客户端从其它 客户端读取数据。
2.6 元数据
Master 服务器 (alex 注:注意逻辑的 Master 节点和物理的 Master 服务器的区别。后续
我们谈的是每个 Master 服务器的行为,如存储、内存等等,因此我们将全部使用物理名
称)存 储 3 种主要类型的元数据,包括:文件和 Chunk 的命名空间、文件和 Chunk 的对
应关系、每个 Chunk 副本的存放地点。所有的元数据都保存在 Master 服务器的内存中。
前两种类型的元数据(命名空间、文件和 Chunk 的对应关系)同时也会以记录变更日志的
方式记录在操作系统的系统日志文件 中,日志文件存储在本地磁盘上,同时日志会被复制
到其它的远程 Master 服务器上。采用保存变更日志的方式,我们能够简单可靠的更新
Master 服务器 的状态,并且不用担心 Master 服务器崩溃导致数据不一致的风险。Master
服务器不会持久保存 Chunk 位置信息。Master 服务器在启动时,或 者有新的 Chunk 服务
器加入时,向各个 Chunk 服务器轮询它们所存储的 Chunk 的信息。
2.6.1 内存中的数据结构
因为元数据保存在内存中,所以 Master 服务器的操作速度非常快。并且,Master 服务器
可以在后台简单而高效的周期性扫描自己保存的全部 状态信息。这种周期性的状态扫描也
用于实现 Chunk 垃圾收集、在 Chunk 服务器失效的时重新复制数据、通过 Chunk 的迁移
实现跨 Chunk 服务器的 负载均衡以及磁盘使用状况统计等功能。4.3 和 4.4 章节将深入讨
论这些行为。
评论0
最新资源