Hadoop中HDFS文件系统NameNode的Federation设计文档(HDFS-1052：Hdfs scalability with multiple namenodes)

原文请参：
https://issues.apache.org/jira/browse/HDFS-1052
https://issues.apache.org/jira/secure/attachment/12453067/high-level-design.pdf

译文如下：

1 Introduction

Terminology:

Federated HDFS, Namenode Federation：容许多个namespace在一个Hdfs集群，并且在多个集群之间进行协作。这个文档中主要是指一个HDFS集群中，存在多个namespace

Horizontal Scaling：通过增加额外的单元来进行扩展，如servers。

Hdfs Cluster：当前集群是指，一个单一的Namespace(NameNode)以及多个Datanodes。新的集群是指，多个Namespace(NameNode)共享多个Datanodes的Storage

Namenode：一个能够访问Namespace的server

Namespace Volume：包含Namespace及其block集，独立的管理集合。

Vertical Scaling：通过使用更强大的unit，如大server，大memory，更多cores

目前的HDFS使用一个Namenode来管理Namespace，单一的NN导致了以下的缺陷：

1、Scalability：NN使用内存来管理的文件系统的metadata，内存的大小直接限制了文件系统的大小（包括Storage和Namespace）

2、Performance：文件系统吞吐量也完全由单一的NN限制

3、Isolation：多个私立的环境没法做到隔离，Namenode作为中心节点容易无法隔离各个环境

4、Availability：NN是HDFS集群的SPOF。

Limits to Vertical Scaling of Namenode

单一server的内存大小终究是有限的，优化NN去更有效的使用内存是一个很复杂的事情，另外大内存带来的GC问题，以及启动时间加长，调试内存信息也更困难，大JVM下调试工具支持有限。

1、1     Background

当前HDFS架构有两层，如下：

1、Namespace管理层：管理Namespace中的 directories, files and blocks。提供文件和目录的 creation/modification/deletion/listing

2、Block管理层：主要由两个部分组成：

1、Block管理：管理Datanodes，提供Block相关的操作，如： creation/deletion/modification/gettingLocation/ replicaPlacement/blockR eplication

2、Storage管理：物理存储管理，访问block数据

当前的HDFS实现架构如下：

1、NN实现Namespace和Block的管理。

DN提供物理的存储和访问Blk数据，DN注册到NN的blk管理层，为HDFS提供Storage层。尽管从现在代码来看，DN注册到NN，然后与NN进行通信，但是实际2、上DN仅仅与NN的blk管理层通信而不会参与的Namespace管理。

3、因此blk管理层一部分在DN中，一部分在NN中

现在的实现及JavaApi都没有提供比较干净的隔离

Block Identification：每个文件都是由一个或多个blk组成，每个blk有一个64位的数字id，在全局唯一。当前的集群中仅有一个Namespace和一个blk pool来做Storage。

2 Federated HDFS and Block Storage Architecture Overview

在这个设计中，为了提升Scalability，多个Namespace/Namenode会在一个集群中。每个Namespace Volume使用所有的DNs在一个或多个blk pools

HDFS Cluster 定义：

当前的HDFS：

1、一个HDFS集群的Namespace在单一的NN中实现，一个单一的 storage -pool由所有的DNs组成。

Federated HDFS：

1、多个独立的HDFS Namespace独自实现在各个分离的NN中

2、一个单一的 storage -pool由所有的DNs组成，DNs不会进行分区(partitioned)，DN能够给所有的NN提供Storage。整个Storage包含多个独立的blk-pools，每个blk-pools由单一的NN管理。

Salient features of Block Storage:

1、一个blk-pool是一个独立的blks集合，属于单一的Namespace。一个blk-pools在管理上和其他的pools是独立的，不需要与其他pools进行协调

blk管理，管理集群DNs来提供blk的Storage， 提供Block相关的操作，如： creation/deletion/modification/gettingLocation/ replicaPlacement/blockR eplication

2、DN提供共享的Storage层，存储属于所有blk-pools的blks

3、DN管理blk的归属，在blk-pool层次而不是在单一的blk层次。

4、每个DN和NN的blk管理层通信，如下：

