IP packet reassembles failed導致例項被驅逐

n   資料庫第二個節點被驅逐出叢集，並且多次自動重啟以失敗告終

驅逐原因在GI Alert log顯示是私網通訊丟失，而重啟失敗也是因為ASM無法啟動，ASM db alert顯示IPC Send timeout.  當時ping和tracert並沒發現什麼異常，從OSW中的netstat -s檢視IP packet reassembles failed時間段值大量增長， 這是一套oracle 11.2.0.4 2Nodes RAC on RHEL 6.6的環境，另個每個資料庫伺服器CPU核數過百， 這個案例有多種巧合,如果CPU只有幾個，問題也可能不會發生，如果是RHEL7也不會發生等等。當然最終以調速OS引數解決，但是原因更值得分析。

Node1 GI ALERT LOG

2017-03-02 11:46:26.607:

[/u01/11.2.0/grid/bin/oraagent.bin(121496)]CRS-5011:Check of resource "testdb" failed: details at "(:CLSN00007:)" in "/u01/11.2.0/grid/log/anbob/agent/crsd/oraagent_oracle//oraagent_oracle.log"

2017-03-02 11:46:26.612:

[crsd(175117)]CRS-2765:Resource 'ora.testdb.db' has failed on server 'anbob'.

2017-03-02 11:46:42.866:

[cssd(172139)]CRS-1612:Network communication with node db2 (2) missing for 50% of timeout interval.  Removal of this node from cluster in 14.620 seconds

2017-03-02 11:46:50.869:

[cssd(172139)]CRS-1611:Network communication with node db2 (2) missing for 75% of timeout interval.  Removal of this node from cluster in 6.620 seconds

2017-03-02 11:46:54.870:

[cssd(172139)]CRS-1610: Network communication with node db2 (2) missing for 90% of timeout interval.  Removal of this node from cluster in 2.620 seconds

2017-03-02 11:46:57.493:

[cssd(172139)]CRS-1607:Node db2 is being evicted in cluster incarnation 351512591; details at (:CSSNM00007:) in /u01/11.2.0/grid/log/anbob/cssd/ocssd.log.

2017-03-02 11:46:58.626:

[cssd(172139)]CRS-1662:Member kill requested by node db2 for member number 0, group DBHBCRM

 

Node2 GI ALERT LOG

2017-03-02 11:46:45.378:

[cssd(177450)]CRS-1663:Member kill issued by PID 84816 for 1 members, group DBCRM. Details at (:CSSGM00044:) in /u01/11.2.0/grid/log/db2/cssd/ocssd.log.

2017-03-02 11:46:58.982:

[cssd(177450)]CRS-1608:This node was evicted by node 1, anbob; details at (:CSSNM00005:) in /u01/11.2.0/grid/log/db2/cssd/ocssd.log.

2017-03-02 11:46:58.983:

[cssd(177450)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /u01/11.2.0/grid/log/db2/cssd/ocssd.log 

node2 因網路通訊失敗而自殺 member kill.

* allocate domain 7, invalid = TRUE

 * domain 7 valid = 1 according to instance 1

 Master broadcasted resource hash value bitmaps

 Non-local Process blocks cleaned out

 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived

 Set master node info

 Submitted all remote-enqueue requests

 Dwn-cvts replayed, VALBLKs dubious

 All grantable enqueues granted

Thu Mar 02 11:54:14 2017

IPC Send timeout detected. Sender: ospid 153935 [oracle@db2 (LMD0)]

Receiver: inst 1 binc 430132771 ospid 174276

IPC Send timeout to 1.0 inc 92 for msg type 65521 from opid 10

Thu Mar 02 11:54:16 2017

Communications reconfiguration: instance_number 1

Thu Mar 02 11:54:16 2017

Dumping diagnostic data in directory=[cdmp_20170302115416], requested by (instance=1, osid=174274 (LMON)), summary=[abnormal instance termination].

Reconfiguration started (old inc 92, new inc 96)

List of instances:

 2 (myinst: 2)

 Nested reconfiguration detected.

 Global Resource Directory frozen

* dead instance detected - domain 1 invalid = TRUE

freeing rdom 1

* dead instance detected - domain 2 invalid = TRUE

freeing rdom 2

NODE2 的ASM因ipc time out失敗一直未啟動。

Node2 OSW netsat 資訊

zzz ***Thu Mar 2 11:40:31 CST 2017

75646 packet reassembles failed

zzz ***Thu Mar 2 11:40:52 CST 2017

77043 packet reassembles failed

zzz ***Thu Mar 2 11:46:33 CST 2017

131134 packet reassembles failed

這段時間產生了大量的IP packet reassembles failed. 彙總統計了之前的時間裡是不存在這個問題的。

當然到這裡如果你以以上資訊為關鍵字在MOS中應該已經可以找到解決方案RHEL 6.6: IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1)。在NOTE中記錄是因為OS過多的IP包重組失敗導致，解決方法是加大重組的BUFFER大小或啟用jumbo frame，對於jumbo frame需要硬體的支援，簡單的就是增加network IP 重組buffer的大小。如RHEL 6.6中的

