鞍山网站设计制作网站,新密网站,工作室网站模板,凡科做网站为什么80%的码农都做不了架构师#xff1f; 原文#xff1a;HYDRAstor: a Scalable Secondary Storage. HYDRAstor#xff08;官网#xff09;是NEC推出的二级存储系统,先后有多篇关于HYDRAstor的论文发表在FAST#xff08;包括后来9livesdata发表的论文 原文HYDRAstor: a Scalable Secondary Storage. HYDRAstor官网是NEC推出的二级存储系统,先后有多篇关于HYDRAstor的论文发表在FAST包括后来9livesdata发表的论文。HYDRAstor是一个完整的存储解决方案,因此涉及的方面很多,包括文件系统、DHT、dedup、erasure code等。这类论文往往是多种技术的汇聚点可以帮助扩展自己的领域。看这篇文章只能了解有这样的东西太多技术细节没有说明。 HYDRAstor的目标是商用产品支持可扩展容量和性能垃圾回收负载均衡高可靠性、可用性等特性。本文关注的是其后端back-end或者称为Hydra一个通过分布式哈希表构建的存储网络对外界而言就像是一个整体系统。为了支持所有流式数据访问的应用API是块级的上层可以实现多种访问协议包括通用的文件系统HydraFS。 0.编程模型 在Hydra中数据都以变长的内容寻址的不可修改的块block的形式存在。每个块除了包括数据以外还有一个指针数组指向其它的数据块。变长是为了提高去重率指针数组可以方便垃圾回收为什么。Hydra只提供最原始的块访问接口因此为上层应用提供了灵活性。 如图1所示Hydra将所有的块组织成有向无循环图DAG。图中最多的是普通块每个块的地址由它的内容包括指针数组决定图中每个顶点SP1、SP2都开启了一棵树整棵树可以看作是一个数据流这些顶点称为可搜索保留根节点searchable retention root每个可搜索根结点都由用户指定一个搜索关键字search key它的地址是由关键字决定的而不是块内容还有一种可搜索删除根节点searchable deletion root它是一种特殊的可搜索根节点用户写入它是为了删除一棵树图中还有一个特殊的顶点A它只是个普通块它存在的原因是树还未构造完成。 Hydra提供写/读普通块写可搜索保留块根据关键字搜索可搜索保留块标记删除可搜索保留块等API。至于对数据流进行分块是交给上层例如HydraFS去做。当写入一个数据块时用户还需指定一个弹性等级resiliency class用于确定如何编码。当用户需要删除某棵树时就写入与其根节点相同关键字的删除根节点。 论文没有提及构建树的过程因此我们也不知道如何维持块之间的逻辑关系。后面的内容都是如何有效地存储数据块了可能这种逻辑关系是放在上层HydraFS维持的吧。这一小节的目的可能是告诉我们如何去使用后端API和后面的内容其实没什么关系。 1.体系结构 HYDRAstor由前端和后端组成。后端是一个由存储结点storage node组成的网格提供可扩展的存储容量前端由一些访问结点access node组成提供可扩展的性能。后端的软件组件包括存储服务器storage server、代理服务器proxy server都是Linux的用户态进程以及协议驱动protocal driver实现为库。 存储服务器组织成一个覆盖网络每个存储结点可以运行多个存储服务器每个存储服务器负责一部分硬盘这就实际上将一个物理结点虚拟化为多个虚拟结点充分利用多核资源。代理服务器位于访问结点向上提供块级接口协议驱动实现上层访问协议比如文件系统都不是本文的重点。 1.1网络 Hydra使用分布式哈希表DHT组织后端网络具体使用的是一个修改过的定长前缀网络FPN。在FPN中每个结点负责一个哈希前缀图2的顶部显示了一棵哈希前缀树它包括四个叶子结点将整个前缀空间分为四个子空间。数据块就根据其哈希的前缀被映射到某个结点。 由于Hydra用纠删码保证数据的弹性resiliency而纠删码需要将数据块分片然后放在不同结点因此每个FPN结点应该要跨越多个物理结点。Hydra并不直接用物理结点或者应该是存储服务器作为FPN结点而是如图2的底部每个FPN结点都跨越多个物理结点称之为超级结点supernode。每个超级结点跨越的物理结点个数称为超级结点维度supernode cardinality维度是一个重要的参数Hydra设为12。超级结点涉及的每个物理结点称为超级结点组件supernode component同一个超级结点的组件可以称为伙伴peer。 因此Hydra按超级结点为单位分配数据当一个数据块根据其哈希前缀被分配到超级块时再由超级结点内部决定如何跨物理结点存储。 1.2读写处理 写一个块时首先根据其哈希前缀决定由哪个超级结点负责再根据哈希前缀选出该超级结点的某个组件负责该块称为写处理伙伴write-handling peer。写处理伙伴会判断这个块是否重复如果重复就直接返回地址否则这个块会被压缩、分片并且按片分布到其它伙伴处。可见去重的好处是可以避免压缩、分片 读一个块时按照同样原则选出读处理伙伴read-handling peer。读处理伙伴会判断最少需要多少个分片才能重构数据块这个信息放在块的元数据里。接着读处理伙伴向一定数量的伙伴发送读请求如果请求都得到满足数据就读完了。如果存在请求失败读处理伙伴就会尝试去读剩下的所有分片。 1.3负载均衡 后端的负载均衡影响了系统的可用性如果某个物理结点放置了过多的超级结点组件那么这个结点的失效将会影响到很多超级结点。最理想的状态是每个物理结点根据其能力放置一定数量的组件。 Hydra不停地在尝试平衡组件的分布使得容错性性能和存储利用率都达到最优。一个特定分布的质量是由一个多维函数评价的称为系统熵system entropy。每个结点都在评估如果将部分组件传输给邻居结点系统是否会更加均衡。如果系统发现一个传输能改善分布就会执行传输。传输是很耗时的。 2.数据组织 前面部分介绍了数据块如何分布现在介绍的是每个块的分片具体以何种形式存储在物理结点。 2.1 synchrun和synchrun组件 Hydra使用纠删码提供数据冗余每个分片被分布在某个超级结点的一个伙伴上。由于数据块及其分片都是变长的不方便管理所以多个数据块逻辑上组成定长的synchrunsynchrun是数据管理的基本单元类似于RAID的条带。synchrun物理上被分为若干超级结点维数个synchrun组件。因此超级结点的第i个伙伴存储着synchrun的第i个组件存储着数据块的第i个分片。 在任意时刻写处理伙伴实际上只对一个synchrun写数据因此所有的synchrun按顺序组成了一个链。一个synchrun组件是以SCCsynchrun component container数据结构存储的。每个SCC可以包含一个或多个synchrun组件。SCC也组成了类似的链。 图3的第一行显示某个超级结点该超级结点覆盖了整个哈希空间即前缀为空的synchrun那些叠起来的矩形就是synchrun每个矩形为synchrun组件这里每个SCC只包含一个synchrun组件。每个synchrun组件内的小方框代表了一个数据块的分片。一个synchrun链可以表示成维度个SCC链。在图的剩余部分只显示了一条SCC链。 当超级结点存储了过多数据或者有新的结点加进系统时超级结点会分裂为两个新结点。例如图3的第二行该超级结点分裂为2个超级结点前缀分别为0和1。每个synchrun也都分裂为二其中的分片或者说synchrun组件根据其前缀分配到各自结点。这样的就得到了两个新的synchrun链。 分裂后的SCC显然变短了Hydra会将邻接的SCC合并防止系统有过多的SCC。图3的第三行显示了合并。SCC的目标大小是一个常量100MB。图3的剩余部分显示了删除操作删除后SCC也要进行合并。 Hydra是一个动态系统由于负载均衡导致的数据迁移需要将一个SCC链传输到另一个物理结点或者超级结点发生分裂。这些都不是立刻就能完成的而是用一个后台进程慢慢进行因此在任意时刻Hydra都可能有某个链分裂了一半或者迁移了一半。所幸Hydra提供了数据冗余在大多数情况下都有足够多的完整的链可以提供数据服务但是结点分裂时不是应该其所有SCC链都在分裂吗这该如何解决。 3.数据服务 Hydra提供诸如数据重建、去重、删除等数据服务。重建是靠纠删码。Hydra实现的是变长的、在线的、基于哈希比对的、全局数据去重如果一个块被认定重复就可以省去编码的时间所以有潜力提升性能。 删除是其中非常难的部分因为有数据去重。Hydra引入了一个只读阶段标记所有引用次数为0的块引用数不是立即更新的而是在每次只读阶段时更新自上次只读阶段以来的所有引用数。其中需要注意的问题是各个分片引用次数的一致性。在2013年的FAST上9livesdata专门讨论了删除问题。 转载于:https://my.oschina.net/fomy/blog/167519
