Skip to main content
NetApp Solutions SAP
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

系統重新整理、複製及複製的使用案例

貢獻者

在多種情況下、來源系統的資料必須提供給目標系統以供測試或訓練之用。這些測試與訓練系統必須定期更新來源系統的資料、以確保使用目前的資料集進行測試與訓練。

這些系統重新整理作業包含基礎架構、資料庫和應用程式層上的多項工作、視自動化程度而定、可能需要多天的時間。

此影像說明從主要開發環境到暫時性專案分割、修復系統、訓練系統和SANbox系統的環境工作流程。它會顯示系統更新、系統複製和系統複製用於這些不同用途的位置。

SAP Lama和NetApp複製工作流程可用於加速及自動化基礎架構和資料庫層的必要工作。SAP Lama不需要將備份從來源系統還原至目標系統、而是使用NetApp Snapshot複本和NetApp FlexClone技術、因此可在數分鐘內完成所需的工作、而非數小時內完成、如下圖所示。複製程序所需的時間與資料庫大小無關、因此即使是非常大型的系統、也能在幾分鐘內建立完成。透過自動化作業系統和資料庫層以及SAP後處理端的工作、進一步縮短執行時間。

此映像顯示使用和不使用NetApp Snapshot複本的複製程序與NetApp FlexClone技術之間的比較、可大幅加快程序的執行速度。

解決邏輯毀損問題

邏輯毀損可能是由軟體錯誤、人為錯誤或破壞所造成。遺憾的是、邏輯毀損問題通常無法透過標準的高可用度與災難恢復解決方案來解決。因此、視發生邏輯毀損的層級、應用程式、檔案系統或儲存設備而定、有時無法滿足最短的停機時間和可接受的資料遺失需求。

最糟的情況是SAP應用程式的邏輯毀損。SAP應用程式通常會在不同應用程式彼此通訊及交換資料的環境中運作。因此、還原及還原發生邏輯毀損的SAP系統並非建議的方法。將系統還原至毀損發生前的某個時間點、會導致資料遺失。此外、SAP環境也不再同步、需要額外的後處理。

與其還原SAP系統、更好的方法是嘗試在個別的修復系統中分析問題、以修正系統內的邏輯錯誤。根本原因分析需要業務程序和應用程式擁有者的參與。在此案例中、您會根據邏輯毀損發生之前所儲存的資料、建立修復系統(正式作業系統的複本)。在修復系統中、所需的資料可匯出並匯入正式作業系統。使用這種方法、不需要停止正式作業系統、而且在最佳情況下、不會遺失任何資料或只會遺失一小部分資料。

在設定修復系統時、靈活度和速度是關鍵。有了NetApp儲存型Snapshot備份、就能使用NetApp FlexClone技術建立多個一致的資料庫映像、以建立正式作業系統的複本。如果使用檔案型備份的重新導向還原來設定修復系統、則FlexClone磁碟區可在數秒內建立、而非數小時內建立。

此映像說明使用FlexClone技術從複製系統建立修復系統的逐步程序。

災難恢復測試

有效的災難恢復策略需要測試所需的工作流程。測試可證明策略是否有效、以及內部文件是否足夠。此外、系統管理員也能訓練所需的程序。

使用SnapMirror進行儲存複寫、可在不影響RTO和RPO的情況下執行災難恢復測試。災難恢復測試可在不中斷資料複寫的情況下執行。非同步和同步SnapMirror的災難恢復測試會在災難恢復目標上使用Snapshot備份和FlexClone磁碟區。

SAP Lama可用來協調整個測試程序、也可負責網路隔離、目標主機維護等。

此映像描述一線資料中心的NetApp儲存系統、本機災難恢復資料中心和遠端災難恢復資料中心之間的關係。它們同時透過同步SnapMirror和非同步SnapMirror關係進行連線。