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

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

啟用Instance Caging

Instance Caging 通過設定2個資料庫的初始化引數來達到管控CPU的目的：

?     cpu_count

?     resource_manager_plan

這兩個初始化引數都可以線上修改不用重啟，這為我們管控CPU資源的分配提供了極大的靈活性。在實施Instance Caging前，我們需要資料庫有一個resource manager plan，如果你當前的資料庫還沒有resource manager plan，也可以啟用預設的。

alter system set resource_manager_plan = 'default_plan';

注意：如果是RAC資料庫，那麼上面的語句將會在RAC的所有例項生效，確認這是你希望的結果，否則在alter system語句中增加sid='xxx'引數。在開啟管理計劃後，資料庫的後臺程式VKRM會開始執行。

如果要確認instance caging功能已經生效，可以使用下面的語句確認：

select instance_caging from v$rsrc_plan where is_top_plan = 'TRUE';

INSTAN
------
ON

剩下的事就是設定你的例項可以使用的CPU的個數了。先檢查下當前資料庫的CPU個數：

show parameter cpu_c

NAME                   TYPE                   VALUE
---------------------- ---------------------- ----------
cpu_count              integer                40

我的主機上有40 core邏輯CPU，真實的CPU物理core其實是有20，由於採用了CPU的超執行緒技術，所以主機上看到的CPU數量是40.可以根據業務需要來設定例項可以使用的CPU個數。例如下面的語句設定讓本例項最多可以使用到20個CPU資源。

alter system set cpu_count=20;

一單開啟了instance caging，它就會發揮作用，限制單個例項的cpu使用數量。可以通過vrsrc_consumer_group，vrsrcmgrmetric，v$rsrcmgrmetric_history檢視來獲得Instance Caging的參考資料，它提供以分鐘為單位的CPU使用情況和過去一小時的CPU流量反饋。

Instance Caging實踐

準備指令碼，目的是為了消耗CPU

test.sql的內容
declare
L_N number;
begin
 while ( true)
 loop
L_N := dbms_random.random();
end loop;
end;
/

a.sh指令碼：開啟60個併發執行test.sql

#! /bin/sh
. /home/Oracle/.bash_profile
step=1
while [ $step -lt 60 ]
do
nohup sqlplus test/test @test.sql &
let "step+=1"
echo $step
done

指令碼準備好後，就可以讓它在後臺跑了。

開始實驗

這裡先不對cpu_count做任何限制，看看CPU最多能使用到多少

sys@TEST>show parameter cpu_c

NAME                  TYPE                   VALUE
--------------------- ---------------------- ----------
cpu_count             integer                40

SQL>alter system set resource_manager_plan = 'default_plan';

System altered.

SQL>select instance_caging from v$rsrc_plan
where is_top_plan = 'TRUE';

INSTAN
------
ON

/home/Oracle>vmstat -w 1
procs --------------memory------------------  --system-- -----cpu-------
 r  b  swpd       free       buff      cache    in   cs  us sy  id wa st
41  0     0   39065524     341360   17386716     2    5   1  0  99  0  0
42  0     0   39066200     341360   17386716  41851 11027  92  0   8  0  0
40  0     0   39066072     341360   17386720  41205 10284  92  0   8  0  0
40  0     0   39066144     341368   17386712  41420 10578  92  0   8  0  0
40  0     0   39066144     341368   17386720  41297 11481  90  0  10  0  0
40  0     0   39066284     341368   17386720  41795 11919  91  0   9  0  0

幾乎使用了所有的CPU資源，接下來通過調整cpu_count的值來觀察資源管理是否會起作用，先調整到20，也就是邏輯CPU數的一半

sys@TEST>alter system set cpu_count=20;

System altered.


/home/Oracle>vmstat -w 1
procs ----------------memory------------------  --system-- -----cpu-------
 r  b    swpd       free       buff      cache    in   cs  us sy  id wa st
20  0       0   39067484     341392   17386756     2    5   1  0  99  0  0
20  0       0   39067476     341392   17386760  25716 10551  50  0  50  0  0
20  0       0   39066980     341392   17386764  26138 11154  50  0  50  0  0
23  0       0   39067228     341392   17386764  26818 12372  51  0  49  0  0
20  0       0   39071444     341392   17386772  27138 12124  52  0  48  0  0