1、注册及定期发送Heartbeat

2、为每个blk-pool发送BRs

3、接受NN对blk的管理命名(copy,delete,etc)

Salient features of Multiple Namespaces:

1、Namespace加上对应的blk-pool才称之为Namespace Volume。在管理上这是一个独立的单元。

2、GC独立：当NN/NS被删除时，对应的blk-pool也能被删除

3、Namespace Volume不需要与其他Namespace Volume协作

2、1     Benefits

Benefits of Block Storage Layer:

1、单独拎出block storage层次，好处在于：

a、能够在blk-storage-layer上实现一个non-hdfs的Namespace

b、Hbase之类的应用可以直接使用blk-storage-layer

c、blk-storage-layer的独立使得将来的分布式Namespace变得可能

2、多个应用公用同一个DN-pools(而不partitioned)使得storage能够更优化的被使用。其余优点在Appendix-B中详述。

3、正在调查特殊的blk-pools提供给mr作为temp storage

Benefits and drawbacks of multiple namespaces:

1、为Namespace及整个集群提供水平扩展。

2、多个NN使得可以将用户进行分区，提供可用性和可管理性

3、缺点在于：需要考虑多个Namespace和NN，Hdfs-1053在客户端通过client-side-mount来提供统一视图。

3 High Level Design

Terminology:

BP：Block Pool

Birthmark：实体的全局

 

（跨集群） 唯一标识

前面的架构讨论定义了一个抽象的层次，但没有提及到边界定义。这一节提供架构的具体实现，定义抽象层的各个部分都在哪个server中。下图描述的设计中，具有以下特性：

1、每个Namespace只用一个blk-pools（在一个Namespace中使用多个blk-pools在第一阶段中暂未支持）

2、和现阶段一致，一个Namenode包含两个层次(Namespace和blk-management)，一个Namenode管理一个Namespace Volume。尽管目前仍然由NN来实现这两个层次，但是目标还要将这两层从逻辑上彻底分开，方便后续很多工作

3、各个Namenode之间相互独立

4、整个集群作为一个整体或升级或rollback，和现在一样。

3 Managing Namespace Volumes and Block Pools

以下几点必须在设计blockpool的功能设计中考虑到：

1、一个由BlockPoolID标识的blockpool属于一个单一的Namespace，违反了这个规则将会发生错误，并且系统必须检测这个错误以及采取适当的措施。

2、DN在停止一段长时间之后，可能使用一个老的且不再使用的blokpool，因为其对应的Namespace可能已经被删除。

3、当DN或者人为的或无意的移动到另一个集群的时候，必须被检测到，而且DN上的BP不能与新cluster上的BP冲突。

4、可选：设计中必须考虑简化两个cluster的合并

3.1 Identifiers  

Block Pool ID：

一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。下表中对比描述当前集群与Federated集群的各种标识对比：

3.1.1 FAQ

1、为毛需要一个ClusterID？

通过全局的唯一的BlockPoolID或者NamespaceID 并不能解决问题， 在federation的情况下，一个DN需要与多个NN进行通信。如果一个DN无意中移到另一个Cluster，这个DN保留老的blocks，然后为新Cluster的NN创建新的blockpools，NamespaceID在这个情况下将不能阻止这种移动。

2、为毛blockpoolID需要全局唯一

a、与其由admin来配置这个全局唯一的BlockPoolID，还不如让程序生成

b、显然BlockPoolID必须在集群内唯一，还不如多增加几个字节来让它变成全局唯一

c、删除一个BlockPool将不需要考虑其ID 可能的被重用，之前确实考虑集群内唯一，还被迫加了一个BP-BirthMark来防止重用。

d、容许集群合并

e、如果BPID不唯一，那么BPID可能被重用，必须要使用BirthMark来区分。

3、为毛不直接使用NamespaceID来作为BlockPoolID(或者不需要BlockPoolID这个东西了)

a、错误的抽象层，block层并不关注谁在上层使用自己，因此这个名字必须是BlockPoolID，而不是NamespaceID(你可以争论用BlockPoolID来取代NamespaceID)

b、将来一个Namespace将支持多个blockpools

