拿一套S/4生产系统构架来举例，最佳实践建议采用HA/DR的部署方式来提供比较高的系统可用性。

1. 高可用(HA - High Availability)

2. 容灾(DR – Disaster Recovery)

国内现实中还是有很多企业，他们的SAP ERP/ S/4等生产机还没有部署容灾系统，这并不意味着他们不需要容灾来提供生产业务的保障，而是SAP系统搭建异地容灾系统的成本往往是也需要投入比较大的成本，传统的部署方式要考虑1 是否异地部署以及数据中心搭建 2 采购满配的生产硬件 3 独立的线路连通 这些都是传统企业摆在IT巨大成本投入以及业务间需求难以平衡的问题。

随着云技术的发展，如今SAP容灾上云已经很好的解决了这三个难题:

在了解SAP容灾之前，让我们先聊聊两个指标RTO和RPO，容灾构架中设计的关键要求：

具体样例参考下面式样：

技术上我们是如何实现SAP系统本地与云上容灾部署呢？

首先我们先来了解一下本地数据中心与Azure网络连接问题，SAP上云场景一般会采用两种连接方式：

1. ER专线连接  --- 安全，稳定，独享

推荐独立专线给SAP系统使用 例如客户总部或则核心工厂使用，或则客户有非sap解决方案在以及SAP系统在azure云混用场景，单独使用一条专线给SAP核心系统使用。

2. VPN互联网连接 --- 快捷灵活，成本低

有网络抖动，推荐作为专线补充，例如客户只有容灾系统部署，一些分公司办公室工厂等连接。

然后我们再来看下系统构架，一套SAP系统本身是有应用服务器和数据库服务器构成，所以我们无论在云端还是本地端，都要考虑两层的数据如何部署同步。表单组件只有开启编辑区域的增强特性后才能看到，目前支持单行文字、单选和多选组件，在图文的状态页面可以查看提交的表单数据。

--- 数据库层面同步机制一般采用数据库本身同步方式，例如HANA数据库可以利用HSR(hana system replication)异步方式进行同步，由于HANA是内存式数据库，容灾节点只做数据同步不做数据处理，所以硬件资源配置一般可以采用相对主节点半配的大小，举例主节点采用了1TB的HANA节点，次节点可以采用HANA数据库表unload模式从而使用512GB或指更小的节点，当然也可以利用数据库pre-load功能来减少RTO时间到分钟级别，就看业务的需求来灵活配置。发生业务切换时，再按照主节点大小，动态调整HANA虚机服务器到1TB节点，充分利用云上弹性能力来解决SAP容灾成本高的问题。

SAP容灾设计过程中，客户一般最关心的还是RPO以及RTO的指标是如何定义和实现的。

2. 右键单击Bandwidths，然后在SQL控制台中选择Open

3. 在这个SQL语句中，您可以更改/*修改部分*/以便结果按“天”显示；例如：

有关网络吞吐量的要求取决于所选的操作模式，因为（如上所述）通过网络传输的数据量不同。特别相关的是上面标记的PERSISTENCE_GB和LOG_SIZE_GB值. 利用这两个值来计算相应的带宽来满足业务RPO的要求。举例来说，一天log数据同步量为100GB，RPO要求30分钟，需要的最低带宽是多少呢？我们来算下：

100GB*1024/24h/2 约等于产生2133M半小时数据量，假设2133M数据量在需要1800秒（30分钟) 内传输到azure云，所需带宽为

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

即需要10M左右带宽保障RPO为30分钟，所以RPO15分钟为20M带宽，RPO 1分钟为300M带宽，以此类推。

最后笔者想强调的是SAP容灾备份不只是一个架构，而是真正要具备接管支持核心业务系统能力，从而我们认为一个合格的SAP容灾系统，应该具备：

1. 合理的RPO及RTO，RPO和RTO并不是越小越好，而是要适合企业现状

2. 容灾系统的可用性，容灾是养兵千日用兵一时，在真正启用前，需要有效方式确保从底层硬件到系统层可靠性

3. 定期容灾演练，一方面检查系统，另一方面让IT人员熟悉恢复操作

如果有相应的SAP容灾上云需求，欢迎联系微软Azure销售人员。