HDFS架构和HA集群的简单理解
一.简述HDFS架构
HDFS是Hadoop分布式文件系统, 采用Master/Slave的架构来存储数据,这种架构主要由四个部分组成,分别为HDFS Client、NameNode、DataNode和Secondary NameNode.
HDFS架构图
二.HDFS架构中的角色
1.HDFS Client：客户端
a.文件切分
文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
b.操作文件系统
读/写/修改元数据。与 NameNode 交互，获取文件的位置信息; 与 DataNode 交互，读取或者写入数据。
2.NameNode:Master, 管理文件系统的命名空间,存储文件和目录的元数据，响应客户端的请求
a.元数据以两种方式在NameNode本地进行持久化
(1)fsimage:命名空间镜像文件
(2)edits log:编辑日志
b.元数据存储信息:
(1) 文件名称
(2) 文件的block副本个数
(3) 修改和访问的时间
(4) 访问权限
(5) block大小以及组成文件的block信息
其中，block的DataNode位置信息不会记录到fsimage, 这些信息在每次系统启动的时候从DataNode重建。之后DataNode会周期性地通过心跳包向NameNode报告block信息。
3. DataNode:Slave, 存储block信息,执行block的读/写操作。NameNode 下达命令，DataNode 执行实际的操作。
DataNode存储模型:
(1) 文件按字节线性切割成块(block)
(2) block分散存储在集群节点中
(3) block的大小默认为128MB(从2.7.3版本开始为128MB,之前的版本是64MB),对于同一个文件,block大小必须一致,不同文件可以不一致。
(4) block的副本数默认为3, 不要超过节点数量。副本分散在不同节点中，可以容错、解决并发读、承担计算。
(5) 文件上传时可以设置block大小和副本数,已上传的文件不可以修改block大小,可以修改block副本数。
(6) 只支持一次写入多次读取，同一时刻只能有一个写入者。
(7) 可以append追加数据
4.Secondary NameNode:为NameNode内存中的文件系统元数据生成检查点(checkpoint),创建检查点(fsimage和edits log的合并)步骤:
(1) secondarynamenode请求namenode生成新的edits log文件并向其中写日志。
(2) SecondaryNameNode通过HTTP GET的方式从NameNode下载fsimage和edits文件到本地。
(3) SecondaryNameNode将fsimage加载到自己的内存，并根据edits log更新内存中的fsimage信息，然后将更新完毕之后的fsimage写到磁盘上。
(4) SecondaryNameNode通过HTTP PUT将新的fsimage文件发送到NameNode，NameNode将该文件保存为.ckpt的临时文件备用。
(5) NameNode重命名该临时文件并准备使用。此时NameNode拥有一个新的fsimage文件和一个新的很小的edits log文件。
三.HA集群的架构图
四.HA集群角色
1.Namenode
2.Datanode
3.journalnode：元数据的存储
当用户发生修改操作之后，会通知所有的journalnode，只有过半的journalnode都接受到请求之后才会生效，一般配置为奇数台 配置三个是最合适的 当其中两个接受后就可以进行
4.Zkfc：监控namenode的状态，当active namenode宕机之后，会完成自动切换
如果要实现手动切换，可以没有zkfc
五.HA集群启动流程
1. 一个NameNode进程处于Active状态，另几个NameNode进程处于Standby状态。Active的NameNode负责处理客户端的请求。
2. Active的NN修改了元数据之后，会在JNs的半数以上的节点上记录这个日志。Standby状态的NameNode会监视任何对JNs上edit log的更改。一旦edits log出现更改，Standby的NN就会根据edits log更改自己记录的元数据。
3. 当发生故障转移时，Standby主机会确保已经读取了JNs上所有的更改来同步它本身记录的元数据，然后由Standby状态切换为Active状态。
4. 为了确保在发生故障转移操作时拥有相同的数据块位置信息，DNs向所有NN发送数据块位置信息和心跳数据。
5. JNs只允许一台NameNode向JNs写edits log数据，这样就能保证不会发生“脑裂”。
6. 提供两种切换选择实现主备之间的切换
手动切换：通过命令实现主备之间的切换，可以用HDFS升级等场合
自动切换：基于Zookeeper实现
基于Zookeeper自动切换方案
ZooKeeper Failover Controller：监控NameNode健康状态，
并向Zookeeper注册NameNode
NameNode挂掉后，ZKFC为NameNode竞争锁，获得ZKFC 锁的NameNode变为active
六.搭建HA集群的几个问题
1、ZKFC和NameNode进程的启动有什么一定的次序吗？
没有。先启动哪个都行
2、我应该监控哪些？
首先，你应该监控每个运行NameNode的节点以保证ZKFC运行正常。在一些zookeeper失效的案例中，例如ZKFC突然退出，需要重启以保证系统还可以自动故障切换。
你也需要监控zookeeper的quorum集群中的每一台主机。如果zookeeper崩溃，就不能自动故障切换了。
3、如果zookeeper宕机，会发生什么？
如果zookeeper集群宕机，不会触发自动故障切换。然而，HDFS还会不受影响地继续运行。当zookeeper重启之后，HDFS会重新连接不受影响。
4、我可以指定哪个NameNode作为主节点吗？
不能。当前版本不支持。一般哪个NameNode启动的早，哪个NameNode作为主节点。你可以选择让集群中的NameNode以一定顺序启动，比如你向做active的NameNode首先启动。
5、在配置自动故障切换之后我如何手动触发故障切换？
即使在自动故障切换配置之后，你还可以使用相同的hdfs haadmin命令触发手动的故障切换。
七.验证自动故障切换
1、首先找到active的NameNode。
2、在active的节点上引发一个失效。例如：你可以kill -9 <nn的PID>模拟一个JVM崩溃。或者你可以重启服务器或者拔掉网点然后再接上。
3、在发生active失效的情况下，几秒之后其他的NameNode之中应该有一个变为active状态。检测失效并触发一个自动故障切换的时间由ha.zookeeper.session-timeout.ms配置，默认是5秒。
4、如果测试没通过，配置有可能出错了。检查zkfc进程的日志以及NameNode进程的日志来检查