RAC架構中public網路卡down後發生什麼和RAC如何自愈？

導讀：privdate網路卡down後，rac會發生腦裂。public網路卡down後，會發生什麼呢？public網路卡恢復後，rac又是如何自愈的呢？故事的起因：早上5:42左右收到資料庫伺服器bmcdb2無法連結的告警，5:48左右自動恢復了。這短短10分鐘內究竟發生了什麼？接下來我們就分析一下。

1.環境簡介

資料庫版本
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production
伺服器版本
# oslevel -s
7200-02-02-1810

2.分析原因

2.1 當前狀態服務是否正常，確認業務已恢復

2.1.1 叢集資源與db狀態

crsctl stat res -t
bmcdb2:/home/grid$crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.ARCH.dg
               ONLINE  ONLINE       bmcdb1
               ONLINE  ONLINE       bmcdb2
ora.DATA.dg
               ONLINE  ONLINE       bmcdb1
               ONLINE  ONLINE       bmcdb2
ora.LISTENER.lsnr
               ONLINE  ONLINE       bmcdb1
               ONLINE  ONLINE       bmcdb2
ora.OCR.dg
               ONLINE  ONLINE       bmcdb1
               ONLINE  ONLINE       bmcdb2
ora.asm
               ONLINE  ONLINE       bmcdb1                   Started
               ONLINE  ONLINE       bmcdb2                   Started
ora.gsd
               OFFLINE OFFLINE      bmcdb1
               OFFLINE OFFLINE      bmcdb2
ora.net1.network
               ONLINE  ONLINE       bmcdb1
               ONLINE  ONLINE       bmcdb2
ora.ons
               ONLINE  ONLINE       bmcdb1
               ONLINE  ONLINE       bmcdb2
ora.registry.acfs
               ONLINE  ONLINE       bmcdb1
               ONLINE  ONLINE       bmcdb2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       bmcdb1
ora.bmcdb.db
      1        ONLINE  ONLINE       bmcdb1                   Open
      2        ONLINE  ONLINE       bmcdb2                   Open
ora.bmcdb1.vip
      1        ONLINE  ONLINE       bmcdb1
ora.bmcdb2.vip
      1        ONLINE  ONLINE       bmcdb2
ora.cvu
      1        ONLINE  ONLINE       bmcdb1
ora.oc4j
      1        ONLINE  ONLINE       bmcdb1
ora.scan1.vip
      1        ONLINE  ONLINE       bmcdb1
--當前狀態均是ok的

2.1.2 資料庫的連線是否正常

監聽狀態和持續產生的listener.log必須都ok，才是正常的
bmcdb2:/home/grid$lsnrctl status
......
Alias                     LISTENER
Version                   TNSLSNR for IBM/AIX RISC System/6000: Version 11.2.0.4.0 - Production
Start Date                01-JUL-2022 05:47:09
Uptime                    0 days 4 hr. 56 min. 5 sec ==》重啟過
.....
bmcdb1:/home/grid$lsnrctl status
......
Alias                     LISTENER
Version                   TNSLSNR for IBM/AIX RISC System/6000: Version 11.2.0.4.0 - Production
Start Date                26-MAY-2022 20:50:02
Uptime                    35 days 13 hr. 52 min. 59 sec
......
--當前listener狀態是ok的，值得注意點是bmcdb2監聽重啟過。
--當前listener.log有持續日誌產生這裡就不列出來，說明當前listener對外服務正常。

2.1.3 資料庫讀寫是否正常

#資料庫檔案寫入正常才ok。簡單測試一下：logfile,archivelog,datafile寫入均ok，才是正常的
多次執行
alter system switch logfile;
說明日誌切換正常，歸檔切換正常
多次執行
alter system checkpoint;
說明資料從database buffer cache寫入datafile正常

2.1.4 此時已證明資料庫服務狀態正常，業務已恢復

# 業務即已恢復，就不緊張了。接下來我們來分析短短10分鐘內，為什麼bmcdb2不能建立連線，然後又自動恢復了呢？

2.2 分析問題，我們採用FTA分析法來進行排查（主要是伺服器、叢集、網路）

2.2.1 伺服器相關錯誤資訊剖析

 伺服器是否重啟：last reboot
--結果：無重啟資訊
 伺服器告警：erpprt | more
