碼上快樂

相關內容    簡體    繁體

oracle之 RAC Interconnect之HAIP

本文轉載自   查看原文   2017-09-14 10:03   1787    oracle 11G RAC

0、 背景

Oracle 從11.2.0.2開始引入了一個新特性叫做Redundant Interconnect，簡稱HAIP。HAIP的目的用來代替操作系統級別的網卡綁定以實現Active-Active的模式進行數據傳輸。一來可以實現傳統操作系統網卡綁定帶來的故障轉移的功能，另一方面則可以更加充分利用其負載均衡的特性最大程度的減少因為gc等待帶來的性能問題。

HAIP的歷史可以追溯到Oracle 10g時代，那個時候CRS中就已經包含了HAIP的雛形. 在安裝10g安裝CRS的時候，在選擇私有網絡的時候可以選擇多個私有網卡， 雖然官方文檔中沒有提及，但是很多Oracle的銷售甚至工程師都宣稱其可以提供高可用性，但實際測試中卻往往不盡如人意。

從11.2.0.2這一功能開始得到完善，最終形成了HAIP。 我們可以看到在GI升級到11.2.0.2以后，會自動生成一個叫做ora.cluster_interconnect.haip的資源（這也是haip名字的來歷），管理這個資源的是ohasd.bin進程。其對應的log位於$GRID_HOME/log//ohasd/ohasd.log 以及GRID_HOME/log//agent/ohasd/orarootagent_root/orarootagent_root.log這兩個位置。在HAIP資源online以后，通過操作系統命令ifconfig -a就能查看到多了類似與eth0:1的虛擬網卡，HAIP地址為169.254.X.X, 當然也可以在數據庫級別查看V_$CLUSTER_INTERCONNECTS視圖HAIP的地址。HAIP對應的地址由系統自動分配，無法由用戶手工進行指定。

由於HAIP使用的是169.254.X.X的地址段，所以在GI准備升級到11.2.0.2+以前都需要檢查此地址段是否已經被占用，否則可能會遇到一些意想不到的情況，最終導致GI無法啟動而整個升級則不得不失敗告終。一個比較典型的情況是在IBM的IMM web interface就是使用這個地址段的。那么Oracle為啥偏偏要選擇這個地址段呢？簡單的回答就是因為169.254.X.X地址段是預留的ip地址段。 此地址段用於ip地址的autoconfiguration以及link localaddress, 並且早已經被RFC標准化——RFC3927。對這個感興趣的讀者可訪問Zero configuration networking, Link local address和RFC3927來獲取更多相關信息。

HAIP對於Oracle Clusterware以及RDBMS的要求很嚴格。這兩者的版本都需要在11.2.0.2以上。簡單的舉個例子，有這么一種組合： GI的版本在11.2.0.3, RDBMS的版本在10.2.0.5。這種模式下雖然心跳網卡上會生成169.254.X.X地址段的虛地址，但實際上低於11.2.0.2的RDBMS是無法感知到這個地址的存在的，所以也無法使用HAIP提供的高可用特性。另外請注意在早期的HAIP的文檔中並沒有強制要求使用HAIP的私有網卡地址必須在同一個子網，結果導致了很多問題——尤其是在AIX平台，現在新版的文檔/MOS已經對此明確要求。

值得一提的是早期的HAIP存在不少bug。在MOS note 11gR2 Grid Infrastructure Redundant Interconnect and ora.cluster_interconnect.haip [ID 1210883.1] 上提供了大多數已知的HAIP，請讀者自行閱讀，我這里簡單的Bug號方便由於某些原因暫時無法登錄MOS的讀者：（注意其中兩個note雖然並非HAIP本身的bug，但是同樣與HAIP相關）

bug 12674817
Bug 10332426
Bug 10363902
Bug 10357258
Bug 10397652
Bug 10253028
Bug 9795321
Bug 11077756
Bug 12546712
Note 1366211.1
bug 10114953
Note 1447517.1

