Hadoop单节点故障改进方案对比

202次阅读

共计 8772 个字符，预计需要花费 22 分钟才能阅读完成。

HDFS 单点改造方案对比

1 背景

目前，HDFS集群的架构包括了单个 Name Node 和若干个 DataNode。Name Node 负责两方面的事情：一方面是存储和管理整个命名空间，包括创建、修改、删除和列举文件目录等文件系统级别的操作；另一方面是管理 Data Node 和文件块。Data Node主要负责文件块的持久化存储和远程访问。

1.1 命名空间管理

HDFS 的命名空间包含目录、文件和块。命名空间管理：是指命名空间支持对 HDFS 中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作

1.2 块管理

A) 处理 Data Node 向 NameNode 注册的请求，处理 datanode 的成员关系，处理来自 DataNode 周期性的心跳。

B) 处理来自块的报告信息，维护块的位置信息。

C) 处理与块相关的操作：块的创建、删除、修改及获取块信息。

D) 管理副本放置（replica placement）和块的复制及多余块的删除。

目前 HDFS 为单 NameNode 模式，Namenode 运行时将元数据及其块映射关系加载到内存中，随着集群数据量的增大，Namenode 的内存空间也会遇到瓶颈。据实际生产经验统计如下：

文件数

数据块数

内存空间占用

3 千万

约 12GB

块管理 ≈ 7.8G，包括全部块副本信息

目录树 ≈ 4.3G，目录层次结构，包含文件块列表信息

10 亿

约 380GB

块管理 ≈ 240GB

目录树 ≈ 140GB

注：淘宝与百度等均以支撑 10 亿的文件数为设计目标，京东文件系统的业务对象主要为图片，电子书等，10 亿文件量可能只是时间问题。

2 方案对比

2.1 Federation HDFS

HDFS Federation 使用了多个独立的 Namenode/namespace 来使得 HDFS 的命名服务能够水平扩展。在 HDFS Federation 中的 Namenode 之间是联盟关系，他们之间相互独立且不需要相互协调。HDFS Federation 中的 Namenode 提供了提供了命名空间和块管理功能。Federation 中引入了 block pool 的概念，负责对该命名空间的数据块进行管理。命名空间和它所拥有的 BlockPool 统称为一个 Namespace Volume。datanode 被所有的 Namenode 用作公共存储块的地方。每一个 datanode 都会向所在集群中所有的 Namenode 注册，并且会周期性的发送心跳和块信息报告，同时处理来自 Namenode 的指令。

优点：namenode 增加了集群存储数据容量与访问的并发处理，namenode 中分为了 2 个部分: 命名空间管理及其数据块管理；单个 namenode down 掉重启需要的时间比集中到一个 namenode 需要的时间变短；降低集群整体不可用的风险。

缺点：集群失去了统一的命名空间管理，单个 namenode down 掉对应该 namenode 的数据不可访问；多命名空间独立而不支持统一命名空间；

2.2 HDFS2

百度从 2007 年开始使用 Hadoop，我们相信从那时候开始，HDFS 逐渐开始被改造。从百度 HDFS2 的架构图可以看出大致分为 2 层，上面一层为命名空间管理，类似 Federation 的多命名空间设计思路，提供了几种命名空间管理方式：层级命名空间管理；S3 扁平化命名空间管理；用户定制化命名空间。3 者是平级的。文件管理与块管理不再包括在 namenode。在对象管理层，整合了文件管理与块管理功能，同时也负责了数据块存储。

优点：

1、大部分耗时操作都属于文件对象管理层，不用经过 Namespace

2、最耗 CPU 资源的若干操作中，仍需经过 Namespace 的只占 13.7%

3、命名空间管理不再维护块信息，大部分操作都不需要加全局锁，可以更充分利用 CPU 资源；

4、文件对象管理服务直接就是水平可扩展的；

5、文件对象管理做为单独服务存在，可挂载不同类型命名空间，如 S3；

6、改造后，10 亿文件量，文件 ≈66GB，目录 ≈ 1GB，单节点命名空间就可以管理；

缺点：

