Oracle RAC最佳实践-优化私网连接

在 Oracle RAC 环境中，私网（Interconnect） 是节点之间通信和数据传输的关键部分。一直有个误解，认为私网（心跳网）只要能通随便什么交换机都可以,甚至有直连的，实际上私网的性能至关重要，应该用公司里性能最好的交换机；私网连接性能直接影响集群的整体效率，尤其是在全局缓存（GC，Global Cache）操作中，如果通信延迟或带宽不足，会导致等待事件增多，进而影响数据库性能。在ORACLE RAC最佳实践中 私网络建议配置 Jumbo Frame（也就是设置网卡的 MTU 为 9000，默认为1500），可以极大的减少心跳网络上的包重组。Jumbo Frame 可以非常有效地解决很多 RAC 上的 ORA-600/ORA-7445/性能问题/节点驱逐问题。比如： 常见的“节点不断因心跳中断被驱逐的问题” 和某些 “ORA-600 [kjctr_pbmsg:badbmsg2] 的问题”。

为什么要配置Jumbo Frame：

以太网是集群互联（Cluster Interconnect）中广泛使用的网络技术。以太网的可变帧大小范围为46-1500 字节，这是主机、交换机等所有以太网参与者之间的传输单元。在这种情况下，1500 字节的上限被称为MTU（Maximum Transmission Unit，最大传输单元）。当一个应用程序发送的消息大于1500 字节（MTU） 时，这些消息会被分段为1500 字节或更小的帧，在端点之间进行传输。在 Oracle RAC 中，DB_BLOCK_SIZE（一般8K） 乘以db_file_multiblock_read_count（默认128）的设置决定了全局缓存（Global Cache）消息的最大大小，而PARALLEL_EXECUTION_MESSAGE_SIZE（默认16384） 决定了并行查询（Parallel Query）中消息的最大大小。这些消息的大小可以从2K 到64K 或更大。因此，在使用较低或默认的 MTU 值时，消息会被分段得更加频繁，碎片化更严重，消息重组消耗更多的时间，从而带来RAC性能问题。

1. 在负载较高时，或者实例重启时，私网流量会很大。

2. 增大MTU减少包重组可以显著提升RAC的稳定性。

3. OSWatcher 的 netstat log 中显示 packet reassembles failed 指标增加，就可以考虑配置 Jumbo Frame 了。

1. 如何通过 Jumbo Frame 优化私网

Jumbo Frame 是指支持超过标准 MTU（1500 字节）的网络数据包，通常设置为9000 字节。 

(1) 修改网卡 MTU 为 9000

在 Linux 系统中，临时修改私网eth1的 MTU 的命令如下：

 [root@dbt01 ~]# ip link show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether fe:fc:fe:30:7c:a4 brd ff:ff:ff:ff:ff:ff
[root@dbt01 ~]# 
[root@dbt01 ~]#  ip link set dev eth1 mtu 9000 ##修改私网网卡MTU
[root@dbt01 ~]# ip link show eth1   ##验证修改结果
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether fe:fc:fe:30:7c:a4 brd ff:ff:ff:ff:ff:ff
 [root@dbt01 ~]# 

 注意：两个节点都需要修改

(2) 永久修改 MTU

编辑网卡配置文件：

• Red Hat/CentOS

  sudo vi /etc/sysconfig/network-scripts/ifcfg-eth1

  添加以下内容：

  MTU=9000

重启网卡：

sudo ifdown eth1 && sudo ifup eth1

 注意：两个节点都需要修改

2. 修改 Jumbo Frame 后如何验证效果

(1) 使用ping 命令测试 Jumbo Frame

测试节点间的网络是否支持 9000 字节的 MTU：

 [root@dbt01 ~]# ping -c 4 -Mdo -s 8972 192.168.11.122PING 192.168.11.122 (192.168.11.122) 8972(9000) bytes of data.
8980 bytes from 192.168.11.122: icmp_seq=1 ttl=64 time=0.887 ms
8980 bytes from 192.168.11.122: icmp_seq=2 ttl=64 time=0.492 ms
8980 bytes from 192.168.11.122: icmp_seq=3 ttl=64 time=0.546 ms
8980 bytes from 192.168.11.122: icmp_seq=4 ttl=64 time=0.557 ms

• -Mdo
  ：强制不分片。
• -s 8972
  ：ICMP 数据包大小（加上 28 字节头部等于 9000 字节 MTU）。

正常情况下，所有包都应返回成功。

如果没有启用成功 报错应该如下，提示message to long

[root@dbt01 ~]# ping -c 4 -Mdo -s 8972 10.229.43.142
PING 10.229.43.142 (10.229.43.142) 8972(9000) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

(2) 检查网络统计信息

使用ifconfig  检查网卡统计信息：

[root@btdbt01 ~]# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr FE:FC:FE:30:7C:A4  
          inet addr:192.168.11.121  Bcast:192.168.11.255  Mask:255.255.255.0
          inet6 addr: fe80::fcfc:feff:fe30:7ca4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
          RX packets:853452922 errors:0 dropped:5 overruns:0 frame:0
          TX packets:708597428 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:724294742414 (674.5 GiB)  TX bytes:510652307354 (475.5 GiB)

• 确保没有RX 或TX 错误包。
• 验证网络数据包的传输正常。

(3) AWR 报告对比分析

启用 Jumbo Frame 后，重新生成 AWR 报告，比较RAC相关指标变化如GC类等待，interconnect statistics等

总结

 尽管Jumbo Frames在大多数 交换机中广泛支持，但它并不是IEEE认可的标准。所以在实际操作中，建议与网络管理员协作，确保交换机和所有节点都支持Jumbo Frame，以避免网络不兼容问题。 在许多情况下，由于不正确的设置、驱动程序或交换机软件中的错误，可能会出现故障或不一致，从而导致次优性能和网络错误。基于这些考虑在做集群的Jumbo Frame优化时 建议谨慎操作，并和网络管理员深度沟通确认。

虽然有诸多限制，和可能得风险但是在oracle的官方文档中依然有如下的表述“There is some complexity involved in configuring Jumbo Frames, which is highly hardware and OS specific.  The lack of a specific standard may present OS and hardware bugs. Even with these considerations, Oracle recommends using Jumbo Frames for private Cluster Interconnects.” 总之一句话虽然可能有诸多困难和问题，但是oracle 仍然建议在RAC集群中启用Jumbo Frame。