c、将来可以将一个blockpoo从一个NN移动到另一个NN上，那个时候NamespaceID唯一定义这个单一的owner

3.2 Namespace Volume management

3、2、1  Current Cluster and Namespace management

1、当期集群配置：

当前的集群配置在conf文件（ core‐site.xml/hdfs‐site.xml ）中，集群中所有的node都会share这个配置文件。DN使用这个配置来PrimaryNN沟通。

PrimaryNN设置以下两个文件：

1、dfs.include - 列举所有容许注册到NN的DN

2、dfs.exclude - 列举所有不容许注册到NN的DNs，如果一个DN之前已经注册了，一旦出现在这个文件上。那么该DN将会进行Decommission

另外，下面两个文件被用来启动及停止集群

1、master - 包含 SecondaryNameNode 的信息，启动脚本启动的时候，将会在这些nodes上面启动SecondaryNameNode。

2、slaves - 包含所有的datanodes信息，启动脚本将会在这些nodes上面启动datanode进程

2、当前Namespace的创建：

当一个NN被格式化的时候，会创建一个由NamespaceID唯一标识的Namespace。NameNode会将这个NamespaceID持久化并且在DN注册时候发送到DN。DN也会将这个NamespaceID持久化，然后DN仅仅与这个NN进行交互。

3、当前Namespace的删除：

格式化NN和所有的DN将会删除这个HDFS集群，但是没有办法通过NN来对DN进行全局格式化。

3.2.2 Federated Cluster and Namespace Volume management

1、新的集群配置方式

一个HDFS集群的初始化被视为在集群的第一个Namespace Volum创建的时候，在NN进行format的时候，如果带上"-newCluster"参数时，将会生成一个全局唯一的ClusterID和一个全局唯一的BlockPoolID并持久化在NN上：

1、后续的过程中，NN必须一直使用这个ClusterID

2、每个DN将会在注册的时候收到这个ClusterId，然后绑定到这个cluster。

3、任何时候，如果一个NN或者DN尝试加入到另一个cluster，那么另一个cluster上的NN或者DN必须拒绝。

下表列出新式集群配置

下面两个文件被用来启动及停止集群，HDFS代码并不会读取到。

1、master - 包含 SecondaryNameNode 的信息，启动脚本启动的时候，将会在这些nodes上面启动SecondaryNameNode。

2、slaves - 包含所有的datanodes信息，启动脚本将会在这些nodes上面启动datanode进程

2、 Namespace Volume creation

1、NN进行format的时候，会创建一个新的Namespace及对应的BlockPool。NN持久化NamespaceID和BlockPoolID

2、DN在registion之前的hanhshake中会获取NN的这些NamespaceID，BlockPoolID，ClusterID信息。在第一次DN注册到了NN上时，DN将会依据获取的这些信息来初始化一个新的BlockPool

3、 Adding a Namespace Volume (namenode) to the cluster

1、在新的NN进行format的时候，如果提供了一个ClusterID的话，那么NN只会生成BlockPoolID并且将它与提供的ClusterID持久化

2、集群中的DN将会收到NN-refresh命令去重新读取NN的配置文件：

每个DN注册到新的NN都会为这个NN的BlockPool创建一个新的Directory

如果DN宕机，在重启的时候也会读取到最新的配置文件并且注册到新的NN

4、 Adding a new datanodes to the cluster

1、首先在dfs.include文件中添加

2、格式化DN并启动

3、DN读取NN列表，并注册到每个NN上：

a、在注册到第一个NN的时候，DN就能获取到ClusterID并成为该集群的一部分

b、为每个NN创建一个directory来存储NN的BlockPool中的blocks

5、 Adding a new datanodes to the cluster

1、启动集群，删除所有NN的volume中的文件

2、重新格式化NN

3、在每个DN上发布delete BP命令，如果block pool没有block，那么立马就删除。如果带了"-force"命令，那么block pool中即使有block也会被删除。

6、 Move a namespace from one namenode to another namenode within a cluster

1、停止NN

2、拷贝必须的元数据(TBD)到另一个NN

3、在conf配置文件中更新NN的Address和DNS Name

4、确保老的Namenode有hi家停止，启动新的。

