Hyper-V
Oracle 資料庫容錯移轉搭配 SnapMirror 主動式同步
建議變更
PDF
在 SnapMirror 主動式同步上託管 Oracle 資料庫的主要原因、是在計畫性和非計畫性儲存事件期間提供透明的容錯移轉。
SnapMirror 主動式同步支援兩種儲存容錯移轉作業：計畫性和非計畫性、運作方式略有不同。系統管理員會手動啟動計畫性容錯移轉、以快速切換至遠端站台、而非計畫性容錯移轉則由第三站台的協調員自動啟動。計畫性容錯移轉的主要目的是執行漸進式修補與升級、執行災難恢復測試、或是採用正式的原則、在一年內在站台之間切換作業、以證明完整的主動式同步功能。
下圖顯示正常、容錯移轉及容錯回復作業期間的情況。為了便於說明、它們描述了複寫的 LUN 。在實際的 SnapMirror 主動式同步組態中、複寫是以磁碟區為基礎、其中每個磁碟區都包含一個或多個 LUN 、但為了讓圖片更簡單、磁碟區層已經移除。
正常運作
在正常作業中、可以從本機或遠端複本存取 LUN 。紅色線表示 ALUA 所通告的最佳化路徑、結果應該是 IO 優先傳送至此路徑。
綠線是一條活動路徑，但由於該路徑上的 IO 需要通過 SnapMirror 活動同步路徑傳遞，因此會產生更多延遲。額外的延遲時間取決於用於 SnapMirror 主動同步的站台之間互連的速度。
故障
如果主動鏡像複本因為計畫性或非計畫性容錯移轉而無法使用、則顯然無法再使用。然而、遠端系統已擁有通往遠端站台的同步複本和 SAN 路徑。遠端系統能夠為該 LUN 提供 IO 服務。
容錯移轉
容錯移轉會導致遠端複本變成使用中複本。路徑會從「 Active 」變更為「 Active/Optimized 」、 IO 也會持續提供服務、不會遺失資料。
修復
一旦來源系統恢復服務、 SnapMirror 主動式同步就能重新同步複寫、但會執行其他方向。現在的組態基本上與起點相同、只是主動鏡射站台已經翻轉。
容錯回復
如果需要、管理員可以執行容錯回復、並將 LUN 的作用中複本移回原始控制器。