2017-02-03 22 views
2

我们正在测试流量管理器以查看它是否是故障转移的可行解决方案。如果我们的主要Azure区域因任何原因而变得不可用,我们希望最终用户转到可以继续使用该站点的辅助位置。Azure流量管理器,优先级模式:当主节点故障时,浏览器刷新不会进入辅助节点

我已经按照文档设置了这一点,并有3个简单的API返回页面作为3个不同区域的端点,只是简单地提醒您打哪一个。我将它们划分为1,2和3的优先级。

当点击.trafficmanager.net URL时,显示的是主应用。所有3个在流量管理器配置文件中显示“在线”。如果我停止主站点,然后刷新我的浏览器,我得到一个403错误,指出该站点已停止。

我将流量管理器配置文件配置中的TTL设置为60秒。但是,15分钟以后,浏览器仍然显示403.我似乎能够获得辅助站点的唯一方法是启动一个新的浏览器会话。这就像浏览器会话存在某种缓存和/或TTL问题,阻止它尝试辅助站点。

在现场生产环境中,这显然是不可接受的。必须有解决方法,对吧?有没有人处理过这个问题?

回答

0

浏览器可能会使用Keep-Alive

请记住,Azure的流量管理器的工作原理在DNS级别的话,而不是使用浏览器来获得一个摄制,试图得到一个摄制一些DNS工具,如挖, nslookup等。

+0

感谢您的回复。这似乎是发生了什么事。但对于基于浏览器的应用程序来说,这不是一个可接受的故障转移选项。我们需要一种解决方案,让最终用户不知道问题出在哪里,而不是一个必须被指示在网站停机时启动新的浏览器会话的解决方案。也许这只是微软还没有实现的东西。希望他们很快会做出一些改进。 – JCM

+0

不知道这是否属于微软的域名,但我相信你可以在你主持你的网站的任何地方禁用Keep-Alive。例如,看看如何在ASP.NET中执行此操作:http://stackoverflow.com/questions/1975983/how-can-i-disable-http-keep-alive-in-asp-net-mvc –

0

这不仅仅是一个浏览器设置。您的IIS管理器可能会被视为使用保持活动来减少自身的压力,从而留下完全绕过流量管理器的DNS规则的开放连接。我有这些完全相同的症状,并能通过遵循我发布的步骤here缓解他们。它是否会在现实世界中被证明有用尚未被看到,但我希望这将有助于你进一步发展。