# errpt | more
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
8650BE3F   0701054722 I H ent13          ETHERCHANNEL RECOVERY
42F2355C   0701054722 T H ent4           PROBLEM RESOLVED
F1814D51   0701054622 T H ent4           ETHERNET DOWN
42F2355C   0701054622 T H ent4           PROBLEM RESOLVED
11FDF493   0701054622 I H ent13          ETHERCHANNEL RECOVERY
42F2355C   0701054622 T H ent5           PROBLEM RESOLVED
B50A3F81   0701054622 P H ent13          TOTAL ETHERCHANNEL FAILURE
F1814D51   0701054622 T H ent5           ETHERNET DOWN
59224136   0701054622 P H ent13          ETHERCHANNEL FAILOVER
42F2355C   0701054622 T H ent5           PROBLEM RESOLVED
CE9566DF   0701053922 P H ent13          TOTAL ETHERCHANNEL FAILURE
F1814D51   0701053922 T H ent4           ETHERNET DOWN
F1814D51   0701053922 T H ent5           ETHERNET DOWN
E87EF1BE   0630150022 P O dumpcheck      The largest dump device is too small.
--結果：公有網路卡ent13出現短暫的故障，然後恢復
05:39：ent4和ent5網路卡down，然後公共網路卡ent13故障
05:46：ent5和ent4網路卡先後恢復
05:47：公有網路卡ent3恢復
## 伺服器分析結果：bmcdb2出現過短暫網路卡故障
## 這裡有一個疑點：2個網路卡同時出現故障，推測是網路卡上線交換機故障，若交換機故障連線在他上面的埠均會在同一個時間內出現故障

2.2.2 叢集相關資訊剖析

## crs alert log
節點bmcdb1
2022-07-01 05:39:04.720:
[crsd(6619772)]CRS-2765:Resource 'ora.net1.network' has failed on server 'bmcdb2'.
2022-07-01 05:39:05.896:
[crsd(6619772)]CRS-2878:Failed to restart resource 'ora.net1.network'
2022-07-01 05:39:05.930:
[crsd(6619772)]CRS-2769:Unable to failover resource 'ora.net1.network'.
--結果，發現bmcdb2的ora.net1.network資源無法管理
節點bmcdb2
--結果，crs alert log無告警日誌
## crs alert log分析結果：節點bmcdb2這個伺服器的ora.net1.network資源異常，結合伺服器網路卡故障資訊，推薦出是因為網路卡故障導致了ora.net1.network資源異常，進而導致vip故障轉移
 
## crsd log
節點bmcdb1
--節點bmcdb1的crsd日誌還是很豐富的。透過crsd日誌過程，我們可以分析出rac的vip故障轉移和vip自愈機制
透過crsd日誌分析RAC故障轉移和自愈機制。
1）發現問題：ora.net1.network bmcdb2當前是offline，RAC嘗試將其online
2）處理過程
 2.1 嘗試透過crs命令在bmcdb2啟動ora.net1.network資源
2022-07-01 05:39:04.774: [   CRSPE][11824]{0:5:6936} CRS-2672: Attempting to start 'ora.net1.network' on 'bmcdb2'
 2.2 嘗試失敗
2022-07-01 05:39:05.881: [   CRSPE][11824]{0:5:6936} CRS-2674: Start of 'ora.net1.network' on 'bmcdb2' failed
 2.3 並通知crs資源啟動失敗
2022-07-01 05:39:05.882: [   CRSPE][11824]{0:5:6936} Sequencer for [ora.net1.network bmcdb2 1] has completed with error: CRS-0215: Could not start resource 'ora.net1.network'.
 2.4 既然不能管理此項資源，name進行故障轉移操作。先停止bmcdb2伺服器上與ora.net1.network相關的資源。即停止ons和listener
2022-07-01 05:39:05.935: [   CRSPE][11824]{0:5:6936} CRS-2673: Attempting to stop 'ora.ons' on 'bmcdb2'
2022-07-01 05:39:05.936: [   CRSPE][11824]{0:5:6936} CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'bmcdb2'
2022-07-01 05:39:06.177: [   CRSPE][11824]{0:5:6936} CRS-2677: Stop of 'ora.ons' on 'bmcdb2' succeeded
2022-07-01 05:39:07.314: [   CRSPE][11824]{0:5:6936} CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'bmcdb2' succeeded
2022-07-01 05:39:07.316: [   CRSPE][11824]{0:5:6936} CRS-2673: Attempting to stop 'ora.bmcdb2.vip' on 'bmcdb2'
2022-07-01 05:39:08.375: [   CRSPE][11824]{0:5:6936} CRS-2677: Stop of 'ora.bmcdb2.vip' on 'bmcdb2' succeeded
 2.5 vip故障轉移操作，但請注意vip，ons雖然偏移了，但是本地listener是不會偏移的。所以沒有嘗試在bmcdb2啟動listener。
# 所以這裡也說明一點，vip在故障轉移中只是快速轉移的效果，但不具備服務轉移的能力。他可以透過ons很快的反饋給客戶端故障機器的vip已偏移，請客戶端速度做出故障轉移的動作。
2022-07-01 05:39:08.379: [   CRSPE][11824]{0:5:6936} CRS-2672: Attempting to start 'ora.bmcdb2.vip' on 'bmcdb1'
2022-07-01 05:39:11.023: [   CRSPE][11824]{0:5:6936} CRS-2676: Start of 'ora.bmcdb2.vip' on 'bmcdb1' succeeded
2022-07-01 05:47:05.954: [   CRSPE][11824]{0:5:6940} CRS-2672: Attempting to start 'ora.ons' on 'bmcdb2'
## 此時到這裡vip的轉移已完成。配合客戶端故障轉移配置。新進業務會嘗試連線活著的伺服器，進而完成rac外服務
3）當伺服器服務網路卡恢復後，rac又是如何自愈的？
 3.1 通知CRS節點bmcdb2資源ora.net1.network已恢復
