让我们说我在5个D1级（1核，3.5GB RAM，50GB SSD）VM上运行Service Fabric群集。并且我在这个集群上运行了2个可靠的服务，一个是无状态的，一个是有状态的。我们假设副本目标是3.
如何计算我的可靠藏品能容纳多少？
我们假设我添加了一个或多个有状态服务。由于我不太了解框架如何分配服务，我需要采取最保守的方法并假设节点可以在单个节点上运行我的所有有状态服务，并且它们的累积内存需要低于可用的RAM在一台机器上？
答案 0 :(得分：23)
TLDR - 估计群集的预期容量是部分艺术，部分科学。你可能会获得一个很好的下限，你可能会推高，但在大多数情况下，部署，运行它们，以及在工作负载条件下收集数据是回答这个问题的最佳方法。
1）通常，给定计算机上的集合受可用内存量或节点上可用磁盘空间量（以较低者为准）的限制。今天我们将所有数据保存在内存中，并将其保存到磁盘中。因此，群集中的集合可以容纳的最大量通常是（群集中的可用内存量）/（目标副本集大小）。
请注意＆＃34;可用内存＆＃34;是从机器上运行的其他代码遗留下来的东西，包括操作系统。在上面的示例中，虽然您没有在所有节点上运行 - 但您只能获得其中的3个节点。因此，（不切实际地）从这些其他因素假设0开销，您可以期望能够在运行它的节点上的内存不足之前将大约3.5 GB的数据放入该有状态服务副本。群集中仍有2个节点留空。
让我们再看一个例子。让我们说它与上面的示例大致相同，除非在这种情况下您设置要分区的有状态服务。假设您选择的分区数为5.因此，现在每个节点上都有一个主副本和两个来自其他分区的辅助副本。在这种情况下，每个分区最多只能容纳大约1.16 GB的状态，但现在总体而言，您可以将5.83 GB的状态打包到群集中（因为现在可以完全利用所有节点）。顺便说一下，为了证明数学是有效的，那个（每个节点3.5 GB的内存*集群中的5个节点）[17.5] /（目标副本集大小为3）= 5.83。
在所有这些示例中，我们还假设所有分区和所有副本的内存消耗是相同的。很多时候事实证明不是真的（至少是暂时的） - 一些分区最终可能会有更多或更少的工作要做，因此资源消耗不均匀。我们还假设副词总是与初选相同。在国家数量的情况下，可能公平地假设这些将相当均匀地跟踪，但是对于其他资源消耗它可能不是（只是要记住的事情）。在消费不均衡的情况下，这正是Service Fabric的其他群集资源管理将提供帮助的地方，因为我们可以了解不同副本的消耗并将它们有效地打包到群集中以利用可用的副本空间。自动报告集合中与州相关的资源消耗是我们想要做的事情，因此将来这将是自动的，但今天您必须自己报告这种消耗。
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中包含故障和升级域。
还有一些其他的东西实际上会限制你能够储存的州的数量。你想要做几件事：
我们还强烈建议您在一段时间内运行服务，并通过性能计数器测量实际资源消耗。模拟某种实际工作负荷然后测量您关心的指标的实际使用情况将很好地为您服务。我们之所以特别推荐这一点，是因为您可以看到消费来自哪些CLR对象堆最终放置的对象，GC的运行频率，是否存在泄漏，或其他类似的事情。会影响您实际可以使用的内存量。
我知道这是一个很长的答案，但我希望你觉得它有用而且完整。