Service Fabric 升级卡在 PreUpgradeSafetyCheck 上

Posted 2023-03-27

【中文标题】Service Fabric 升级卡在 PreUpgradeSafetyCheck 上

【英文标题】：Service Fabric Upgrade stuck on PreUpgradeSafetyCheck

【发布时间】：2019-05-08 05:18:49

【问题描述】：

我收到了一条警告，提示有新版本的 Service Fabric 可用，但是当我尝试升级它时，该过程卡在节点 Rep_247 上的 PreUpgradeSafetyCheck 处。我试过 -Force 和 -ForceRestart 但没有帮助。

Cluster Map

【问题讨论】：

我认为这可能意味着耗尽第一个节点会破坏您拥有的副本\服务的一些可用性目标

您能否提供有关集群的更多详细信息？哪些节点是种子节点？

【参考方案1】：

此问题很可能会发生，因为 Service Fabric 无法以安全的方式关闭服务以升级节点或应用程序。

每当升级一个节点时，该节点中激活的服务必须先移动到另一个节点，这样才能在不影响您的应用程序\服务可用性的情况下重新启动该节点。

在这种情况下，当服务无法放置在另一个节点时，这样做可能会导致仲裁丢失，可能是因为没有其他节点可用，或者是因为服务中的放置限制，或者只有一个实例服务。

由于顺丰无法保证服务的可靠性，因此会暂停升级过程，直到可以应用解决方案解决问题并继续升级。

从您的集群地图和消息中可以知道问题，您的集群只有一个类型为“Rep_247 ReportServerType”的节点，我假设您有服务由于放置约束仅部署在此节点类型上，删除节点将使这些服务不可用，因为放置约束将阻止它们移动到另一个节点类型。

如果服务不受该节点类型的限制，问题可能是：

在其他节点上激活失败，例如，节点中缺少依赖项，这将无法拥有最小副本。 该服务只有一个可用的实例，关闭将使该服务不可用。

PS：同样适用于节点MR_236 MRType

PreUpgradeSafetyCheck

PreUpgradeSafetyCheck 的 UpgradePhase 表示存在问题 在执行之前准备升级域。最普遍的 这种情况下的问题是关闭或降级时的服务错误 主要代码路径。

可能的解决方案是：

添加更多服务的副本\实例，以满足最低法定人数。 移除服务的 Placement 约束，让它们移动到其他节点。 添加一个相同节点类型的额外节点，以便服务可以安全移出。 更新节点时关闭服务并重新创建（如果没有状态，则为最后一个选项，否则会丢失数据）

您可能有兴趣查看相关问题：

Github Issue #1279 Github Issue #377

【讨论】：

所有 Orch 都是种子节点。另外，我在升级时没有遇到问题，有没有办法绕过它？将 UpgradeReplicaSetCheckTimeout 设置为 1 秒无助于绕过 PreUpgradeSafetyCheck。而且我无法添加额外的节点或移除约束。

AFAIK，唯一可能的解决方案是上面答案中列出的解决方案，SF 将验证SafetyCheck。它们有不同的行为，但都强制服务可用性。