作者lisongqing

联盟成员

·2020-06-14 17:56

软件架构设计师·IPS

如何让Oracle RAC数据库能更充分利用高端服务器资源

字数 8018阅读 3402评论 0赞 3

近年来，高端 CPU 芯片技术不断在突破摩尔定律，核数也越来越多，多路高端服务器的 CPU 处理能力越强。但实际应用却很难把多路高端服务器资源有效利用起来。

以高端服务器用于常见高并发交易的 Oracle RAC 数据库为例，往往会看到数据库服务器 CPU 利用率还较低，内存也有很多富余， Disk IO 响应也很快，网络看似网卡带宽也没用满，查看数据库 AWR 报告， Top Event 中貌似也没有特别突出的等待事件。但即使应用端怎么增加节点、优化配置，并发性能就是上不去了。心理不免担忧在负载高峰来临时如何能应对，总不能把整个架构推翻，进行分库分表或者用分布式吧，那些看着挺好，但应用改造代价太高了，完全不是一朝一夕能解决的事情。

这中间可能忽略了一个问题，那就是高并发交易场景通常传输的是小网络包 ( 几十 - 几百字节不等），而网卡在传输小网络包条件下，在远没达到带宽极限情况下，每秒传输包数量（ PPS ）先达到了网卡能力上限。出现这种情况怎么办？一种方式是让数据库和应用运行在一起，应用和数据库间通信走 ipc 机制或者用 loopback 环路地址，这种方式至今仍在广泛使用。另一种方式是我们考虑用新型的高带宽低延迟的 10Gb 甚至 100Gb 网卡，并且将多张卡多个网口绑定在一起使用，这种方式能倍增网络带宽，但难以倍增 PPS 能力提升。

如何能让网络 PPS 能力翻倍：

比较简便的是用多个独立的网络接口，配置多个不同的 IP 并行使用了，这种方式我们的数据库应用需要如何改造呢？

Oracle RAC 数据库早已经具备了这样的能力， Oracle 11gR2 时，已经支持对 RAC 私有通信的 HAIP （ Highly Available IP ）功能，实现了集群内部通信的高可用及负载均衡。 Oracle 12c(2013 推出 ) 支持多个不同网段的 SCAN IP （ Multiple Subnets SCAN IP ），同时提供对外连接和服务。

![](/home/attachment/202006/14/930977_159212841464805.png)
 l  左半部分为最常用的 Oracle RAC 1*SCAN IP+1*Private IP 模式

l  右半部分为 Oracle RAC (12c/18c/19c/20c) 支持的多 SCAN IP+HAIP 模式

采用这种多 SCAN IP+HAIP 模式，除了已提到的解决高端服务器上数据库网络包传输能力不足问题，提升数据库系统整体性能，都有什么好处呢？

**HAIP****好处**

l  多对 Private IP 同时负载均衡的为 Oracle RAC 提供私有数据通信服务

l  倍增 Oracle RAC 私有通信带宽，降低节点间通信延迟

l  数据库应用可以在 RAC 间更好的负载均衡

l  提高 Oracle RAC 数据库的响应速度和整体并发性能

**多 SCAN IP 好处**

l  多个 SCAN IP 同时对外提供服务

l  提高网络传输能力，提升数据库高并发交易处理能力

l  为数据库应用提供分组负载均衡

l  为数据库部署多服务、多租户 (CDB/PDB) 环境提供网络隔离，更安全

l  不同数据库应用服务可以接入不同网元，实现应用的网元隔离

l  提高 Oracle RAC 数据库的整体并发性能、可靠性和安全性

这种模式的性能能提升多少？可靠性又怎么样呢？

我们在 K1 Power9 高端服务器上做了 Oracle 19c RAC on AIX 7.2 做了全面验证，分享结果如下：

**1.****性能提升**

如下图：

p  256CPU 线程配置下

Ø  单 SCAN ，网络性能勉强够用的

p  提高到 352CPU 线程（增加 37% ）

Ø  单 SCAN ，网络有明显网络瓶颈

Ø  配上双 SCAN ，性能比单 SCAN 时提升了（ 20.96 vs 15.52 ）**44%**

![](/home/attachment/202006/14/930977_159212843919781.png)

**1.****可靠性验证**

对 HAIP 和双 SCAN IP 共做了 22 组故障场景下 RAC 可靠性和服务连续性验证，结果全部通过。

l  **HAIP****验证：**

Oracle RAC 用了 en4 和 en5 两个网口做 HAIP 私有网络通信（测试条件有限，没有更多张卡了）

|   |   |   |   |   |
| ------------ | ------------ | ------------ | ------------ | ------------ |
| 序号 | HAIP over (en4+en5)故障场景 | 故障模拟方式 | 期望效果 | 结果 |
| 1 | 节点1的en5故障 | en5网口down | 两个节点私有通信都飘到en4上，对性能影响有限 | 通过 |
| 2 | 节点1的en5故障后恢复 | en5网口线恢复并up | en5私有通信自动恢复，en4,en5恢复负载均衡 | 通过 |
| 3 | 节点1的en4,en5同时故障 | en4,en5网口down | 数据库节点1 down，节点1所有vip,scan ip, Oracle服务飘到节点2上。剩余节点2继续运行 | 通过 |
| 4 | 节点1的en4,en5恢复 | 节点1恢复，en4,en5网口线恢复并up | 数据库节点1恢复后，节点1上原有vip,scan ip, Oracle服务器自动从节点2漂移回来，节点1可继续承接负载 | 通过 |
| 5 | 节点1和2的en4同时故障 | 节点1和2的en4网口同时down | 两个节点私有通信都飘到en5上，对性能影响有限 | 通过 |
| 6 | 节点1和2的en4恢复 | 节点1和2的en4网口线恢复并up | en4私有通信自动恢复，en4,en5恢复负载均衡 | 通过 |

l  **多 SCAN IP 验证：**

Oracle RAC 用了 en0 和 en1 两个网口做对外服务器双 SCAN IP （测试条件有限，没有更多张卡了）

|   |   |   |   |   |
| ------------ | ------------ | ------------ | ------------ | ------------ |
| 序号 | SCAN IP over (en0+en1)故障场景 | 故障模拟方式 | 期望效果 | 结果 |
| 1 | 节点1的en1故障,故障前en1的SCAN IP在节点2 | 节点1的en1网口down | 属于节点1的en1上VIP漂移至节点2,负载影响较小 | 通过 |
| 2 | 节点1的en1恢复 | 节点1的en1网口线恢复并up | 属于节点1的en1上VIP自动从节点2漂移回来，且侦听与服务恢复正常,负载正常 | 通过 |
| 3 | 节点2的en1故障,故障前en2的SCAN IP在节点2 | 节点2的en1网口down | 属于节点2的en1上VIP漂移至节点1,负载影响较小 | 通过 |
| 4 | 节点2的en1恢复 | 节点2的en1网口线恢复并up | 属于节点2的en1上VIP，SCAN IP自动从节点1漂移回来，且侦听与服务恢复正常,负载正常 | 通过 |
| 5 | 节点1的en0,en1同时故障,故障前en0的SCAN IP在节点1，故障前en1的SCAN IP在节点2 | 节点1的en0,en1网口down | 属于节点1的en0上VIP,SCAN IP漂移至节点2,en1上VIP,SCAN IP漂移至节点2,负载影响较小 | 通过 |
| 6 | 节点1的en0,en1恢复 | 节点1的en0,en1网口线恢复并up | 属于节点1的en0上VIP,SCAN IP自动从节点2漂移回来,en1上VIP自动从节点2漂移回来，且侦听与服务恢复正常,负载正常 | 通过 |
| 7 | 节点1和2的en1同时故障,故障前en1的SCAN IP在节点2 | 节点1和2的en1网口down | 节点1和2的en1上VIP,SCAN IP都不能工作，还剩en0对外提供服务，负载影响较小 | 通过 |
| 8 | 节点1和2的en1恢复 | 节点1和2的en1网口线恢复并up | 属于节点1的en1上VIP恢复起来，属于节点2的en1上VIP,SCAN IP恢复起来,且侦听与服务恢复正常,负载正常 | 通过 |
| 9 | 节点1和2的en0同时故障,故障前en0的SCAN IP在节点1 | 节点1和2的en0网口down | 节点1和2的en0上VIP,SCAN IP都不能工作，还剩en1对外提供服务，负载影响较小 | 通过 |
| 10 | 节点1和2的en0恢复 | 节点1和2的en0网口线恢复并up | 属于节点1的en0上VIP,SCAN IP恢复起来，属于节点2的en0上VIP恢复起来,且侦听与服务恢复正常,负载正常 | 通过 |
| 11 | 节点1的对外en0和私有通信en4同时故障,故障前en0的SCAN IP在节点1 | 节点1的en0,en4网口down | 节点1和2的私有通信都飘到en5,属于节点1的en0上VIP和SCAN IP漂移到节点2，负载影响较小 | 通过 |
| 12 | 节点1的对外en0和私有通信en4恢复 | 节点1的en0,en4网口线恢复并up | 节点1和2的私有通信恢复到en4+en5,属于节点1的en0上VIP和SCAN IP从节点2漂移回来，且侦听与服务恢复正常,负载正常 | 通过 |
| 13 | 节点1的所有对外en0,en1和私有通信en4，en5同时故障,故障前en0的SCAN IP在节点1, en1的SCAN IP在节点2 | 节点1的en0，en1,en4,en5网口全部down | 节点1私有通信全断。属于节点1的en0上VIP和SCAN IP漂移到节点2，节点1的en1上VIP漂移到节点2。剩余节点2对外服务器，负载影响较小 | 通过 |
| 14 | 节点1的所有对外en0,en1和私有通信en4，en5恢复 | 节点1的en0，en1,en4,en5网口线全部恢复并up | 节点1私有通信恢复。属于节点1的en0上VIP和SCAN IP从节点2漂移回来，节点1的en1上VIP从节点2漂移回来。节点1数据库实例启动后，侦听与服务恢复正常,2个节点同时对外服务,负载正常 | 通过 |
| 15 | 模拟节点1挂账 | 节点1 halt -q | 节点1故障后。剩余节点2对外服务器，负载影响较小 | 通过 |
| 16 | 节点1重启恢复 | 节点1重启恢复 | 节点1恢复后，属于节点1的en0上VIP和SCAN IP从节点2漂移回来，节点1的en1上VIP从节点2漂移回来。节点1数据库实例启动后，侦听与服务恢复正常,2个节点同时对外服务,负载正常 | 通过 |

最后您可能要问，它会对数据库应用的开发、部署和运维带来什么影响。

l  对数据库应用开发过程是透明的，与单 SCAN 时用法基本一致

l  数据库系统架构设计要考虑双 SCAN IP 在对网络架构带来的变化，以及数据库服务部署是否针对多 SCAN 方式做相应调整（默认多个 SCAN 均等，接入所有数据库服务）

l  上线前需要对这种架构多做带负载的功能测试及性能验证，消除部署过程可能发生的错误

如果使用高端服务器上 Oracle RAC 数据库，在高并发下遇到类似网络性能问题，不妨试试这种方式。

**附录：**

**多 SCAN 参考：**

[https://support.oracle.com/knowledge/Oracle%20Database%20Products/2138078_1.html](https://support.oracle.com/knowledge/Oracle%20Database%20Products/2138078_1.html)

[https://www.oracle.com/technetwork/products/clustering/overview/scan-129069.pdf](https://www.oracle.com/technetwork/products/clustering/overview/scan-129069.pdf)

**HAIP****参考：**

[https://docs.oracle.com/database/121/CWADD/GUID-478452E9-5A0B-4B36-BF82-CDF585007D14.htm#CWADD92358](https://docs.oracle.com/database/121/CWADD/GUID-478452E9-5A0B-4B36-BF82-CDF585007D14.htm#CWADD92358)

**实验环境说明**

|   |   |   |   |   |   |   |   |   |
| ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ |
| RAC LPAR | Hostname | 系统版本 | Boot网口及IP_1 | Boot2网口及IP_2 | RAC心跳网口 HAIP | 服务VIP 1 & 2 | SCANIP 1 & 2 | 共享存储 |
| dblpar1 | dbnode1 | 7200-04-01-1939 | en0:172.16.102.221 | en1: 172.16.103.221 | en4:192.168.102.221 en5:192.168.103.221 | en0:172.16.102.223 en1:172.16.103.223 | en0:172.16.102.225 | 5*350GB =1.65TB |
| dblpar2 | dbnode2 | 7200-04-01-1939 | en0:172.16.102.222 | en1: 172.16.103.222 | en4:192.168.102.222 en5:192.168.103.222 | en0:172.16.102.224 en1:172.16.103.224 | en1:172.16.103.225 |
****

**配置双 SCAN+HAIP 参考**

l  分配新增的 SCAN IP 和 HAIP 用的 public ip 2,vip 2, scan ip2 和 Private IP 2 …

l  完成网络交换机配置和布线改造

l  给 AIX 系统配置新增的 IP 地址

# cat /etc/hosts

172.16.102.221 dbnode1

172.16.102.222 dbnode2

172.16.102.223 dbnode1_vip

172.16.102.224 dbnode2_vip

172.16.102.225 dbscan102

192.168.102.221 dbnode1_priv

192.168.102.222 dbnode2_priv

172.16.103.221 dbnode12

172.16.103.222 dbnode22

172.16.103.223 dbnode1_vip2

172.16.103.224 dbnode2_vip2

172.16.103.225 dbscan103

192.168.103.221 dbnode1_priv2

192.168.103.222 dbnode2_priv2

l  **给 Oracle RAC 配置 SCAN IP & HAIP ，然后重启生效**

[root]# ./oifcfg setif -global en5/192.168.103.0:cluster_interconnect

[root]# cd /oracle/grid/bin; ./oifcfg setif -global en1/172.16.103.0:public

[root]# ./oifcfg getif – global

en0 172.16.102.0 global public

en4 192.168.102.0 global cluster_interconnect,asm

en5 192.168.103.0 global cluster_interconnect

en1 172.16.103.0 global public

[root]# ./srvctl add network -netnum 2 -subnet 172.16.103.0/255.255.255.0/en1

[root]# ./srvctl config network -netnum 2

[root]# ./srvctl add vip -node dbnode1 -netnum 2 -address dbnode1_vip2/255.255.255.0

[root]# ./srvctl add vip -node dbnode2 -netnum 2 -address dbnode2_vip2/255.255.255.0

[grid]$ srvctl add listener -listener listener2 -netnum 2 -endpoints "TCP:1522"

[root]# ./srvctl add scan -scanname dbscan103 -netnum 2

[root]# ./srvctl start vip -vip dbnode1_vip2; ./srvctl start vip -vip dbnode2_vip2

[grid]$ srvctl start listener -listener listener2; srvctl status listener -listener listener2

[root]# ./srvctl start scan -netnum 2

[grid]$ srvctl add scan_listener -netnum 2 -listener LISTENER_SCAN2 -endpoints "TCP:1522"

[grid]$ srvctl start scan_listener -netnum 2

[root]# ./srvctl config scan -netnum 2; ./srvctl status scan -netnum 2

Power Oracle集群 Oracle AIX

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

作者其他文章

国产K1 Power上统信UOS系统+Spectrum Scale集群部署
评论 0 · 赞 2

DB2 V11.5数据库及日志内置Power ZLIB硬件加速压缩与加密备份
评论 1 · 赞 2

如何让AIX系统过滤errlog/errpt中无用报错信息
评论 0 · 赞 0

全面支持+性能优势 - K1 Power强力支持开源和国产数据库
评论 0 · 赞 1

MySQL for AIX 7.2
评论 0 · 赞 1

相关文章

某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-技术路线选择篇

Oracle数据库日常巡检指令

数据库租户能力大调研

Oracle 兼容性面面观

在AIX 7.3上安装XL C/C++ V16.1编译器

相关问题

docker能否运行AIX系统？

hdiskpower和hdisk盘PVID相同？

国产分布式数据库真的能全面替换核心业务吗？Oracle为何没有向分布式发力？

现在入行数据库，选择Oracle数据库为切入点，是对是错呢？

AIX 转 x86 的 CPU 选型该如何选？

相关资料

国产K1 Power10 K8880G3上AIX由7.2升级7.3+Oracle_19c升级实践

AIX及S924小型机日常维护手册

Redhat7.6 Oracle 19C RAC部署手册

Redhat7.0 Oracle 12C RAC部署手册

Oracle数据库日常维护手册v1.8

关于TWT 使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们
© 2024talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30

X社区推广