Page 10:

圖4為i.sql腳本的輸出。在14：30：43這一時刻，正在共有4個RAC實例在運行。

圖4：在進(jìn)行故障注入測試時的RAC實例狀態(tài)

在圖5中，我們執(zhí)行io.sql腳本以顯示在14：23：13Oracle每秒在集群范圍內(nèi)正在執(zhí)行約9,424個物理I/O。這說明該集群已經(jīng)達(dá)到了一個飽和穩(wěn)定階段。

圖5：由gv$性能視圖報告的集群范圍內(nèi)的物理I/O

Page 11:

通過使用TotalStorage Performance Monitor，我們還可以輕松地獲得集群范圍內(nèi)I/O活動的概況圖。如圖6所示，在14：28：37 I/O速率為每秒9,985次傳輸。

圖6：節(jié)點3出現(xiàn)故障前一時刻的TotalStorage Performance Monitor

當(dāng)工作負(fù)載達(dá)到穩(wěn)定狀態(tài)時，我們隨即突然斷掉該集群節(jié)點3的電源，模擬一次服務(wù)器故障。圖7顯示了來自一個RAC節(jié)點的PolyServe Matrix Server matrix.log文件屏幕截圖，說明在14：38：24節(jié)點3 (192.168.3.23)脫離PolyServe Matrix集群。

時鐘旋即開始計時，測量需要花費多長時間才能恢復(fù)OLTP處理。

4 TotalStorage Performance Monitor可以在左下角顯示監(jiān)控會話何時開始（14:26:59），并在右下角顯示監(jiān)控會話共運行了多長時間（1分鐘38秒）。此屏幕截圖于14:28:37截取。

Page 12:

圖7：正如PolyServe matrix.log文件中所報告的，該集群的節(jié)點3在14:38:24停機(jī)

此時，在OLTP處理恢復(fù)之前，需要進(jìn)行3種形式的恢復(fù)：

• 1. PolyServe Matrix Server恢復(fù)。PolyServe將重放任何可能由于新出現(xiàn)的節(jié)點分離而產(chǎn)生問題的日志項。
• 2. Oracle Clusterware 恢復(fù)。Oracle 群件必須弄清楚在一個節(jié)點"死亡"以后，該集群所處的狀態(tài)。

指出下列事實非常重要：用于Linux和Windows的Oracle10g Release 2 Real Application Cluster，不再以任何方式與任何主機(jī)群件集成。取而代之的是，Oracle群件與主機(jī)群件并行運行。由于PolyServe Matrix Server是等級更低的主機(jī)群件⁵，以"內(nèi)核"模式執(zhí)行其集群狀態(tài)代碼，所以，它總能確定一個節(jié)點是否已經(jīng)死亡，并遠(yuǎn)在Oracle Clusterware意識到該節(jié)點已經(jīng)死亡之前將其隔離。因為Oracle Clusterware沒有與主機(jī)群件集成，所以它必須自己判斷出一個節(jié)點是否已經(jīng)死亡。

用于確定某節(jié)點是否已死亡的方法取決于節(jié)點死亡的方式，但是為了簡化，該方法將基于節(jié)點與Oracle Cluster Synchronization Services (CSS)主機(jī)定期"登記聯(lián)系"的方案。若某RAC節(jié)點已經(jīng)在一段可調(diào)整的時間內(nèi)沒有"登記"了，則Oracle群件可以將其從RAC集群中排除⁶。錯過登記的容限是可調(diào)整的，默認(rèn)值為60秒。在極極端系統(tǒng)負(fù)載條件下，若將此參數(shù)調(diào)得過低可能會導(dǎo)致錯誤出現(xiàn)，所以必須要保持一個平衡。這就是Oracle Clusterware的架構(gòu)方式，它與PolyServe Database Utility for Oracle無關(guān)。

• 3. Oracle實例恢復(fù)。若一個Oracle實例死亡，則其他實例中的一個必須執(zhí)行交易回滾/前滾，完成重做線程。

由于PolyServe Matrix Server是以完全對稱的分布式方法鎖定管理，并以聯(lián)機(jī)模式完成某些恢復(fù)工作，所以，其全面恢復(fù)的部分過程極為簡潔。圖7說明了PolyServe可以在12秒內(nèi)（14:38:36）以聯(lián)機(jī)模式開始其恢復(fù)工作。聯(lián)機(jī)恢復(fù)一旦開始，即可啟動Oracle處理。

5 在所有Unix 群件（例如HACMP）上的Oracle10gR2都遵循此同一個模式。

