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

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

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

亚马逊支持告知我们，负载均衡器的基础弹性IP一直在变化，问题在于某些ISP的DNS服务器不支持TTL。我们对此解释不满意，因为我们使用Amazon自己的EC2实例的DNS服务器，澳大利亚本地的ISP和Google的DNS服务器（8.8.8.8）复制了该问题。

亚马逊还确认，在我们注意到某些位置的停机时间期间，通过ELB的流量显着下降-因此问题出在我们的终端上。

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

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

有谁知道我们将如何更深入地诊断这个问题？弹性负载均衡器是否有其他人遇到过此问题？

谢谢，

我在Google搜索时发现了这个问题，该问题是如何诊断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查询，否则亚马逊最多只会显示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记录，使用例如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的超时时间调整为可接受的值。

使用弯头对ELB进行故障排除

当然，这样做可能会非常乏味，因此我建立了一个工具来自动化这个称为elbping的工具。它可以作为宝石红宝石使用，因此，如果您有宝石红宝石，则只需执行以下操作即可安装它：

$ 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提出合理的理由以解决问题。

希望这可以帮助！

解决方法实际上很简单：使用A记录而不是CNAMERoute53中的。

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

您可以在此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设置得很高，我们可以减少遇到DNS问题的频率（这样它们将被非网络解决方案服务器缓存）。但是，我们仍然遇到了足够多的问题，无法再使用Network Solutions。我们曾考虑根据服务的良好报告迁移到UltraDNS，但对于Route 53（它会在表皮下使用UltraDNS，看来会显得便宜）对我们来说便宜一些。自从切换到Route 53以来，我们不再有DNS问题，而且我们的ELB名称也可以很长。

该帖子中还有其他尝试的方法，但这些方法似乎是最好的线索。