HAProxy 之前的 Varnish 似乎重用了(错误的)后端连接

HAProxy 之前的 Varnish 似乎重用了(错误的)后端连接

我们有以下设置:Nginx -> Varnish -> HAProxy -> 应用服务器 A / 应用服务器 B。

我们处理的大多数请求都由 HAProxy 代理到应用服务器 A。这是根据主机标头值完成的。一些主机应重定向到应用服务器 B。应用服务器 B 的流量非常低。

大多数请求都运行正常。偶尔,应代理到应用服务器 B 的请求会给出 404 状态代码。这些请求会显示在 Nginx、Varnish 和应用服务器 A 的日志中,但不会显示在 HAProxy 的日志中。

对运行正常的应用服务器 A 和 B 的请求均被 HAProxy 正确记录。

看来 Varnish 重用了 HAProxy 建立的与应用服务器 A 的连接,从而阻止重新评估这些请求并将其发送到正确的后端。这是我遇到问题的合理原因吗?有没有办法强制 Varnish 重新连接到后端,或者强制 HAProxy 保留在这些服务器之间?每种解决方案的优点/缺点是什么?

谢谢!

编辑:

这是我的 Varnish 日志文件的一部分:

   12 SessionClose c Connection: close
   12 StatSess     c 127.0.0.1 54331 0 1 1 0 0 1 652 0
    0 CLI          - Rd ping
    0 CLI          - Wr 200 PONG 1329319173 1.0
   12 SessionOpen  c 127.0.0.1 54334 :6081
   12 ReqStart     c 127.0.0.1 54334 1884874126
   12 RxRequest    c GET
   12 RxURL        c /path/to/page
   12 RxProtocol   c HTTP/1.0
   12 RxHeader     c Host: www.example.com
   12 RxHeader     c Connection: close
   12 RxHeader     c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7
   12 RxHeader     c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   12 RxHeader     c Referer: http://www.example.com/path/to/previous/
   12 RxHeader     c Accept-Encoding: gzip,deflate,sdch
   12 RxHeader     c Accept-Language: en-US,en;q=0.8
   12 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
   12 RxHeader     c Cookie: 71666-bl0098f964_r=0; 71666-bl0098f964_s=145818062; _advocaten-cms_session=BAh7BjoPc2Vzc2lvbl9pZCIlMmRhNGFhMWY3MDRlMzljNGRkZTQ0MTI3MjJhN2E2NzY%3D--5d089ff2c72e4ad91d415cb14020834387c2077e; 71666-bl0098f964_i=272; 71666-bl0098f964_vt=1329319215438
   12 VCL_call     c recv
   12 VCL_return   c pass
   12 VCL_call     c hash
   12 VCL_return   c hash
   12 VCL_call     c pass
   12 VCL_return   c pass
   12 Backend      c 14 default default
   14 TxRequest    b GET
   14 TxURL        b /path/to/page/
   14 TxProtocol   b HTTP/1.0
   14 TxHeader     b Host: www.example.com
   14 TxHeader     b User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7
   14 TxHeader     b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   14 TxHeader     b Referer: http://www.example.com/path/to/previous/
   14 TxHeader     b Accept-Encoding: gzip,deflate,sdch
   14 TxHeader     b Accept-Language: en-US,en;q=0.8
   14 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
   14 TxHeader     b Cookie: 71666-bl0098f964_r=0; 71666-bl0098f964_s=145818062; _advocaten-cms_session=BAh7BjoPc2Vzc2lvbl9pZCIlMmRhNGFhMWY3MDRlMzljNGRkZTQ0MTI3MjJhN2E2NzY%3D--5d089ff2c72e4ad91d415cb14020834387c2077e; 71666-bl0098f964_i=272; 71666-bl0098f964_vt=1329319215438
   14 TxHeader     b X-Forwarded-For: 127.0.0.1
   14 TxHeader     b X-Varnish: 1884874126
   14 RxProtocol   b HTTP/1.1
   14 RxStatus     b 404
   14 RxResponse   b Not Found
   14 RxHeader     b Date: Wed, 15 Feb 2012 15:20:06 GMT
   14 RxHeader     b Server: Apache
   14 RxHeader     b Vary: Accept-Encoding
   14 RxHeader     b Content-Encoding: gzip
   14 RxHeader     b Content-Length: 243
   14 RxHeader     b Connection: close
   14 RxHeader     b Content-Type: text/html; charset=iso-8859-1
   12 TTL          c 1884874126 RFC 120 1329319174 0 0 0 0
   12 VCL_call     c fetch
   12 VCL_return   c pass
   12 ObjProtocol  c HTTP/1.1
   12 ObjStatus    c 404
   12 ObjResponse  c Not Found
   12 ObjHeader    c Date: Wed, 15 Feb 2012 15:20:06 GMT
   12 ObjHeader    c Server: Apache
   12 ObjHeader    c Vary: Accept-Encoding
   12 ObjHeader    c Content-Encoding: gzip
   12 ObjHeader    c Content-Type: text/html; charset=iso-8859-1
   14 Length       b 243
   14 BackendClose b default
   12 VCL_call     c deliver
   12 VCL_return   c deliver
   12 TxProtocol   c HTTP/1.1
   12 TxStatus     c 404
   12 TxResponse   c Not Found
   12 TxHeader     c Server: Apache
   12 TxHeader     c Vary: Accept-Encoding
   12 TxHeader     c Content-Encoding: gzip
   12 TxHeader     c Content-Type: text/html; charset=iso-8859-1
   12 TxHeader     c Content-Length: 243
   12 TxHeader     c Date: Wed, 15 Feb 2012 15:19:34 GMT
   12 TxHeader     c X-Varnish: 1884874126
   12 TxHeader     c Age: 0
   12 TxHeader     c Via: 1.1 varnish
   12 TxHeader     c Connection: close
   12 Length       c 243
   12 ReqEnd       c 1884874126 1329319174.638826609 1329319174.639825106 0.000061750 0.000943899 0.000054598
   12 SessionClose c Connection: close
   12 StatSess     c 127.0.0.1 54334 0 1 1 0 1 1 260 243
    0 CLI          - Rd ping
    0 CLI          - Wr 200 PONG 1329319176 1.0

HAProxy 是默认后端。

这是否也与 HAProxy 不记录同一会话的后续请求有关?我假设由于 HAProxy 没有记录它们,它们没有通过它,但根据文档,这是预期的行为。由于 Varnish 是 HAProxy 的客户端,因此多个请求(来自多个访问者)可以属于同一会话?

编辑2:看来如果我添加

option forceclose
option http-pretend-keepalive

在我的 HAProxy 配置中,问题消失或变得不那么频繁了。这感觉像是针对 Varnish / HAProxy 交互的更深层次问题的一种解决方法。Varnish 收到一个Connection: Close标头,但未在对后端的请求中指定该标头。强制关闭连接可确保 HAProxy 评估来自 Varnish 的每个请求。

相关内容