SAP容災(zāi)系統(tǒng)上云,sap異地容災(zāi)

SAP災(zāi)難恢復(fù)系統(tǒng)上的云

01

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

以一套S/4生產(chǎn)系統(tǒng)架構(gòu)為例，最佳實踐建議采用HA/DR部署模式，提供高系統(tǒng)可用性。

1。高可用性

2。災(zāi)難恢復(fù)

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

隨著云技術(shù)的發(fā)展，SAP容災(zāi)云解決了這三個問題:

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

Azure客戶可以重用現(xiàn)有的ER專線進(jìn)行數(shù)據(jù)同步，也可以使用互聯(lián)網(wǎng)S2S VPN連接到云服務(wù)器進(jìn)行數(shù)據(jù)同步。

通過在云上使用靈活的配置功能，日常容災(zāi)系統(tǒng)只需要打開數(shù)據(jù)庫的最低配置就可以滿足數(shù)據(jù)同步需求。當(dāng)需要切換容災(zāi)系統(tǒng)時，會根據(jù)需要拉起應(yīng)用服務(wù)器系統(tǒng)，并擴展數(shù)據(jù)庫機配置。

02

在了解SAP容災(zāi)之前，我們先來談?wù)剝蓚€指標(biāo)RTO和RPO，容災(zāi)架構(gòu)設(shè)計的關(guān)鍵要求:

RPO(恢復(fù)點目標(biāo)):即數(shù)據(jù)恢復(fù)點目標(biāo)，主要指業(yè)務(wù)系統(tǒng)可以容忍的數(shù)據(jù)丟失。災(zāi)難發(fā)生后，兩個點之間的時間段稱為RTO，從IT系統(tǒng)關(guān)閉、業(yè)務(wù)停止開始，到IT系統(tǒng)恢復(fù)并能支持各部門運行為止。

RTO(Recovery Time Objective):即恢復(fù)時間目標(biāo)，主要指業(yè)務(wù)停止服務(wù)的最長可容忍時間，即從災(zāi)難發(fā)生到業(yè)務(wù)系統(tǒng)服務(wù)功能恢復(fù)的最短時間段。

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

技術(shù)上，我們?nèi)绾卧诒镜睾驮粕蠈崿F(xiàn)SAP系統(tǒng)的容災(zāi)部署

首先，我們來看看本地數(shù)據(jù)中心和Azure網(wǎng)絡(luò)之間的連接。SAP上的云場景一般采用兩種連接方式:

1。ER專線連接安全、穩(wěn)定、專屬

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

2。VPN互聯(lián)網(wǎng)連接快速、靈活、低成本

有網(wǎng)絡(luò)抖動，建議作為專線的補充。例如，客戶只有災(zāi)難恢復(fù)系統(tǒng)部署，一些分支機構(gòu)和工廠是相連的。

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

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

應(yīng)用服務(wù)器可以通過腳本或ASR(Azure Site Recovery)鏡像進(jìn)行同步。

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

[S2/]03

在SAP容災(zāi)設(shè)計過程中，客戶普遍最關(guān)心的是如何定義和實現(xiàn)RPO和RTO指標(biāo)。

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

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

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

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

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

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

100GB*1024/24h/2大約等于半小時2133m的數(shù)據(jù)。假設(shè)2133m的數(shù)據(jù)在1800秒(30分鐘)內(nèi)傳輸?shù)絘zure Cloud，所需帶寬為

2133米/30米/60秒* 8 = 9.5兆字節(jié)/秒

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

04

最后，作者想強調(diào)的是，SAP容災(zāi)備份不僅僅是一個架構(gòu)，而是接管和支持核心業(yè)務(wù)系統(tǒng)的能力。因此，我們認(rèn)為一個合格的SAP災(zāi)難恢復(fù)系統(tǒng)應(yīng)該具備:

1。合理的RPO和RTO，RPO和RTO不是越小越好，而是要適合企業(yè)的現(xiàn)狀。

2。災(zāi)難恢復(fù)系統(tǒng)的可用性。災(zāi)備是養(yǎng)兵千日。在真正投入使用之前，需要有效的方法來保證從底層硬件到系統(tǒng)層的可靠性。

3。定期災(zāi)難恢復(fù)演習(xí)[/s2/]。一方面檢查系統(tǒng)，另一方面讓IT人員熟悉恢復(fù)操作。

如果您有相應(yīng)的SAP災(zāi)難恢復(fù)云需求，請聯(lián)系Microsoft Azure銷售人員。

李肯

微軟(中國)有限公司

云解決方案架構(gòu)師

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

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