Hadoop_HDFS架构和HA机制
Hadoop学习笔记总结
01.HDFS架构
1. NameNode和ResourceManager
NameNode负责HDFS，从节点是DataNode；ResourceManager负责MapReduce，从节点上是NodeManager。
2. NameNode工作原理
元数据内容
名字，几个副本，几个块_Id，每一个块在哪些主机上。
实际是真实文件和系统block块的映射。
NameNode职责
- 维护元数据信息
- 维护hdfs目录树
- 响应客户端请求
NameNode元数据管理机制
（1）NameNode在内存中保存metedata，为了快速处理“读请求”。硬盘中存放着metedata，为了持久化存储和安全。
（2）有“写请求”到来时，NameNodeNN以日记的形式追加最新的文件信息写edit_log到磁盘中。上传给DataNode成功后，NN才在内存中再将这次操作的元数据写入，实现了内存中存放的最新的元数据信息，提供以后的快速查询。
（3）写文件时，edit_log最先更新，然后内存再更新；但fsImage不是立即更新。fsimage和内存中的一致性是通过edit_log隔断时间合并入fsimage来保证的。
上传文件_原理图和元数据管理图
上传文件：
（1） 申请上传文件(向NameNode)
（2） NameNode返回分配的DataNode给客户端
（3） 客户端向第一个DataNode写入第一个块，……
（4） DataNode负责复制副本。第二个副本会优先放在另外的机架上。保证安全性。
Ps: 当大量小文件存放时，浪费的是NameNode的元数据存储空间，而不是DataNode上的空间。
3. SecondNameNode作用
Hadoop 1.X中的SecondNameNode
从上面可以看到edit_log需要定期和fsimage合并，但是如果在NameNode中合并过于消耗资源，因而在SecondNameNode中合并。是HA的一种方式，但不支持热备份。
SecondNameNode合并文图
（1）发现edit_log达到64MB的合并条件，通知SN进行checkpoing操作。
（2）请求NN停止向edit文件写数据，并新建一个edit_new来存新的元数据。
（3）SN从NN下载fsImage和edits(Http get)，在内存中合并并通过Http post将新的fsImage文件发回NN，替换旧的fsImage。
（4）SecondNameNode不是一个热备份，其拥有的fsImage不是最新的，因为还有edit_new中的数据，可以将损失减小到最小。
（5）NameNode宕机，元数据的可靠性是有保证的，但是服务的可靠性不能保证（需要HA机制）。
（6）check_point触发有两个条件：1.edits_log满(fs.checkpoint.size,默认大小是64M)和设定的时间到了(fs.checkpoint.period,3600秒)。
Ps：集群NameNode宕机时，集群如何对外保证服务？
HA机制，高可用性，两个NameNode，一个在工作active，一个停止standby。
Hadoop 2.x中fsImage和edits_log的合并
Hadoop2.x中使用了配置奇数个JournalNode来存储共享的edits log来实现HA。元数据保持一致。Active NN负责更新共享的edit_log，而Standby NN负责观察edits log的变化，它能够读取从JNs中读取edits信息，并更新其内部的命名空间。
那么这种机制是如何实现fsimage和edits的合并？步奏如下：
（1）客户端所有的更新操作将会写到JournalNodes节点的共享目录中。
（2）Active Namenode和Standby NameNode从JournalNodes的edits共享目录中同步edits到自己edits目录中；
（3）Standby NameNode中的StandbyCheckpointer类会定期的检查合并的条件是否成立，如果成立会合并fsimage和edits文件；
（4）Standby NameNode中的StandbyCheckpointer类合并完之后，将合并之后的fsimage上传到Active NameNode相应目录中；
（5）Active NameNode接到最新的fsimage文件之后，将旧的fsimage和edits文件清理掉；
（6）通过上面的几步，fsimage和edits文件就完成了合并，由于HA机制，会使得Standby NameNode和Active NameNode都拥有最新的fsimage和edits文件（之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的）,因而其实不必要运行SecondNameNode。
参考来自《http://blog.csdn.net/wisgood/article/details/47066077》
02. HA（高可用）机制
在hadoop2.0之前，namenode只有一个，存在单点问题。hadoop2.0的HA机制官方介绍了有2种方式，一种是NFS（Network File System）方式，另外一种是QJM（Quorum Journal Manager）方式。
下面是QJM方式：
1. HDFS的HA
补充:
- HDFS 的HA功能通过配置Active/Standby 两个NameNodes实现在集群中对NameNode 的热备来解决上述问题。
- 快速的无缝切换，需要元数据时刻一致，所以原先fsimage是放在NameNode本地就行不通了，需要将edits放在JournalNodes集群中。
- QJournal是一个分布式应用，管理edits，提供元数据的更新和读写操作，底层使用了zookeeper集群实现（所以需要安装zk）。这样实现了edit的高可用，也是半数个节点存在，就能对外提供正常读写操作。启动zookeeper后，启动journalnode进程，在jps中就会有一个JournalNode来对外服务。
- 当一个NameNode宕机，另一个如何感知其失败。如何监控？在每一个NameNode上启动一个监控进程zkfc，来监控NameNode状态，并向zookeeper写入一个本机状态，另一个NameNode上的zkfc就可以定时知道另一个是否宕机。
- zkfc作用就是：解决两个NameNode的状态切换管理。
- 脑裂(brain split现象)：定义：当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。比如，一台NameNode假死后复活，造成两个NameNode都是Active状态后，读写edits日志造成混乱。
- 如何解决脑裂？fencing（规避）机制来保证。当它发现另一个NameNode异常，不会立刻切换本机为Active。首先，它会通过ssh发送一个指令去kill掉对方进程。指令执行成功，得到执行成功的返回码后，执行切换Active指令。（sshfence）
- 但是，发送了ssh后，如网络断开，未得到返回值，zkfc不知道是否该不该切换。还有一个定义超时时间，如果超时时间到了，还没有得到返回值，能执行一个自定义的Shell脚本程序。来关机等操作。避免脑裂现象。(fence_shell脚本)
- 故障的切换是对用户透明的，因而，HDFS URI的主机是一个逻辑主机名，映射到一对NameNode地址（配置文件中有）
- 联邦Federation HDFS. 每一对NameNode都是组成一个联邦。一个集群中可以由很多个NameService，来对外工作。
2. HDFS——HA的测试
在实现了HDFS的HA后，如下情形测试：
（1）杀掉active状态的NameNode进程，Hadoop能迅速切换standby->active。
（2）断电形式断掉active机器，则需要等待30秒，因为standy机器中的会等待发送的SSH指令，等待后再执行shell脚本。
（3）在上传文件中杀掉NameNode进程，文件依然能够上传成功。
足以证明，HDFS的HA机制还是很强大的。
初接触，记下学习笔记，还有很多问题，望指导，谢谢。
