這么用X86，小心ORACLE+RAC中招--技術人生系列第四十一期-我和數據中心的故事

最近有朋友和小 y 反饋：

他們的一臺 IBM 的 X86 服務器（現在屬于聯想）出現硬件損壞，維護人員通過管理口收集診斷日志給廠商時，服務器上運行的好好的一套 ORACLE 11.2 的 RAC 數據庫，

突然有一個節點重啟了 .. 這是是什么情況 ? 

聽到這里，小 y 基本上猜到了原因，類似的問題，以前分析和處理過幾次，分析過程也不復雜， 但是沒想到，類似的故障現在居然還在發生 .

因此有必要把這個 風險提示出來 !

這里，小 y 為大家分享一個過去處理的案例 , 文章最后會給出 X86 服務器與 RAC 結合的具體的風險提示，希望大家早了解，早預防，避免踩坑，傷人傷己。

周五，晚上十一點，電話響了，是一位服務商的電話，看來出大事了，一下來了精神;

BTW：

是的，大家沒看錯，是服務商而不是最終客戶的電話。

小y所在的公司不僅直接面向客戶提供數據庫專家服務，也為其他服務商、軟件開發商提供三線支持，不過小y最近業績壓力大的晚上睡不著覺，還請各位兄弟多多幫忙推薦和介紹啊。

分析與恢復故障

時間緊急，遠程連入后，發現節點 2 確實掛掉了，那就直接 startup 啟動數據庫看看

照理來說，startup命令下去后，這里很快就可以看到SGA分配并啟動到mount的信息，

但命令下去已經一分鐘了，還沒任何輸出，確實不妙。

最終，startup命令在敲入后長時間依然無響應，大概10分鐘后后報ORA-03113錯誤后退出。

如下圖所示：

看來，數據庫啟動過程中遇到了異常，需要繼續分析alert日志。  

截取altert日志關鍵信息，如下圖所示：

可以看到：

由于節點 2 的 Lmon 進程通過 ipc 與節點 1 的 LMON 進程通訊超時，簡單來說，兩個節點的 RAC 無法通訊，因此無法加入集群。因此需要進一步檢查兩個節點的私網通訊是否正常。

之前他們提到兩個節點的私網 IP 是可以 ping 通的，我估計他們是 ping 錯 IP 了。

因為，從 11.2.0.2 （含）開始， ORACLE 私網通訊不再直接采用“我們在私網網卡上所配置的地址（例如 192.168 這樣的地址）”，而是采用 GRID 啟動后， ORACLE 在私網網卡上綁定的 169.254 這個網段的地址。確認了一下，他們果然 ping 的是 192.168 這個 IP ，這個 IP 能 PING 通是不夠的 …

發出下列命令獲得，兩個節點私網通訊采用的 IP 地址如下所示:

也就是說， RAC 兩個節點用于私網通訊的真實地址是：

節點 1 采用的私網通訊地址是 169.254.220.75 ，而不是 192.168.x.x

節點 2 采用的私網通訊地址是 169.254.106.133 ，而不是 192.168.x.x

也就是說， GRID 啟動前后的 IP ，如下所示：

從上圖可以看到：

兩個節點之間互相 ping 不通 169.254 這個實際的私網通訊地址！這就是為什么節點 2 的數據庫實例加不到集群的原因！

到這里，我們不妨用一張表表格小結一下：

其中 bond0 是私網網卡， 192.168 是手工配置的， 169.254 這個 IP 是 GRID 起來后綁上去的:

這是什么情況呢？

其實很簡單，別著急，問題原因就在后面，什么時候往下翻，由你決定…

……

……

……

……

……

……

……

……

……

……

……

……

……

……

……

……

那是什么原因導致兩個地址不通呢？

我們進一步檢查兩個節點的路由情況，發現了異常。如下所示

檢查，發現節點 1 上的私網路由丟失，導致兩個節點之間的私網無法正常通訊，繼而無法正常加入集群。

而節點 2 上是存在 169.254 這個路由的！

在節點 1

#route add -net 169.254.0.0 netmask  255.255.0.0 dev bond1

在節點 1 上實施該解決方案后，節點 2 數據庫實例啟動正常，問題得到解決。

因為重啟 GRID ，會重新在 bond0 綁 169.254 這個 IP ，同時添加 169.254.0.0 這個路由

2016-06-02 23:05:47.457:

[crsd(10403)]CRS-2772:Server 'node2' has  been assigned to pool 'ora.RACDB'.

2016-06-03 19:36:48.517:

[/oracle/app/11.2.0.3/grid/bin/orarootagent.bin(8641)]CRS-5018:(:CLSN00037:)

1)         19:36:25,  節點 1 USB0 網卡被分配 169.254.95.120 這個 IP

2)         19:36:48,  節點 1 orarootagent 進程發現 USB0 上分配的 169.254 IP 與 RAC 集群通訊的 IP 沖突后刪除 169.254 的路由   ，導致兩個節點 RAC 無法通訊

3)         19:41:24,  節點 2  報 IPC  通訊超時，被驅逐出集群

4)         由于節點 1 的 169.254 的路由丟失，導致節點 2  無法與節點 1 通訊，一直無法加入集群

5)         手工對節點 1 增加 169.254 的路由后，問題解決

 

不難看出來，這個行為是正常的行為！

我們以“ Removed unused HAIProute:  169.254.95.0 ”作為搜索關鍵字，在 METALINK 上查找， MOS 上的下面文章也介紹了這個行為，推測得到驗證。

Oracle RAC H/A Failure Causes Oracle Linux Node Eviction On Server With  IBM Integrated Management Module (IMM) (文檔 ID 1629814.1)

風險提示

風險提示

在部署了 ORACLE11.2.0.2 或以上的版本中

由于集群的 ASM 和 DB 使用 169.254.x.x 作為集群私網通訊的 IP

【 GRID 啟動后在私網網卡綁定 169.254.x.x 這個 IP 并添加 169.254.0.0 的路由】

 

目前已知的情況中， IBM X86 服務器裝完操作系統后，存在 USB0 這樣一塊網卡，這個網卡是用來和 IMM 通訊的， IMM 是服務器的管理口，通過 USB 網絡的 LAN 進行硬件管理。

當 USB0 網卡被激活時，將分配 169.265.95.120 （ 118 ）這個 IP ，將導致 RAC 集群路由被破壞，繼而導致 DB/ASM 無法通訊而重啟 / 節點驅逐的故障 ,

#cat  /var/log/messages*|grep dhclient |grep "bound to 169.254"

如有，則進入預防環節

2 ） 發出下列命令，檢查系統是否當前存在非 RAC 私有網卡被分配 169.254 這個網段的 IP

# ifconfig -a .. usb0     Link  encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX         # vi # /sbin/ifdown  usb0 # /sbin/ifup usb0 # /sbin/ifconfig  usb0

 

本文轉載于中亦安圖