ELB 生成 504 GATEWAY_TIMEOUTS w/ 2 EC2 实例 - 数据包未到达服务器
ELB generating 504 GATEWAY_TIMEOUTS w/ 2 EC2 instances - Packets not reaching Servers
我有一个面向互联网的 ELB 并连接到 2 个为网页提供服务的 EC2 实例。已使用 AWS Opsworks 部署基础设施。
配置如下：
面向 ELB 的互联网：
- 存在于两个可用性区域
- 启用跨区域负载平衡
- 空闲超时：60 段
- 粘性：LBCookieStickinessPolicy，expirationPeriod='0'
为网页提供服务的 EC2 实例 (demo1.virtualtoptraining.com)
- 两者的配置完全相同
- 运行 Apache 2 和 PHP5 作为模块
DNS 配置：
demo1.virtualtoptraining.com --> CNAME 到负载均衡器的 DNS 名称
当我使用 JMETER 运行 再次测试 demo1.virtualtoptraining.com 时，我看到大约 20% 的请求出错。报错是504GATEWAY_TIMEOUT。这些错误不取决于负载条件，因为我可以在网络浏览器上与单个用户一起导航时遇到此错误。错误是 100% 可重现的。
尝试了以下方法：
我一直在玩 apache 定时器，虽然这可能与 Web 服务器没有及时响应负载平衡器有关，但我没有得到任何改进。
我一直在使用同一可用区的服务器。错误仍然存在。
经过一些调查，我得出的结论是，我获得 504 GATEWAY_TIMEOUT 的请求到达了负载均衡器，但它们从未转发到 Web 服务器，因为我在任何Web 服务器访问日志。
我在下面展示了所有日志问题的示例。我得到这个例子只是在我的浏览器上导航到网页：
示例序列
- 退出网页（转发到首页）
- 获得首页
- 获取登录页面
- Post 登录凭据
- 凭据验证后跟随重定向
- 获取主页。错误 --> 在任何服务器访问日志中都看不到此 GET 操作
我现在列出访问日志和 ELB 日志，我用 ***(message #)
突出显示消息
服务器 1 访问日志：
ubuntu@php-app1:/var/log/apache2$ tail -f moodle281-access.log
172.31.40.186 - - [09/Jun/2015:22:44:52 +0000] "POST /login/index.php HTTP/1.1" 303 1018 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:53 +0000] "GET / HTTP/1.1" 200 39933 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:54 +0000] "GET /course/view.php?id=2 HTTP/1.1" 200 55453 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:55 +0000] "GET /course/view.php?id=2 HTTP/1.1" 200 55453 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:55 +0000] "GET /mod/forum/discuss.php?d=1 HTTP/1.1" 200 47600 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:56 +0000] "POST /mod/forum/post.php HTTP/1.1" 404 26456 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:56 +0000] "GET /user/index.php?id=2 HTTP/1.1" 200 82175 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
****(1) 172.31.19.167 - - [09/Jun/2015:22:48:52 +0000] "GET /login/logout.php?sesskey=fXjerOYZEo HTTP/1.1" 303 862 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
****(4) 172.31.19.167 - - [09/Jun/2015:22:48:55 +0000] "GET /login/index.php HTTP/1.1" 200 6088 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
****(5) 172.31.19.167 - - [09/Jun/2015:22:49:00 +0000] "GET /login/index.php?testsession=2 HTTP/1.1" 303 800 "http://demo1.virtualtoptraining.com/login/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
服务器 2 访问日志：
....
**** (2) 172.31.19.167 - - [09/Jun/2015:22:48:52 +0000] "GET / HTTP/1.1" 200 7078 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
**** (3) 172.31.19.167 - - [09/Jun/2015:22:49:00 +0000] "POST /login/index.php HTTP/1.1" 303 1010 "http://demo1.virtualtoptraining.com/login/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
....
负载均衡器访问日志：
015-06-09T22:48:52.128826Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.000092 0.204629 0.000058 303 303 0 434 "GET http://demo1.virtualtoptraining.com:80/login/logout.php?sesskey=fXjerOYZEo HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:48:52.382853Z itoptest2 151.182.141.178:52554 172.31.34.25:80 0.000082 0.456022 0.00007 200 200 0 6500 "GET http://demo1.virtualtoptraining.com:80/ HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:48:55.853509Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.000105 0.292976 0.000046 200 200 0 5617 "GET http://demo1.virtualtoptraining.com:80/login/index.php HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:00.382245Z itoptest2 151.182.141.178:52554 172.31.34.25:80 0.000105 0.545512 0.000068 303 303 36 463 "POST http://demo1.virtualtoptraining.com:80/login/index.php HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:00.980174Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.00007 0.219837 0.000044 303 303 0 434 "GET http://demo1.virtualtoptraining.com:80/login/index.php?testsession=2 HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:01.248300Z itoptest2 151.182.141.178:52554 - -1 -1 -1 504 0 0 0 "GET http://demo1.virtualtoptraining.com:80/ HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
如您所见，生成 504 GATEWAY_TIMEOUT 的请求从未出现在任何 Web 服务器访问日志中。
知道问题出在哪里吗？
您是否可能在负载测试场景中没有给 ELB 足够的启动期？确保在 CloudWatch 上监控 ELB Surge 队列。被丢弃的激增请求 return 5xx 错误 (More on CloudWatch ELB Metrics here).
此外，在针对 Amazon EC2 ELB 进行测试时，配置 JMeter 的 stalecheck 很重要。这是因为亚马逊会将您的 ELB 热交换为更大的 ELB，而不是主动扩展您正在使用的 ELB。这意味着底层寻址发生了变化，因此 JMeter 必须检查过时的连接。可能是 JMeter 正在向旧的 ELB 发送请求，然后又出现网关超时，因为它无法再发送到您的应用服务器。
查看来自 AWS 的深度 ELB 测试指南：
AWS Best Practices for Load Testing ELB
此外，这是 JMeter 的 stalecheck 属性 所在的位置。
../bin/hc.参数：
# Default value since JMeter 2.11,
# also uncomment hc.parameters.file=hc.parameters to enable this check:
#http.connection.stalecheck$Boolean=false
您还需要编辑 jmeter.properties 文件，使其实际使用 hc.parameters 设置，如上面的评论所述。
您是否添加并启用了 DNS Cache Manager？如果不是，我建议您尝试一下，它应该可以解决您的问题。
我们对该主题做了进一步调查：
请求到达服务器（通过 运行 tcpdump 找到）但 Apache 未回答
Apache 错误日志显示 "not answered requests" Apache 因核心转储而崩溃。在日志中看到以下错误：
AH00051：子 pid 11419 退出信号总线错误 (7)
核心转储分析显示如下：
警告：无法加载 4 个库的共享库符号，例如/usr/lib/php5/20121212/sasl.所以。
使用 "info sharedlibrary" 命令查看完整列表。
您需要 "set solib-search-path" 还是 "set sysroot"？
[使用 libthread_db 启用线程调试]
使用主机 libthread_db 库“/lib/x86_64-linux-gnu/libthread_db.so.1”。
核心由“/usr/sbin/apache2 -k start”生成。
程序因信号 SIGBUS、总线错误而终止。
0 lex_scan (zendlval=) 在 Zend/zend_language_scanner.c:1091
1091 Zend/zend_language_scanner.c: 没有那个文件或目录。
(gdb)
分析完所有这些信息后，我们得出结论，问题与 PHP 错误有关，因为 并发访问文件 来自应用程序的两个不同实例。因此，此访问未正确协调，导致崩溃。
我有一个面向互联网的 ELB 并连接到 2 个为网页提供服务的 EC2 实例。已使用 AWS Opsworks 部署基础设施。
配置如下：
面向 ELB 的互联网：
- 存在于两个可用性区域
- 启用跨区域负载平衡
- 空闲超时：60 段
- 粘性：LBCookieStickinessPolicy，expirationPeriod='0'
为网页提供服务的 EC2 实例 (demo1.virtualtoptraining.com)
- 两者的配置完全相同
- 运行 Apache 2 和 PHP5 作为模块
DNS 配置：
demo1.virtualtoptraining.com --> CNAME 到负载均衡器的 DNS 名称
当我使用 JMETER 运行 再次测试 demo1.virtualtoptraining.com 时，我看到大约 20% 的请求出错。报错是504GATEWAY_TIMEOUT。这些错误不取决于负载条件，因为我可以在网络浏览器上与单个用户一起导航时遇到此错误。错误是 100% 可重现的。
尝试了以下方法：
我一直在玩 apache 定时器，虽然这可能与 Web 服务器没有及时响应负载平衡器有关，但我没有得到任何改进。
我一直在使用同一可用区的服务器。错误仍然存在。
经过一些调查，我得出的结论是，我获得 504 GATEWAY_TIMEOUT 的请求到达了负载均衡器，但它们从未转发到 Web 服务器，因为我在任何Web 服务器访问日志。
我在下面展示了所有日志问题的示例。我得到这个例子只是在我的浏览器上导航到网页：
示例序列
- 退出网页（转发到首页）
- 获得首页
- 获取登录页面
- Post 登录凭据
- 凭据验证后跟随重定向
- 获取主页。错误 --> 在任何服务器访问日志中都看不到此 GET 操作
我现在列出访问日志和 ELB 日志，我用 ***(message #)
突出显示消息服务器 1 访问日志：
ubuntu@php-app1:/var/log/apache2$ tail -f moodle281-access.log
172.31.40.186 - - [09/Jun/2015:22:44:52 +0000] "POST /login/index.php HTTP/1.1" 303 1018 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:53 +0000] "GET / HTTP/1.1" 200 39933 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:54 +0000] "GET /course/view.php?id=2 HTTP/1.1" 200 55453 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:55 +0000] "GET /course/view.php?id=2 HTTP/1.1" 200 55453 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:55 +0000] "GET /mod/forum/discuss.php?d=1 HTTP/1.1" 200 47600 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:56 +0000] "POST /mod/forum/post.php HTTP/1.1" 404 26456 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
172.31.40.186 - - [09/Jun/2015:22:44:56 +0000] "GET /user/index.php?id=2 HTTP/1.1" 200 82175 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
****(1) 172.31.19.167 - - [09/Jun/2015:22:48:52 +0000] "GET /login/logout.php?sesskey=fXjerOYZEo HTTP/1.1" 303 862 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
****(4) 172.31.19.167 - - [09/Jun/2015:22:48:55 +0000] "GET /login/index.php HTTP/1.1" 200 6088 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
****(5) 172.31.19.167 - - [09/Jun/2015:22:49:00 +0000] "GET /login/index.php?testsession=2 HTTP/1.1" 303 800 "http://demo1.virtualtoptraining.com/login/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
服务器 2 访问日志：
....
**** (2) 172.31.19.167 - - [09/Jun/2015:22:48:52 +0000] "GET / HTTP/1.1" 200 7078 "http://demo1.virtualtoptraining.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
**** (3) 172.31.19.167 - - [09/Jun/2015:22:49:00 +0000] "POST /login/index.php HTTP/1.1" 303 1010 "http://demo1.virtualtoptraining.com/login/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5"
....
负载均衡器访问日志：
015-06-09T22:48:52.128826Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.000092 0.204629 0.000058 303 303 0 434 "GET http://demo1.virtualtoptraining.com:80/login/logout.php?sesskey=fXjerOYZEo HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:48:52.382853Z itoptest2 151.182.141.178:52554 172.31.34.25:80 0.000082 0.456022 0.00007 200 200 0 6500 "GET http://demo1.virtualtoptraining.com:80/ HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:48:55.853509Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.000105 0.292976 0.000046 200 200 0 5617 "GET http://demo1.virtualtoptraining.com:80/login/index.php HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:00.382245Z itoptest2 151.182.141.178:52554 172.31.34.25:80 0.000105 0.545512 0.000068 303 303 36 463 "POST http://demo1.virtualtoptraining.com:80/login/index.php HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:00.980174Z itoptest2 151.182.141.178:52554 172.31.25.91:80 0.00007 0.219837 0.000044 303 303 0 434 "GET http://demo1.virtualtoptraining.com:80/login/index.php?testsession=2 HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
2015-06-09T22:49:01.248300Z itoptest2 151.182.141.178:52554 - -1 -1 -1 504 0 0 0 "GET http://demo1.virtualtoptraining.com:80/ HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.5 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.5" - -
如您所见，生成 504 GATEWAY_TIMEOUT 的请求从未出现在任何 Web 服务器访问日志中。
知道问题出在哪里吗？
您是否可能在负载测试场景中没有给 ELB 足够的启动期？确保在 CloudWatch 上监控 ELB Surge 队列。被丢弃的激增请求 return 5xx 错误 (More on CloudWatch ELB Metrics here).
此外，在针对 Amazon EC2 ELB 进行测试时，配置 JMeter 的 stalecheck 很重要。这是因为亚马逊会将您的 ELB 热交换为更大的 ELB，而不是主动扩展您正在使用的 ELB。这意味着底层寻址发生了变化，因此 JMeter 必须检查过时的连接。可能是 JMeter 正在向旧的 ELB 发送请求，然后又出现网关超时，因为它无法再发送到您的应用服务器。
查看来自 AWS 的深度 ELB 测试指南： AWS Best Practices for Load Testing ELB
此外，这是 JMeter 的 stalecheck 属性 所在的位置。
../bin/hc.参数：
# Default value since JMeter 2.11,
# also uncomment hc.parameters.file=hc.parameters to enable this check:
#http.connection.stalecheck$Boolean=false
您还需要编辑 jmeter.properties 文件，使其实际使用 hc.parameters 设置，如上面的评论所述。
您是否添加并启用了 DNS Cache Manager？如果不是，我建议您尝试一下，它应该可以解决您的问题。
我们对该主题做了进一步调查：
请求到达服务器（通过 运行 tcpdump 找到）但 Apache 未回答
Apache 错误日志显示 "not answered requests" Apache 因核心转储而崩溃。在日志中看到以下错误：
AH00051：子 pid 11419 退出信号总线错误 (7)
核心转储分析显示如下：
警告：无法加载 4 个库的共享库符号，例如/usr/lib/php5/20121212/sasl.所以。 使用 "info sharedlibrary" 命令查看完整列表。 您需要 "set solib-search-path" 还是 "set sysroot"？ [使用 libthread_db 启用线程调试] 使用主机 libthread_db 库“/lib/x86_64-linux-gnu/libthread_db.so.1”。 核心由“/usr/sbin/apache2 -k start”生成。 程序因信号 SIGBUS、总线错误而终止。 0 lex_scan (zendlval=) 在 Zend/zend_language_scanner.c:1091 1091 Zend/zend_language_scanner.c: 没有那个文件或目录。 (gdb)
分析完所有这些信息后，我们得出结论，问题与 PHP 错误有关，因为 并发访问文件 来自应用程序的两个不同实例。因此，此访问未正确协调，导致崩溃。