Amazon AutoScaling和GlusterFS

GlusterFS是在Autoscaling组中的所有实例之间共享数据的一个很好的解决scheme吗？

可能..然而，只有通过自己的testing才能得到明确的答案。 过去，我在Linode实例上build立了一个4节点的Web服务器集群，使用GlusterFS来分发/共享图像的资产目录等等。
我们发现这种方法存在两个主要问题：

1. GlusterFS相当密集的IO，并且在具有无竞争IO的硬件上运行得非常好
2. 偶尔，Linode服务器可能会遇到对后端SAN访问不甚理想的情况，并且IO等待时间会大幅增加。 发生这种情况时，Gluster会在剩下的节点之间复制更多的数据，从而导致IO性能在这些节点上依次受到影响。 这样做的结果是由于次优SANconfiguration或时间共享所导致的次要IO blip将意味着整个web服务器集群将进入poot，并且整个共享文件系统可能变得不可用。

纯粹的轶事证据，但我不会再运行SAN /共享存储虚拟机上的GlusterFS。

Gluster确保没有数据丢失？

它可以…在Gluster 3.0中，对“复制池”有更好的认识，您可以在其中定义整个群集中存在多less数据副本。 将复制级别设置为2意味着整个集群中有两个副本。这有效地减less了您的存储容量，但意味着您对节点故障具有更大的恢复能力。
重要的是，这也意味着您必须添加更多的节点作为复制级别的倍数，在这种情况下，节点对。

如果Autoscaling中的所有实例都终止，会发生什么情况？我会丢失用户数据吗？

如果这些实例只使用临时实例存储，是的。 如果他们是基于EBS的，或者使用挂载的EBS实例，那么没有。

如果用户上载图像并且处理请求的服务器closures，会发生什么情况？

这很大程度上取决于您的应用程序的devise。 我强烈怀疑用户会丢失他们的数据（几乎可以肯定，这是一个天真的架构解决scheme）。

如果客户倒下，是否会对IO产生影响？

请参阅上文。如果客户端由于后端存储问题而closures，则可能完全损坏集群的性能。

GlusterFS似乎需要一点点太多的configuration时，使在线新的实例，使其成为一个很好的系统使用需要自动调整的实例。 我相信它可以做到，但更容易改变体系结构，以便web实例不同于glusterfs实例。 networking实例只需要作为客户端连接到glusterfs层。 networking实例可以设置为自动调整。

处理云系统的一个很好的规则是将服务与实例进行1：1的映射。 不要试图让一个实例太多。 在架构上，这有助于扩展事物。

你已经对Gluster的问题有了一些很好的答案，但是我想提一些可能有用的东西。

根据您的使用情况，您可能会发现以下更容易pipe理和更less的错误：

• EC2是完全相同的，代码从一个回购仓库中保持到最新（你可以通过部署过程以多种方式进行pipe理）
• 任何用户上传直接通过s3fs或API调用集成到您的应用程序（Python / PHP等）

S3的好处很简单：

• 只需支付您使用的费用（无需支付EC2中大量未使用的资源，运行成本，通过多台机器进行复制等，也不需要pipe理）
• S3中内置了冗余function，因此在进入s3的时候，文件是安全的（安全意味着它们位于全球多个地点的托pipe服务中，AWS报告说它们在s3中从未丢失过文件）

如果你想多走一步，你可以configuration你的（linux）服务器把所有的日志发送到一个“日志服务器”（这样可以使所有的EC2s保持一致，就像你可以得到的一样）。

过去，我发现这种设置在我pipe理的Web服务器上工作得很好。