2.3 Architecture
A GFS cluster consists of a single master and multiple chunkservers and is accessed by multiple clients, as shown in Figure 1. Each of these is typically a commodity Linux machine running a user-level server process. It is easy to run both a chunkserver and a client on the same machine, as long as machine resources permit and the lower reliability caused by running possibly flaky application code is acceptable.
Files are divided into fixed-size chunks. Each chunki s identified by an immutable and globally unique 64 bit chunk handle assigned by the master at the time of chunkcreat ion.Chunkservers store chunks on local disks as Linux files and read or write chunkda ta specified by a chunkha ndle and byte range. For reliability, each chunkis replicated on multiple chunkservers. By default, we store three replicas, though users can designate different replication levels for different regions of the file namespace.
The master maintains all file system metadata. This includes the namespace, access control information, the mapping from files to chunks, and the current locations of chunks.It also controls system-wide activities such as chunklease management, garbage collection of orphaned chunks, and chunkmigration between chunkservers. The master periodically communicates with each chunkserver in HeartBeat messages to give it instructions and collect its state.
GFS client code linked into each application implements the file system API and communicates with the master and chunkservers to read or write data on behalf of the application.Clients interact with the master for metadata operations,but all data-bearing communication goes directly to the chunkservers. We do not provide the POSIX API and
therefore need not hookin to the Linux vnode layer.
Neither the client nor the chunkserver caches file data.Client caches offer little benefit because most applications stream through huge files or have working sets too large to be cached. Not having them simplifies the client and the overall system by eliminating cache coherence issues.(Clients do cache metadata, however.) Chunkservers need not cache file data because chunks are stored as local files and so Linuxrsquo;s buffer cache already keeps frequently accessed data in memory.
2.4 Single Master
Having a single master vastly simplifies our design and enables the master to make sophisticated chunk placement and replication decisions using global knowledge. However we must minimize its involvement in reads and writes so that it does not become a bottleneck. Clients never read and write file data through the master. Instead, a client asks the master which chunkservers it should contact. It caches this information for a limited time and interacts with the chunkservers directly for many subsequent operations.
Let us explain the interactions for a simple read with reference to Figure 1. First, using the fixed chunks ize, the client translates the file name and byte offset specified by the application into a chunki ndex within the file. Then, it sends the master a request containing the file name and chunk index. The master replies with the corresponding chunk handle and locations of the replicas. The client caches this information using the file name and chunki ndex as the key.
The client then sends a request to one of the replicas,most likely the closest one. The request specifies the chunk handle and a byte range within that chunk. Further reads of the same chunkreq uire no more client-master interaction until the cached information expires or the file is reopened.In fact, the client typically asks for multiple chunks in the same request and the master can also include the information for chunks immediately following those requested. This extra information sidesteps several future client-master interactions at practically no extra cost.
2.5 Chunk Size
Chunks ize is one of the key design parameters. We have chosen 64 MB, which is much larger than typical file system blocks izes. Each chunk replica is stored as a plain
Linux file on a chunkserver and is extended only as needed.Lazy space allocation avoids wasting space due to internal fragmentation, perhaps the greatest objection against such
a large chunksize.
A large chunksize offers several important advantages.First, it reduces clients need to interact with the master because reads and writes on the same chunkre quire only one initial request to the master for chunklo cation information.The reduction is especially significant for our workloads because applications mostly read and write large files sequentially. Even for small random reads, the client can comfortably cache all the chunklo cation information for a multi-TB working set. Second, since on a large chunk, a
client is more likely to perform many operations on a given chunk, it can reduce network overhead by keeping a persistentTCP connection to the chunkserver over an extended
period of time. Third, it reduces the size of the metadata stored on the master. This allows us to keep the metadata in memory, which in turn brings other advantages that we will discuss in Section 2.6.1.
On the other hand, a large chunks ize, even with lazy space allocation, has its disadvantages. A small file consists of a small number of chunks, perhaps just one. The chunkservers storing those chunks may become hot spots if many clients are accessing the same file. In practice, hot spots have not been a major issue because our applications mostly read large multi-chunkfil es sequentially.
However, hot spots did develop when GFS was first used by a batch-queue system: an executable was written to GFS as a single-chunkfil e and then started on hundreds of machines at the same time. The few chunkservers storing this executable were overloaded by hundreds of simultaneous requests. We fixed this problem
全文共15737字，剩余内容已隐藏，支付完成后下载完整资料
2.3 架构
一个GFS 集群包含一个单独的Master 节点、多台Chunk 服务器，并且同时被多个客户端访问。所有的这些机器通常都是普通的Linux 机器，运行着用户级别的服务进程。我们可以很容易的把Chunk 服务器和客户端都放在同一台机器上，前提是机器资源允许，并且我们能够接受不可靠的应用程序代码带来的稳定性降低的风险。
GFS 存储的文件都被分割成固定大小的Chunk。在Chunk 创建的时候，Master 服务器会给每个Chunk 分配一个不变的、全球唯一的64位的Chunk 标识。Chunk 服务器把Chunk 以linux文件的形式保存在本地硬盘上，并且根据指定的Chunk 标识和字节范围来读写块数据。出于可靠性的考虑，每个块都会复制到多个块服务器上。缺省情况下，我们使用3个存储复制节点，不过用户可以为不同的文件命名空间设定不同的复制级别。
Master 节点管理所有的文件系统元数据。这些元数据包括名字空间、访问控制信息、文件和Chunk 的映射信息、以及当前Chunk 的位置信息。Master 节点还管理着系统范围内的活动，比如，Chunk 租用管理、孤儿Chunk的回收、以及Chunk 在Chunk 服务器之间的迁移。Master 节点使用心跳信息周期地和每个Chunk 服务器通讯，发送指令到各个Chunk 服务器并接Chunk 服务器的状态信息。
GFS 客户端代码以库的形式被链接到客户程序里。客户端代码实现了GFS 文件系统的API接口函数、应用程序与Master 节点和Chunk 服务器通讯、以及对数据进行读写操作。客户端和Master 节点的通信只获取元数据，所有的数据操作都是由客户端直接和Chunk 服务器进行交互的。我们不提供POSIX 标准的API 的功能，因此，GFS API 调用不需要深入到Linuxvnode 级别。
无论是客户端还是Chunk 服务器都不需要缓存文件数据。客户端缓存数据几乎没有什么用处，因为大部分程序要么以流的方式读取一个巨大文件，要么工作集太大根本无法被缓存。无需考虑缓存相关的问题也简化了客户端和整个系统的设计和实现。Chunk 服务器不需要缓存文件数据的原因是，Chunk 以本地文件的方式保存，Linux操作系统的文件系统缓存会把经常访问的数据缓存在内存中。
2.4 单一的Master节点
单一的Master 节点的策略大大简化了我们的设计。单一的Master 节点可以通过全局的信息精确定位Chunk 的位置以及进行复制决策。另外，我们必须减少对Master 节点的读写，避免Master 节点成为系统的瓶颈。客户端并不通过Master 节点读写文件数据。反之，客户端向Master 节点询问它应该联系的Chunk 服务器。客户端将这些元数据信息缓存一段时间，后续的操作将直接和Chunk 服务器进行数据读写操作。
我们利用图1解释一下一次简单读取的流程。首先，客户端把文件名和程序指定的字节偏移，根据固定的Chunk 大小，转换成文件的Chunk 索引。然后，它把文件名和Chunk 索引发送给Master 节点。Master 节点将相应的Chunk 标识和副本的位置信息发还给客户端。客户端用文件名和Chunk 索引作为key 缓存这些信息。
之后客户端发送请求到其中的一个副本处，一般会选择最近的。请求信息包含了Chunk 的标识和字节范围。在对这个Chunk 的后续读取操作中，客户端不必再和Master 节点通讯了，除非缓存的元数据信息过期或者文件被重新打开。实际上，客户端通常会在一次请求中查询多个Chunk 信息，Master 节点的回应也可能包含了紧跟着这些被请求的Chunk 后面的Chunk的信息。在实际应用中，这些额外的信息在没有任何代价的情况下，避免了客户端和Master节点未来可能会发生的几次通讯。
2.5 Chunk尺寸
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章节将深入讨论这些行为。
将元数据全部保存在内存中的方法有潜在问题：Chunk 的数量以及整个系统的承载能力都受限于Master 服务器所拥有的内存大小。但是在实际应用中，这并不是一个严重的问题。Master服务器只需要不到64个字节的元数据就能够管理一个64MB 的Chunk。由于大多数文件都包含多个Chunk，因此绝大多数Chunk 都是满的，除了文件的最后一个Chunk 是部分填充的。同样的，每个文件的在命名空间中的数据大小通常在64字节以下，因为保存的文件名是用前缀压缩算法压缩过的。
即便是需要支持更大的文件系统，为Master 服务器增加额外内存的费用是很少的，而通过增加有限的费用，我们就能够把元数据全部保存在内存里，增强了系统的简洁性、可靠性、高性能和灵活性。
2.6.2 Chunk位置信息
Master 服务器并不保存持久化保存哪个Chunk 服务器存有指定Chunk 的副本的信息。Master服务器只是在启动的时候轮询Chunk 服务器以获取这些信息。Master 服务器能够保证它持有的信息始终是最新的，因为它控制了所有的Chunk 位置的分配，而且通过周期性的心跳信息监控Chunk 服务器的状态。
最初设计时，我们试图把Chunk 的位置信息持久的保存在Master 服务器上，但是后来我们发现在启动的时候轮询Chunk 服务器，之后定期轮询更新的方式更简单。这种设计简化了在有Chunk 服务器加入集群、离开集群、更名、失效、以及重启的时候，Master 服务器和Chunk 服务器数据同步的问题。在一个拥有数百台服务器的集群中，这类事件会频繁的发生。可以从另外一个角度去理解这个设计决策：只有Chunk 服务器才能最终确定一个Chunk 是否在它的硬盘上。我们从没有考虑过在Master 服务器上维护一个这些信息的全局视图，因为Chunk 服务器的错误可能会导致Chunk 自动消失(比如，硬盘损坏了或者无法访问了)，亦或者操作人员可能会重命名一个Chunk 服务器。
2.6.3 操作日志
操作日志包含了关键的元数据变更历史记录。这对GFS 非常重要。这不仅仅是因为操作日志是元数据唯一的持久化存储记录，它也作为判断同步操作顺序的逻辑时间基线（alex 注：也就是通过逻辑日志的序号作为操作发生的逻辑时间，类似于事务系统中的LSN）。文件和Chunk，连同它们的版本(参考4.5节)，都由它们创建的逻辑时间唯一的、永久的标识。
操作日志非常重要，我们必须确保日志文件的完整，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。否则，即使Chunk 本身没有出现任何问题，我们仍有可能丢失整个文件系统，或者丢失客户端最近的操作。所以，我们会把日志复制到多台远程机器，并且只有把相应的日志记录写入到本地以及远程机器的硬盘后，才会响应客户端的操作请求。
Master 服务器会收集多个日志记录后批量处理，以减少写入磁盘和复制对系统整体性能的影响。Master 服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。为了缩短Master 启动的时间，我们必须使日志足够小（alex 注：即重演系统操作的日志量尽量的少）。Master 服务器在日志增长到一定量时对系统状态做一次Checkpoint(alex 注：Checkpoint 是一种行为，一种对数据库状态作一次快照的行为)，将所有的状态数据写入一个Checkpoint 文件（alex 注：并删除之前的日志文件）。在灾难恢复的时候，Master 服务器就通过从磁盘上读取这个Checkpoint 文件，以及重演Checkpoint 之后的有限个日志文件就能够恢复系统。
Checkpoint 文件以压缩B-树形势的数据结构存储，可以直接映射到内存，在用于命名空间查询时无需额外的解析。这大大提高了恢复速度，增强了可用性。
由于创建一个Checkpoint 文件需要一定的时间，所以Master 服务器的内部状态被组织为一种格式，这种格式要确保在Checkpoint 过程中不会阻塞正在进行的修改操作。Master 服务器使用独立的线程切换到新的日志文件和创建新的Checkpoint 文件。新的Checkpoint 文件包括切换前所有的修改。对于一个包含数百万个文件的集群，创建一个Checkpoint 文件需要1分钟左右的时间。创建完成后，Checkpoint 文件会被写入在本地和远程的硬盘里。Master 服务器恢复只需要最新的Checkpoint 文件和后续的日志文件。旧的Checkpoint 文件和日志文件可以被删除，但是为了应对灾难性的故障（alex 注：catastrophes，数据备份相关文档中经常会遇到这个词，表示一种超出预期范围的灾难性事件），我们通常会多保存一些历史文件。Checkpoint 失败不会对正确性产生任何影响，因为恢复功能的代码可以检测并跳过没有完成的Checkpoint 文件。
2.7 一致性模型
GFS 支持一个宽松的一致性模型，这个模型能够很好的支撑我们的高度分布的应用，同时还保持了相对简单且容易实现的优点。本节我们讨论GFS 的一致性的保障机制，以及对应用程序的意义。我们也着重描述了GFS 如何管理这些一致性保障机制，但是实现的细节将在本论文的其它部分讨论。
2.7.1 GFS一致性保障机制
文件命名空间的修改（例如，文件创建）是原子性的。它们仅由Master 节点的控制：命名空间锁提供了原子性和正确性（4.1章）的保障；Master 节点的操作日志定义了这些操作在全局的顺序（2.6.3章）。
数据修改后文件region（alex 注：region 这个词用中文非常难以表达，我认为应该是修改操作所涉及的文件中的某个范围）的状态取决于操作的类型、成功与否、以及是否同步修改。表1总结了各种操作的结果。如果所有客户端，无论从哪个副本读取，读到的数据都一样，那么我们认为文件region 是“一致的”；如果对文件的数据修改之后，region 是一致的，并且客户端能够看到写入操作全部的内容，那么这个region 是“已定义的”。当一个数据修改操作成功执行，并且没有受到同时执行的
全文共7168字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[142902]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