HAIP無法被禁用，當然某些不支持HAIP的平台例如Microsoft Windows除外。如果用戶使用的是操作系統級別的綁定或者沒有使用私網的綁定，則可以通過在rdbms和asm的init.ora/spfile中設置CLUSTER_INTECONNECTS指定私網地址將HAIP覆蓋（如果有多個私網地址，請用英文：分隔），雖然說HAIP本身依然存在，但是ASM實例和RDBMS實例以后就不會使用HAIP。

就鄙人看來，HAIP到目前為止還太新，僅僅是一個“看上去很美”的特性，Oracle總是幻想實現一切不依賴於操作系統的內建高可用特性。但是和Oracle大多數看上去很誘人新特性一樣，想法很好， 實現很糟糕。當然在11.2.0.4出來以后HAIP Bug基本會修復完，到時候再去使用HAIP也不遲，目前推薦使用操作系統級別的綁定理由只有一個——因為它更穩定可靠。下一篇將主要介紹OS級別的故障轉移。

 

1. HAIP簡介

Oracle從11.2.0.2開始引入了一個新特性網絡冗余技術HAIP。HAIP的目的用來代替操作系統級別的網卡綁定以實現Active-Active的模式進行數據傳輸。一來可以實現傳統操作系統網卡綁定帶來的故障轉移的功能，另一方面則可以更加充分利用其負載均衡的特性最大程度的減少因為gc等待帶來的性能問題。

如果更多的網絡適配器被指定，clusterware可以一次激活最多4個專用網絡適配器。ora.cluster_interconnect.haip 將為Oracle RAC、Oracle ASM、Oracle ACFS等啟用一至四個連接本地HAIP的互聯通信網絡適配器，注意，如果存在sun cluster，HAIT特性將在11.2.0.2中禁用。

Grid將自動選擇連接本地保留地址169.254.*.*作為HAIP子網，並且不會嘗試適用任何169.254.*.*地址，如果它已經被在用於其它目的使用。由於HAIP，在默認情況下，網絡流量將被所有活動的網絡接口負載均衡。並且如果其中一個失敗或者變成不可連接狀態，相應的HAIP地址將透明的轉移到相對的其它網絡適配器。

當Grid中啟動集群中的第一個節點，HAIP地址數量是由有多少個私有網絡適配器是活動狀態所決定的。如果只有一個活躍的私有網絡，那么Grid將創建一個，如果有兩個，Grid將創建兩個,如果大於兩個，Grid將創建4個HAIPs.即使更多的私有網絡適配器隨后被激活，HAIPs的數量是不會改變的，要使得新的網絡適配器變成活動狀態，則要重啟集群所有的節點。
[參考 http://blog.csdn.net/ora_unix/article/details/9420393 ]
[參考 MetaLink 1210883.1]

2. HAIP服務

由於HAIP是默認開啟的，使用169.254.*.*私有地址，可以通過oifcfg和ifconfig來查看：

 

在數據庫和ASM實例的啟動階段，可以從alert_.log中找到：
Cluster communication is configured to use the following interface(s) for this instance
169.254.151.97

在數據庫中通過gv$cluster_interconnects視圖可以顯示haip的信息

 

而集群架構中的相關結構：

 

3. 添加新的專用網絡適配器

下面我們對racdb01, racdb02, racdb03三個節點繼續添加一塊網卡eth02（地址分配192.168.1.211,192.168.1.213,192.168.1.215)，然后通過oifcfg將這塊網卡添加到ocr中。

 

然后分別重啟三個節點的集群服務，HAIP會自動生效：
在三個節點分別做完配置，重啟集群，HAIP自動生效。

 

4. 模擬網絡故障

