2024年7月

一哥们早上发来一段消息

故障详细信息 - 硬盘检查:故障 ID:QE7T6M-A27C6M-MFPU21-61X003测试日期:2024-07-31已测试的组件:硬盘检查重大:测试发现硬盘有问题,可能需要更换。如果可能,请尽快将您的个人文件备份到闪存驱动器或外部硬盘驱动器。

硬盘检测的样子
2024-07-31T01:42:56.png

蓝屏的样子
2024-07-31T01:45:52.png

尝试修复蓝屏,无果。
2024-07-31T01:49:47.png

初步判断是硬盘问题,转而一想,可能是夏天天气热,而nvme散热量又大,所以导致蓝屏。

可以尝试更改为sata ssd,但是该型号貌似不支持。
2024-07-31T01:50:34.png
2024-07-31T01:50:42.png

后来,大家也发表了一些看法

后来,哥们说一上午通过风扇外置散热的方式没有再出现蓝屏。基本定位是硬盘硬件问题。再观察观察。另外,通过型号找到了hp官方的驱动更新程序,下次再蓝屏可以试试看https://support.hp.com/cn-zh/drivers/hp-zhan-66-pro-14-g3-notebook-pc/29428893。直接下载地址https://d2.sddts.cn/download/hp/驱动。

业务越来越多,资源有点不够用了,而且最近还出现了因资源不足导致虚拟机工作异常,进而出现集群不稳定的问题,给日常的工作和摸鱼带来了很大的困扰。

升级。

手头有4根32GB内存条,有一根有问题,这次只更新3根。手头还有4片NVME256GB,但是工作站还剩余2槽PCI 16,也就升级2个吧。
2024-07-30T03:53:10.png

(1)关机
打开proxmox,分别针对虚拟机进行shutodwn -h now。然后把proxmox也关闭。

(2)物理硬件更换
2024-07-30T03:53:22.png
(3)长ping判断机器启动
2024-07-30T03:53:36.png
(4)打开proxmox页面,开启虚拟机

(5)参考手册,根据没有启动的服务进行一一点射
2024-07-30T03:54:00.png

收摊野餐~

平台分布式文件存储采用的是国内成熟的fdfs软件实现,由于物联网设备升级依赖http协议,所以在返回的升级文件协议中默认是http,不能是https。但是,时间到了2024年7月,https早已是成熟的技术并得到普遍的应用,而且微信小程序必须使用https以及域名验证才能获得webview打开下载。

这可如何是好。

本来架构就复杂,后端fdfs,前端nginx负载,为了方便apk分发,将一个一个apk采用 location的形式跳转到123pan,但是123pan无法实现文件验证。
想来想去,之前的域名是file,123pan使用的域名是filecdn,干脆使用file3固定在华为云来实现吧。

没想到,整个过程还真不难。华为云OBS新建一个桶,权限是全局读,开启域名加速也就实现了CDN功能。下载一个试试,还能跑到45Mbps左右。效果还不错呢。

周一一大早,有一条告警,提示kubesphere的vip地址的6443端口无法通信。经排查,原来是办公区有节点拿走了vip地址201的地址。这下导致发布也报错了。

2024-07-29T02:02:02.png

紧急处理:

在发布机器里
arp -s 192.168.124.201 00:16:3e:16:fe:90

并且在dhcp分配里,静态分配地址192.168.124.201。

2024-07-29T02:02:54.png

其实,这个地方的mac地址是假的。因为mac地址00:16:3e:16:fe:90已经分配给了vip所在的云主机了,而dhcp不允许一个mac地址有两个ip地址对应。

总结一下,当把服务器放在办公网的IP段后,就牵扯到一个管理的问题了,避免地址冲突是很重要的一项工作。

新加坡服务器94.74.82.232访问山东移动济宁120.224.58.239存在网络异常问题,主要表现在时断时续。
2024-07-26T05:23:39.png
2024-07-26T05:33:14.png
2024-07-26T05:27:19.png
经过遥测发现,服务器到120.224.58.1网关一直正常。
2024-07-26T05:31:58.png
在异常过程中,做了路由追踪图如下。
2024-07-26T05:24:31.png
2024-07-26T05:24:35.png

