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

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

《如果让Oracle RAC数据库能更充分利用高端服务器资源.docx》由会员分享，可在线阅读，更多相关《如果让Oracle RAC数据库能更充分利用高端服务器资源.docx（12页珍藏版）》请在冰豆网上搜索。

如果让OracleRAC数据库能更充分利用高端服务器资源

如果让OracleRAC数据库能更充分利用高端服务器资源

近年来，高端CPU芯片技术不断在突破摩尔定律，核数也越来越多，多路高端服务器的CPU处理能力越强。

但实际应用却很难把多路高端服务器资源有效利用起来。

以高端服务器用于常见高并发交易的OracleRAC数据库为例，往往会看到数据库服务器CPU利用率还较低，内存也有很多富余，DiskIO响应也很快，网络看似网卡带宽也没用满，查看数据库AWR报告，TopEvent中貌似也没有特别突出的等待事件。

但即使应用端怎么增加节点、优化配置，并发性能就是上不去了。

心理不免担忧在负载高峰来临时如何能应对，总不能把整个架构推翻，进行分库分表或者用分布式吧，那些看着挺好，但应用改造代价太高了，完全不是一朝一夕能解决的事情。

这中间可能忽略了一个问题，那就是高并发交易场景通常传输的是小网络包（几十-几百字节不等），而网卡在传输小网络包条件下，在远没达到带宽极限情况下，每秒传输包数量（PPS）先达到了网卡能力上限。

出现这种情况怎么办？

一种方式是让数据库和应用运行在一起，应用和数据库间通信走ipc机制或者用loopback环路地址，这种方式至今仍在广泛使用。

另一种方式是我们考虑用新型的高带宽低延迟的10Gb甚至100Gb网卡，并且将多张卡多个网口绑定在一起使用，这种方式能倍增网络带宽，但难以倍增PPS能力提升。

如何能让网络PPS能力翻倍，如果因为这个而舍弃高端数据库

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

OracleRAC数据库早已经具备了这样的能力，Oracle11gR2时，已经支持对RAC私有通信的HAIP（HighlyAvailableIP）功能，实现了集群内部通信的高可用及负载均衡。

Oracle12c（2013推出）支持多个不同网段的SCANIP（MultipleSubnetsSCANIP），同时提供对外连接和服务。

l左半部分为最常用的OracleRAC1SCANIP+1PrivateIP模式

l右半部分为OracleRAC（12c/18c/19c/20c）支持的多SCANIP+HAIP模式

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

HAIP**好处**

l多对PrivateIP同时负载均衡的为OracleRAC提供私有数据通信服务

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

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

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

多SCANIP好处

l多个SCANIP同时对外提供服务

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

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

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

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

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

这种模式的性能能提升多少？

可靠性又怎么样呢？

我们在K1Power9高端服务器上做了Oracle19cRAConAIX7.2做了全面验证，分享结果如下：

1.**性能提升**

如下图：

p256CPU线程配置下

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

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

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

Ø配上双SCAN，性能比单SCAN时提升了（20.96vs15.52）44%

1.**可靠性验证**

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

lHAIP**验证：

**

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

序号

HAIPover（en4+en5）故障场景

故障模拟方式

期望效果

结果

1

节点1的en5故障

en5网口down

两个节点私有通信都飘到en4上，对性能影响有限

通过

2

节点1的en5故障后恢复

en5网口线恢复并up

en5私有通信自动恢复，en4,en5恢复负载均衡

通过

3

节点1的en4,en5同时故障

en4,en5网口down

数据库节点1down，节点1所有vip,scanip,Oracle服务飘到节点2上。

剩余节点2继续运行

通过

4

节点1的en4,en5恢复

节点1恢复，en4,en5网口线恢复并up

数据库节点1恢复后，节点1上原有vip,scanip,Oracle服务器自动从节点2漂移回来，节点1可继续承接负载

通过

5

节点1和2的en4同时故障

节点1和2的en4网口同时down

两个节点私有通信都飘到en5上，对性能影响有限

通过

6

节点1和2的en4恢复

节点1和2的en4网口线恢复并up

en4私有通信自动恢复，en4,en5恢复负载均衡

通过

l多SCANIP验证：

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

序号

SCANIPover（en0+en1）故障场景

故障模拟方式

期望效果

结果

1

节点1的en1故障,故障前en1的SCANIP在节点2

节点1的en1网口down

属于节点1的en1上VIP漂移至节点2,负载影响较小

通过

2

节点1的en1恢复

节点1的en1网口线恢复并up

属于节点1的en1上VIP自动从节点2漂移回来，且侦听与服务恢复正常,负载正常

通过

3

节点2的en1故障,故障前en2的SCANIP在节点2

节点2的en1网口down

属于节点2的en1上VIP漂移至节点1,负载影响较小

通过

4

节点2的en1恢复

节点2的en1网口线恢复并up

属于节点2的en1上VIP，SCANIP自动从节点1漂移回来，且侦听与服务恢复正常,负载正常

通过

5

节点1的en0,en1同时故障,故障前en0的SCANIP在节点1，故障前en1的SCANIP在节点2

节点1的en0,en1网口down

属于节点1的en0上VIP,SCANIP漂移至节点2,en1上VIP,SCANIP漂移至节点2,负载影响较小

通过

6

节点1的en0,en1恢复

节点1的en0,en1网口线恢复并up

属于节点1的en0上VIP,SCANIP自动从节点2漂移回来,en1上VIP自动从节点2漂移回来，且侦听与服务恢复正常,负载正常

通过

7

