【问题标题】:Warmup services on upgrade in Service FabricService Fabric 中升级时的预热服务
【发布时间】:2016-10-13 20:22:09
【问题描述】:

我们想知道作为 Service Fabric 中服务升级的一部分,是否有一种内置方式来预热服务,类似于您可以预热的各种方式,例如在请求命中之前基于 IIS 的应用程序池。理想情况下,我们希望各个服务在被视为已启动并可供其他服务联系之前执行一些预热任务,作为其初始化的一部分(可能是缓存加载、恢复等)。此预热应该是升级域处理的一部分,因此升级过程应该等待预热完成并且服务报告为 OK/Ready。

其他人如何处理此类场景,控制向服务结构发出特定服务已完全启动并准备好与其他服务联系的信号流程?

【问题讨论】:

    标签: azure-service-fabric warm-up


    【解决方案1】:

    在卫生政策中有这样的概念:

    HealthCheckWaitDurationSec 在升级域上完成升级后,Service Fabric 评估应用程序的运行状况之前等待的时间(以秒为单位)。这个持续时间也可以被认为是应用程序在被认为是健康的之前应该运行的时间。如果健康检查通过,则升级过程继续到下一个升级域。如果运行状况检查失败,Service Fabric 会等待一段时间(UpgradeHealthCheckInterval),然后再次重试运行状况检查,直到达到 HealthCheckRetryTimeout。默认和推荐值为 0 秒。

    Source

    这是一个固定的等待期。

    您还可以发出健康事件yourself。例如,您可以在热身时报告健康状况“未知”。并调整您的健康政策 (HealthCheckWaitDurationSec) 来检查这一点。

    【讨论】:

    • 感谢@LoekD 的回复。我们已经尝试过了,但无论等待时间长短,升级过程都会从初始升级域继续进行。从目前我们所读到的所有内容来看,我们似乎需要很早就发出一个未知健康事件,然后在热身完成后将其设置为 OK。
    【解决方案2】:

    报告健康状况会有所帮助。您不能报告未知,您必须尽早报告错误,然后在您的服务准备好时清除错误。警告和确定不影响升级。要清除错误,您的服务可以报告健康状态 Ok、RemoveWhenExpired=true、低 TTL(更多信息请参阅 how to report)。

    您必须根据最大预热时间增加 HealthCheckRetryTimeout。否则,如果执行了运行状况检查并且集群被评估为错误,则升级将失败(并根据您的策略回滚或暂停)。

    所以,事件的顺序是:

    • 您的服务报告错误 - “正在预热”
    • 升级等待固定的 HealthCheckWaitDurationSec(您可以将此设置为最小预热时间)
    • 升级执行健康检查:如果服务尚未预热,则健康状态为错误,因此升级重试,直到达到 HealthCheckRetryTimeout 或您的服务不再处于错误状态(预热完成并且您的服务清除了错误)。

    【讨论】:

    • 抱歉,@oana-platon 把球丢在这上面了。我刚刚对此进行了测试,并有一个可行的解决方案,该解决方案将延迟升级域的进度,直到服务进入正常状态,由自定义运行状况事件控制(请参阅github.com/enemaerke/servicefabric-upgradetests)。
    猜你喜欢
    • 2017-06-26
    • 2023-04-04
    • 2017-10-30
    • 2018-09-01
    • 2021-06-18
    • 2017-06-07
    • 2018-11-14
    • 2019-05-08
    • 2016-07-26
    相关资源
    最近更新 更多