Oracle RAC的機制與測試方法

 

Oracle RAC的機制與測試方法

標籤： rac 機制 測試

2016-05-25 09:54 1150人閱讀 評論(0) 收藏 舉報

 分類：

oracle（2） 

 

1.RAC原理

Oracle 數據庫系統是美國oracle公司（甲骨文股份有限公司）提供的以分佈式數據庫爲核心的一組軟件產品，是目前最流行的客戶/服務器(CLIENT/SERVER)或B/S體系結構的數據庫之一,至今仍在數據庫市場上佔有主要份額。

1.1 RAC原理

對於每一個軟件相關從業人員來講，都有必要了解一下Oracle數據庫，下面我將對Oracle RAC原理作以下介紹。

Oracle RAC是Oracle Real Application Cluster的簡寫，官方中文文檔通常翻譯爲「真正應用集羣」。RAC集羣是由若干物理機組成，每一個物理機爲一個節點，這些節點間經過網線鏈接（也叫心跳網絡）。每一個節點上都運行一個實例，這些實例經過CRS（CRS經過一系列的進程和服務來保證集羣的運行，提供高可用性）的協助，共同操做一個數據庫,是一個典型的「多實例，單數據庫」架構，數據庫被全部節點共享、並行訪問。共享存儲是RAC架構的核心。數據庫的數據文件、控制文件、參數文件、重作日誌文件等等都要放到共享存儲上，各節點能夠對這些文件進行並行訪問。若是其中某個節點發生故障，RAC可以將鏈接自動切換到另一個節點上，無單點故障問題，從而實現應用的無縫切換。

下圖爲基本的RAC拓撲圖：

 

 

2.RAC 特性

依上文所說，RAC是一堆特性應用的集合，下面重點介紹幾個特性：VIP漂移、腦裂和IO隔離。

2.1 VIP漂移特性

這裏有必要解釋下RAC爲何要使用VIP地址：在TCP/IP四層模型中，TCP header中最重要的信息是源端口和目標端口，IP header 中記錄的最重要的信息是源IP和目標IP地址，而數據庫監聽中記錄了IP地址和端口號，位於應用層，因此客戶端的鏈接請求只有發現TCP層超時才能感知數據庫或者是監聽出了問題。TCP/IP協議棧超時，其時間閥值由OS內核決定，每一個操做心跳的閥值不相同。爲了解決TCP/IP協議棧超時問題，Oracle RAC引進了VIP。

VIP 和通常的IP不一樣的是：通常的IP是固定到物理網卡上的，VIP是浮動的。一旦某個節點出現了故障，其上運行的VIP會漂移到活着的節點上，可是活着的節點上的監聽裏找不到該VIP的地址。應用程序立馬會感知到，並向其餘VIP地址發起鏈接請求。捕獲錯誤的時間大大縮短。

VIP漂移原理：假設有兩個節點的RAC，分別是節點1和節點2。正常運行時節點1上有VIP1，節點2上有VIP2 ；當節點1發生故障，RAC 會作以下操做：

1） CRS 在檢測到節點1異常後，會觸發Clusterware 重構，最後把節點1剔除集羣，由節點2組成新的集羣。  

2）RAC的Failover 機制會把節點1的VIP轉移到節點2上（也就是VIP漂移），這時節點2的PUBLIC 網卡上就有3個IP 地址： VIP一、VIP二、PUBLIC IP2。

3）用戶對VIP1的鏈接請求會被IP層路由轉到節點2。

4）由於在節點2上有VIP1的地址，全部數據包會順利經過路由層、網絡層、傳輸層。    

5）可是節點2上只監聽VIP2和PUBLIC IP2的兩個IP地址。並無監聽VIP1，故應用層沒有對應的程序接收這個數據包，這個錯誤當即被捕獲。

6）客戶端可以當即接收到這個錯誤，以後客戶端會從新發起向VIP2的鏈接請求。VIP2就自動接管交易處理。

2.2 腦裂

在集羣環境中，節點間須要心跳機制瞭解彼此的健康情況，假如心跳出了故障，就會出現腦裂。這時每一個節點還在正常運行，每一個節點都會認爲其餘節點都不復存在，本身是惟一的倖存者，以後就會控制整個集羣。數據是共享的，若是每一個節點都想控制獨享，勢必會破壞共享數據的完整性和一致性。這樣的情況就是腦裂。

爲了解決這個腦裂問題，經過投票機制，得到高票數或是最先到達的得到投票，倖存，其餘節點被踢出。Oracle RAC中的Voting Disk用來記錄節點間成員狀態，出現腦裂時，仲裁哪一個節點得到控制權，其餘的節點被剔除。

2.3 IO隔離

IO隔離是上一個問題的延伸，投票機制雖然已經判斷出哪一個成節點該得到集羣掌控權，哪些節點被剔除，但僅僅這樣作是不夠的，還必須保證被剔除的節點不能操做共享數據。爲了限制已踢出節點對共享數據的訪問，必須進行IO隔離。Oracle RAC採起的是直接重啓故障節點。

3.RAC測試案例

上文介紹了RAC的原理以及三個特性，下面我將重點講解「如何在測試中測試RAC的有效性」。

3.1 測試案例1名稱：RAC有效性測試-異常關機

測試目的：

驗證系統數據庫RAC中的一個節點發生故障後，另外一個節點可否自動接管交易處理；以及故障恢復後，節點處理能力可否恢復正常。

