链接2个EC2实例

你描述的场景（一台运行apache的服务器和另外一个存储文件）并不提供任何真正的备份 – 可以说，它使失败的机会增加了一倍（现在你有两台机器，如果失败，整个系统将无法工作）。

如果您刚刚开始使用EC2，获得类似function的最简单方法是将您的数据存储在EBS驱动器上，并将您的自定义实例保存为AMI。 从那里，你可以设置自动调整，以保持一个实例在任何时候 – 如果你的一个实例失败，另一个可以根据您的AMI联机，你可以使用快照（稍微过时），或移动EBS卷得到一切备份和运行（可以自动）。

如果您只是提供静态文件，那么您可以完全不用EC2，只需使用S3 – 它将提供您所需的可扩展性和（内部）冗余。 但是，如果您使用的是数据库，那么将它们存储在S3上并不是一个好主意，因为它们会导致显着的性能损失。

如果您确实在寻找故障转移设置，则即使实例发生故障，也需要您的设置才能正常工作。 有两个例子，这意味着要么a）每个都是自给自足的，或者b）当一个失败时，另一个等价的实例将被带入在线。

上述故障转移设置和自动缩放集群之间存在的潜在差异在于您拥有的控制程度。 虽然Cloudwatch（从而自动缩放）确实支持自定义度量标准，但是其他解决scheme允许实现更多function。 例如（纯粹是理论上的），你可以设置一个2节点的集群（例如在Amazon的VPC中），并使用Heartbeat / Corosync监控每个实例的状态，用Pacemakerpipe理资源（例如，如果你的Apache发生故障而不是整个实例，可以采取一些行动）。 文件可以在实例之间通过一个简单的rsync（如果没有太多的改变），或者与一个分布式文件系统（例如Gluster）共享。 一个实例将被选为“领导者”，并可以运行负载均衡器（例如nginx，HAProxy等），并将请求发送给一个实例或另一个实例。 这样的devise不是没有问题的（当然需要花费很多精力来设置），但是可能提供一些潜在的体系结构。

按照问题回答问题（其实质上是如何在本地访问远程文件）。 你可以去：

• 共享存储方式（存储在S3上的文件，使用保险丝本地安装）
• networking文件系统（例如Gluster – 远程文件系统可以访问networking实例）
• 在本地访问的远程文件系统（例如sshfs – 基于熔丝的方法通过ssh / sftp访问/挂载远程文件系统）

几乎所有您select的方法都需要打开安全组上的端口以允许实例之间的通信 – 您可能希望将对这些端口的访问限制在同一安全组中的其他实例上。