1.迁移JournalNode节点
当你在HDFS服务中新加入一个JournalNode角色时，JournalNode角色需要的数据目录是没有被创建的。
但你启用HDFS的HA后，NameNode必须需要JournalNodes都是正常的，并且可以接受edits更新，所以JN如果有问题，会直接导致NN起不来。
无论你是新装JournalNode还是迁移JournalNode角色，JN的edits目录必须格式化。
格式化后会有namespace目录，并且目录里会包含正确信息的其他文件。
2.1.新装JournalNode
1.通过Cloudera Manager进入JournalNode服务，确认JN的edits目录配置，比如：
/dfs/jn
（可左右滑动）
2.登录到那台JN，备份一下旧的jn目录（如果存在）。
sudo mv /dfs/jn /dfs/jn.backup
（可左右滑动）
3.通过Cloudera Manager进入NameNode的实例界面，最好是上次那个active的NameNode。
4.执行“初始化共享Edits目录”---NameNode节点-操作
注意：你必须停止NameNode服务才能执行这个服务。
5.格式化JN的edits成功后，再重新启动HDFS服务。
2.2.迁移JournalNode服务
1.确认JournalNode的edits目录的位置，参数名叫dfs.journalnode.edits.dir。使用Cloudera Manager查看HDFS配置中的JournalNode可以查看该参数的配置值，如果你没有使用Cloudera Manager，则该参数一般会在hdfs-site.xml文件中。比如：
/dfs/jn
（可左右滑动）
2.登录到旧的JN节点，备份JN的edit目录，如下：
cd /dfs/jn sudo
tar czvf /tmp/jn_edits.tgz *
（可左右滑动）
3.拷贝jn_edits.tgz到新的JN节点
4.进入新的JN节点的edits目录，并解压edits文件
cd /dfs/jn
sudo tar xzvf /tmp/jn_edits.tgz
（可左右滑动）
5.确认一下解压后文件夹，子文件夹的用户和属组，包含权限正确。
6.重启JN服务。
3.异常总结
1.请注意JN节点必须是奇数个，无论是2.1的操作还是2.2的操作，保证在所有新的JN节点上都进行了同样的操作。
2.如果你是重新启用HA，请保证之前JN节点上的旧的目录已经被你清空干净了，然后再开始重新启用HA。
2.Service Monitor超时解决
1.CDH运行一段时间就提示：请求 Service Monitor 超时。这可能会导致页面响应缓慢。请查看 Service Monitor 的状态
1）调整monitor服务的jvm配置（ps -ef jmap -heap pid） ps -ef | grep -i service_monitor/host_monitor
2）检测主机时间是否同步
3）检测主机cloudera-cmf-agent是否正常运行
4）句柄：ulimit -n
5）跟踪日志，分析原因
netstat -nat|grep ESTABLISHED|wc -l
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
netstat -nat|grep -i "80"|wc -l
ps -ef|grep httpd|wc -l
ps aux|grep httpd|wc -l
如发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决，
vim /etc/sysctl.conf
编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。
net.ipv4.tcp_syncookies = 1 表示开启SYN cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间