【Oracle 12c Flex Cluster 】Leaf Node的故障遷移

Oracle 在12c中使用hub-and-spoken技術實現了Flex Cluster的功能(即RAC集羣中的每個節點不再需要既運行ASM實例又運行DB實例，各節點可以扮演不同的角色)。相比12c以前的版本，該功能使集羣規模的擴大和縮減變得更加靠譜。原因如下：

• 集羣中各節點間網絡的互相干擾變得更少。
• 關鍵的集羣組件爭用更少，如OCR、VOTING DISK。

一個Flex Cluster中可以包含兩類節點，分別是hub node和leaf node。

Hub Node

• 這種節點幾乎完全等價於12c以前版本的傳統RAC節點，在12c中這種節點就是集羣的核心(爲什麼說是核心呢？因爲後面會介紹12c flex cluster中的非核心節點——leaf node)。
• 每個hub node之間通過私網連接，而且需要配置ssh對等性。
• 每個節點需要訪問共享存儲，因爲ocr voting都依賴於共享存儲。
• hub node上既運行ASM實例又運行db實例。
• 每個flex cluster至少一個hub node最多64個hub node。

Leaf Node

• 相比hub node，leaf node對於集羣來說不是那麼核心，與集羣耦合度很低，而且leaf node之間不需要互聯。

• 每個leaf node通過一個hub node連接集羣並獲取數據。

• 雖然leaf node不要求直接訪問共享存儲，但最好還是連上共享存儲，因爲說不準未來哪天就要把這個leaf node轉爲hub node使用。

譯者注：雖然leaf node啓動集羣件是不依賴共享存儲的，但當leaf node以只讀打開了某數據庫時，也就是這個leaf node上運行着數據庫實例時，這個leaf node就變成了reader node，官方明確說了reader node是必須連接共享存儲的。官方連接：http://docs.oracle.com/database/122/RILIN/running-database-instances-on-leaf-nodes.htm#RILIN-GUID-35BDCD41-375D-4EB2-B0FC-49345AF6C572

• 他們上面運行着輕量版的集羣件。

• leaf node上面不能運行ASM實例，也不能在上面建庫，因爲上面運行的實例打開方式只能是隻讀的。

• leaf node上可運行多種應用，例如中間件、EBS、IDM等，leaf node上的應用會在leaf node掛掉後自動切換到其他leaf node。

• 一個flex cluster中可包含0個或多個leaf node。

• leaf node和hub node擁有相同的公網和私網。

即使flex cluster中沒有一個leaf node， hub node也可以正常的像傳統rac節點一樣工作。但如果flex cluster中只有leaf node沒有一個hub node是萬萬不可的，因爲leaf node需要通過hub node上的asm實例獲取數據。

當集羣件啓動在leaf node上時，leaf node就會根據GNS信息查找所有hub node，然後選擇其中一個hub node來獲取數據(配置GNS是使用leaf node的重要前提)。一個hub node同時可能被0個或多個leaf node連接，而一個leaf node同時只能連接一個hub node。hub node和leaf node之間也會交換心跳信息，只有這樣leaf node才能加入集羣並作爲集羣的一部分。

標準集羣可無痛轉換爲flex cluster，但flex cluster無法轉爲標準集羣，除非你重新配置(約等於重裝)。

當作爲集羣的一部分的某hub node掛了，將發生什麼？

當發生如下情況時，hub node會被從集羣中移除：

• 被驅逐
• 服務器關機
• 手動停止Oracle集羣件

這種情況發生時，連接着這個hub node的leaf node會自動挑一個活着的hub node來作爲數據源。 這篇文章中，我會論證：

• 如何確定leaf node連的是那個hub node?
• 當leaf node連接的hub node掛了後，這個leaf node如何進行故障遷移?

現狀：

爲了更好的闡述，我搭建瞭如下結構的12.1.0.2c的flex cluster：