select to_char(begin_time, 'HH24:MI') time,
       sum(avg_running_sessions) avg_running_sessions,
       sum(avg_waiting_sessions) avg_waiting_sessions
  from v$rsrcmgrmetric_history
 group by begin_time
 order by begin_time;


TIME       AVG_RUNNING_SESSIONS AVG_WAITING_SESSIONS
10:03                21.9687333           43.8441667
10:04                  20.58455             38.56545
10:05                20.4874333           38.5253333
10:06                  20.53805             38.54745

Instance Caging在發揮著作用，從作業系統監控CPU的資源使用情況非常清楚的看到CPU的使用率在50%上下。

再調整成10看看，也就是CPU的1/4數量

sys@TEST>alter system set cpu_count=10;

System altered.

/home/Oracle>vmstat -w 1
procs ---------------memory------------------ --system-- -----cpu-------
 r  b   swpd       free       buff      cache   in   cs  us sy  id wa st
10  0      0   39069604     341388   17387168    2    5   1  0  99  0  0
10  0      0   39069416     341388   17387168 16653 11306  25  0  75  0  0
11  0      0   39069292     341388   17387168 15504 10032  25  0  75  0  0
10  0      0   39069416     341388   17387244 15822 10124  25  0  75  0  0
11  0      0   39069540     341388   17387248 16079 10413  26  0  74  0  0
11  0      0   39069416     341388   17387248 16779 11280  26  0  74  0  0

select to_char(begin_time, 'HH24:MI') time,
       sum(avg_running_sessions) avg_running_sessions,
       sum(avg_waiting_sessions) avg_waiting_sessions
  from v$rsrcmgrmetric_history
 group by begin_time
 order by begin_time;

TIME       AVG_RUNNING_SESSIONS AVG_WAITING_SESSIONS
---------- -------------------- --------------------
10:00                14.0004833           45.4167667
10:01                14.0001833           48.5537833
10:02                14.0001333           48.2055167

和預期的一樣，使用了25%的CPU資源。Instance Caging很好的發揮了作用。Good Job ！

如何為每個例項分配CPU資源

讀者可能會有疑問，我能不能給一臺主機上的例項分配的CPU資源超過總的邏輯CPU數，答案是可以的。但就核心資料庫來說，並不建議去過量分配CPU。如下圖，推薦為每一個例項按照工作負載來去分配CPU，分配CPU的總數等於邏輯CPU的數目。當然就像下圖中所註釋的，如果已經分配給例項的CPU，例項非常的空閒，無任何的壓力，那麼這些CPU會被浪費，別的例項一旦想要使用也不能使用。

如果是開發、測試、QA一些邊緣庫，可以根據實際情況，酌情為主機上的例項分配的CPU之和大於主機的邏輯CPU數，使用這種分配方式的風險就在於一旦幾個例項的負載同時上來，可能會出現CPU的爭用問題，但是它的優點也是非常的明顯，在限制資源的同時可以更加充分地利用主機的CPU資源。這種方式推薦在非核心庫上使用，

記憶體資源隔離

對於記憶體使用量的隔離比較好做到，只需要在每個例項間通過sga_target，pga_aggregate_target引數設定就可以做到例項間記憶體資源的隔離。需要強調的是，對於PGA的使用，Oracle 12C之前並沒有硬限制，請仔細為資料庫預留出足夠的PGA空間，以防記憶體出現SWAP。關於記憶體分配的詳細介紹，請參考我的另一篇文章（文章最後的白皮書部分有連結），這裡不做贅述。

IO資源隔離

Oracle並沒有直接提供IO隔離的技術(Exadata可以)，如果ASM中的盤有SSD,SAS不同介質型別，建議在ASM層面進行儲存池的劃分，例如高效能SSD的為一個DG，SAS的為一個DG，在進行DB建立過程中根據業務的特點去選擇把DB建立於哪個儲存池之上。

ServerPool

