hadoop3.X版本特性：路由器联邦
2020/11/15 [email protected]
文章目录
-
- 一、路由器联邦（Router-based Federation/RBF）
-
- 1.1背景
- 1.2代理服务-Router层次设计
- 1.3可用性和容错能力
- 1.4接口
- 1.5配额管理
- 1.6 客户端-路由器配置(详见官网文档)
一、路由器联邦（Router-based Federation/RBF）
1.1背景
- 在 HDFS 单集群的架构中，随着集群规模的扩大，Block Manager 和Namespace 会消耗掉 NameNode 越来越多的资源，最终导致NameNode 难以提供可靠的服务。于是就提出了 Federation 架构。
Federation 架构是指由多个子集群联合构成一个 Federation 集群，通常的做法是这 些子集群会共享Datanode.然后由挂载表来维护Federation Namespace 到子集群Namespace 间的映射关系，这个挂载表存在客户端本地的配置文件里，由客户端来解析从而访问到正确的子集群。在社区的实现中，用了一个新的协议viewfs:// 来 访问Federation Namespace.
- Federation架构带来的问题：
（1）挂载表是由客户端实现，修改代码逻辑需要考虑新老客户端的兼容性并分发新的客户端
（2）在实现子集群 Namespace 的 Rebalance 时，难以保证所有客户端同步更新到新的挂载表
为了解决上述问题，hadoop提出了新的Federation架构：Router-based Federation
相较于ViewFs通过在客户端维护挂载表信息，Router Federation是真正做到了对客户端的完全透明。因为这部分映射信息将会被额外的保存下来，还会持久化出去。这个模块我们姑且称之为状态维护（State Maintenance）的模块。另外还有一个重要的部分是请求转发模块，这里我们称之为Request forward。
以上2个模块构成了HDFS新的Federation软件层的设计。在这层软件结构以下，就是各个子集群。每个子集群会与Federation软件层，进行信息交互。结构图如下：
1.2代理服务-Router层次设计
为了对用户屏蔽Federation的实现细节，将挂在表的配置和实现从客户端中剥离出来，一个自然的想法是：引入新的代理服务。客户端直接请求代理服务，由其解析挂载表后将请求转发给正确的子集群。我们将这个代理服务叫做Router。
- 系统中可以有多个处于软状态的Router，每个路由器都有两个角色：
（1）联合接口：提供Federation接口，这个接口是给客户端使用的，它会将客户端请求转发到正确的子集群上。
（2）NameNode心跳:收集NameNode的心跳信息，报告给State Store。这样State Store维护的信息是实时更新的。
- Router RPC Forwarding：Router是如何转发RPC（Client请求）的
-
Router启动RouterRpcServer服务，这个类和NameNodeRpcServer一样实现了CluentProtocol，也就是说Client不需要改实现，就可以把Router当做Namenode来访问，当然Router也实现了其他的协议用以管理员来管理Router或者集群状态。
-
Router在通过RouterRpcServer收到RPC后，显示通过解析挂载表得到对应的自己群和其路径，再通过ConnerctionMannger构造出对应NameNode的RpcClient，利用Client转发这个Rpc
-
ConnectionManager 维护了一组连接池，每个 RPC 的UserGroupInformation,NameNode Address 和 Protocol 共同构成了连接池的 Key.连接池在构造时会创建一定数量的 RPC Client,随后对于每一个过来的 RPC,在连接池里找一个空闲的 RPC Client 用以发送RPC.当空闲的 RPC Client 不够时，由后台的 Creator 线程异步的构造新的连接，同时有后台的 Cleaner 线程负责清理连接池。
-
MountTableResolver：挂载映射关系
在 Router 中，每一条 Federation Namespace 到子集群 Namespace的映射对应一个 MountTable,所有的 MountTable 就是集群的挂载表。在 MountTableResolver 中，由类型为 TreeMap
社区还实现了一个支持把一个路径挂在多个集群下的 Resolver,它可以根据指定的规则例如一致性哈希来决定把子目录映射到哪个子集群上。
挂载表由管理员通过命令来设定，但是为了让所有的 Router 都能读到最新的挂载表，以及 Router 重启后不需要重新设定挂载表，这个挂载表应该持久化存在哪里呢？
- State Store
关键的服务State Store服务。因为有了这个状态服务，所以Router路由服务它是无状态的。那么State Store存储的信息主要有哪些呢？答案如下：
（1）各个NameNode的基础信息，包括地址信息，空间大小信息等基础信息。
（2）2.远程挂载表信息，形式为路径–>真实路径信息，这个与之前viewFs基本类似。
（3）各个Router的状态信息。
（4）Federation情况下的balancer状态信息。
为了更方便的管理 Router 的配置和状态，我们引入了 State Store,这是对于存储 Router 状态的存储服务的一个抽象，目前社区有基于文件系统和基于 Zookeeper 的两种实现。
负责与 State Store 通信的是 StateStoreDriver,定义了一些基本的GET/PUT 接口，由 StateStoreConnectionMonitorService 维护。StateStoreService 是 Router 管理 State Store 的服务，负责从 State Store 拉取数据，更新注册进来的 RecordStore 的缓存。在 State Store 上存储的叫做Record,目前只有基于 protobuf 的序列化实现。
举例来说，上面我们提到的挂载表就是一个 RecordStore 的实现，每条 Mount Table 就是一个 Record,他们被 protobuf 序列化后存储在State Store 上。
- Router Security：Router安全服务
有了上面的架构，Router 就可以作为一个无状态的代理层来工作了。可是 Client 不再直接与NameNode通信，非 RBF 集群的安全认证方案就失效了，所以就有了 Router 层的安全认证方案。
HDFS实践中用到的认证方案有两个，Kerberos 和 Delegation Token，这两种是针对不同应用同时在使用的。
显然，我们可以将 Router 作为 Service 注册到 Kerberos，由 Router来认证 Client.同时，Router 由作为 HDFS 的超级用户来代理 Client 的用户信息。
Delegation Token 相对就没这么容易实现了。按照社区现在的实现，是由 Router 来构造 Delegation Token,认证Client.为了让所有的 Router 能同步已构造的 Delegation Token,需要将其存到 State Store 来让 Router 间进行同步。这样做的好处实现简单，不需要和所有的 NameNode 进行通信就可以在 Route r层完成认证。坏处是需要 Router 间进行同步，这可能会导致性能问题，以及由于 Zookeeper 并非保证强一致性，Router 可能会读不到另一个 Router构造的 Delegation Token,结果 Client 认证失败。
目前尚不支持安全身份验证和授权，因此路由器将不会代理到启用了安全性的Hadoop群集。
- 完整的RouterFederation路由请求过程
（1）：客户端调用Router提供的请求接口。
（2）：该Router向State Store服务查询该请求对应的正确的NN地址。
（3）：Router得到正确的NN地址后，将请求转发到正确的NN上。
（4）：然后NN返回文件数据所在的DN地址，客户端与此DN进行消息通信（读/写block文件数据）
1.3可用性和容错能力
路由器在多个级别上均出现故障。
- **联合接口HA：**路由器是无状态的，元数据操作在NameNode上是原子的。如果路由器不可用，则任何路由器都可以接管它。客户端使用联合身份验证中的所有路由器作为端点配置其DFS HA客户端（例如，ConfiguredFailoverProvider或RequestHedgingProxyProvider）。
- **不可用的状态存储：**如果路由器无法联系状态存储，它将进入安全模式状态，从而禁止其处理请求。客户端将以安全模式对待路由器，因为它是一个备用NameNode，然后尝试另一个路由器。有一种手动方法可以管理路由器的安全模式。
可以使用以下命令来管理安全模式状态：
[hdfs] $ $ HADOOP_HOME / bin / hdfs dfsrouteradmin -safemode输入| 离开 得到
- **NameNode心跳HA：**为了实现高可用性和灵活性，多个路由器可以监视同一个NameNode并将心跳到状态存储。如果路由器发生故障，这会增加客户端对过时信息的弹性。每个路由器都通过仲裁来解决状态存储中有冲突的NameNode信息。
- **不可用的NameNode：**如果路由器无法联系活动的NameNode，则它将尝试子群集中的其他NameNode。它将首先尝试报告为备用的那些，然后尝试不可用的那些。如果路由器无法访问任何NameNode，则它将引发异常。
- **NameNode过期：**如果在状态存储中没有记录NameNode心跳超过心跳间隔的倍数，监视路由器将记录NameNode过期，并且没有路由器将尝试访问它。如果随后为NameNode记录了更新的心跳，则监视路由器将把NameNode从过期状态恢复
1.4接口
为了与用户和管理员进行交互，路由器公开了多个接口。
- **RPC：**路由器RPC实现客户端用于与HDFS交互的最常见接口。目前的实现已经使用普通MapReduce，Spark和Hive（在Tez，Spark和MapReduce上）编写的分析工作负载进行了测试。快照，加密和分层存储等高级功能留待未来版本使用。所有未实现的函数都会抛出异常。
- **管理员：**管理员可以从群集中查询信息，并通过RPC在装载表中添加/删除条目。此接口也通过命令行公开，以获取和修改联合的信息。
- **Web UI：**路由器公开Web UI，可视化联合的状态，模仿当前的NameNode UI。它显示有关装入表的信息，有关每个子群集的成员身份信息以及路由器的状态。
- **WebHDFS：**除了RPC之外，路由器还提供HDFS REST接口（WebHDFS）。
- **JMX：**它通过模仿NameNode的JMX公开指标。Web UI使用它来获取群集状态。
1.5配额管理
公开，以获取和修改Federation的信息。
- **Web UI：**路由器公开Web UI，可视化联合的状态，模仿当前的NameNode UI。它显示有关装入表的信息，有关每个子群集的成员身份信息以及路由器的状态。
- **WebHDFS：**除了RPC之外，路由器还提供HDFS REST接口（WebHDFS）。
- **JMX：**它通过模仿NameNode的JMX公开指标。Web UI使用它来获取群集状态。
1.6 客户端-路由器配置(详见官网文档)
参考资料
http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs-rbf/HDFSRouterFederation.html
https://mp.weixin.qq.com/s?__biz=MzUxMDQxMDMyNg==&mid=2247485844&idx=1&sn=4622f7e513aef52dbe3256237fc11dfe&chksm=f90222adce75abbb1b9ceaf9b5a31c64d632a89573224d8e05174f8d73471035cea4af302e0a&token=2135356908&lang=zh_CN#rd
https://blog.csdn.net/Androidlushangderen/article/details/78573732?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160505952619725222443081%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=160505952619725222443081&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2allfirst_rank_v2~rank_v28_p-1-78573732.pc_first_rank_v2_rank_v28p&utm_term=HDFSRouterFederation&spm=1018.2118.3001.4449
one-task-blog-2allfirst_rank_v2~rank_v28_p-1-78573732.pc_first_rank_v2_rank_v28p&utm_term=HDFSRouterFederation&spm=1018.2118.3001.4449