namenode+secondaryNamenode fsimage持久化+edit日志，处理操作放在edit里面，一段时间过后，edit文件数量巨大，需合并在SN上面，SN将image+edit下载到本地 合并在内存变成一个大的全的image，合并完成，返回给NN替换原来的image
但，一旦NN宕机，就不能提供服务，所以要两个namenode，一个active一个是standby
数据同步：keepalived不能解决数据同步问题,分布式麻烦时，用第三方或者增加集群字节点数量，
所以将active edit日志文件放在一个第三方上面，因为image太大且不容易更新需加载到内存，所以将edit日志放到第三方,NN共享
解决数据同步，就差最后一条inprogress那条日志不能同步，一旦activeNN死掉，standby就可以上任
但 第三方一旦挂掉，NN是可以工作，但NN间的数据就不会同步了
所以，第三方变成集群，每台机器都保留日志，但数据一致性就会降低，机器数量多，同步延迟，但也不会差太多
第三方为zookeeper来进行协调，实现日志管理叫做 quorum journal node借助zk协调，
但NN中也要保留点edit，更加可靠，同步线程同步去存，本地存，第三方也存，但第三方有多台机器，只要能保证多数台成功就认为成功
active和standby的状态管理和切换通过ZKFC（zookeeper Failover Controller）即在每一个namenode下面也是依赖于zookeeper和quorum journal node的zookeeper是同一个
首先 zkfc通过rpc调用active 根据返回值等判断namenode状态，一旦active挂掉，不会直接通知standby，而是通过zookeeper的监听机制即 active和standby事先会在zookeeper中建立一个节点表示状态，一旦active挂掉就会删除此节点，另zkfc在监听此节点，发现删除，rpc调用standby->active接着在往zookeeper注册一把锁声明其为active
但在状态变成active之前，会判断原来的namenode是否为真的挂掉，可能会假死，若恢复，两个activer，所以，保证activedeque挂掉
通过ssh远程kill -9 通过返回值判断是否杀死，但网络会超时等，长时间没有返回值，所以通过用户脚本强制kill 然后就会切换到active
而yarn就没那么紧迫的需要高可用了，因为没有什么元数据同步等问题，挂掉重启就好了
一台active 可以多台standby因为不涉及数据同步元数据管理active向zk注册一把锁声明其为active
namenode容量的水平扩展，如果数据非常多，namenode的内存磁盘等会被沾满，所以就要扩容，不是指加磁盘，加内存，内存最大也就好像是128G，反正不可能在一台机器上堆加，所以就要namenode容量的水平扩展，
就需要多个namenode 前面的高可能实际上算是一个namenode，因为数据完全是一样的，
多个namenode同时都对外提供服务，那么数据就会不同步，所以需要hdfs分目录，分区，请求指定目录去指定的namenode
两个namenode就变成federation联邦
两个namenode互不影响，其中任意一个都可以在HA
HA下的一对namenode 在客户端访问的时候 会有个逻辑名称可以自己配比如ns1 客户端访问ns1，客户端解析配置文件到zk知道哪个是active
在federation中有多台namenode 再通过上层封装ViewFs://path访问
federation datanode
datanode不需要分开，如果分开就变成两个集群了就意义了，datanode可以共用
datanode有clusterId，看自己归属于哪个namenode，HA两个namenodeclusterId相同，然后还要让federation中的namenode clusterId相同，共享datanode，但datanode中还有个标志叫做blockpool为namenode的ip地址，声明某个块属于federation中的namenode