我們再來看，服務質量的第二個問題，發現叢集需要擴容或縮容，如果做到敏捷？答案是可以通過serverpool來實現，11GR2之前建立RAC的時候，需要去選節點，例項與節點間存在一個強耦合的關係，如果某個節點的實 例掛掉了，也不容易遷移（需要一些複雜操作）到叢集其他可用的節點上，Oracle把這種方式稱為基於管理員的管理方式，11GR2之後出現了一種新的管理方式，基於策略的管理方式，而serverpool就是這種理念下的一個產物。資源和機器之間不再具有耦合性，資源“隨時隨地”都可用。使用基於serverpool的方式建立DB，DB是建立在預先定義好的serverpool之上的，DB的可擴充套件性受限於serverpool的屬性設定。我們通過一個具體的例子來看看如何使用這種新的方式來建立DB，以及使用它的好處是什麼。

構建Grid叢集

Oracle Grid是個叢集，把多個伺服器虛擬成一臺伺服器，這一層叢集通過上面的各種應用體現價值，這些應用被叫做資源，Oracle資料庫就是一種資源，雖然Oracle一直宣稱GI作為一個叢集的基礎元件，上面可以跑各種資源，但是市場的歸市場，技術的歸技術，目前GI之上跑的絕大部分資源還都是Oracle資料庫，以上圖為例，一共9個計算節點，組成了一個大的Grid叢集,作為叢集的基礎元件，它本身具有HA、可擴充套件的特性，並且為其上層的應用提供監控、故障切換、心跳檢測、節點成員管理等服務。上圖中這9臺機器需要裝好Grid和Oracle Database的軟體。

構建ServerPool

叢集按照好後，就可以在這個Grid叢集之上，建立serverpool，這裡我們規劃了4個serverpool：erppool,productpool,testpool,devpool，還有一個free pool（預設會建立）。 每一個serverpool都需要有一個定義，定義這個pool中主機數量的最小值、最大值、重要度。

?       最小值：定義serverpool中執行伺服器的最小數量

?       最大值：定義serverpool中執行伺服器的最大數量

?       重要度：Serverpool的重要度，只有相對意義，沒有絕對意義，在計算節點分配階段、計算節點故障後，重要度高的serverpool會優先被保證資源充足

我們現在對我們即將要建立的4個pool來規劃好屬性：

?       erppool的屬性：最小1個節點，最大2個節點，重要程度為3

?       productpool的屬性：最小3個節點，最大3個節點，重要程度為10

?       testpool的屬性： 最小1個節點，最大兩個節點，重要度2

?       devpool的屬性：最小1個節點，最大兩個節點，重要度1

叢集在執行時，會根據serverpool的屬性，動態的調整伺服器在serverpool之間的分配，我們來看一下計算節點在serverpool上的分配規則：

?      按照Server Pool的Importance順序，依次填充每個Server Pool，填充至Min個伺服器。如果還有剩餘機器，則進入到下一步。

?      再按照Server Pool的Importace順序，依次填充每個Server Pool，填充至Max個伺服器，如果還有剩餘的機器，則進入到下一步。

?      再剩下來的機器進入到free pool中。

9個節點的叢集安裝完畢後，按照上面提到過的分配原則，看下我們這個例子中的分配過程：

?     productpool的重要度最高，因此先滿足它所要求的最小節點數量3

?     其次是erppool的重要度最高，因此滿足它所要求的最小節點數量1

?     其次是testpool的重要度最好，因此滿足它所要求的最小節點數量1

?     最後是devpool，滿足它所要求的最小節點數量1

經過這一輪的分配後，還剩餘3臺機器，進入下一輪的分配：

?    滿足serverpool的最大節點數量要求，同樣從重要度最大的serverpool開始

?    productpool的重要度最高，但是由於它已經滿足了最大值要求，直接跳過，接下來是erppool，從剩餘的4個節點中分配1個節點給它，滿足它的最大節點數要求2

?    其次是testpool的重要度最高，再從剩餘的2個節點中，分配一個節點給它，滿足它的最大節點數要求2

?    最後是devpool，把僅剩的一個節點分配給它，這個時候已經沒有多餘的機器了，因此free pool中的機器數量為0.

最終的分配結果如下圖所示。

建立基於ServerPool的DB

