今天被前同事问起NameNode都启动了哪些端口，分别是IPC server, Http Server, jmx Server,但是netstat -anlp发现不止有三个，是五个。经过我同事分析，多出的两个是

启动java 的profile 参数（jvisualvm的参数）

-Dcom.sun.management.jmxremote=true
-Djava.rmi.server.hostname=ip
-Dcom.sun.management.jmxremote.port=9986
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

注意：这里这一组参数会启动3个端口，分别是因为 com.sun.management.jmxremote=true 启动一个随机
com.sun.management.jmxremote.port=9986 启动一个9986端口以及再启动一个额外的随机端口

正是因为hadoop-env.sh脚本中带有-Dcom.sun.management.jmxremote 属性，才导致hadoop本身又多起了一个端口

一、背景

      Hadoop目前使用Distcp作为集群间的数据传输工具，但是Hadoop2.0 可以采用federation，每个ns公用存储节点，这样还采用Distcp作为集群间数据传输将会非常浪费，直接的想法就是能够通过硬链接将federation中共用存储的block也进行共享，就会大大的节省带宽，IO，网络以及时间。

 

 

 

二、流程说明

 

      整体流程如图，以下为简要说明：

1、Client首先向Source NS1获取需要拷贝的文件的block location

2、对每一个block，根据Source得Location向Dest NS2申请block，并尽量申请到同一个DataNode节点

3、向DataNode发送File copy的RPC请求

4、DataNode获得请求后查看源DataNode和目的DataNode是否是同一台机器上的同一个实例的DataNode，如果是通过hard link完成copy

5、如果不是，退化为常规的机器间拷贝

    想要调整Hadoop DFSClient的级别很简单，只要在启动前加入以下环境变量就可以了。

    export HADOOP_ROOT_LOGGER=DEBUG,console

一、背景

 

    Hadoop 2 开始采用JournalNode作为共享存储，JournalNode由NameNode部分的QuorumJournalManager,IPCLoggerChannel及JournalNode Server端的JournalNodeRPCServer组成。

 

    IPCLoggerChannel由一个JournalNode对应一个线程去完成日志的发送，保证日志的有序性，同时根据Paxos算法，绝大多数JournalNode完成回应就算完成日志发送。

 

    原先Hadoop 1采用的是本地记录Editlog并在远程NFS上记录一份，使用JournalNode后，我们需要获得相应的数据来比较JournalNode性能及对NameNode的影响。

 

 

 

二、测试方法

 

    分别采用1，3，5台机器组成journalNode，测试每分钟写入的日志数，并且与大集群相比，得到比较结果。

 

    以下数据是从大集群获得的每分钟edit transaction数,一般的峰值不到10万。

    以下是单节点JournalNode接收数量：

    五个节点JournalNode接收数量：

    综合上述数据，我们可以确定，即使使用journalnode，也能保证我的NameNode的并发性能。