SAP容災系統上云,sap異地容災

SAP災難恢復系統上的云

01

隨著信息技術在全球的發展和應用，SAP系統作為全球排名第一的ERP企業資源計劃軟件，依托其系統化的管理理論和信息技術，打造信息管理系統平臺，輔助公司進行決策和管理。SAP系統的可用性和穩定性是保證企業核心業務的前提，因此企業往往在設計和構建SAP系統架構上投入很大的成本。生產機器的高可用性是基本的配置要求，異地容災經常被一些要求高的客戶使用。

以一套S/4生產系統架構為例，最佳實踐建議采用HA/DR部署模式，提供高系統可用性。

1。高可用性

2。災難恢復

現實中，國內還有很多企業，他們的SAP ERP/ S/4等生產機器還沒有部署容災系統，并不代表他們不需要容災來提供生產業務的保障。但是，用SAP系統構建異地容災系統的成本往往很高，傳統的部署方式要考慮是否異地部署，建設數據中心，購買設備齊全的生產硬件，連接獨立的線路。這些都是傳統企業面臨的IT成本投入巨大，業務需求難以平衡的問題。

隨著云技術的發展，SAP容災云解決了這三個問題:

Azure為國內客戶提供了北京和上海的選擇，輕松滿足SAP異地容災需求。

Azure客戶可以重用現有的ER專線進行數據同步，也可以使用互聯網S2S VPN連接到云服務器進行數據同步。

通過在云上使用靈活的配置功能，日常容災系統只需要打開數據庫的最低配置就可以滿足數據同步需求。當需要切換容災系統時，會根據需要拉起應用服務器系統，并擴展數據庫機配置。

02

在了解SAP容災之前，我們先來談談兩個指標RTO和RPO，容災架構設計的關鍵要求:

RPO(恢復點目標):即數據恢復點目標，主要指業務系統可以容忍的數據丟失。災難發生后，兩個點之間的時間段稱為RTO，從IT系統關閉、業務停止開始，到IT系統恢復并能支持各部門運行為止。

RTO(Recovery Time Objective):即恢復時間目標，主要指業務停止服務的最長可容忍時間，即從災難發生到業務系統服務功能恢復的最短時間段。

具體示例請參考以下樣式:

技術上，我們如何在本地和云上實現SAP系統的容災部署

首先，我們來看看本地數據中心和Azure網絡之間的連接。SAP上的云場景一般采用兩種連接方式:

1。ER專線連接安全、穩定、專屬

對于sap系統，如客戶總部或核心工廠，或者客戶有非SAP解決方案且SAP系統混合在azure cloud中，單獨為SAP核心系統使用一條專線，建議使用獨立專線。

2。VPN互聯網連接快速、靈活、低成本

有網絡抖動，建議作為專線的補充。例如，客戶只有災難恢復系統部署，一些分支機構和工廠是相連的。

然后再來看系統架構。一套SAP系統本身是由應用服務器和數據庫服務器組成的，無論是在云端還是在本地端，我們都要考慮如何部署和同步兩層的數據。只有在編輯區域的增強功能打開后，才能看到組件。目前支持單行文本、單選和多選組件，提交的表單數據可以在圖文狀態頁面查看。

數據庫級的同步機制一般采用數據庫本身的同步方式。例如，可以使用HSR(hana系統復制)異步模式同步HANA數據庫。由于HANA是內存數據庫，容災節點只做數據同步，不做數據處理，所以硬件資源配置一般可以是主節點的一半大小。比如主節點采用1TB的HANA節點，次節點可以采用HANA數據庫表卸載模式使用512GB或更小的節點。當然，也可以利用數據庫預加載功能將RTO時間降低到分鐘級，可以根據業務需求靈活配置。業務切換時，HANA虛擬機服務器根據主節點大小動態調整到1TB節點，充分利用云的彈性，解決SAP容災成本高的問題。

應用服務器可以通過腳本或ASR(Azure Site Recovery)鏡像進行同步。

由于應用服務器中存儲的數據主要是配置文件和執行文件，所以OS腳本用于定期同步SAP trans sapmnt kernel等文件目錄數據，例如在每年的災難恢復演習期間或定期升級內核時?；蛘逜zure Site Recovery用于虛擬機級同步，特別適合SAP容災系統多、運維復雜的場景，可以簡化客戶的運維工作量。災難恢復應用服務器通常建議采用關機模式來降低成本。

[S2/]03

在SAP容災設計過程中，客戶普遍最關心的是如何定義和實現RPO和RTO指標。

簡單來說，RTO分為兩部分:1。技術切換時間，切換拉起核心系統一般需要3060分鐘；2.業務驗證時間，需要客戶調整DNS方向，切換三方接口連接，業務顧問驗證系統數據，對用戶開放。一般需要24個小時或更長時間，視工藝要求和熟練程度而定。因此，RTO時間越短，IT運維團隊在容災切換過程中就越熟練，需要每年進行演練測試，以確保容災系統的RTO要求能夠得到滿足。

關于RPO時間，我們需要了解日常工作負載期間生成的數據和日志的大小，以估計HANA所需的吞吐量。要獲得這些信息，您可以使用zip文件中包含的SQL語句之一，該文件附在SAP說明1969700之后。它提供了一組復雜的SQL語句，包括一些與SAP HANA系統復制相關的語句，可以導入到SAP HANA studio中并在其中執行，如下所示:

1.選擇從SAP note下載的“SQL Statements.zip”文件。

2.右鍵單擊帶寬，然后選擇在SQL控制臺中打開。

3.在這個SQL語句中，可以更改/* modify part */使結果按“天”顯示；例如:

網絡吞吐量的要求取決于所選擇的操作模式，因為(如上所述)通過網絡傳輸的數據量是不同的。特別地，上面標記的PERSISTENCEGB和LOGSIZEGB的值用于計算相應的帶寬，以滿足服務RPO的要求。例如，每日日志數據同步量為100GB，RPO需要30分鐘。所需的最小帶寬是多少我們來計算一下:

100GB*1024/24h/2大約等于半小時2133m的數據。假設2133m的數據在1800秒(30分鐘)內傳輸到azure Cloud，所需帶寬為

2133米/30米/60秒* 8 = 9.5兆字節/秒

即保證RPO為30分鐘需要10M左右的帶寬，所以RPO為15分鐘20M帶寬，1分鐘300M帶寬，以此類推。

04

最后，作者想強調的是，SAP容災備份不僅僅是一個架構，而是接管和支持核心業務系統的能力。因此，我們認為一個合格的SAP災難恢復系統應該具備:

1。合理的RPO和RTO，RPO和RTO不是越小越好，而是要適合企業的現狀。

2。災難恢復系統的可用性。災備是養兵千日。在真正投入使用之前，需要有效的方法來保證從底層硬件到系統層的可靠性。

3。定期災難恢復演習[/s2/]。一方面檢查系統，另一方面讓IT人員熟悉恢復操作。

如果您有相應的SAP災難恢復云需求，請聯系Microsoft Azure銷售人員。

李肯

微軟(中國)有限公司

云解決方案架構師

多年的SAP項目實施經驗，以及在SAP系統上云的最佳實踐設計和部署方面的豐富經驗。企業云直升機團隊深度參與SAP on Azure解決方案，為客戶提供Azure云平臺的最佳實踐，實現更好、更快、更高質量的定制化業務應用場景。欲了解更多信息，請聯系CloudCrew@microsoft.com。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。