【问题标题】:CloudFront - S3 origin failover and origin response timeoutCloudFront - S3 源故障转移和源响应超时
【发布时间】:2020-05-20 05:45:06
【问题描述】:

我正在尝试将 CloudFront 分配配置为对 S3 源使用源故障转移。最初它看起来是个好主意 - 当主存储桶所在的区域关闭时,所有请求都会自动路由到故障转移存储桶。然而,在 CloudFront 文档中,我发现以下与响应超时相关的描述:

GET 和 HEAD 请求 – 如果 Amazon S3 在 30 秒内未响应或停止响应 30 秒,CloudFront 将断开连接并再次尝试联系源站两次。如果源在第三次尝试期间没有回复,CloudFront 不会再次尝试,直到它收到对同一 CloudFront 源上内容的另一个请求。

对于所有请求,CloudFront 会尝试与 S3 建立连接。如果连接在 10 秒内失败,CloudFront 会断开连接并再次尝试联系 S3 两次。如果源在第三次尝试期间没有回复,CloudFront 不会再次尝试,直到它收到对同一源上的内容的另一个请求。

无法更改 S3 的响应超时。

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorS3Origin.html#RequestS3RequestTimeout

如此高的响应超时以及 CloudFront 故障转移不像 Route53 健康检查那样工作的事实,即它总是尝试将流量路由到主要来源,即使之前的请求失败,提出了一个问题 - CloudFront 故障转移真的是对于整个区域可能出现故障的罕见情况的实际解决方案?看起来在这种情况下,通过 CloudFront 托管的网站的性能无论如何都会很差。我错过了什么吗?

【问题讨论】:

    标签: amazon-web-services amazon-s3 amazon-cloudfront


    【解决方案1】:

    事实上,这个响应超时是健康检查的一部分,而不是用户加载请求。如果源不健康,CloudFront 将开始将所有用户流量引导到故障转移。

    因此,除了执行运行状况检查的 30 秒之外,用户不会出现性能问题,CloudFront 实际执行运行状况检查以了解是否应该切换

    【讨论】:

    • 这也是我最初的想法,但我在文档中找不到任何可以明确支持该假设的片段。句子'CloudFront 在连续三次尝试单个请求后无法连接到源时发出连接超时。 CloudFront 在连接尝试之间最多等待 10 秒。真的很混乱,让我相信每个请求都会重复这样的过程。
    • 你确定吗?您是否有指向有关此行为的文档的链接?
    猜你喜欢
    • 2023-03-24
    • 1970-01-01
    • 1970-01-01
    • 2011-10-27
    • 2017-07-10
    • 1970-01-01
    • 1970-01-01
    • 2010-11-06
    • 2016-05-01
    相关资源
    最近更新 更多