Service Fabric - 如何修复失败的有状态应用程序

Posted 2023-03-27

【中文标题】Service Fabric - 如何修复失败的有状态应用程序

【英文标题】：Service Fabric - How to repair a failing stateful application

【发布时间】：2021-04-10 18:21:14

【问题描述】：

我有一个有状态服务，它使用 Azure 存储帐户为 RunAsync 上的主副本配置状态备份。

前几天有人无意中删除了用于备份的存储帐户。在我们的下一次部署中，由于这个 404 错误响应，服务在初始化时开始抛出错误。

我注意到，在部署过程中，fabric 显然会围绕旧版本的服务进行洗牌，根据需要启动新的主节点以释放它正在升级的虚拟机。如果旧版本的代码通过抛出异常未能实例化，升级过程将失败导致回滚。

我的问题是，一旦我创建了一个新的存储帐户，我似乎仍然无法将现有服务恢复到健康状态。我现有的服务正在使用 Azure 中不再存在的带有 AccountKeys 的存储帐户 URL。升级尝试失败，因为旧服务实例由于现在配置错误而无法实例化。

有没有办法处理这种情况？

【参考方案1】：

最简单的方法是使用unmonitored manual 升级来强制执行将服务指向新存储帐户的更改。

但是，这会给您带来很多管理开销，尤其是在有许多其他服务的情况下，因为您需要小心手动执行所有安全和功能检查，以免出现任何倒退。

推荐的解决方案是使用here 描述的 ServiceTypeHealthPolicyMap 来“屏蔽”不健康的服务（因为您希望它在升级期间不健康）。您可能还需要根据具体情况调整其他一些升级参数。

第三个建议，或者将来可能要改进的一些建议是进行升级以更改帐户信息，仅升级配置。这将确保 SF 尝试在不重新启动服务的情况下就地更改配置（默认情况下），这将防止现有服务在升级期间发生故障转移并遇到问题。这在this example 中得到了演示。

【讨论】：

如果我在已经处于故障循环中的服务上尝试仅配置升级会发生什么？他们会得到新的配置吗？

是的，但整体升级与任何其他升级相同 - 对健康和安全检查进行了门控。因此，无论哪种方式，您都需要修改健康策略映射。我提到它是因为您说错误是在故障转移时引入的，这是避免故障转移的一种方法（将来）。

好的，谢谢，健康政策地图看起来很有希望，我只是无法决定多久使用一次。一方面，将其作为 CI 管道结构升级脚本的一部分会很好，通常这将确保升级成功。但是当实际上存在真正的问题时，我对掩盖错误持谨慎态度，因此可能会保留该选项仅用于手动干预。