HDFS2现阶段版本没有实现高可用性；

HDFS2 借鉴了 Lustre，Ceph，S3 等的设计思想，调研结果如下：

	Lustre	Ceph	GFS2
分布式元数据组织策略	随机，轮询等；各节点平坦存放 INODE 信息	动态子树分割，元数据服务维护 INODE 到根目录的路径；子树修改可以同步到每一个节点上的子树副本；
独立块，对象管理层	是	是，独立的对象管理层 RADOS，通过 P2PW 维护内部的数据一致性和副本安全	推测是
元数据存储策略	共享对象存储	共享对象存储	共享存储 bigtable
元数据定位	路径查询和权限控制需要根据目录层级遍历多个元数据服务。解决性能问题采用了客户端缓存和分布式锁机制	无需跨多台
特色		RADOS，CRUSH	支持小文件存储；支持低延迟的交互式请求

由于这些资料都不是官方发布，我们通过公布的一些架构图大致可以推断一些设计：

1、在命名空间部分，用到了静态子树，动态子树分割，及其 hash 算法，猜测其树状命名空间是跨越节点的；

2、对象层有文件管理及其块管理，猜测可能先通过树状命名空间获得文件的 inode，及其位置，然后客户端直接到相应节点读取文件元数据，通过文件对象找到其块映射，及其块与 datenode 的映射关系，然后客户端再直接与 datenode 通信，进行相关块的读写操作，在树状命名空间，后面的对象层均可以实现冗余及其修复机制。

3、像亚马逊的 S3，文件系统最大的问题就是扩展性，完全取决于他的树状结构，扩展起来相当困难。亚马逊解决存储服务的时候，抛弃了树状，采取了很平坦的结构，对象存储的概念。S3 对象存储概念，使得亚马逊支撑对象数可以支撑上千亿，是现在最大的存储集群。实现了 S3 的平坦两层命名空间，可用于存储百度的图片，MP3，PPT。当然如网盘类的应用可采用树状结构的命名空间。

相关阅读：

Ubuntu 13.04 上搭建 Hadoop 环境 http://www.linuxidc.com/Linux/2013-06/86106.htm

Ubuntu 12.10 +Hadoop 1.2.1 版本集群配置 http://www.linuxidc.com/Linux/2013-09/90600.htm

Ubuntu 上搭建 Hadoop 环境（单机模式 + 伪分布模式）http://www.linuxidc.com/Linux/2013-01/77681.htm

Ubuntu 下 Hadoop 环境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm

单机版搭建 Hadoop 环境图文教程详解 http://www.linuxidc.com/Linux/2012-02/53927.htm

搭建 Hadoop 环境（在 Winodws 环境下用虚拟机虚拟两个 Ubuntu 系统进行搭建）http://www.linuxidc.com/Linux/2011-12/48894.htm

2.3 ADFS（TBFS）

ADFS 的现有架构从上到下分为三层，如图表 1 所示: 最上层 (StateManager, Zookeeper 和 MetaChecker) 负责元数据持久化和校验，无状态的中间层 (Stateless Namenode) 负责事务逻辑和最底层 (Datanode) 负责文件块的物理存储和访问。将命名空间 (Namespace)、块对应关系(BlocksMap) 和 Datanode 信息存储到 innode 数据库中，避免了重启时需要通过 Datanode 的 blockReport 来构建 BlocksMap 和 Datanode 信息，提供了快速重启的必要条件。通过缓存，SSD 和 RAID 卡来提高 IO 性能等来提高性能。通过MetaChecker 异步地检查元数据的正确性。Zookeeper 在 ADFS 的架构中也承担比较重要的角色，它不仅负责记录租约，正在写入的文件，以及多块、少块和坏块等结构，而且还负责 State Manager 的主备选举。以后会将 Zookeeper 负责的 namenode 部分的功能放到数据库中，Zookeeper 仅负责主备选举。通过配置文件，和 Zookeeper 替换 namenode。

优点：单个 namenode down 掉可以快速切换，提供正常服务；元数据等持久化，namenode 重启等不需要很长的时间；

