学步园

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

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

在这个设计中，为了提升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/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)

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来提供统一视图。

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，和现在一样。

以下几点必须在设计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.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必须满足：

均衡机制如下：