Azure 流量管理器对于故障转移是否可靠？我应该担心的其他问题是什么？
Is Azure Traffic manager is reliable for failover? what are other problems I should be worried about?
我计划使用 Azure 流量管理器将我的应用程序 运行 从一个 Azure 区域故障转移到 Azure 区域。
我需要一些建议，如果这是进行故障转移的正确方法？我们已经看到 Azure 的问题，一个区域中的大多数服务都会中断几个小时。虽然我知道 Azure 流量管理器与该区域没有关联。但是，尽管我的后端 Web 应用程序可以访问，但 Azure 流量管理器是否可能出现故障或流量管理器端点无法访问？
如果我打算使用 Azure 流量管理器，我还应该担心哪些其他问题？
流量管理器在 DNS 级别工作，它本身是复制的。然而，即便如此，您仍应在解决方案中构建冗余。
看看 "Make all things redundant" 下的 Azure 架构中心，你会看到 recommendation for Traffic Manager:
consider adding another traffic management solution as a failback. If
the Azure Traffic Manager service fails, change your CNAME records in
DNS to point to the other traffic management service.
我使用 TM 已经有一段时间了，所以这里有一些我以前没有提到过的问题：
如果您的服务允许 Keep-Alive，那么只要连接保持打开状态，您的 DNS 条目就会被忽略。我已经看到由此导致的一些异常奇怪的行为，包括用户因为继续使用连接而被困在后备页面上，导致它无限期地保持打开状态。如果您有权访问 IIS 管理器，you can force Keep-Alive to be false.
- 浏览器 DNS 缓存
大部分浏览器都有自己的DNS缓存，很少有honorDNS Time To Live. In my experience Chrome is pretty responsive, with IE and Edge having significant delays if you need them to rollover quickly. I've heard that Opera特别差
- 其他 DNS 缓存
即使您不通过浏览器访问您的服务，其他组件也可以有 DNS 缓存，并且其中一些 允许您自己管理缓存。这在理论上甚至可以依赖于 ISP 的 DNS 缓存，尽管关于这种程度的报告差异很大。
Traffic Manager 内部架构可以应对任何单个 Azure 区域的故障。因此，即使某个区域发生故障，流量管理器也应该保持运行。这适用于所有流量管理器组件：控制平面、端点监控和 DNS 名称服务器。
由于流量管理器在 DNS 级别工作，因此它没有 'endpoint' 来代理您的流量——它使用 DNS 将客户端定向到适当的端点，然后客户端直接连接到这些端点.因此，无法访问的终结点是应用程序问题，而不是流量管理器问题。
就是说，如果流量管理器 DNS 名称服务器出现故障，则问题很严重。您的 DNS 解析路径将失败，您的客户将受到影响。唯一的解决方案是要么接受风险（很小，但永远不会为零），要么制定计划使用另一个 DNS 系统，并行或故障转移。这不是流量管理器的限制；您可以对任何基于 DNS 的流量管理系统说同样的话。
DornaDigital 的较早回答非常好（除了第一点建议 DNS 缓存将在名称服务器中断时保护您——它不会）。它涵盖了一些要点。简而言之，基于 DNS 的故障转移适用于新会话。现有客户端可能需要刷新甚至关闭浏览器并重新连接。
我也同意 dornadigital 提供的详细信息。
还有前端应用的注意事项。浏览器对于保持持久连接的时间长短都有不同的阈值。例如，Chromium 目前会保持连接，除非有 300 秒没有活动。
在我们的 Web 应用程序中，我们通过对端点的一定数量的失败请求的存在来检测故障转移。请求开始失败后，我们暂停请求 301 秒以允许连接重置。这允许将来自流量管理器的 DNS 更改应用于后续请求。我们弹出一个 snackbar 来向用户表明我们遇到了问题，并在请求恢复时显示倒计时。与 Gmail 类似，当它连接到他们的服务器时出现问题。
我希望这能让您了解如何在您的 Web 应用程序中构建一些冗余。
我不同意 Jonathan 的观点，因为他对流量管理器服务的弹性的理解与 Microsoft 自己关于该主题的文档不一致。
当您配置 Azure 流量管理器时，您 select 一个要在其中部署服务的区域。我（正确地）推断这是为了断言如果所述区域发生故障，流量管理器服务也可能受到影响，反过来，您的应用程序解决方案将无法正确地故障转移到次要区域。
根据 Microsoft 的 Azure 应用程序架构指南，在 "Make all things redundant" 下，客户应将流量管理器部署到多个区域：
Include redundancy for Traffic Manager. Traffic Manager is a possible failure point. Review the Traffic Manager SLA, and determine whether using Traffic Manager alone meets your business requirements for high availability. If not, consider adding another traffic management solution as a failback. If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service.
Azure Application Architecture Guide - Make all things redundant
我的想法和意图是不在主要服务区域内部署流量管理器，而是将其部署到辅助（故障转移区域）和三级（第三）区域作为备份。
我计划使用 Azure 流量管理器将我的应用程序 运行 从一个 Azure 区域故障转移到 Azure 区域。 我需要一些建议，如果这是进行故障转移的正确方法？我们已经看到 Azure 的问题，一个区域中的大多数服务都会中断几个小时。虽然我知道 Azure 流量管理器与该区域没有关联。但是，尽管我的后端 Web 应用程序可以访问，但 Azure 流量管理器是否可能出现故障或流量管理器端点无法访问？
如果我打算使用 Azure 流量管理器，我还应该担心哪些其他问题？
流量管理器在 DNS 级别工作，它本身是复制的。然而，即便如此，您仍应在解决方案中构建冗余。
看看 "Make all things redundant" 下的 Azure 架构中心，你会看到 recommendation for Traffic Manager:
consider adding another traffic management solution as a failback. If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service.
我使用 TM 已经有一段时间了，所以这里有一些我以前没有提到过的问题：
如果您的服务允许 Keep-Alive，那么只要连接保持打开状态，您的 DNS 条目就会被忽略。我已经看到由此导致的一些异常奇怪的行为，包括用户因为继续使用连接而被困在后备页面上，导致它无限期地保持打开状态。如果您有权访问 IIS 管理器，you can force Keep-Alive to be false.
- 浏览器 DNS 缓存
大部分浏览器都有自己的DNS缓存，很少有honorDNS Time To Live. In my experience Chrome is pretty responsive, with IE and Edge having significant delays if you need them to rollover quickly. I've heard that Opera特别差
- 其他 DNS 缓存
即使您不通过浏览器访问您的服务，其他组件也可以有 DNS 缓存，并且其中一些 允许您自己管理缓存。这在理论上甚至可以依赖于 ISP 的 DNS 缓存，尽管关于这种程度的报告差异很大。
Traffic Manager 内部架构可以应对任何单个 Azure 区域的故障。因此，即使某个区域发生故障，流量管理器也应该保持运行。这适用于所有流量管理器组件：控制平面、端点监控和 DNS 名称服务器。
由于流量管理器在 DNS 级别工作，因此它没有 'endpoint' 来代理您的流量——它使用 DNS 将客户端定向到适当的端点，然后客户端直接连接到这些端点.因此，无法访问的终结点是应用程序问题，而不是流量管理器问题。
就是说，如果流量管理器 DNS 名称服务器出现故障，则问题很严重。您的 DNS 解析路径将失败，您的客户将受到影响。唯一的解决方案是要么接受风险（很小，但永远不会为零），要么制定计划使用另一个 DNS 系统，并行或故障转移。这不是流量管理器的限制；您可以对任何基于 DNS 的流量管理系统说同样的话。
DornaDigital 的较早回答非常好（除了第一点建议 DNS 缓存将在名称服务器中断时保护您——它不会）。它涵盖了一些要点。简而言之，基于 DNS 的故障转移适用于新会话。现有客户端可能需要刷新甚至关闭浏览器并重新连接。
我也同意 dornadigital 提供的详细信息。
还有前端应用的注意事项。浏览器对于保持持久连接的时间长短都有不同的阈值。例如，Chromium 目前会保持连接，除非有 300 秒没有活动。
在我们的 Web 应用程序中，我们通过对端点的一定数量的失败请求的存在来检测故障转移。请求开始失败后，我们暂停请求 301 秒以允许连接重置。这允许将来自流量管理器的 DNS 更改应用于后续请求。我们弹出一个 snackbar 来向用户表明我们遇到了问题，并在请求恢复时显示倒计时。与 Gmail 类似，当它连接到他们的服务器时出现问题。
我希望这能让您了解如何在您的 Web 应用程序中构建一些冗余。
我不同意 Jonathan 的观点，因为他对流量管理器服务的弹性的理解与 Microsoft 自己关于该主题的文档不一致。
当您配置 Azure 流量管理器时，您 select 一个要在其中部署服务的区域。我（正确地）推断这是为了断言如果所述区域发生故障，流量管理器服务也可能受到影响，反过来，您的应用程序解决方案将无法正确地故障转移到次要区域。
根据 Microsoft 的 Azure 应用程序架构指南，在 "Make all things redundant" 下，客户应将流量管理器部署到多个区域：
Include redundancy for Traffic Manager. Traffic Manager is a possible failure point. Review the Traffic Manager SLA, and determine whether using Traffic Manager alone meets your business requirements for high availability. If not, consider adding another traffic management solution as a failback. If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service.
Azure Application Architecture Guide - Make all things redundant
我的想法和意图是不在主要服务区域内部署流量管理器，而是将其部署到辅助（故障转移区域）和三级（第三）区域作为备份。