关注云计算路上的一点一滴(二)

关注云计算路上的一点一滴（二）

云计算框架之 Hadoop

部署hadoop之公钥访问
1 在master,slave1,slave2,perforce四台pc上分别删除~/.ssh目录
2 分别运行ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
把master上的id_dsa.pub scp到slave1,slave2,perforce，分别重新命名成id_dsa_master.pub
3 分别在4台主机上cp id_dsa.pub 为authorized_keys
4 把master的公钥追加到每个datanode，cat id_dsa_master.pub >> authorized_keys，这样master就不需要输入密码就可以ssh到datanodes了
5 把每个datanode的公钥也追加到master的authorized_keys，这样，每个datanode，当然，也是jober，也可以不输入密码访问master，不过这不是必须的，因为通常datanode不访问master。

怎样看到各个datanode的文件
通常，定义在master和datanode之间的主机名不能被windows所知道，linux放置在/etc/hosts，windows下，修改
c:\Windows\system32\drivers\etc\hosts
127.0.0.1       localhost

109.119.20.127 slave1
109.119.20.128 slave2
109.119.20.52 master
109.119.20.129 perforce
可以在windows主机上通过web方式看到文件的名字空间
，可以在主界面上点击Live Nodes查看每个dfs的datanode的状况和目录空间。


参考资料：

Hadoop源代码分析 41篇
分析源码具体到了类，很值得一看。

分布式选举算法-Paxos

http://lxhzju.blog.163.com/blog/static/45008200911410425128/

Hadoop相关网络资源汇总

http://www.cnblogs.com/OnlyXP/archive/2009/06/14/1503175.html

HDFS详解

http://www.cnblogs.com/chinacloud/archive/2010/12/03/1895369.html

HDFS和KFS 比较

http://blog.csdn.net/cloudeep/archive/2009/08/20/4467238.aspx
http://blog.csdn.net/cnhome/archive/2010/08/04/5786807.aspx

详细讲解Hadoop中的一个简单数据库HBase

http://www.cnblogs.com/wycg1984/archive/2009/08/03/1537490.html

Hadoop源码分析-HDFS

内容如下：

为了能够让更多的朋友认识Hadoop在此附上一Google’s Solution --> Open Source Word’s Solution ：
 Google File System – Hadoop Distributed FS
 Map-Reduce – Hadoop Map-Reduce
 Sawzall – Pig, Hive, JAQL
 Big Table – Hadoop HBase,  Cassandra
 Chubby – Zookeeper

