HDFS Federation基于Ambari部署安装（调研文档）

一、 HDFS Federation架构

* 在有Federation之前的HDFS架构

NameSpace层: 管理路径、文件以及blocks的关系，同时支持文件系统的操作比如mkdir/put/get等；
BlockStorage层：
- Block Management: 维护Datanode中存储的映射关系，主要是支持block层的创建、删除、修改及副本的放置等；
- Physical Storage: 存储block；

该架构中一个集群中只能存在一个namespace，存在以下限制：
- 过多的BlockStorage同NameSpace的耦合；
- NameSpace的扩展性问题；
- 性能问题：单个节点的NameSpace虽然可以通过使用SSD盘刷FSEdit日志、加大内存等手段改进，但随着节点的增多单NN瓶颈总汇出现；
- 隔离性问题：各业务线共用一个NN，使得一旦有业务线使用不当导致NN不可用或者负载过高，会影响其他业务线（线上小文件问题）；

* 改进后的HDFS Federation架构

HDFS Federation在0.23版本中已经加入。

HDFS Federation简单原理：
- 多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务；
- 每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储；
- DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况；

改进后的优点：
- 扩展性和隔离性： 支持多个namenode水平扩展整个文件系统的namespace。可按照应用程序的用户和种类分离namespace volume，进而增强了隔离性。
- 通用存储服务： Block Pool抽象层为HDFS的架构开启了创新之门。分离block storage layer使得：
- 新的文件系统（non-HDFS）可以在block storage上构建；
- 新的应用程序（如HBase）可以直接使用block storage层；
- 分离的block storage层为将来完全分布式namespace打下基础；
- 改动最小，向前兼容
- 现有的NN无需任何配置改动；
- 如果现有的客户端只连某台NN的话，代码和配置也无需改动；
- 客户端挂载表
- 通过路径自动对应NN；
- 使Federation的配置改动对应用透明；

二、当前Ambari架构的局限

Ambari是Hortonworks贡献给社区的、完全开源的、Hadoop生态的集群管理、监控、部署的工具，我们现有自动化部署工具Ambari是基于社区版2.5.0分支开发的。

Ambari中主要概念如下：
- Stack： 发行版本(比如Hotorworks的HDP，我们自研的NDP)，同时支持不同的版本，版本之间可以继承，但一次部署安装智能选择一个发行版；
- Service: 服务，属于stack，一个stack下可以有多个service，service也可以分多个版本，版本间可以有继承关系；比如当前我们自研版本支持Zookeeper/HDFS/YARN/Spark2/Hive2/Mammut/ElasticSearch/Kafka/Atlas等21个服务；
- Component： 组件，属于service，一个service下可以有多个component组成。例如HDFS服务下的组件有datanode,namenode等，Yarn下包含resourcemanager/nodemanager等；
- 角色： Component的属性，如master、slave等，也可以指定每种角色需要的host个数。例如namenode为单一host组件，可以部署在master机器上，datanode可以部署在多台host上那么可以指定部署datanode的角色为slave；
- Host: host为运行ambari-agent的一台机器，同时也是搭建集群内部的一台机器，可以部署多个Service的多个Component；

Ambari-Server调度原理：
- Ambari-server的Heartbeat Handler模块用于接收各个agent的心跳请求（心跳请求里面主要包含两类信息：节点状态信息和返回的操作结果），把节点状态信息传递给FSM状态机去维护着该节点的状态，并且把返回的操作结果信息返回给Action Manager去做进一步的处理。
- Coordinator模块又可以称为API handler，主要在接收WEB端操作请求后，会检查它是否符合要求，stageplanner分解成一组操作，最后提供给ActionManager去完成执行操作。
- Ambari-Server的所有状态信息的维护和变更都会记录在数据库中，用户做一些更改服务的操作都会在数据库上做一些相应的记录，同时，agent通过心跳来获得数据库的变更历史。

但在使用的过程中，发现Ambari有许多限制，社区已经发现了，在AMBARI-14714中已经计划Ambari3.0.0进行重构，比如：
- 多个Stack问题：比如无法部署HDP的一些社区组件+自研的NDP的一些组件；
- 多个集群问题： 无法基于Ambari部署多个集群，集群1供产品1使用，集群2供产品2使用；
- 多个Service问题： 通过Ambari部署，HDFS/Yarn/Kafka/Solr公用一套Zookeeper，其隔离性受限；
- 多版本Service问题：现实中可能依赖Kafka0.8.x和Kafka0.9.x等，或者Elasticsearch1.x/2.x/5.x版本等，但基于Ambari只能部署一个版本；
- Ambari-Server HA问题：虽然社区有通过VIP的方式提供解决方案，但依然达不到HA的要求AMBARI-17126;
- HDFS Federation问题： 社区没有做这个的意思；
- Fair Scheduler问题： 社区（或者说Hortonworks）当前支持Capacity Scheduler调度，对Fair Scheduler调度不支持；

三、关于HDFS Federation的部署方式