斷開racdb03的eth1:
# ifconfig eth1 down
數據庫和ASM的alert中並未出現任何報錯，說明IP地址已經進行了透明的偏移。
[參考 http://www.luocs.com/archives/281.html]

 

查看ohasd的日志$GRID_HOME/log/ohasd/ohasd.log

 

查看agent日志$GRID_HOME/log/racdb03/agent/ohasd/orarootagent_root,可以看到moving ip ‘169.254.79.164’ from inf ‘eth1′ to inf ‘eth2’：

 

這時打開eth1網卡來模擬地址恢復
ifconfig eth1 up
查看日志$GRID_HOME/log/racdb03/agent/ohasd/orarootagent_root,可以看到IP地址飄回：Moving ip ‘169.254.79.164’ from inf ‘eth2′ to inf ‘eth1′

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
2013-08-12 14:19:49.675: [ USRTHRD][3420448512]{0:0:2} HAIP:  Updating member info HAIP1;192.168.1.0#0;192.168.1.0#1
2013-08-12 14:19:49.676: [ USRTHRD][3420448512]{0:0:2} HAIP:  Moving ip '169.254.79.164' from inf 'eth2' to inf 'eth1'
2013-08-12 14:19:49.676: [ USRTHRD][3420448512]{0:0:2} pausing thread
2013-08-12 14:19:49.676: [ USRTHRD][3420448512]{0:0:2} posting thread
2013-08-12 14:19:49.676: [ USRTHRD][3420448512]{0:0:2} Thread:[NetHAWork]start {
2013-08-12 14:19:49.677: [ USRTHRD][3420448512]{0:0:2} Thread:[NetHAWork]start }
2013-08-12 14:19:49.677: [ USRTHRD][3418347264]{0:0:2} [NetHAWork] thread started
2013-08-12 14:19:49.677: [ USRTHRD][3418347264]{0:0:2}  Arp::sCreateSocket {
2013-08-12 14:19:49.692: [ USRTHRD][3418347264]{0:0:2}  Arp::sCreateSocket }
2013-08-12 14:19:50.192: [ USRTHRD][3418347264]{0:0:2} Starting Probe for ip 169.254.79.164
2013-08-12 14:19:50.192: [ USRTHRD][3418347264]{0:0:2} Transitioning to Probe State
2013-08-12 14:19:50.192: [ USRTHRD][3418347264]{0:0:2}  Arp::sProbe {
2013-08-12 14:19:50.192: [ USRTHRD][3418347264]{0:0:2} Arp::sSend:  sending type 1
2013-08-12 14:19:50.192: [ USRTHRD][3418347264]{0:0:2}  Arp::sProbe }
2013-08-12 14:19:51.688: [ USRTHRD][3418347264]{0:0:2}  Arp::sProbe {
2013-08-12 14:19:51.688: [ USRTHRD][3418347264]{0:0:2} Arp::sSend:  sending type 1
2013-08-12 14:19:51.688: [ USRTHRD][3418347264]{0:0:2}  Arp::sProbe }
2013-08-12 14:19:52.339: [ora.crf][3899438848]{0:0:2} [check] clsdmc_respget return: status=0, ecode=0
2013-08-12 14:19:52.339: [ora.crf][3899438848]{0:0:2} [check] Check return = 0, state detail = NULL
2013-08-12 14:19:52.713: [ USRTHRD][3418347264]{0:0:2}  Arp::sProbe {
2013-08-12 14:19:52.713: [ USRTHRD][3418347264]{0:0:2} Arp::sSend:  sending type 1
2013-08-12 14:19:52.713: [ USRTHRD][3418347264]{0:0:2}  Arp::sProbe }
2013-08-12 14:19:52.713: [ USRTHRD][3418347264]{0:0:2} Transitioning to Announce State
2013-08-12 14:19:54.718: [ USRTHRD][3418347264]{0:0:2}  Arp::sAnnounce {
2013-08-12 14:19:54.718: [ USRTHRD][3418347264]{0:0:2} Arp::sSend:  sending type 1
2013-08-12 14:19:54.718: [ USRTHRD][3418347264]{0:0:2}  Arp::sAnnounce }
[  clsdmc][3406784256]CLSDMC.C returnbuflen=8, extraDataBuf=E6, returnbuf=9801CEA0
2013-08-12 14:19:56.632: [ora.ctssd][3406784256]{0:0:2} [check] clsdmc_respget return: status=0, ecode=0, returnbuf=[0x7f8a9801cea0], buflen=8
2013-08-12 14:19:56.632: [ora.ctssd][3406784256]{0:0:2} [check] translateReturnCodes, return = 0, state detail = OBSERVERCheckcb data [0x7f8a9
801cea0]: mode[0xe6] offset[2 ms].
2013-08-12 14:19:56.720: [ USRTHRD][3418347264]{0:0:2}  Arp::sAnnounce {
2013-08-12 14:19:56.720: [ USRTHRD][3418347264]{0:0:2} Arp::sSend:  sending type 1
2013-08-12 14:19:56.720: [ USRTHRD][3418347264]{0:0:2}  Arp::sAnnounce }
2013-08-12 14:19:56.720: [ USRTHRD][3418347264]{0:0:2} Transitioning to Defend State
2013-08-12 14:19:57.220: [ USRTHRD][3418347264]{0:0:2} VipActions::startIp {
2013-08-12 14:19:57.220: [ USRTHRD][3418347264]{0:0:2} Adding 169.254.79.164 on eth1:1
2013-08-12 14:19:57.220: [ USRTHRD][3418347264]{0:0:2} VipActions::startIp }
2013-08-12 14:19:57.221: [ USRTHRD][3418347264]{0:0:2} Assigned IP:  169.254.79.164 on interface eth1
2013-08-12 14:19:57.677: [ USRTHRD][3420448512]{0:0:2} Thread:[NetHAWork]stop {
2013-08-12 14:19:57.695: [ USRTHRD][3395221248]{0:0:2} [NetHAWork] thread stopping
2013-08-12 14:19:57.695: [ USRTHRD][3395221248]{0:0:2} Thread:[NetHAWork]isRunning is reset to false here
2013-08-12 14:19:57.695: [ USRTHRD][3420448512]{0:0:2} Thread:[NetHAWork]stop }
2013-08-12 14:19:57.695: [ USRTHRD][3420448512]{0:0:2} VipActions::stopIp {
2013-08-12 14:19:57.695: [ USRTHRD][3420448512]{0:0:2} NetInterface::sStopIp {
2013-08-12 14:19:57.695: [ USRTHRD][3420448512]{0:0:2} Stopping ip '169.254.79.164', inf 'eth2', mask '192.168.1.0'
2013-08-12 14:19:57.695: [ USRTHRD][3420448512]{0:0:2} Stopping ip 169.254.79.164 on inf eth2:2
2013-08-12 14:19:57.695: [ USRTHRD][3420448512]{0:0:2} NetInterface::sStopIp }
2013-08-12 14:19:57.695: [ USRTHRD][3420448512]{0:0:2} VipActions::stopIp }
2013-08-12 14:19:57.710: [ USRTHRD][3420448512]{0:0:2} IptoClean '169.254.0.1', ip '169.254.0.0', mask '255.255.128.0'
2013-08-12 14:19:57.710: [ USRTHRD][3420448512]{0:0:2} USING HAIP[  0 ]:  eth1 - 169.254.79.164
2013-08-12 14:19:57.710: [ USRTHRD][3420448512]{0:0:2} USING HAIP[  1 ]:  eth2 - 169.254.135.126

 

而cssd.log日志中有相應的adding interface information等內容。

說明： 整理於網絡


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 Oracle 11g RAC之HAIP相關問題總結 在Oracle中，RAC中的Public IP、Private IP、Virtual IP、SCAN IP、GNS VIP及HAIP的作用分別是什么？ 在Oracle中，RAC中的Public IP、Private IP、Virtual IP、SCAN IP、GNS VIP及HAIP的作用分別是什么？ RAC配置2個私網網卡使用HAIP服務 HAIP異常，導致RAC節點無法啟動的解決方案 在oracle 12c上如何禁用haip，以及打開haip，以及對haip的理解 Oracle Haip無法啟動問題學習 Oracle RAC負載均衡 Oracle RAC（Linux）搭建 Oracle RAC與DG
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM