【元数据管理的高可用性和可扩展性】
(1)高可用:单个节点出现问题,服务仍旧可以用。
(2)可扩展:分布式做法线性提高扩展能力。

通常的做法是可以将这些节点做成多个备份,保证在一个备份出现问题的时候,仍然可以提供服务。但是多个备份间需要维护数据一致性,防止服务切换造成的数据不一致或者丢失。

【高可用性方案】

方案一:
HDFS中元数据的高可用性方案是引入了分布式锁服务ZooKeeper,每个NameNode的FailoverController来维护分布式锁状态,在出现锁丢失的情况下,触发主备切换。主NameNode将操作日志写入到共享数据存储的设备上,这样的设备可以是有DRBD功能的磁盘或者NFS系统。
这个实现方案相对简单,因为较复杂的功能都放到了锁服务和共享存储系统中。这样的做法也是非常经济实惠的,复杂性均由分布式系统的单个模块来维护,其他服务进行依赖,这种做法降低了软件的实现难度和维护工作量。

方案二:
阿里的盘古分布式文件系统Meta server之间采用了Paxos的特化Raft实现数据选举和同步,可以存在多个master的备份。

方案三:
在Ceph系统的元数据管理模块MDS从原理上来说使用了共享存储,每个MDS有一个Standby进程作为热备。但是其独特之处在于是利用了OSD同Ceph monitor组成的RADOS最为共享存储,这样的实现方法即保证了元数据管理的高可用,又提供了无限可扩展的能力,同时可以不依赖于其他系统做到了独立自包含。

【可扩展性方案】
方案一:
HDFS的可扩展性,Namespace切分的Fedeation。在HDFS Federation中NameNode的扩展性依赖于目录树的静态切分,每个目录子树被称为一个Volume,并将切分后的Volume分配到不同的NameNode上。DataNode则作为数据存储池,被所有的NameNode共享使用。为了让客户端可以找到某棵树中的节点,在client端需要加载ClientSideMountTable,这里记录了目录树同NameNode的对应关系,用户使用文件名访问元数据时,客户端首先用文件名从MountTable中获取NameNode的服务端口后,再发送元数据请求。
Federation的这种做法简单高效,静态划分的方法需要提前对各个NameNode未来元数据量有比较准确的估计,否则很容易造成各个NameNode间元数据的不平衡,给整个存储系统带来瓶颈。 盘古系统采用了同HDFS一样的解决方案,在实现过程中对应每个HDFS中的NameNode会部署一组盘古多master。盘古Federation除了用MountTable让用户透明访问系统外,还提供了新的访问方式。用户可以在文件名前指定Volume名称,这样可以绕过mount table的访问直接请求到某组盘古master上,这个功能可以有效防止集群中大量进程短时间启动时集中获取mount table带来的流量冲击。为了应对元数据不均衡的问题,盘古提供了在两个Volume间的元数据迁移工具。

方案二:
Ceph系统的MDS的扩展性用动态分裂功能实现,分裂依据是目录或者文件的请求频率。当用户请求某个路径的时候,将路径中的每个目录以及最终末端的节点或者目录上的请求统计值增加,然后通过定期来计算每个MDS中目录的请求频率来决定是否已经超过了MDS的负载而需要动态分裂。分裂过程中源MDS会元信息发送给目标MDS,并分别记录迁移日志。
这种动态分裂的方式可以有效解决局部访问热点带来的性能瓶颈,在元数据规模和处理能力方面都做了扩展,是比静态划分方法更好的设计和实现方式。

0
Posted in BigData

Leave a Comment:

电子邮件地址不会被公开。