十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
问题:
创新互联专注为客户提供全方位的互联网综合服务,包含不限于成都做网站、网站设计、红桥网络推广、重庆小程序开发公司、红桥网络营销、红桥企业策划、红桥品牌公关、搜索引擎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的命令。至此问题解决!
如果最后你的命令,确实列出了相应的目录文件,那么这种情况确实挺少见的,有两种情况:1、你的"/"的文件太多了。2、你的网络或硬件配置太低,这种情况下的可情性不大我的反应情况挺快的,也有可能是你的配置有问题,实在解决不了的话,建议你重布一下,可参考一下我的百度博客中,写了两篇这个内容。
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/目录
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 保持不变。
两个月前写过一篇文章,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得不行了,栗娜真的超好看。