小投資大回報(bào)：SAP容災(zāi)系統(tǒng)上云

拿一套S/4生產(chǎn)系統(tǒng)構(gòu)架來舉例，最佳實(shí)踐建議采用HA/DR的部署方式來提供比較高的系統(tǒng)可用性。

1. 高可用(HA - High Availability)

2. 容災(zāi)(DR – Disaster Recovery)

國內(nèi)現(xiàn)實(shí)中還是有很多企業(yè)，他們的SAP ERP/ S/4等生產(chǎn)機(jī)還沒有部署容災(zāi)系統(tǒng)，這并不意味著他們不需要容災(zāi)來提供生產(chǎn)業(yè)務(wù)的保障，而是SAP系統(tǒng)搭建異地容災(zāi)系統(tǒng)的成本往往是也需要投入比較大的成本，傳統(tǒng)的部署方式要考慮1 是否異地部署以及數(shù)據(jù)中心搭建 2 采購滿配的生產(chǎn)硬件 3 獨(dú)立的線路連通 這些都是傳統(tǒng)企業(yè)擺在IT巨大成本投入以及業(yè)務(wù)間需求難以平衡的問題。

隨著云技術(shù)的發(fā)展，如今SAP容災(zāi)上云已經(jīng)很好的解決了這三個(gè)難題:

在了解SAP容災(zāi)之前，讓我們先聊聊兩個(gè)指標(biāo)RTO和RPO，容災(zāi)構(gòu)架中設(shè)計(jì)的關(guān)鍵要求：

具體樣例參考下面式樣：

技術(shù)上我們是如何實(shí)現(xiàn)SAP系統(tǒng)本地與云上容災(zāi)部署呢？

首先我們先來了解一下本地?cái)?shù)據(jù)中心與Azure網(wǎng)絡(luò)連接問題，SAP上云場景一般會(huì)采用兩種連接方式：

1. ER專線連接  --- 安全，穩(wěn)定，獨(dú)享

推薦獨(dú)立專線給SAP系統(tǒng)使用 例如客戶總部或則核心工廠使用，或則客戶有非sap解決方案在以及SAP系統(tǒng)在azure云混用場景，單獨(dú)使用一條專線給SAP核心系統(tǒng)使用。

2. VPN互聯(lián)網(wǎng)連接 --- 快捷靈活，成本低

有網(wǎng)絡(luò)抖動(dòng)，推薦作為專線補(bǔ)充，例如客戶只有容災(zāi)系統(tǒng)部署，一些分公司辦公室工廠等連接。

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

--- 數(shù)據(jù)庫層面同步機(jī)制一般采用數(shù)據(jù)庫本身同步方式，例如HANA數(shù)據(jù)庫可以利用HSR(hana system replication)異步方式進(jìn)行同步，由于HANA是內(nèi)存式數(shù)據(jù)庫，容災(zāi)節(jié)點(diǎn)只做數(shù)據(jù)同步不做數(shù)據(jù)處理，所以硬件資源配置一般可以采用相對主節(jié)點(diǎn)半配的大小，舉例主節(jié)點(diǎn)采用了1TB的HANA節(jié)點(diǎn)，次節(jié)點(diǎn)可以采用HANA數(shù)據(jù)庫表unload模式從而使用512GB或指更小的節(jié)點(diǎn)，當(dāng)然也可以利用數(shù)據(jù)庫pre-load功能來減少RTO時(shí)間到分鐘級別，就看業(yè)務(wù)的需求來靈活配置。發(fā)生業(yè)務(wù)切換時(shí)，再按照主節(jié)點(diǎn)大小，動(dòng)態(tài)調(diào)整HANA虛機(jī)服務(wù)器到1TB節(jié)點(diǎn)，充分利用云上彈性能力來解決SAP容災(zāi)成本高的問題。

SAP容災(zāi)設(shè)計(jì)過程中，客戶一般最關(guān)心的還是RPO以及RTO的指標(biāo)是如何定義和實(shí)現(xiàn)的。

2. 右鍵單擊Bandwidths，然后在SQL控制臺(tái)中選擇Open

3. 在這個(gè)SQL語句中，您可以更改/*修改部分*/以便結(jié)果按“天”顯示；例如：

有關(guān)網(wǎng)絡(luò)吞吐量的要求取決于所選的操作模式，因?yàn)椋ㄈ缟纤觯┩ㄟ^網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量不同。特別相關(guān)的是上面標(biāo)記的PERSISTENCE_GB和LOG_SIZE_GB值. 利用這兩個(gè)值來計(jì)算相應(yīng)的帶寬來滿足業(yè)務(wù)RPO的要求。舉例來說，一天log數(shù)據(jù)同步量為100GB，RPO要求30分鐘，需要的最低帶寬是多少呢？我們來算下：

100GB*1024/24h/2 約等于產(chǎn)生2133M半小時(shí)數(shù)據(jù)量，假設(shè)2133M數(shù)據(jù)量在需要1800秒（30分鐘) 內(nèi)傳輸?shù)絘zure云，所需帶寬為

2133M/30m/60s*8=9.5Mbs/s

即需要10M左右?guī)挶Ｕ蟁PO為30分鐘，所以RPO15分鐘為20M帶寬，RPO 1分鐘為300M帶寬，以此類推。

最后筆者想強(qiáng)調(diào)的是SAP容災(zāi)備份不只是一個(gè)架構(gòu)，而是真正要具備接管支持核心業(yè)務(wù)系統(tǒng)能力，從而我們認(rèn)為一個(gè)合格的SAP容災(zāi)系統(tǒng)，應(yīng)該具備：

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

2. 容災(zāi)系統(tǒng)的可用性，容災(zāi)是養(yǎng)兵千日用兵一時(shí)，在真正啟用前，需要有效方式確保從底層硬件到系統(tǒng)層可靠性

3. 定期容災(zāi)演練，一方面檢查系統(tǒng)，另一方面讓IT人員熟悉恢復(fù)操作

如果有相應(yīng)的SAP容災(zāi)上云需求，歡迎聯(lián)系微軟Azure銷售人員。