本博客将介绍为企业客户设置灾难恢复（DR）的设计、技术和建议，以便在SAP S/4HANA环境中实现一流的恢复点目标（RPO）和恢复时间目标（RTO）。本文由Cognizent SAP云业务全球主管Sivakumar Varadananjayan共同撰写。Microsoft Azure为企业级创新提供了一条可靠的途径，可通过云中的SAP解决方案进行创新。关键任务应用程序（如SAP）在Azure上可靠运行，这是一个经过企业验证的平台，它为运行客户的SAP环境提供了超规模、灵活性和成本节约。系统可用性和灾难恢复对于在Azure上运行关键SAP应用程序的客户至关重要。RTO和RPO是组织为制定适当的灾难恢复计划而考虑的两个关键指标，该计划可以在意外事件发生时保持业务连续性。恢复点目标是指在"时间"方面存在风险的数据量，而恢复时间目标指的是时间量或最大值灾难发生后系统可以停止运行的可容忍时间。下图给出了在业务照常（BAU）场景中时间轴视图上的RPO和RTO视图。Orica是世界上最大的商用炸药供应商，为采矿、采石、石油和天然气以及建筑市场提供创新的爆破系统。他们还是黄金提取用氰化钠的领先供应商，以及采矿和隧道工程地面支持服务的专业提供商。作为Orica数字化转型之旅的一部分，Cognizent被选为值得信赖的技术顾问和托管云平台提供商，为Microsoft Azure中的SAP s/4HANA和其他SAP应用程序构建高可用性、可扩展、防灾难的IT平台。本博客描述了Cognitive如何接受为Orica构建灾难恢复解决方案的挑战，这是以SAP S/4HANA为数字核心的数字转型计划的一部分。这个博客包含了过去两年中由cognetint和Orica提出的SAP on Azure体系结构设计考虑，导致RTO减少到4小时。这是通过部署Azure上可用的最新技术特性以及自动化来实现的。在减少RTO的同时，使用特定于数据库的技术（如SAP HANA系统复制和Azure Site Recovery），RPO也减少到5分钟以下。灾难恢复系统的设计原则根据针对SAP HANA的SAP认证虚拟机选择灾难恢复区域—验证灾难恢复区域中SAP认证虚拟机类型的可用性非常重要。RPO和RTO价值观—企业需要对RPO和RTO价值观提出明确的期望，这将极大地影响灾难恢复的体系结构以及实施灾难恢复所需的工具和自动化的要求实施灾难恢复、维护和灾难恢复演练的成本系统的关键性—可以在灾难恢复实施成本和业务需求之间建立权衡。虽然大多数关键系统可以利用最先进的灾难恢复体系结构，但中等和不太关键的系统可能提供更高的RPO/RTO值。按需调整灾难恢复实例大小—最好对灾难恢复实例使用小型虚拟机，并在活动灾难恢复场景中升迁这些虚拟机。还可以在灾难恢复区域保留所需的虚拟机容量，以便没有"等待"时间来升级虚拟机。Microsoft提供了保留实例，使用这些实例可以提前预订虚拟机并节省高达80%的成本。根据所需的RTO值，需要在运行较小的虚拟机与Azure RI之间进行权衡。请注意，虽然保留实例为容量请求提供了优先级，但它们不能保证在请求灾难恢复时容量将完全可用。我们建议您在考虑成本与业务连续性目标时考虑这一点。云基础设施成本的其他考虑因素，以及为无中断灾难恢复测试设置环境的努力。无中断灾难恢复测试是指执行灾难恢复测试，而不执行实际生产系统到灾难恢复系统的故障转移，从而避免任何业务停机。这涉及到在DR测试期间建立完全隔离的vNet中的临时基础设施的额外成本SAP系统体系结构中的某些组件（如群集网络文件系统（NFS））不建议使用Azure Site Recovery进行复制，因此需要附加许可证成本的工具，如SUSE Geo cluster或SIOS Data keeper for NFS Layer DR。特定技术和工具的选择–虽然Azure提供了"Azure Site Recovery（ASR）"在整个区域复制虚拟机，但此技术用于非数据库组件或系统层，而特定于数据库的方法（如SAP HANA系统复制（HSR））则用于数据库层，以确保一致性数据库。SAP HANA数据库上运行的SAP系统的灾难恢复体系结构在很高的层次上，下图描述了基于SAP HANA的SAP系统的体系结构，以及在发生本地或区域故障时可用的系统。下图给出了用于实现灾难恢复的SAP HANA系统组件和相应技术的下一级详细信息。数据库层在数据库层，使用特定于数据库的复制方法，如SAP HANA系统复制（HSR）。使用特定于数据库的复制方法，可以通过配置各种特定于复制的参数来更好地控制RPO值，并在灾难恢复站点提供数据库的一致性。在数据库（DB）层实现灾难恢复的替代方法（如备份和恢复、恢复或存储基础复制）是可用的，但是它们会导致更高的RTO值。SAP HANA数据库的RPO值取决于以下因素：复制方法（高可用性时为同步，灾难恢复复制为异步）、备份频率、备份数据保留策略、保存点和复制配置参数。SAP Solution Manager可用于监视复制状态，以便在复制受到影响时触发电子邮件警报。即使在撰写本文之时或撰写本文时，SAP HANA 2.0 SP 3（修订版33）已提供多节点复制，但此方案并未与高可用性群集一起测试。随着多目标复制的成功实施，灾难恢复维护过程将变得更加简单，并且由于主站点的故障转移情况，不需要手动干预。应用层–（A）SCS、APP、iSCSIAzure Site Recovery用于复制SAP系统架构的非数据库组件，包括（A）SCS、应用程序服务器，以及Linux群集防护代理，如iSCSI（NFS层除外，将在下面讨论）。Azure Site Recovery将虚拟机（VM）上运行的工作负载从主站点复制到存储层的辅助位置，并且不要求VM处于运行状态，虚拟机可以在实际灾难场景或灾难恢复演习期间启动。在Azure中设置pacemaker集群有两种选择。您可以使用围栏代理，它负责通过azureapi重新启动发生故障的节点，也可以使用基于存储的死亡（SBD）设备。SBD设备需要至少一个额外的虚拟机，该虚拟机充当iSCSI目标服务器并提供SBD设备。但是，这些iSCSI目标服务器可以与其他pacemaker群集共享。使用SBD设备的优点是更快的故障转移时间。下图描述了应用程序层的灾难恢复，（A）SCS、应用程序服务器和iSCSI服务器使用相同的体系结构，使用Azure Site recovery跨灾难恢复区域复制数据NFS层–主站点的NFS层使用具有分布式复制块设备（DRBD）的群集来实现高可用性复制。我们评估了在NFS层实现DR的多种技术。由于DRBD和站点恢复配置不兼容，因此可以使用SUSE geo cluster、SIOS data keeper或简单虚拟机快照备份和还原等解决方案来实现NFS层灾难恢复。由于DRBD使用磁盘复制实现NFS层的高可用性，因此不支持站点恢复复制。在启用DRBD的情况下，实现NFS层灾难恢复的经济高效的解决方案是使用VM快照备份进行简单的备份/恢复。调用DR或DR drill的步骤Microsoft Azure Site Recovery技术有助于在灾难恢复区域更快地复制数据。在不使用或配置站点恢复的灾难恢复实施中，恢复大约五个系统需要超过24小时，最终RTO将导致24小时或更长时间。然而，当在应用层使用站点恢复时，利用数据库层特定于数据库的复制方法，对于相同数量的系统，可以将RTO值降低到远远低于4小时。下图描述了时间轴视图，其中包含激活具有4小时RTO值的灾难恢复的步骤。调用灾难恢复或灾难恢复演练的步骤：虚拟机使用新IP地址的DNS更改启动iSCSI—从ASR复制的数据启动单个VM恢复数据库并将虚拟机调整到所需的容量手动配置NFS–使用快照备份的单个VM从ASR复制数据构建应用层vm执行群集更改启动应用程序验证应用程序释放系统关于无中断灾难恢复演练的建议一些企业无法承受灾难恢复演习期间的停机时间。在无法安排停机时间执行灾难恢复时，建议进行无中断灾难恢复演练。无中断灾难恢复过程可通过创建一个额外的灾难恢复VNet，将其与网络隔离，并按以下步骤执行灾难恢复演练。作为先决条件，构建SAP
