AWS:ALB立即或在130秒后做出响应

时间:2018-12-05 17:22:45

标签: amazon-web-services load-balancing amazon-elb

我正在使用ALB,并尝试利用基于主机的路由的概念在其后放置几台主机(与目标组进行1-1映射)。

所以我有5个网址,每个网址都被转发到另一个TG(因此以我的情况为例),例如

https://path1.mydomain.com
https://path2.mydomain.com

(...等等)...

我注意到我得到了一种二进制行为,即ALB将几乎立即(即<1.sec)或大约130秒内做出响应。

$ for X in `seq 60`; do curl -Ik -w "HTTPCode=%{http_code} TotalTime=%{time_total}\n" https://path1.mydomain.com -so /dev/null; done
HTTPCode=200 TotalTime=130.157
HTTPCode=200 TotalTime=131.053
HTTPCode=200 TotalTime=131.050
HTTPCode=200 TotalTime=0.485
HTTPCode=200 TotalTime=130.533
HTTPCode=200 TotalTime=0.467
HTTPCode=200 TotalTime=130.586
HTTPCode=200 TotalTime=0.477
HTTPCode=200 TotalTime=130.567

这适用于所有路径。

您知道这种行为可能来自哪里吗?

以下是响应标头(无论延迟如何,我总是得到200

$ curl -kI  https://path1.mydomain.com
HTTP/1.1 200 OK
Date: Wed, 05 Dec 2018 17:03:14 GMT
Content-Type: text/html
Content-Length: 1617
Connection: keep-alive
Server: nginx
Last-Modified: Thu, 19 Jul 2018 09:52:09 GMT
ETag: "5b505f49-651"
Cache-Control: no-cache
Accept-Ranges: bytes

edit_1 :尽管我要为ALB注册2个子网/可用区,但重要的是我所有实例都在同一可用区/子网中;

edit_2 :直接击中公共实例的IP之一时:

$ for X in `seq 60`; do curl -Ik -w "HTTPCode=%{http_code} TotalTime=%{time_total}\n" http://18.9.48.141 -so /dev/null; done
HTTPCode=200 TotalTime=0.005
HTTPCode=200 TotalTime=0.007
HTTPCode=200 TotalTime=0.005
HTTPCode=200 TotalTime=0.007
HTTPCode=200 TotalTime=0.007
HTTPCode=200 TotalTime=0.005
HTTPCode=200 TotalTime=0.005
HTTPCode=200 TotalTime=0.005
HTTPCode=200 TotalTime=0.010
HTTPCode=200 TotalTime=0.005
HTTPCode=200 TotalTime=0.005
HTTPCode=200 TotalTime=0.008

edit_3 :它也是不是 dns解析问题,因为dig命令的100迭代将立即返回而没有错误。

edit_4 :这是strace命令的curl挂起的位置:

connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("51.53.132.130")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 199)  = 0 (Timeout)
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 0)    = 0 (Timeout)
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 1000) = 0 (Timeout)
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 1000) = 0 (Timeout)
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 1000) = 0 (Timeout)
poll([{fd=4, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 1000) = 0 (Timeout)

edit_5 tcptraceroute命令挂起的公共IP的一些curl迭代

$ for i in `seq 10`; do sudo tcptraceroute 51.53.132.130; done
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  2.109 ms  2.097 ms  2.230 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  1.964 ms  1.954 ms  1.942 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  2.148 ms  2.220 ms  2.208 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  2.227 ms  2.214 ms  2.200 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  2.181 ms  2.170 ms  2.159 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  2.157 ms  2.221 ms  2.207 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  2.228 ms  2.216 ms  2.203 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  1.810 ms  1.962 ms  1.961 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  1.695 ms  1.757 ms  1.852 ms
traceroute to 51.53.132.130 (51.53.132.130), 30 hops max, 60 byte packets
 1  * * *
 2  51.53.132.130 (51.53.132.130) <syn,ack>  2.202 ms  2.187 ms  2.173 ms

很明显,巨大的延迟是由应用程序负载平衡器引入的。

1 个答案:

答案 0 :(得分:0)

问题出在以下方面:

我已经为我的ALB分配了2个可用区,并且与其中一个对应的子网没有0.0.0.0/0 --> IG路由。