Service Fabric 资源平衡器使用过时的报告负载答案

【问题标题】：Service Fabric Resource balancer uses stale Reported loadService Fabric 资源平衡器使用过时的报告负载
【发布时间】：2016-04-07 09:47:13
【问题描述】：

在查看 Service Fabric 上的资源平衡器和动态负载指标时，我们遇到了一些问题（运行 devbox SDK GA 2.0.135）。
在 Service Fabric Explorer（门户和独立应用程序）中，我们可以看到平衡运行非常频繁，most of the time it is done almost instantly，并且每秒都会发生这种情况。在查看节点或分区上的负载指标信息时，它不会在我们报告负载时更新值。

我们根据我们的交互（对服务的 HTTP 请求）发送动态负载报告，大量增加单个分区的报告负载数据。这个尖峰在 5 分钟后在某处变得可见，此时平衡器实际上开始平衡。这似乎是刷新负载数据的时间间隔。 上次报告的时间一直在更新，但没有新值。

我们将指标添加到 applicationmanifest 和 clustermanifest 以确保在平衡中使用它。这意味着资源平衡器使用相同的数据 5 分钟。这是可配置的设置吗？是因为它在开发盒上运行而受到限制吗？我们在集群清单中尝试了很多变量，但似乎没有一个会影响刷新时间。

如果这不适应，有人可以解释为什么你会用陈旧的数据运行平衡器吗？为什么选择这个 5 分钟的间隔？

【问题讨论】：

标签： metrics azure-service-fabric rebalancing

【解决方案1】：

这确实是一个可配置的设置，默认为 5 分钟。其背后的想法是，在 prod 中，您有大量的副本一直在报告负载，因此您希望将它们批量化，这样您就不会将所有这些作为独立消息向集群资源管理器发送垃圾邮件。

你可能是对的，这个值对于本地开发来说方式太长了。我们将考虑更改本地集群的设置，但与此同时，您可以将以下内容添加到本地集群清单中，以更改我们默认等待的时间。如果那里已经有其他设置，只需添加 SendLoadReportInterval 行。该值以秒为单位，您可以相应地调整它。下面会将默认负载报告间隔从 5 分钟（300 秒）更改为 1 分钟（60 秒）。

    <Section Name="ReconfigurationAgent">
        <Parameter Name="SendLoadReportInterval" Value="60" />
    </Section>

请注意，这样做确实会增加某些系统服务 (TANSTAAFL) 的负载，并且与往常一样，如果您在生成或完整的集群清单上进行操作，请务必在部署之前进行 Test-ServiceFabricClusterManifest。如果您使用本地开发集群，部署它的最简单方法可能只是修改集群清单模板（默认情况下：“C:\Program Files\Microsoft SDKs\Service Fabric\ClusterSetup\NonSecure\ClusterManifestTemplate. xml") 并添加该行，然后右键单击系统托盘中的 Service Fabric 本地集群管理器并选择“重置本地集群”。这将使用您对模板的更改重新生成本地集群。

【讨论】：

您提到了本地开发场景，但是对于使用 ARM JSON 模板部署的 Azure 集群，我们如何实现呢？我没有看到 Customize Service Fabric cluster settings 上列出的“SendLoadReportInterval”设置
那是因为它不是我们认为人们应该触摸的真正设置，因此被标记为内部 - 调整此值可能会通过在系统服务上引入过多负载来破坏您的集群。在生产中，我们看不到人们在实践中需要触摸它，所以没有描述。例如，如果您出于某种原因确实想在 prod.xml 中更改它，则从 XML 到 JSON 的语法转换与您看到的 here 相同。不推荐。
很公平 - 非常有帮助。我想坚持推荐的设置，但只是为了我 [缺乏] 理解 - 比如说我有一个监视我的指标的看门狗服务，这是否意味着在生产中通常可以接受任何可见性或反应性操作被延迟 up到五分钟？我正在尝试尽可能多地利用内置功能。
是的，这就是会发生的事情，这就是上限。对于平衡和修复这些理想化的度量容量限制，这种延迟通常是可以接受的。这就是集群资源管理——优化。还要记住，随着这扩展到许多节点和服务——如果事情真的那么泡沫，那么你会看到约束被违反并一直被修复（集群资源管理器的每次运行——每隔几秒钟），因为节点最终会在整个 5 分钟的报告窗口中涂抹。在实践中，他们最终会“不断报告”。
另外，如果您真的需要对资源消耗进行严格、即时的治理，那么 /logical/ 指标可能不是满足这些要求的最佳位置，您应该查看 Resource Governance 的东西我们在 5.6 中发布的，但这仅适用于实际资源（撰写本文时的 CPU 和内存）。