运维开发网

centos6 – 服务器对收到的多播数据包中的Spike没有响应

运维开发网 https://www.qedev.com 2020-05-09 09:56 出处:网络 作者:运维开发网整理
大约一周前我从 UbiquityServers获得了一台服务器,我安装了一个简单的Apache服务器,它只提供图像.服务器的负载非常小,因为它只是亚马逊CloudFront背后的原始服务器,但是昨天它突然变得没有响应SSH,直到我把它关闭/
大约一周前我从 UbiquityServers获得了一台服务器,我安装了一个简单的Apache服务器,它只提供图像.服务器的负载非常小,因为它只是亚马逊CloudFront背后的原始服务器,但是昨天它突然变得没有响应SSH,直到我把它关闭/打开到SSH上.我试图找到导致这个问题的原因. &安培;我很感激社区的任何意见.

以下是一些调查结果.

我注意到接收到的组播数据包在周围时间有一个峰值,这是一个日志:

sar -n DEV -f sa29 | less
08:30:01 PM      eth1     66.96     63.34     19.54     62.51      0.00      0.00      0.05
08:40:01 PM        lo      0.07      0.07      0.01      0.01      0.00      0.00      0.00
08:40:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:40:01 PM      eth1     65.05     70.51      5.63     84.70      0.00      0.00      0.02
08:50:01 PM        lo      0.04      0.04      0.00      0.00      0.00      0.00      0.00
08:50:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:50:01 PM      eth1     57.84     59.48      6.71     67.85      0.00      0.00      0.04
09:00:01 PM        lo      0.03      0.03      0.00      0.00      0.00      0.00      0.00
09:00:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09:00:01 PM      eth1     48.55     47.35      4.30     53.78      0.00      0.00      0.03
09:10:01 PM        lo      0.01      0.01      0.00      0.00      0.00      0.00      0.00
09:10:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09:10:01 PM      eth1     53.16     51.88      5.61     58.48      0.00      0.00      0.02
09:20:01 PM        lo      0.04      0.04      0.00      0.00      0.00      0.00      0.00
09:20:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09:20:01 PM      eth1     61.80     63.91      7.75     73.46      0.00      0.00      0.05
09:30:01 PM        lo      0.03      0.03      0.00      0.00      0.00      0.00      0.00
09:30:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09:30:01 PM      eth1     54.74     55.70      5.79     63.43      0.00      0.00      0.02
09:40:01 PM        lo      0.01      0.01      0.00      0.00      0.00      0.00      0.00
09:40:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09:40:01 PM      eth1     27.83     28.57      3.17     32.59      0.00      0.00 1058754721.47
09:50:01 PM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09:50:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09:50:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00 2142789576.69
10:00:01 PM        lo      0.05      0.05      0.01      0.01      0.00      0.00      0.00
10:00:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:00:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00 2152346090.50
10:10:01 PM        lo      0.01      0.01      0.00      0.00      0.00      0.00      0.00
10:10:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:10:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00 2142038999.87
10:20:01 PM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:20:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:20:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00 2153457524.69
10:30:01 PM        lo      0.01      0.01      0.00      0.00      0.00      0.00      0.00
10:30:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:30:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00 2142646569.12
Average:           lo      0.03      0.03      0.00      0.00      0.00      0.00      0.00
Average:         eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth1     91.61     90.43     21.05     59.33      0.00      0.00 87333330.59

10:42:20 PM       Linux RESTART

10:50:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
11:00:01 PM        lo      0.03      0.03      0.00      0.00      0.00      0.00      0.00
11:00:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:00:01 PM      eth1     31.57     28.14      2.54     30.25      0.00      0.00      0.05
11:10:01 PM        lo      0.11      0.11      0.01      0.01      0.00      0.00      0.00
11:10:01 PM      eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00

服务器正在使用CentOS 6.

我不太确定我应该检查什么.

我只是想为此做出贡献,因为我有完全相同的问题,使用与OP相同的托管公司.我们的服务器会长时间(有时是几小时)没有响应,并且总是与疯狂的传入多播数据包数量相吻合.

我发现我们的服务器不在私有VLAN上,并且正在暴露于“公共”多播和广播流量,特别是流量可能直接指向我们IP地址的先前所有者(Web主机回收那些).我们的IP地址曾经被在线游戏社区使用过,所以请继续使用.

让Ubiquity的人员将我们置于私有VLAN上可以立即解决这个问题,总共需要80美元(一次性费用).当我购买关于此漏洞的专用服务器时,他们本应该警告我,但他们没有.

我对Ubiquity Hosting一无所知,所以我想确保记录很清楚它只是归结为我的IP容易受到UDP流量的影响,而且我的盒子无法处理十亿错误UDP包在如此短的突发中.

希望这有助于某人!

0

精彩评论

暂无评论...
验证码 换一张
取 消