最初我的问题是“如何在不必首先找到其IP地址的情况下进入EC2实例”。为了解决这个问题,我写了一个在每个实例上定期执行的脚本。该脚本读取特定标记值,并使用实例的公共DNS名称更新Route53中的相应条目。
这样我总是可以转到web-01.ec2.mydomain.com并连接到正确的实例。
当我继续设置我的实例时,我意识到要设置mongodb复制,我需要以某种方式引用三个独立的实例。我不能使用内部私有IP地址,因为它们不断变化(或者在实例停止/启动时以及在dhcp租约到期时容易发生变化)。
尝试从我的EC2实例中访问web-01.ec2.mydomain.com
会返回实例的内部IP地址。这似乎是标准行为。因此,通过提及我的三个实例的route53 cnames,我可以确保它们总是可以彼此发现。我不会支付任何额外的数据传输费用,因为cnames将始终解析为内部IP。然而,我会支付所有route53查询。
我可以每30秒运行一次脚本甚至更少,以确保dns条目尽可能保持最新状态。
此时,我意识到我所拥有的是一种弹性IP替代方案。也许不完全,但肯定对我所有的用例。所以我想知道,是否使用弹性IP。只要我的实例正在运行,就不会产生任何费用。这看起来似乎更容易。
大多数人都做了什么?如果有经验的人可以回复,我会很感激。
其次,在实例丢失其当前私有IP并获得新的内部ip的几秒/分钟内会发生什么。假设所有现有连接都被丢弃。这是否会影响ELB健康检查(每30秒一次ping一次)?假设我使用弹性IP,dns名称会立即解析为新的ip,而不是说我的脚本执行后。假设我的脚本每30秒运行一次,是否只有30秒的停机时间,或者可能还有更多? Elastic ip总是比我的脚本化解决方案表现更好吗?
答案 0 :(得分:4)
根据official AWS documentation a“私有IP地址在其生命周期内专门与实例关联,并且仅在实例停止或终止时返回到Amazon EC2。在Amazon VPC中,实例保留其私有IP实例停止时的地址。“因此,如果发生变化,每隔30秒检查一下就会出现内在的错误。这为您提供了两个明显的选择:
使用过的弹性IP不会花费任何成本,即使是停放的IP也只会花费很少。如果您的实例大部分都在运行,请使用弹性IP。如果它们大多数都已关闭,请执行启动时更新路径。如果您的实例位于VPC中,则严格不需要更新引导时间(但在VPC中,您可能有不同的需求和更复杂的网络设置)。
答案 1 :(得分:1)
您可以考虑的另一个选择是使用软件定义的数据中心解决方案,例如Amazon VPC或Ravello Systems(免责声明:我们公司)。
使用这样的解决方案将允许您在公共云中创建一个有围墙的私有环境。在环境中,您可以完全控制,包括您自己的专用L2网络,您可以在其上管理IP寻址,并且可以使用例如静态分配的IP。与外部(例如您的应用服务器)的通信通过您配置的IP和端口进行。