1

我在 Azure 中设置了两个 Web 应用程序。在我在生产中做任何事情之前，我现在只是用它来测试交通管理器，所以我创建了两个“假”应用程序来试用它。

我在以下 URL 的门户中添加了流量管理器：

http://mbfakesite.trafficmanager.net

我将端点 1 列为第一个 Web 应用程序，将端点 2 列为第二个，我使用的是 Priority 方法。

当我停止 Azure 中的第一个 Web 应用程序并转到流量管理器 URL 时，我收到 403 错误页面。我想要发生的是默认为第二个端点。

最终目标是让 MVC 应用程序在与生产网站不同的服务器上运行。当生产服务器关闭（备份和所有）时，它应该默认为在单独的服务器上运行这个“故障安全”应用程序，就像最坏情况下的情况一样。

如果有所不同，用于测试的两个 Web 应用程序都托管在 azurewebsites.net 和流量管理器中，一个被列为 Azure 终结点（第一个），另一个被列为外部终结点。

正如有人在我发现的另一篇文章中所建议的那样，我还尝试添加到 web.config，但它没有任何改变。

任何人有任何想法或我们可以使用的交通管理器的替代品吗？

谢谢！

4

3 回答 3

2

虽然另一个答案中给出的时间表大部分是正确的，但它忽略了流量管理器如何运作的一些基本方面。

由于流量管理器仅更改 DNS 规则，因此它仅在您的浏览器实际检查该规则时才有效。不幸的是，现代网络通信有许多捷径，其中一种被称为“保持活跃”。

在我走得更远之前，我为您的症状找到的解决方案是

  1. 远程进入您的节点
  2. 打开 IIS 管理器
  3. 打开“IIS”下的“HTTP 响应头”
  4. 点击右侧的“Set Common Headers”，取消勾选keep-alive选项

请注意，这将导致流量管理器的点击次数增加。基本上，这需要浏览器检查 DNS 规则并在每个连接上打开一个新连接。这是必需的，因为这些打开的连接可以在 TTL 持续时间和任何 DNS 缓存破坏之后继续存在。实际上，可以通过点击刷新来进一步扩展这些打开的连接。与你想要的完全相反。

我知道这个答案对您来说可能为时已晚，所以我很抱歉。但是，我认为它值得一个答案。

于 2017-08-03T21:45:18.977 回答
0

根据官方文档，它应该路由到最近的（就延迟而言）可用的 DC。

https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-routing-methods

您可以尝试此处描述的测试故障转移： https ://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-testing-settings

于 2017-03-26T19:55:53.693 回答
0

当我停止 Azure 中的第一个 Web 应用程序并转到流量管理器 URL 时，我收到 403 错误页面。我想要发生的是默认为第二个端点。

Azure 流量管理器用作 DNS 级别的负载均衡器。Azure 流量管理器包括内置的终结点监视和自动终结点故障转移，它会定期检查每个终结点的健康状况，包括不健康的终结点。这些DNS 缓存效应对所有基于 DNS 的流量路由系统都是通用的，因此 DNS 级别的负载平衡器无法立即切换到另一个可用站点。

流量管理器监控设置也会影响切换到另一个可用站点的时间。
以下时间线是对流量管理器监控过程的详细描述。

在此处输入图像描述

有关 azure traffic manager monitor 的更多信息，请参阅此链接。

于 2017-03-27T01:55:42.480 回答