7、 Move part of a namespace from one namenode to another namenode

1、使用distcp拷贝文件

2、删除这个子空间

3、将来可能支持创建copy-on-write的快照，然后移动这个快照

8、 Move a namespace to another cluster

1、使用distcp复制该空间到另一个cluster

2、在第一个cluster中删除该空间

9、 Merging two clusters into a single Federated Cluster.

1、在两个集群都关闭的情况下，将其中的某个cluster的ClusterID重命名为另一个cluster的ClusterID。

2、合并两者的dfs.include和dfs.exclude

3、启动两个集群

4、可选：使用Balancer来进行存储均衡

5、更新client side mount table来支持透明访问两个集群

3.3 Block Storage

1、当前架构：

DN将block数据存储在本地文件系统的disk上，整个block存储的目录结构如下：

如Hadoop-702所示，目录 previous  and  current是在升级过程中保持数据的完整性而使用的。升级时，在NN和DN中创建文件快照，以备rollback使用。

在创建快照的过程中：

1、 <datadir>/current  移动到  <datadir>/previous

2、DN的元数据将在 <datadir>/current下创建

3、block文件在 <datadir>/current下创建，并被硬链接到Previous目录下

在rollback过程中，Previous目录移回到Current。

2、Federation下的block storage 架构

DN的存储目录架构需要改变并包含BlockPoolID，有以下三个选择：

选择1：这个架构仅支持DN级别的snapshot，单一的NN升级使得所有的blockpool进行快照，这个方案不适应于独立的Namenode升级管理操作

选择2：能解决选择1的blockpool级别的快照问题，但是为了能够进行rollback，<datadir>目录下的Previous目录仍是必须的，这个目录在升级的finalizing过程中被删除。

选择3：支持选项2的功能，并能支持DN级别的快照，如果未来DN的升级与DN解耦的话。而且还能支持各个NN在blockpool级别独立创建快照。

3.4 Single Checkpointer

当前每个PrimaryNN都一个CheckPointNN( either backup or secondary namenode )， CheckPointNN主要完成合并fsiamge和Editlog来产生新的Fsimage，为了减少节点数，可以使用单一的CheckpointerNN来为所有的PrimaryNN完成这个工作。细节工作留待实现阶段讨论。

3.5 Network Partition and Federated Cluster

在网络发生分区时，NN可能会和大片的DN失去联系，这可能导致replication风暴并把仅有的一些DN空间给占满。这个问题在当前集群也存在，但是在Federation的环境下，这个问题更糟，网络分区的时候，可能导致各个NN看到的DN不同。HDFS-779通过在丢失大片的replica的时候，将NN退回到safemode来解决了这个问题，

4 Cluster Management

4.1 Web UI

4.1.1 Namenode Web UI

1、Cluster Summary:

集群信息汇总的部分将会增加ClusterID，blockpoolID，storage使用情况等等。

2、 Live Nodes:

DN详细信息列表中也会增加 Block Pool Used  and  Block Pool Used %来表明各个blockpool占总空间的量和比重

3、 Decommissioning status:

展示每个blockpool的 Decommissioning status和整个DN的Decommissioning status

4.1.2 Cluster Web UI

NN的servlet和jsp将会产生结构化数据来帮助构建cluster web ui，主要包括以下信息：

1、展示整个集群的占用情况，NN列表，blockpool列表，blockpool使用情况，blockmissing信息，DN健康汇总数据

2、点击每个NN都会引导到NN web ui界面

4.2 Upgrade

4.2.1 Upgrade Mechanism

1、当前升级机制

当前的NN的升级将会引起整个集群的升级，当DN链接到NN时发现"ctime"和"layout-version"与自己的不匹配时，将会建立一个blocks的快照然后执行本地升级。整个集群由此升级到一个新版本，并且不能回退。

在Federation环境下，第一阶段，并不容许出现混合集群，即：一些NN和DN在不同的software version上运行。每个NN可以进行独立的升级，DN在注册到该NN阶段升级与之对应的blockpool。过程如下：

