TFS任务队列模型

TFS系统里主要包含复制、迁移、压缩、删除等四种后台任务,主要由nameserver(NS)负责控制。

复制任务

当NS检测到block副本数不足时,就会产生复制任务,选择block某个副本所在的DS作为复制源,选择一个机架安全的DS作为复制目标,NS将任务信息发给源DS,源DS接受到任务后将block的数据复制到目标DS,数据复制完后,源DS向NS提交任务执行情况,如果复制成功,NS则建立block到目标DS的映射关系。

当有DS宕机时,凡是有副本在该DS上的block就一定会出现副本数不足道情况,NS会直接这批block加入到复制队列,NS不断从复制队列里取出block,构建复制任务;但仅通过上述这种方式并不能保证检测出所有缺副本的block,因为复制队列的信息只存在于内存,如果出现了NS重启的情况,而复制队列的数据是不可重建的,所以NS还会在后台遍历检查所有的block,来确保副本数不足的block都能得到复制。

迁移任务

迁移任务与复制任务流程非常类似,只不过block复制到目标DS上后,会将block从源DS上删除。迁移任务主要是尽量让各个DS之间负载均衡,只有在block数据安全(所有block的副本数都达到配置值)的情况下才会启动。

enter image de.ion here

压缩任务

TFS删除文件时,只是在文件的元信息上设置删除标记,当block里文件删除数超过一定比例时,NS就会构造压缩任务,让所有拥有该block副本的DS压缩block,以回收block里删除文件的存储空间;接收到压缩任务后,每个DS在本地压缩block,实际上就是将block数据重新写一遍,忽略掉删除的文件,压缩完后,DS会向NS提交压缩的结果,NS收到所有DS的反馈则压缩任务完成。压缩任务主要消耗IO资源,通常在访问低峰期进行,避免影响到用户请求。

enter image de.ion here

删除任务

当某个block的副本数超出配置值时,NS就会选择某个多余的副本,加入删除队列。NS会请求对应的DS删除队列里的block,发送删除请求前,NS会再次确认block的副本数是足够的,比如在删除前,该block某个副本所在的DS宕机,这时要等block复制完,才能安全的删除block。

以上后台任务都是异步完成的,NS发送请求给DS,DS完成对应的任务后,向NS提交执行结果,NS收集所有结果后,更新元信息。如果超过一定时间,某个任务还没有收到DS提交结果,则任务该任务执行超时,直接将任务对应的元数据删除掉(每个任务由一个seqno唯一标识),NS后台会重新创建该任务。

对于复制任务,NS需要发送一次请求,接受一次结果提交,总共2次网络交互;而对于压缩任务,如果有3个副本,则NS需要发送3次请求,接受3次提交,总共6次网络交互;NS作为TFS系统里的单点(目前通过HA的方式来避免),应该尽量让单点少做事情,基于此,我们对任务模型进行了优化,将NS的部分工作转移到DS上(DS在网络、CPU上的处理能力有很大的富余且机器数多)。

在新的模型里,NS只需要生成任务元信息,并将其发送给某个主控端DS,主控DS负责任务的分发及结果的收集(原来NS的工作),主控DS在任务执行完后,将最终结果提交给NS。这样一来,无论何种类型的任务,对于NS而言就只有2次网络交互;优化后的压缩任务流程如下图所示,虽然整个网络交互次数变多了,但从优化NS的角度看来是有效的,毕竟DS的资源是由富余的,闲着也是闲着,还不如充分利用起来。

enter image de.ion here


ref:
2013-11-07 22:56:09
blog.yunnotes.net

0 回复
需要 登录 后方可回复, 如果你还没有账号你可以 注册 一个帐号。