Facebook Hadoop HA
organized by aaronwxb，04.01
一些数据
- 21 PB of storage in a single HDFS cluster
- 2000 machines
- 12 TB per machine (a few machines have 24 TB each)
- 1200 machines with 8 cores each + 800 machines with 16 cores each
- 32 GB of RAM per machine
- 15 map-reduce tasks per machine
- The master had 64 GB of memory.
70 million 文件和目录
90 million 块
花费6分钟加载元数据，35分钟处理datanodes的block reports
运行情况
硬件比较可靠，软件在部署前已做好充分测试，四年来只有一次NameNode down掉。主要的中断服务的问题是给hadoop打补丁升级，DataNode打补丁比较简单，不会造成服务中断，每次对其中的一部分DataNode部署新的代码、重启，就OK了。 问题是需要给NameNode部署新的代码时,NodeNode重启需要花费1个小时，这期间所有的Hadoop服务都不能运行。
AvatarNode
两个角色
AvatarNode完全封装NameNode。AvatarNode运行有两种模式Active Avatar或者Standby Avatar.
如果启动运行在Active Avatar模式，那么它就和当前NameNode功能完全一样，其实运行的代码就是NameNode的代码。运行Active Avatar模式的AvatarNode机器，保存HDFS事务日志(edit log)到一个共享的NFS。
在另外一台机器上，启动AvatarNode的另一个实例，运行在Standby Avatar模式。 Standby AvatarNode封装了NameNode和SecondaryNameNode。Standby AvatarNode持续的从共享的NFS filer中读取HDFS edit log，并持续的把这些事务推送到Standby AvatarNode中NameNode实例。Standby AvatarNode中的NameNode运行在SafeMode。原因是不能让它负责NameNode的工作，但是必须保持和NameNode同步的NameNode Metadata信息（Standby AvatarNode从NFS中读取transaction log，同时作用在自己内存中的namespace，已使得尽量和Active AvatarNode的元数据相同）。
切换过程
HDFS客户端访问NameNode通过一个虚拟IP(Virtual IP Address,注：这块其实可以用zookeeper来取代).当发生故障需要快速切换时，管理员会在机器M1上杀掉Primary AvatarNode进程，然后在机器M2上设置Standby AvatarNode作为Primary Avatar。Standby AvatarNode会保证把所有提交的事务都处理完，因为Standby AvatarNode会重新打开edit log，并处理完文件中所有的事务.这个假设是基于NFS-v3支持close-to-open cache coherency semantics。Standby AvatarNode把所有NFS filer上的事务处理完之后，退出SafeMode模式。管理员将M2的VIP换为M1，这样所有的HDFS客户端的请求会提交到M2的实例上。这个failover一般情况只需要几秒钟。 另外根本不需要单独一台SecondaryNameNode。 AvatarNode在Standby avatar模式时，可以履行SecondaryNameNode的职责。Standby AvatarNode持续的处理从Primary Avatar来的所有的事务，在处理事务日志的空闲间隙会唤醒SecondaryNameNode进程，创建并上传一个新的checkpoint，Copy到Primary AvatarNode, 接着再回来处理事务日志。
Avatar DataNode
DataNodes同时和 Active、Standby通信，则Standby Avatar也有DataNode的最新的block信息，因此Standby可以在很短时间内转换成Active Avatar。Avatar DataNode不使用VIP和AvatarNode连接。(HDFS客户端通过VIP连接AvatarNode)。Avatar DataNodes从Zookeeper那里知道哪个Avatar是Active的，因此只执行从Active Avatar来的删除/复制操作请求，对Standby传来的请求则忽略。
backup node分析
1.BackupNode在故障恢复时还需要从各个DataNodes读取块信息，需要花费一二十分钟，而故障切换允许的时间应以秒计算。如果BackupNode从DataNodes接受和处理块信息，则BackupNode就是热备了，但和AvatarNode相似了。
2.NameNode每个事务都在BackupNode上同步更新，整个系统的可靠性就比单独的NameNode的可靠性降低了。
3. HDFS BackupNode在Hadoop 0.20中还不能用，升级Hadoop 0.20也不是一个很好的选择。这个升级部署之前，需要花费大量时间做测试。
缺点
没有实现自动切换
注：