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

TR-4614:SAP HANA備份與還原SnapCenter 功能搭配使用

貢獻者

NetApp公司Nils Bauer

現今的企業需要持續且不中斷的SAP應用程式可用度。他們期望面對不斷增加的資料量、以及系統備份等例行維護工作的需求、能達到一致的效能等級。執行SAP資料庫備份是一項重要工作、可能對正式作業SAP系統造成重大效能影響。

備份時間越來越短、而要備份的資料量卻越來越多。因此、很難找到能夠在對業務程序影響最小的情況下執行備份的時間。還原及還原SAP系統所需的時間是一項重大考量、因為必須將SAP正式作業與非正式作業系統的停機時間降至最低、以減少資料遺失及企業成本。

以下各點概述SAP備份與還原所面臨的挑戰:

  • *效能對正式作業SAP系統的影響。*傳統的複製型備份通常會因為資料庫伺服器、儲存系統和儲存網路承受沉重的負載、而在正式作業SAP系統上造成顯著的效能消耗。

  • *縮減備份時間。*只有在SAP系統上進行的對話或批次活動很少時、才能進行傳統備份。當SAP系統全天候使用時、備份排程變得更加困難。

  • *快速資料成長*快速資料成長與縮減備份時間、需要持續投資備份基礎架構。換句話說、您必須採購更多磁帶機、額外的備份磁碟空間、以及更快的備份網路。您也必須支付儲存及管理這些磁帶資產的持續費用。遞增或差異備份可以解決這些問題、但這種安排會造成非常緩慢、繁瑣且複雜的還原程序、難以驗證。這類系統通常會以企業無法接受的方式、增加恢復時間目標(RTO)和恢復點目標(RPO)的時間。

  • 停機成本增加。 SAP系統的非計畫性停機通常會影響企業財務。在任何非計畫性停機中、有一大部分是因為還原和恢復SAP系統的需求而耗用。因此、所需的RTO決定了備份與還原架構的設計。

  • * SAP升級專案的備份與還原時間。* SAP升級專案計畫至少包含三個SAP資料庫備份。這些備份可大幅縮短升級程序的可用時間。決定繼續進行的時間通常取決於從先前建立的備份還原及還原資料庫所需的時間。快速還原不只是將系統還原至先前的狀態、更能提供更多時間來解決升級期間可能發生的問題。

NetApp解決方案

NetApp Snapshot技術可在幾分鐘內建立資料庫備份。建立Snapshot複本所需的時間與資料庫大小無關、因為Snapshot複本不會在儲存平台上移動任何實體資料區塊。此外、使用Snapshot技術對即時SAP系統沒有任何效能影響、因為NetApp Snapshot技術在建立Snapshot複本或變更作用中檔案系統中的資料時、不會移動或複製資料區塊。因此、建立Snapshot複本的排程不需考慮尖峰對話或批次活動期間。SAP與NetApp客戶通常會在一天內排程多個線上Snapshot備份、例如、每四小時一次就很常見。這些Snapshot備份通常會在主要儲存系統上保留三到五天、然後再移除。

Snapshot複本也為還原與還原作業提供重要優勢。NetApp SnapRestore 支援資料恢復軟體、可根據可用的Snapshot複本、將整個資料庫或部分資料庫還原至任何時間點。這類還原程序只需幾分鐘就能完成、不受資料庫大小限制。由於每天都會建立數個線上Snapshot備份、因此相較於傳統備份方法、還原程序所需的時間會大幅縮短。由於只需幾小時(而非24小時)的Snapshot複本即可執行還原、因此必須套用較少的交易記錄。因此、RTO可縮短至數分鐘、而非傳統單週期磁帶備份所需的數小時。

Snapshot複本備份與作用中的線上資料儲存在相同的磁碟系統上。因此、NetApp建議使用Snapshot複本備份做為補充、而非取代次要位置的備份。大部分的還原和還原動作都是使用SnapRestore 主儲存系統上的功能進行處理。只有當包含Snapshot複本的主要儲存系統毀損時、才需要從次要位置進行還原。如果需要還原從Snapshot複本(例如月底備份)中無法使用的備份、也可以使用次要位置。

備份到次要位置的基礎是在主要儲存設備上建立的Snapshot複本。因此、資料會直接從主要儲存系統讀取、而不會在SAP資料庫伺服器上產生負載。主儲存設備會直接與二線儲存設備通訊、並使用NetApp SnapVault ®磁碟對磁碟備份、將備份資料傳送至目的地。

與傳統備份相比、此技術提供顯著優勢。SnapVault在初始資料傳輸(所有資料都已從來源傳輸至目的地)之後、所有後續備份只會將變更的區塊複製到次要儲存設備。因此、主儲存系統的負載和完整備份所需的時間會大幅減少。由於僅將變更的區塊儲存在目的地、因此完整資料庫備份所需的磁碟空間較少。SnapVault

