昨天提车，颤颤悠悠的开回家，停入地下车库，总感觉要撞，慢，一定要慢，提醒自己。
这是早期写的一篇文章，记录在blogger，自己转过来。
众所周知 hadoop是一个单点系统，即所谓的spof，所以元数据的保护就是重中之重。目前元数据写两份，分别是本地的磁盘，远程的磁盘。还有一个secondary namenode做冷备。写到远程的磁盘就需要的是NFS服务了。
NFS(Network File System, 网络文件系统)可以通过网络将分享不同主机(不同的OS)的目录——可以通过NFS挂载远程主机的目录, 访问该目录就像访问本地目录一样。
首先下载NFS,网址是http://sourceforge.net/projects/nfs/files/ 选择合适的版本下载。到server和client机器安装。
编辑server主机的文件/etc/exports /etc/hosts.allow /etc/hosts.deny三个文件。
对/etc/exports 加入例如：/data0 10.39.2.121(rw,no_root_squash)
一、说明
Hadoop无论是1.x还是2.x机器不同角色之间的通信全部是通过RPC完成的，RPC底层都是通过Dynamic Proxy完成，无外乎就是TCP连接，验证协议，提取字段等等。所不同的是1.x采用的是plain java自己完成序列化与反序列化，而2.x底层采用的是PB序列化与反序列化，造成了使用的不同。
二、Dynamic Proxy基本概念
Dynamic Proxy是动态代理，采用的是反射技术，在运行时动态生成对象，要求代理类与实际执行类具有相同的接口,同时实现InvocationHandler接口，最后通过Proxy类生成代理类：
Proxy.newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h)
参数第一个为ClassLoader,第二个为共同的interface，第三个是实现的handler方法。这样调用代理的相应方法会调用handler方法。
三、RPC in Hadoop 1.x
Hadoop底层RPC通信采用Dynamic Proxy，这样隔离了不同身份的机器之间底层连接检验等细节，而专注于业务逻辑。
下面是Hadoop 1.x RPC的一个简单流程，比如DFSClient想要与NameNode通信，建立RPC连接。
(一)Client端
今早被人发邮件说集群任务有个reduce一直无法完成，查看了一下日志，发现有大量的创建块操作失败，根据以往的经验，当年曾经被桌面级磁盘坑过，这种情况无外乎是压力过大，导致pipeline长时间无法建立。然后通过ganglia检查后发现并没有太大的压力。
检查DataNode日志发现有大量的too many open files错误，很低级的错误，装机后没有改好配置。
ulimit -a 后印证了想法，nofile为1024。
同时记录一下：
18内核修改/etc/security/limits.conf文件,32内核除了修改上面的文件，还需要修改/etc/security/limits.d/90-nproc.conf文件。
* soft nofile 65535
* hard nofile 65535
有些时候集群中的机器无法联网，通过yum进行安装，这样就需要找一个相同内核的机器将rpm下载后再到相应的机器上进行安装，以解决这一问题。
yum 有相应的工具完成这一任务。
1、首先安装yum-downloadonly。
yum install yum-downloadonly
2、如果是新安装，使用命令
yum install httpd –downloadonly —downloaddir=./httpd
如果是升级，则使用
yum update httpd -y –downloadonly —downloaddir=./httpd
3、然后将rpm拷贝到指定机器
rpm -ivh 安装即可
Hadoop从2.4开始支持HDFS层面的ACLs，新的ACLs功能包含了新的api，使用方法以及使用场景，本测试探查ACLs与我们原先基于主机与组的ACLs的结合，以及ACLs使用方法等。
一、配置增加
为了使用ACLs，需要在NameNode增加一个配置选项，为:
<property>
<name>dfs.namenode.acls.enabled</name>
<value>true</value>
</property>
默认是不开启的。
二、说明及使用场景
hadoop原先使用的permission比较简单，采用的是类似Linux POSIX，即定义User，Group 和Other的权限。对文件或者目录做的任何操作都会进行permission check。permission check的步骤如下：
1、检查用户是否是文件或者目录Owner，如果是检查权限，权限符合返回
2、检查用户组是否在文件或者目录的Group中，用户组是通过原先的ACLs获得，如果在相应的组中，符合权限就返回
3、最后检查Other的权限，如果满足就返回
4、如果都不符合，抛出AccessControlException
可以看到，以前的权限检查比较简单，相应的角色也只有User,Group,Other,对于稍微复杂的需求存在缺陷。比如:
1、需要对某些文件对多个用户开放读权限，但是所有用户都不属于同一个组
2、某些文件开放对多个组用户的访问权限，但是不同组中所有用户并不能归为一个大组等其它很多用处。所以新增的ACLs能够满足用户的大量对权限管理的需求。
相对于1.x版本的Hadoop，2.x版本的Hadoop采用了Protocol Buffer作为序列化反序列化工具，以及RPC通讯工具。这样当我们对Hadoop源码进行修改之前，就需>要了解Hadoop 2.x的代码结构和修改方法。
几个结构，以DatanodeProtocol举列子：
DatanodeProtocol.java 还像1.x一样只是一个接口，NameNode继承这一个接口，实现所有功能，但2.x新增了DatanodeProtocolPB.java，DatanodeProtocolClientSideTranslatorPB.java, DatanodeProtocolServerSideTranslatorPB.java三个类。除此之外，还有PB文件,路径在$HADOOP_SOURCE_HOME/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/。maven编译的时候会将相应的类生成到target目录下，并加入CLASSPATH中。
1、DatanodeProtocol.proto
PB文件，定义了message以及service，如果
PB文件，定义了message以及service，如果加入一个接口，需要在其内部定义rpc service。
编辑好后需要通过protoc进行编译，使用maven默认的goal mvn generate-sources即可以。
Hadoop 滚动升级非常方便，只需要在配置中增加一些选项就可以通过Hadoop自身的代码进行完成。
步骤：
1、首先到需要升级的NameService的Active NameNode上面，比如我们10.39.2.131是ns1的Active NameNode。
2、新增加的配置：
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(/bin/true)</value>
</property>
3、在ActiveNameNode上面使用命令
hdfs haadmin -ns ns1 -failover nn1 nn2
将nn1切换为Standby，nn2切换为Active。随后看一下web页面，确认这一过程完成顺利。
(如果这一过程失败，采用手动切换。
(1)如果ActiveNameNode没有切换为StandbyNameNode
hdfs haadmin -ns ns1 -transitionToStandby nn1
(2)确认nn1进入standby状态，防止client读取过期的数据。
hdfs haadmin -ns ns2 -transitionToActive nn2)
This is a test from my macbook pro. I use MarsEdit apps. Thank you.