2022-07-01 05:47:05.917: [   CRSPE][11824]{0:5:6940} State change received from bmcdb2 for ora.net1.network bmcdb2 1
2022-07-01 05:47:05.917: [   CRSPE][11824]{0:5:6940} Processing PE command id=365. Description: [Resource State Change (ora.net1.network bmcdb2 1) : 110f60070]
2022-07-01 05:47:05.917: [   CRSPE][11824]{0:5:6940} RI [ora.net1.network bmcdb2 1] new external state [ONLINE] old value: [OFFLINE] on bmcdb2 label = []
2022-07-01 05:47:05.917: [   CRSPE][11824]{0:5:6940} Processing unplanned state change for [ora.net1.network bmcdb2 1]
2022-07-01 05:47:05.918: [  CRSRPT][12081]{0:5:6940} Published to EVM CRS_RESOURCE_STATE_CHANGE for ora.net1.network
2022-07-01 05:47:05.952: [   CRSPE][11824]{0:5:6940} Op 112093c70 has 5 WOs
2022-07-01 05:47:05.954: [   CRSPE][11824]{0:5:6940} RI [ora.ons bmcdb2 1] new internal state: [STARTING] old value: [STABLE]
2022-07-01 05:47:05.954: [   CRSPE][11824]{0:5:6940} Sending message to agfw: id = 1328819
 3.2 嘗試在bmcdb2啟動ons，得到嘗試啟動vip的命令後ons才會啟動成功
2022-07-01 05:47:05.954: [   CRSPE][11824]{0:5:6940} CRS-2672: Attempting to start 'ora.ons' on 'bmcdb2'
 3.3 嘗試在bmcdb1停止vip併成功
2022-07-01 05:47:06.021: [   CRSPE][11824]{2:36251:309} CRS-2673: Attempting to stop 'ora.bmcdb2.vip' on 'bmcdb1'
2022-07-01 05:47:07.099: [   CRSPE][11824]{2:36251:309} CRS-2677: Stop of 'ora.bmcdb2.vip' on 'bmcdb1' succeeded
 3.4 嘗試在bmcdb2啟動vip，然後ons先啟動成功，然後vip再次啟動成功
2022-07-01 05:47:07.102: [   CRSPE][11824]{2:36251:309} CRS-2672: Attempting to start 'ora.bmcdb2.vip' on 'bmcdb2'
2022-07-01 05:47:07.207: [   CRSPE][11824]{0:5:6940} CRS-2676: Start of 'ora.ons' on 'bmcdb2' succeeded
22-07-01 05:47:09.806: [   CRSPE][11824]{2:36251:309} CRS-2676: Start of 'ora.bmcdb2.vip' on 'bmcdb2' succeeded
 3.5 嘗試恢復listener
2022-07-01 05:47:09.822: [   CRSPE][11824]{2:36251:309} CRS-2672: Attempting to start 'ora.LISTENER.lsnr' on 'bmcdb2'
2022-07-01 05:47:11.681: [   CRSPE][11824]{2:36251:309} CRS-2676: Start of 'ora.LISTENER.lsnr' on 'bmcdb2' succeeded
## 至此，rac自愈完成。真的很強大
節點bmcdb2
--節點bmcdb2的crsd log忽略

2.3 網路相關分析

 2.3.1 分析：透過上面的分析我們得知因為網路卡故障導致，rac故障轉移；10分鐘內，網路卡恢復，rac自愈完成。一臺伺服器2個網路卡同時故障，最有可能的故障就是交換機故障。
 2.3.2 落實：透過諮詢網路同事，發現故障時間段內交換機發生過重啟故障。這樣就詮釋了為什麼兩個網路卡同時故障，同時恢復的原因。

3.故障分析結果

3.1 rac架構中public故障後會發生vip故障轉移。rac架構中public故障後過程分析：
網路卡故障，ora.net1.network資源異常，ons資源異常，vip故障轉移，listener異常
3.2 rac架構中public恢復後rac會發生rac自愈，vip偏移回原始節點。rac架構中public恢復後過程分析：
網路卡恢復，ora.net1.network正常，vip正常，ons正常，listener正常
3.3 一臺伺服器兩個網路卡同時損壞，是交換機故障

########################################################################################

版權所有，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任!【QQ交流群：53993419】

QQ：14040928 E-mail：dbadoudou@163.com

本文連結： http://blog.itpub.net/26442936/viewspace-2903833/

########################################################################################