基於Oracle的私有云架構探析（連載二）

沃趣科技高階資料庫專家 魏興華

RAC One Node

根據整合的資料庫的SLA要求，還需要決定整合資料庫所選用的資料庫型別，在資料庫的型別上，11GR2版本之前，要不是單例項要不是RAC，單例項不具有HA的功能，只能做冷的HA，通過使用類似HACMP之類的軟體進行切換，有不可用時間，而且由於引入了第三方的HA軟體，讓整個架構、運維變得複雜，如果使用RAC架構，那麼對於資料庫整合來說，顯得有點資源浪費，RAC要求至少是雙節點，對於整合的資料庫來說，一般都是非核心庫，往往壓力不大，對於高可用的需求也沒有那麼高，因此使用RAC顯得有點浪費，那麼有沒有一種折中的方案呢？既然Oracle的ClusterWare一個很重要的功能就是為其上的資源提供監控、故障處理、故障切換服務，為什麼不能在ClusterWare之上跑單節點的RAC，然後在發生故障後對資源進行嘗試重啟，如果重啟不成功，在另外的節點再進行例項的拉起。RAC One Node就是這樣一種技術，顧名思義，RAC One Node是單節點的RAC，它跑在GI之上，通過GI基礎元件實現HA，藉助於GI叢集件，RAC One Node作為其上的資源在發生故障後，可以嘗試進行重啟或切換，這一切都會自動完成，而不需要人工干預。RAC One Node除了能做故障切換外，還可以實現有計劃性的線上漂移。漂移過程中，會階段性的存在2個例項，等舊例項上的事務都完成後會被關閉，然後新例項對外提供服務。客官可能會問，線上遷移有啥用？做了資料庫的整合後，一臺機器上可能跑的就是多個資料庫例項了，如果發現某些機器上的負載比較高，那麼就可以使用RAC One Node的線上遷移功能，把負載較高的主機上的一些例項線上的遷移到其他負載低的機器上。仔細想想，Oracle能做到這一點還挺不容易的，因為裡面涉及到了一些技術細節，只是你還沒認識到。11GR2之前，增加例項是一個複雜的過程：

線上漂移

資料庫一旦做了整合，一個主機之上就可能會有多個例項，例項之間可能會互相影響效能，如果DBA發現某臺主機上的負載較高，或者由於其他原因需要對RAC One Node進行節點遷移，就可以使用RAC One Node的線上漂移功能，DBA通過命令人為的把資料庫例項遷移到其他機器上執行，在遷移過中，RAC One Node會等待舊的例項上的事務完成，同時在目標機器上啟動一個新例項，在遷移這段時間內，會有兩個例項以active-active雙活的模式執行，當舊例項上的事務都完成後，這些連線會被轉移到新的例項上來，一旦所有的連線轉移工作都完成後，舊例項會被關閉，整個轉移過程也完成了。

RAC One Node的線上漂移時間視窗預設為30分鐘，在這段時間內，Oracle會等待舊例項上的事務完成，如果超過這個時間視窗後，還有事務未完成，那麼會被強制取消，例項也會被強制關閉，可以通過srvctl命令增加-w引數來增加或減少這個預設的時間視窗。

漂移的命令是通過srvctl來完成的，具體用法如下：

srvctl relocate database -d
{[-n ] [-w ]|-a [-r]} [-v]

其中的引數機器說明如下

●    -d：資料庫的名稱

●    -n：目標節點

●    -w：等待舊例項事務完成的時間視窗

●    -a：放棄失敗的線上漂移

下面給出一個線上漂移的例子，讓讀者更為直觀的感受一下線上漂移的過程。本例中會把oltp8從節點RAC2遷移到目標節點RAC1.首先觀察一下資料庫的當前狀態是否正常

srvctl status database -d oltp8
Instance oltp8_1 is running on node rac2
Online relocation: INACTIVE

oltp8為RAC One Node只有一個例項oltp8_1，當前執行在節點RAC2上，線上漂移的狀態為INACTIVE。接下來我們對RAC One Node進行線上漂移，這是通過srvctl的relocate語法來完成的

