Hadoop之HA高可用性
HA存在的背景：
HA的工作原理图：
HDFS HA高可用性
1、active namenode对外提供服务和standby namenode时刻待机准备的
2、保证两个namenode任何时候都是元数据同步的
3、standby namenode同样需要去读取fsimage和edits文件
-》edits变化后的数据文件同样也是需要实时同步的
4、如何同步日志信息
cloudera公司提出一个方案，分布式存储日志文件
编辑日志文件写入，一写写多份，结合之前讲解的ZK的2n+1的概念
策略：写多份，再读取，前提条件节点数目必须是奇数个
active namenode和standby namenode有一块共享存储日志的区域
5、JounralNode日志节点：专门管理编辑日志文件的
-》QJM全称是Quorum Journal Manager, 由JournalNode（JN）组成，一般是奇数点结点组成。每个JournalNode对外有一个简易的RPC接口，以供NameNode读写EditLog到JN本地磁盘。当写EditLog时，NameNode会同时向所有JournalNode并行写文件，只要有N/2+1结点写成功则认为此次写操作成功，遵循Paxos协议。
-》注意在HA的架构下，就不需要secondarynamenode了
-》JN日志节点是一个轻量级的，所以可以和Hadoop的其他守护线程放在一起
6、datanode需要向standby namenode实时汇报块的状态信息
7、如何帮助客户端判断HDFS正在提供服务的namenode
-》通过代理的方式判断
8、在任何时刻下，必须要保证只有一个namenode对外提供服务
-》当两个namenode启动以后，由ZK来完成选举，选举出一个active namenode
-》隔离机制
JournalNodes：
主备切换机制：
从图中可以看出，整个切换过程是由ZKFC来控制的，具体又可分为HealthMonitor、ZKFailoverController和ActiveStandbyElector三个组件。
- ZKFailoverController: 是HealthMontior和ActiveStandbyElector的母体，执行具体的切换操作
- HealthMonitor: 监控NameNode健康状态，若状态异常会触发回调ZKFailoverController进行自动主备切换
- ActiveStandbyElector: 通知ZK执行主备选举，若ZK完成变更，会回调ZKFailoverController相应方法进行主备状态切换
在故障切换期间，ZooKeeper主要是发挥什么作用呢，有以下几点：
- 失败保护：集群中每一个NameNode都会在ZooKeeper维护一个持久的session,机器一旦挂掉，session就会过期，故障迁移就会触发
- Active NameNode选择：ZooKeeper有一个选择ActiveNN的机制，一旦现有的ANN宕机，其他NameNode可以向ZooKeeper申请排他成为下一个Active节点
- 防脑裂： ZK本身是强一致和高可用的，可以用它来保证同一时刻只有一个活动节点
那在哪些场景会触发自动切换呢，从HDFS-2185中归纳了以下几个场景：
- ActiveNN JVM奔溃：ANN上HealthMonitor状态上报会有连接超时异常，HealthMonitor会触发状态迁移至SERVICE_NOT_RESPONDING, 然后ANN上的ZKFC会退出选举，SNN上的ZKFC会获得Active Lock, 作相应隔离后成为Active结点。
- ActiveNN JVM冻结：这个是JVM没奔溃，但也无法响应，同奔溃一样，会触发自动切换。
- ActiveNN 机器宕机：此时ActiveStandbyElector会失去同ZK的心跳，会话超时，SNN上的ZKFC会通知ZK删除ANN的活动锁，作相应隔离后完成主备切换。
- ActiveNN 健康状态异常： 此时HealthMonitor会收到一个HealthCheckFailedException，并触发自动切换。
- Active ZKFC奔溃：虽然ZKFC是一个独立的进程，但因设计简单也容易出问题，一旦ZKFC进程挂掉，虽然此时NameNode是OK的，但系统也认为需要切换，此时SNN会发一个请求到ANN要求ANN放弃主结点位置，ANN收到请求后，会触发完成自动切换。
- ZooKeeper奔溃：如果ZK奔溃了，主备NN上的ZKFC都会感知断连，此时主备NN会进入一个NeutralMode模式，同时不改变主备NN的状态，继续发挥作用，只不过此时，如果ANN也故障了，那集群无法发挥Failover, 也就不可用了，所以对于此种场景，ZK一般是不允许挂掉到多台，至少要有N/2+1台保持服务才算是安全的。
HDFS HA架构部署1、准备一个完全分布式的Hadoop环境一个完全分布式的zookeeper环境为了保证出错可以恢复，建议重新备份一份完全分布式的环境2、在配置之前，先关闭整个集群的所有服务3、修改hdfs-site.xml文件-》将secondarynamenode参数删除，不需要-》给namenode管理的元数据空间起一个逻辑名称<property> <name>dfs.nameservices</name> <value>ns1</value></property>-》指定两个namenode的逻辑名称<property> <name>dfs.ha.namenodes.ns1</name> <value>nn1,nn2</value></property>-》指定两个namenode的实例，RPC内部通信，监听地址<property> <name>dfs.namenode.rpc-address.ns1.nn1</name> <value>bigdata-01.yushu.com:8020</value></property><property> <name>dfs.namenode.rpc-address.ns1.nn2</name> <value>bigdata-02.yushu.com:8020</value></property>-》指定两个namenode的实例，http监听地址<property> <name>dfs.namenode.http-address.ns1.nn1</name> <value>bigdata-01.yushu.com:50070</value></property><property> <name>dfs.namenode.http-address.ns1.nn2</name> <value>bigdata-02.yushu.com:50070</value></property>-》指定journalnode日志节点的uri<property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://bigdata-01.yushu.com:8485;bigdata-02.yushu.com:8485;bigdata-03.yushu.com:8485/ns1</value></property>-》指定JN本地存储日志的路径<property><name>dfs.journalnode.edits.dir</name><value>/opt/app/moduels/hadoop-2.5.0/data/dfs/jn</value></property> ->>配置代理<property><name>dfs.client.failover.proxy.provider.ns1</name><value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value></property>-》指定选择哪个隔离的方案，选择SSH<property> <name>dfs.ha.fencing.methods</name> <value>sshfence</value></property><property> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/home/ds/.ssh/id_rsa</value></property>-》指定是否开启自动故障转移功能<property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value></property>-》修改core-site.xml文件，指定ZK的实例和端口号<property> <name>ha.zookeeper.quorum</name> <value>bigdata-01.yushu.com:2181,bigdata-02.yushu.com:2181,bigdata-03.yushu.com:2181</value></property> -》指定管理的命名空间<property><name>fs.defaultFS</name><value>hdfs://ns1</value></property>4、将配置文件分发到各个节点上$ scp -r etc/hadoop/ bigdata-02.yushu.com:/opt/app/hadoop-2.5.0/etc/$ scp -r etc/hadoop/ bigdata-03.yushu.com:/opt/app/hadoop-2.5.0/etc/5、首先先启动所有节点的ZKbin/zkServer.sh start6、再启动所有节点的JN$ sbin/hadoop-daemon.sh start journalnode7、如果是一个新的集群那么需要首次格式化namenode，如果不是新的集群可以不用bin/hdfs namenode -format只需要格式化一台，因为两个namenode管理的是同一个元数据空间注意：先启动第一台的namenode再操作下面的元数据同步sbin/hadoop-daemon.sh start namenode8、同步元数据切换到第二台的namenode机器，执行元数据的同步可以使用bin/hdfs namenode -help参数查看shell命令$ bin/hdfs namenode -bootstrapStandby启动三台机器的 datanode sbin/hadoop-daemon.sh start datanode9、先暂时停掉两台namenode服务进程10、ZKFC监听器DFSZKFailoverController11、初始化ZKFC$ bin/hdfs zkfc -formatZK进入ZK的客户端，检查是否生产了hadoop-ha的节点目录12、在两台namenode所在的机器去分别启动ZKFC监听器$ sbin/hadoop-daemon.sh start zkfc13、启动两台 namenode 总结流程：1、ZKFC监控namenode的状态（active状态的）2、ZKFC链接zookeeper，进行选举，在后续的阶段中保持心跳3、另一个ZKFC也会去监控对应的namenode4、ZKFC链接zookeeper，进行选举，在后续的阶段中保持心跳5、active namenode出现异常6、ZKFC会在监控周期中检测到active失效，触发故障切换的流程7、ZKFC记录失败的active的信息，去通知standby的ZKFC8、standby的ZKFC接收到通信，进入切换流程，首先进行隔离，确保失效的active隔离在集群外9、ZKFC进行选举，确认自己成为新的active节点10、选举后，通知本机从standby切换到了active，然后正式接管集群，相应外部请求处理任务