EC2 弹性负载均衡器 DNS 和路由问题

Question

我们正在尝试在 Amazon EC2 上运行一个相当简单的设置 - 位于 Amazon Elastic Load Balancer (ELB) 后面的几个 HTTP 服务器。

我们的域是在 Route53 中管理的，我们设置了一个指向 ELB 的 CNAME 记录。

我们遇到了一些问题，其中一些（但不是全部）位置间歇性地无法连接到负载均衡器；看来这可能是ELB的域名解析。

亚马逊支持告诉我们负载均衡器的底层弹性 IP 一直在变化，问题是一些 ISP 的 DNS 服务器不遵守 TTL。我们对这种解释并不满意，因为我们使用 Amazon 自己的 DNS 服务器从 EC2 实例以及澳大利亚本地 ISP 和 Google 的 DNS 服务器复制了该问题 ( 8.8.8.8)。

亚马逊还证实，在我们注意到某些位置出现停机期间，通过 ELB 的流量显着下降——因此问题不在于我们的端点。

有趣的是，域似乎在无法连接的服务器上解析为正确的 IP - 但尝试建立 TCP 连接失败。

附加到 ELB 的所有实例一直处于健康状态。他们都是

有谁知道我们如何更深入地诊断这个问题？有没有其他人在使用 Elastic Load Balancer 时遇到过这个问题？

谢谢，

Answer 1

我在谷歌搜索如何诊断 Amazon Elastic Load Balancer (ELB) 时发现了这个问题，我想为像我这样在没有太多指导的情况下遇到这个问题的其他人回答这个问题。

ELB 属性

ELB 有一些有趣的特性。例如：

• ELB 由 1 个或多个节点组成
• 这些节点作为 ELB 名称的 A 记录发布
• 这些节点可能会失败或被关闭，并且连接不会正常关闭
• 通常需要与亚马逊支持（$$$）建立良好的关系才能让某人深入研究 ELB 问题

注意：另一个有趣但不太相关的特性是 ELB 并非设计用于处理突然的流量高峰。它们通常需要 15 分钟的繁忙交通才能扩大规模，或者可以通过支持票根据要求进行预热

ELB 故障排除（手动）

更新： AWS 已将所有 ELB 迁移到将 Route 53 用于 DNS。此外，所有 ELB 现在都有一个all.$elb_name记录，将返回 ELB 的完整节点列表。例如，如果您的 ELB 名称是elb-123456789.us-east-1.elb.amazonaws.com，那么您将通过执行类似的操作来获取节点的完整列表dig all.elb-123456789.us-east-1.elb.amazonaws.com。对于 IPv6 节点，all.ipv6.$elb_name也适用。此外，Route 53 仍然可以使用 UDP 返回最多 4KB 的数据，因此+tcp可能不需要使用该标志。

知道了这一点，您就可以自行进行一些故障排除。首先，将 ELB 名称解析为节点列表（作为 A 记录）：

$ dig @ns-942.amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

tcp建议使用该标志，因为您的 ELB 可能有太多记录无法放入单个 UDP 数据包。我还被告知，但尚未亲自确认，除非您执行ANY查询，否则Amazon 最多只会显示 6 个节点。运行此命令将为您提供如下所示的输出（为简洁起见进行了修剪）：

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.amazon.com. root.amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

现在，对于每个A记录，使用 egcurl来测试与 ELB 的连接。当然，您还希望将您的测试隔离到 ELB，而不连接到您的后端。关于 ELB 的最后一个属性和鲜为人知的事实：

• 可以通过 ELB 发送的请求方法（动词）的最大大小为127 个字符。任何更大的 ELB 将回复HTTP 405-Method not allowed。

这意味着我们可以利用这种行为来仅测试 ELB 正在响应：

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

如果您看到，HTTP/1.1 405 METHOD_NOT_ALLOWED则 ELB 响应成功。您可能还想将 curl 的超时调整为您可以接受的值。

使用 elbping 对 ELB 进行故障排除

当然，这样做会变得非常乏味，所以我构建了一个工具来自动化这个叫做elbping。它可以作为 ruby​​ gem 使用，因此如果您有 ruby​​gems，那么您只需执行以下操作即可安装它：

$ gem install elbping

现在你可以运行：

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

请记住，如果您看到，code=405则表示 ELB 正在响应。

下一步

无论您选择哪种方法，您至少都会知道您的 ELB 节点是否有响应。有了这些知识，您就可以将注意力转向对堆栈的其他部分进行故障排除，或者能够向 AWS 提出一个非常合理的案例，说明出现了问题。

希望这可以帮助！

Answer 2

修复实际上很简单：在 Route53 中使用A记录而不是 a CNAME。

在 AWS 管理控制台中，选择“A 记录”，然后将标有“别名”的单选按钮移动到“是”。然后从下拉菜单中选择您的 ELB。