缺点：元数据持久化，数据库应该有瓶颈；同时服务的仅一个 namenode，因此仍然存在性能瓶颈

2.4 XFS

命名空间由 Master 进行管理，XFS 的 Master 通过主从热备实现了高可用解决方案，由 Zookeeper 实现监控、选举和切换；文件标识和块管理由独立的 MetaServer 进行管理，它记录了文件属性、长度以及该文件拥有的块等信息；与 Datanode 类似，块物理存储和访问由 NodeServer 负责。客户端在访问 XFS 时，先通过文件名在 Master 上获取 MetaServer 标识和文件标识等信息，然后在指定的 MetaServer 上获得需要请求的文件信息或者块信息，如果要访问文件的块，则通过 NodeServer 获取块内容。

实现推测：

1、master 部分实现了一个简单的命名空间如树形结构，文件 id，Meta id 等，客户端获得这些值到元数据服务器去获得文件的其他属性，及其块映射关系；

2、客户端通过获得的块位置到相应的 NodeServer 节点操作相应的数据块；

3、Master 通过 Zookeeper 实现高可用，元数据服务器可以实现冗余模式保证高可用；

Xfs 架构图如下

Hadoop 单节点故障改进方案对比

2.5 MAPR

通过官方介绍，实现了无锁存储服务，据说比 hdfs 速度快 3 倍；namenode 实现分布式话，默认存储 3 份，可以指定元数据存储分数，并且具有自动修复功能，如果某台机器坏了，会在其他机器修复该元数据，保存该数据始终有 3 份。

2.6 Clover

由中科院研发，实现了元数据的分布式冗余

2.7 Ceph

Ceph 为一个分布式存储系统，提供了 restful 及其 fuse（目前可能已经实现内核态）接口，元数据存储和对象存储均实现了支持冗余分布式，元数据与对象分开存储，客户端通过元数据服务器获得对象的位置，然后通过客户端直接获取。

CEPH 采用元数据和文件数据分开处理的体系结构，由三个子系统组成：客户端 (CLIENT)，元数据服务器集群(Metadata Cluster) 和对象存储集群(Object StorageCluster)。MDS 维护全局的名字空间，负责处理元数据相关的请求以及相心的权限管理：对象存储设备负责文

件数据和元数据的存储，为客户端和 MDS 提供统一的数据读写服务。在 CEPH 中，元数据保存在对象存储设备中，MDS 幂 IJ 用缓存的数据对外提供服务。由于 MDS 本身并不

存储数据，所以可以很方便地进行目录子树的复制迁移以实现负载均衡。通过监控访问的热度等进行负载均衡。

2.8 其他

AvatarNode

通过 NFS 共享 EditLog 文件，人工切换 namenode，可在秒到分钟内完成；

优点：由于采用热备，单个 namenodedown 掉可以快速切换，提供正常服务；

缺点：同时服务的仅一个 namenode，因此仍然存在性能瓶颈；

Cloudera CDH4 与 AvatarNode 类似。

2.9 命名空间

存储系统都涉及到命名空间的概念，从上面的调研已经明确，命名空间一般分为 2 类：树形命名空间和平坦命名空间。具体如下：

树形命名空间：元数据以树形结构维护，文件系统最大的问题就是扩展性，完全取决于他的树状结构，扩展起来相当困难。

平坦命名空间：元数据以 2 层或者层数很少来维护，实现对象存储的概念。亚马逊支撑对象数可以支撑上千亿，是现在最大的存储集群。

不同业务，可能命名空间选择不一样。

2.10 元数据管理

动态子树：出现热点数据或者 MDS 负载过高时可以很方便地进行目录子树的复制和迁

移，易于扩展 MDS 和负载均衡，但实现较为复杂。

静态子树：元数据与 MDS 的对应关系一旦确立就不会改变，容易出现负载不均衡。

Hash 算法：初始的时候，可以通过良好的设计使得元数据在 MDS 间均匀分布，整体负载比较均衡，但是在增加或减少 MDS 的时候，需要重新调整 hash 函数，会导致人量的数据迁移。