oracle之 RAC Interconnect之HAIP

張衝andy發表於2017-09-14
OracleAI

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地址的以及link localaddress, 並且早已經被RFC標準化——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地址已經進行了透明的偏移。
[參考 ]

 

檢視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等內容。

說明： 整理於網路

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31383567/viewspace-2144960/，如需轉載，請註明出處，否則將追究法律責任。

相關文章