6 Oracle以通知服務(wù)器重新啟動自己的方式將該服務(wù)器從RAC集群中驅(qū)逐。

Page 13:

圖8顯示在14:38:58，Oracle Clusterware確定節(jié)點3不再"活動"⁷。同時，Oracle Clusterware開始進(jìn)行恢復(fù)。

圖8：正如ocssd.log文件中所報告的，Oracle Clusterware在14:38:58將節(jié)點3排除

最后，這些單獨的恢復(fù)水平指標(biāo)并不是特別重要，重要的是恢復(fù)OLTP交易所花費的時間有多長。圖9顯示了一個在14:39:07執(zhí)行–i.sql腳本的會話的屏幕截圖，說明當(dāng)時共有3個實例在線。截至此時，從節(jié)點3死亡開始時間已經(jīng)過去了63秒。事實上i.sql腳本的執(zhí)行時間是14:39:07，但是，這并不能準(zhǔn)確地描述交易恢復(fù)的時間。事實上，查看TotalStorage Performance Monitor可以更有效地完成此任務(wù)。

圖9：恢復(fù)之后，gv$instance視圖報告說明共存在3個依然存在的節(jié)點。

7 Oracle Clusterware使用可調(diào)整的參數(shù)，以減少錯過登記的次數(shù)。您可以使用crsctl命令了解默認(rèn)值， Linux 10.2.0.1版本的默認(rèn)值為60。

Page 14:

圖10為14:39:06⁸的屏幕截圖，顯示集群范圍內(nèi)RAC I/O請求數(shù)量已經(jīng)上升到每秒2,799次。在獲取此屏幕截圖之前，該數(shù)據(jù)庫至少已經(jīng)有一段時間可以使用了，因此才能回升到此I/O水平。

圖10：TotalStorage Performance Monitor顯示，在故障注入42秒內(nèi)，I/O已回升到每秒2,799次

圖10顯示I/O是在14:39:06開始回升。而另一方面，圖11顯示，在節(jié)點3死亡（14:39:33⁹）的69秒內(nèi)，集群范圍內(nèi)的I/O速率已經(jīng)回升到每秒7,777個I/O，占4個節(jié)點取得的I/O速率的77%。所以，PolyServe能夠得到恢復(fù)，而Oracle能夠執(zhí)行其60秒CSS戰(zhàn)略，而OLTP I/O也在近69秒內(nèi)恢復(fù)到預(yù)計的3個節(jié)點的水平。毫無疑問，調(diào)整Oracle Clusterware的時間容限將加速此任務(wù)的完成。關(guān)鍵是在損失一個負(fù)載繁重的節(jié)點后，集群架構(gòu)能夠得到恢復(fù)。

8監(jiān)控會話于15:26:59開始啟動，此屏幕截圖是在該會話開始啟動12分鐘零6秒后–即14:39:06獲取的。

9監(jiān)控會話于15:26:59開始啟動，此屏幕截圖是在該會話開始啟動12分鐘46秒后–即14:39:33獲取的。

Page 15:

圖11：TotalStorage Performance Monitor顯示，I/O速率已回升到3個依然存在節(jié)點的預(yù)期值

故障恢復(fù)總結(jié)

通過在OLTP峰值吞吐率期間將集群中的一個節(jié)點斷電，此測試確定PolyServe Database Utility for Oracle中恢復(fù)Real Application Cluster的能力。不進(jìn)行任何調(diào)整，用戶可以觀察到的唯一效果是PolyServe集群文件系統(tǒng)訪問存在12秒的停頓。從這一時刻僅過了30秒，物理I/O便恢復(fù)到故障前水平（每秒9,984次I/O）的約28%。如上所述，在損失節(jié)點3后的69秒內(nèi)，該集群所有3個依然運行的節(jié)點的OLTP吞吐率已經(jīng)恢復(fù)到故障前的水平。沒有對Oracle 群件進(jìn)行任何專門調(diào)整，獲得這樣的結(jié)果已經(jīng)非常了不起了。最重要的是，當(dāng)節(jié)點3出現(xiàn)故障時，與其余3個節(jié)點上的Oracle實例相連的會話并沒有中斷。它們依然能夠保持連接，而Oracle的恢復(fù)剛剛完成，它們的交易也隨之立即恢復(fù)。

Page 16；

按照需要動態(tài)、透明地進(jìn)行擴(kuò)展

決策支持系統(tǒng)（DSS）：輕量級掃描

按照配置，為了測試TotalStorage DS4500 SAN的性能情況，我們進(jìn)行了Oracle Parallel Query Option (PQO)輕量級掃描測試。

圖文翻譯：