net.ipv4.ipfrag_high_thresh = 16M     --default 4M

net.ipv4.ipfrag_low_thresh = 15M       -- default 3M

 

通常預設的應該滿足基本需求的，像上面的調整在ORACLE的RHEL的最佳實踐中也並未建議安裝裡調整，那後續的LINUX平臺都要調整該引數麼？ 帶著這個問題我查開了LINUX 7.2的核心引數

[root@MiWiFi-srv ~]# sysctl -a|grep ipfrag

net.ipv4.ipfrag_high_thresh = 4194304

net.ipv4.ipfrag_low_thresh = 3145728

net.ipv4.ipfrag_max_dist = 64

net.ipv4.ipfrag_secret_interval = 600

net.ipv4.ipfrag_time = 30

 

如果是引數配置不是最佳，為什麼LINUX最新版並未改變，連ORACLE軟體也沒建議修改？ 那我們可以再深入研究一些。

  什麼是 IP packet reassembles failed ？

在linux平臺使用netstat -s命令時會看到packet reassembles failed項， 記錄的是IP重組包失敗的累計資料值，什麼時候要重組呢？當IP包通訊存在碎片時。在網路通訊協議中MTU（最大傳輸單元）限制了每次傳輸的IP 包的大小，一種是源端和目標端使用了不同的MTU時會交生碎片，這裡需要先確認傳輸過程中的MTU大小配置，確認使用了相同的MTU；還有就是當傳送的資料大於MTU時，回分成多個分片傳遞。這時調整MTU就不可能解決所有的IP包碎片的問題，可以透過加大通訊的buffer值，儘可能保留更多的資料在源端拆包，目標端快取等接收完整後再重組校驗。 在LINUX系統中調整BUFFER使用ipfrag_low_thresh 和ipfrag_high_thresh引數，如果調整了這個引數仍有較大的重組失敗還可以加大ipfrag_time 引數控制IP 碎片包在記憶體中保留的秒數時間。

如果在ORACLE RAC環境中一個節點突然產生了大量的資料包輸送給另一個節點，如應用設計問題，如資料檔案cache fusion或歸檔只能一個節點訪問時,都加大了網路通訊量，這裡需要檢查網路負載及丟包或包不一致的現象，因為ORACLE在網路通訊中使用了UDP和IP通訊協議，這兩類資訊都需要關注。

那是不是LINUX所有的系統都需要調整上面的引數呢？

不是的， 從RHEL瞭解這個問題基本也就出現在LINUX6.6，和部分6.7中，這個問題的根本原因是在linux6.6中引入了percpu counters計數器在核心 kernel-2.6.32-477.el6， 在後面的linux 6.8(kernel-2.6.32-642.el6)和linux 6.7.x(kernel-2.6.32-573.8.1.el6)已經修復了該問題， 所以在其它配置中沒有影響。
這個計數器是在每個CPU上一個，當CPU多時很容易超過預設的4M ipfrag_high_thresh， 所以這也是就是我一開始說的CPU多了也是這個問題的巧合，當網路傳輸大里更容易超過，而產生faild.

  Summary:

當資料庫的某種場景觸發了大量的資料在節點間傳送， 剛好又是LINUX 6.6核心的一個bug, 剛好這又是一臺CPU非常多的伺服器，觸發了這次的IPC TIMEOUT和IP包重組失敗， 導致的私網資料包丟失，節點2被驅逐。解決方法可以通常調整作業系統引數，加大IP包buffer大小，儘可能的減少IP packet reassembles failed。無系統不網路，DBA也應該有所瞭解，希望對你有幫助。