关于Oracle RAC调整网卡MTU值的问题

墨墨导读:在Oracle RAC的环境中,如果我们发现OSW监控数据显示包重组失败率过高,就需要引起足够的重视,因为这很可能会引发member kill/Node kill等重大故障,甚至在有些场景会连带影响到所有RAC节点不可用。

一般我们会选择调整ipfrag相关参数。除此之外,还有一种解决方案就是选择调整私网网卡的MTU值,通常Oracle使用8k标准块大小时,会选择设置MTU=9000,从而减缓包重组失败次数的增长速率,期望的理想状态下是完全没有包重组失败的发生。


需要注意的是,修改MTU需要心跳交换机配合做相应的修改和适配,确保使用的交换机能够支持巨帧,所以通常给客户的建议会优先给出方案一,实施方案一效果不理想的情况下才会考虑方案二。

方案一:修改ipfrag相关参数

官方建议一般是修改:

net.ipv4.ipfrag_high_thresh=16Mnet.ipv4.ipfrag_low_thresh=15M

这个修改的官方主要依据是 RHEL 6.6: IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1) ,虽然文档给出的是RHEL6.6,但实际经验是在6.6以后的版本也建议修改,在很多真实案例中,不止局限于6.6这个版本。


另外,如果实际业务量比较大,可以考虑进一步增大这两个值,比如修改为32M/31M甚至64M/63M,一般high和low相差1M即可。


结合公司专家们的实战经验,对ipfrag系列参数给了一个参考,我这里结合网上的资料和RHEL7系统的默认值进行对比:

net.ipv4.ipfrag_high_thresh = 41943040    #分片占用内存的高阈值,默认值4194304net.ipv4.ipfrag_low_thresh = 40894464    #分片占用内存的低阈值,默认值3145728net.ipv4.ipfrag_time = 120          #分片超时时间,默认值30net.ipv4.ipfrag_secret_interval = 600    #默认值600net.ipv4.ipfrag_max_dist = 1024        #分片有效的最长间隔距离,默认值64

这里除了修改ipfrag_high/low_thresh由默认的4M/3M改为40M/39M之外,还将ipfrag_time由默认值的30修改为120,ipfrag_max_dist由默认的64修改为1024。但是这个并没有找到Oracle官方的说明,只是从参数含义的角度来看应该会有所改善。这里先不作为优先修改项。

方案二:使用巨帧,调整MTU值

这个修改的官方主要依据:Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)

当方案一实施后效果不明显时,则考虑调整MTU值,这里选择设置MTU=9000:

修改私有网卡MTU为9000:
ifconfig <网卡名称> mtu 9000查看MTU是否更改成功:ifconfig <网卡名称>
修改私有网卡配置文件,添加MTU=9000的配置,以确保主机重启后MTU=9000不变:vi /etc/sysconfig/network-scripts/ifcfg-<网卡名称>配置文件末尾新添加一行MTU=9000的配置:MTU=9000

在实际测试验证中发现,节点1主机重启后无法启动ASM实例,alert明确报错MTU远端是1500,即使远端ifconfig临时修改MTU=9000也不行,这个结果还是很意外的,之前没想到这个mtu的修改居然不能实现完全滚动,也就是说停机是不可避免的(ifconfig可以动态修改mtu,但是如果rac想用上mtu=9000的话需要重启)。

--节点1主机重启后无法启动ASM实例,alert明确报错MTU远端是1500,即使远端已经临时修改过MTU=9000:
2020-07-03T17:15:52.602414+08:00Errors in file /oracle/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_lmon_12878.trc:ORA-27300: OS system dependent operation:config_check failed with status: 0ORA-27301: OS failure message: Error 0ORA-27302: failure occurred at: skgxpvalpidORA-27303: additional information: Remote port MTU does not match local MTU. [local: 9000, remote: 1500] (169.254.1.60)

在MOS 947223.1文档中也有说明:After correct MTU issue, a node reboot is required to bring up CRS stack and ASM instance for 11.2 release.


如何判定包重组失败的现象是否存在风险?

上面讲了半天的包重组失败,那该如何判定当前系统包重组失败是否存在风险?当然理想环境下,不应该出现包重组失败的现象,但如果环境不够理想,那有没有一个参考值,多长时间内包重组失败超过多少次就会有问题?或者有其他的判定标准?


目前了解到的是对于Oracle RAC,对包重组失败速率并没有一个统一的标准来定义正常/不正常的临界值:
为此客户也开过SR求证,O原厂回复也是说没有一定的标准,只是基于数据库性能和稳定性方面建议是减少内网包重组现象。

我也咨询了专家罗海雄老师,认为一般30s内包重组失败超过5个就需要给予一定的关注,持续观察是否存在风险,并给出下面的awk命令来辅助观察osw的netstat数据:

awk '/zzz/{d=$4"-"$5}/packet reassembles failed/{curr=$1;diff=curr-prev;if(diff>5)print d,diff,prev,curr;prev=curr}' *.dat

根据上述语句分析了10余套系统,唯有出现过问题的这套环境依然存在风险,下一步计划修改MTU值后再观察。

此外,O原厂建议增加OSW私网的监控,但需要注意增加这个监控后,不止多了oswprvtnet等监控数据,之前netstat监控数据的格式也会发生变化,会详细列出每个网卡的监控信息,但格式变化后的连带影响就是上面awk脚本不再可用了,观察新的数据格式,改写脚本如下:

awk '/zzz/{d=$4"-"$5}/IpReasmFails/{curr=$2;diff=curr-prev;if(diff>5)print d,diff,prev,curr;prev=curr}' *.dat

最后要提一下的是,当出现这类问题时,还要配合检查私网本身是否存在问题,比如:网卡、网线、交换机等,都要确保状态正常,排除硬件本身的问题。

墨天轮原文链接:https://www.modb.pro/db/28633(复制到浏览器中打开或者点击“阅读原文”)

推荐阅读:144页!分享珍藏已久的数据库技术年刊


视频号,新的分享时代,关注我们,看看有什么新发现?

数据和云

ID:OraNews

如有收获,请划至底部,点击“在看”,谢谢!

点击下图查看更多 ↓

云和恩墨大讲堂 | 一个分享交流的地方

长按,识别二维码,加入万人交流社群

请备注:云和恩墨大讲堂

  点个“在看”

你的喜欢会被看到❤

你可能感兴趣的:(关于Oracle RAC调整网卡MTU值的问题)