1

我有一个 Asp.Net core 2.0 Wen API，它的逻辑相对简单（在 SQL Azure DB 上进行简单选择，返回大约 1000-2000 条记录。没有连接、聚合、函数等）。我只有 1 个 GET API。这是从角度SPA调用的。两者都作为无状态服务部署在服务结构中，作为自托管 exe 托管在 Kestrel 中。

考虑到用户数量和刷新频率，我确定每分钟大约有15000个请求。换句话说，250 个请求/秒。

在创建 Service Fabric 群集时，我试图了解不同的设置。

我想知道：

  1. 有多少节点类型？（我已经确定为前端和后端）
  2. 每个节点类型有多少个节点？
  3. 我需要选择的 VM 大小是多少？

我已经准备好了关于集群容量规划的 azure文档。虽然我理解这些概念，但我没有参考框架来确定我需要为上述问题提供的实际值。

4

1 回答 1

2

在您阅读有关集群规划的大多数地方，他们会建议该主题既是科学又是艺术，因为这个问题没有简单的答案。很难回答，因为它在很大程度上取决于应用程序的复杂性，在不了解其工作原理的情况下，我们只能猜测解决方案。

根据您的问题，我能给您的最佳指导是，Measure first, Measure again, Measure... Plan later. 您的应用程序可能是内存密集型、网络密集型、CPU、磁盘等，找到最佳配置的唯一方法是了解它。

要在对 SF 结构做出任何决定之前了解您的应用程序，您可以简单地部署一个具有多种节点类型的简单集群，其中包含每个 VM 大小的一个节点，并在每个节点上测量您的应用程序行为，然后您将添加更多节点和跨度您的服务在这些节点上的多个实例，并查看哪种配置最适合每个服务。

1.有多少节点类型？

我喜欢将节点类型以 1:1 的方式映射到您的应用程序上的角色，但这不是法律，这将取决于每个服务将消耗多少资源，如果服务消耗足够的资源以使单个 VM（节点）忙碌（内存, CPU, Disk, IO), 这是拥有自己的节点类型的一个很好的候选者, 在其他情况下, 有一些轻量级的服务会浪费资源为其配置整个 VM(节点), 一个例如，计划作业、备份等，在这种情况下，您可以配置一组可以为这些服务共享的机器，当您与多个服务共享一个节点类型时，您必须记住的重要一点是它们将争夺资源（内存、CPU、网络、磁盘），而您单独为每个服务采取的性能测量可能不再相同，所以他们需要更多的资源，可以选择一起测试它们。

另一点是副本的数量，拥有一个服务实例是不可靠的，因此您必须创建它的副本（我在下一个答案中描述的正确数字），在这种情况下，您最终会得到服务负载拆分到多个节点，使这种节点类型得到充分利用，是您可以考虑在相同节点类型上加入服务的地方。

2.每种节点类型有多少个节点？

如前所述，这将取决于您的服务资源消耗，但一个非常基本的规则是每个节点类型至少 3 个。

为什么是3？

因为 3 是您可以进行滚动更新并保证 51% 的节点\服务\实例运行的法定人数的最低数字。

  • 1 个节点：如果您有一个服务在 1 个节点类型的节点类型中运行 1 个实例，当您部署新版本的服务时，您必须在新版本出现之前关闭此实例，因此您不会有任何实例以在升级时为负载提供服务。
  • 2 个节点：类似于 1 个节点，但在这种情况下，您只保持 1 个节点运行，如果发生故障，在新实例出现之前您不会有故障转移来处理负载，如果您正在运行会更糟有状态的服务，因为在升级过程中您将只有一份数据副本，如果发生故障，您可能会丢失数据。
  • 3 节点：在更新期间您仍有 2 个节点可用，当正在更新的一个恢复时，下一个被放下，您仍然有 2 个节点在运行，如果一个节点发生故障，另一个节点可以支持负载直到部署了新节点。

3个节点并不意味着你的集群会非常可靠，这意味着失败和数据丢失的机会会更低，你可能会不幸同时松动2个节点。正如文档中所建议的那样，在生产中最好始终将节点数保持为 5 个或更多，并计划有 51% 的节点\服务可用。在这种情况下，如果您确实需要更长的正常运行时间，我会推荐 5、7 或 9 个节点99.9999...%

3.我需要选择的VM大小是多少？

如前所述，只有测量才能给出这个答案。

观察：

这些建议没有考虑到Primary Node Types的规划，建议Primary Node Types上至少有5个节点，是SF系统服务放置的地方，他们负责管理集群，所以必须高度可靠，否则您可能会失去对集群的控制。如果您计划与您的应用程序服务共享这些节点，请记住您的服务可能会影响它们，因此您必须始终监控它们以检查它可能造成的任何影响。

于 2018-05-11T10:04:04.840 回答