☰

ELB 属性

tag-icon • tag-icon amazon-ec2 load-balancing cloud
ELB 属性

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

我们的域名在 Route53 中管理，并且我们设置了 CNAME 记录来指向 ELB。

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

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

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

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

连接到 ELB 的所有实例始终处于健康状态。它们都是

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

谢谢，

答案1

我在谷歌上搜索如何诊断 Amazon Elastic Load Balancers (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 数据包中。我还被告知，但尚未亲自证实，亚马逊最多只会显示 6 个节点除非您执行ANY查询。运行此命令将为您提供类似以下的输出（为简洁起见，已删减）：

;; 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记录，使用例如curl测试与 ELB 的连接。当然，您还希望将测试隔离到 ELB，而不连接到后端。关于 ELB 的最后一个属性和鲜为人知的事实：

  • 可以通过 ELB 发送的请求方法（动词）的最大大小为127 个字符。如果再大一点，ELB 就会回复HTTP 405-方法不允许。

这意味着我们可以利用这种行为来仅测试 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 故障

当然，这样做可能会非常繁琐，所以我创建了一个工具来自动化这个过程，叫做埃尔平。它以 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 提出合理的理由，说明出现了问题。

希望这可以帮助！

答案2

修复方法其实很简单：在 Route53 中 使用A记录而不是记录。CNAME

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

答案3

您可以在此 AWS 开发人员论坛中尝试一些潜在的解决方案。https://forums.aws.amazon.com/message.jspa?messageID=387552。

例如：

潜在修复 #1

当我们迁移到 ELB 时，我们遇到了类似的问题，我们通过将 ELB 的名称缩减为一个字符来解决这个问题。即使 ELB 的名称只有 2 个字符，也会导致网络解决方案 DNS 解析出现随机问题。

您的 ELB 的 DNS 名称应类似于 -> X.<9chars>.us-east-1.elb.amazonaws.com

潜在修复 #2

我是原始发帖人。感谢大家的回复。我们能够通过将 TTL 设置为非常高（这样它们将被非 Network Solutions 服务器缓存）来减少遇到 DNS 问题的频率。但是，我们仍然遇到足够多的问题，以至于我们无法再使用 Network Solutions。我们考虑根据对该服务的良好报告转向 UltraDNS，但看起来 Route 53（似乎在幕后使用 UltraDNS）对我们来说更便宜。自从切换到 Route 53 以来，我们不再遇到 DNS 问题，而且我们的 ELB 名称也可以很好很长。

该帖子中还提到了其他可以尝试的事情，但这些似乎是最好的线索。

相关内容