其中有关HDFS Federation的解决方案结合Ambari本身的架构来讲，想很好的剥离其原本的架构来实现有一定的难度，暂时想到了如下几个方案：
- 手动部署：最灵活，可参考当前线上联通集群的案例；
- 多Ambari-Server部署方式：部署多套Ambari-Server，同时修改各自配置，达到自动化部署HDFS Federation的效果；
- 社区Multi-Everything方案: 最理想的状态，完全自动化部署，解决以上许多问题；首先社区Ambari3.0.0改动很大，现在分支还没有release（有询问过，但没人保障最终deadline，毕竟都是hortonworks一帮人在弄，社区很不活跃），同时将我们自研结果何如社区Ambari3.0.0有一定的时间；

方案一、手动部署

部署新的Federation，还是按照HDFS HA的方式部署，需要两台机器namenode和secondery_namenode；

在namenode和secondery_namenode两台机器上均需要如下操作：
1. 在需要添加的节点上添加hdfs_client，并复制相应的路径：/usr/ndp/current/hdfs_client -> /usr/ndp/current/hdfs_namenode，并修改相应的hdfs_namenode conf配置路径。；
2. 修改复制的hdfs_namenode下的hadoop-env.sh: 将其中的hdfs_client变更为hdfs_namenode；
3. 修改core-site.xml
在core-site.xml中添加federation的serviceId：

  <property>
      <name>fs.defaultFSname>
      <value>hdfs://test1value>
      <final>truefinal>
    property>

1. 修改hdfs-site.xml: 首先删除不必要的配置：dfs.internal.nameservices， 同时添加如下配置：

<property>
        <name>dfs.nameservicesname>
        <value>hzadg,test1value>
    property>

    <property>
        <name>dfs.client.failover.proxy.provider.test1name>
        <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvidervalue>
    property>

    <property>
      <name>dfs.ha.namenodes.test1name>
      <value>nn3,nn4value>
    property>
    <property>
      <name>dfs.namenode.http-address.test1.nn3name>
      <value>hzadg-mammut-platform3.server.163.org:50070value>
    property>
    <property>
      <name>dfs.namenode.https-address.test1.nn3name>
      <value>hzadg-mammut-platform3.server.163.org:50470value>
    property>
    <property>
      <name>dfs.namenode.rpc-address.test1.nn3name>
      <value>hzadg-mammut-platform3.server.163.org:8020value>
    property>
    <property>
        <name>dfs.namenode.servicerpc-address.test1.nn3name>
        <value>hzadg-mammut-platform3.server.163.org:8021value>
    property>
    <property>
      <name>dfs.namenode.rpc-address.test1.nn4name>
      <value>hzadg-mammut-platform4.server.163.org:8020value>
    property>
    <property>
      <name>dfs.namenode.https-address.test1.nn4name>
      <value>hzadg-mammut-platform4.server.163.org:50470value>
    property>
    <property>
      <name>dfs.namenode.http-address.test1.nn4name>
      <value>hzadg-mammut-platform4.server.163.org:50070value>
    property>
    <property>
        <name>dfs.namenode.servicerpc-address.test1.nn4name>
        <value>hzadg-mammut-platform4.server.163.org:8021value>
    property>

1. 创建必要的目录，注意权限hdfs:hadoop用户组：
   

   日志/run路径
   hdfs存储目录: /srv/nbs/0/hadoop/hdfs/namenode

2. 添加keytab，并根据hdfs-site.xml指定位置复制到相应的路径下：
   addprinc -randkey nn/hzadg-mammut-platform4.server.163.org
   ktadd nn/hzadg-mammut-platform4.server.163.org
3. namenode/secondery_namenode 格式化，注意使用同已有集群相同的cluster-id:
   su hdfs -l -s /bin/bash -c ‘/usr/ndp/current/hdfs_namenode/bin/hdfs namenode -format -clusterId CID-bc01aa89-d9db-4d28-b035-698456b78b95’
4. 启动 namenode
   su hdfs -l -s /bin/bash -c ‘ulimit -c unlimited ; /usr/ndp/current/hdfs_namenode/sbin/hadoop-daemon.sh –config /usr/ndp/current/hdfs_namenode/conf start namenode’
5. 启动 second namenode
   su hdfs -l -s /bin/bash -c ‘/usr/ndp/current/hdfs_namenode/bin/hdfs namenode -bootstrapStandby’
6. 添加ZKFailOver
   注意添加完毕连个namenode之后，两个节点都是standby状态，同时没办法使用hdfs haadmin --transitionToActive nn3命令切换为active，只有开启ZKFailControl，在namenode/secondnamenode中输入如下命令：
   su hdfs -l -s /bin/bash -c ‘ulimit -c unlimited ; /usr/ndp/current/hdfs_namenode/bin/hdfs zkfc -formatZK’
   su hdfs -l -s /bin/bash -c ‘ulimit -c unlimited ; /usr/ndp/current/hdfs_namenode/sbin/hadoop-daemon.sh –config /usr/ndp/current/hdfs_namenode/conf start zkfc’