srvctl relocate database -d oltp8 -n rac1 -w 5

漂移過程中，另開一個會話觀察漂移的狀態

srvctl status database -d oltp8
Instance oltp8_1 is running on node rac2
Online relocation: ACTIVE
Source instance: oltp8_1 on rac2
Destination instance: oltp8_2 on rac1

輸出的資訊非常的詳細，oltp8_1這個例項正執行在RAC2上，ACTIVE關鍵字說明線上漂移也正在進行中，漂移的源端為RAC2，目標端為RAC1，並且目標端的例項名發生了變化：oltp8_2。

漂移完成後再檢視狀態，線上漂移狀態已經為INACTIVE，例項oltp8_2也已經執行在新的節點上了

srvctl status database -d oltp8
Instance oltp8_2 is running on node rac1
Online relocation: INACTIVE

這裡補充一個小細節，上面我已經提到過，這種線上漂移例項名是會發生變化，其實內部的操作就是在另外的節點幫我們自動的增加了一個例項，手工增加過例項的朋友都知道增加例項一般需要增加redo thread,增加undo表空間，那我們來看看，Oracle自動幫我們增加的例項有沒有幫我們來搞定這些事

                  
TABLESPACE_NAME     TOTAL_MBYTES  USED_MBYTES  FREE_MBYTES     PCT_FREE
------------------- ------------ ------------ ------------ ------------
SYSAUX                   1080.00      1021.69        58.31         5.39
UNDOTBS1               145.00        31.25       113.75        78.44
USERS                     5.00         1.69         3.31        66.25
SYSTEM                   810.00       802.81         7.19          .88
UNDOTBS2               25.00         2.44        22.56        90.25
WXH                        10.00         1.00         9.00        90.00
                    ------------ ------------ ------------
                         2075.00      1860.88       214.13

上面的內容顯示，有2個undo表空間，undotbs1 是之前oltp8_1例項用的，而undotbs2是新增加的。不過遺憾的是，這個undo表空間比較小，一般難以滿足我們的要求。這裡告訴大家一個小技巧，可以建立完RAC One Node後，手工增加undo表空間和redo thread，Oracle非常的智慧，下次做例項漂移，它會自動使用上你手工建立的這些redo thread和undo表空間了，而且大小也都符合你的要求。

SQL>select group#,thread# from v$Log;

    GROUP#    THREAD#
---------- ----------
     1      1
     2      1
     3      2
     4      2


SQL>select group#,member  from v$Logfile;

    GROUP# MEMBER
---------- -----------------------------------------------
     2 +OCRVOTE/OLTP8/ONLINELOG/group_2.265.907239997
     1 +OCRVOTE/OLTP8/ONLINELOG/group_1.256.907239995
     3 +OCRVOTE/OLTP8/ONLINELOG/group_3.264.907240291
     4 +OCRVOTE/OLTP8/ONLINELOG/group_4.263.907240291

同樣,redo thread也都幫我們建立好了，包括對應的日誌檔案。

故障切換

RAC One Node不但可以做有計劃性的線上漂移，同時對於主機等故障發生後，通過GI的HA元件把失敗主機上的例項遷移到其他節點，不過這種遷移有不可用時間。 下面我們通過殺死CRS程式的方式，模擬主機故障，來觀察RAC One Node的故障切換。

oltp8正在執行的節點1上，在節點1上殺掉CRS程式

ps -elf | egrep "d.bin|ohas|oraagent|orarootagent|cssdagent|\
cssdmonitor" | grep -v grep |awk '{print $4}' |xargs -n 10  kill -9

在RAC2節點上觀察資料庫的狀態，例項已經為not running狀態。

>srvctl status database -d oltp8
Database is not running.
Online relocation: INACTIVE

通過crsctl stat命令檢視故障切換是否已經發生

>crsctl stat res -t
-------------------------------------------------------------------
Name           Target  State        Server      State details
-------------------------------------------------------------------
Local Resources
-------------------------------------------------------------------
ora.DATADG.dg
               ONLINE  ONLINE       rac2        STABLE
               ONLINE  ONLINE       rac3        STABLE
               ONLINE  ONLINE       rac4        STABLE
