關於11g rhel6 11.2.0.3.0 rac VIP failover back ping不通的問題
1.主節點hosts配置
10.30.50.1 zrac01
10.30.50.2 zrac02
10.30.50.3 zrac01-vip
10.30.50.4 zrac02-vip
192.168.137.1 zrac01-priv
192.168.137.2 zrac02-priv
10.30.50.5 zrac-cluster-scan
2.網卡配置
public IP 網卡名 em1
VIP 網卡名 em1:1
em1 Link encap:Ethernet HWaddr 54:9F:35:0A:6F:50
inet addr:10.30.50.1 Bcast:10.30.50.63 Mask:255.255.255.192
inet6 addr: fe80::569f:35ff:fe0a:6f50/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:23410 errors:0 dropped:0 overruns:0 frame:0
TX packets:17231 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2448649 (2.3 MiB) TX bytes:1947974 (1.8 MiB)
Interrupt:35
em1:1 Link encap:Ethernet HWaddr 54:9F:35:0A:6F:50
inet addr:10.30.50.3 Bcast:10.30.50.63 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:35
em2 Link encap:Ethernet HWaddr 54:9F:35:0A:6F:51
inet addr:192.168.137.1 Bcast:192.168.137.255 Mask:255.255.255.0
inet6 addr: fe80::569f:35ff:fe0a:6f51/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:557429 errors:0 dropped:0 overruns:0 frame:0
TX packets:312048 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:611390963 (583.0 MiB) TX bytes:262148220 (250.0 MiB)
Interrupt:38
3.客戶端TNS配置
客戶端與數據庫服務器不在同一子網網段
GNNT1 =
(DESCRIPTION =
(FAILOVER=ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.30.50.3)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.30.50.4)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = gnnt)
(FAILOVER_MODE=(TYPE=select)(METHOD=basic)(BACKUP=zrac02))
)
)
GNNT3 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.30.50.3)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = gnnt)
)
)
問題描述:
當主節點RAC01停止CRS集羣后， zrac01-vip 10.30.50.3將漂移至第二個節點，關於VIP的migrate存在兩種情況
case1:如果客戶端與數據庫服務器不在同一子網網段，則VIP要漂移時要值得注意
1.當停止RAC1節點CRS後，zrac01-vip 10.30.50.3漂移至節點RAC2，此時客戶端通過ping 10.30.50.3是在超時狀態
2.當RAC1節點重新啓動CRS後，zrac01-vip 10.30.50.3重新漂移至節點RAC1,但客戶端仍舊無法通過TNS進行sqlplus連接實例1，客戶端反饋爲TNS超時
case2:如果客戶端與數據庫服務器在同一子網網段，則不存在vip漂移後ping不通的問題與sqlplus連接問題
測試狀態:
C:\Windows\System32>ping 10.30.50.3 -t
正在 Ping 10.30.50.3 具有 32 字節的數據:
請求超時。
請求超時。
請求超時。
請求超時。
導致此種情況，可以有兩種方式解決
1.此種情況是由於Oracle Duplicate list bug 13389756 bug 13396423 bug 13396684 bug 13357494 bug 13352041造成的，可以更新GI PSU至11.2.0.3.2以後解決
2.手動更新主機的ARP CACHE
導致VIP連接與ping超時情況的原因是arp cache機制與arp 自動響應的原因造成的，不通網段和平臺arp cache列表的自動更新時間各不同
通常
– 思科設備 – 20 min至4 hours,
– Linux – default 60 seconds,
– Windows – up to 10 more than minutes.
因此需要進行手動更新arp cache進行解決，當執行arping命令後，系統會爲VIP提供新的MAC地址，更新各個網段的路由信息和arp cache
#arping -c2 -I em1 -U 10.30.50.3
ARP cache 手動更新完成後，客戶端可以ping通VIP，sqplus可以正常連接
C:\Windows\System32>ping 10.30.50.3
正在 Ping 10.30.50.3 具有 32 字節的數據:
來自 10.30.50.3 的回覆: 字節=32 時間<1ms TTL=63
來自 10.30.50.3 的回覆: 字節=32 時間<1ms TTL=63
來自 10.30.50.3 的回覆: 字節=32 時間<1ms TTL=63
