这是一个由四部分组成的博客系列文章的第三部分，该系列文章讲述了如何在Azure架构上设计一个伟大的SAP。强大的SAP on Azure架构建立在安全性、性能和可扩展性、可用性和可恢复性、效率和运营等支柱之上。我们之前讨论了性能和可伸缩性的设计，在本博客中，我们将重点讨论可用性和可恢复性。为可用性而设计针对可用性设计可确保您的关键SAP应用程序（如SAP ERP或S/4HANA）应用了高可用性（HA）规定。这些HA规定可确保应用程序能够抵御硬件和软件故障，并确保SAP应用程序正常运行时间能够满足您的服务级别协议（SLA）。在下面的链接中，您将找到有关Azure虚拟机维护与停机的全面概述，其中详细介绍了计划外硬件维护事件、意外停机和计划内维护事件。管理Linux虚拟机的可用性文档管理Azure中Windows虚拟机的可用性从可用性的角度来看，在Azure上部署SAP的选项如下：对于使用Azure高级存储的单实例虚拟机，99.9%的SLA。在本例中，SAP数据库（DB）、system central services A（SCS）和应用程序服务器要么在单独的VM上运行，要么在一个或多个VM上合并。我们的单节点裸机HANA大型实例也提供了99.9%的SLA。同一Azure可用性集中的VM的99.95%SLA。可用性集合强制将集合中的虚拟机部署在不同的故障域和更新域中，这反过来确保了虚拟机不受计划外硬件维护事件、意外停机和计划内维护事件的影响。为确保SAP应用程序的高可用性，可用性集与Azure负载平衡器、来宾操作系统群集技术（如Windows故障转移群集或Linux Pacemaker）结合使用，以缩短故障转移时间和同步数据库复制技术（SQL AlwaysOn、HANA系统复制、，等）以保证数据不丢失。此外，配置SAP排队复制服务器可以减轻a（SCS）故障转移期间SAP锁表的丢失。Azure可用性区域内VM的99.99%SLA。Azure区域中的可用性区域是容错域和更新域的组合。Azure平台可以跨更新域识别此分布，以确保在发生Azure计划的维护事件时不同区域中的VM不会同时更新。此外，可用性区域是Azure区域内物理上独立的区域，每个区域都有自己的电源、网络，并在逻辑上与Azure区域内的其他区域分开。这种构造可以避免由于给定区域内的硬件或基础设施故障而导致的意外停机。通过设计SAP部署以利用跨区域的复制，即DBMS复制（HANA系统复制，SQL AlwaysOn）、SAP排队复制服务器以及跨区域分布SAP应用程序服务器（用于冗余），您可以保护SAP系统不受完整数据中心丢失的影响。如果一个区域受到破坏，SAP系统将在另一个区域可用。有关Azure可用性区域和我们最新的Mv2虚拟机产品的概述，请查看此视频。HANA大型实例配置为HA对时，其SLA为99.99%，这适用于单数据中心和可用区部署。在可用性集和可用性区域的情况下，来宾操作系统群集对于HA是必要的。我们想借此机会澄清一下Azure上的Linux Pacemaker围栏选项，以避免您的SAP应用程序出现分裂，这些选项包括：Azure剑术代理基于存储的死亡（SBD）Azure围栏代理在RedHat Enterprise Linux（RHEL）和SUSE Enterprise Linux（SLES）上都可用，并且SLES支持SBD，但不支持RHEL；要获得SAP on Azure with Pacemaker的最短群集故障转移时间，我们建议：基于RHEL构建的用于SAP群集的Azure围栏代理。基于SLES构建的SAP群集的SBD对于高效的SAP应用程序，我们强烈建议使用可用性集或可用性区域。可用性区域是可用性集的替代品，为HA提供Azure区域内数据中心故障的恢复能力。但是，请注意，不能保证承载不同可用区的建筑结构之间有一定的距离。不同的Azure区域在物理建筑的距离方面会遇到不同的设置。因此，对于确定性的应用程序性能和最低的网络往返时间（RTT），可用性集可能是更好的选择。单实例VMs非常适合于非生产（项目、沙盒和测试SAP系统），这些系统没有与生产相同级别的可用性sla，此选项还有助于最小化运行成本。可恢复性设计设计可恢复性意味着从数据丢失（如SAP数据库上的逻辑错误）、大规模灾难或整个Azure区域的丢失中恢复。在设计可恢复性时，有必要了解SAP应用程序的恢复点目标（RPO）和恢复时间目标（RTO）。建议将Azure区域对用于灾难恢复，它提供隔离和可用性，以对冲影响单个区域的自然或人为灾害的风险。在DBMS层，可以使用异步复制将生产数据从主区域复制到灾难恢复（DR）区域。在SAP应用程序层，Azure到Azure Site Recovery可作为高效、有成本意识的灾难恢复解决方案的一部分。您还可以选择在灾难恢复方面设计一个双重用途的场景，例如运行一个组合的QA/DR系统，以获得更好的投资回报，如下所示。除了提供HA和DR之外，还必须为SAP数据的备份和恢复提供企业数据保护解决方案。我们的第一方Azure备份产品是针对SAP HANA认证的，该解决方案目前处于公开预览阶段（截至2019年9月），并支持SAP HANA扩展（数据和日志备份），未来还将支持进一步的场景，如数据快照和SAP HANA横向扩展。此外，Azure平台支持广泛的isv，它们为您的SAP应用程序提供企业数据保护和管理。其中一个ISV就是Commvault，微软最近在那里合作编写了这份白皮书。Commvault的一个关键优势是IntelliSnap（数据快照）功能，它为您的SAP数据库提供即时的应用程序一致性数据快照，这对于RTO要求较低的大型数据库非常有利。Commvault为SAP HANA扩展、SAP HANA横向扩展和anyDB工作负载提供了直接到Azure Blob存储的高性能多流（backint）数据备份。您的企业数据保护策略可以包括数据快照和数据备份的组合，即在周末运行每日快照和数据备份（backint）。下面是通过IntelliSnap对M128s（2TB）VM上的SAP HANA数据库执行的数据快照，快照持续时间为20秒。 在本博客中，我们总结了在Azure上设计SAP以实现可用性和可恢复性的选项。在Azure上架构和部署生产SAP应用程序时，必须包括可用性集或可用性区域，以支持关键任务SAP SLA。此外，您应该应用灾难恢复条款和企业数据保护，以保护您的SAP应用程序免受完整的Azure区域丢失或数据损坏。确保在SAP to Azure项目的整个生命周期内执行HA和DR测试，并且在SAP应用程序投入生产运营（即每年进行灾难恢复演练测试）后，在维护窗口期间重新测试这些功能。应持续审查可用性和可恢复性，以纳入Microsoft关于最佳做法的最新技术和指导。在我们系列的博客4中，我们将讨论效率和操作的设计。