本文讲的分布式文件系统,是通过集群来实现的,因此也是集群文件系统。本文介绍下分布式文件系统中的常见问题及GFS中给出的解决方法。
性能
提高性能的方法就是并行,讲一个任务分解成多个任务,同一时候运行。
GFS中的思路是将文件分块,每一个块是一个chunk,每一个chunk单独保存,保存chunk的节点叫chunkserver。对文件的读写,能够转成对chunk的读写,不同的chunk能够并行运行,提高效率。每一个chunk有唯一的一个chunk handle表示,chunk的大小(chunk size)须要依据应用特点决定。chunk size过大,影响并行度;过小,占用很多其它的metadata空间,很多其它的chunk解析时间。
高可用性(availability)和可靠性(reliability)
可用性指系统平均宕机时间占总使用时间的比例,越小越好。
可控性指系统的平均无故障执行时间,越长越好。
高可用性能够通过硬件冗余(redundency)实现,当一个硬件不能工作的时候,迅速切换到备份系统。缩小切换时间能够添加�系统的可用性。
提高容错性(fault tolerance)能够提高系统的可靠性,一个component失效,不会影响总体的功能。
GFS中採用的就是硬件冗余的方法来实现高可用和高可靠。master和chunkserver都有备份,对于chunkserver,有3个节点互为备份,备份以chunk为单位进行。
master採用主备(master/slave)方式备份。master主节点(primary master)会将自己的状态信息(operation log和checkpoint)同步到备份节点上,当主节点不可用时,备份节点能够新的主节点使用。
chunkserver採用负载均衡(load balance)方式备份。每一个chunk会被保存在3台chunkserver上,每一个chunkserver都会參与处理请求。对于读请求,会选择距离client较近的chunkserver;对于写请求,master会选择一个primary replica,由primary replica负责将client的数据同步到其它的备份节点上。
可扩展性
集群的规模能够依据须要动态扩展,主要指存储能力的扩展性,即添加�chunkserver的能力。为了支持动态扩展,须要做到chunk保存位置的透明性(Location transparency),用户不须要知道每一个chunk保存在哪些机器上,而是由系统动态维护。这样系统中chunkserver的添加�和降低就不会影响client的使用。
GFS中的思路,採用一个master节点来保存全部的元数据(metadata),实现chunk的位置透明性。
master的主要工作:
文件的namespace管理
类似于传统文件系统中的文件夹结构,维护系统中已有的文件。
将文件映射成chunks
每一个文件由若干个chunk组成。从client看来,chunk由0開始编号直到N。master须要将chunk的逻辑编号(0,1,…N)映射为内部的chunk handle(chunk的唯一全局标示符)。
chunk位置管理
记录每一个chunk所属的chunkserver的位置,每一个chunk会保存在多个chunkserver上。依据这个信息,能够实现chunk的位置无关性。master会和每一个chunkserver通信,已得到每一个chunkserver上保存的chunk信息。创建新的chunk时,master也会依据一定的算法来选择chunkserver(默认选择3台,存放3个备份)来保存chunk。
容错处理
系统执行中,可能出现chunkserver损坏的情况。master须要将这台机器上所保存的chunk进行又一次部署(re-replicatoin)。还有随着机器的添加�,还要对chunk存放进行又一次的平衡(rebalancing,chunk migration between chunk servers)。
元数据保存和备份、恢复
上述功能的实现都依赖于metadata,metadata主要保存在内存中。系统中对文件的更改操作(mutation)都会记录操作日志中(operation log,这个日志类似于关系数据库系统中的日志)。内存中的metadata也会以checkpoint的形式存放在磁盘上。依据一个checkpoint和在其上进行的operation log,就能够恢复系统的状态(在checkpoint基础上重放运行过的全部操作就可以)。master就是将checkpoint和operation log备份到其它机器上,来实现备份恢复。
一致性指当一个client更改了文件的内容时,其它的clients是否能看到这些内容,何时看到。
GFS中採用的是强一致性(strong consistency model)模型,这个模型中,当一个client改动完毕后,其它的全部clients都会立马看到改动(无论client是从哪个备份读)。这个和普通的单机文件系统是一致的。GFS中没有提供的文件读写的并发控制,当多个client同一时候进行更改操作时,文件内容是不确定的(undefined)
并发控制(concurrency control)
当有多个client同一时候运行某个操作时,要保证系统的正确性。
GFS中对文件namespace的操作时原子操作,及多个client同一时候使用不会产生问题,内部有一定的并发控制策略(通过锁lock机制实现)。但对文件内容的读写没有提供并发控制。
GFS还提供了还有一种原子操作,附加记录(Atomic Record Appends)。
总结:
这些问题在每一个分布式文件系统中都会出现,不同的系统可能有不同的解决方法。在学习的时候,能够先关注这些点。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/118611.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】:
Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】:
官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...