cdh集群linux命令 linux cd

CDH集群-无法找到主机的NTP 服务或该服务未响应时钟偏差请求

问题：

创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都做网站、网站设计、红桥网络推广、重庆小程序开发公司、红桥网络营销、红桥企业策划、红桥品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供红桥建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com

部分主机宕机后，CDH集群启动成功，但是有某些主机提示“无法找到主机的NTP 服务,或该服务未响应时钟偏差请求”

解决步骤：

1.先同步服务器时钟

执行命令：

service ntpd stop  停止ntp服务

ntpdate  主机ip   同步主机时钟

service ntpd start  启动ntp服务

service ntpd status  查看服务启动情况

ntpq -pn  查看同步的服务器IP

ntpstat  查看同步结果

2.在CDH界面停止主机上的角色

3.进入该主机的CDH安装目录执行 ./cloudera-scm-agent restart (即需要在问题主机上重启cloudera-scm-agent服务)

目录在 etc/init.d下

4.等待CDH界面刷新，问题解决，大概等3  5分钟就看不到时钟偏差问题了。

解决思路：

1.同步服务器时钟是为了确定是否是ntp服务本身的问题。

2.发现服务器时钟没有问题，所以不是ntp服务本身的问题。

其中这句话说，如果该命令失败、NTP 未与服务器同步，或主机的 NTP 后台程序未运行或无法联系，该测试将返回运行状况“不良”。

所以可能是CDH集群本身没有接收到时间同步服务器的结果，于是执行重启agent的命令。至此问题解决！

在cdh集群中，hadoop fs -ls / command not found 求教，谢谢

如果最后你的命令，确实列出了相应的目录文件，那么这种情况确实挺少见的，有两种情况：1、你的"/"的文件太多了。2、你的网络或硬件配置太低，这种情况下的可情性不大我的反应情况挺快的，也有可能是你的配置有问题，实在解决不了的话，建议你重布一下，可参考一下我的百度博客中，写了两篇这个内容。

cdh hadoop安装后的启动命令在哪个目录

1.关闭selinux

修改/etc/selinux/config 文件

将SELINUX=enforcing改为SELINUX=disabled

重启机器即可

2.修改bin文件的运行权限，运行bin文件后，进入安装cdh-manager的安装界面

如果直接安装，cdh-manager会去archive.cloudera.com下载安装包，这样会很慢，所以最好在内网搭一个下载源，做个host

echo '192.168.8.XX archive.cloudera.com' /etc/hosts

每一步安装的日志会保存在 /var/log/cloudera-manager-installer/目录

centos 7 安装CDH 5.11

1.配置 Cloudera Manager 仓库(所有节点)

2.安装jdk 1.8（略）

3.安装mysql 5.7（略）

或者yum

这里 不详细说明了

修改集群中各机器的hosts和hostname，并使之永久生效。步骤如下：

输入命令 hostname：查看当前hostname；

输入命令 hostname new.hostname：修改new hostname并立即生效（临时有效，重启系统后失效）

输入命令 vim /etc/hosts：为集群中的各机器添加对应的hosts；

输入命令 vim /etc/sysconfig/network：修改HOSTNAME=new.hostname，使new.hostname永久生效。（如果没有该值则手动添加，并重启确认是否永久生效）

设置集群中的各机器能互相SSH免密登录，并且能够ssh locahost登录本机。步骤如下：

输入命令 ssh-keygen -t rsa，一路回车即可；

输入命令 ssh-copy-id -i .ssh/id_ rsa.pub username@target.machine.ip；

ssh登录各机器进行确认。

可能会有的报错：

/usr/bin/ssh-copy-id: ERROR: Host key verification failed.

因为我输入ssh-copy-id -i .ssh/id_ rsa.pub root@10.1.2.104.master时没有输入yes 直接回车，再次输入yes成功

sudo firewall-cmd --zone=public --add-port=7180/tcp --permanent

sudo firewall-cmd --reload

临时关闭防火墙

systemctl stop firewalld

检查SELinux当前状态：getenforce；

如果输出为Permissive或Disabled，那么就可以不用设置SELinux的模式了。如果输出是enforcing，就接着做下一步；

vim /etc/selinux/config (有些系统里是 /etc/sysconfig/selinux)；

将 SELINUX=enforcing 修改为 SELINUX=permissive，保存并退出；

输入 setenforce 0，使设置立即生效

集群中各机器都要配

解压cloudera-manager-centos7-cm5.11.0_x86_64.tar.gz

cloudera manager的目录默认位置在/opt下

mv cm-5.11.0 /opt/