-------------------------------------------------------------------
Cluster Resources
-------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       rac4        STABLE
ora.MGMTLSNR
      1        ONLINE  ONLINE       rac2        169.254.198.57 192.1
                                                68.100.2,STABLE
ora.cvu
      1        ONLINE  ONLINE       rac2        STABLE
ora.oltp8.db
      2        ONLINE  OFFLINE      rac2        STARTING
-------------------------------------------------------------------

從crsctl stat res -t的輸出可以清楚看到，叢集正在RAC2節點上嘗試拉起例項。過2分鐘再次檢視，資料庫已經完成故障切換，整個過程不到五分鐘，非常的棒！

>crsctl stat res -t
---------------------------------------------------------------------
Name           Target  State        Server        State details
---------------------------------------------------------------------
Local Resources
---------------------------------------------------------------------
ora.DATADG.dg
               ONLINE  ONLINE       rac2          STABLE
               ONLINE  ONLINE       rac3          STABLE
               ONLINE  ONLINE       rac4          STABLE

---------------------------------------------------------------------
Cluster Resources
---------------------------------------------------------------------
ora.oltp8.db
      2        ONLINE  ONLINE       rac2          Open,STABLE

---------------------------------------------------------------------

雖然RAC One Node的HA是Cold Failover的，但是對於一些邊緣、測試、開發環境，對於可用性要求不是那麼高的環境，它都是一種非常好的整合方案。試想，有幾個客戶會把自己最為核心的資料庫來進行整合呢？

RAC One Node擴充套件性

RAC和RAC One Node之間可以通過srvctl命令輕鬆的做轉換，我們以把RAC One Node擴充套件成多個節點的RAC。這裡給出轉換的示例：

檢視當前RAC One Node的執行狀態

srvctl status database -d oltp8
Instance oltp8_1 is running on node rac2
Online relocation: INACTIVE

執行在RAC2節點上，執行狀態正常。

使用srvctl convert命令進行轉換，-c引數代表了要把RAC One Node擴充套件成標準的RAC。

srvctl convert database -d oltp8 -c RAC

轉換完成後，檢視資料庫的例項狀態

srvctl status database -d oltp8
Instance oltp8_1 is running on node rac1
Instance oltp8_2 is running on node rac2

非常好，Oracle幫我們自動增加了例項，而且增加的例項已經啟動。需要注意，筆者的測試環境為12C，如果為11GR2，增加的例項需要DBA手工去啟動。

就這樣輕鬆的完成了RAC One Node到RAC的轉化。

同樣我們看如何來“縮”，把RAC 轉化為RAC One Node，同樣通過srvctl 命令來完成，-c引數代表了把RAC“收縮”為RAC One Node.

srvctl convert database -d oltp8 -c raconenode
PRCD-1154 : Failed to convert the configuration of cluster database oltp8 into its equivalent RAC One Node database configuration because cluster database is running on more than one server [rac1, rac2]

提示有2個例項在執行，看來需要關閉一個例項才能進行RAC到RAC One Node的轉化

srvctl stop instance -d oltp8 -i oltp8_1 -f

srvctl convert database -d oltp8 -c raconenode

轉換完成後，再次檢視資料庫例項的狀態

srvctl status database -d oltp8
Instance oltp8_2 is running on node rac2
Online relocation: INACTIVE

oltp8已經只有一個例項在執行了。

從上面的實驗過程中可以看出，RAC One Node具有非常好的可用性、伸縮性，而且這一切的操作都非常的簡便。

到這裡你已經對RAC One Node有了一定了解，由於是以單例項的狀態執行，而且還具有非常高的可用性，那麼用來做資料庫的整合太合適了，整合的密度可以很大，適用於那些對於可用性要求沒有那麼的高的開發、測試、QA、邊緣系統。

12C CDB

