问题标签 [amazon-elb]

我们使用 WebSockets 与我们的 EC2 实例进行通信。我们的脚本使用 nodejs 和 Express 提供服务，然后初始化 WebSocket。现在使用 ELB，这使得识别客户端 IP 变得更加困难。使用 x-forwarded-for 标头我们可以在 HTTP 的上下文中获取 IP，但是当涉及到服务器中的 WebSocket 上下文时，它看起来好像不是由 Amazon 转发的。

我们确定了 2 个选项：

1. 直接与实例通信 WebSocket（使用其公共 DNS）。
2. 维护某种 sessionid，在其中存储在 HTTP 上下文中的 IP 并将其与 sessionid 关联。客户端将使用 HTTP 响应获取其 sessionid，并将其用于 WebSockets。服务器将识别客户端并从缓存中解析其 IP。

这两个选项都不是很好：1 不是容错的，2 是复杂的。还有更多的解决方案吗？亚马逊可以以某种方式转发 IP 吗？最佳做法是什么？

谢谢

我正在尝试将一组 EC2 实例放在几个 Varnish 服务器后面。我们的 Varnish 配置很少更改（一年一次或两次），但我们总是出于各种原因（更新、问题、负载峰值）添加/删除/替换 Web 后端。这会产生问题，因为我们总是必须更新我们的 Varnish 配置，这导致了错误和心碎。

我想做的是管理一组后端服务器，只需在弹性负载均衡器中添加或删除它们即可。我尝试将 ELB 端点指定为后端，但出现此错误：

ELB 提供的唯一一致的公共接口是它的 DNS 名称。此 DNS 名称解析为随时间和负载而变化的 IP 地址集。

在这种情况下，我宁愿不指定一个确切的地址——我想在从 DNS 返回的任何内容之间进行循环。这可能吗？或者有人可以提出另一个解决方案来完成同样的事情吗？

谢谢，山姆

我有一个使用 Amazon Web Services (AWS) 的实时 iOS 应用程序。我已经根据亚马逊的说明成功设置了令牌自动售货机 (TVM)，并且该应用程序可以完美地与 AWS 配合使用。

按照 AWS 说明设置 TVM 需要您在 Elastic Beanstalk 中创建一个新环境，该环境会自动为您创建一个负载均衡器。

我的免费套餐最近已过期，现在我开始为负载均衡器时间付费。由于我的应用程序相当小众并且只有少量追随者，我认为我不再需要负载均衡器，因此想删除它。

问题是，如果我这样做（按照亚马逊在此处的说明），我的令牌自动售货机将无法访问。Chrome 报告该 URL 不可用。

在运行亚马逊的 TVM 时，有没有人有任何关于删除 ELB 的提示？

有没有办法让 ELB 或 EC2 自动扩展组从 ELB 终止（或重启）不健康的实例？

我们的前端有一些特定的数据库故障情况，使其变得不健康，因此 ELB 将停止将流量路由到它。该实例也是自动缩放组的一部分，该组会根据组的 CPU 负载进行缩放。因此，最终发生的情况是实例不再从 ELB 获取流量，因此它没有 CPU 负载，并且扭曲了组的 CPU 负载，从而破坏了扩展条件。

是否有一种“简单”的方法可以以某种方式配置 ELB 或自动缩放组以自动终止组中不健康的实例，而无需实际编写代码来通过 EC2 API 进行轮询和终止？

我想从 ELB 中删除/分离一个实例（但不删除实例本身）。

API 似乎需要DeleteLoadBalancerListeners的特定端口号。

如何从 LB（所有端口）中完全删除它？（就像 AWS 中的 GUI 操作“从负载均衡器中删除”一样）

我正在使用Java SDK。

当服务器未能向客户保证我们正在解决该问题时，我无法找到 AWS ELB 显示失败鲸鱼式系统消息的选项。

我们能想到的最好办法是设置一个 micro-ec2 实例，然后使用守护程序或 cron 作业或使用 monit 监控服务器运行状况，并在所有服务器都关闭时启动这个微实例。

这个问题还有其他更优雅的解决方案吗？

我按照此链接中的说明进行操作： 如何使 Amazon 的 ELB 与 HTTPS/SSL 一起使用 Web 套接字？设置 ELB 以使用 Websocket（在 TCP 模式下将 ELB 转发 443 到 8443）。现在我看到 wss 的这个问题：服务器发送 message1，客户端没有收到它；几秒钟后，服务器发送消息 2，客户端收到两条消息（两条消息大约 30 个字节）。我可以很容易地重现这个问题。如果我在服务器上使用 iptable 设置端口转发并让客户端直接连接到服务器（端口 443），我就没有问题 此外，这个问题似乎只发生在 wss 上。ws 工作正常。

服务器正在运行 jetty8。

我检查了 EC2 论坛并没有真正找到任何东西。我想知道是否有人见过同样的问题。

谢谢

我在 AWS 中有一个实例，我在其上设置了我的整个环境（我将其称为我的就绪实例）并且运行良好。然后，我创建了一个带有自动缩放策略的负载均衡器 (ELB)。

当我使用自动扩展策略（最少 2 个实例）创建负载均衡器时，出现了 2 个实例。然而，这些实例是空的。对于启动配置，我指定了我的就绪实例 AMI。这不应该告诉自动缩放策略要克隆哪个实例吗？在这种情况下，我的就绪实例不应该被克隆到它们中并且它们应该具有相同的内容吗？

如果我注册多个不同大小的实例，任何人都知道如何ELB分发请求。EC2说一m1.medium，一m1.large，一m1.xlarge。

EC2如果我注册相同大小的实例会有所不同吗？如果是，那怎么办？

我正在设计一个托管在云中的网站/网络服务（特别是 AWS，尽管这几乎无关紧要），而且我花了很多时间思考“为失败而设计”。我希望我的系统能够无缝地处理节点故障，即没有任何重大的用户影响或工程师干预。

在大多数情况下，很容易看出如何处理突然的节点故障。如果我的应用程序有一个由负载均衡器后面的 4 个服务器处理的 API，由 AJAX 或 iPhone 应用程序轮询，轮询器可以简单地检测失败的 TCP/IP 传输并重试......假设负载均衡器行为正确，它将命中健康的实例。

如果应用程序更面向处理，则可以使用像 SQS 这样的队列服务来允许无状态节点从故障节点停止的地方继续工作。

我看到的困难在于“入口点”，因为尚未加载应用程序，因此无法重试/轮询，并且失败意味着应用程序永远不会启动。例如，网页上的 index.html ......如果一个节点在传输该文件时失败，用户的浏览器可能会挂起并且不会自动重试（他们需要刷新）。

负载均衡器也是一个单一的“入口/故障点”。但是，在这种情况下，我们似乎可以通过创建多个负载平衡器来解决问题，并使用 DNS 负载平衡对它们进行负载平衡，如下所述：http: //blog.rightscale.com/2012/10/23/dns-load-云中的平衡和使用多个负载平衡器/

这是一个适用于更简单的 index.html 案例的解决方案吗？总的来说，我们如何在无法进行轮询/重试/排队的情况下创建冗余？

编辑：另一个想法是将 index.html 静态托管在 CDN、S3 等（资源可用性更可靠）上，尽管这会阻止使用动态内容。如果页面使用 JS 填充自身，则可以添加动态内容，但这会增加对 JS 的依赖以及用户的延迟。