SAP是部署到公司环境中最关键的业务系统之一。它拥有最有价值的数据，许多组织完全依赖其SAP ERP或SAP S/4HANA解决方案的可用性。即使是一个小的中断也可能带来巨大的挑战，并导致业务运营中断。因此，许多组织决定实施以高可用模式运行的系统，这意味着SAP系统的所有组件：数据库、中央服务实例和应用服务器都是冗余的，因此，即使硬件故障也不会停止系统。

我已经讨论了基于SAP NetWeaver的系统的高可用性。它需要不容易配置和维护的故障转移群集。由于SAP系统的每个组件都是一个单一的故障点，因此您需要确保即使在发生硬件故障的情况下，每个组件都受到保护并可访问。一个示例体系结构包括三个故障转移群集以保护每个系统层：

故障转移群集需要额外的资源才能正常工作。首先，您需要负载均衡器将用户流量路由到正确的节点。根据配置，大数据是，您还需要一个由几个小型Linux vm组成的集群见证。通常如此复杂的体系结构会破坏您的工作，最终会降低SAP系统的整体可用性。

在今天的博客中，我将尝试回答在Azure中运行SAP时是否可以简化上述示例体系结构。我将重点介绍两个方面—中央服务实例和共享存储。

在介绍我的解决方案之前，让我们先仔细看看中央服务实例体系结构。它由两个进程组成：

消息服务器暂时不可用会阻止新用户访问SAP系统，但不会中断现有连接。但是，每当重新启动排队服务器时，可视化数据大屏，锁表的内容就会丢失，物联网产品，您将无法再确保系统的一致性。

为了解决此问题，一个高可用的Central Services实例安装包括一个在集群的辅助节点上运行的附加组件。排队复制服务器将锁表的副本保存在被动节点的共享内存中，十大淘客软件排名，在故障转移时，可以检索所有锁条目，即使排队服务器重新启动，也可以确保系统的一致性。但由于锁表存储在共享内存中，无法通过网络检索，因此必须在排队复制服务运行时在同一节点上启动中心服务实例。到目前为止，网购返利，这是一个很大的限制，基本上强制使用集群。

当您将虚拟机部署到Azure时，hypervisor会持续监视其状态。如果电源状态有问题，虚拟机将自动重新启动。如果故障发生在物理主机上，您的工作负载将被重新部署到另一台服务器，并且存储在永久磁盘上的数据将被保留。默认情况下，在所有位置运行的所有虚拟机都启用服务修复。它确保您的工作负载即使在底层硬件出现故障的情况下也能尽快继续运行。

从SAP NetWeaver 7.52开始，您可以使用最新版本的排队框架。在与排队复制服务器相同的主机上启动中央服务实例的要求不再有效，因为可以通过网络检索锁表。当您将其与Microsoft Azure服务修复功能结合使用时，您可以设计一个简化的高可用性SAP系统体系结构，而无需复杂的群集配置。如果出现故障，您的虚拟机将重新启动，独立排队服务器2将自动连接到排队复制服务器2并获取锁表的内容。

独立排队服务器2和排队复制服务器2仅适用于在SAP NetWeaver 7.52及更新版本上运行的系统。根据您的系统版本，它可能在默认情况下被激活，或者您需要手动激活它。

由于中央服务实例在同一虚拟机上重新启动，保留了存储在永久磁盘上的所有数据，因此您不必担心共享文件系统。您可以创建一个NFS服务器并从同一主机共享/sapmnt目录—并且删除另一个故障转移群集，如果您必须配置DRBD复制，这一点尤其值得赞赏。

通过使用新排队框架附带的新功能，我们能够在高可用性部署中消除三分之二的群集。如果您不必运行起搏器，配置和维护就容易多了。此外，使用Azure Site Recovery将这样的部署复制到辅助区域也更加友好，并且不需要额外的故障转移后活动。

与往常一样，所有的好东西都有一些限制。在这种情况下，简化的高可用性配置允许您在虚拟机暂时不可用的情况下继续操作，这可以由Azure资源管理器自动解决。它不会帮助您在错误配置的情况下-例如，如果您提供错误的IP配置或手动停止服务。从Azure的角度来看，虚拟机仍然可以正常运行。也无法保证服务器的重启速度——在下面的示例中，重启服务器的时间不到2分钟，但您应该始终参考SLA，以根据您的配置获得最大值。

请记住，这是我对群集的私人看法，此博客不遵循Microsoft的官方建议，您可以在此处找到：https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/get-started

系统部署