Freigeben über


禁用 Windows Azure 网站中的 ARR 实例关联

编辑人员注释: 本博客文章由 Windows Azure 网站团队的项目经理 Erez Benari 撰写。

在 Windows Azure 网站中设置网站的多个实例是横向扩展网站的绝佳方式,Azure 最大程度地利用应用程序请求路由 IIS 扩展包以在活动实例之间分配连接到您的网站的用户。ARR 通过向连接的用户提供一个特殊的 Cookie(即关联 Cookie),因此可以在用户发出后续请求时知晓其在与哪个服务器实例通信,从而巧妙地对连接用户进行跟踪。这样我们即可确保客户端与特定服务器实例建立会话后,在会话处于活动状态时,客户端始终与同一台服务器进行通信。这对使用会话的应用程序(也称为无状态应用程序)尤为重要,因为特定于会话的数据自身不会从一台服务器移动到另一台服务器。应用程序可以设计用于执行此操作(通常通过将数据存储在某种共享存储中,如 SQL),但大多数应用程序并未这样做,因此通常我们要使每个用户连接到指定的服务器。如果用户移动到另一台服务器,将开始新的会话,并且无论应用程序使用何种会话数据,数据都将丢失(例如,购物车内容)。下面是此过程的简短描述:

1. 客户端连接到 Azure 网站

2. ARR 在前端 Azure 服务器上运行并接收请求

3. ARR 决定应将请求发送到哪个可用实例

4. ARR 将请求转发给所选服务器,创建 ARRAffinity Cookie 并将其附加到请求

5. 包含 ARRAffinity Cookie 的响应返回到客户端

6. 客户端接收响应时,将存储 Cookie 以供稍后使用(浏览器将为从服务器接收的 Cookie 执行此操作)

7. 当客户端提交后续请求时,将包括此 Cookie

8. 当 ARR 接收请求时,将查找 Cookie 并对其进行解码

9. 已解码的 Cookie 保存了之前使用的实例名称,以便 ARR 将请求转发到相同的实例,而非从池中进行选择

10. 在用户关闭浏览器之前(即清除 Cookie 时),将对相同站点的每个后续请求重复相同的步骤(步骤 7 - 9)

但是,也存在无需保留关联的情况。例如,某些用户未关闭其浏览器,并长时间地保持连接状态。这种情况下,关联 Cookie 将保留在浏览器中,使用户保持与服务器的连接,这可能持续几小时、几天甚至更长时间(理论上是无期限的!)。将电脑开着,浏览器也开着,这早已司空见惯,很多人都是这样(特别是工作区的计算机)。实际上,这将导致每个实例的用户分配失去平衡(这和超市中某些收银台被一个用户占用,而导致其他用户的等待时间变长的道理是一样的)。

根据应用程序及其功能,您可以有选择性地关注将用户连接到固定的服务器。如果这不是很重要或完全不重要,您可以禁用此关联以选择更好的负载平衡,我们已引入了此功能,以便您进行控制。

关联受关联 Cookie 控制,因此您仅需确保 Azure 未分发 Cookie 即可禁用关联。禁用后,用户发出的后续请求将视为“新请求”,ARR 将使用普通的负载平衡行为将请求路由到最佳服务器,而非尝试将其路由到“自己的”服务器。

关联 Cookie 如下所示:

可以通过以下两种方式禁用关联:

1. 在应用程序中

2. 在站点配置中

要在应用程序中控制此行为,您需要编写代码来发出一个特殊的 HTTP 头以指示应用程序请求路由器删除关联 Cookie。此头为 Arr-Disable-Session-Affinity,如果您将其设置为 true,ARR 将剔除 Cookie。例如,您可以将与此头类似的行添加到您的应用程序代码中:

headers.Add("Arr-Disable-Session-Affinity", "True");

* 此示例针对 C#,但使用任何其他语言或平台也可以轻松实现。

如果您想在大多数情况下保持关联并且仅在特定的应用程序页面重置关联,则在应用程序的代码中设置此头将非常适合。但是,如果您想要完全禁用关联,您可以始终通过将 IIS 自身直接插入该头使 ARR 删除 Cookie。这可以通过 web.config 中的 customHeaders 配置部分实现。只需将以下内容添加到 web.config,并将 web.config 上传到站点的根目录即可:

但是请记住,web.config 中的配置非常敏感,如果文件格式错误,可能会导致站点无法正常运行。如果您之前没有使用过 web.config 文件,请阅读此入门指南

故障排除

如果您打算实施这一方案,您可能想知道如何确认它的运行情况并进行故障排除。ARR 关联 Cookie 正常情况下包含在任何 Azure 网站的第 1 个响应中,随后包含在客户端发送的任何请求以及从服务器接收的响应中。要查看其是否在运行,您可以使用多种 HTTP 故障排除和诊断工具中的任意一种。下面列出了一些较为常用的选项:

1. Fiddler

2. HTTPWatc

3. Network Monitor

4. WireShark

5. Firebug

您可以在此处查找关于其他一些工具的信息。上面列出的第 1 个工具 Fiddler 是最常用的工具之一,因为它可以与任何浏览器交互,并且是免费提供的。安装 Fiddler 后,它将记录您浏览到的任何 URL,然后您可以单击请求或响应的 Inspector 选项卡来查看详细信息。例如,您可以在下面查看 HTTP Headers 选项卡,其中显示了服务器使用 Set-Cookie 头发送的关联 Cookie:

如果您添加 Arr-Disable-Session-Affinity 头来禁用关联 Cookie,ARR 将不设置 Cookie,但它也会自行删除 Arr-Disable-Session-Affinity 头,因此如果您的进程正常运行,您将看不到 Cookie 和头。如果您看到 Cookie 和头,则意味着您设置头的方式有误。可能是头名称或头值的文本出错了。如果您只看到 Cookie 而并未看到头,这可能意味着您对 web.config 的更改无效,或您的头插入代码没有运行,您可以尝试通过添加其他的无关头来进行确认。一般来说,使用 web.config 设置头要比使用代码进行设置更加容易,因此,如有疑问,应该先简化设置以缩小要调查的范围。

最后,应该指出的是,禁用关联时不应掉以轻心。静态内容很少会出现问题,但是如果您正在运行应用程序,并且这些应用程序不是专门用来处理从一台服务器跳到另一台服务器的用户的,程序可能会失败。对于关联导致失衡的情况,这一新功能无疑是个大好消息。

本文翻译自:

https://blogs.msdn.com/b/windowsazure/archive/2013/11/18/disabling-arr-s-instance-affinity-in-windows-azure-web-sites.aspx