2020年8月13日 |

这几天有个很好的兄弟项目所搭建的阿里云ECS出现了极其诡异的现象,简单分析来看就是,系统会定期屏蔽访问,重启后会短暂恢复,但是很快又会故障依旧,这种问题凭借我Linux运维老鸟的经验来看,第一解决切入口就是进入阿里云后台,查看ECS服务器所在的安全组,是否开放了cPanel所需要的2087 2086 2083等端口,结果发现这些端口一直是开放状态。

然后我想到了局域网的IP可能被阿里云防火墙挡掉的原因,于是建议兄弟重启本地路由器,更换IP,结果还是没解决问题,照旧定期抽风,至此我才感觉到了这个问题的复杂性。

然后我兄弟和我聊起的时候,说他有给ECS购买了付费的云盾,我兄弟对网络安全要求是极高的,因此云盾的安全设定规则也很复杂,我建议他进去一顿关闭,咔咔操作猛如虎,结果却是二百五,问题还是像小强一样,外甥打灯笼–照旧。

到这个时候,我有点开始慌了,凭借我十多年的运维经验,这个现象非常不科学,而且甚至可以说有点“诡异”,我开始有点手足无措了,于是通过阿里云ECS自带的远程SSH登陆工具,登陆到了服务器上,通过命令行输入 service cpanel status 得到如下错误信息:

[root@cpanel ~]# service cpanel status
Redirecting to /bin/systemctl status cpanel.service cpanel.service – cPanel services Loaded: loaded (/etc/systemd/system/cpanel.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2020-08-13 15:00:21 CST; 17min ago Process: 1171 ExecStart=/usr/local/cpanel/scripts/restartsrv_cpsrvd –no-verbose –notconfigured-ok –systemd-service=cpanel (code=exited, status=0/SUCCESS) Main PID: 1399 (code=exited, status=255)

注意到我红色标注的地方一个清晰的 failed 由此可以断定,cPanel服务压根没启动起来,于是我输入 service cpanel start  执行很顺利,没有报错,于是我小小窃喜了一下,重新输入 service cpanel status 的时候,发现 failed  部分变为了绿色 running ,于是我再次测试发现,还是没解决问题,而且再次检测的时候,发现这个成功的标志再次消失,重新变为红色的失败提示。

由此我发现了问题根源依旧没找到,不过已经逐步接近真相了,于是我输入 df -h 发现系统盘20G,所剩无几,这时候我突然意识到,会不会是系统盘空间不够导致了安装在系统盘的cPanel无法启动,或者间歇性的宕机。

这之后多个操作都证明我的判断是正确的,在系统盘上执行任何安装类型的操作,都会提示 no space left on this device ,于是我让兄弟通过阿里云对这块系统盘进行了扩容,从20G扩充到了60G,信心满满的重启了服务器,通过命令行发现服务器压根没识别到这个新的60G空间,于是刚刚升腾起的希望又瞬间跌入谷底,看来阿里云的云盘扩容压根不完善,还要手工去做什么操作,于是提交工单给阿里云客服,慢腾腾的得到了一个扩容教程如下:

yum install cloud-utils-growpart

yum install xfsprogs
resize2fs /dev/vda1

通过以上命令终于成功的将系统盘从20G扩充到了60G,于是,终于看到了曙光,然后输入如下命令:/usr/local/cpanel/scripts/upcp 全新升级了当前cPanel,升级过程很顺利,最终升级完成以后,此次问题也成功的获得了解决。

综上来看,Linux运维是个非常复杂而且充满不确定的过程,因为每次的问题处理可能都会面临新的不确定性,分分钟可能会让你怀疑人生,要想做好Linux运维,除了需要掌握大量的Linux知识以外,更多的是需要进行实战操作,只有在不断的实战中积累大量的一手经验,这样当下次遇到新的问题的时候,不至于茫然不知所措。

学海无涯,掌握某个知识不难,难就难在于掌握一整套解决问题的思路,一旦掌握了这种思路,无论下次遇到的问题有多棘手,总归都能顺利搞定。

特记录此次解决问题的过程,算是抛砖引玉,与大家共勉。