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

译文如下：
[align=left]1 Introduction[/align]

[align=left]Terminology:[/align]
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集，独立的管理集合。
[align=left]Vertical Scaling：通过使用更强大的unit，如大server，大memory，更多cores[/align]
[align=left]目前的HDFS使用一个Namenode来管理Namespace，单一的NN导致了以下的缺陷：[/align]

[align=left]1、Scalability：NN使用内存来管理的文件系统的metadata，内存的大小直接限制了文件系统的大小（包括Storage和Namespace）[/align]
[align=left]2、Performance：文件系统吞吐量也完全由单一的NN限制[/align]
[align=left]3、Isolation：多个私立的环境没法做到隔离，Namenode作为中心节点容易无法隔离各个环境[/align]
[align=left]4、Availability：NN是HDFS集群的SPOF。[/align]

[align=left]Limits to Vertical Scaling of Namenode[/align]

单一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/blockReplication
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都没有提供比较干净的隔离



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

[align=left]2 Federated HDFS and Block Storage Architecture Overview[/align]

在这个设计中，为了提升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管理。



[align=left]Salient features of Block Storage:[/align]

1、一个blk-pool是一个独立的blks集合，属于单一的Namespace。一个blk-pools在管理上和其他的pools是独立的，不需要与其他pools进行协调
blk管理，管理集群DNs来提供blk的Storage，提供Block相关的操作，如：creation/deletion/modification/gettingLocation/replicaPlacement/blockReplication
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)

[align=left]Salient features of Multiple Namespaces:[/align]

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

[align=left]2、GC独立：当NN/NS被删除时，对应的blk-pool也能被删除[/align]
[align=left]3、Namespace Volume不需要与其他Namespace Volume协作[/align]

2、1 Benefits
[align=left]Benefits of Block Storage Layer:[/align]

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

[align=left]Benefits and drawbacks of multiple namespaces:[/align]

1、为Namespace及整个集群提供水平扩展。
2、多个NN使得可以将用户进行分区，提供可用性和可管理性
3、缺点在于：需要考虑多个Namespace和NN，Hdfs-1053在客户端通过client-side-mount来提供统一视图。

[align=left]3 High Level Design[/align]

[align=left]Terminology:[/align]

[align=left]BP：Block Pool[/align]

[align=left]Birthmark：实体的全局[/align]

（跨集群）唯一标识

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



1、每个Namespace只用一个blk-pools（在一个Namespace中使用多个blk-pools在第一阶段中暂未支持）
2、和现阶段一致，一个Namenode包含两个层次(Namespace和blk-management)，一个Namenode管理一个Namespace Volume。尽管目前仍然由NN来实现这两个层次，但是目标还要将这两层从逻辑上彻底分开，方便后续很多工作
3、各个Namenode之间相互独立
4、整个集群作为一个整体或升级或rollback，和现在一样。

[align=left]3 Managing Namespace Volumes and Block Pools[/align]

以下几点必须在设计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集群的各种标识对比：



[align=left]3.1.1 FAQ[/align]

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

[align=left]3.2 Namespace Volume management[/align]

3、2、1 Current Cluster and Namespace management

[align=left]1、当期集群配置：[/align]

当前的集群配置在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进行全局格式化。
[align=left]3.2.2 Federated Cluster and Namespace Volume management[/align]

[align=left]1、新的集群配置方式[/align]

一个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来支持透明访问两个集群

[align=left]3.3 Block Storage[/align]

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级别独立创建快照。
[align=left]3.4 Single Checkpointer[/align]
当前每个PrimaryNN都一个CheckPointNN(either backup or secondary namenode)，CheckPointNN主要完成合并fsiamge和Editlog来产生新的Fsimage，为了减少节点数，可以使用单一的CheckpointerNN来为所有的PrimaryNN完成这个工作。细节工作留待实现阶段讨论。
[align=left]3.5 Network Partition and Federated Cluster[/align]
在网络发生分区时，NN可能会和大片的DN失去联系，这可能导致replication风暴并把仅有的一些DN空间给占满。这个问题在当前集群也存在，但是在Federation的环境下，这个问题更糟，网络分区的时候，可能导致各个NN看到的DN不同。HDFS-779通过在丢失大片的replica的时候，将NN退回到safemode来解决了这个问题，

[align=left]4 Cluster Management[/align]

[align=left]4.1 Web UI[/align]
[align=left]4.1.1 Namenode Web UI[/align]

[align=left]1、Cluster Summary:[/align]

集群信息汇总的部分将会增加ClusterID，blockpoolID，storage使用情况等等。
2、Live Nodes:
DN详细信息列表中也会增加Block Pool Used and Block
Pool Used %来表明各个blockpool占总空间的量和比重
3、Decommissioning status:
展示每个blockpool的Decommissioning status和整个DN的Decommissioning status
[align=left]4.1.2 Cluster Web UI[/align]
NN的servlet和jsp将会产生结构化数据来帮助构建cluster web ui，主要包括以下信息：
1、展示整个集群的占用情况，NN列表，blockpool列表，blockpool使用情况，blockmissing信息，DN健康汇总数据
2、点击每个NN都会引导到NN web ui界面
[align=left]4.2 Upgrade[/align]
[align=left]4.2.1 Upgrade Mechanism[/align]
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。
[align=left]4.2.2 Upgrading to Federation release[/align]
Namenode changes

1、NN刚刚启动时候创建BlockpoolID，ClusterID，并持久化到VERSION文件中
2、NN加载该新的BlockPooID下所有的blocks到内存中。

