Partager via

群集资源管理器与 Service Fabric 群集管理的集成

Service Fabric 群集资源管理器不会主导 Service Fabric 中的升级过程，但它参与其中。 群集资源管理器帮助进行管理的第一种方法是跟踪群集及其内部服务的期望状态。 群集资源管理器在无法将群集放入所需配置时发送运行状况报告。 例如，如果容量不足，群集资源管理器会发出健康警告和错误指示问题。 集成的另一个部分与升级的工作方式有关。 在升级期间，群集资源管理器会稍微改变其行为。

健康集成

群集资源管理器会持续跟踪您为放置服务而定义的规则。 它还会在节点和群集上，以及整个群集中，跟踪每个指标的剩余容量。 如果无法满足这些规则或容量不足，则会发出健康警告和错误。 例如，如果某个节点超出容量，Resource Manager 将尝试通过移动服务来修复这种问题。 如果无法纠正，群集资源管理器将发出运行状况警告，指出哪个节点超出容量，以及警告是针对哪些指标。

Resource Manager 健康警告的另一个示例是违反了放置限制。 例如，如果已定义放置约束（如 "NodeColor == Blue"），而资源管理器检测到违反该约束的情况，则会发出运行状况警告。 这一点适用于自定义约束和默认约束（例如容错域和升级域约束）。

下面是这种健康报告的示例。 在这种情况下，运行状况报告适用于系统服务的分区之一。 运行状况消息指出，该分区的副本暂时集中在过少的升级域数量中。

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'

PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

以下是此健康消息告诉我们的内容：

  1. 所有副本本身都是健康的：每个都有 AggregatedHealthState : Ok
  2. 目前违反了升级域分配约束。 某个升级域在此分区中拥有的副本数超过了应有的数量。
  3. 哪个节点包含会引起违规的副本。 在本例中，它是名为 Node.8 的节点
  4. 此分区中是否正在进行升级（“当前正在升级 -- false”）
  5. 此服务的分发策略：“分发策略 -- 打包”。 这受 RequireDomainDistribution放置策略的控制。 打包 表示在这种情况下不需要 DomainDistribution，因此我们知道该服务没有指定放置策略。
  6. 报告发生时间 -- 2015/8/10 晚上 7:13:02

这种类型的信息驱动警报系统。 可在生产中使用警报来知晓某个地方出错。 警报还用于检测和停止不良升级。 在这种情况下，我们希望能够弄清楚为什么资源管理器模块需要将副本打包到升级域。 通常情况下，分组是暂时的，例如，因为其他升级域中的节点宕机了。

假设群集资源管理器正尝试放置某些服务，但没有任何可行的解决方案。 如果无法放置服务，这通常是出于以下原因之一：

  1. 某个暂时性状态导致无法正确放置此服务实例或副本
  2. 无法满足该服务的放置要求。

在这种情况下，群集资源管理器的健康报告可以帮助您确定服务无法放置的原因。 我们将此过程称为“约束消除序列”。 在此过程中，系统将逐步检查配置的约束如何影响服务，并记录它们所消除的内容。 这样，当无法放置服务时，便可以看到哪些节点已被消除及其原因。

约束类型

接下来，我们讨论一下这些健康报告中的每一个不同的约束。 当无法放置副本时，你将看到与这些约束相关的运行状况消息。

  • ReplicaExclusionStatic 和 ReplicaExclusionDynamic：这些约束指示某个解决方案遭到拒绝，因为同一分区中的两个服务对象必须放置在同一节点上。 不允许这样操作，因为该节点的失败会过度地影响该分区。 ReplicaExclusionStatic 和 ReplicaExclusionDynamic 遵循几乎相同的规则，有所差别也无关紧要。 如果看到的约束消除序列包含 ReplicaExclusionStatic 或 ReplicaExclusionDynamic 约束，群集资源管理器就会认为没有足够的节点。 这要求剩余的解决方案需要使用这些被禁止的无效放置。 序列中的其他约束通常会告诉我们首先要消除节点的原因。
  • PlacementConstraint：如果看到此消息，表示已消除了一些节点，因为它们不符合服务的放置约束。 我们在此消息中描绘当前配置的放置约束。 如果定义了放置约束，则这种情况是正常的。 但是，如果放置约束错误地导致消除了过多的节点，则会看到这种结果。
  • NodeCapacity：此约束表示群集资源管理器无法将副本放在指定的节点上，因为这样放置会超出容量。
  • Affinity：此约束表示无法将副本放在受影响的节点上，因为这会导致违反相关性约束。 此文介绍了有关相关性的详细信息。
  • FaultDomain 和 UpgradeDomain：如果将副本放在指定的节点上会导致副本打包在特定的容错域或升级域中，此约束将消除节点。 容错域与升级域约束及结果行为中的主题提供了几个讨论此约束的示例
  • PreferredLocation：通常我们看不到这个会将节点从解决方案中删除的约束，因为该约束默认作为优化运行。 首选的位置约束在升级过程中也同样适用。 在升级期间，它用于将服务移回到升级开始时所处的位置。

将节点列入阻止列表

群集资源管理器报告的另一个运行状况消息是节点何时列入阻止列表。 可以将黑名单视为为您自动应用的临时约束。 如果节点在启动该服务类型的实例时遇到重复的失败，则会将这些节点列入阻止列表。 根据每个服务类型，将节点列入阻止列表。 某个节点可能因为一种服务类型而被列入阻止列表，但不会因为其他服务类型。

