我们正在考虑在 Amazon AWS 上托管一个 Web 应用程序。我已为其制定了建议的设置，我将尝试用几行来总结：
- Web 应用程序由负载均衡器后面的 3 个可用区域中的 Web 服务器提供服务。当负载增加时，Web 服务器会自动从 3 个扩展。这是通过运行一些 bash 命令的用户数据文件完成的。
- 数据库位于多可用区 RDS 解决方案中
- 因为应用程序写入文件系统，所以我们还需要在 webroot 上安装某种网络附加文件系统。
最后一点让我担心。我有一些 AWS 经验，除了处理两个可用区域之间的延迟之外，这还会带来单点故障。
因此，我一直在研究 GlusterFS，因为 serverfault 上的某个人向遇到类似问题的人建议了 GlusterFS。我一直在设置一个环境，每个可用区都有一个 Gluster 节点。在我的 Web 服务器的启动脚本中，我评估了它所在的可用区的名称，并选择了位于同一可用区的 Gluster 节点，以减少延迟。太完美了！
但是假设 AZ 中的节点以某种方式发生故障。如果 中的节点不可用us-east-1a，是否有办法让我的 Web 服务器us-east-1a回退到 中的节点？当然，如果两者都不可用，也可以？us-east-1bus-east-1aus-east-1c
到目前为止，我只见过有人在同一台机器上使用 Gluster 的服务器和客户端功能，我想避免这种情况。值得注意的是，出于性能原因，我将使用 NFS 客户端。
当然，对于该文件存储系统的任何其他建议都非常欢迎。
答案1
我想向感兴趣的人介绍我是如何决定这么做的。就像我说的，S3没有适合我们的情况，这也许是更多人正在努力解决的问题。
当时 Gluster 似乎是最佳选择，因为它专门用于执行这些操作。然而，在我们的测试环境中，Gluster 的速度阻碍了我们。是的，文件传输到 Gluster 文件系统非常快，但我们在这些已安装的卷上进行了大量查找和快速读写，当测试更高的负载时，它成为了瓶颈。Gluster NFS 客户端在这些操作上要快得多，但它不支持 Gluster 内置的容错功能。
因此，我们回到了最初的想法：简单地使用在另一个可用区中具有故障转移功能的 NFS 服务器。为了保持节点同步，我们使用DRBD。我们使用 VTun 解决了没有虚拟 IP 的问题（我非常乐意接受其他建议），并使用 Heartbeat 在主服务器关闭时提升从服务器。