关于Hadoop的内部实现流程方案，我想列到下篇日志当中，本篇我只想讲述如何剖析这3万多行的代码。在对Java 应用程序的IO操作的基础上理解Hadoop并不难，关键是掌握程序系统各组件的依懒性，有条理的分析先做什么，后实现什么这样的原则，我的plan是：
1. 系统中存在的case : Master / Slaves / Client 其对应的实现:
Master– NameNode
Slaves–DataNode s
Client –DFSClient
2. 三者之间的通信通过IPC建立，最底层仍然是TCP，底层实现原理暂且不理，通过Hadoop 的RPC机制做出Demo。
3. 认知NameNode后发现该庞然大物犹如人体的大脑，它充当着HDFS的控制器，但尽管有着近似一万行代码的它，我们也无需慌张，现在的工作没有它的 份，聪明的朋友就会分析到，就是现在实现这样的控制器，也无法工作，因为人体还没有四肢。Okay, 接下来的任务是
4. 在RPC的基础上定义ClientProtocol / DatanodeProtocol两interface，本质上他们是RMI技术的应用。
ClientProtocol: DFSClient- -> NameNode
Allows clients to ask for DFS services.
DatanodeProtocol: Datanode - -> NameNode
Used by DataNode programs that actually store DFS data blocks.
5. 接口完了，接下来我们定义上面仨。至此，我们的第一阶段顺利完成。
6. 如果前面工作顺利的话，下面我们的工作就是DFSClient 和 Datanode 了，事实上我们通过Hadoop的官方文档便可得知，DFSClient做任何事是必须向NameNode 发出请求，等NameNode处理完请求给予响应后，才允许和Datanode交互。然而此时我们未必要实现它，就当作DFSClient直接向DataNode通信。
7. 前面没有讲到DFSClient与DaatNode的交互方式，是因为他们俩不存在请求与被响应的的策略，因此Hadoop HDFS并未使用RPC来实现他们俩之间的通信，而是直接通过底层的socket 连接Datanode的ServerSocket，以实现数据的传输。
8. 该部分的成功实现，是建立在对chunk / packet / block，以及Java IO操作的理解之上的。那么我们的任务当然是先实现上传，后下载了，原因你知道的。
9. 在完成put操作时，我们发现DataNode存储block的机制（之后的日志会说到，此处会改为链接），这里提醒一下，现在无需实现，简单的流程是， 当Datanode收到block时，我们先找本地磁盘的任意地方存放，等get操作完了之后，我们认为DFSClient 与 DataNode暂时是没有什么活要做的，那么之后，我们可以考虑研究DataNode的存储机制然后加上。
10. 前面第二阶段的工作很艰巨，而且是比较重要，这就好似我们创造了人体的四肢一样，那么接下来是更为艰巨的任务NameNode。
11. 该物如何剖析是关系到项目进度以及工作效率最受影响的因素之一，与其茫然的不停双击鼠标，还不如准备笔纸仔细的分析该如何开展工作。在注释与文档的帮助 下，找到了一个切入点，首先从DFSClient的session入手，也就是请求的开始直到结束，NameNode直始至终做了哪些工作，跟到最后一 步，大脑是如何存储记忆的，渐渐浮出水面，那就是INode。
12. 熟悉Linux OS的朋友应该知道INode的概念，我们知道block 是记录档案内容数据的地区，而INode则是记录该档案的属性，以及该档案存在哪一个block之内的信息。在terminal 中，下达ls –i 命令可以看到indoe的参数值。要想攻破NameNode，INode必须理解。
13. OK, 接下来的任务最为艰巨，那就是我们的FSNamesystem出场，解决了 它，NameNode基本上可以说所剩无几，此类有近4500行。在初步分析时，内部线程可以不用看，而工作的重点则是这样的流程interface - > NameNode->FSNamesystem->FSDirectory->INode。
14. 在完成以上流程后，可以研究FSNamesystem中的内部线程，实际上不难看出，Master Server正是使用了它们维持了整个 HDFS 系统的负载平衡。
15. 完成内部线程后，我们便可模拟数据进行测试。最后另用Shell 脚本来封装我们的系统。
以上是我研究Hadoop-HDFS系统的一般流程，其中有些知识点没有列到会在今后的日志中讲到，例如HDFS对外提供的访问接口，除了Shell ，还有web ui 。而它则是使用jetty 实现的。

分布式选举算法-Paxos

http://lxhzju.blog.163.com/blog/static/45008200911410425128/

    在分布式算法领域，有个非常重要的算法叫Paxos, 它的重要性有多高呢，Google的Chubby [1]中提到

all working protocols for asynchronous consensus we have so far encountered have Paxos at their core.

关于Paxos算法的详述在维基百科中有更多介绍，中文版介绍的是choose value的规则[2]，英文版介绍的是Paxos 3 phase commit的流程[3]，中文版不是从英文版翻译而是独立写的，所以非常具有互补性。Paxos算法是由Leslie Lamport提出的，他在Paxos Made Simple[4]中写道

The Paxos algorithm, when presented in plain English, is very simple.

当你研究了很长一段时间Paxos算法还是有点迷糊的时候，看到上面这句话可能会有点沮丧。但是公认的它的算法还是比较繁琐的，尤其是要用程序员严 谨的思维将所有细节理清的时候，你的脑袋里更是会充满了问号。Leslie Lamport也是用了长达9年的时间来完善这个算法的理论。

