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

Question

当应用程序处于不良状态时，我希望进行以下恢复尝试：

1. 重新启动应用本身
2. 重新启动基础虚拟机
3. 重建基础虚拟机

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

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

更新：使用Service Fabric无法做到这一点。对于我们的服务，我们决定直接在VM Scale Set之上构建它。希望我们还将看到基于VM Scale Set构建的Cloud Service v2，它将负责部署/维护。

Answer 1

Service Fabric具有内置的机制来重新启动失败的应用程序，但是Service Fabric无法理解什么是“不良状态”。如果应用程序失败且进程关闭，SF将对其重新启动几次，直到它放弃并认为该应用程序已损坏并阻止重新启动。

如果它不时发生（例如，一周几次），则不会有任何问题，因为对于将同一问题的连续故障视为一部分的时间有一个阈值。

当您说错误状态时，每个应用程序可能具有不同的错误状态概念，因此除非应用程序通过健康事件。

示例：

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

在这些情况下，您必须实施一种机制来告知SF意外的错误，并且SF将为您处理故障转移。您可以将其实现为：

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

对于第一种方法，将其报告为已发生故障的快速方法是使用ReportFault：

  

使副本能够向运行时报告故障并指示   它遇到了一个错误，无法从中恢复，因此必须   重新启动或删除。

有关其他健康报告的更多信息，请查看以下文档：Service Fabric health reports

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

我不知道SF中有什么可以重新启动VM，可能是由于前面提到的相同原因，它会在SF Explorer中引发故障以通知该问题，因此您必须进行处理。

您可以作为上述看门狗方法的一部分，提出一个解决方案，在该解决方案中，Disable-ServiceFabricNode将从节点移动所有“健康”服务，然后可以使用Azure SDK重新启动基础VM。