SAP容灾系统上云,sap异地容灾-ESG跨境

SAP容灾系统上云,sap异地容灾

2022-07-05

699

SAP容灾系统上云,sap异地容灾SAP灾难恢复系统上的云01随着信息技术在全球的发展和应用，SAP系统作为全球排名第一的ERP企业资源计划软件，依托其系统化的管理理论和信息技术，打造信息管理系统平台，辅助公司进行决策和管理。SAP系统的可用性和稳定性是保证企业核心业务的前提，因此企业往往在设计和构建SAP系统架构上投......

SAP容灾系统上云,sap异地容灾

SAP灾难恢复系统上的云

随着信息技术在全球的发展和应用，SAP系统作为全球排名第一的ERP企业资源计划软件，依托其系统化的管理理论和信息技术，打造信息管理系统平台，辅助公司进行决策和管理。SAP系统的可用性和稳定性是保证企业核心业务的前提，因此企业往往在设计和构建SAP系统架构上投入很大的成本。生产机器的高可用性是基本的配置要求，异地容灾经常被一些要求高的客户使用。

以一套S/4生产系统架构为例，最佳实践建议采用HA/DR部署模式，提供高系统可用性。

1。高可用性

2。灾难恢复

现实中，国内还有很多企业，他们的SAP ERP/ S/4等生产机器还没有部署容灾系统，并不代表他们不需要容灾来提供生产业务的保障。但是，用SAP系统构建异地容灾系统的成本往往很高，传统的部署方式要考虑是否异地部署，建设数据中心，购买设备齐全的生产硬件，连接独立的线路。这些都是传统企业面临的IT成本投入巨大，业务需求难以平衡的问题。

随着云技术的发展，SAP容灾云解决了这三个问题:

Azure为国内客户提供了北京和上海的选择，轻松满足SAP异地容灾需求。

Azure客户可以重用现有的ER专线进行数据同步，也可以使用互联网S2S VPN连接到云服务器进行数据同步。

通过在云上使用灵活的配置功能，日常容灾系统只需要打开数据库的最低配置就可以满足数据同步需求。当需要切换容灾系统时，会根据需要拉起应用服务器系统，并扩展数据库机配置。

在了解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等文件目录数据，例如在每年的灾难恢复演习期间或定期升级内核时。或者Azure 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带宽，以此类推。

最后，作者想强调的是，SAP容灾备份不仅仅是一个架构，而是接管和支持核心业务系统的能力。因此，我们认为一个合格的SAP灾难恢复系统应该具备:

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

2。灾难恢复系统的可用性。灾备是养兵千日。在真正投入使用之前，需要有效的方法来保证从底层硬件到系统层的可靠性。

3。定期灾难恢复演习[/s2/]。一方面检查系统，另一方面让IT人员熟悉恢复操作。

如果您有相应的SAP灾难恢复云需求，请联系Microsoft Azure销售人员。