mv cloudera /opt/

添加mysql 驱动

cd /opt/cloudera/parcel-repo/

复制以下文件到该目录

CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel.sha1

CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel

manifest.json

修改

CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel.sha1为

CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel.sha

各Service所需的库如下图，其中库名和user名可以自定义，但自己必须记住。（建议库名使用图中所示的，user名可以自定义，并且可以相同）

运行

登录：

1 启动报错：

启动server/agent失败，报错pstree: command not found

安装 psmisc

2 我重装了HDFS所以报错

对当前 NameNode 的名称目录进行格式化。如果名称目录不为空，此操作将失败。

删除 /dfs下的nn目录重试即可

3 datanode启动失败报错

将/dfs/nn 和 dn的 VERSION中的clusterIDs改为一致即可

出现该问题的原因：在第一次格式化dfs后，启动并使用了hadoop，后来又重新执行了格式化命令，这时namenode的clusterID会重新生成，而datanode的clusterID 保持不变。

CDH集群假死问题排查之后续

两个月前写过一篇文章，HDFS和Yarn经常出现dataNode和NameNode之间, nodeManager与resourceManager之间 连接不良的现象，开始怀疑是service Monitor监控内存失败的问题，于是更换了JDK版本，当时认为问题解决，然而没过多久，假死和连接不良现象又出现了。重新将nameNode日志阈值改成debug，发现依然存在如下异常：

但网上查了一些资料，也有人说这是CDH版HDFS的一个bug。本身并不影响服务。考虑到CDH本身也将该异常认定为debug级别，觉得是有可能的。个人感觉这个问题除了让日志增长比较快，也就这样了。决定先把这个问题放一放。

由于疫情和工作原因，一直没功夫去看这个问题，一气之下把主节点升到16G内存，惊喜发现部署在主节点的DataNode和nodeManager几乎一直是良好状态，而从节点经常出现问题。

比如这个很可怜，除了主节点之外的nodeManager其余都挂了。

所以现在解决问题的思路无非是

1. 升级从节点的资源配置，和主节点配置保持一致。

2. 通过系统优化和调优解决问题。

本着对技术的探(mei)究(qian)之心，我决定采用第二条方案。

先把服务器上的HDFS nameNode/yarn nodeManager堆栈日志dump下来(因为这两个组件内存占用较大)，看看究竟。发现其中70%的都是不可达对象（也就是图中的灰色部分）。

于是到服务器上去一探究竟。

通过jmap 命令，发现两个现象：

1. 新生代内存比较小，并且频繁进行minor gc，几乎每分钟都有。

2. 老年代内存一直在增长并且没有释放的迹象。

感觉新生代内存过小可能会导致：

1.  频繁的minor gc，很多新生对象没有经过充分gc而进入老年代。（比如新生对象存活时间是五分钟，而频繁的minor gc导致3分钟这个对象就被当成老人放入老年代）

2.  频繁的minor gc，可能导致对cpu资源的争夺或其它未知的原因导致nodeManager或者dataNode不良。

而老年代内存回收过慢则导致系统内存一直处于高位。

于是尝试设置两个参数：

-XX:NewRatio=2 -XX:CMSInitiatingOccupancyFraction=45

第一个XX:NewRatio是指扩大新生代内存的比例，降低minor gc的频率，而第二个则是降低触发老年代full gc内存回收的阈值，使得老年代不至于保存大量已不可达的对象。如果但这个值如果设太低，则又会频繁触发full gc和major gc，所以也不敢设置太低，设成45。

通过设置，HDFS的dataNode连接不良的问题得以解决，但yarn的nodeManager还是频繁出现不良。

继续百度+谷歌，发现JDK1.8有更好的垃圾收集器，G1回收器，感兴趣的同学请移步：

深入理解JVM（5）——GC垃圾回收（3）——8大垃圾收集器

G1回收器比之前用的新生代并行垃圾收集器无论是吞吐量优先(让单位时间内，STW 的时间最短)还是对响应时间优先(尽可能让单次 STW 的时间最短)的处理都比并行垃圾处理器(useParNewGC）优雅不少。

我们可以通过以下参数设置，其中XX:MaxGCPauseMillis为单次最大gc停顿时间。这是一个软目标，G1会尽量保证单次停顿低于该值。

-XX:+UseG1GC -XX:MaxGCPauseMillis=200

设置完之后，集群稳定的一批。跑了一些任务，也没有问题。收工。

最后又是安利追剧时间，今天安利的是精英律师，老干部嘴皮子简直6得不行了，栗娜真的超好看。