TPDS 2008 Paper 分布式元数据论文阅读笔记整理
问题
随着集群中节点数量的增加,元数据管理的效率对于基于集群的存储系统的总体性能至关重要,它不仅提供文件属性和数据块地址,还同步并发更新,强制执行访问控制,支持从节点故障中恢复,并保持用户数据和文件元数据之间的一致性。
用于文件映射或文件查找的高效和分布式方案对于在一组元数据服务器内分散元数据管理至关重要。
本文方法
本文提出了层次布隆过滤器阵列(HBA)的新技术,将文件名映射到保存其元数据的元数据服务器。
-
在每个元数据服务器上使用两个不同精度级别的Bloom过滤器(BF)阵列。一个阵列具有较低的精度并表示整个元数据的分布,以精度换取显著减少的内存开销。另一个阵列则具有较高的精度,缓存部分分布信息并利用文件访问模式的时间局部性。使用全路径进行BF哈希。
-
这两个阵列都被复制到所有元数据服务器,以支持快速的本地查找。随着系统的发展,BF在本地更新,并将更改定期传播到其远程副本,以提高查找准确性。
通过在Linux中进行广泛的跟踪驱动模拟和实现来评估HBA。结果表明,HBA设计在1000到10000个节点(或超级集群)的集群中,数据量达到或超过PB级的文件系统的性能和可扩展性方面非常有效。当系统配置有16个元数据服务器时,HBA可以将单个元数据服务器架构的元数据操作时间减少43.9倍。
Bloom过滤器问题
纯Bloom过滤器(PBA)的准确性会随着MDS数量的增加而迅速下降。为了实现令人满意的命中率,需要使用大尺寸的BF,从而增加了对每个MDS的内存空间要求。例如,如果一个集群中有200个MDS,则每个BF中每个文件需要16位,以保持旧文件的大约90%的命中率和新文件的10%的误命中率。如果该集群中存储了5亿个文件,BF阵列将在每个MDS上占用约1GB的内存空间。在实践中,命中率可能低于理论估计,这意味着需要采用更高的比特/文件比率。例如在Web缓存设计系统[37]中,建议每个对象的比率为32位。
层次Bloom滤波器阵列设计
在典型文件系统中大部分I/O只访问少量的文件,据此设计了HBA。
图4显示了每个MDS上HBA设计的结构,其中包括两个级别的BF阵列。每个MDS维护一个最近最少使用BF(LRU BF),该列表缓存最近访问的文件的名称,表示该文件的元数据本地存储在该MDS上。
第一层的每个BF,称为LRU BF i,表示在MDSi的LRU列表中缓存的所有文件。每个LRU BF在所有MS之间全局复制,当LRU BF的更改量超过某个阈值时,LRU BF才会更新其他MDS的所有副本。由于LRU BF中的条目数量相对较少,因此使用高比特/文件比来实现低误命中率。
第二层的BF表示所有MS的元数据分布。由于文件的总数非常大,因此使用较低的位/文件比来减少内存开销。第一层阵列中的未命中会导致查询到第二层,第二层阵列中的查询不成功将导致向所有其他元数据服务器发出广播。相对于命中时间,对未命中或误命中的惩罚是更昂贵的。
缺点是使用全目录进行哈希,导致权限修改和重命名操作会产生大量的修改,可能产生大量网络开销。为了在重命名上级目录时最大限度地减少广播次数,文件和子目录的名称(不包括子目录的文件)将被记录为其父目录元数据的一部分。
另一个缺点是没有负载均衡,大量请求访问少量热点时可能导致单个MDS过载。
总结
针对多元数据服务器时,元数据性能优化。本文提出层次布隆过滤器阵列(HBA),使用全路径进行BF哈希。(1)在每个元数据服务器上维护两个Bloom过滤器。第一层具有较高的精度,使用LRU利用时间局部性,缓存部分热点文件元数据。第二层具有较低的精度,表示整个元数据的分布,以精度换取显著减少的内存开销。(2)将这两个Bloom过滤器复制到所有元数据服务器,以支持每个元数据服务器上都可以实现全局文件查找。Bloom过滤器在本地更新,修改超过阈值后更新其远程副本。