1、DN在pre-registration的handshake阶段获取NN的software version，如果DN运行在另一个版本，并且比NN的要新，那么将不会注册到该NN。然后DN定期尝试检查该NN是否更新了到新版本

2、在DN的 pre-registration的handshake阶段，如果DN的blockpool的 "ctime"和"layout-version"与NN的不同时，那么DN会将该blockpool创建快照并且进行升级。别的blockpool将不会改变

3、在rollback过程找那个，DN将会rollback所有的blockpool。如果集群中的某个NN没有rollback，DN将不会注册到该NN，然后定期重试等待该NNrollback。

注：如果集群中仅有一个NN升级了，其余的因为某些原因失败了。那么这个集群的上job可能在一个Namespace不在情况下仍然可以跑。当admin使得其余的NN可以进行升级并升级之后，DN将会尝试链接新的NN，然后创建快照进行升级。这个过程会影响正在跑的job。为了避免这样的情况，可以设置设置一个选项使DN在下一个预定的升级阶段之前不会重试链接新NN。

4.2.2 Upgrading to Federation release

Namenode changes

1、NN刚刚启动时候创建BlockpoolID，ClusterID，并持久化到VERSION文件中

2、NN加载该新的BlockPooID下所有的blocks到内存中。

Datanode changes:

1、启动之后，存储该新的ClusterID

2、在首次注册的时候，发送的StorageID及BlockPoolID都为null

3、从注册返回信息中获取ClusterID，NamespaceID，BlockPoolID，如果该DN上还木有任何的BlockPoolID，DN将所有的blocks移动到新的BlockPoolID下。

4、DN将发送该BlockPoolID下的Block Report

rollback仍然和之前的一样，只需将 <datadir>/previous 移动到 <datadir>/current.

4.2.3 Backward compatibility

扩展BlockID类为 ExtendedBlockID 来BlockPoolID字段，这个改变最好不能改变用户的application，而只能影响到input/output流，对application而言是不可见的。

4.3 Decommissioning

当前的Decommissioning工作流程如下：

1、DN首先加入dfs.exclude，并且在NN端进行refresh node list

2、NN将该DN的状态标记为 decommission_in_progress并且开始为该DN进行blocks进行replication

3、DN的状态在web ui上展示

4、当replication完成了之后，DN将会标记为Decommissioned，最后会shutdown。

在Federation下， 当所有的BlockPool中的所有的blocks都完成了replication时， DN才会变成Decommissioned。新的工具提供：

1、开始decommissioning过程

2、查询decommission状态

3、这个工具可以在集群中的任何一个节点上开始运行

新的decommissioing过程如下：

1、DN加入到dfs.exclude，新的工具通过ssh传送该exclude文件到所有的NN并开始进行decommissioing。然后NN开始进行decommissioing和现阶段的decommissioing过程一样

2、各个NN将各自在该DN上BlockPool的block进行replicate，当所有的blocks完成了replicate，那么NN更新DN的状态为decommissioned。但是NN并不会关闭该DN。

3、新的工具将查询所有的NN进行关于该DN的decommission状态，主要有如下状体：

1、 Decommissioned 此时所有的NN已将该DN标识为decommissioned

2、 Decommissioning Started 如果所有的NN要么标识该DN为 decommissioned 要么为 decommission_in_progress  .

3、 Decomissioning  Partially Started 如果某些NN没有标识该DN为正常的decommission状态( not  decommissioned  or  decommission_in_progress )，这可能由于某些NN不可达到，或者NN在start decommission命令之后刚刚加入，或者接到命令之后重启了，等等。这个时候需要重新运行该start decommission命令，因为该命令是幂等。

4、新工具将会提供shutdown已经完成Decommission的DN。

4.4 Distributed Upgrade

Distributed upgrade并不在本地执行，而是需要集群中的nodes进行协作。例如：当CRC被移动到meta文件，DN之间需要通信来确认同一个block的crc是一致的。Federation本身并不需要进行 Distributed upgrade，未来有需要进行 Distributed upgrade的时候，必须要考虑到Federation的情况。

4.5 Balancer

1、当前均衡机制

当前balancer与单一的NN协同工作，NN中有所有的DN的资源占用信息，如果Banlancer指定了阀值t%作为输入，那么DN的Balance过程在以下情况下将会触发：