12C出現了容器資料庫CDB，虛擬化整合方案共享了宿主機，多例項整合方案共享了宿主機和OS，而12C的容器資料庫共享了宿主機、OS和例項，共享的層次越多，內耗越少，效能越高，整合的密度就可以越大，但隔離性上會弱一些，一旦例項層面出現問題，所有的PDB都會出問題。Oracle通過在12C增強了Resource Manager的功能來進一步提供PDB之間的資源隔離實現。由於PDB的建立可以基於模板和克隆，因此資源供應速度上得到了很大的提升。12CR1版本，一個容器資料庫最多支援252個PDB,到了12CR2版本已經增強到4096個。筆者所在公司-沃趣科技也一直在研發12C的相關資料庫平臺和產品，就我們的使用測試情況來看，12CR1版本的BUG還比較多，有些BUG在MOS上還沒有記錄，因此建議不要著急上12C，等12CR2釋出後再做決定。

資源快速供應

資源快速供應是DBaaS出現之後延伸出來的一個概念，意在使用者通過自服務的方式去快速的獲取資源。以前資料庫簡直就是世界的中心，想申請一個資料庫資源從專案的立項到最終獲得資源，要經過相對漫長的時間，所有人都要圍著它轉，而DBaaS做為一個大的資料庫平臺，有著“無限”大的可用效能、可用容量，因此只需要使用者在雲平臺之上點點滑鼠，就能完成資源的獲取，Oracle 12C出現的容器資料庫讓資源的獲取更加的快速和便捷，它本身通過資料庫的模板來快速提供PDB。要實現資源的快速供應，你需要：

●  有一個強大的硬體平臺，比如一體機產品

●  有一個雲平臺，開發、測試、QA可以便捷的在雲平臺之上完成資源的申請和獲取

●  決定使用何種技術提供資源，PDB？SCHEMA？DB？

目前我們沃趣科技也是在研發DBaaS雲平臺產品DBPool，在其上可以方便的完成資源的申請、獲取、使用、下線，資源的整個生命週期都可以在平臺之上完成，可以極大提升獲取資源的敏捷性，為企業的資料庫提供一個標準化的操作平臺。

服務質量管理QoS

資料庫做了整合之後，面臨著幾個問題

●  資源隔離如何做，如果不做資源隔離，就難以保證資料庫對外的服務質量，例項之間、PDB之間會互相影響

●   可不可以對資源進行靈活的調配，以滿足不同業務，不同時間段的對資源的需求情況

CPU資源隔離技術Instance Caging

Alt text

我們首先來看第一個問題，資源隔離如何做，如果資源是無限的，就不需要對他們進行管理，資源隔離是DBaaS裡一個非常重要的概念，也是每一個DBaaS平臺都需要去解決的核心問題。

以前使用Oracle的方式大多都是一臺機器跑一個例項，但是資料庫一旦進行整合，一臺機器可能就不是跑一個例項了，而是多個例項，例項一多，一個現實的問題擺在面前：資源隔離如何做？

為了保證每個資料庫例項的服務質量，你需要提前對每個例項分配資源，在它的整個活躍週期內都不能跑出給它分配的資料庫資源。如果資源不加以不加限制，就可能出現這樣的情況：一個優先順序非常低的業務由於應用程式BUG進而導致侵佔了主機上的絕大部分CPU資源，最終導致主機上其他重要度高的應用受到非常大的影響，業務被降級。如下圖：

Instance Caging就是這樣的技術，用於CPU資源的管控，它能夠管理CPU在例項間的分佈，確保每個例項可以使用的CPU資源不跑出它的一畝三分地。

Instance Caging相對於其他資源管理的技術，例如作業系統的Cgroup，它具有一些天然的優勢

●  Instance Caging是11GR2自帶的功能，不需要額外安裝軟體

● 它是免費的，不需要支付額外的licence費用

● 由於是自帶的功能，因此它能與Oracle資料庫庫高度的整合，可以感知到資料庫內部的負載

● 最為重要的一點，它的使用特別的簡便，請看下一節

12C版本可以利用資料庫的引數processor_group_name結合LINUX Cgroup來一起使用，這部分內容本文不做詳細介紹。

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