Hadoop记录-Federation联邦机制
在Hadoop2.0以前，HDFS的单NameNode设计带来诸多问题： php
单点故障、内存受限，制约集群扩展性和缺少隔离机制（不一样业务使用同一个NameNode致使业务相互影响）等
为了解决这些问题，除了用基于共享存储的HA解决方案咱们还能够用HDFS的Federation机制来解决这个问题。
【单机namenode的瓶颈大约是在4000台集群，然后则须要使用联邦机制】html
什么是Federation机制
Federation是指HDFS集群可以使用多个独立的NameSpace(NameNode节点管理)来知足HDFS命名空间的水平扩展
这些NameNode分别管理一部分数据，且共享全部DataNode的存储资源。java
NameSpace之间在逻辑上是彻底相互独立的(即任意两个NameSpace能够有彻底相同的文件名)。在物理上能够彻底独立(每一个NameNode节点管理不一样的DataNode)也能够有联系(共享存储节点DataNode)。一个NameNode节点只能管理一个Namespacenode
Federation机制解决单NameNode存在的如下几个问题
（1）HDFS集群扩展性。每一个NameNode分管一部分namespace，至关于namenode是一个分布式的。
（2）性能更高效。多个NameNode同时对外提供服务，提供更高的读写吞吐率。
（3）良好的隔离性。用户可根据须要将不一样业务数据交由不一样NameNode管理，这样不一样业务之间影响很小。
（4）Federation良好的向后兼容性，已有的单Namenode的部署配置不须要任何改变就能够继续工做。linux
Federation是简单鲁棒的设计
鲁棒性（健壮和强壮）：在输入错误、磁盘故障、网络过载或有意攻击状况下，可否不死机、不崩溃web
因为联盟中各个Namenode之间是相互独立的：Federation整个核心设计大部分改变是在Datanode、Config和Tools，而Namenode自己的改动很是少，这样Namenode原先的鲁棒性不会受到影响。比分布式的Namenode简单，虽然扩展性比真正的分布式的Namenode要小些，可是能够迅速知足需求。算法
另一个缘由是Federation良好的向后兼容性，能够无缝的支持目前单Namenode架构中的配置。已有的单Namenode的部署配置不须要任何改变就能够继续工做。shell
Federation不足之处
HDFS Federation并无彻底解决单点故障问题。虽然namenode/namespace存在多个，可是从单个namenode/namespace看，仍然存在单点故障。所以 Federation中每一个namenode配置成HA高可用集群，以便主namenode挂掉一下，用于快速恢复服务。
Federation 架构apache
Federation方案的基本思路就是使用多个独立的NameSpace(NameNode节点管理)来知足HDFS命名空间的水平扩展,NameSpace之间在逻辑上是彻底相互独立的(即任意两个NameSpace能够有彻底相同的文件名),而在物理上能够彻底独立(NameNode节点管理不一样的DataNode)也能够有联系(共享存储节点DataNode)很显然,任何一个NameNode节点只能管理一个Namespace.这种在逻辑上没法统一命名空间的设计对于初学者来讲,可能会经常踩到文件名冲突或文件不存在的陷阱中.很显然,任何一个NameNode节点只能管理一个Namespace.bootstrap
为了水平扩展namenode，federation使用了多个独立的namenode/namespace
这些namenode之间相互独立且不须要互相协调，各自分工，管理本身的区域。分布式的datanode被用做通用的数据块存储存储设备。每一个datanode要向集群中全部的namenode注册，且周期性地向全部namenode发送心跳和块报告，并执行来自全部namenode的命令。
每一个namenode维护一个命名空间卷（namespace volume）
由命名空间的元数据和一个数据块池组成，数据块池（block pool）包含该命名空间下文件的全部数据块。
命名空间卷之间相互独立
两两之间并不互相通讯，甚至其中一个namenode的失效也不会影响由其余namenode维护的命名空间的可用性。
一个namespace和它的blockpool做为一个管理单元（称为namespace volume）
数据块池再也不切分，则集群中的DataNode须要注册到每一个namenode，而且存储着来自多个数据块池中的数据块。当namenode/namespace被删除后，其全部datanode上对应的block pool也会被删除。集群升级时，这个管理单元也独立升级。
NameNode的HA
实现NameNode的HA方案,最重要的部分就是须要一个共享式的存储系统来实时存储NameNode的操做日志,而这种共享式的存储系统必需要知足两个基本条件:一是自身必需要高可用,二是保证强一致性.目前,Hadoop-2.x使用Quorum Journal Manager(QJM)来实现操做日志的共享,QJM是一个比ZooKeeper要轻量级的分布式存储系统,所使用的一致性约束条件远远不如paxos,raft等高可用的一致性算法.HDFS抽象出了一个日志接口JournalManager来屏蔽底层对操做日志存储的实现细节,目前主要有三种实现:
-
+ JournalManager
-
-FileJournalManager
-
-QuorumJournalManager
-
-BackupJournalManager
FileJournalManager将操做日志写入本地文件系统中,QuorumJournalManager将操做日志写入QJM中来实现主/备NameNode之间的操做日志共享,BackupJournalManager将操做日志实时的推送给backup的NameNode节点.QuorumJournalManager为了保证性能,采用了异步并发的方式将操做日志刷入全部的JournalNode节点
配置的HA的HDFS,全部NameSpace的NameNode节点在启动加载完元数据以后都处于Standby状态,以后被手动或自动的选择一个NameNode节点做为Active节点而开始正常工做.HA的自动方式是经过在每个NameNode的本地启动一个守护进程ZKFailoverController来竞争Active NameNode的,ZKFailoverController除了为本地的NameNode争取Active角色以外,还负责监控本地的NN节点当前是否正常的,一旦它发现本地的NN不正常,要么主动替当前的Active NN退出Active角色或退出Active的竞争.
DistributedFileSystem的容错Proxy
HDFS的HA方案并不仅是保证NameNode节点的高可用,还得保证客户端可以对用户透明的容忍主/备NameNode节点之间的切换.目前客户端对HA方案的实现方式主要是经过重试的机制来完成的.
简述
hadoop 集群一共有4种部署模式，详见《hadoop 生态圈介绍》。
HA联邦模式解决了单纯HA模式的性能瓶颈（主要指Namenode、ResourceManager），将整个HA集群划分为两个以上的集群，不一样的集群之间经过Federation进行链接，使得HA集群拥有了横向扩展的能力。理论上，在该模式下，可以经过增长计算节点以处理无限增加的数据。联邦模式下的配置在原HA模式的基础上作了部分调整。
全部四种模式的部署指南见：
hadoop 伪分布式搭建指南
hadoop 彻底分布式搭建指南
hadoop HA高可用集群模式搭建指南
hadoop HA+Federation（联邦）模式搭建指南
搭建过程
系统环境
Ubuntu 14.04 x64 Server LTS
Hadoop 2.7.2
vagrant 模拟4台主机，内存都为2G
集群节点规划
| IP | 主机名 | 角色描述 | 集群 |
|---|---|---|---|
| 192.168.100.201 | h01.vm.com | namenode-ns1-nn1, zkfc, QuorumPeerMain, resourcemanager | ns1 |
| 192.168.100.202 | h02.vm.com | namenode-ns1-nn2, zkfc, QuorumPeerMain, resourcemanager, journalnode, | ns1 |
| 192.168.100.203 | h03.vm.com | namenode-ns2-nn3, zkfc, QuorumPeerMain, journalnode, nodemanager, datanode | ns2 |
| 192.168.100.204 | h04.vm.com | namenode-ns2-nn4, zkfc, journalnode, nodemanager, datanode | ns2 |
上表中：
- QuorumPeerMain 是zookeeper集群的入口进程；
- zkfc 是 Zookeeper FailoverController 的简称，主要用于实现两个NN之间的容灾。
- resourcemanager 是 yarn 中负责资源协调和管理的进程
- nodemanager 是 yarn 中单个节点上的代理进程，向 RM 汇报信息，监控该节点资源
- datanode 是 hdfs 的工做节点，负责实际的数据存储和任务计算
- journalnode 是QJM模式下两个NN节点同步数据的进程，每一个HA集群里面的高可用依赖它
- ns1,ns2 是集群的逻辑名称
- nn1,nn2, nn3, nn4 是集群中NN的逻辑名称
zookeeper 节点须要配置奇数台，通常配置3-7台便可。2000多个节点的集群也仅须要5-9台zk；journalnode与zk相似，也是配置奇数台，且最少须要3台，一样不须要太多；另外zkfc须要在启动namenode的节点上也启动，以保障NN间的心跳机制。
更新软件源索引
- 分别在 h01 h02 h03 h04 操做
sudo apt-get update
安装基础软件
- 分别在 h01 h02 h03 h04 操做
sudo apt-get install ssh sudo apt-get install rsync
配置主机域名
- 分别在 h01 h02 h03 h04 操做
sudo vim /etc/hostname # centos系统可能没有该文件，建立便可 h01.vm.com # 该节点主机名
将该文件内容修改成对应的主机名，例如 h01.vm.com
域名解析
- 搭建内网DNS服务器（可选，但推荐），可阅读vincent的博文
http://blog.kissdata.com/2014/07/10/ubuntu-dns-bind.html - 配置 /etc/hosts，将如下代码追加到文件末尾便可（如搭建了DNS服务器，则跳过此步骤）
- 分别在 h01 h02 h03 h04 操做
sudo vim /etc/hosts 192.168.100.201 h01.vm.com h01 192.168.100.202 h02.vm.com h02 192.168.100.203 h03.vm.com h03 192.168.100.204 h04.vm.com h04
!!! Ubuntu系统，须删掉 /etc/hosts 映射 127.0.1.1/127.0.0.1 !!!
Check that there isn't an entry for your hostname mapped to 127.0.0.1 or 127.0.1.1 in /etc/hosts (Ubuntu is notorious for this).
127.0.1.1 h01.vm.com # must remove否则可能会引发 hadoop、zookeeper 节点间通讯的问题
时间同步（生产环境中务必配置）
在内网中搭建 ntp 服务器，可阅读vincent的博文
http://blog.kissdata.com/2014/10/28/ubuntu-ntp.html
准备jdk、hadoop和zookeeper软件包
- 须到官方网站下载stable版本
jdk-7u79-linux-x64.tar.gz
hadoop-2.7.2.tar.gz
zookeeper-3.4.8.tar.gz - 全部的软件包都统一解压到 /home/vagrant/VMBigData 目录下，其中 vagrant 是linux系统的用户名，因为我是使用 vagrant 虚拟的主机，因此默认是 vagrant
- 在 h01 操做
# 先在其中一台机子操做，后面会使用 scp 命令或者其余方法同步到其余主机 mkdir -p /home/vagrant/VMBigData/hadoop /home/vagrant/VMBigData/java /home/vagrant/VMBigData/zookeeper tar zxf jdk-7u79-linux-x64.tar.gz -C /home/vagrant/VMBigData/java tar zxf hadoop-2.7.2.tar.gz -C /home/vagrant/VMBigData/hadoop tar zxf zookeeper-3.4.8.tar.gz -C /home/vagrant/VMBigData/zookeeper
配置软链接，方便之后升级版本
- 在 h01 操做，后面经过 scp 同步到其余主机
ln -s /home/vagrant/VMBigData/java/jdk1.7.0_79/ /home/vagrant/VMBigData/java/default ln -s /home/vagrant/VMBigData/hadoop/hadoop-2.7.2/ /home/vagrant/VMBigData/hadoop/default ln -s /home/vagrant/VMBigData/zookeeper/zookeeper-3.4.8/ /home/vagrant/VMBigData/zookeeper/default
配置环境变量
- 分别在 h01 h02 h03 h04 操做
sudo vim /etc/profile
export HADOOP_HOME=/home/vagrant/VMBigData/hadoop/default export JAVA_HOME=/home/vagrant/VMBigData/java/default export PATH=$JAVA_HOME/bin:$HADOOP_HOME/bin:$PATH source /etc/profile
配置免密码ssh登陆
hadoop主节点须要能远程登录集群内的全部节点（包括本身），以执行命令。因此须要配置免密码的ssh登录。可选的ssh秘钥对生成方式有rsa和dsa两种，这里选择rsa。
- 分别在 h01 h02 h03 h04 ，即4个主节点上操做
ssh-keygen -t rsa -C "youremail@xx.com" # 注意在接下来的命令行交互中，直接按回车跳过输入密码
- 分别在 h01 h02 h03 h04 上操做。如下命令将本节点的公钥 id_rsa.pub 文件的内容追加到远程主机的 authorized_keys 文件中（默认位于 ~/.ssh/）
ssh-copy-id vagrant@h01.vm.com # vagrant是远程主机用户名 ssh-copy-id vagrant@h02.vm.com ssh-copy-id vagrant@h03.vm.com ssh-copy-id vagrant@h04.vm.com
- 在 h01 h02 h03 h04 上测试无密码 ssh 登陆到 h01 h02 h03 h04
ssh h01.vm.com ssh h02.vm.com ssh h03.vm.com ssh h04.vm.com
!!! 注意使用rsa模式生成密钥对时，不要轻易覆盖原来已有的，肯定无影响时方可覆盖 !!!
配置从节点
在 slaves 文件中配置的主机即为从节点，将自动运行datanode, nodemanager服务
- 在 h01 操做，后面经过 scp 同步到其余主机
vim /home/vagrant/VMBigData/hadoop/default/etc/hadoop/slaves h03.vm.com h04.vm.com
也能够在不一样集群里配置不一样的从节点
创建存储数据的相应目录
- 在 h01 操做，后面经过 scp 同步到其余主机
mkdir -p /home/vagrant/VMBigData/hadoop/data/hdfs/tmp
mkdir -p /home/vagrant/VMBigData/hadoop/data/journal/data
mkdir -p /home/vagrant/VMBigData/hadoop/data/pid
mkdir -p /home/vagrant/VMBigData/hadoop/data/namenode1
mkdir -p /home/vagrant/VMBigData/hadoop/data/namenode2
mkdir -p /home/vagrant/VMBigData/hadoop/data/datanode1
mkdir -p /home/vagrant/VMBigData/hadoop/data/datanode2
mkdir -p /home/vagrant/VMBigData/hadoop/data/local-dirs mkdir -p /home/vagrant/VMBigData/hadoop/data/log-dirs
配置hadoop参数
在 h01 操做，后面经过 scp 同步到其余主机
- vim /home/vagrant/VMBigData/hadoop/default/etc/hadoop/hadoop-env.sh
# export JAVA_HOME=${JAVA_HOME} # 注意注释掉原来的这行 export JAVA_HOME=/home/vagrant/VMBigData/java/default export HADOOP_PREFIX=/home/vagrant/VMBigData/hadoop/default # export HADOOP_PID_DIR=${HADOOP_PID_DIR} # 注意注释掉原来的这行 export HADOOP_PID_DIR=/home/vagrant/VMBigData/hadoop/data/hdfs/pid export YARN_PID_DIR=/home/vagrant/VMBigData/hadoop/data/hdfs/pid # export HADOOP_SECURE_DN_PID_DIR=${HADOOP_PID_DIR} # 注意注释掉原来的这行 export HADOOP_SECURE_DN_PID_DIR=${HADOOP_PID_DIR}
- vim /home/vagrant/VMBigData/hadoop/default/etc/hadoop/mapred-env.sh
export HADOOP_MAPRED_PID_DIR=/home/vagrant/VMBigData/hadoop/data/hdfs/pid
- vim /home/vagrant/VMBigData/hadoop/default/etc/hadoop/core-site.xml
<?xml version="1.0" encoding="utf-8"?> # <configuration> # 注意此处的修改 <configuration xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="/home/vagrant/VMBigData/hadoop/default/etc/hadoop/cmt.xml" /> # 此处引入federation的额外配置文件 <property> <!-- 指定hdfs的nameservice名称，在 cmt.xml 文件中会引用。注意此处的修改 --> <name>fs.defaultFS</name> <value>viewfs://nsX</value> </property> <!-- 指定hadoop数据存储目录 --> <property> <name>hadoop.tmp.dir</name> <value>/home/vagrant/VMBigData/hadoop/data/hdfs/tmp</value> </property> <property> <!-- 注意此处将该配置项从 hdfs-site.xml 文件中迁移过来了 --> <name>dfs.journalnode.edits.dir</name> <value>/home/vagrant/VMBigData/hadoop/data/journal/data</value> </property> <!-- 指定zookeeper地址 --> <property> <name>ha.zookeeper.quorum</name> <value>h01.vm.com:2181,h02.vm.com:2181,h03.vm.com:2181</value> </property> </configuration>
- vim /home/vagrant/VMBigData/hadoop/default/etc/hadoop/cmt.xml
<?xml version="1.0" encoding="utf-8"?> <configuration> <property> <!-- 将 hdfs 的 /view_ns1 目录挂载到 ns1 的NN下管理，整个federation的不一样HA集群也是能够读写此目录的，可是在指定路径是须要指定彻底路径 --> <name>fs.viewfs.mounttable.nsX.link./view_ns1</name> <value>hdfs://ns1</value> </property> <property> <name>fs.viewfs.mounttable.nsX.link./view_ns2</name> <value>hdfs://ns2</value> </property> <property> <!-- 指定 /tmp 目录，许多依赖hdfs的组件可能会用到此目录 --> <name>fs.viewfs.mounttable.nsX.link./tmp</name> <value>hdfs://ns1/tmp</value> </property> </configuration>
- vim /home/vagrant/VMBigData/hadoop/default/etc/hadoop/hdfs-site.xml
<?xml version="1.0" encoding="utf-8"?> <!-- HDFS-HA 配置 --> <configuration> <property> <!-- 由于集群规划中只配置了2各datanode节点，因此此处只能设置小于2，由于hadoop默认不容许将不一样的副本存放到相同的节点上 --> <name>dfs.replication</name> <value>2</value> </property> <property> <!-- 白名单：仅容许如下datanode链接到NN，一行一个，也能够指定一个文件 --> <name>dfs.hosts</name> <value> <!-- ~/VMBigData/hadoop/default/etc/hadoop/hosts.allow --> h01.vm.com h02.vm.com h03.vm.com h04.vm.com </value> </property> <property> <!-- 黑名单：不容许如下datanode链接到NN，一行一个，也能够指定一个文件 --> <name>dfs.hosts.exclude</name> <value></value> </property> <property> <!-- 集群的命名空间、逻辑名称，可配置多个，可是与 cmt.xml 配置对应 --> <name>dfs.nameservices</name> <value>ns1,ns2</value> </property> <property> <!-- 命名空间中全部NameNode的惟一标示。该标识指示集群中有哪些NameNode。目前单个集群最多只能配置两个NameNode --> <name>dfs.ha.namenodes.ns1</name> <value>nn1,nn2</value> </property> <property> <name>dfs.ha.namenodes.ns2</name> <value>nn3,nn4</value> </property> <property> <name>dfs.namenode.rpc-address.ns1.nn1</name> <value>h01.vm.com:9000</value> </property> <property> <name>dfs.namenode.http-address.ns1.nn1</name> <value>h01.vm.com:50070</value> </property> <property> <name>dfs.namenode.rpc-address.ns1.nn2</name> <value>h02.vm.com:9000</value> </property> <property> <name>dfs.namenode.http-address.ns1.nn2</name> <value>h02.vm.com:50070</value> </property> <property> <name>dfs.namenode.rpc-address.ns2.nn3</name> <value>h03.vm.com:9000</value> </property> <property> <name>dfs.namenode.http-address.ns2.nn3</name> <value>h03.vm.com:50070</value> </property> <property> <name>dfs.namenode.rpc-address.ns2.nn4</name> <value>h04.vm.com:9000</value> </property> <property> <name>dfs.namenode.http-address.ns2.nn4</name> <value>h04.vm.com:50070</value> </property> <property> <!-- JournalNode URLs，ActiveNameNode 会将 Edit Log 写入这些 JournalNode 所配置的本地目录即 dfs.journalnode.edits.dir --> <name>dfs.namenode.shared.edits.dir</name> <!-- 注意此处的ns1，当配置文件所在节点处于ns1集群时，此处为ns1，当处于ns2集群时，此处为ns2 --> <value>qjournal://h02.vm.com:8485;h03.vm.com:8485;h04.vm.com:8485/ns1</value> </property> <!-- JournalNode 用于存放 editlog 和其余状态信息的目录 --> <property> <name>dfs.journalnode.edits.dir</name> <value>/home/vagrant/VMBigData/hadoop/data/journal</value> </property> <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property> <property> <name>dfs.client.failover.proxy.provider.ns1</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <property> <name>dfs.client.failover.proxy.provider.ns2</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <!-- 一种关于 NameNode 的隔离机制(fencing) -->