serverpool建立完成後，就可以在serverpool之上去建立Oracle DataBase,舊的模式（Administrator-Based Management）在建立DB的時候，是選擇節點列表。 基於Policy-Based Management的管理方式，db在建立的時候是選擇serverpool。 你需要去問為什麼要使用這種方式，能帶來什麼好處？接下來我們會講到。

QoS服務質量保證

細心的同學可能已經發現了，我在定義serverpool的時候為每一個serverpool 不僅指定了最小值最大值要求，而且還指定了重要度，這個重要度是serverpool裡一個很重要的概念。我們繼續以上面的圖裡的內容為例，productpool是公司的核心生產庫，它的重要度是最高的，而且對於這個pool的最小值要求是3，如果天有不測風雲，productpool 裡有天突然down了個節點，那麼會發生什麼呢？如果是基於ADMIN方式的管理模式，什麼都不會發生，但是基於policy的管理方式，就不一樣了，由於produdctpool的重要度最高，而且已經不滿足了最小值要求，因此它會選擇從其他重要度低的pool中拉過來一臺機器，從哪拉呢？先從滿足了最小值要求，而且重要度最低的pool裡找機器，因此devpool就被盯上了，devpool不但滿足了最小值要求，而且還多出了一個機器滿足了最大值要求，因此強行把這個devpool裡的一臺機器拿走給了productpool，滿足了productpool對於機器的最小值要求。productpool上面的資源，例如資料庫例項在等這個機器加入到productpool後也會自動被拉起來，不需要DBA手工的干預，是不是非常的棒！等productpool之前故障的機器起來後，它會被放入freepool，然後發現所有的serverpool 除了devpool 都已經滿足了最小值最大值要求，因此會把這個機器從free pool 中轉移到devpool中，同樣構建在devpool 裡的資源也會被自動的拉起，不需要DBA手工的干預。

如果你還適應不了這麼靈活的資源分配方式，那麼可以通過把serverpool的重要度都設定成一樣，這樣就不會出現主機故障後，資源可能重分配的問題，而是通過DBA去決定是否通過修改serverpool的屬性來達到資源重分配的目的。

彈性伸縮

使用serverpool的第二大好處是彈性伸縮的能力，繼續以上圖為例，如果某天業務上需要搞促銷，生產環境壓力會很大，DBA擔心現有的伺服器資源不夠，那麼就可以通過調整serverpool的屬性值，自動完成生產環境的擴容，例如把productpool的最小值最大值數量從3調整為4，調整後，由於重要度最高的productpool不滿足了它的最小值要求，因此會從重要度最低的pool中拿走一臺來滿足它的最小值要求，這裡同樣是從devpool中拉走一臺，這臺機器加入到 productpool後，上面的資源會被自動拉起，自動完成擴容，同樣，促銷結束後，通過修改productpool屬性值，也會自動的完成收縮。從這裡可以清楚的看出，RAC的可擴充套件性完全的依賴於serverpool的屬性值。而之前舊的模式下，如果RAC需要擴容，需要去加例項，而加例項本身是一個比較複雜的過程，使用基於策略的管理之後，這些都會由Oracle自動幫你完成。

Policy Set

ServerPool在12C有一個新特性，可以建立一些策略集合，例如，某運營商有2個RAC叢集，第一個RAC是用來做線上業務的，白天壓力很大，需要5臺伺服器來滿足業務的要求，而晚上壓力很小，只需要2臺伺服器就能滿足業務要求，第二個叢集是用來做晚上的分析任務的，白天壓力非常小，只需要2臺就能滿足業務要求，而晚上壓力很大，需要5臺伺服器才能滿足分析要求，那麼基於這個情況，可以建立2個策略DAYTIME和NIGHTTIME，分別代表白天的策略和晚上的策略，再建立2個POOL，online 代表線上業務pool，DW代表資料倉儲分析pool。這兩個策略作為一個policy set，在白天時段，通過任務去觸發DAYTIME這個policy，然後根據serverpool的功能自動完成伺服器的分配和例項的拉起，在晚上時段，觸發NIGHTTIME這個policy。很方便，是不是？

POLICY DAYTIME
Online： 最小值5，最大值5，重要度10
DW：     最小值2，最大值2，重要度10

POLICY NIGHTTIME
Online： 最小值2，最大值2，重要度10
DW：     最小值5，最大值5，重要度10

