用本地冗余分发网站文件

因此，我们正在考虑将我们的单个专用服务器（如共享虚拟主机设置）迁移到具有多个负载平衡前端服务器和独立数据库服务器（由于stream量增长和可用性问题）的体系结构。

TLDR; 当文件服务器出现故障时，我想要一些故障转移到站点文件的本地只读镜像。

场景：

大约200个虚拟主机，每个都有一些别名
每个站点基本上只有一个“包装器”，大约只有30个本地文件，大部分只是模板文件，其余的只是从一个集中的代码库
站点基本上是只读的，除了一个caching目录（可以在每个主机上分开）
没有第三方访问站点文件（即不共享）
每个网站只能获得2-10k次点击/月

目标/要求：

对任何单个服务器进行维护或由于错误而处于脱机状态时，都要具有适应性
定期进行less量文件更新的一些集中方式（手动，只是正常的站点更新），最好通过FTP
在最多5秒内将更改传播到前端服务器是可以接受的
如果一台服务器意外脱机，我会很高兴最多10分钟的文件更改丢失
在这个阶段，我们可能只会看到两台全时运行的前端服务器，另外还有一台文件服务器
可能会在AWS上实施
更多的前端服务器可能会定期添加和删除

我意识到一个典型的方法是通过版本控制进行部署，这是我们在某些情况下已经做的，但是我们的工作人员（非开发人员，主要pipe理横幅，文本更新等）非常适用于“FTP”工作stream程，我想改革，但也许还没有。

以下是我提出的解决scheme：

rsync部署

文件服务器承载可通过FTP访问的站点文件的“主”副本，并通过rsync服务器公开这些副本。我有某种“部署”接口触发每个前端服务器rsync站点和“部署”。

优点

很简单
在文件服务器上允许“暂存”版本，这可能是有用的
每个前端服务器都有自己的文件副本，如果文件服务器处于脱机状态，则不会有任何问题

缺点

有多可靠？
可能会混淆已部署的内容以及未部署的内容

NFS

具有本地caching的NFS文件服务器，定期rsync本地备份，然后可能通过将绑定的挂载点切换到本地备份进行故障转移。

优点

可能支持写作（不是必要的）
NFS在某种程度上更简单
除非发生停电，否则应始终保持同步

缺点

我不确定本地NFScaching的效果如何，以及是否会自动使修改对象的caching无效。没有本地cachingNFS很慢？
我非常确定，我需要一些心跳才能触发故障切换，并在主机恢复联机时挂载主机

Gluster等

我对这个选项并不是很熟悉，但是我相信当你拥有大量的服务器时，这是一种常见的方法。我看了一些文档，可能是合适的，但是我没有看到很多人推荐这么小规模的文档。

优点

会允许读写
支持caching我认为，应该比非cachingNFS更快？
自动复制，恢复和故障转移

缺点

我喜欢有一个可以快照和备份的单个“主”卷的想法，我不认为有一个选项可以在gluster中说“这个节点必须有一个完整的副本”。
有了这么小的服务器池，似乎你可能很容易意外地终止了两台服务器，而这两台服务器恰好有一些数据的副本

所以，我的问题是：

NFS真的是我唯一的select吗？
我应该考虑其他select吗？
这些选项中的哪一个最适合我的需求？

编辑：

感谢你们的回应，我开始意识到，考虑到我的需求规模（相对较小），我正在把事情变得太复杂。我认为在我的实例中正确的解决scheme是，我需要引入一个显式的“部署”事件，触发本地文件更新，醚从版本控制或其他来源。

虽然文件是定期更新的，但当分布在200个网站时，实际情况是大多数网站不太可能每月更新一次，所以有一种机制可以随时随地同步任何文件上的任意更改。

复杂的想法…但是你可能会过于复杂的事情。

想想这个。你的NFS服务器在什么情况下会“closures”？你想要保护什么样的失败模式？云托pipe服务提供商的存储和虚拟化平台是不是缓解了这些问题？

我是NFS的粉丝为此目的。请注意，通常情况下，裸机存储硬件具有足够的内部弹性来维持正常的故障。但是你正在计划一个云部署。

所以我想在集群化的NFS存储支持的Web服务器层前设置集群负载平衡器。 NFS存储需要向Web主机提供虚拟IP（VIP）。常用的方法是使用DRBD和Pacemaker ，但还有其他的select。

定期同步的备用NFS服务器可能是一个选项。

您可以将DNS名称用于您的NFS安装，并在您丢失主存储时利用Route 53 （手动或自动）更改IP目标。

一些想法。我倾向于避免用于Web解决scheme的完整集群文件系统，但它们也可以是选项。

在我处理的一个类似的安装中，我已经以每个Web服务器都有完整数据副本的方式进行了gluster安装。这意味着读取永远不需要通过networking，如果对我们来说是完美的 – 相当低的数据量与罕见的写入。

Volume Name: gv0 Type: Replicate Volume ID: 1f70af9d-4caa-4d2d-8dbd-feedfacebeef Status: Started Number of Bricks: 1 x 6 = 6 Transport-type: tcp Bricks: Brick1: server1:/export/glusterfs Brick2: server2:/export/glusterfs Brick3: server3:/export/glusterfs Brick4: server4:/export/glusterfs Brick5: server5:/export/glusterfs Brick6: server6:/export/glusterfs

听起来恰到好处！