掌握HDFS2的新特性：HA和Federation

一、HDFS的新特性HA

(一)HDFS的HA机制

Hadoop 2.2.0 版本之前，NameNode是HDFS集群的单点故障点，每一个集群只有一个NameNode ，如果这个机器或者进程不可用，整个集群就无法使用，直到重启NameNode或者新重启一个NameNode节点 。

影响HDFS集群不可用主要包括以下两种情况：

(1)类似机器跌宕这样的意外情况将导致集群不可用，只有重启NameNode之后才可使用。

(2) 计划内的软件或硬件升级（NameNode节点）将导致集群在短时间范围内不可用。

HDFS的高可用性（HA ,High Availability）就可以解决上述问题，通过提供选择运行在同一集群中的一个热备用的 "主/备"两个冗余NameNode，允许在机器宕机或系统维护的时候，快速转移到另一个NameNode。

(二)典型的HA集群

一个典型的HA集群，两个单独的机器配置为NameNodes，在任何时候，一个NameNode处于活动状态，另一个处于待机状态，活动的NameNode负责处理集群中所有客户端的操作，待机时仅仅作为一个slave，保持足够的状态，如果有必要提供一个快速的故障转移。

为了保持备用节点与活动节点状态的同步，目前的实现需要两个节点同时访问一个共享存储设备（例如从NASNFS挂载）到一个目录。将有可能在未来的版本中放宽此限制。

当活动节点对命名空间进行任何修改，它将把修改记录写到共享目录下的一个日志文件，备用节点会监听这个目录，当发现更改时，它会把修改内容同步到自己的命名空间。备用节点在故障转移时，它将保证已经读取了所有共享目录内的更改记录，保证在发生故障前的状态与活动节点保持完全一致。

为了提供快速的故障转移，必须保证备用节点有最新的集群中块的位置信息，为了达到这一点，Datanode节点需要配置两个nameNode的位置，同时发送块的位置信息和心跳信息到两个nameNode。

任何时候只有一个namenode处于活动状态，对于HA集群的操作是至关重要的，否则两个节点之间的状态就会产生冲突，数据丢失或其它不正确的结果，为了达到这个目的或者所谓的“裂脑场景”出现，管理员必须为共享存储配置至少一个（fencing）方法。在宕机期间，如果不能确定之间的活动节点已经放弃活动状态，fencing进程负责中断以前的活动节点编辑存储的共享访问。这可以防止任何进一步的修改命名空间，允许新的活动节点安全地进行故障转移。

(三)HA架构

HA架构解释如下：

1、只有一个NameNode是Active的，并且只有这个ActiveNameNode能提供服务，改变NameNode。以后可以考虑让StandbyNameNode提供读服务。

2、提供手动Failover，在升级过程中，Failover在NameNode-DataNode之间写不变的情况下才能生效。

3、在之前的NameNode重新恢复之后，不能提供failback。

4、数据一致性比Failover更重要。

5、尽量少用特殊的硬件。

6、HA的设置和Failover都应该保证在两者操作错误或者配置错误的时候，不得导致数据损坏。

7、NameNode的短期垃圾回收不应该触发Failover。

8、DataNode会同时向NameNodeActive和NameNodeStandby汇报块的信息。NameNodeActive和NameNodeStandby通过NFS备份MetaData信息到一个磁盘上面。

(四)为什么会有HA机制

1、单点故障

在Hadoop 2.0之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结

A、Secondary NameNode。它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NameNode(以下简称NN)失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。

B、Backup NameNode (HADOOP-4539)。它在内存中复制了NN的当前状态，算是Warm Standby，可也就仅限于此，并没有failover等。它同样是阶段性的做checkpoint，也无法保证数据完整性。

C、手动把name.dir指向NFS。这是安全的Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。

D、Facebook AvatarNode。Facebook有强大的运维做后盾，所以Avatarnode只是Hot Standby，并没有自动切换，当主NN失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟IP映射到Standby NN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和Hadoop 2.0里的HA非常相似，从时间上来看，Hadoop 2.0应该是借鉴了Facebook的做法。

E、还有若干解决方案，基本都是依赖外部的HA机制，譬如DRBD，Linux HA，VMware的FT等等。

2、集群容量和集群性能

单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。Hadoop 2.0里的HDFS Federation就是为了解决这两个问题而开发的。

二、HDFS的新特性Federation

(一)单个Namenode的HDFS架构的局限性

1. Namespace（命名空间）的限制

由于Namenode在内存中存储所有的元数据（metadata），因此单个Namenode所能存储的对象（文件+块）数目受到Namenode所在JVM的heap size的限制。50G的heap能够存储20亿（200 million）个对象，这20亿个对象支持4000个datanode，12PB的存储（假设文件平均大小为40MB）。 随着数据的飞速增长，存储的需求也随之增长。单个datanode从4T增长到36T，集群的尺寸增长到8000个datanode。存储的需求从12PB增长到大于100PB。

2. 性能的瓶颈

由于是单个Namenode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个Namenode的吞吐量。毫无疑问，这将成为下一代MapReduce的瓶颈。

3. 隔离问题

由于HDFS仅有一个Namenode，无法隔离各个程序，因此HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序。那么在HDFS Federation中，可以用不同的Namespace来隔离不同的用户应用程序，使得不同Namespace Volume中的程序相互不影响。

4. 集群的可用性

在只有一个Namenode的HDFS中，此Namenode的宕机无疑会导致整个集群不可用。

