数据库管理-第164期 关于RAC私网的一些探索（20240326）

数据库管理-第164期 关于RAC私网的一些探索（20240326）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
国内某科技公司 DBA总监
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家，OCM讲师
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭。

“众所周知”，在Oracle Real Application Cluster（RAC）集群架构中，每个节点都有一个到公网（public network）的网络连接，该网络是用语应用程序访问数据库集群。每个节点都有一个私有用网络（private network），也称为互连（interconnect），用于提供集群节点之间的通信。共享存储（shared storage）则必须可以从每个节点访问。

本期就探讨一下私网相关的一些问题。

1 带宽

RAC的私网，不仅仅承载了集群节点间的心跳，也承载了cache fusion等其他RAC特性。因此私网占用量不会很小，最早我那个12.2的四节点RAC，大概30TB数据，使用单万兆网络作为私网就经常发现GC相关等待较高，从EMCC的实时ADDM来看，万兆经常处于带宽占满的状态，引起了大量GC等待。其实这是有风险的，如果GC相关操作完全占满了私网带宽，除了会引起集群等待增加、延迟增大，也很容易造成心跳检测异常。因此，在一体机来之前，新加了网卡，让私网变成两路万兆并行，暂时解决了这一问题（当然最后这套库大多数都迁移到一体机了）。

2 直连还是交换机

在很多场景，一些DBA会使用节点间直连方式来构建私网，这一看似简单的方便的集群假设方案，会带来一些问题：

1. 将集群节点总数限制为2，无法实现扩展
2. 直连不如过交换机稳定
3. 某些NIC卡因为无法协商DTE/DCE时钟而无法正常工作。因为交换机有时钟，这些NIC就变得更便宜了。同时无法知道哪些NIC没有时钟功能。
4. 网线断开时（比如直连集群中的一个节点挂掉了），各种操作系统上的媒介感知行为会导致NIC断开（在Linux上有时还会导致网卡UUID产生变化无法使用）。这些问题中的任何一个都可能导致集群不稳定，并导致ORA-29740错误（节点驱逐）。

因此不建议在生产RAC集群使用直连。特别是第2、4点叠加，之前处理过很多次，节点异常or网络波动导致集群只能单节点运行，有时候还得去重置网卡UUID。

3 其他建议

这里也引入一下在操作系统层面的一些优化建议，即在/etc/sysctl.conf中添加以下内容并生效，这样可以避免一些异常网络发包带来的一些问题：

net.ipv4.ipfrag_high_thresh=16777216
net.ipv4.ipfrag_low_thresh=15728640

sysctl -p

在某些情况下，网卡与网络环境默认的mtu也是不合适的，需要调整，只要涉及硬件侧调整的，停库做，和网络工程师联调好。

总结

本期对RAC私网的一些技术点进行了探索。
老规矩，知道写了些啥。