我们有一个设置，其中3个ec2实例各自与其主网络接口eth0上的弹性IP相关联，因此这些实例可以提供传入请求。
这些实例中的每一个都具有辅助网络接口eth1，其中在实例发生故障/崩溃/重启时，与该实例关联的弹性ip将与该接口上剩余的正在运行的ec2实例之一相关联。这是某种故障转移机制，因为我们总是希望这些弹性ips由一些正在运行的实例提供服务，因此我们不会丢失任何传入的请求。
我遇到的问题主要是重启实例。当一个实例重新启动时，它无法恢复它所拥有的公共IP，其中公共IP是现在与另一个实例关联的弹性ip的ip。因此，除非我手动将弹性IP重新分配给此实例，否则此实例无法访问Internet。
是否可以在重启时自动回收/重新关联曾经拥有的弹性IP到其eth1接口？如果没有，您对解决方法有什么建议吗？
重新启动是必要的，因为我们将对实例进行无人值守的升级。
更新 另请注意，我需要使用这些弹性ips，因为它们是我们集成的合作伙伴公司的防火墙中允许的那些。随着时间的推移，使用ELB不会起作用。
答案 0 :(得分：2)
所以，我最终解决了这个问题。我错过的是亚马逊只在两种条件下为一个实例提供了一个新的公共IP。
基于此，在启动时，我使用两个实例配置实例，但我分离了辅助eth1接口。因此，这使得实例有资格获得新的公共IP（如果出于任何原因重新启动）。
现在进行故障转移，一旦其中一个正在运行的实例检测到某个实例已从群集中脱机（在这种情况下，假设它已重新启动），它将随时附加辅助接口并将弹性IP关联到它。因此，弹性IP现在由至少一个正在运行的实例提供服务。效果很快。
现在，当重启后失败的实例重新启动时，亚马逊已经为它提供了一个新的非弹性公共IP。这是因为它满足了仅具有一个网络接口的两个条件，并且其弹性IP也被解除关联并重新关联到另一个正在运行的实例。因此，此重新启动的实例现在具有新的公共IP，并且可以在启动时连接到Internet，并执行配置自身并重新加入群集所需的必要任务。之后，它重新关联了它需要的弹性ip。
此外，当接管弹性IP的运行实例检测到新实例或重新启动的实例已联机时，它会再次分离辅助接口，因此如果重新启动，它也有资格获得新的公共IP。
这就是我处理故障转移并确保始终提供弹性ips的方法。然而，这种解决方案并不完美，可以改进。它可以扩展到处理N个失败/重新启动的实例，前提是N个网络接口可用于故障转移！
但是，如果在故障转移期间连接辅助接口的实例重新启动，它将无法获得新的公共IP并将保持与群集断开连接，但至少弹性IP仍将由剩余的实时实例提供服务。这只是在重新启动的情况下。
BTW，至少从我读到的所有内容来看，这些获取新公共IP的条件在亚马逊文档中没有明确提及。答案 1 :(得分：0)
听起来使用弹性负载平衡器（ELB）会更好。您可以只使用一个ELB，它将为您的3个应用程序服务器提供请求。
如果一个发生故障，ELB会检测到并停止在那里发送路由请求。当它重新联机时，ELB会检测到并再次将其添加到路由组中。