一次扩容引发的ARP Cache问题

当某个EMR客户进行扩容时,机器接近上千台时,造成了网络通信问题,甚至有机器ping自己都平不通的情况。根据提示,原因是对于大集群来说,默认的centos arp cache配置不适合,需要调整相关参数。
现象是在给一个大客户进行扩容的时候,当机器接近千台的时候,NameNode主节点突然间通信变慢,请求堆积,最后zkfc直接将NameNode进行了failover了,另一台NameNode也是不定期的failover。
查看dmesg,发现了大量的异常日志:

[76391312.109413] net_ratelimit: 97 callbacks suppressed
[76391319.885189] net_ratelimit: 37 callbacks suppressed
[76391325.104167] net_ratelimit: 62 callbacks suppressed
[76391330.508496] net_ratelimit: 60 callbacks suppressed
[76391335.694525] net_ratelimit: 50 callbacks suppressed
[76391343.815606] net_ratelimit: 108 callbacks suppressed

dmesg报错

 

另外,NameNode的gmond metrics 收集也一直报错,无法发送metrics。对于gmond的metrics发送,其实对网络压力很小,如果依然无法发送,说明网络出现了较严重问题。
经过跟其他部门、兄弟团队合作,发现了是由于ARP Cache overflow造成的问题,从而严重的影响了网络性能。
ARP Cache的作用为,ARP表存储了IP地址和MAC地址的映射关系,ARP Cache有以下几个参数:
net.ipv4.neigh.default.gc_thresh1 ARP表小于该数值的时候不做垃圾回收
net.ipv4.neigh.default.gc_thresh2 ARP表大于该数值时,5s内进行垃圾回收
net.ipv4.neigh.default.gc_thresh3 ARP表的最大限额

再从我们系统中取得默认值发现:
net.ipv4.neigh.default.gc_thresh1 = 128
net.ipv4.neigh.default.gc_thresh2 = 512
net.ipv4.neigh.default.gc_thresh3 = 1024

默认配置偏小,导致了集群机器超过1000台后,网络丢包,不稳定现象,修改相关配置。

追加 /etc/sysctl.conf
net.ipv4.neigh.default.gc_thresh1 = 512
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 10240
net.nf_conntrack_max = 524288

sysctl -p 更新配置

Linux 各种包download only

一、pip download

pip donwload package

二、yum downloadonly

首先安装包downloadonly包

yum install yum-plugin-downloadonly

使用方法:

yum install --downloadonly --downloaddir=<directory> <package>

kipmi0 导致cpu 100%问题

    最近在做测试的时候,观察ganglia发现几台机器即使没有任务的时候load值依然不低,到机器上top后发现kipmi0这个进程一直占满一个核,非常恶心。google了一下,下面是kipmi0的一些说明:

The kipmi0 process may show increased CPU utilization in Linux. The utilization may increase up to 100% when the IPMI (Intelligent Platform Management Interface) device, such as a BMC (Baseboard Management Controller) or IMM (Integrated Management Controller) is busy or non-responsive.

Fix

No fix required. You should ignore increased CPU utilization as it has no impact on actual system performance.

看着不顺眼的简单处理就是

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us
更新:
问了下公司的ops,解决方法为,请各位自己评估:

这个问题最近我们也有遇到,在高版本的redhat/centos系统中(比如6.4/6.5),Redhat官网也有说明,是由于操作系统的驱动与BMC交互出现了问题,导致kipmi0进程占用CPU 100%,并且ipmitool操作无响应。

In this case, there is a problem in the interaction between the driver and the hardware/firmware which leads the driver to believe that an operation is still in progress, causing the high CPU load to continue until the system is rebooted.

kipmi0进程优先级是非常低的,当有系统应用需要CPU资源时,kipmi0会释放资源。

 

对于目前的情况,临时措施可以尝试使用命令hot plug驱动来恢复:

echo “remove,” > /sys/modules/ipmi_si/parameters/hotmod

echo “add,” > /sys/modules/ipmi_si/parameters/hotmod.

 

最终解决方案:本次提供的firmware中加入了相应的解决方案,升级后可以解决。ps:需要先恢复后才可以升级。https://access.redhat.com/solutions/21322

logrotate问题

     今天为vps配置反攻击策略,将所有登陆信息扫描,凡是通过密码一天登陆超过5次的直接拒绝访问。最后使用了logrotate工具,详细信息可以参加man logrotate。说一下我遇到的问题,配置好rotate的日志后,logrotate -f -d -v …..conf 后,发现日志都是正确的,但是并没有rotate,折腾了快半个小时,才发现这是debug模式,去掉-d就可以了。

VIP配置方法

    通过系统管理员找到一个VIP地址,添加虚拟网卡命令:ifconfig eth0:0 10.210.225.31 up

    关闭虚拟网卡命令 ifconfig eth0:0 down 

SOCAT使用说明

一、SOCAT说明

 

    SOCAT类似于NC,它内部命令比较复杂,需要的时候可以man看一下,主要用于两个流之间的连接。我们主要用它的TCP转发。

 

二、使用说明 

    测试环境为虚拟机,ns1的nn1为10.210.225.30,将10.210.225.35的50070端口全部转发到10.210.225.30:50070。

    nohup socat TCP-LISTEN:50070,fork TCP:10.210.225.30:50070  &Socat1

    这样访问10.210.225.30:50070就可以通过10.210.225.35:50070来进行。

    这样的意义是对hadoop get结果的操作不用落地一次,直接下载到客户前端机。