Light Weight Scan (LWS) Workload：輕量級掃描（LWS）工作負(fù)載

Scan of 2 Billion Rows (75GB)：掃描20億行（75GB）

Throughput (MB/sec)：吞吐率（MB/秒）

1 Node：1個節(jié)點

2 Nodes： 2個節(jié)點

Blades：刀片服務(wù)器

圖12.決策支持系統(tǒng)（DSS）：輕量級掃描（LWS）工作負(fù)載

輕量級掃描由對20億行的信用卡交易表進(jìn)行的select count(*)組成。Parallel Query Option的I/O設(shè)置為直接路徑讀?。╠irect-path reads）。直接路徑讀取是1MB異步串行I/O操作，在PGA內(nèi)進(jìn)行緩存，在個并行查詢從進(jìn)程同時可以并行進(jìn)行4或8個查詢。測試Oracle服務(wù)器在給定的硬件配置上能夠?qū)崿F(xiàn)的基本掃描吞吐率，Parallel Query輕量級掃描是最簡單的方法。

決策支持系統(tǒng)（DSS）：數(shù)據(jù)加載吞吐率

我們還測量了卡表的加載。該測試包括將20億pipe-delimited格式的數(shù)據(jù)記錄。從平面文件同步加載到卡表中。平面文件和目標(biāo)卡表空間都駐留在PolyServe Matrix Serve集群文件系統(tǒng)中。單一節(jié)點測試包括8個SQL*Loader流，每個流將加載等量的平面文件數(shù)據(jù)。在4個節(jié)點中，每個節(jié)點都有2個并發(fā)SQL*Loader進(jìn)程，且4個節(jié)點的每個節(jié)點都并發(fā)地執(zhí)行2個加載（loader）流。記錄長度約為54個字節(jié)。平面文件總共需要約110GB文件系統(tǒng)空間。一經(jīng)插入，該表需要約75GB空間。圖13顯示了一個集群文件系統(tǒng)，列出了8個平面文件，并顯示了其中一個文件的幾個最新記錄。

Page 17:

圖13.集群文件系統(tǒng)列表

LS20刀片數(shù)據(jù)加載時間展示了出色的可擴(kuò)展性。圖14顯示，當(dāng)LS20刀片服務(wù)器從1個節(jié)點擴(kuò)展到4個節(jié)點使，大塊數(shù)據(jù)加載的擴(kuò)展能力實現(xiàn)了82%。一個節(jié)點的插入速率為每秒564,972行，完成任務(wù)需要59分鐘…增加第二個節(jié)點并再次執(zhí)行測試，結(jié)果為每秒可以插入1,075,269行，完成任務(wù)需要31分鐘–擴(kuò)展能力實現(xiàn)了95%。最后，在4個節(jié)點上執(zhí)行該測試，結(jié)果為每秒插入1,851,852行，完成任務(wù)需要18分鐘。

圖文翻譯：

Decision Support Sustem (DSS)Workload：決策支持系統(tǒng)（DSS）工作負(fù)載

Reduction in Completion Time：完成時間縮短

Time to Completion (Minutes)：完成時間（分鐘）

1 Node：1個節(jié)點            

2 Nodes：2個節(jié)點               

4 Nodes：4個節(jié)點

Blades：刀片服務(wù)器     

圖14.隨著節(jié)點數(shù)量的增加，完成時間縮短

Page 18:

DSS測試亮點如下：

• l 通過增加節(jié)點加快工作負(fù)載的完成是一種非侵入式方法。在另一臺刀片服務(wù)器上啟動DSS數(shù)據(jù)庫實例，然后再次運行任務(wù)，完成時間縮短了。
• l Oracle10g RAC和PolyServe Matrix Server，可以充分利用所有可用的磁盤子系統(tǒng)帶寬，而且沒有顯示出軟件層的擴(kuò)展能力限制。
• l 雖然每個測試的CPU和內(nèi)存需求都存在顯著差異，但是可擴(kuò)展能力屬性卻是相同的。若存在服務(wù)器瓶頸，會明顯出現(xiàn)重大性能差異。

OLTP環(huán)境中的可擴(kuò)展性

為了測試靈活數(shù)據(jù)庫集群架構(gòu)在OLTP環(huán)境中的可擴(kuò)展性，我們在RAC集群的節(jié)點1到節(jié)點4執(zhí)行了前面描述的Order Entry工作負(fù)載。此工作負(fù)載極具爭議，其讀寫率為約65:35。沒有使用任何形式的分區(qū)（如工作負(fù)載、依賴于數(shù)據(jù)的請求路由等）。

