如果让Oracle RAC数据库能更充分利用高端服务器资源Word文件下载.docx
《如果让Oracle RAC数据库能更充分利用高端服务器资源Word文件下载.docx》由会员分享,可在线阅读,更多相关《如果让Oracle RAC数据库能更充分利用高端服务器资源Word文件下载.docx(12页珍藏版)》请在冰豆网上搜索。
![如果让Oracle RAC数据库能更充分利用高端服务器资源Word文件下载.docx](https://file1.bdocx.com/fileroot1/2022-12/30/fdc502f7-a2bc-474f-8a41-e24be925ff15/fdc502f7-a2bc-474f-8a41-e24be925ff151.gif)
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的en1故障,故障前en1的SCANIP在节点2
节点1的en1网口down
属于节点1的en1上VIP漂移至节点2,负载影响较小
节点1的en1恢复
节点1的en1网口线恢复并up
属于节点1的en1上VIP自动从节点2漂移回来,且侦听与服务恢复正常,负载正常
节点2的en1故障,故障前en2的SCANIP在节点2
节点2的en1网口down
属于节点2的en1上VIP漂移至节点1,负载影响较小
节点2的en1恢复
节点2的en1网口线恢复并up
属于节点2的en1上VIP,SCANIP自动从节点1漂移回来,且侦听与服务恢复正常,负载正常
节点1的en0,en1同时故障,故障前en0的SCANIP在节点1,故障前en1的SCANIP在节点2
节点1的en0,en1网口down
属于节点1的en0上VIP,SCANIP漂移至节点2,en1上VIP,SCANIP漂移至节点2,负载影响较小
节点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故障后。
16
节点1重启恢复
节点1恢复后,属于节点1的en0上VIP和SCANIP从节点2漂移回来,节点1的en1上VIP从节点2漂移回来。
最后您可能要问,它会对数据库应用的开发、部署和运维带来什么影响。
l对数据库应用开发过程是透明的,与单SCAN时用法基本一致
l数据库系统架构设计要考虑双SCANIP在对网络架构带来的变化,以及数据库服务部署是否针对多SCAN方式做相应调整(默认多个SCAN均等,接入所有数据库服务)
l上线前需要对这种架构多做带负载的功能测试及性能验证,消除部署过程可能发生的错误
如果使用高端服务器上OracleRAC数据库,在高并发下遇到类似网络性能问题,不妨试试这种方式。
附录:
多SCAN参考:
HAIP**参考:
实验环境说明
RACLPAR
Hostname
系统版本
Boot网口及IP_1
Boot2网口及IP_2
RAC心跳网口HAIP
服务VIP1&
2
SCANIP1&
共享存储
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
172.16.102.223en1:
172.16.103.223
172.16.102.225
5*350GB=1.65TB
dblpar2
dbnode2
172.16.102.222
172.16.103.222
192.168.102.222en5:
192.168.103.222
172.16.102.224en1:
172.16.103.224
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"
[grid]$srvctlstartscan_listener-netnum2
[root]#./srvctlconfigscan-netnum2;
./srvctlstatusscan-netnum2