文字版如下:

[root@ecs-b125 ~]# traceroute -w 1 -d -n 120.224.58.239 -n | nali
traceroute to 120.224.58.239 [山东省 移动]  (120.224.58.239 [山东省 移动] ), 30 hops max, 60 byte packets
 1  10.22.135.97 [局域网 IP]   3.072 ms  3.306 ms  3.969 ms
 2  11.22.25.20 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.297 ms 11.22.25.22 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.611 ms 11.22.25.20 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.136 ms
 3  11.22.80.156 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.549 ms  4.405 ms 11.22.80.144 [美国俄亥俄州哥伦布市 DoD网络信息中心]   8.382 ms
 4  11.22.80.22 [美国俄亥俄州哥伦布市 DoD网络信息中心]   3.439 ms 11.22.80.141 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.211 ms 11.22.80.18 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.404 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  11.22.97.55 [美国俄亥俄州哥伦布市 DoD网络信息中心]   1.547 ms * 11.22.97.57 [美国俄亥俄州哥伦布市 DoD网络信息中心]   1.102 ms
11  * * *
12  * * *
13  172.16.12.50 [局域网 对方和您在同一内部网]   34.897 ms 172.16.12.42 [局域网 对方和您在同一内部网]   36.166 ms 172.16.12.50 [局域网 对方和您在同一内部网]   34.878 ms
14  223.119.19.217 [香港 中国移动国际有限公司]   38.252 ms 223.119.19.221 [香港 中国移动国际有限公司]   41.198 ms 223.119.19.217 [香港 中国移动国际有限公司]   39.004 ms
15  223.120.3.89 [中国 移动]   37.124 ms 223.120.3.178 [中国 移动]   59.656 ms 223.120.3.182 [中国 移动]   78.404 ms
16  221.183.89.170 [广东省广州市 移动骨干网]   63.791 ms  62.432 ms  64.021 ms
17  * * 221.183.89.182 [广东省广州市 移动骨干网]   62.458 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@ecs-b125 ~]# traceroute -w 1 -d -n 120.224.58.1 -n | nali
traceroute to 120.224.58.1 [山东省 移动]  (120.224.58.1 [山东省 移动] ), 30 hops max, 60 byte packets
 1  10.22.135.65 [局域网 IP]   377.736 ms 10.22.135.97 [局域网 IP]   2.111 ms  5.245 ms
 2  11.22.25.20 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.874 ms 11.22.25.22 [美国俄亥俄州哥伦布市 DoD网络信息中心]   6.613 ms 11.22.25.16 [美国俄亥俄州哥伦布市 DoD网络信息中心]   6.252 ms
 3  11.22.80.144 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.222 ms 11.22.80.146 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.187 ms 11.22.80.158 [美国俄亥俄州哥伦布市 DoD网络信息中心]   8.164 ms
 4  11.22.80.24 [美国俄亥俄州哥伦布市 DoD网络信息中心]   5.150 ms 11.22.80.18 [美国俄亥俄州哥伦布市 DoD网络信息中心]   4.978 ms  5.103 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * 11.22.97.61 [美国俄亥俄州哥伦布市 DoD网络信息中心]   1.417 ms *