• hub node
  
  • host01
  • host02
  • host03
• leaf node
  
  • host04
  • host05

論證：

確定hub node host01和leaf node host04是活着的：

[root@host01 log]# crsctl get node role status -all
Node 'host01' active role is 'hub'
Node 'host04' active role is 'leaf'

因爲當前host01是集羣中唯一活着的hub node，所以host04一定連的是host01。而且，host04的警告日誌中也可以證明這個事實：

這時啓動host02和host05：

[root@host01 log]# crsctl get node role status -all
Node 'host01' active role is 'hub'
Node 'host02' active role is 'hub'
Node 'host04' active role is 'leaf'
Node 'host05' active role is 'leaf'

爲了確定host05連得是那個hub node，我們看下ocssdrim進程的trace文件：

[root@host05 trace]#export ORACLE_BASE=/u01/app/grid
[root@host05 ~]# cat  $ORACLE_BASE/diag/crs/host05/crs/trace/ocssdrim.trc |grep 'Sending a ping msg to' | tail -1
2016-05-04 11:12:01.008283 :    CSSD:1086187840: clssbnmc_PeriodicPing_CB: Sending a ping msg to host host01, number 1, using handle (0x14055d0) last msg to hub at 4294948750, connection timeout at 11454, current time 4294951260]]

我們可以看到host05連得也是host01。

讓我們停掉host01上的集羣件，來確定所有leaf node都能故障切換到集羣中其他存活的hub node，在這裏就是host02：

[root@host01 log]# crsctl stop crs
[root@host02 ~]# crsctl get node role status -all
Node 'host02' active role is 'hub'
Node 'host04' active role is 'leaf'
Node 'host05' active role is 'leaf'

確定host04切到了host02：

[root@host04 ~]# cat  $ORACLE_BASE/diag/crs/host04/crs/trace/ocssdrim.trc |grep 'Destroying connection' | tail -1
2016-05-04 11:17:31.932770 :    CSSD:1085761856: clssbnmConnDestroy: Destroying connection object (0x1061200) for host host01

[root@host04 ~]# cat  $ORACLE_BASE/diag/crs/host04/crs/trace/ocssdrim.trc |grep 'Sending a ping msg to' | tail -1
2016-05-04 11:18:21.860771 :    CSSD:1085761856: clssbnmc_PeriodicPing_CB: Sending a ping msg to host host02, number 2, using handle (0x17e2fe0) last msg to hub at 1404044, connection timeout at 1434044, current time 1405324

確定host05切到了host02：

[root@host05 ~]# cat  $ORACLE_BASE/diag/crs/host05/crs/trace/ocssdrim.trc |grep 'Destroying connection' | tail -1
2016-05-04 11:17:31.873993 :    CSSD:1086187840: clssbnmConnDestroy: Destroying connection object (0x16979f0) for host host01

[root@host05 ~]# cat  $ORACLE_BASE/diag/crs/host05/crs/trace/ocssdrim.trc |grep 'Sending a ping msg to' | tail -1
2016-05-04 11:17:36.751628 :    CSSD:1086187840: clssbnmc_PeriodicPing_CB: Sending a ping msg to host host02, number 2, using handle (0x10950b0) last msg to hub at 318184, connection timeout at 348184, current time 319664

總結

• 12c引入的flex cluster有兩種節點，hub node和leaf node。
• 鑑於hub node可以訪問共享存儲，leaf node不直接訪問共享存儲，而是通過某個hub node連入集羣。
• 當leaf node上的集羣件啓動時，leaf node自動使用GNS來發現所有hub node，然後通過其中一個hub node連入集羣。
• 如果hub node掛了，那麼通過這個hub node訪問集羣的leaf node會自動切換至某存活的hub node繼續訪問集羣。

原文：http://allthingsoracle.com/oracle-flex-cluster-leaf-node-failover/
譯者：周天鵬
來源：沃趣科技（woqutech）