AWS Route53 故障转移和 chrome DNS 缓存

Posted

技术标签:

【中文标题】AWS Route53 故障转移和 chrome DNS 缓存【英文标题】:AWS Route53 failover and chrome DNS cache 【发布时间】:2018-08-15 08:00:09 【问题描述】:

我使用 Route53 进行了非常标准的故障转移:

两个地区 主要,与运行状况检查相关联,以及每个区域的辅助故障转移记录。 记录指向 API。此外,我们还有使用 API 的前端 JS 应用程序。

如果 Primary 运行状况不佳,则 DNS 会返回一条 Secondary 记录,如果用户在失败时未使用该应用程序,则该记录运行良好。

所以:

如果 Primary 运行状况不佳,并且用户在故障转移激活后尝试使用该应用 - 一切正常(指向 Secondary 记录)

如果用户在使用应用程序时主记录变得不健康,应用程序会尝试访问不可用的旧 IP 地址,因此不会切换到辅助记录。 p>

似乎 DNS 已缓存(可以在此处检查 chrome://net-internals/#dns for Chrome)。用户可以在一段时间不活动后继续使用该应用:当 API 未触发且 Chrome 的 DNS 缓存已过期时。

当用户使用应用程序时主节点变得不健康时,是否有针对这种特殊情况的解决方法?或者在这种情况下我们如何让用户体验更愉快?

添加示例:

用户 1 正在使用应用程序(应用程序是 Ember.js 应用程序) 主服务器已关闭,故障转移已激活 之后用户 2 访问应用程序(故障转移处于活动状态)并且 route53 提供了辅助记录,因此一切正常。 同时,用户 1 仍在尝试访问应用程序,应用程序向 API 发出请求。但是一个应用正在从 chrome DNS 缓存中访问旧 IP。

添加:

我们正在使用别名记录(Route53 上 A 记录的 TTL 始终为 60 秒)

【问题讨论】:

【参考方案1】:

这一切都归结为 TTL。如果您将资源上的 TTL 设置为 30 秒,则浏览器应每 30 秒解析一次地址,以便在大多数情况下可以接受。当然,这是以一些延迟和更多成本为代价的(尽管 R53 真的很便宜)。如果您需要更短的 TTL you can set it up。

如果您想对其进行更多控制,则必须设置自己的负载均衡器,当您的机器出现故障时,该负载均衡器将路由到不同的区域,但在 EC2 发生故障时不会为您节省时间(可能会为您争取足够的时间启动一个新实例)。

【讨论】:

因此,在这种情况下,故障转移将更早激活......但似乎无法通过 Chrome DNS 缓存解决此问题。向任务添加工作流(添加示例) @Igor 好吧,Chrome 的默认值为 30 秒,因此在最坏的情况下不会超过一分钟。你真的需要那种 HA 吗? so.. 应用程序在尝试访问已关闭的主记录时出错。然后用户尝试在 10 秒内再次登录,并且似乎在触发端点时旧 ip 和 DNS 记录未更新。所以我们需要 30 秒不活动(以获得正确的 IP 地址。大多数用户会没事的:) 只是想知道是否有任何好的解决方法:) 当然减少 TTL 仍然是一个不错的选择 所以我们使用 Alias 记录,似乎无法为 A 记录设置 TTL,所以我们的 TTL 是 60 秒。

以上是关于AWS Route53 故障转移和 chrome DNS 缓存的主要内容,如果未能解决你的问题,请参考以下文章

AWS Route53 DNS 故障转移设置上的临时反转主要 <=> 次要

使用 terraform 的 Route 53 故障转移策略

域转移后 AWS Route 53 上的域传播错误

AWS EC2 和 Route 53 域(从不同提供商转移)链接问题 | nslookup 无法解析任何 IP 地址

AWS HostedZone 在从一个 AWS 账户转移到另一个账户后没有做任何事情(Route53 声称没有名称服务器)[重复]

我们如何使用 Route53 将 DNS 条目添加到由外部(第三方)域提供商托管的域