11  * * *
12  * * *
13  172.16.12.50 [局域网 对方和您在同一内部网]   34.949 ms * 172.16.12.46 [局域网 对方和您在同一内部网]   39.795 ms
14  223.119.19.221 [香港 中国移动国际有限公司]   36.168 ms  40.160 ms 223.119.19.217 [香港 中国移动国际有限公司]   36.256 ms
15  223.120.3.89 [中国 移动]   35.585 ms  33.026 ms  35.657 ms
16  221.183.89.174 [广东省广州市 移动骨干网]   59.611 ms  62.659 ms 221.183.89.170 [广东省广州市 移动骨干网]   62.967 ms
17  221.183.89.178 [广东省广州市 移动骨干网]   63.071 ms 221.183.89.33 [广东省广州市 移动骨干网]   59.152 ms *
18  * 221.183.89.14 [广东省广州市 移动骨干网]   66.073 ms 221.183.89.46 [广东省广州市 移动骨干网]   74.578 ms
19  221.183.89.14 [广东省广州市 移动骨干网]   66.112 ms 221.183.136.157 [广东省广州市 移动骨干网]   78.909 ms  81.533 ms
20  221.183.40.82 [广东省广州市 移动骨干网]   87.655 ms 221.183.143.18 [广东省广州市 移动骨干网]   84.349 ms *
21  221.183.143.18 [广东省广州市 移动骨干网]   84.528 ms  84.879 ms *
22  120.222.48.142 [山东省 移动]   94.940 ms * 120.222.48.138 [山东省 移动]   104.946 ms
23  120.224.58.1 [山东省 移动]   90.051 ms  89.346 ms  89.011 ms
[root@ecs-b125 ~]#  

联系了移动技术员,没有回消息,想着这问题可能也不归他们管。尝试打了10086,可是需要手机号以及服务密码,可是我没有哦。然后就搜索了一下,找到了10080,一打感觉像是个投诉电话,赶忙解释,只是想优化一下网络,但是不知道找谁。对方也不错,耐心听取,然后说转接一个电话。电话转接后,客服记录了下问题以及我的电话,说稍后有人联系。大概过了一会儿,有一个本地的电话打来了,详细了解了一下问题现象。对方以为是我们访问国外网站不行,我做了解释,是我们面向东南亚客户在华为云购买了云服务器,但是与我们办公出口的公网地址通信有丢包或者中断,但是呢,从办公区访问那边确可以,而且根据遥测数据显示,从新加坡到我们办公网出口的网关之间是没有任何丢包的。对方表示去查一下。

是否最近遇到如下情况:

npm i 报错:request to https://registry.npm.taobao.org/@sxzz%2fpopperjs-es failed, reason: certificate has expired

参考:https://blog.csdn.net/ganyingxie123456/article/details/135850728

可以尝试如下:

cd /opt
wget https://nodejs.org/dist/v14.21.3/node-v14.21.3-linux-x64.tar.gz
tar xvf node-v14.21.3-linux-x64.tar.gz
ln -s /opt/node-v14.21.3-linux-x64/bin/node /bin/node
ln -s /opt/node-v14.21.3-linux-x64/bin/npm /bin/npm
node -v
npm -v

# 配置国内更新源
npm config set registry https://registry.npmmirror.com
npm config set strict-ssl false 

从intel切换到arm架构国产化后,突然发现cpu使用率很高。
2024-07-25T09:21:07.png

如上图所示,一个python程序使用了24个核,而该虚拟机有32个核。另外,负载35说明当前机器压力稍微有点大。好在cpu sys以及内存压力还好。

还在纳闷,为啥以前在intel上面没有这种情况呢。

大概分析,arm的cpu主频往往要低一些,所以运算速度没有那么快。如果该程序支持多线程,可以考虑给该机器增加cpu核数。

哥们发来两个链接,一个微信公众号和一个B站视频链接,希望可以下载。

对于B站视频链接,可以通过bbdown进行下载。
对于微信公众号,可以使用手机QQ浏览器,然后小窗后直接下载。

业务使用华为云,牵扯到北京和新加坡节点,而北京也承担了监控系统的重任。最近三天,时常网络中断,导致新加坡云主机上报categraf信息到北京节点失败,告警不断。昨天整理了相关信息,今天提了华为云工单。
2024-07-24T09:19:05.png

对方也有排查流程,主要是

mtr x.x.x.x --report

拿到信息后,对方排查了几个回合,定位到当前北京和新加坡节点均有EIP流量超量告警。

果不其然,也没有收到过邮件告警,但是确实是有。

2024-07-24T08:02:17.png

处理了一下过多的流量之后,近一个小时已经没有了告警。但是问题依旧存在。

2024-07-24T08:02:49.png

于是,再次反馈工单。并且,尝试使用一些拨测平台进行测试,发现全球访问均正常,只是部分地址访问异常。
2024-07-24T08:03:26.png
2024-07-24T08:03:29.png

