Amazon AutoScaling 和 GlusterFS

Question

我已经使用在负载均衡器中注册的 5 个 EC2 实例设置了弹性负载均衡。对于我们的网站用户上传他们的数据（图像），我们将这些图像存储在网络附加存储（NAS）中。我们在所有实例上都安装了 NAS。

我们正计划引入 Amazon AutoScaling 并搬出网络附加存储。

1. GlusterFS 是在 Autoscaling 组中的所有实例之间共享数据的好解决方案吗？

2. Gluster 是否确保没有数据丢失？

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

4. 如果用户上传图像并且处理请求的服务器出现故障，会发生什么？

5. 如果客户端宕机，对 IO 有影响吗？（Gluster 到底是做什么的？）

Answer 1

GlusterFS 是在 Autoscaling 组中的所有实例之间共享数据的好解决方案吗？

可能……但是，您获得明确答案的唯一方法是通过您自己的测试。过去，我在 Linode 实例上设置了一个 4 节点网络服务器集群，使用 GlusterFS 分发/共享图像的资产目录等。
我们发现这种方法有两个主要问题：

1. GlusterFS 是非常 IO 密集型的，并且在具有无竞争 IO 的硬件上运行得非常好
2. 有时，Linode 服务器会遇到对后端 SAN 的访问不太理想的情况，并且 IO 等待时间会急剧增加。发生这种情况时，Gluster 会在剩余节点之间复制更多数据，从而导致这些节点上的 IO 性能依次受到影响。这样做的结果是，由次优 SAN 配置或分时导致的轻微 IO 信号将意味着整个 Web 服务器集群将变得不可用，并且整个共享文件系统可能变得不可用。

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

Gluster 是否确保没有数据丢失？

它可以... 在 Gluster 3.0 中，可以更好地识别“复制池”，您可以在其中定义整个集群中存在多少数据副本。将复制级别设置为 2，意味着整个集群上有 2 个副本。这实际上将您的存储容量减半，但意味着您对节点故障具有更大的弹性。
重要的是，这也意味着您必须添加更多节点作为复制级别的倍数，在本例中为节点对。

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

如果实例仅使用临时实例存储，则可以。如果它们基于 EBS，或者使用挂载的 EBS 实例，则不会。

如果用户上传图像并且处理请求的服务器出现故障，会发生什么？

这在很大程度上取决于您的应用程序的设计方式。我强烈怀疑用户会丢失他们的数据（在天真的架构解决方案中几乎可以肯定。）

如果客户端宕机，对 IO 有影响吗？

见上.. 如果客户端因为后端存储问题而宕机，它很容易完全破坏集群的性能。