如何减少 SAP 的停机时间

想着怎么做减少 SAP 的停机时间是在初始解决方案设计期间应该访问的一个重要主题。 可以对现有的 SAP 环境进行更改，但在现有的生产环境中，这些可能会更加棘手，停机时间会成为问题。

SAP 环境中有几个典型的组件可以被视为单点故障； ASCS（中央服务）、HANA DB、NFS 节点和 SAP 应用程序服务器。 理想情况下，应该通过在高可用性配置中使用冗余服务器来保护这些。

SAP 的 HA/DR 目标

为 SAP 设计高可用性/灾难恢复组件时的核心目标应该是：

● 最大限度地减少停机时间 ● 消除数据丢失 ● 保持数据完整性 ● 支持灵活配置 在当今的现代云环境中，底层硬件的基础架构通常通过使用多个冗余 NIC、冗余存储和硬件可用区得到很好的保护，避免出现故障——然而，这仍然没有'不保证您的 SAP 应用程序将运行并响应请求。

用一个高可用性SIOS 保护套件等解决方案引入了智能高可用性以及本地磁盘复制，以确保您的 SAP 应用程序和服务受到持续监控和保护，并能够在检测到故障时自动切换到冗余硬件。

现在让我们考虑一个不受 HA 保护的 SAP 配置的简单示例，它可能看起来像这样（图 1）：如果此环境用于处理来自用于向客户销售服装的 Web 服务器的交易，那么 SAP 将用于处理销售、跟踪订单、跟踪库存并基于这些交易提供多个自动订购等。

现在让我们假设这个销售处理环境（如上图）是在没有 HA 的情况下在云中配置的，因为架构师认为云环境中的高度冗余硬件足以防止故障。如果该 HANA 数据库遇到问题并关闭，让我们看看使数据库恢复正常运行所需的典型步骤： ● 即使HANA 配置了HANA 系统复制，故障转移到辅助HANA 数据库系统也不会自动进行。 这将需要知道 HANA 的人在检测到故障并通知他们中断后进行纠正。
● 来自网络服务器的实时交易将暂停，直到问题得到解决 如果这家小型服装零售商每年通过网络销售进行约 1000 万美元的交易，这相当于全年平均销售额约为每小时 1150 美元。 高峰时间每小时会花费更多。

IBM 的这份报告表明每小时的平均停机成本为 1 万美元图 2：具有 HA/DR 的 SAP 环境如果 HA 软件一直在使用中（图 2），HANA DB 故障转移将是自动的，并且 Web 服务器的中断将在配置的超时范围内，并且绝对不会有任何销售损失。 将生成警报，并且可以比系统停机情况更轻松地查看和诊断原因。

扩大客户规模，很可能任何系统停机情况都会开始花费数十万美元并消耗大量人力资源来解决。

其他IBM 报告表明惊人的 44% 的受访者每两个月进行一次计划外停机，另有 35% 的受访者每月进行一次计划外停机。

计划中断本身是另一个潜在问题，46% 的受访者报告每月计划中断，另有 29% 报告年度计划中断。 让应用程序和服务受 HA 软件保护还可以通过允许在维护活动期间将服务转移到正在运行的系统来缓解这些计划内的中断。

学习更多关于SAP 和 S/4HANA 的高可用性.

在这篇博客中，我将讨论通用负载平衡器应用程序恢复套件 (ARK)适用于 Linux 的 SIOS Lifekeeper，特别是如何在 Microsoft Azure 上配置它。 我将使用一个两节点 NFS 集群，它们提供的 NFS 导出最终将通过负载平衡器访问。

SIOS 创建了这个 ARK 以促进在 Azure 中运行的 LifeKeeper 集群中的客户端重定向。

由于 Azure 不支持免费 ARP，因此客户端无法直接连接到传统的集群虚拟 IP 地址。 相反，客户端必须连接到负载均衡器，负载均衡器将流量重定向到活动集群节点。 . Azure 实现了在第 4 层（TCP、UDP）上运行的负载均衡器解决方案，负载均衡器可以配置为具有私有或公共前端 IP，可以确定哪个节点处于活动状态的运行状况探测器，一系列后端 IP 地址（对于集群中的每个节点）和传入/传出网络流量规则。

传统上，健康探测将监视应用程序上的活动端口并确定该应用程序在哪个节点上处于活动状态。SIOS 通用负载平衡器 ARK 配置为让活动节点侦听用户定义的端口。 然后在 Azure 负载均衡器中将此端口配置为运行状况探测端口。 这允许活动集群节点响应 TCP 健康检查探测，从而启用自动客户端重定向。

Azure 中的安装和配置简单明了，详细如下：

