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

旧城等待， 2022-08-09 15:50 137阅读 0赞

原文请参：  
[https://issues.apache.org/jira/browse/HDFS-1052][https_issues.apache.org_jira_browse_HDFS-1052]  
[https://issues.apache.org/jira/secure/attachment/12453067/high-level-design.pdf][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都没有提供比较干净的隔离

> ![1348756520_3160.png][]

> 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管理。

> > ![1348756525_6493.png][]
> 
> 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中。下图描述的设计中，具有以下特性：

> > ![1348756661_6165.png][]
> 
> > 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集群的各种标识对比：
> 
> > ![1348756669_9450.png][]

> 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必须拒绝。
> > 
> > 下表列出新式集群配置
> 
> > ![1348757158_4608.png][]  
> >

> > 下面两个文件被用来启动及停止集群，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存储的目录结构如下：
> 
> > ![1348756679_5923.png][]
> 
> > 如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，有以下三个选择：
> 
> > ![1348756685_6485.png][]
> 
> > 选择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过程在以下情况下将会触发：
> 
> > ![1348756690_1576.png][]

> > 2、Federation下的存储均衡机制
> 
> > 由于BlockPool的存在，存储均衡的目标是：

> > > 1、与当前一样必须要均衡DN的存储
> 
> > > 2、另外，每个BlockPool必须满足：

> > ![1348756695_4694.png][]
> 
> > 均衡机制如下：

> > > 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层的接口
> 
> ![1348756703_3828.png][]

> 分离出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

> > ![1348756710_8564.png][]

> 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的角色加入到集群中来解决

[https_issues.apache.org_jira_browse_HDFS-1052]: https://issues.apache.org/jira/browse/HDFS-1052
[https_issues.apache.org_jira_secure_attachment_12453067_high-level-design.pdf]: https://issues.apache.org/jira/secure/attachment/12453067/high-level-design.pdf
[1348756520_3160.png]: https://img-my.csdn.net/uploads/201209/27/1348756520_3160.png
[1348756525_6493.png]: https://img-my.csdn.net/uploads/201209/27/1348756525_6493.png
[1348756661_6165.png]: https://img-my.csdn.net/uploads/201209/27/1348756661_6165.png
[1348756669_9450.png]: https://img-my.csdn.net/uploads/201209/27/1348756669_9450.png
[1348757158_4608.png]: https://img-my.csdn.net/uploads/201209/27/1348757158_4608.png
[1348756679_5923.png]: https://img-my.csdn.net/uploads/201209/27/1348756679_5923.png
[1348756685_6485.png]: https://img-my.csdn.net/uploads/201209/27/1348756685_6485.png
[1348756690_1576.png]: https://img-my.csdn.net/uploads/201209/27/1348756690_1576.png
[1348756695_4694.png]: https://img-my.csdn.net/uploads/201209/27/1348756695_4694.png
[1348756703_3828.png]: https://img-my.csdn.net/uploads/201209/27/1348756703_3828.png
[1348756710_8564.png]: https://img-my.csdn.net/uploads/201209/27/1348756710_8564.png