Hadoop2实践之HDFS进阶篇-高可用

What


Hadoop 2.x由HDFS、MapReduce和YARN三个分支构

  • HDFS:分布式文件存储系统;
  • YARN:资源管理系统
  • MapReduce:运行在YARN上的MR;

Hadoop 2.0产生背景

  • Hadoop 1.0中HDFS和MapReduce在高可用、扩展性等方面存在问题。
  • HDFS存在的问题
    • NameNode单点故障,难以应用于在线场景
    • NameNode压力过大,且内存受限,影响系统扩展性
  • MapReduce存在的问题
    • JobTracker访问压力大,影响系统扩展性
    • 难以支持除MapReduce之外的计算框架,比如Spark、Storm等.

Yarn

资源管理系统 ,由jobTracker 演化而来

  • 资源管理 ResourceManager
  • 任务调度 ApplicationMaster

资源管理调度流程

流程大致如下

  • client客户端向yarn集群(resourcemanager)提交任务
  • resourcemanager选择一个node创建appmaster
  • appmaster根据任务向rm申请资源
  • rm返回资源申请的结果
  • appmaster去对应的node上创建任务需要的资源(container形式,包括内存和CPU)
  • appmaster负责与nodemanager进行沟通,监控任务运行
  • 最后任务运行成功,汇总结果。
  • 其中Resourcemanager里面一个很重要的东西,就是调度器Scheduler,调度规则可以使用官方提供的,也可以自定义。

Where

http://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

Why


  • zookeeper 选举机制

How

  1. hdfs-site.xml cd /opt/soft/hadoop-2.5.1/ vi etc/hadoop/hdfs-site.xml

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    <property>
    <name>dfs.nameservices</name>
    <value>appcity</value>
    </property>
    <property>
    <name>dfs.ha.namenodes.appcity</name>
    <value>nn1,nn2</value>
    </property>
    <property>
    <name>dfs.namenode.rpc-address.appcity.nn1</name>
    <value>sj-node1:8020</value>
    </property>
    <property>
    <name>dfs.namenode.rpc-address.appcity.nn2</name>
    <value>sj-node2:8020</value>
    </property>
    <property>
    <name>dfs.namenode.http-address.appcity.nn1</name>
    <value>sj-node1:50070</value>
    </property>
    <property>
    <name>dfs.namenode.http-address.appcity.nn2</name>
    <value>sj-node2:50070</value>
    </property>
    <property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>qjournal://sj-node2:8485;sj-node2:8485;sj-node4:8485/appcity</value>
    </property>
    <property>
    <name>dfs.client.failover.proxy.provider.appcity</name>
    <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
    </property>
    <property>
    <name>dfs.ha.fencing.methods</name>
    <value>sshfence</value>
    </property>
    <property>
    <name>dfs.ha.fencing.ssh.private-key-files</name>
    <value>/root/.ssh/id_dsa</value>
    </property>
    <property>
    <name>dfs.journalnode.edits.dir</name>
    <value>/opt/soft/hadoop-2.5.1/data/jn</value>
    </property>
    <property>
    <name>dfs.ha.automatic-failover.enabled</name>
    <value>true</value>
    </property>

  2. core-site.xml vim etc/hadoop/core-site.xml

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    <property>
    <name>fs.defaultFS</name>
    <value>hdfs://appcity</value>
    </property>
    <property>
    <name>fs.default.name</name>
    <value>hdfs://appcity</value>
    </property>
    <property>
    <name>ha.zookeeper.quorum</name>
    <value>sj-node2:2181,sj-node3:2181,sj-node4:2181</value>
    </property>
    <property>
    <name>ipc.client.connect.max.retries</name>
    <value>100</value>
    <description>Indicates the number of retries a client will make to establish
    a server connection.
    </description>
    </property>
    <property>
    <name>ipc.client.connect.retry.interval</name>
    <value>1000</value>
    <description>Indicates the number of milliseconds a client will wait for
    before retrying to establish a server connection.
    </description>
    </property>

  3. 复制配置文件

    1
    2
    3
    4
    5
    6
    scp etc/hadoop/hdfs-site.xml  sj-node2:/opt/soft/hadoop-2.5.1/etc/hadoop/
    scp etc/hadoop/hdfs-site.xml sj-node3:/opt/soft/hadoop-2.5.1/etc/hadoop/
    scp etc/hadoop/hdfs-site.xml sj-node4:/opt/soft/hadoop-2.5.1/etc/hadoop/
    scp etc/hadoop/core-site.xml sj-node2:/opt/soft/hadoop-2.5.1/etc/hadoop/
    scp etc/hadoop/core-site.xml sj-node3:/opt/soft/hadoop-2.5.1/etc/hadoop/
    scp etc/hadoop/core-site.xml sj-node4:/opt/soft/hadoop-2.5.1/etc/hadoop/

  4. 删除masters cp ./etc/hadoop/masters ./etc/hadoop/masters.bak rm ./etc/hadoop/masters

  5. 删除之前存储的一些元信息和数据 譬如/opt/hadoop rm -rf data/dfs/

  6. 启动JNs 至少三个节点 分别在2,3,4节点执行./sbin/hadoop-daemon.sh start journalnode

  7. 在其中一个namenode所在的节点来执行 ./bin/hdfs namenode -format

  8. 把刚才格式化好的那个namenode启动起来 ./sbin/hadoop-daemon.sh start namenode

  9. 在另外的其他你配置的namenode上面去执行 ./bin/hdfs namenode -bootstrapStandby

  10. 把刚才第8步启动那个namenode先停掉 ./sbin/hadoop-daemon.sh stop namenode

  11. 启动ZK集群 3台机器上执行/opt/soft/zookeeper-3.4.8/bin/zkServer.sh start

  12. 在其中某一台namenode节点上面来完成 ./bin/hdfs zkfc -formatZK

  13. 在其中某一台namenode节点上面来完成 启动集群 ./sbin/start-dfs.sh

  14. 启动在3或4节点上启动yarn yarn-daemon.sh start resourcemanager

有可能会出错的地方

  • 确认每台机器防火墙均关掉
  • 确认每台机器的时间是一致的
  • 确认配置文件无误,并且确认每台机器上面的配置文件一样
  • 如果还有问题想重新格式化,那么先把所有节点的进程关掉
  • 删除之前格式化的数据目录hadoop.tmp.dir属性对应的目录,所有节点同步都删掉,别单删掉之前的一个,删掉三台JN节点中dfs.journalnode.edits.dir属性所对应的目录
  • 接上面的第6步又可以重新格式化已经启动了
  • 最终Active Namenode停掉的时候,StandBy可以自动接管!

脑裂(brain-split)

脑裂是指在主备切换时,由于切换不彻底或其他原因,导致客户端和Slave误以为出现两个active master,最终使得整个集群处于混乱状态。解决脑裂问题,通常采用隔离(Fencing)机制,包括三个方面:

  • 共享存储fencing:确保只有一个Master往共享存储中写数据。
  • 客户端fencing:确保只有一个Master可以响应客户端的请求。
  • Slave fencing:确保只有一个Master可以向Slave下发命令。

Hadoop公共库中对外提供了两种fenching实现,分别是sshfence和shellfence(缺省实现),其中sshfence是指通过ssh登陆目标Master节点上,使用命令fuser将进程杀死(通过tcp端口号定位进程pid,该方法比jps命令更准确),shellfence是指执行一个用户事先定义的shell命令(脚本)完成隔离。

参考

Juforg wechat
欢迎您扫一扫上面的微信公众号,订阅我的博客!