5. Namespace和Block Management的紧密耦合

当前在Namenode中的Namespace和Block Management组合的紧密耦合关系会导致如果想要实现另外一套Namenode方案比较困难，而且也限制了其他想要直接使用块存储的应用。

6. 为什么纵向扩展目前的Namenode不可行？比如将Namenode的Heap空间扩大到512GB。

这样纵向扩展带来的第一个问题就是启动问题，启动花费的时间太长。当前具有50GB Heap Namenode的HDFS启动一次大概需要30分钟到2小时，那512GB的需要多久？ 第二个潜在的问题就是Namenode在Full GC时，如果发生错误将会导致整个集群宕机。 第三个问题是对大JVM Heap进行调试比较困难。优化Namenode的内存使用性价比比较低。

(二) 为什么要引入Federation

引入Federation的最主要原因是简单，其简单性是与真正的分布式Namenode相比而言的。Federation能够快速的解决了大部分单Namenode HDFS的问题。

Federation是简单鲁棒的设计，由于联盟中各个Namenode之间是相互独立的。Federation整个核心设计实现大概用了3.5个月。大部分改变是在Datanode、Config和Tools，而Namenode本身的改动非常少，这样Namenode原先的鲁棒性不会受到影响。比分布式的Namenode简单，虽然这种实现的扩展性比起真正的分布式的Namenode要小些，但是可以迅速满足需求。另外一个原因是Federation良好的向后兼容性，已有的单Namenode的部署配置不需要任何改变就可以继续工作。

因此Federation（联盟）是未来可选的方案之一。在Federation架构中可以无缝的支持目前单Namenode架构中的配置。

(三)HDFS的Federation机制

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

(四)Federation HDFS与当前HDFS的比较及改进

当前HDFS只有一个命名空间（Namespace），它使用全部的块。而Federation HDFS中有多个独立的命名空间（Namespace），并且每一个命名空间使用一个块池（block pool）。

当前HDFS中只有一组块。而Federation HDFS中有多组独立的块。块池（block pool）就是属于同一个命名空间的一组块。

当前HDFS由一个Namenode和一组datanode组成。而Federation HDFS由多个Namenode和一组datanode，每一个datanode会为多个块池（block pool）存储块。

1.Block Pool(块池)

所谓Block pool(块池)就是属于单个命名空间的一组block(块)。每一个datanode为所有的block pool存储块。Datanode是一个物理概念，而block pool是一个重新将block划分的逻辑概念。同一个datanode中可以存着属于多个block pool的多个块。Block pool允许一个命名空间在不通知其他命名空间的情况下为一个新的block创建Block ID。同时，一个Namenode失效不会影响其下的datanode为其他Namenode的服务。 当datanode与Namenode建立联系并开始会话后自动建立Block pool。每个block都有一个唯一的标识，这个标识我们称之为扩展的块ID（Extended Block ID）= BlockID+BlockID。这个扩展的块ID在HDFS集群之间都是唯一的，这为以后集群归并创造了条件。

Datanode中的数据结构都通过块池ID（BlockPoolID）索引，即datanode中的BlockMap，storage等都通过BPID索引。 在HDFS中，所有的更新、回滚都是以Namenode和BlockPool为单元发生的。即同一HDFS Federation中不同的Namenode/BlockPool之间没有什么关系。 Hadoop V0.23版本中Block Pool的管理功能依然放在了Namenode中，将来的版本中会将Block Pool的管理功能移动的新的功能节点中。

2.Datanode的改进

在datanode中，对应于每个Namnode都有一条相应的线程。每个datanode会去每一个Namenode注册，并且周期性的给所有的Namenode发送心跳及datanode的使用报告。Datanode还会给Namenode发送其所在的block pool的block report（块报告）。由于有多个Namenode同时存在，因此任何一个Namenode都可以随时动态加入、删除和更新。

3.Federation中的其他方面的改进

提供了工具，对于Namenode的初始化和退役的监控和管理。 允许在datanode级别或者block pool级别的负载均衡。 Datanode的后台守护进程，为Federation所做的磁盘和目录扫描。 提供了显示Namenode的Block pool的使用状态的Web UI。 还提供了对全部集群存储使用状态的UI展示。 在Web UI中列出了所有的Namenode及其细节，如Namenode-BlockPoolID和存储的使用状态，失去联系的、活的和死的块信息。还有前往各个Namenode Web UI的链接。 Datanode退役状态的展示。

4.多命名空间的管理问题

在一个集群中需要唯一的命名空间还是多个命名空间，核心问题命名空间中数据的共享和访问的问题。使用全局唯一的命名空间是解决数据共享和访问的一种方法。在多命名空间下，我们还可以使用Client Side Mount Table方式做到数据共享和访问。

5.Namespace Volume（命名空间卷）

一个Namespace和它的Block Pool合在一起称作Namespace Volume。Namespace Volume是一个独立完整的管理单元。当一个Namenode/Namespace被删除，与之相对应的Block Pool也也被删除。在升级时每一个Namespace Volume也会整体作为一个单元。

6.ClusterID

在HDFS Federation中添加了Cluster ID用来区分集群中的每个节点。当格式化一个Namenode时，这个ClusterID会自动生成或者手动提供。在格式化同一集群中其他Namenode时会用到这个ClusterID。

7.HDFS Federation对老版本的HDFS是兼容的

这种兼容性可以使得已有的Namenode配置不需要任何改变继续工作。

Hadoop 存储

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。