一种低延迟的面向小文件的分布式存储系统的制作方法
【专利摘要】本发明设计了一种低延迟的面向小文件的分布式存储系。系统中所有的DataServer在逻辑上组织成环，系统采用一致性哈希方案，按照特定哈希算法对DataServer的ID进行哈希，并根据哈希值将各个DataServer分布在整个哈希值域的环上。集群中设置一个中心的CV节点，CV节点管理的集群拓扑信息包括集群中所有活动的DataServer列表以及当前集群拓扑信息的版本号。客户端在本地缓存集群拓扑信息。客户端第一次集群时，会访问CV节点获取集群拓扑信息，并缓存在本地，后续读写时使用本地缓存的集群拓扑信息。客户端进行读写时，首先根据文件名，按照一致性哈希方案，对文件名进行哈希，并确定该小文件所落在的DataServer。然后对比DataServer保存的集群拓扑信息和客户端保存的集群拓扑信息的版本号，如果版本号一致，则在DataServer进行实际的读写操作。
【专利说明】一种低延迟的面向小文件的分布式存储系统
【技术领域】
[0001]本发明涉及分布式存储和海量小文件存储领域，具体涉及一种低延迟的面向小文 件的分布式存储系。
【背景技术】
[0002]小文件通常指文件尺寸小于HDFS默认块大小(即64MB)的文件，在目前的应用中， 照片文件、音乐文件、email文本内容、微博内容等都可以认为是小文件。
[0003]小文件问题逐渐在学术界和工业界引起了一些关注。著名社交网站Facebook存 储了 2600亿张图片，容量超过20PB，这些文件绝大部分都小于64MB。在超级计算机领域， 例如，ORNL’ s CrayXT5集群(18688个节点，每个节点12个处理器)上的应用程序会周期性 地将应用状态写入文件，导致系统产生大量的小文件。美国西北太平洋国家实验室2007年 的一份研究报告表明，该实验室系统中有1200万个文件，其中94%的文件小于64MB，58%的 文件小于64KB，在具体科研计算环境中，例如某些生物学计算中，可能产生3000万个文件， 而其平均大小只有190KB。音乐网站巨鲸网已经收录了 360万MP3格式的音乐文件。其他 文献也表明，互联网上访问的数据多为高访问频率的小文件。
[0004]GFS技术领导人Sean Quinlan在GFS访谈中提到BigTable的其中一个应用场景 即面向小文件。著名Hadoop应用公司Cloudera发布的关于Small File Problem的报告 也指出Hadoop在处理海量小文件方面存在问题。
[0005]Hadoop本身提供了 Hadoop archive (HAR)用来将小文件合并成大文件。HAR文 件是通过HDFS上构建一个层次化的文件系统来工作的，一个HAR文件是通过Hadoop的 archive命令进行创建,这个命令实际运行了 一个Mapreudce任务来将小文件打包成HAR文 件。
[0006]GIGA+研究了单个目录下海量小文件的应用情况，提出了一种扩展性良好的目录 设计方案GIGA+，GIGA+通过将索引分散到集群中不同的服务器节点上并避免同步和序列 化，实现一个异步、最终一致性，可容忍陈旧索引状态的目录设计。该设计是对现有集群文 件系统的补充，原有的集群应用程序无需改动。
[0007]Facebook针对其图片存储应用设计了 Haystack存储系统。Haystack Store通 过将图片打包到一个大型的volume (100G)中，将图片id和图片在volume中的检索信息 (offset和size)建立映射并放在内存中。系统建立了一个Haystack Cache的组件来缓存 新增加的图片，并有Haystack Directory处理volume的映射和负载均衡。通过建立索引 文件(index file)来加速重建内存映射信息。
[0008]TFS是开源的面向海量小文件的存储系统，广泛应用于淘宝网、人人网等公司。TFS 包括三个部分=TFS集群，Meta服务集群，以及客户端库。
[0009]TFS 集群主要包括 NameServer 和多个 DataServer。同 Facebook 的 Haystack 系统管理块的方式一致，TFS将大量的小文件合并成为一个大文件，这个大文件称为块 (Block),每个块具有唯一 ID,块分布在各个DataServer上。NameServer负责DataServer的状态管理，并维护块与DataServer的映射关系。NameServer不负责实际数据的读写，实 际数据的读写由DataServer完成。TFS集群使用TFS文件名存放文件，TFS文件名是对块 号、偏移、文件大小进行编码后的字符串。
[0010] Meta服务集群包括一个主控节点RootServer和多个服务节点MetaServer组成。 RootServer主要管理所有的MetaServer, MetaServer用于管理自定义文件名和TFS文件 名的映射。目前TFS使用MySQL数据库提供后端持久化存储。
[0011 ] TFS可以不配置Meta服务集群，此时TFS只用TFS文件名，不支持自定义文件名。 记这种配置的TFS为TFS-noname。记配置了 Meta服务集群的集群为TFS-name。
[0012]TFS能够完成用户自定义文件名存取小文件，但TFS仍然存在3个问题。
[0013]第一，TFS读写文件过程中需要建立多次网络连接。客户端写小文件时，首先客 户端库访问TFS集群中的NameServer, NameServer指定一个可写块用于写入该小文件,然 后客户端访问这个可写块所在DataServer进行实际的写入操作并返回给客户端一个TFS 文件名，客户端再访问Meta服务集群，将自定义文件名和刚得到TFS文件名映射关系写入 Meta服务集群。客户端读小文件时，客户端首先访问Meta服务集群,根据用户自定义文件 名读取对应的TFS文件名，然后客户端访问NameServer，解析TFS文件名，获得其中块号，并 根据NameServer中管理的块号到DataServer的映射关系，得到应访问的DataServer。客 户端再访问DataServer，执行实际的文件读操作。TFS在执行读写操作时，如果客户端库中 没有缓存MetaServer信息,客户端需要先访问RootServer获取当前活跃的MetaServer,然 后进行后续的处理。因此TFS最少进行三次网络连接来完成一次读写操作，第一次访问时， 需要四次网络连接。这是TFS读写文件低效的原因之一。
[0014]第二，TFS使用重量级的MySQL作为存储TFS文件名和自定义文件名映射关系的 后端存储系统，相比于用轻量级的NoSQL数据库，延迟开销也比较大。
[0015]第三,TFS的NameServer记录了所有块的信息,维护了块号到DataServer的映射 关系。如果NameServer发生失效后执行恢复时,必须重建块信息和映射关系。由TFS架构 图和读写流程可知，NameServer是TFS集群的单点故障,NameServer失效时,整个集群读写 均不可用。因此TFS可用性仍有提高空间。
【发明内容】
[0016]针对TFS存在的问题，本发明设计一种新的面向小文件的分布式存储系统。系 统架构如图1，所有的DataServer在逻辑上组织成环(图中的SI?S8节点)。系统采用 一致性哈希方案，按照特定哈希算法对DataServer的ID进行哈希,并根据哈希值将各个 DataServer分布在整个哈希值域的环上。
[0017]集群中设置一个中心的CV (Central Version)节点，每一个DataServer周期性 地向CV节点发送其心跳消息，CV节点接收这些消息，用于管理集群的拓扑信息。CV节点 管理的集群拓扑信息包括集群中所有活动的DataServer列表以及当前集群拓扑信息的版 本号。DataServer列表中保存了每一个活动的DataServer的ID和这个DataServer所 监听的IP地址和端口。集群拓扑信息版本号用单调递增的时间戳表示。每当集群有新的 DataServer加入或者原有的DataServer退出时,CV节点重新生成一个集群拓扑信息,并将 这个集群拓扑信息的版本号设置为当前时间戳，然后CV节点将这个新的集群拓扑信息发送到所有当前活动的DataServer,这样所有的DataServer都会保存同样的集群全局信息。
[0018]客户端在本地缓存集群拓扑信息。客户端第一次集群时，会访问CV节点获取集群拓扑信息，并缓存在本地，后续读写时使用本地缓存的集群拓扑信息。
[0019]客户端进行读写时，首先根据文件名，按照一致性哈希方案，对文件名进行哈希， 并确定该小文件所落在的DataServer。然后对比DataServer保存的集群拓扑信息和客户端保存的集群拓扑信息的版本号，如果版本号一致，则在DataServer进行实际的读写操作。
[0020]DataServer有两个主要组件，如图2，一个是块管理组件，一个是检索信息管理组件。块管理组件使用小文件合并成大块的方案。系统预先分配好较大的文件块，然后新写入的小文件会写入大块内。在已知小文件所在块号，小文件在块内偏移量和小文件大小这些检索信息的情况下，就可以从一个DataServer中检索出该小文件。系统使用Key-Value 存储来管理文件名到检索信息的映射关系，即:
[0021]Key:filename — Value:(Blockld, Offset, Size)
[0022]系统设计并实现了一个类似于Redis并具备持久化功能的Key-Value存储。系统用这个Key-Value存储来管理检索信息。
【专利附图】
【附图说明】
[0023]图1是系统架构图。
[0024]图2是系统中DataServer的结构图。
【具体实施方式】
[0025]步骤1:设计一个块管理组件。
[0026]将小文件存放在大块中，每个大块预分配好。新写入的小文件顺序写入大块中。块管理组件提供向块中写入一个小文件和从块中读取一个小文件的接口。向块管理`组件中写入一个小文件后，块管理组件返回一个检索信息，检索信息包括块号，偏移量，大小。块管理组件可以根据检索信息从块管理组件中读取出一个小文件。
[0027]步骤2:设i十一个key-value管理组件。
[0028]实现一个内存key-value的存储，并将每一个存入的key-value同时写入磁盘。 key为小文件文件名，value为检索信息。在内存的key-value用哈希表实现,哈希函数使用murmurhash算法。对每一个新插入的key-value对,都顺序写入磁盘。
[0029]步骤3:设计CV节点。
[0030]设计CV节点,用于接收DataServer的心跳消息,并维护整个集群的拓扑信息。在集群拓扑信息发生变化时，CV节点向每一个节点发送最新的集群拓扑信息。CV节点上启动一个监听服务，监听每一个连接到CV的DataServer的心跳消息。并使用std:: vector管理所有活跃的DataServer。对于每一个新来的心跳消息,如果这个消息的发送者DataServer 没有在vector中，则加入vector，并标记集群拓扑信息有了更新。如果已经存在，则将该 DataServer从vector中删除并添加到vector末尾。检查vector中第一个DataServer, 如果这个DataServer的最后的一次心跳消息时间距离当前时间超过一定阈值,则清理这个DataServer (同时在网络连接访问出错时清理对应的网络连接)，标记集群拓扑信息有了更新。如果集群拓扑信息有了更新，则将新的集群拓扑信息发送给所有活跃的DataServer。
[0031]步骤4:读写流程。
[0032]系统写小文件的流程如下:
[0033]1.如果客户端是第一次访问系统，则客户端访问CV节点，请求集群的拓扑信息， 并记录到本地。连续访问时，如果不是第一次访问系统，则客户端本地已缓存了集群的拓扑信息。
[0034]2.客户端对文件名进行哈希，并按照一致性哈希算法决定该小文件应由哪一个 DataServer进行处理。
[0035]3.客户端访问2中得到的DataServer，将客户端缓存的集群拓扑信息、小文件的 文件名、小文件内容缓冲区发送到该DataServer。
[0036]4.DataServer首先判断客户端缓存的集群拓扑信息是否过时，即对比 DataServer本身记录的集群拓扑信息和客户端写请求消息中的集群拓扑信息的版本号是 否一致。如果一致转5。如果不一致，则对比客户端写请求消息中的集群拓扑信息，判断差 异是否会影响本次写操作，如果不影响，标记NEED_UPDATE并转5，否则告诉客户端写操作 失败，并将新的集群拓扑信息发送给客户端，写操作结束。
[0037]5.DataServer访问检索信息管理组件，检查该小文件文件名是否已经存在，若存 在则告诉客户端文件名已存在。否则转6。
[0038]6.DataServer通过块管理组件将小文件的内容写入块中，同时将块管理组件得到 的检索信息和文件名以key-value形式写入检索信息管理组件。并向客户端返回写入成 功消息，如果设置了 NEED_UPDATE标记，则同时将新的集群拓扑信息告诉客户端，写操作结 束。
[0039]系统读小文件的流程如下:
[0040]1.如果客户端是第一次访问系统，则客户端访问CV节点，请求集群的拓扑信息， 并记录到本地。连续访问时，如果不是第一次访问系统，则客户端本地已缓存了集群的拓扑信息。
[0041]2.客户端对文件名进行哈希，并按照一致性哈希算法决定该小文件应由哪一个 DataServer进行处理。
[0042]3.客户端访问2中得到的DataServer。判断客户端读请求中附带的集群拓扑信 息是否与本地DataServer记录的集群拓扑信息版本号一致。如果一致,转4。如果不一致, 标记 NEED_UPDATE。
[0043]4.DataServer向检索信息管理组件查询该小文件的文件名，检查该小文件文件名 是否存在。如果存在，读取出检索信息，转5。如果不存在，则向客户端发送文件不存在消 息，若3设置了 NEED_UPDATE标记，则将新的集群拓扑信息附带在文件不存在消息中，通知 客户端更新缓存中的集群拓扑信息，读操作结束。
[0044]5.DataServer通过4中得到的检索信息，从块管理组件中读取小文件内容,并发 送给客户端，如果标记了 NEED_UPDATE，则将新的集群拓扑信息附带在该消息中，读操作结 束。
[0045]淘宝公司开源的TFS在读写过程中，至少进行三次网络连接。在TFS的客户端没 有缓存TFS的MetaServer信息的情况下,客户端库还需要再连接TFS的RootServer。[0046]从我们的系统的读写流程可以看出，连续访问的情况下，客户端在第一次访问 CV节点后，读取到集群拓扑信息，并在客户端缓存。在集群拓扑没有发生变化时，客户端 后续的读写操作根据客户端已经缓存的集群拓扑信息能够直接确定客户端需要访问的 DataServer,客户端访问这个DataServer完成一次读请求或写请求。
[0047]在集群拓扑发生变化时，客户端后续的读写请求首先根据客户端之前缓存的陈旧 的集群拓扑信息，确定要访问的DataServer。
[0048]如果客户端连接成功，并正确进行了读取或者写入，则表明DataServer判断出此 时集群拓扑变化(新增节点或者有节点退出)并没有影响到该小文件的读写请求，同时客户 端再完成此次读写请求后能够从请求消息中读取出附带的最新的集群拓扑信息，更新客户 端本地的陈旧的集群拓扑信息缓存。再后续的读写请求就可以用最新的集群拓扑信息来 访问我们设计的集群。如果连接不成功，则表明想要访问的节点已经失效退出，则客户端 需要多一次访问CV节点，获取当前最新的集群拓扑信息，重新进行读写。如果访问成功但 DataServer判断出集群拓扑变化影响了此次读写请求，则DataServer回复客户端读写失 败，并将最新的集群拓扑信息附带给客户端，客户端重新进行读写。
[0049]因此本发明设计的系统简化了读写流程，减少了每次读写过程中的网络连接次 数。实验结果证明这种改进能够有效降低延迟。
[0050]另外，本发明设计的系统使用更轻量级的Key-Value存储来管理检索信息。有测 试表明，在检索信息比较多，连续写入检索信息的情况下，Key-Value存储往往会在性能上 比传统数据库如MySQL表现出更低的延迟和更高的吞吐量。
[0051]从中心节点负载、故障恢复速度、系统健壮性三个角度对比分析TFS与本发明的 系统，证明本发明的系统设计在可用性方面更有优势。
[0052]本发明的系统的中心节点CV只负责监控DataServer是否仍活跃。CV节点维护 一个列表，列表每一项都是一个DataServer及其最近一次心跳到来的时间。当CV节点收 到新的某个DataServer发送的心跳消息,如果这个DataServer是列表中没有的则加入列 表，否则更新列表中这个DataServer对应的最近一次心跳时间。同时检查列表中是否有 超时未收到心跳的DataServer,若有,则将其从列表中清除。如果列表有新增或被清除的 DataServer,则将CV维护的集群拓扑信息版本号更新为当前时间戳。并把最新的集群拓扑 信息分发到所有活跃的DataServer。由于CV节点仅仅是接收DataServer发送心跳消息, 维护一个列表，因此CV节点进程负载很低。有文献表明，集群中负载越高的节点，发生失 效的概率越高。同时有文献表明，集群中涉及更多IO的节点更容易发生失效。因此，相比 TFS中NameServer节点，本发明的系统中CV节点的负载低得多，同时CV节点只有网络IO 而没有磁盘10，因此同样的运行环境下，本发明的系统的CV节点发生失效的概率比TFS中 NameServer失效的概率更低。
[0053]NameServer在TFS中是单点故障一样,在某种意义下，CV节点是本发明的系统 的单点故障。由于TFS中NameServer维护了所有块到DataServer的映射信息，因此在 NameServer节点发生失效后，需要重建这种映射关系，这一过程中维护的数据结构复杂。而 本发明的系统中CV节点仅仅维护DataServer是否仍活跃，因此CV节点失效，进程重启后， 可以实现秒级的恢复。因此同样失效的情况下，本发明的系统不可用时间更短，根据可用性 计算公式:
【权利要求】
1.本发明设计了新的系统架构，其特征在于:在集群拓扑没有变化的情况下，连续访问的模式下，每次访问时，只需要一次网络连接。这相对于类似的系统，如TFS，访问更为高效。
2.本发明的系统架构使用的CV节点负载极轻，其特征在于:CV节点失效概率低，且能够实现秒级的恢复。
【文档编号】G06F3/06GK103501319SQ201310429804
【公开日】2014年1月8日 申请日期:2013年9月18日 优先权日:2013年9月18日
【发明者】王鲁俊, 龙翔, 王雷 申请人:北京航空航天大学