7. 修改原有集群配置
   针对原集群，修改hdfs-site.xml这样datanode就可以汇报至新的federation集群了，修改方式同上述部署一致：
   首先删除不必要的配置：dfs.internal.nameservices

    <property>
        <name>dfs.nameservicesname>
        <value>hzadg,test1value>
    property>

    <property>
        <name>dfs.client.failover.proxy.provider.test1name>
        <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvidervalue>
    property>

    <property>
      <name>dfs.ha.namenodes.test1name>
      <value>nn3,nn4value>
    property>
    <property>
      <name>dfs.namenode.http-address.test1.nn3name>
      <value>hzadg-mammut-platform3.server.163.org:50070value>
    property>
    <property>
      <name>dfs.namenode.https-address.test1.nn3name>
      <value>hzadg-mammut-platform3.server.163.org:50470value>
    property>
    <property>
      <name>dfs.namenode.rpc-address.test1.nn3name>
      <value>hzadg-mammut-platform3.server.163.org:8020value>
    property>
    <property>
        <name>dfs.namenode.servicerpc-address.test1.nn3name>
        <value>hzadg-mammut-platform3.server.163.org:8021value>
    property>
    <property>
      <name>dfs.namenode.rpc-address.test1.nn4name>
      <value>hzadg-mammut-platform4.server.163.org:8020value>
    property>
    <property>
      <name>dfs.namenode.https-address.test1.nn4name>
      <value>hzadg-mammut-platform4.server.163.org:50470value>
    property>
    <property>
      <name>dfs.namenode.http-address.test1.nn4name>
      <value>hzadg-mammut-platform4.server.163.org:50070value>
    property>
    <property>
        <name>dfs.namenode.servicerpc-address.test1.nn4name>
        <value>hzadg-mammut-platform4.server.163.org:8021value>
    property>

1. 重启原有集群： 保持集群配置一致，同时datanode会注册至新的federation集群；

方案二、多Ambari-Server部署方式

需要注意的是，暂时调研发现单个ambari-agent无法服务于多个ambari-server，所以暂时需要通过添加机器，重新部署ambari-agent的方式解决；

思路：
1. 添加新的机器，独立部署一套ambari-server；
2. 在ambari-server上安装zookeeper和hdfs基础组件；
3. 启动HA和Kerberos环境；
4. 参考上述需要修改的配置，修改原集群和新添加集群的配置；
5. 重启服务；

实验

TODO

方案三、社区Multi-Everything方案

一个ambari实例同一个Mpack Repository关联(图中的Mpack Repository)， 可以通过Mpcak Repositoryc查询一系列的可用Mpack（图中的DistroX3.0.0/DistroY3.2.0等），同时可以用不同的Mpack部署y一个集群，在这个集群内可以创建不同的servcie group（图中的Core SG/Stream SG等），可以在集群中部署不同的service实例（图中的ZK1/ZK2），同时在同一个host可以部署多个同一个组件实例（图中的Broker-1/Broker-2等）；

社区Ambari3.0.0的设计方案中，新添加了如下概念：
- Packlet： Packlet为一个service/view的发布部署单元，其为Management pack的组成单元，比如Spark-2.0.0-packlet/HBase-3.0.0-packlet等。
- Service Packlet： Service服务的packlet，Spark-2.0.0-packlet/HBase-3.0.0-packlet等。；
- View Packlet: 同service packlet相似，但面向于ambari view的；
- Mpack(Management pack)： 由不同packlet组成的一个组合，比如HDP-3.0.0.0-mpack等；
- Mpack Repository： 不同Mpack组成的一个发布组合；
- Service Group: 为了支持multi-mpcak和multi-service，引入了Service Group的概念，SG为相关的service组合的逻辑概念，集群内可以包含多个SG，SG安装均来自相同的mpack，SG之间存在继承关系；

需要注意的是SG同mpack概念是不同的：mpack类似于stack的概念，其为一个发布概念，如果你想引入service则需要在mpack中添加，SG为运行时的概念，将不同的service组合一起的逻辑集合；所以在安装部署的时候需要确认：
- 安装service时需要绑定在mpack下的SG；
- 确定不同SG之间的依赖关系；

TODO: 持续关注；

总结

从上述的阐述中，当前总体思路: 打通思路一、思路二，长远考虑关注思路三。

参考：
* Hortonworks关于HDFS Federation的说明： https://hortonworks.com/blog/an-introduction-to-hdfs-federation/
* HDFS Federation Issue: https://issues.apache.org/jira/browse/HDFS-1052
* HDFS Federation设计动机与基本原理： http://dongxicheng.org/mapreduce/hdfs-federation-introduction/
* http://www.infoq.com/cn/articles/hadoop-2-0-namenode-ha-federation-practice-zh/
* Hadoop 2.0 NameNode HA和Federation实践： Ambari Multi Everything Issue: https://issues.apache.org/jira/browse/AMBARI-14714
* Ambari Server HA: https://issues.apache.org/jira/browse/AMBARI-17126
* Ambari HDFS Federation: https://issues.apache.org/jira/browse/AMBARI-10982
* Ambari Fair Scheduler: https://issues.apache.org/jira/browse/AMBARI-6819
* HDFS Federation机制： http://blog.csdn.net/androidlushangderen/article/details/52135506
* HA&Federation： http://blog.csdn.net/tutucute0000/article/details/39756123