此解決方案也可無縫延伸至混合雲營運模式。用於災難恢復或異地備份的資料複寫、可從內部部署的NetApp ONTAP 支援系統、到Cloud Volumes ONTAP 雲端執行的執行個體、都能完成。您可以使用SnapCenter 「不受限於SAP HANA系統在內部部署或雲端上執行、而將「不受限」功能當作管理資料保護和資料複寫的集中工具。下圖顯示備份解決方案的總覽。

錯誤:缺少圖形影像

Snapshot備份的執行時間

下一個快照顯示客戶在NetApp儲存設備上執行SAP HANA的HANA Studio。客戶使用Snapshot複本來備份HANA資料庫。此影像顯示HANA資料庫(大小約2.3TB)使用Snapshot備份技術、可在2分鐘11秒內完成備份。

註 整體備份工作流程執行時間最大的一部分是執行HANA備份儲存點作業所需的時間、而此步驟取決於HANA資料庫的負載。儲存Snapshot備份本身一律會在幾秒鐘內完成。

錯誤:缺少圖形影像

恢復時間目標比較

本節提供檔案型與儲存型Snapshot備份的RTO比較。RTO是根據還原資料庫所需的時間總和、以及啟動及還原資料庫所需的時間所定義。

還原資料庫所需的時間

使用檔案型備份時、還原時間取決於資料庫和備份基礎架構的大小、而備份基礎架構會以每秒MB為單位來定義還原速度。例如、如果基礎架構支援以250Mbps速度進行還原作業、則還原資料庫的大小為1TB約需1小時10分鐘。

有了儲存Snapshot複本備份、還原時間將不受資料庫大小限制、而且可以從主要儲存設備執行還原、時間範圍在幾秒鐘內。只有當主要儲存設備無法使用時、才需要從次要儲存設備進行還原。

啟動資料庫所需的時間

資料庫開始時間取決於列和欄儲存區的大小。對於欄儲存區、開始時間也取決於資料庫啟動期間預先載入的資料量。在下列範例中、我們假設開始時間為30分鐘。檔案型還原與還原的開始時間與根據Snapshot進行還原與還原的開始時間相同。

恢復資料庫所需的時間

恢復時間取決於還原後必須套用的記錄數目。此數字取決於資料備份的頻率。

使用檔案型資料備份時、備份排程通常每天一次。備份頻率通常無法提高、因為備份會降低正式作業效能。因此、在最糟的情況下、一天內寫入的所有記錄都必須在轉送恢復期間套用。

儲存Snapshot複製資料備份通常會以較高的頻率排程、因為它們不會影響SAP HANA資料庫的效能。例如、如果每六小時排程一次Snapshot複本備份、則在最糟的情況下、還原時間是檔案型備份的恢復時間的四分之一(6小時/ 24小時= 1/4)。

下圖顯示使用檔案型資料備份時、1TB資料庫的RTO範例。在此範例中、每天會進行一次備份。RTO會因執行還原與還原的時間而有所不同。如果在備份完成後立即執行還原與還原、RTO主要是以還原時間為基礎、範例中的還原時間為1小時10分鐘。恢復時間增加至2小時50分鐘、在進行下一次備份之前立即執行還原與還原、最大RTO為4小時30分鐘。

錯誤:缺少圖形影像

下圖顯示使用Snapshot備份時1TB資料庫的RTO範例。使用儲存型Snapshot備份時、RTO僅取決於資料庫的開始時間和轉送恢復時間、因為還原只需幾秒鐘就完成、而且不受資料庫大小限制。轉送恢復時間也會隨還原與還原的完成時間而增加、但由於備份頻率較高(本例中每六小時一次)、轉送恢復時間最多為43分鐘。在此範例中、RTO上限為1小時13分鐘。

錯誤:缺少圖形影像

下圖顯示不同資料庫大小和Snapshot備份頻率的檔案型與儲存型Snapshot備份RTO比較。綠色列會顯示檔案型備份。其他長條圖則會顯示具有不同備份頻率的Snapshot複本備份。

與檔案型資料備份相比、每天只需備份一次Snapshot複本資料、RTO已減少40%。每天進行四次Snapshot備份時、減少量會增加至70%。圖中也顯示、如果您將Snapshot備份頻率增加到每天四到六個以上的Snapshot備份、曲線就會變平。因此、我們的客戶通常每天設定四到六個Snapshot備份。

錯誤:缺少圖形影像

註 圖表顯示HANA伺服器的RAM大小。記憶體中的資料庫大小是伺服器RAM大小的一半。
註 還原與還原時間是根據下列假設來計算。資料庫可還原為250Mbps。每天的記錄檔數為資料庫大小的50%。例如、1TB資料庫每天會建立500MB的記錄檔。恢復速度可達100Mbps。