圖15顯示測試得到的從1個節(jié)點（310 TPS）到4個節(jié)點（1081 TPS）的可擴(kuò)展性為87%。

圖文翻譯：

On-Line Transaction Processing (OLTP) Workload：聯(lián)機(jī)交易處理（OLTP）工作負(fù)載

Transactions per Second：每秒處理的交易

1 Node：1個節(jié)點    

2 Nodes：2個節(jié)點       

3 Nodes：3個節(jié)點       

4 Nodes：4個節(jié)點

Blades：刀片服務(wù)器 

圖15. OLTP環(huán)境中的可擴(kuò)展性

此工作負(fù)載耗盡CPU資源，但是對了解生成的I/O負(fù)載也是很重要的。如圖16所示，I/O曲線與吞吐率曲線極為相像，這也說明了工作負(fù)載始終在擴(kuò)展。4個節(jié)點每秒的物理I/O操作數(shù)量峰值超過了6,500，顯而易見，LS20刀片服務(wù)器能夠處理大量OLTP I/O負(fù)載。

Page 19:

圖文翻譯：

On-Line Transaction Processing (OLTP) Workload：聯(lián)機(jī)交易處理（OLTP）工作負(fù)載

Physical I/O per Second：每秒處理的物理I/O數(shù)量

1 Node：1個節(jié)點    

2 Nodes：2個節(jié)點       

3 Nodes：3個節(jié)點       

4 Nodes：4個節(jié)點

Blades：刀片服務(wù)器

圖16. 運行OLTP工作負(fù)載的I/O可擴(kuò)展性

如圖16所示，在1個節(jié)點上測量的物理I/O數(shù)量為2,185，但是，LS20刀片并不局限于此。這是一個Oracle OLTP工作負(fù)載，在交易層處理從磁盤讀入數(shù)據(jù)時，包含了大量CPU密集型工作。無需運行生成I/O請求的全處理器密集型交易工作負(fù)載，即可測量一個服務(wù)器能夠處理的Oracle OLTP I/O的最大理論值。Orion測試工具包可以用于此類測量。

Oracle I/O工作負(fù)載(Orion)

Orion代表Oracle IO數(shù)量?？梢詮腛racle網(wǎng)站上獲得Orion¹⁰。簡言之，Orion工具包由在生產(chǎn)中運行Oracle時執(zhí)行I/O的實際服務(wù)器代碼組成。它還帶有一個驅(qū)動這些具有不同工作負(fù)載性質(zhì)（例如，大量連續(xù)掃描和隨機(jī)單塊傳輸）的I/O例程層。如需深入了解Orion測試工具包，請訪問Oracle網(wǎng)站上的Orion Web頁面。

為了在單一LS20節(jié)點上測試單節(jié)點Oracle服務(wù)器OLTP讀取吞吐率的理論最大值，我們在PolyServe Matrix Server集群文件系統(tǒng)中創(chuàng)建一個256GB的Orion文件，并通過直接I/O進(jìn)行訪問。

Orion測試顯示，單一LS20刀片服務(wù)器每秒能夠從256GB文件中完成9,496次隨機(jī)的4KB傳輸。因為目標(biāo)文件要比TotalStorage陣列緩存大得多，Orion測量的每秒9,496次操作的I/O延遲為10.12ms。此測說明，LS20中的I/O子系統(tǒng)完全能夠滿足完成OLTP I/O請求的要求–事實上，對于全Oracle Server的驅(qū)動程度比以往要高得多。

10 http://www.oracle.com/technology/software/tech/orion/index.html。

Page 20:

總結(jié)

IBM BladeCenter H、PolyServe Matrix Server和Oracle10g RAC相互協(xié)作，使靈活數(shù)據(jù)庫集群成為了一個支持多應(yīng)用的強(qiáng)大平臺。本文中提供的FDC分析驗證了FDC架構(gòu)和技術(shù)，并證實了以下內(nèi)容：

