Oracle Extended RAC
建議變更
PDF
許多客戶透過在各個站台之間延伸 Oracle RAC 叢集來最佳化 RTO 、進而實現完全主動式的組態。整體設計變得更複雜、因為它必須包含 Oracle RAC 的仲裁管理。
傳統的延伸 RAC 叢集式仰賴 ASM 鏡射來提供資料保護。這種方法可行、但也需要大量手動設定步驟、並對網路基礎架構造成負擔。相反地、讓 SnapMirror 主動式同步處理負責資料複寫、可大幅簡化解決方案。同步、中斷後重新同步、容錯移轉和仲裁管理等作業都變得更簡單、而且 SAN 不需要分散在各個站台上、如此就能簡化 SAN 的設計與管理。
複寫
瞭解 SnapMirror 主動式同步上的 RAC 功能的關鍵在於將儲存裝置視為單一 LUN 集、並以鏡射儲存設備為主控。例如：
沒有主要複本或鏡射複本。從邏輯上來說、每個 LUN 只有一個複本、而位於兩個不同儲存系統上的 SAN 路徑上則有該 LUN 可用。從主機的角度來看、沒有儲存容錯移轉、而是有路徑變更。當其他路徑保持連線時、各種故障事件可能會導致通往 LUN 的特定路徑遺失。SnapMirror 主動式同步可確保所有作業路徑都能使用相同的資料。
儲存組態
在此範例組態中、 ASM 磁碟的組態與企業儲存設備上任何單站台 RAC 組態的組態相同。由於儲存系統提供資料保護、因此會使用 ASM 外部備援。
統一存取與不通知存取
在 SnapMirror 主動式同步上使用 Oracle RAC 最重要的考量、是使用統一或非統一存取。
統一存取意味著每個主機都可以看到兩個叢集上的路徑。非統一存取表示主機只能看到本機叢集的路徑。
這兩個選項都不是特別推薦或不鼓勵的。有些客戶可以隨時連線到網站、有些客戶可能沒有這種連線能力、或是他們的 SAN 基礎架構不支援長距離 ISL 。
不一致的存取
從 SAN 的角度來看、不一致的存取更容易設定。
此方法的主要缺點"不一致的存取"是、站台對站台 ONTAP 連線中斷或儲存系統遺失、將導致一個站台的資料庫執行個體遺失。這顯然不是理想的做法、但在交換較簡單的 SAN 組態時、這可能是可接受的風險。
統一存取
統一存取需要將 SAN 延伸至各個站台。主要優點是儲存系統的遺失不會導致資料庫執行個體遺失。相反地、它會導致路徑目前正在使用的多重路徑變更。
有幾種方法可以設定不一致的存取。
|
在下圖中、也會出現一些作用中但未最佳化的路徑、這些路徑會在簡單的控制器故障期間使用、但這些路徑並不代表簡化圖表的目的。 |
具有鄰近設定的 AFF
如果站台之間存在嚴重延遲、則可以使用主機鄰近設定來設定 AFF 系統。如此一來、每個儲存系統就能知道哪些主機是本機主機、哪些是遠端主機、並適當地指派路徑優先順序。
在正常作業中、每個 Oracle 執行個體都會優先使用本機主動 / 最佳化路徑。結果是所有讀取都會由區塊的本機複本提供服務。這會產生最低的可能延遲。寫入 IO 也同樣會向下傳送至本機控制器的路徑。在確認之前必須複寫 IO 、因此仍會產生跨越站台對站台網路的額外延遲、但在同步複寫解決方案中無法避免這種情況。
ASA / AFF 不含感應設定
如果站台之間沒有明顯的延遲、則可在不設定主機鄰近設定的情況下設定 AFF 系統、或使用 ASA 。
每個主機都可以使用兩個儲存系統上的所有作業路徑。如此一來、每部主機就能充分發揮兩個叢集的效能潛力、而不只是一個叢集、進而大幅提升效能。
有了 ASA 、不僅兩個叢集的所有路徑都會視為作用中且最佳化、而且合作夥伴控制器上的路徑也會是作用中的。結果是整個叢集上的全作用中 SAN 路徑、
|
|
ASA 系統也可用於非統一存取組態。由於不存在跨站台路徑、因此透過 ISL 的 IO 不會影響效能。 |