通过EC2负载均衡器的请求挂起

时间:2014-04-30 12:10:03

标签: amazon-ec2 proxy load-balancing

我使用Tinyproxy在EC2实例上设置了一个简单的代理(默认配置侦听/允许所有传入连接)。这很好用。如果我,为了调试,在我的浏览器中填写IP地址和代理设置的端口,我可以通过代理浏览,没有任何问题。一切正常。但是,如果我在实例前面创建一个EC2负载均衡器(确保正确转发http端口),那么当我浏览负载均衡器IP时它就会挂起。这对我来说似乎是个谜。实例正在运行,负载均衡器报告“在服务中”,并且绕负载均衡器工作,但通过它只是挂起。我错过了什么,我应该在哪里寻找错误?

更新

我现在看看Tinyproxy的日志:当试图通过实例代理直接访问google.com时,我看到这样的日志:

CONNECT   Apr 30 20:41:33 [1862]: Request (file descriptor 6): GET http://google.com/ HTTP/1.1
INFO      Apr 30 20:41:33 [1862]: No upstream proxy for google.com
CONNECT   Apr 30 20:41:33 [1862]: Established connection to host "google.com" using file descriptor 7.
INFO      Apr 30 20:41:33 [1862]: Closed connection between local client (fd:6) and remote client (fd:7)
CONNECT   Apr 30 20:41:33 [1901]: Connect (file descriptor 6): x1-6-84-1b-ADDJF-20-07-92.fsdfe [430.12327.65117.615]
CONNECT   Apr 30 20:41:33 [1901]: Request (file descriptor 6): GET http://www.google.ie/?gws_rd=cr&ei=_V9hU8DeFMTpPJjygIgC HTTP/1.1
INFO      Apr 30 20:41:33 [1901]: No upstream proxy for www.google.ie
CONNECT   Apr 30 20:41:33 [1901]: Established connection to host "www.google.ie" using file descriptor 7.

但是,如果我尝试通过负载均衡器访问谷歌,然后转发到实例,那么我会看到这样的日志:

CONNECT   Apr 30 20:42:54 [1860]: Request (file descriptor 6): GET / HTTP/1.1
CONNECT   Apr 30 20:42:54 [1869]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [10.238.155.237]
CONNECT   Apr 30 20:42:54 [2037]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [10.238.155.237]
INFO      Apr 30 20:42:54 [1860]: process_request: trans Host GET http://google.com:8888/ for 6
INFO      Apr 30 20:42:54 [1860]: No upstream proxy for google.com
CONNECT   Apr 30 20:43:12 [1861]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [1230.23845.515.2537]
CONNECT   Apr 30 20:43:12 [2035]: Connect (file descriptor 6): ip-432-2383245-53.eu-west-1.compute.internal [143.238.12345.117]
ERROR     Apr 30 20:43:12 [2035]: read_request_line: Client (file descriptor: 6) closed socket before read.
ERROR     Apr 30 20:43:12 [1861]: read_request_line: Client (file descriptor: 6) closed socket before read.
ERROR     Apr 30 20:43:12 [2035]: Error reading readble client_fd 6
ERROR     Apr 30 20:43:12 [1861]: Error reading readble client_fd 6
WARNING   Apr 30 20:43:12 [2035]: Could not retrieve request entity
WARNING   Apr 30 20:43:12 [1861]: Could not retrieve request entity

根据我的注意,ELB正试图通过端口8888发送请求

2 个答案:

答案 0 :(得分:1)

您可以获取ELB访问日志。这些访问日志可以帮助您确定不同时间间隔的请求所用的时间。 e.g:

  1. request_processing_time:从负载均衡器收到请求并将请求发送到已注册的实例之后经过的总时间(以秒为单位)。
  2. backend_processing_time:从负载均衡器将请求发送到已注册实例并且实例开始发送响应标头之后经过的总时间(以秒为单位)。
  3. response_processing_time :从负载均衡器收到来自已注册实例的响应头并开始向客户端发送响应之后经过的总时间(以秒为单位)。此处理时间包括负载均衡器的排队时间和从负载均衡器到后端的连接获取时间。
  4. ......以及更多信息。您需要先配置访问日志。请按照以下文章了解有关使用ELB访问日志的更多信息:

    1. Access Logs for Elastic Load Balancers
    2. Access Logs
    3. 这些日志可能/可能无法解决您的问题,但肯定是一个很好的开始。此外,您可以随时咨询AWS技术支持部门,以获得更深入的分析。

答案 1 :(得分:1)

听起来你正试图在HTTP模式下使用ELB,实质上是类似于转发代理的东西,或者至少是你正在其后面运行的转发代理的网关。这不是ELB的预期应用程序,因此它在该配置中不起作用也就不足为奇了。

HTTP侦听器模式下的ELB旨在用作Web端点/源服务器前面的反向代理。

配置ELB侦听器以使用TCP模式而不是HTTP模式应该允许您的预期配置工作,但这有点超出了ELB的最佳应用程序。

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html

相关问题