[align=left]Datanode changes:[/align]

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.

[align=left]4.2.3 Backward compatibility[/align]

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

[align=left]4.3 Decommissioning[/align]

[align=left]当前的Decommissioning工作流程如下：[/align]

[align=left]1、DN首先加入dfs.exclude，并且在NN端进行refresh node list[/align]

[align=left]2、NN将该DN的状态标记为decommission_in_progress并且开始为该DN进行blocks进行replication[/align]

[align=left]3、DN的状态在web ui上展示[/align]

[align=left]4、当replication完成了之后，DN将会标记为Decommissioned，最后会shutdown。[/align]

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

[align=left]1、开始decommissioning过程[/align]
[align=left]2、查询decommission状态[/align]
[align=left]3、这个工具可以在集群中的任何一个节点上开始运行[/align]

新的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。

[align=left]4.4 Distributed Upgrade[/align]

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

[align=left]4.5 Balancer[/align]

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



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

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

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



均衡机制如下：

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

[align=left]while (cluster_balanced is not true) {[/align]

[align=left]// Balance one block pool at a time – as much as possible[/align]

[align=left]for (block pool b : block pool list) {[/align]

[align=left]if (b is not balanced)[/align]

[align=left]balance b as much as possible or for time unit x;[/align]

[align=left]}[/align]

[align=left]if (all block pools are balanced)[/align]

[align=left]cluster_balanced = true;[/align]

[align=left]}[/align]

[align=left]4.6 Cluster startup/shutdown[/align]

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

1、启动或停止集群中所有的DN
2、启动或停止集群中所有的NN，指定的某些NN，某个NN
3、启动或停止整个集群(所有的DN和NN)

[align=left]5 Security[/align]

当前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的信息

[align=left]Appendix A ‐ Use Cases[/align]

[align=left]Following use cases have been considered in the document:[/align]

[align=left]Use case 1. Creating a new Federated HDFS Cluster[/align]

[align=left]See section 4.2.2.1[/align]

[align=left]Use case 2. Adding datanodes to a cluster[/align]

[align=left]See section 4.2.2.4[/align]

[align=left]Use case 3. Adding a namenode/namespace volume to a cluster[/align]

[align=left]See section 4.2.2.3[/align]

[align=left]Use case 4. Delete a namenode/namespace volume from a cluster[/align]

[align=left]See section 4.2.2.5[/align]

[align=left]Use case 5. Datanode is misconfigured and accidentally moved to a cluster[/align]

[align=left]Use case 6. Move a namespace from one namenode to a different namenode with in the cluster[/align]

[align=left]See section 4.2.2.6[/align]

[align=left]Use case 7. Move a part of namespace from one namenode to a different namenode with in the cluster[/align]

[align=left]See section 4.2.2.7[/align]

[align=left]Use case 8. Move a namespace from one cluster to another cluster.[/align]

[align=left]See section 4.2.2.8[/align]

[align=left]Use case 9. Upgrade cluster from old release to a new release with federation[/align]

[align=left]See section 5.2.2[/align]

[align=left]Use case 10. Rollback a cluster from release with federation back to the previous release[/align]

[align=left]See section 5.2.2[/align]

[align=left]Use case 11. Decommissioning datanodes[/align]

[align=left]See section 5.4[/align]

[align=left]Use case 12. Balancing storage utilization[/align]

[align=left]See section 5.5[/align]

[align=left]Use case 13. Centralized cluster monitoring[/align]

[align=left]See section 5.1[/align]

[align=left]Use case 14. Merging two cluster into a single federated HDFS cluster[/align]

[align=left]Section 4.2.2.9[/align]

[align=left]Following use cases are not considered in the document:[/align]

[align=left]Use case 15. Splitting a federated cluster into multiple clusters.[/align]

Appendix B ‐ Separating Block Storage Layer

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



分离出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，来管理，启动，停止这个集群。

[align=left]Appendix C – Namenode and Datanode metadata changes[/align]

DN存储目录

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

[align=left]<data>/in_use.lock[/align]

[align=left]<data>/storage[/align]

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



3、DN VERSION 文件

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

[align=left]o Type of node (DATA_NODE)[/align]
[align=left]o StorageID[/align]
[align=left]o NamespaceID[/align]
[align=left]o ctime[/align]
[align=left]o LayoutVersion[/align]

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

[align=left]1. <data>/current/ID[/align]

[align=left]oType of node (DATA_NODE)[/align]

[align=left]oStorageID[/align]

[align=left]oClusterID[/align]

[align=left]2. <data>/current>/bpid/VERSION (one for each block pool)[/align]

[align=left]oNamespaceID[/align]

[align=left]oBlockPoolID[/align]

[align=left]octime[/align]

[align=left]oLayoutVersion[/align]

4、NameNode VERSION文件

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

[align=left]oType of node (NAME_NODE)[/align]

[align=left]oNamespaceID[/align]

[align=left]octime[/align]

[align=left]oLayoutVersion[/align]

Federation下该文件被拆分成：

[align=left]1. <data>/ID[/align]

[align=left]oClusterID[/align]

[align=left]oNamespaceID[/align]

[align=left]oBlockPoolID[/align]

[align=left]oType of node (NAME_NODE)[/align]

[align=left]2. <data>/VERSION[/align]

[align=left]octime[/align]

[align=left]oLayoutVersion[/align]

[align=left]Appendix D ‐ Namespace Volume creation[/align]

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不匹配将会导致注册过程中止
[align=left]Appendix E – Future Improvements[/align]

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