HDFS2.x利用ha和f解决HDFS1.0单点故障和内存受限问题

HDFS HA（高可用）解决单点故障问题

主备NN解决：涉及到数据同步的问题

• HDFS HA包含namenode Active和namenode Standby。namenode Active 包含两部分信息：datanode的edis和客户端信息。然而客户端只连接namenode Active汇报自己的结构树信息，
  还有一个namenode Standby如果同步信息数据？

• 尝试：其实只要scoket通信，客户端创建结构时直接由NNA告诉NNS
  具体实现过程中，若NNA和NNS由于网络波动，导致客户端一直失败。这就是由于一致性的目标而破坏了可用性 “强一致性破坏可用性”

• 真正解决方案：NFS技术，网络文件系统
  利用这种技术可以将两个NameNode的目录指向外部的一个服务器(JN)。这样就完全同步了。也不用担心两个NameNode之间通信耽误时间的问题，哪怕Standby网络波动，也可以“最终一致”

• 扩充：这又是一个新的单点问题，要需要新的技术解决。除了hadoop，还要有别的技术…

ZKFC ZooKeeperFailoverController 故障转移器

• 两个NN都有自己的ZKFC，与NN近源，然后ZKFC连接着zk。ZKFC的目的是为了检测NN是否还在

zk提供目录树结构、事件监听机制(回调)、session机制

• 开机的时候NN地位相等，需要协调一下谁是active，两个ZKFC去zk中的目录树争抢一个锁，抢到的即为active

那么就会有两种异常情况

• NN 挂了
  此时ZKFC首先知道，因为利用zk的watcher机制一直在监听，然后会去zk里面删除创建的avtive节点（事件）
  同时，另一个ZKFC也在监听，由此也上升自己的NN
  针对这个事件，整体过程响应按照顺序：
  active挂了 – 对应的ZKFC删除zk中avtive – 第二个ZKFC捕捉到了 – 上升standby为active
  这个过程zk很简单，适合做分布式协调，只是传导信息
• ZKFC 挂了
  session发挥作用（时间性）
  zk对创建的session计时，zk删除ZKFC（事件），并且另外的ZKFC会将NNA降下去，将NNS升上来
  并且两个ZKFC硬件的串口连接，一旦一个ZKFC挂了，另一个会断当前的电，这样就不会让JN矛盾，不会同时有两个active

联邦

这里ZKFC和nnactive的连接是通过linux file system实现的ZKFC里面的代码由开发人员实现，这块才是经常使用的。

HDFS F（联邦）解决压力过大，内存受限，影响扩展性问题

联邦机制

• 公司旧部门有50台服务器，新部门说有洁癖需要新买50台，独立玩自己的。这个时候旧部门有一个大项目，需要100台做个集群，使用联邦可以将这100台放在一起，但是各自独立，比如各自有自己的NN active，但是并不能拿到对方的源数据，所以并不能去访问对应的文件。

公司角度看联邦
不同的部门对数据的需求不一样，可以通过多个NNA去拿数据。
这个时候用到平台文件系统，通过不同API访问数据，平台文件系统平台通过平台解耦，实现多种功能，比如hdfs ftp hbase等等

联邦里的nn挂了一个，这个时候就有单点故障的问题，再针对每个nn做ha，保证数据可靠性
来个客户端，访问完nn，就去和datanode通信去了，这个时候需要对平台的文件系统做负载均衡，比如nginx，根据目标不同服务需求，转到不同负载的server中去。这是架构师的职责