背景:
小项目用到的服务器老旧,其中一台周末因为总线等硬件原因挂掉了,各种监控报警,运维尝试恢复失败后直接建议更新设备,于是需要服务迁移和恢复。
其中ZooKeeper&Flink&Hadoop集群因为单节点连接失败也开始罢工了。
组里的架构加运维大牛走了,小白尝试恢复集群服务。所以本文只涉及简单的服务恢复和报错处理。
Tips:要学会利用日志、日志、日志排查问题。
一、ZooKeeper
最初尝试恢复的实际是Flink,恢复失败后发现其日志中关于zooKeeper的报错(如下),于是又恢复zookeeper。项目用到的Kafka同样依赖zookeeper,恢复zookeeper后kafka服务自动恢复。
2021-01-11 14:42:40,259 INFO org.apache.flink.shaded.zookeeper.org.apache.zookeeper.ClientCnxn - Opening socket connection to server 10.*.*.*/10.*.*.*:2181
2021-01-11 14:43:00,281 INFO org.apache.flink.shaded.zookeeper.org.apache.zookeeper.ClientCnxn - Client session timed out, have not heard from server in 20266ms for sessionid 0x0, closing socket connection and attempting reconnect
恢复方法:
1. 登录正常的集群服务器,进入zookeeper的服务路径,查看配置文件:
cd /data1/apache-zookeeper-3.5.6-bin
vim conf/zoo.cfg
2. 去掉失效节点的配置
server.1=server132:2888:3888
server.2=server138:2888:3888
server.3=server137:2888:3888
server.4=server166:2888:3888
例如上面原配置中的server.3失效了,删除原server.3,把原server.4改成server.3。
3. 重启服务
./bin/zkServer.sh restart
在配置文件中涉及的每台集群机器上重复以上步骤。
通过日志查看重启是否成功:tail -f logs/zookeeper-root-server-server138.out
4. 错误警告:
在server166的服务器上,因为其id从4变为3,在重启之后会报错:
java.lang.RuntimeException: My id 4 not in the peer list
原因是:配置文件zoo.cfg中的server顺序id与 vim /data1/apache-zookeeper-3.5.6-bin/tmp/myid 中的id不一致。
即配置变更中涉及到id变更的服务器,需要修改myid使其跟配置文件中一致,然后再重启就可以了。
二、Flink
恢复方法:
1. 登录集群的正常的服务器,查看配置文件确认Flink的主从配置。
vim /data1/flink-1.10.1/conf/master
vim /data1/flink-1.10.1/conf/slaves
master配置中是IP端口号,slaves配置中就是IP列表
2. 更新配置文件,把失效节点去掉
3. 在master服务器上执行服务重启
cd /data1/flink-1.10.1
./bin/start-cluster.sh
在集群各台服务器上通过jps命令(TaskManagerRunner等各进程是否正常启动)或日志查看服务的重启情况(例如:tail -f log/flink-root-taskexecutor-1549-server138.log)。
4. 错误预警
启动的shell脚本是通过ssh远程连接其他master或slave机器进行控制的,所以执行命令的机器公钥需要放到被连接的机器的公钥授权文件中。否则会报错:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
操作步骤:
在执行机器通过: cat ~/.ssh/id_rsa.pub or cat /root/.ssh/id_rsa.pub 获取公钥
在被连接机器上编辑:vim ~/.ssh/authorized_keys 添加公钥
三、Hadoop
恢复步骤:
1. 登录集群机器,修改配置文件
cd /data1/hadoop/etc/hadoop
vim core-site.xml
vim hdfs-site.xml
vim yarn-site.xml
vim workers
涉及节点配置的配置文件有4个,在每台集群机器上都同步修改。
2. 重启
在其中一台服务器上执行即可。
cd /data1/hadoop
./sbin/start-all.sh
#单独启动nodemanager:
./sbin/yarn-daemons.sh start nodemanager
同样,可通过jps或日志(tail -f logs/hadoop-root-nodemanager-server138.log )确认重启的情况。
3. 错误预警
项目中Hadoop中用到了两台服务器,在server1中执行重启命令后,nodemanager启动15分钟后就又自动关闭了,报错信息如下:
org.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl: Unexpected error starting NodeStatusUpdater
org.apache.hadoop.yarn.exceptions.YarnRuntimeException: java.net.ConnectException: Call From server138/10.13.1.138 to server132:8031
在网上查到的信息大多是:
yarn.resourcemanager.resource-tracker.address的默认端口,yarn-site中没有配置这个的地址,结果连接到本地的8031端口等,需要修改配置文件等。
如:https://www.cnblogs.com/zwgblog/p/6071603.html
实际还有一种情况,即被连接机器的服务有问题,如log中的server132(日志中显然尝试连接的并不是本地)
且两台服务器通过 netstat -ntual |grep 8031 查看端口,根本就没启动。
到server132上查看Hadoop日志,发现是这台服务器的/data1/磁盘空间不够了。
2021-01-13 15:07:39,575 WARN org.apache.hadoop.yarn.server.nodemanager.DirectoryCollection: Directory /data1/hadoop/data/nm-local-dir error, used space above threshold of 90.0%, removing from list of valid directories
2021-01-13 15:07:39,575 WARN org.apache.hadoop.yarn.server.nodemanager.DirectoryCollection: Directory /data1/hadoop/logs/userlogs error, used space above threshold of 90.0%, removing from list of valid directories
2021-01-13 15:21:49,947 ERROR org.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl: Unexpected error starting NodeStatusUpdater