实际上对于一般的开发人员，我们并不需要了解Paxos所有细节及如何实现，只需要知道Paxos是一个分布式选举算法就够了。本文主要介绍一下 Paxos常用的应用场合，或许有一天当你的系统增大到一定规模，你知道有这样一个技术，可以帮助你正确及优雅的解决技术架构上一些难题。

1. database replication, log replication等， 如bdb的数据复制就是使用paxos兼容的算法。Paxos最大的用途就是保持多个节点数据的一致性。

2. naming service, 如大型系统内部通常存在多个接口服务相互调用。
1) 通常的实现是将服务的ip/hostname写死在配置中，当service发生故障时候，通过手工更改配置文件或者修改DNS指向的方法来解决。缺点是可维护性差，内部的单元越多，故障率越大。
2) LVS双机冗余的方式，缺点是所有单元需要双倍的资源投入。
通过Paxos算法来管理所有的naming服务，则可保证high available分配可用的service给client。象ZooKeeper还提供watch功能，即watch的对象发生了改变会自动发 notification, 这样所有的client就可以使用一致的，高可用的接口。

3.config配置管理
1) 通常手工修改配置文件的方法，这样容易出错，也需要人工干预才能生效，所以节点的状态无法同时达到一致。
2) 大规模的应用都会实现自己的配置服务，比如用http web服务来实现配置中心化。它的缺点是更新后所有client无法立即得知，各节点加载的顺序无法保证，造成系统中的配置不是同一状态。

4.membership用户角色/access control list, 比如在权限设置中，用户一旦设置某项权限比如由管理员变成普通身份，这时应在所有的服务器上所有远程CDN立即生效，否则就会导致不能接受的后果。

5. 号码分配。通常简单的解决方法是用数据库自增ID, 这导致数据库切分困难，或程序生成GUID, 这通常导致ID过长。更优雅的做法是利用paxos算法在多台replicas之间选择一个作为master, 通过master来分配号码。当master发生故障时，再用paxos选择另外一个master。

这里列举了一些常见的Paxos应用场合，对于类似上述的场合，如果用其它解决方案，一方面不能提供自动的高可用性方案，同时也远远没有Paxos实现简单及优雅。

Yahoo!开源的ZooKeeper [5]是一个开源的类Paxos实现。它的编程接口看起来很像一个可提供强一致性保证的分布式小文件系统。对上面所有的场合都可以适用。但可惜的 是，ZooKeeper并不是遵循Paxos协议，而是基于自身设计并优化的一个2 phase commit的协议，因此它的理论[6]并未经过完全证明。但由于ZooKeeper在Yahoo!内部已经成功应用在HBase, Yahoo! Message Broker, Fetch Service of Yahoo! crawler等系统上，因此完全可以放心采用。

另外选择Paxos made live [7]中一段实现体会作为结尾。

*  There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. In order to build a real-world system, an expert needs to use numerous ideas scattered in the literature and make several relatively small protocol extensions. The cumulative effort will be substantial and the final system will be based on an unproven protocol.
* 由于chubby填补了Paxos论文中未提及的一些细节，所以最终的实现系统不是一个理论上完全经过验证的系统

* The fault-tolerance computing community has not developed the tools to make it easy to implement their algorithms.
* 分布式容错算法领域缺乏帮助算法实现的的配套工具, 比如编译领域尽管复杂，但是yacc, ANTLR等工具已经将这个领域的难度降到最低。

* The fault-tolerance computing community has not paid enough attention to testing, a key ingredient for building fault-tolerant systems.
* 分布式容错算法领域缺乏测试手段

这里要补充一个背景，就是要证明分布式容错算法的正确性通常比实现算法还困难，Google没法证明Chubby是可靠的，Yahoo!也不敢保证 它的ZooKeeper理论正确性。大部分系统都是靠在实践中运行很长一段时间才能谨慎的表示，目前系统已经基本没有发现大的问题了。

Resources
[1] (PDF)
[2]
[3]
[4] (PDF)
[5]
[6]
[7] (PDF)