Hypertable高可用完善架构

    在Hypertable或其他类似BigTable的系统中，元数据一般采用一种两级的类B+树结构，这主要是出于规模的考虑：采用这种结构理论上可以支持存放并索引2EB的用户数据。若要索引这么多用户数据，所需的元数据就高达16TB,一台机器是存不下的，因此在类BigTable系统中，元数据也是分布在不同节点上进行管理的，集群中任意一个节点既可能包含用户Range也可能包含元数据Range.

 

 

    虽然这种做法可以解决规模问题，但在管理上带来了一些困难，特别是进行故障恢复时，由于用户表的Range恢复过程中需要读取元数据，所以必须先恢复METADATA表中的Range,再恢复用户表中的Range.如果有多台Range Server同时故障，这种跨节点的依赖性处理起来非常困难，其他一些维护性操作同样具有类似问题。此外，由于一条METADATA实际上覆盖了一个200MB的Range,所以任何一台包含METADATA的Range Server发生故障，都可能导致这部分METADATA所涵盖的一大批数据不可访问。将METADATA分布到多个不同的Range Server上，无异于给系统增加了很多单点，降低了系统可靠性。

 

 

    解决：本着简单原则，我们认为将元数据与用户数据分离，放在专用的Meta Range Server上更具有可操作性。元数据集中化的唯一缺点是，由于受Meta Range Server内存限制，32GB物理内存所能存放的元数据理论上只能支持上PB的用户数据。但考虑一般机房所能容纳的机器规模，PB级的数据规模完全可以满足大多数公司的需要。

 

 

 

    图3 Hypertable高可用改进架构示意图

 

 

    图3给出了Hypertable元数据集中管理的整体结构。目前的实现将Hypertable中的数据服务器（Range Server）分为两种：Meta Range Server和User Range Server.Meta Range Server只管理Root表和METADATA表的Range,User Range Server只管理用户表的Range.由于Master的负载较轻，因此一般将Meta Range Server与Master放在同一个节点上。

 

 

    系统启动时，每个Range Server从配置文件得知自己的类型，并在注册时汇报自己的类型。Master记录每台Range Server的信息。当Master需要将Range分配给Range Server时（例如表格创建和Range分裂），会根据Range所在表格的类型来选择合适的Range Server,元数据Range分配到Meta Range Server,用户Range则分配到User Range Server.