我不是云计算专家——我花了相当多的时间研究它和各种提供商，但还没有获得任何实际经验。从我读过的有关 AWS 和自动扩展 EC2 实例的文章来看，似乎每个实例都应该与所有其他实例完全分离。即，如果内容从自定义 CMS 后端上传到 Web 服务器的本地文件系统，那么如果随后从自动扩展组中的其他 Web 服务器请求该内容，则该内容将不可用。对吗？
我最近会见了我们现有托管服务提供商的一位代表，他声称我们的旧式 CMS 系统高度依赖本地文件系统并不是问题。他说，所有 Web 服务器（无论有多少）都将保留为完全相同的副本，因此与现有的单个专用服务器设置相比，我不会注意到任何差异。这对我来说有点像胡说八道......我应该对此持怀疑态度吗？我有点担心，因为最终做出决定的（非技术）老板完全赞成签署此云解决方案，因为它不需要任何额外的工作。
我确信他们至少能够提供这一点，否则他们就不会试图将其出售给我们。但代价是什么？听起来好像每个 Web 服务器总是需要检查其他 Web 服务器是否有新的静态内容，在我看来，这听起来像是不必要的开销，会减慢速度。
如果有人能帮我澄清这一点，我将不胜感激。我完全赞成切换到 AWS 并使用 S3+CloudFront 来存储所有静态内容，但目前看来不太可能发生这种情况。
答案1
为了服务于依赖于一致的后端文件系统的应用程序，同步必须是全方位的，并且需要阻止任何写入请求，直到所有副本都更新……至少可以说，要正常工作是非常棘手的事情，而且这种系统的任何内部错误都将产生灾难性的后果。
他们可能实际上通过单个大型后端存储（NFS 或文件系统感知 SAN）来操作所有 Web 头，这可能会导致单点故障。
答案2
如果你谈论的是静态文件，那么有集群、复制的解决方案，例如格鲁斯特这样就可以相对无缝地完成这一目标，并且开销也相当合理。
不过，您可能不想在其上运行类似 MySQL 数据库的东西。
答案3
我并不是想表现得“厚颜无耻”或漠不关心，但这取决于服务和价格。可以进行文件系统复制，也可以在 SAN 设备上进行块复制。您必须询问您的提供商是否正在使用这两种技术中的任何一种……并且您需要知道复制站点之间的距离。复制站点之间的距离将改变系统复制的效果。通过 SAN 进行复制需要花费一些钱。通过服务或文件系统进行复制可能是免费的（如果它们是通过 rsync 或其他方式复制的）。