azure-service-fabric - Azure Service Fabric 可靠集合和内存

Question

假设我在 5 个 D1 类(1 个核心、3.5GB RAM、50GB SSD)VM 上运行 Service Fabric 群集。并且我在这个集群上运行了 2 个可靠的服务，一个是无状态的，一个是有状态的。假设副本目标为 3。

如何计算我的可靠收藏可以容纳多少？

假设我添加了一个或多个有状态服务。由于我真的不知道框架如何分配服务，我是否需要采取最保守的方法并假设一个节点可以在单个节点上运行我的所有有状态服务，并且它们的累积内存需要低于可用的 RAM单机？

Answer 1

TLDR - 估计集群的预期容量既是艺术，也是科学。您可能会得到一个很好的下限，您可以将其推高，但在大多数情况下，部署、运行它们并在您的工作负载条件下收集数据是回答这个问题的最佳方式。

1) 一般来说，给定机器上的集合受可用内存量或节点上可用磁盘空间量的限制，以较低者为准。今天，我们将集合中的所有数据保存在内存中，并将其持久化到磁盘。因此，您跨集群的集合可以容纳的最大数量通常是(集群中的可用内存量)/(目标副本集大小)。

请注意，“可用内存”是机器上运行的其他代码(包括操作系统)剩余的任何内容。在上面的示例中，虽然您没有运行所有节点 - 您只能获得其中的 3 个。因此，(不切实际地)假设这些其他因素的开销为 0，您可以期望能够在运行它的节点上的内存耗尽之前将大约 3.5 GB 的数据放入该有状态服务副本。集群中仍然会有 2 个节点留空。

让我们再举一个例子。假设它与您上面的示例大致相同，除了在这种情况下您将有状态服务设置为要分区。假设您选择的分区数为 5。所以现在在每个节点上，您有一个主副本和来自其他分区的 2 个辅助副本。在这种情况下，每个分区最多只能保存大约 1.16 GB 的状态，但现在总体上可以将 5.83 GB 的状态打包到集群中(因为现在可以充分利用所有节点)。顺便说一下，只是为了证明数学有效，即(每个节点 3.5 GB 内存 * 集群中的 5 个节点)[17.5]/(目标副本集大小为 3)= 5.83。

在所有这些示例中，我们还假设所有分区和所有副本的内存消耗是相同的。很多时候事实证明并非如此(至少暂时是这样) - 某些分区最终可能需要完成或多或少的工作，因此资源消耗不均匀。我们还假设次要总是与主要相同。在状态量的情况下，假设这些将相当均匀地跟踪可能是公平的，尽管对于其他资源消耗可能不会(只是要记住)。在消耗不均的情况下，这确实是 Service Fabric 的集群资源管理的其余部分将有所帮助的地方，因为我们可以了解不同副本的消耗情况并将它们有效地打包到集群中以利用可用空间。自动报告与集合中的状态相关的资源消耗是我们的雷达，也是我们想做的事情，所以在 future ，这将是自动的，但今天你必须自己报告这种消耗。

2) 默认情况下，我们会根据默认指标来平衡服务(更多关于指标的信息是 here )。因此，默认情况下，这两个不同服务的不同副本可能会出现在机器上，但在您的示例中，您最终会得到 4 个节点，其中有 1 个来自其上的服务的副本，然后是 1 个节点，其中有来自这两个服务的两个副本不同的服务。这意味着每个服务(根据您的示例每个服务有 1 个分区)在每个服务中只能消耗 1.75 GB 的内存，而集群中的总内存为 3.5 GB。这再次小于集群的总可用内存，因为您没有使用某些节点部分。

请注意，这是最大可能的消耗，并且假设在服务本身之外没有消耗。将此作为您的最大值是不可取的。您可能出于多种原因想要减少它，但最实际的原因是确保在出现升级和故障时集群中有足够的可用容量。例如，假设您有 5 个升级域和 5 个故障域。现在假设当您在升级域中进行升级时，容错域的节点发生故障。这意味着(略低于)集群容量的 40% 可能随时消失，并且您可能希望在剩余节点上留出足够的空间来继续。这意味着，如果您的集群以前可以保存 5.83 GB 的状态(根据我们之前的计算)，实际上您可能不想在其中放置超过 3.5 GB 的状态，因为如果有更多的状态，服务可能无法恢复到 100% 的健康状态(还要注意，我们不会立即构建替换副本，因此在您遇到这种情况之前，节点必须在 ReplicaRestartWaitDuration 期间关闭)。 this article 中涵盖了更多关于指标、容量、缓冲容量(您可以使用这些信息来确保节点上为故障情况留出空间)以及故障和升级域的信息。 .

还有一些其他的东西实际上会限制你可以存储的状态量。你会想做几件事:

估计数据的大小。您可以通过计算对象包含的每个字段的大小，预先合理估计数据的大小。请务必考虑 64 位引用。这会给你一个下限的起点。

存储开销。您存储在集合中的每个对象都会带来一些用于存储该对象的开销。在取决于集合和当前进行中的操作(复制、枚举、更新等)的可靠集合中，此开销的范围可以从 100 到大约 700 字节之间，每个项目(行)存储在集合中。还要知道，我们一直在寻找减少我们引入的开销的方法。

我们还强烈建议您在一段时间内运行您的服务，并通过性能计数器测量实际资源消耗。模拟某种真实的工作负载，然后测量您关心的指标的实际使用情况，将为您提供很好的服务。我们特别推荐这样做的原因是，您将能够从诸如对象最终放置在哪个 CLR 对象堆中、GC 运行的频率、是否存在泄漏或其他类似会影响数量的事情中看到消耗您可以实际使用的内存。

我知道这是一个很长的答案，但我希望您觉得它有用且完整。