如果我们使用具有多个实例的 Amazon 负载平衡，当第二个实例启动时，它将如何访问最新的 Web 数据/文件系统。您是否应该将站点文件存储在存储桶内，并以某种方式设置 Apache 以访问存储桶？
谢谢您的任何意见。
答案1
我想我可能会用 GlusterFS 来做这件事。设置一个存储服务器集群，然后在扩展前端的存储服务器中安装资产，并从那里提供服务。
答案2
我用过云初始化过去的脚本在 Web 服务器启动之前将内容从中央源同步到每个实例。
另一种选择可能是使用在 EBS 快照中预先加载内容的基于 EBS 的实例。
答案3
我正在使用这个方法：
- 每隔 X 分钟，另一个实例会对要提供的文件进行快照
- 当新实例启动时，有效载荷脚本会下载快照并将文件复制到 Web 目录。
- 然后，新实例与另一个实例 rsync 以更新新的或修改的文件。
- 最后，Web 服务器启动。
您还可以使用 EBS 进行快照。我使用压缩快照是因为我的 Web 目录中有很多文件，rsync 需要花费大量时间来复制所有文件。
答案4
正常的云架构原则会说您应该将数据拉到单独的层 - S3 用于 Blob、SimpleDB 用于非关系数据、RDS 用于关系数据等 - 并且扩展前端不应该有数据。
EBS 和快照也是一个选项，这取决于您更改文件的频率。如果用户贡献数据/文件，您几乎肯定需要按照上述方法转到共享存储库。但如果只有您一个人，那么其他东西也可以正常工作。
如果这样做，您必须处理复制复杂性。通过 cloudinit 或 Chef 或 Puppet 等专用拉取配置机制，您可以进行拉取同步。这里的问题是，当您想要更改内容时，您还必须将其推送到所有服务器（或依赖于计划的拉取）。对于静态 Web 内容来说，这可能没问题；一旦您想要跨服务器管理应用程序，它就会变得更加棘手，而且还取决于您是每月更改一次文件还是每五分钟更改一次文件。
我们使用与推送同步相结合的编排机制。当新服务器启动时，它会注册并立即推送当前内容；然后当我们推送新内容时，我们会将其推送到所有活动服务器。这样做的好处是，在配置时和之后的更改时使用相同的渠道进行初始播种。有些人会破解 chef/puppet 来做类似的事情（或者用像 capistrano 这样的专用推送机制来增强它们）。