2、Federation下的存储均衡机制

由于BlockPool的存在，存储均衡的目标是：

1、与当前一样必须要均衡DN的存储

2、另外，每个BlockPool必须满足：

均衡机制如下：

Balancer均衡所有的blockpool，当所有的blockpool都被均衡。DN也就均衡了，Balancing算法的机制如下：

while (cluster_balanced is not true) {

// Balance one block pool at a time – as much as possible

for (block pool b : block pool list) {

if (b is not balanced)

balance b as much as possible or for time unit x;

}

if (all block pools are balanced)

cluster_balanced = true;

}

4.6 Cluster startup/shutdown

现阶段HDFS使用start-all.sh和start-dfs.sh来启动或停止NNs和DNs。salves机器从任列出所有的DN，集群中任何一个机器上都能够发起该命令。

有了blockpool之后，需要以下脚本：

1、启动或停止集群中所有的DN

2、 启动或停止集群中所有的NN，指定的某些NN，某个NN

3、启动或停止整个集群(所有的DN和NN)

5 Security

当前JobTracker使用delegation tokens来代表用户提交job，taskes在与NN交互的过程中使用合适的delegation token。在向NN发起请求时，DFSCilent已经处理了这个。
Client side mount table将包含多个delegation token来与多个NN交互，通信时client必须选择合适的delegation token。

DFSClient现在已经能够使用delegation token与DN交互。加入Federation之后，该token需要包含blockpool和block的信息

Appendix A ‐ Use Cases

Following use cases have been considered in the document:

Use case 1. Creating a new Federated HDFS Cluster

See section 4.2.2.1

Use case 2. Adding datanodes to a cluster

See section 4.2.2.4

Use case 3. Adding a namenode/namespace volume to a cluster

See section 4.2.2.3

Use case 4. Delete a namenode/namespace volume from a cluster

See section 4.2.2.5

Use case 5. Datanode is misconfigured and accidentally moved to a cluster

Use case 6. Move a namespace from one namenode to a different namenode with in the cluster

See section 4.2.2.6

Use case 7. Move a part of namespace from one namenode to a different namenode with in the cluster

See section 4.2.2.7

Use case 8. Move a namespace from one cluster to another cluster.

See section 4.2.2.8

Use case 9. Upgrade cluster from old release to a new release with federation

See section 5.2.2

Use case 10. Rollback a cluster from release with federation back to the previous release

See section 5.2.2

Use case 11. Decommissioning datanodes

See section 5.4

Use case 12. Balancing storage utilization

See section 5.5

Use case 13. Centralized cluster monitoring

See section 5.1

Use case 14. Merging two cluster into a single federated HDFS cluster

Section 4.2.2.9

Following use cases are not considered in the document:

Use case 15. Splitting a federated cluster into multiple clusters.

Appendix B ‐ Separating Block Storage Layer

在HDFS中block storage是一个独立的层次，Namespace用它来存储blocks，下图展示Block Storage层的接口

分离出Block storage层具有以下优势：

1、将Namespace从Block storage干净的分离出来

2、其他应用可以绕过Namespace/Namenode来从Block Storage中获取block信息。

依据block管理层的位置，下面两个情况变得可能：

1、 Block Storage interface as a library  ‐ 作为一个lib包被应用引入，如NN中引入该lib包

2、Block Storage as a service ‐ 用几个独立的nodes来提供服务，这些nodes与DNs构成存储集群。

将Storeage层作为一个独立的服务能够解决：

1、容易的扩展block管理层，考虑到blockid的空间是平的，可以采用hashing来在多个blockmanager nodes上分布blocks/blockpools。

2、应用可以独立block管理层进行扩展，另外应用也无需要关注头痛的replication storm，DN失效等

3、上层应用无须进行协作，而blockmanagement层需要进行协作来得到整个集群的存储状态，这样能够带来：

1、简化和减少DN与blockmanager的交互，如注册，Heartbeat

2、Blockmanager层能够更高效的进行Balancing，Decommissioning，处理network partions

4、Blockmanager提供中心化的集群WebUI，来管理，启动，停止这个集群。

