如何从Service Fabric运行时重新启动/回收底层VM

Question

当应用程序处于错误状态时，我想实现以下恢复尝试：

1. 重启应用程序本身
2. 重新启动底层VM
3. 重建底层VM

使用Cloud Service，只需调用Environment.FailFast并自动触发上述序列即可。

如何使用Service Fabric实现相同的目标？目前，它被用作VM Scale Set（每个VM一个应用程序实例）之上的部署/维护层。

更新：使用Service Fabric无法执行此操作。对于我们的服务，我们决定直接在VM Scale Set上构建它。希望我们看到Cloud Service v2也建立在VM Scale Set之上，它将负责部署/维护。

Answer 1

Service Fabric有一个内置机制来重启失败的应用程序，但服务结构不了解“坏状态”是什么。如果应用程序失败并且进程关闭，SF将重新启动它几次，直到它放弃并认为应用程序已损坏并阻止重新启动。

如果它不时发生，例如，每周发生几次，那就不会有任何问题，因为在相同问题的连续失败部分有多长时间存在阈值。

当您说Bad State时，每个应用程序可能有不同的Bad State概念，因此除非应用程序通过Health Event报告，否则无法通过SF识别它。

例：

• 应用程序可能正在消耗太多内存（内存泄漏），您唯一能做的就是限制应用程序内存设置的限制，SF不知道这是一个泄漏，也许是应用程序设计的内存消耗部分。
• 另一个问题，由于无效配置或依赖服务而返回错误响应的API已关闭。如果错误是由于应用程序故障或您的服务设计导致服务结构无法打结。

在这些情况下，您必须实现一种机制来告诉SF这些错误是不期望的，SF将为您处理故障转移。您可以将其实现为：

• 作为应用程序的一部分，它将发出自己的健康报告
• 在群集中运行的监视应用程序监视服务事件或日志并代表其他服务发出事件。

对于第一种方法，使用qazxsw poi的快速方式将此报告为失败：

允许副本向运行时报告故障，并指示它遇到无法恢复的错误，必须重新启动或删除。

有关其他健康报告的更多信息，请查看此文档：ReportFault

对于问题的第2项和第3项，有一种机制可以识别群集中某个节点何时不可用，它会降级，SF会暂时将其从RING中删除。常见问题是当网络问题阻止节点相互通信时，在某些情况下，内存不足可能会影响SF Host Manager并且它开始失败，响应速度慢，然后SF将从可用节点列表中删除该节点，直到它恢复健康。

我不知道SF中有什么东西会重新启动虚拟机，可能是因为之前提到的相同原因，它会在SF资源管理器中引发故障以通知问题，你将不得不处理它。

作为上述监视方法的一部分，您可以制定解决方案，Service Fabric health reports将从节点移动任何Healthy服务，然后您可以使用Disable-ServiceFabricNode重新启动基础VM。