使用 Azure 流量管理器实现高可用性答案

【问题标题】：Achieving High Availability using Azure Traffic Manager使用 Azure 流量管理器实现高可用性
【发布时间】：2017-02-24 13:38:39
【问题描述】：

我们使用默认设置的 Azure 流量管理器部署了我们的高可用性解决方案。

我们选择的路由方法是性能。

我们预计，一旦主服务器关闭，用户就会转移到辅助服务器。但不幸的是，有 30 秒的延迟。在我们测试的这 30 秒内，我们发现用户出现未响应问题和请求超时。几乎需要一分钟才能恢复工作中的所有内容。 Azure Traffic Manager with 30 second TTL 通常，我们不会在 Facebook 或 Microsoft 站点中观察到这些丢失，这些站点肯定维护了高可用性解决方案。

我们是否需要在我们的应用程序中编写代码以优雅地处理这些丢失，例如在客户端显示一个我们很快就会回来的对话框等？什么是最好的解决方案，让用户体验无缝。

【问题讨论】：

您是否正在运行您的 Web 应用程序的多个实例？如果是这样，流量管理器故障转移解决方案是否只是为了在 Azure 数据中心完全中断时保护您？
对于故障转移，您要配置优先级算法，而不是性能。此外，您是否有多个 Web 应用实例，或者您是否有多个 Web 应用托管您的网站？

标签： azure azure-traffic-manager

【解决方案1】：

由于 Azure 流量管理器是基于 DNS 的负载均衡器，因此客户端必须等待 DNS 条目上的 TTL 通过后才能重新查询 DNS。这就是为什么你有你的问题。流量管理器本身并不管理通信，只管理您的客户端将通过 DNS 与哪个服务器通信

Facebook 和 Microsoft 在更深层次的协议中使用负载均衡器（例如在 IP 地址上进行均衡），因此一旦一个节点退出，负载均衡器就可以切换到另一个节点，因为它正在接收和重定向所有流量。

如果您可以切换到可以解决您的问题的 Azure 负载均衡器（不确定名称）。否则，您必须缩短 TTL 或编写代码来刷新 dns 缓存并重试。

【讨论】：

【解决方案2】：

Azure 负载均衡器或应用程序网关的问题在于它们不能跨数据中心工作，而只能跨数据中心工作，因此 Web 应用程序必须自行管理错误，然后在一段时间后刷新（以确保 TTL 是expired) 重定向到新服务器。 https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview

【讨论】：