• l 在IBM BladeCenter H為PolyServe Matrix Server和Oracle10g RAC提供了全面支持。
• l BladeCenter架構(gòu)和技術(shù)，為實施靈活數(shù)據(jù)庫集群提供了一個具有無與倫比的高可用性的平臺。
• l IBM、PolyServe和Oracle是擴(kuò)展計算的技術(shù)開發(fā)領(lǐng)先企業(yè)。
• l 靈活數(shù)據(jù)庫集群架構(gòu)和技術(shù)支持隨需應(yīng)變的計算。集群節(jié)點提供了供各應(yīng)用使用的靈活的資源池，而且Oracle10g RAC的可用性得到了提高，因為通過使用Matrix Server，可以動態(tài)地重新配置節(jié)點，彌補(bǔ)其他節(jié)點的損失。
• l 靈活數(shù)據(jù)庫集群提供了Matrix Server等強(qiáng)大的管理工具，從而提高了性能和可用性。單一的大集群要比眾多小集群易于管理。
• l 像Matrix Server中所包含的集群文件系統(tǒng)那樣的通用集群文件系統(tǒng)，提供了單一系統(tǒng)的感覺，顯著增強(qiáng)了可管理性。由所有節(jié)點共同使用的共享Oracle主頁也簡化了管理。提供了可用于所有需要文件系統(tǒng)的數(shù)據(jù)庫操作的支持。
• l 改善的FDC集群可管理性、可擴(kuò)展性、延伸性、可用性和資產(chǎn)利用率，還顯著降低了總擁有成本。

Page 21:

©2006年，IBM及其他公司版權(quán)所有。

IBM Systems and Technology Group

Department 23U

Research Triangle Park, NC 27709

美國制造

4-06

保留所有權(quán)利。

如需有關(guān)安全和有效計算方面的最新信息，請定期訪問www.ibm.com/pc/safecomputing如需獲得適當(dāng)產(chǎn)品的保修副本，請寫信至：Warranty Information, P.O. Box 12195, RTP, NC 27709, Attn: Dept. JDJA/B203。IBM 對于有關(guān)第三方產(chǎn)品或服務(wù)（包括指定為ServerProven或ClusterProven的產(chǎn)品或服務(wù)）不作任何聲明或保證。

IBM、八條杠標(biāo)志、xSeries、BladeCenter、BladeCenter H、ServerProven和TotalStorage是國際商業(yè)機(jī)器公司在美國和/或其他國家的商標(biāo)或注冊商標(biāo)。如需其他IBM商標(biāo)清單，請訪問：http://www.ibm.com/legal/copytrade.shtml。

AMD和皓龍是Advanced Micro Devices公司的商標(biāo)或注冊商標(biāo)。

Oracle和Oracle10g Java是Oracle公司的商標(biāo)或注冊商標(biāo)。

UNIX是The Open Group在美國和/或其他國家的注冊商標(biāo)。

PolyServe和PolyServe標(biāo)志是PolyServe公司的商標(biāo)。

其他公司、產(chǎn)品或服務(wù)的名稱可能是其他公司的商標(biāo)或服務(wù)標(biāo)志。

本文中有關(guān)非 IBM 產(chǎn)品的信息來自于那些產(chǎn)品的制造商或他們發(fā)布的聲明。IBM 尚未對這些產(chǎn)品進(jìn)行測試，因此無法證實其性能、兼容性或任何與非 IBM 產(chǎn)品相關(guān)的聲明。有關(guān)非 IBM 產(chǎn)品性能的問題應(yīng)該由那些產(chǎn)品的供應(yīng)商解決。

IBM保留改變規(guī)范或其他產(chǎn)品信息的權(quán)利，無需另行通知。本文引用了 IBM 的產(chǎn)品或服務(wù)，但并不意味著 IBM 計劃在公司業(yè)務(wù)涉及的所有國家提供這些產(chǎn)品或服務(wù)。IBM是"按原樣"提供此出版物，并不提供任何明示或暗含的保證，包括對于適銷和適用于某種特定用途的暗示保證。有些國家或地區(qū)不允許在免責(zé)聲明中對于某些交易進(jìn)行明示或暗示保證，所以，此聲明可能對您并不適用。

此出版物可能包含到第三方站點的鏈接，它們不受IBM的控制或由IBM維護(hù)。訪問任何第三方網(wǎng)站的風(fēng)險由用戶自行承擔(dān)，且IBM不對這些網(wǎng)站上的任何信息、數(shù)據(jù)、觀點、建議或聲明的準(zhǔn)確性和可靠性負(fù)責(zé)。IBM只是將這些鏈接作為一種方便條件提供，包含這種站點的鏈接并不意味著對其的認(rèn)可。

本文僅用于提供信息的目的，對于由PolyServe公司提供或?qū)⒁峁┑娜魏诬浖?、軟件特性或服?wù)不提供任何明示或暗示的保證。PolyServe公司保留隨時更改本文的權(quán)利，無需另行通知，且不對其使用負(fù)責(zé)。此信息文檔中描述的特性可能目前尚未上市。如需有關(guān)特性和產(chǎn)品可用性的信息，請聯(lián)系PolyServe公司總部。

IBM TotalStorage                IBM Server Proven

多易