如果弹性 ip 关联到另一个 运行 ec2 实例,是否可以在重启后将弹性 ip 与 ec2 实例重新关联?

Is it possible to re-associate an elastic ip with an ec2 instance after reboot if the elastic ip is associated to another running ec2 instance?

我们有一个设置,其中 3 个 ec2 实例每个都与其主网络接口 eth0 上的弹性 ip 相关联,因此传入请求可以由这些实例提供服务。

这些实例中的每一个都有一个辅助网络接口 eth1,如果实例发生故障/崩溃/重启,与该实例关联的弹性 ip 将关联到其余 运行该接口上的 ec2 实例。这是某种故障转移机制,因为我们总是希望这些弹性 ip 由某个 运行 实例提供服务,这样我们就不会丢失任何传入请求。

我遇到的问题特别是在实例重启时。当实例重新启动时,它无法取回它拥有的 public ip,其中此 public ip 是现在与另一个实例关联的弹性 ip 的 ip。因此,除非我手动将弹性 ip 重新分配回此实例,否则此实例无法访问互联网。

是否可以在重新启动时自动reclaim/re-associate它曾经拥有的弹性 IP 到它的 eth1 接口?如果没有,您是否有解决方法的建议?

需要重新启动,因为我们将对实例进行无人值守的升级。

更新: 另请注意,我需要使用这些弹性 ip,因为它们是我们与之集成的合作伙伴公司的防火墙中允许的。使用 ELB 将不起作用,因为它的 IP 会随着时间的推移而变化。

听起来使用弹性负载均衡器 (ELB) 会更好。您可以只使用一个 ELB,它会为您的 3 个应用程序服务器提供请求。

如果一个出现故障,ELB 会检测到并停止在那里路由请求。当它重新联机时,ELB 检测到并再次将其添加到路由组。

http://aws.amazon.com/elasticloadbalancing/

这就是我最终解决这个问题的方法。我错过的是亚马逊只在两种情况下为实例提供新的 public IP。

  • 其弹性IP分离
  • 它只有一个网络接口

因此,基于此,在启动时,我为实例配置了两个实例,但分离了辅助 eth1 接口。因此,这使实例有资格获得新的 public IP(如果出于任何原因它重新启动)。

现在进行故障转移,一旦 运行 个实例中的一个检测到一个实例已从集群中脱机(在这种情况下,假设它重新启动),它将立即连接到辅助接口并将弹性 IP 关联到它。因此,弹性 IP 现在由至少一个 运行 实例提供服务。效果立竿见影。

现在,当失败的实例在重启后恢复时,亚马逊已经为其提供了一个新的非弹性 public IP。这是因为它满足了只有一个网络接口的两个条件,而且它的弹性 IP 被取消关联并重新关联到另一个 运行 实例。因此,这个重新启动的实例现在有一个新的 public IP,并且可以在启动时连接到互联网,并执行配置自身和重新加入集群所需的必要任务。之后它重新关联回它需要的弹性 ip。

此外,当接管弹性 IP 的 运行 实例检测到新实例或重新启动的实例已上线时,它会再次分离辅助接口,以便有资格获得新的 public ip 以及如果它重新启动。

这就是我处理故障转移并确保始终提供弹性 ips 的方式。但是这个解决方案并不完美,可以改进。如果 N 个网络接口可用于故障转移,它可以扩展到处理 N failed/rebooted 个实例!

但是,如果在故障转移期间附加辅助接口的实例重新启动,它将不会获得新的 public IP,并且会保持与集群的断开连接,但至少弹性 IP 仍会由剩余的活动实例。这仅在重新启动的情况下。

顺便说一句,至少从我读到的所有内容来看,亚马逊文档中没有明确提到这些获得新 public ip 的条件。