AWS Route53 故障转移和 chrome DNS 缓存

Posted 2023-03-04

【中文标题】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 秒。