节点1和2的en1同时故障,故障前en1的SCANIP在节点2

节点1和2的en1网口down

节点1和2的en1上VIP,SCANIP都不能工作，还剩en0对外提供服务，负载影响较小

通过

8

节点1和2的en1恢复

节点1和2的en1网口线恢复并up

属于节点1的en1上VIP恢复起来，属于节点2的en1上VIP,SCANIP恢复起来,且侦听与服务恢复正常,负载正常

通过

9

节点1和2的en0同时故障,故障前en0的SCANIP在节点1

节点1和2的en0网口down

节点1和2的en0上VIP,SCANIP都不能工作，还剩en1对外提供服务，负载影响较小

通过

10

节点1和2的en0恢复

节点1和2的en0网口线恢复并up

属于节点1的en0上VIP,SCANIP恢复起来，属于节点2的en0上VIP恢复起来,且侦听与服务恢复正常,负载正常

通过

11

节点1的对外en0和私有通信en4同时故障,故障前en0的SCANIP在节点1

节点1的en0,en4网口down

节点1和2的私有通信都飘到en5,属于节点1的en0上VIP和SCANIP漂移到节点2，负载影响较小

通过

12

节点1的对外en0和私有通信en4恢复

节点1的en0,en4网口线恢复并up

节点1和2的私有通信恢复到en4+en5,属于节点1的en0上VIP和SCANIP从节点2漂移回来，且侦听与服务恢复正常,负载正常

通过

13

节点1的所有对外en0,en1和私有通信en4，en5同时故障,故障前en0的SCANIP在节点1,en1的SCANIP在节点2

节点1的en0，en1,en4,en5网口全部down

节点1私有通信全断。

属于节点1的en0上VIP和SCANIP漂移到节点2，节点1的en1上VIP漂移到节点2。

剩余节点2对外服务器，负载影响较小

通过

14

节点1的所有对外en0,en1和私有通信en4，en5恢复

节点1的en0，en1,en4,en5网口线全部恢复并up

节点1私有通信恢复。

属于节点1的en0上VIP和SCANIP从节点2漂移回来，节点1的en1上VIP从节点2漂移回来。

节点1数据库实例启动后，侦听与服务恢复正常,2个节点同时对外服务,负载正常

通过

15

模拟节点1挂账

节点1halt-q

节点1故障后。

剩余节点2对外服务器，负载影响较小

通过

16

节点1重启恢复

节点1重启恢复

节点1恢复后，属于节点1的en0上VIP和SCANIP从节点2漂移回来，节点1的en1上VIP从节点2漂移回来。

节点1数据库实例启动后，侦听与服务恢复正常,2个节点同时对外服务,负载正常

通过

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

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

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

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

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

附录：

多SCAN参考：

HAIP**参考：

**

实验环境说明

RACLPAR

Hostname

系统版本

Boot网口及IP_1

Boot2网口及IP_2

RAC心跳网口HAIP

服务VIP1&2

SCANIP1&2

共享存储

dblpar1

dbnode1

7200-04-01-1939

en0:

172.16.102.221

en1:

172.16.103.221

en4:

192.168.102.221en5:

192.168.103.221

en0:

172.16.102.223en1:

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.222en5:

192.168.103.222

en0:

172.16.102.224en1:

172.16.103.224

en1:

172.16.103.225

配置双SCAN+HAIP参考

l分配新增的SCANIP和HAIP用的publicip2,vip2,scanip2和PrivateIP2…

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

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

cat/etc/hosts

172.16.102.221dbnode1

172.16.102.222dbnode2

172.16.102.223dbnode1_vip

172.16.102.224dbnode2_vip

172.16.102.225dbscan102

192.168.102.221dbnode1_priv

192.168.102.222dbnode2_priv

172.16.103.221dbnode12

172.16.103.222dbnode22

172.16.103.223dbnode1_vip2

172.16.103.224dbnode2_vip2

172.16.103.225dbscan103

192.168.103.221dbnode1_priv2

192.168.103.222dbnode2_priv2

l给OracleRAC配置SCANIP&HAIP，然后重启生效

[root]#./oifcfgsetif-globalen5/192.168.103.0:

cluster_interconnect

[root]#cd/oracle/grid/bin;./oifcfgsetif-globalen1/172.16.103.0:

public

[root]#./oifcfggetif–global

en0172.16.102.0globalpublic

en4192.168.102.0globalcluster_interconnect,asm

en5192.168.103.0globalcluster_interconnect

en1172.16.103.0globalpublic

[root]#./srvctladdnetwork-netnum2-subnet172.16.103.0/255.255.255.0/en1

[root]#./srvctlconfignetwork-netnum2

[root]#./srvctladdvip-nodedbnode1-netnum2-addressdbnode1_vip2/255.255.255.0

[root]#./srvctladdvip-nodedbnode2-netnum2-addressdbnode2_vip2/255.255.255.0

[grid]$srvctladdlistener-listenerlistener2-netnum2-endpoints"TCP:

1522"

[root]#./srvctladdscan-scannamedbscan103-netnum2

[root]#./srvctlstartvip-vipdbnode1_vip2;./srvctlstartvip-vipdbnode2_vip2

[grid]$srvctlstartlistener-listenerlistener2;srvctlstatuslistener-listenerlistener2

[root]#./srvctlstartscan-netnum2

[grid]$srvctladdscan_listener-netnum2-listenerLISTENER_SCAN2-endpoints"TCP:

1522"

[grid]$srvctlstartscan_listener-netnum2

[root]#./srvctlconfigscan-netnum2;./srvctlstatusscan-netnum2