crsctl modify policyset –attr “LAST_ACTIVATED_POLICY= DAYTIME”

基於ServerPool的RAC One Node

如果要使用RAC One Node來做資料庫的整合，強烈建議使用基於ServerPool的方案，在ServerPool之上來構建RAC One Node。經過測試，傳統的方式不能把多個RAC One Node例項在多個節點間做平均分配。例如9個RAC One Node例項，3個RAC節點，如果使用基於Serverpool的管理方式，那麼這9個節點用DBCA建立後會比較均勻的分配到這三個RAC節點上，但是基於Administrator-Based Management方式，9個節點在用DBCA建立後會全部被分配DBCA執行的節點上。同樣，在主機發生down機後，基於ServerPool的RAC One Node也表現出了這一點，故障節點主機上的資料庫例項會比較均勻的分佈到其他存活的節點上。

12C CDB的資源隔離
這裡簡單提一句12C中CDB的資源隔離，12C的CDB容器資料庫本身是一種基於雲而生，用來做資料庫整合的一個解決方案，12C CDB的釋出，配套著資源管理器也新增了基於PDB的資源隔離的功能。

如上圖，CDB中一共存在3個PDB：Sales、Marketing、Support，使用資源管理器對這3個PDB做了一定的資源限制。Sales可以使用到最多90%的CPU資源，在主機資源不夠用的情況下，需要保證50%的CPU資源，這一點上倒是比Instance Caging更靈活，同樣Marketing和Support是一樣的，作者不再給出詳細說明。

架構設計與SLA定義

前面的章節已經講解了種種構建DBaaS私有云可能使用到的技術，最終的架構設計還是要依據企業對於資料庫SLA等級定義、根據實際的業務需要來決定使用何種架構、何種技術做整合，如果對於RPO，RTO要求非常的高，幾乎不能有任何的不可用時間，那麼我推薦使用基於RAC的方式來構建整個私有云，結合Instance Caging和Resource Manager做資源隔離，結合ServerPool來實現RAC的靈活伸縮以及QoS質量保證。資料庫的整合方案建議使用單機多例項的方案，12C的容器資料庫目前還需要有人去踩坑，缺少最佳實踐。

如果業務對於RPO,RTO要求沒那麼高，資料庫的負載也比較小，允許一小段時間的叢集不可用，那麼我推薦使用RAC One Node來構建私有云，同樣，結合Instance Caging和Resource Manager做資源隔離，結合ServerPool來實現RAC的靈活伸縮以及QoS質量保證。

最後需要說明，混合可能是一種常態，現在都流行混搭、跨界，技術界也一樣，什麼混合雲不就是混搭嗎，架構設計也一樣，你可以把私有云架構設計成一種混合的架構，既有高可用的RAC架構，也有RAC One Node這種可用性沒有那麼高的架構，兩種架構同存於一個架構中。

關於作者

魏興華，沃趣科技高階技術專家，主要參與公司一體機產品、監控產品、容災產品、DBaaS平臺的研發和設計。曾就職於東軟集團，阿里巴巴集團，Oracle ACE組成員，DBGEEK 使用者組發起人，ITPUB認證部落格專家，ACOUG、SHOUG核心成員。曾在中國資料庫大會、Oracle技術嘉年華、ORCL-CON、YY分享平臺等公開場合多次做過資料庫技術專題分享。對Oracle 並行機制、資料庫異常恢復方法、ASM等有深入的研究，人稱”Oracle Internal達人”，對企業資料庫架構設計、故障恢復、高併發下資料庫效能調優有豐富的經驗，擅長從等待事件角度分析解決資料庫效能問題，是OWI方法論的提倡者和踐行者。

個人郵箱:xinghua.wei@woqutech.com

DB GEEK QQ 群: 516293316

公司主頁:www.woqutech.com

其它白皮書

SQL MONITOR: http://pan.baidu.com/s/1gfO2DtL

Parallel原理實現： http://pan.baidu.com/s/1i5xun9F

12C IN-MEMORY： http://pan.baidu.com/s/1ge7r1oZ

Oracle Memory Management and HugePage: http://pan.baidu.com/s/1dFdPLEp

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