小投资大回报：SAP容灾系统上云
次
01
伴随信息技术的全球化发展及应用，SAP系统作为全世界排名第一位的ERP企业资源计划系统软件(Enterprise Resource Planning)，企业依托其系统化管理的理论与信息技术，创建信息化管理系统平台，辅助公司制定决策与经营管理。SAP系统的可用性以及稳定性是企业核心业务得以保障的前提，所以企业往往投资比较大的成本在设计搭建SAP系统构架。生产机的高可用都是基本配置要求，异地容灾也是经常被一些高要求的客户所使用。
拿一套S/4生产系统构架来举例，最佳实践建议采用HA/DR的部署方式来提供比较高的系统可用性。
1. 高可用(HA - High Availability)
2. 容灾(DR – Disaster Recovery)
国内现实中还是有很多企业，他们的SAP ERP/ S/4等生产机还没有部署容灾系统，这并不意味着他们不需要容灾来提供生产业务的保障，而是SAP系统搭建异地容灾系统的成本往往是也需要投入比较大的成本，传统的部署方式要考虑1 是否异地部署以及数据中心搭建 2 采购满配的生产硬件 3 独立的线路连通 这些都是传统企业摆在IT巨大成本投入以及业务间需求难以平衡的问题。
随着云技术的发展，如今SAP容灾上云已经很好的解决了这三个难题:
Azure云为国内客户提供了北京，上海两地选择，轻松满足SAP异地容灾需求。
Azure客户即可复用已有ER专线进行数据同步，也可以利用internet S2S VPN方式连接到云端服务器进行数据同步。
利用云上弹性灵活配置功能，日常容灾系统只需要开启数据库最低配置来满足数据同步需求，发生切换容灾系统需求时刻，按需拉起应用服务器系统，扩容数据库机器配置。
02
在了解SAP容灾之前，让我们先聊聊两个指标RTO和RPO，容灾构架中设计的关键要求：
RPO(Recovery Point Objective)：即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量，指灾难发生后，从IT系统宕机导致业务停顿之时开始，到IT系统恢复至可以支持各部门运作、恢复运营之时，此两点之间的时间段称为RTO。
RTO(Recovery Time Objective)：即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
具体样例参考下面式样：
技术上我们是如何实现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容灾成本高的问题。
--- 应用服务器可以采用脚本方式或ASR(Azure Site Recovery)镜像同步方式来进行同步。
由于应用服务器存储的数据以配置文件和执行文件为主，采用OS脚本定期同步SAP trans sapmnt kernel等文件目录数据， 例如每年容灾演练时候，或则Kernel定期升级时候。或者采用Azure Site Recovery来进行虚机级别同步，特别适用于SAP容灾系统比较多，运维复杂的场景，可以简化客户运维工作量。容灾应用服务器平时建议采用关闭模式来降低成本。
03
SAP容灾设计过程中，客户一般最关心的还是RPO以及RTO的指标是如何定义和实现的。
简单来说RTO分两部分内容：1.技术切换时间， 一般30-60分钟内可以完成核心系统切换及拉起的操作 2.业务验证时间，需要客户调整DNS指向，切换三方接口连接，业务顾问验证系统数据，开放用户使用，一般时间2-4小时或则更久，取决于流程要求以及熟练程度。所以RTO时间越短，需要IT运维团队越熟练容灾切换的流程，需要每年的演练测试来保证容灾系统的RTO要求可以被满足。
关于RPO时间，我们要估计HANA所需的吞吐量，需要知道在日常工作负载期间生成的数据和日志的大小。要获取此信息，您可以使用zip文件中包含的SQL语句之一，该文件附在此SAP Note 1969700中。它提供了一组复杂的SQL语句，包括一些与SAP HANA系统复制相关的语句，可以导入到SAP HANA studio并在其中执行，如下所示：
1.选择从SAP note中下载的“SQL Statements.zip”文件
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带宽，以此类推。
04
最后笔者想强调的是SAP容灾备份不只是一个架构，而是真正要具备接管支持核心业务系统能力，从而我们认为一个合格的SAP容灾系统，应该具备：
1. 合理的RPO及RTO，RPO和RTO并不是越小越好，而是要适合企业现状
2. 容灾系统的可用性，容灾是养兵千日用兵一时，在真正启用前，需要有效方式确保从底层硬件到系统层可靠性
3. 定期容灾演练，一方面检查系统，另一方面让IT人员熟悉恢复操作
如果有相应的SAP容灾上云需求，欢迎联系微软Azure销售人员。
Ken Li
微软（中国）有限公司
云解决方案架构师
具有多年SAP项目实施经验，对于SAP系统上云的最佳实践设计以及部署拥有丰富的经验。企业上云直升机团队深度参与SAP on Azure解决方案，为客户提供Azure云平台的最佳实践，实现更好更快更高质量的定制业务应用场景。更多咨询信息，请联系 CloudCrew@microsoft.com.