在 Azure 门户中，选择负载平衡创建一个负载均衡器，您将选择要部署它的资源组以及名称，我喜欢使用与我使用负载均衡器的集群类型一致的名称，例如 IMA -NFS-LB 将位于两个 IMA-NFS 节点的前面。

您可以确定这是公共 LB 还是私有 LB。 在这种情况下，我将一个私有负载平衡器配置到我的 NFS 服务器前面，以便仅在此资源组中使用。

一旦您确定了名称、资源组等，您将被要求为负载均衡器分配名称、虚拟网络、子网和 IP。 IP 地址应该与您将在 LifeKeeper 中创建为虚拟 IP 地址的 IP 地址相同。

为负载均衡器输入基本信息后，您需要定义要在后端配置哪些机器来为负载均衡器提供服务，在我的情况下，这个后端池将由我使用的两个节点组成我的 NFS 服务器。

您将需要一个负载平衡规则，这是负载平衡器确定将哪些流量路由到活动节点的方式。 – 当您配置通用应用程序以支持负载平衡器时，此处配置的端口号将在 SPS-L 中使用。 在此示例中，我们使用“HA 端口”，它将所有流量路由到活动节点。 如果您想限制要路由的流量，您可以指定特定的应用程序端口。

前端 IP 应该是负载均衡器 IP，后端池应该是您配置为负载均衡器使用的资源的节点。 确保选中“HA Ports”按钮并启用“Floated IP”。 可以禁用“TCP 重置”。

创建运行状况探测时，请确保记下您在此处配置的端口，因为我们在 SIOS 保护套件中创建通用应用程序时将使用该端口。 您可以使用“间隔”和“不健康阈值”的标准值。 如果您有应用程序特定的要求，这些可以在以后更改。

现在负载平衡规则应该是完整的，带有一个运行状况探测。 选择“添加”一旦我们选择“添加”，Azure 将开始部署负载均衡器，这可能需要几分钟，一旦完成，配置就会转到 SIOS 保护套件。

注意：一旦后端机器在负载均衡器后面配置，它们将失去对互联网网关的访问权限，因此系统更新等操作将无法正常工作。 您可以从后端资源组中删除机器以再次允许 Internet 访问。

使用 SIOS 保护套件进行配置

在本博客中，我配置了三个 NFS 导出以使用 SPS-L 进行保护，这三个导出配置为使用与 Azure 负载均衡器的前端 IP 相同的 IP。 我正在使用 Datakeeper 复制存储在导出中的数据。

第一步是获取脚本，最简单的方法是使用 wget，但您也可以下载整个包并使用 winscp 或类似工具将 rpm 直接上传到节点。 您需要在 Lifekeeper 集群的所有节点上安装 Hotfix。

完整的恢复套件可在此处获得： http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1可以使用 wget 在这里找到这些部件： wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt下载后，根据 FTP 站点上记录的值验证 MD5 总和。

按如下方式安装 RPM： rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm 通过运行检查安装是否成功： rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172 如果您出于某种原因需要删除 RPM，可以通过运行： rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154 来完成.x86_64下面是显示我已经配置的三个 NFS 导出的 GUI：我们需要在 SIOS 保护套件中做的是使用 SIOS 提供的修补程序脚本定义负载平衡器。

首先我们创建一个新的资源层次结构，我们从下拉列表中选择 Generic Application定义位于 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 restore.pl 脚本定义位于 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 remove.pl 脚本定义位于 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 quickCheck 脚本没有本地恢复脚本，因此请确保清除此输入当询问应用程序信息时，我们希望输入与在 Health Probe 配置中配置的端口号相同的端口号，例如 54321我们将选择在服务创建后将其投入使用。

资源标签是我们将在 SPS-L GUI 中看到的名称，我喜欢使用易于识别的名称。

如果一切配置正确，您将看到“结束成功还原”，然后我们可以将其扩展到另一个节点，以便资源可以托管在任一节点上。

这显示了扩展至两个节点后完成的负载均衡器配置。

该集群的最后一步是为三个 NFS 导出创建子依赖项，这意味着所有带有 Datakeeper 镜像和 IP 的 NFS 导出都将依赖于负载均衡器。 如果活动节点上出现严重问题，则所有这些资源都将故障转移到其他正常运行的节点。

上图是 Lifekeeper GUI 中完整的层次结构。 下面显示了扩展的 GUI 视图，显示 NFS 导出、IP、文件系统和 DataKeeper 复制卷作为负载均衡器资源的子项。

这只是您如何使用 SIOS LifeKeeper 的一个示例天蓝色保护一个简单的 NFS 集群。 同样的概念适用于您需要保护的任何关键业务应用程序。 您只需利用 SIOS 提供的负载均衡器 ARK 来允许 Azure 负载均衡器（内部或外部）确定当前托管应用程序的节点。