在高可用性中使用回避策略的四个理由

避免某些事情——我们以前都做过。我们在与配偶散步时在商店里看到的旧情人，在我们“不准备购买”时看到的销售人员，甚至在我们“度假”时看到的老板。当我是一个开发团队的经理时，我瞥见了一个直接报告在他们应该不在办公室生病时浏览商店。他们躲在衣架之间，匆匆跑下下一个过道，匆匆离开。我们以前都这样做过，在某些情况下，出于心理健康、身体健康或隐私和个人原因，我们都需要采取一些避免措施。即使在 HA。那么，你如何在你的高可用性环境，为什么？

在高可用性中使用回避策略的四个理由

• 更好的性能（最小化服务器过载）

在 HA 中使用避免策略的原因之一是提高应用程序和服务器性能。考虑运行生产工作负载的三台服务器的情况，我们称它们为 Server Alpha、Server Beta 和 Server Gamma。服务器 Alpha 和 Beta 运行由数据库支持的关键应用程序，而服务器 Gamma 运行报告和数据转换作业。如果 Server Alpha 出现故障，通常会发生故障转移到 Server Beta。但是，由于服务器 Beta 已经在运行大量工作负载，因此产生的额外应用程序负载可能会导致服务器过载和两个应用程序的性能不佳。因此，部署避免策略以确保选择 Server Gamma 作为故障转移目标可能是明智之举。

• 性能优化

再次考虑三个服务器的场景，Alpha、Beta 和 Gamma。服务器 Alpha 和 Beta 可扩展以处理峰值工作负载，而服务器 Gamma 是成本优化的服务器。如果 Server Alpha 和 Server Beta 出现故障，则会发生故障转移到成本优化的服务器 Gamma。但是，此服务器无法扩展以处理峰值工作负载，也无法同时处理 Server Alpha 和 Server Beta 的工作负载。在这种情况下，可以使用规避策略通过在另一台主机可用时自动从 Server Gamma 移动一个或两个工作负载来优化性能。

• 高可用优化

HA 优化是另一种部署回避策略的场景。 与性能优化策略一样，HA 优化用于确保您的环境能够承受大多数故障情况，并且您的应用程序经过优化以在任何时间点提供最高级别的可用性。HA 优化对于具有复制入队进程的 SAP 等应用程序很重要。在任何 SAP 环境中，您都不希望 ASCS（ABAP SAP 中央服务）和 ERS（入队复制服务）实例长时间驻留在同一服务器上，因为存在丢失锁定和取消作业的风险。 为了防止这种情况发生，您可以使用避免策略，使 ERS 和 ASCS 实例始终在相对的集群节点上运行。考虑运行生产工作负载的三台服务器的情况，我们称它们为服务器 Alpha、Beta 和 Gamma。Server Alpha 正在运行 ASCS 实例，而 Server Beta 正在运行 ERS 实例。服务器 Gamma 用作服务器 Beta (ERS) 和服务器 Alpha (ASCS) 故障转移的第三个节点。如果 Beta 崩溃，您不希望 ERS 资源与 ASCS 实例在同一节点上运行。为确保此操作，您可以部署避免策略，首先自动检查并确保两个应用程序位于不同的服务器上，并维护 SAP ASCS/ERS 锁定故障转移的最佳实践。

• DR避免

假设您有两个数据中心：City Alpha 和 City Beta，它们相距约 70 英里，您的大多数客户都位于它们之间的中心。 但是，由于最近内部组织的变化、合并/关闭和收购以及治理要求，您的 IT 团队必须添加位于 City Gamma 的第三个数据中心，距离 Alpha 和 Beta 大约 350 英里。现在主要在 Alpha 和 Beta 中保护的资源也扩展到 Gamma 位置。鉴于大多数用户和团队都在 Alpha 和 Beta 位置附近，即使是最极端的用户也位于邻近城市，您的团队需要避免故障转移到 Gamma 位置。 与其他策略一样，DR 避免寻求通过避免 DR 节点来优化性能、输入/输出区域数据成本、延迟和客户端访问，如果任一区域内只有一个节点发生故障。它还可以确保即使两个节点在不同的时间后都发生故障，在转移到 DR 之前，故障转移总是发生在集群或数据中心中的另一个节点上。

那么，您如何部署回避策略呢？

许多提供程序具有可以配置的关联规则，而其他提供程序使用服务器优先级或手动步骤的组合。对于适用于 Linux 的 SIOS 保护套件，您可以使用多种内置方法，包括：

• 资源优先级

如果发生故障，资源将故障转移到剩余优先级最低的服务器，并级联到任何其他服务器（Alpha、Beta 和 Gamma）。Server Alpha 是Resource.HR 的主服务器，Server Beta 是Resource.MFG 的主服务器，Server Gamma 是所有资源/服务器的备份服务器。使用资源优先级，Resource.HR 在服务器 Alpha 上的优先级为一 (1)，在服务器 Gamma 上的优先级为二 (2)。而 Resource.MFG 在服务器 Beta 上的优先级为一 (1)，在服务器 Gamma 上的优先级为二 (2)。如果客户想要优化环境的使用，那么 Resource.HR 在 Server Beta 上的优先级可以是三 (3)，Resource.MFG 在 Server Alpha 上的优先级可以是三 (3)。如果服务器 Alpha 发生故障，资源 Resource.HR 将首先失败到服务器 Gamma，然后再尝试在服务器 Alpha 上投入使用（恢复）。

适用于 Linux 的 SIOS 保护套件（UI 和 CLI）允许用户为每个服务器和资源组合指定优先级。

• 策略或关联规则

策略规则还可用于防止在给定服务器上发生资源恢复，从而允许资源避开可能正在运行更关键或资源密集型工作负载的指定服务器。典型的政策包括：

• • • • • • 默认情况下将阻止来自特定服务器的应用程序的约束策略。
          • 将阻止应用程序来自没有足够资源的服务器的资源策略
          • 定义允许或禁止资源进入系统的时间段的临时策略
          • 定义首选服务器或集群内可能的应用程序所有权能力的自定义策略

SIOS Protection for Linux CLI 允许用户指定策略规则，这些规则可以禁用故障转移到指定服务器的特定资源、提供保护故障的临时策略、禁用特定应用程序类型的故障、约束策略和自定义策略。

• 特定规避资源

建立资源避免策略的最细粒度的方法是在每个层次结构中部署特定的避免脚本。这种方法将允许用户配置特定的应用程序（例如 app1 和 app2），尽可能避免彼此，同时允许其他应用程序不受限制地运行。在我们的三个服务器（Alpha、Beta 和 Gamma）以及三个资源 app1、app2 和 app3 的情况下，此方法将提供最大的灵活性。在这个例子中，app1 和 app2 将在服务器出现故障时寻求避免搭配，但 app3 将根据优先级失败到下一个可用节点，没有任何搭配限制。

有关避免策略和资源的其他示例，请考虑适用于 Linux 的 SIOS 保护套件文件.如果客户有两个应用程序 app1 和 app2，他们需要尽可能在不同的节点上运行，则客户可以使用 SIOS Protection Suite for Linux gen/app 资源和 ‘/opt/LifeKeeper /lkadm/bin/avoid_restore’ 脚本。

转载自SIOS