提交两张图片之后,怀疑是华为云或者其他机构在网络中的安全设备影响。对方再次核查中。

简单梳理一下,在流量超量之后,会造成网络访问丢包、卡顿,但是不会是中断,比如如下情况:
2024-07-24T08:04:42.png

当天晚上,接到华为云的电话,大概分析了一下,对方也承认可能并不是因为超限造成,而且也联系了运营商进行优化。但是,问题依旧。考虑到晚上了,等明天再说吧。

第二天,对方说观测到还是有丢包。索性直接将流量带宽提升到100Mbps,这下没有丢包了。对方也不再说什么,继续排查。

与此同时,通过traceroute进行正反测试,包括正常情况与异常情况。

补充材料,从bj ping sg的190.92.221.0/24,.25是不通的,但是24和26是通的。
2024-07-25T08:53:36.png
2024-07-25T08:53:39.png

目前看,sg到bj 走的是联通骨干,但是到联通海淀可能有问题;bj到sg走的是电信,福建电信到电信骨干没问题,但是出海就有问题了。详情见如下四图。
2024-07-25T08:53:54.png
2024-07-25T08:53:58.png
2024-07-25T08:54:03.png
2024-07-25T08:54:06.png

稍后,对方又说已经联系了运营商进行了调整。可是,问题依旧。
2024-07-25T08:54:41.png
2024-07-25T08:54:37.png

17:00左右,云计算那边应该是被工单搞的不行了,毕竟24小时没有解决。对方打来电话,说了一下进展,对方将该IP地址出口从国际链路与电信链路之间进行切换,都是好一会儿然后就异常,还是无法正常使用。无奈,只能将问题归咎于国墙了。

然后就是扫尾工作。
(1)从华为云上购买一枚新的EIP地址,解绑老地址,绑定新地址。收到告警,新加坡主机监控上线。
(2)打开阿里云,针对每个域名搜索190地址,将解析改成新地址。
(3)修改监控系统nagios,通过sed批量修改成新地址并重启。
(4)修改堡垒机中关于该服务器的地址。

检查:

(1)nagios监控正常。
(2)夜莺监控中该主机监控数据恢复正常。

事毕。

不出意外还是出意外了。没有经过检验的结果是靠不住的。过了一小会儿,问题又出现了。
经过之前的反复排查,大胆的做了一个测试,将北京云主机的服务端口17000挂到了该区域的ELB上面,没想到通了,而且状态稳定。
2024-07-26T00:50:36.png

另外,也做了一个从新加坡云主机到UCloud云ULB的长ping,没想到一晚上一个丢包也没有。

2024-07-26T00:50:10.png

而从华为云新加坡到华为云北京四的ecs的eip,确实不通,或者时断时续。

26号一大早,提了工单,可是测试sg到ecs的eip居然没有问题了?搞的工单里面赶紧跟人说目前良好,无法复现。稍后,华为云电话也打来了,希望可以开会讨论。可是,我说目前现象已不能复现,等等再看吧。于是,关闭了工单。

就这样,过了一会儿之后,看着绿色的连通性能,心中在想到底是咋回事儿呢?
2024-07-26T02:53:48.png

于是,分别在sg和bj的ecs里面进行路由追踪,看下图:
2024-07-26T02:54:15.png
2024-07-26T02:54:18.png
2024-07-26T02:54:21.png

居然改到联通了!!!

之前,sg到bj之间走的是电信线路,现在走的是联通线路。

用户发来消息,说从云主机访问DZZW外网有的通,有的不通。

经过与管理员了解情况,一般DZZW外网的地址是不能够直接访问,如果要访问,要么网络通,要么通过网闸。而用户直接访问的地址3个里面有2个通,有1个不通,这是啥问题来。

用户不让登录查看,那就麻烦其输出一下主机路由查看吧。

2024-07-24T07:56:20.png

通过以上信息分析,该云主机有两张网卡,ens192是云主机地址,而另外一张网卡是DZZW地址,而且还多了两条路由。

然后,同事可以接着进行排查了。