Appendix C – Namenode and Datanode metadata changes

DN存储目录

1、以下文件将会保留，并且不做改变

<data>/in_use.lock

<data>/storage

2、下表中的文件/目录将会改变以增加bpid

3、DN VERSION 文件

当前DN的VERSION文件在 <data>/current/VERSION，并且包含以下信息：

o   Type of node (DATA_NODE)

o  StorageID

o  NamespaceID

o  ctime

o  LayoutVersion

Federation下，这个文件被查房成两个，包含以下信息：

1. <data>/current/ID

o Type of node (DATA_NODE)

o StorageID

o ClusterID

2. <data>/current>/bpid/VERSION (one for each block pool)

o NamespaceID

o BlockPoolID

o ctime

o LayoutVersion

4、NameNode VERSION文件

当前的NN下的VERSION文件存储以下信息：

o Type of node (NAME_NODE)

o NamespaceID

o ctime

o LayoutVersion

Federation下该文件被拆分成：

1. <data>/ID

o ClusterID

o NamespaceID

o BlockPoolID

o Type of node (NAME_NODE)

2. <data>/VERSION

o ctime

o LayoutVersion

Appendix D ‐ Namespace Volume creation

1、更新hdfs_nn.xml包含新的NN

2、在NN上运行format-NN，NN生成唯一的BlockPoolID并持久化到ID文件(该文件持久化 ClusterID, NamespaceID  ,  BlockPoolID , type of node )。VERSION文件包含 ( ctime ,  LayoutVersion )。 具体请看： Appendix C.

3、在DN上，发送一个refresh-nn命令到每个DN，每个DN将会注册到新的NN。

1、在DN首次注册到新NN并发现该新的Namespace/block pool时，过程如下：

1、DN发起versionRequest请求

2、NN在响应中发送NamespaceInfo( LayoutVersion, NamespaceID, BlockPoolID, ctime,BuildVersion, DistributedUpgradeVersion )

3、如果DN没有任何ClusterID，那么DN将会保存ClusterID，StorageID，NodeType等到ID文件

4、DN格式化新的BlockPool，并将信息持久化到各个BlockPool目录下的VERSION文件( LayoutVersion ,  NamespaceID ,  BlockPoolID ,   ctime )，具体见Appendix C。

2、DN的后续启动注册过程中

1、DN发起versionRequest请求
2、NN在响应中发送NamespaceInfo( LayoutVersion, NamespaceID, BlockPoolID, ctime,BuildVersion, DistributedUpgradeVersion )

3、如果DN的ClusterID与NN响应的不一致，那么DN将不会进行注册，log一条warning信息。

4、如果某个NamespaceID下，DN的BlockPoolID与NN响应的不一致，那么DN将不会注册到NN

5、如果所有的ID都一致，DN将发起注册，并传送参数 BlockPoolID  , NamespaceID and  ClusterID .

6、如果NN发现任何的ID不一致的情况，将会拒绝DN的注册。

4、DN将BlockPoolID保存在version文件中(如果DN还没有这个BlockPoolID，如果该DN已经有了该BlockPoolID，那么他就会拿各个ID与NN的对比，如果任何的ID不匹配将会导致注册过程中止

Appendix E – Future Improvements

本节讨论与Federation相关后续优化

1、 HDFS Layout Version improvements:

目前HDFS集群中DN与NN都是使用统一的LayoutVersion，所以任何LayoutVersion的改变都会导致NN和DN的升级。这个应该划分为两个LayoutVersion，从而可以帮助各个Ndoe独立的进行升级

2、 Decommissioning improvement:

当前HDFS使用dfs.exclude来指定被禁止与该NN进行注册的DNs，另外NN也用这个文件来指定已经注册到NN的DN从集群中下线。可以增加一个单独的文件来追踪需要下线的nodes，这个可以从语义上解决dfs.exclude的双重角色。已经Decommissioned的DN将不能注册到NN，但是如果在decommissioning过程中发生了cluster重启，那么可能导致这样的nodes会加入到集群中，这会导致数据丢失。不过这个可以通过容许Decommissioned的DN作为read-only的角色加入到集群中来解决