开发过程中经常会看到阻止列表：某些 bug 导致服务主机在启动时崩溃，Service Fabric 会尝试创建服务主机几次，并且失败仍然存在。 几次尝试后，会将该节点列入阻止列表，群集资源管理器会尝试在其他位置创建该服务。 如果该故障在多个节点上发生，则可能最终会将群集中的所有有效节点列入阻止列表。 列入阻止列表还可移除很多节点，导致可用节点数不足，无法成功启动服务以满足所需规模。 通常会看到群集资源管理器的其他错误或警告，指示服务低于所需的副本数或实例数，还会看到运行状况消息，指示导致列入阻止列表的首要故障是什么。

列入阻止列表不是永久性条件。 几分钟后，会从阻止列表删除该节点，并且 Service Fabric 可能会再次激活该节点上的服务。 如果服务仍失败，则会再次因该服务类型而将该节点列入阻止列表。

约束优先级

警告

不建议更改约束优先级，并且可能对群集造成严重的不利影响。 提供以下信息，供默认约束优先级及其行为参考。

考虑到所有这些约束，您可能一直在想：“嘿，我认为故障域约束是我系统中最重要的事情。” 为了确保不违反容错域约束，我情愿违反其他约束。”

可为约束配置不同的优先级别。 它们是：

  • “硬”(0)
  • “软”(1)
  • “优化”(2)
  • “关”(-1)。

大多数约束默认配置为硬约束。

更改约束的优先级并不常见。 有时需要更改约束优先级，通常是为了解决已影响环境的其他 bug 或行为。 一般情况下，约束优先级基础结构的灵活性效果良好，但通常不需要它。 大部分时间内，所有内容都保持在默认优先级。

优先级别不表示会违反给定的约束，也不表示会始终满足给定约束。 约束优先级定义强制执行约束的顺序。 当无法满足所有约束时，优先级定义权衡。 通常可以满足所有约束，除非环境中还有其他要求。 导致约束冲突的一些方案示例是冲突约束或大量并发故障。

在某些高级场合中，可以更改约束优先级。 例如，假如您希望在必要时，为了解决节点容量问题而始终违反亲和性。 为此，可将相关性约束的优先级设置为“软”(1)，将容量约束保持设置为“硬”(0)。

以下配置文件中指定了不同约束的默认优先级值：

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

通过用于独立部署的 ClusterConfig.json 或用于 Azure 托管群集的 Template.json：

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

容错域和升级域约束

集群资源管理器希望保持服务在故障域和升级域之间的分布。 它会将此作为群集资源管理器引擎内的约束进行建模。 有关如何使用它们及其特定行为的详细信息，请查看 有关群集配置的文章。

群集资源管理器可能需要将一些副本打包到升级域，以便应对升级、故障或其他约束违规。 通常，只有当系统中出现多次故障或其他频繁变化阻碍了正确放置时，才会将数据打包到故障域或升级域。 处于这些情况下若要防止打包，可以使用 RequireDomainDistribution放置策略。 请注意，这样做可能会影响服务可用性和可靠性，因此请仔细考虑。

如果已正确配置环境，则即使在升级期间，也会完全遵循所有约束。 关键的一点是，群集资源管理器负责监视您的约束。 检测到违规时，它会立即报告并尝试解决问题。

首选位置约束

PreferredLocation 约束稍有不同，因为它具有两种不同的用法。 此约束的一个用法是在应用程序升级过程中使用。 群集资源管理器在升级过程中自动管理此约束。 它用于确保升级完成时该副本返回到其初始位置。 PreferredLocation 约束的另一种用法是用于 PreferredPrimaryDomain放置策略。 这两种用法都是优化，因此 PreferredLocation 约束是唯一默认设置为“Optimization”的约束。

升级

在应用程序和群集升级期间，群集资源管理器也会提供帮助，在此过程中，它有两个任务：

  • 确保群集的规则不受到影响
  • 尝试帮助升级顺利完成

继续强制执行规则

规则需要注意的主要问题是，在升级过程中，严格的约束（如放置约束和容量）依然会被强制执行。 放置约束可确保工作负荷仅在允许其运行的位置，即使在升级期间也是如此。 对服务采取高度约束时，升级可能需要更长时间。 服务或其节点在因更新而被停用时，其可运行的位置可能选择不多。

智能替换

开始升级时，Resource Manager 将创建当前群集排列方式的快照。 每个升级域完成后，会尝试将该升级域中的服务恢复到其原始排列方式。 这样，一个服务在升级过程中最多可以有两次转换。 有一次是从受影响的节点移出，另一次是移动回该节点。 将群集或服务恢复到升级前的状态还可确保升级不会对群集的布局造成影响。

客户流失减少

在升级期间，群集资源管理器也会关闭均衡。 阻止均衡可防止对升级本身做出不必要的反应，例如，为了升级而将服务移入空节点。 如果有问题的升级是群集升级，则整个群集在升级期间会失衡。 约束检查始终处于活动状态，仅禁用基于主动度量指标均衡的移动。

缓冲容量与升级

通常，即使群集受到约束或接近完整，我们还是希望升级能够完成。 在升级期间管理群集容量的能力比平常时候更为重要。 根据升级域的数目，当在群集中进行升级时，必须迁移 5% 到 20% 的容量。 工作必须去某处。 这就是缓冲容量概念派上用场的地方。 在正常操作过程中，缓冲容量会被遵守。 如有必要，在升级过程中，群集资源管理器可能会将节点填充到其总容量（占用缓冲区）。

后续步骤

  • Last updated on