我已经设置了 Elastic 负载平衡，并在负载平衡器上注册了 5 个 EC2 实例。我们的网站用户上传他们的数据（图像），我们将这些图像存储在网络附加存储 (NAS) 中。我们在所有实例上都安装了 NAS。
我们计划引入 Amazon AutoScaling 并退出网络附加存储。
GlusterFS 是否是跨 Autoscaling 组中的所有实例共享数据的好解决方案？
Gluster 能确保不会丢失数据吗？
如果 Autoscaling 中的所有实例都终止，会发生什么情况，我会丢失用户数据吗？
如果用户上传图像并且处理请求的服务器出现故障，会发生什么情况？
如果客户端宕机，对 IO 会有影响吗？（Gluster 到底是做什么的？）
答案1
GlusterFS 是否是跨 Autoscaling 组中的所有实例共享数据的好解决方案？
有可能。不过，获得明确答案的唯一方法是通过自己的测试。过去，我在 Linode 实例上设置了一个 4 节点 Web 服务器集群，使用 GlusterFS 分发/共享图像的资产目录等。
我们发现这种方法存在 2 个主要问题：
- GlusterFS 是相当 IO 密集型的，并且在无争用 IO 的硬件上运行良好
- 有时，Linode 服务器对后端 SAN 的访问效果会不太理想，IO 等待时间会急剧增加。发生这种情况时，Gluster 会在剩余节点之间复制更多数据，从而导致这些节点的 IO 性能受到影响。其结果是，由不理想的 SAN 配置或分时导致的轻微 IO 故障将意味着整个 Web 服务器集群将失效，并且整个共享文件系统可能变得不可用。
纯粹是轶事证据，但我不会再在具有 SAN/共享存储的虚拟机上运行 GlusterFS。
Gluster 能确保不会丢失数据吗？
它可以...在 Gluster 3.0 中，对“复制池”有了更好的识别，您可以在其中定义整个集群中存在多少份数据副本。将复制级别设置为 2，意味着整个集群中有 2 个副本。这实际上将您的存储容量减半，但意味着您对节点故障的恢复能力更强。
重要的是，这还意味着您必须添加更多节点作为复制级别的倍数，在本例中是节点对。
如果 Autoscaling 中的所有实例都终止，会发生什么情况，我会丢失用户数据吗？
如果实例仅使用临时实例存储，则可。如果它们基于 EBS，或使用已安装的 EBS 实例，则不可。
如果用户上传图像并且处理请求的服务器出现故障，会发生什么情况？
这很大程度上取决于你的应用程序是如何设计的。我强烈怀疑用户会丢失他们的数据（在一个架构简单的解决方案中几乎是肯定的）。
如果客户端宕机，会对 IO 产生影响吗？
参见上文。如果客户端由于后端存储问题而出现故障，则很容易完全破坏集群的性能。
答案2
GlusterFS 在上线新实例时似乎需要进行过多配置，以使其成为一个适用于需要自动扩展的实例的良好系统。我相信这是可以做到的，但更改架构更容易，这样 Web 实例就不同于 glusterfs 实例了。然后，Web 实例只需要作为客户端连接到 glusterfs 层。然后可以将 Web 实例设置为自动扩展。
处理云系统时的一个好规则是将服务与实例进行 1:1 映射。不要试图让一个实例做太多事情。从架构上讲，这有助于扩展事物。
答案3
您已经对 Gluster 问题得到了一些很好的答案，然而我想提一些可能有用的东西。
根据您的使用情况，您可能会发现以下内容更易于管理且更不容易出错：
- EC2 都是相同的，代码从存储库中提取以保持最新（您可以通过部署流程以多种方式进行管理）
- 任何用户上传的内容都会通过 s3fs 或集成到您的应用程序中的 API 调用（python/php 等）直接进入 S3
S3 的优点很明显：
- 只需为您使用的部分付费（无需支付 EC2 中大量未使用的资源、运行成本、通过多台机器进行复制等费用，也无需任何管理）
- S3 内置了冗余功能，因此您的文件在进入 S3 时是安全的（安全意味着它们处于托管服务中，位于全球多个位置。AWS 报告称他们从未在 S3 中丢失过文件）
如果您想更进一步，您可以配置您的（linux）服务器以将所有日志发送到“日志服务器”（这可以使所有 EC2 保持相同，尽可能简化）。
我发现这种设置在过去对于我管理的网络服务器来说运行得很好。