亚马逊EC2负载平衡的最佳方法

我想我可能会用GlusterFS来做这个。 build立一个存储服务器集群，然后在存储服务器上安装扩展前端的资源，并从那里开始服务。

过去，我曾经使用过CloudInit脚本，在启动Web服务器之前，将内容从中央源同步到每个实例。

另一个选项可能是使用EBS快照中预先加载了内容的基于EBS的实例。

我正在使用这个方法：

• 每隔X分钟，另一个实例为要提供的文件创build一个快照
• 新实例启动后，有效负载脚本将下载快照并将文件复制到Web目录。
• 然后，新的实例rsync与另一个实例更新新的或修改的文件。
• 最后，Web服务器启动。

你也可以使用EBS作为快照。 我正在使用压缩快照，因为我的web目录中有很多文件，rsync会花费大量时间来复制所有文件。

正常的云体系结构原则会说你应该把数据从一个单独的层中提取出来–S3用于blob，SimpleDB用于非关系数据，RDS用于关系数据等等，而且缩放前端不应该有数据。

EBS和快照也是一个选项，这取决于你将多久改变一次文件。 如果用户正在贡献数据/文件，那么几乎可以肯定需要按照上述内容进行共享回购。 但是，如果只是你，那么其他的东西工作正常。

如果你这样做，你必须处理复制的复杂性。 通过cloudinit，或者像厨师或傀儡这样的专门的提供机制，你可以做一个拉同步。 这里的问题是，当你想改变内容时，你必须把它推送到所有的服务器（或依赖于预定的拉）。 对于静态Web内容来说可能是好的; 一旦你想跨服务器pipe理应用程序，它会变得更加棘手，也取决于你是否每月或每五分钟更改一次文件。

我们使用与推送同步相结合的编排机制。 当一个新的服务器出现时，它会注册并立即获取当前内容; 那么当我们推送新内容时，我们会将其推送到所有活动的服务器 这有利于在configuration时和之后的更改时使用相同的频道进行初始播种。 有些人破坏厨师/傀儡做相似（或用像卡皮斯特拉诺这样的专门推送机制来增加他们）。