測試方法：

1）使用HP LoadRunner模擬客戶發壓,按照混合模型的比例,以被測試系統最大處理能力的50%做爲負載壓力向被測試系統施壓，待系統穩定運行5分鐘；

2）在某一臺數據庫服務器上手工執行halt -q(不一樣OS命令有區別)，模擬異常宕機；

3）繼續穩定運行5分鐘；

4）恢復故障節點，同時啓動該節點上的Oracle 實例；

5）繼續穩定運行5分鐘；

6）執行回切操做。

預期測試結果：

1）步驟3後被測試系統數據庫RAC切換成功，切換過程當中，交易響應時間延長

2）切換後VIP漂移到另外一個實例；

3）交易在1分鐘內可以100%恢復正常，交易錯誤率、響應時間均知足測試指標，各主機資源使用正常；

4）步驟5後故障節點恢復後，該節點實例不接管交易，鏈接也不恢復，該實例不處理交易；

5）步驟7後執行回切操做後，服務器狀態恢復爲初始狀態，交易由原主機處理並穩定運行。

實際測試結果：

 

LoadRunner整體趨勢圖

 

節點1： CPU趨勢圖

 

節點2：CPU趨勢圖

查看VIP是否漂移，當節點1故障後，查看節點2的網卡上有節點1的VIP地址，說明節點1的VIP地址漂移到節點2的網卡上。

 

 

測試結果分析：

從上述測試結果的圖表和日誌截圖能夠清楚的看到：節點1模擬宕機後，RAC切換成功，節點1的VIP 漂移至節點2；TPS降低，交易有少許失敗，40秒內TPS徹底恢復。

恢復節點1後，交易由原主機節點1處理並穩定運行。

測試結果符合預期結果，測試結果經過。

3.2 測試案例2名稱：RAC有效性測試-停實例(shutdown abort)

測試目的：

考察系統在必定併發下,手動異常中止一個數據庫實例後，另外一個數據庫實例可否自動接管交易處理；以及故障恢復後，節點處理能力可否恢復正常。

測試方法：

1）使用測試工具LoadRunner發壓，按照混合測試場景中交易的比例,以被測試系統最大處理能力的50%做爲負載壓力向被測試系統施壓，穩定運行5分鐘；

2）手動（shutdown abort）中止一個數據庫實例，場景持續運行5分鐘；

3）啓動中止的數據庫實例，場景持續運行5分鐘；

4）執行回切操做，場景持續運行5分鐘。

預期測試結果：

1.步驟2手動中止數據庫實例後，另外一節點實例會很快接收請求（Failover機制生效）。切換後停掉實例的節點，CPU、IO降低；正常接收交易實例的節點，CPU、IO上升。MTTR（平均失效恢復時間）小於1分鐘，失效交易處理能力恢復水平99.99%；

2.步驟3重啓中止節點實例後，鏈接正常，與切換後保持一致；

3.執行回切操做後，服務器狀態恢復爲初始狀態，交易由原主機處理， 並穩定運行。

實際測試結果：

 

LoadRunner整體趨勢圖

 

節點1：128.196.36.22 CPU利用率圖

 

節點2：128.196.36.25  CPU利用率圖

測試結果分析：

1）手動中止節點1實例後，節點2實例會很快（2秒內）接收請求。停掉實例的節點1 ，CPU、IO降低，接收交易的節點2，CPU、IO上升；交易有少許失敗，在20秒內TPS徹底恢復；

2）重啓節點1實例後，AP爲長鏈接，該實例的鏈接不恢復；交易不受影響；

3）執行回切操做後，TPS降低，交易有少許失敗，40秒內TPS徹底恢復，交易由原主機節點1處理，並穩定運行；

4）實際測試結果符合預期結果，測試結果經過。

3.3 測試案例3名稱：AC有效性測試-心跳網絡異常

測試目的：

驗證數據庫RAC中的心跳網絡（主備網卡置down）異常後，另外一節點可否自動接管交易處理；以及故障恢復後，節點處理能力可否恢復正常。

測試方法：

1）使用測試工具LoadRunner發壓，按照混合模型的比例以被測試系統最大處理能力的50%做爲負載壓力向被測試系統施壓；

2）場景平穩運行5分鐘時，將節點1的網卡置down，觀察各交易錯誤率、處理能力、響應時間及各主機資源狀況；驗證VIP是否能夠正常切換；

3）恢復該節點心跳主備網卡，重啓CRS，交易穩定運行5分鐘，觀察被測試系統交易恢復狀況；

4）場景結束，分析和記錄測試結果。

預期測試結果：

1）步驟2後，實例名權重大的實例重啓，主機不重啓；

2）步驟3後，CRS能正常啓動，數據庫可正常啓動並加入RAC。

實際測試結果：

 

TPS趨勢圖

 

節點1：CPU趨勢圖

 

節點2：CPU趨勢圖

測試結果分析

1）宕掉節點1的心跳主備網卡，出現腦裂，節點2實例重啓，CRS重啓，節點2的VIP漂移到節點1；TPS降低，交易有少許失敗，在50秒內TPS徹底恢復至100%。

2）節點1心跳主備網卡故障恢復後，VIP回漂，數據庫可正常啓動並加入RAC，交易不受影響。

3）實際測試結果符合預期結果，測試結果經過。

從以上三個案例能夠看出：若是其中某個節點發生故障，RAC可以自動切換到另一個節點上，無單點故障問題。