☰

使用本地冗余分发网站文件

tag-icon • tag-icon web-server nfs rsync glusterfs
使用本地冗余分发网站文件

因此，我们正在考虑将单个专用服务器（像共享网络托管一样设置）迁移到具有多个负载平衡前端服务器和单独数据库服务器的架构（由于流量增长和可用性问题）。

TLDR；当文件服务器出现故障时，我希望有某种方式将故障转移到站点文件的本地只读镜像。

场景：

  • 大约 200 个虚拟主机，每个都有一些别名
  • 每个站点基本上只是一个包含约 30 个本地文件的“包装器”，其中大部分只是模板文件，其余的只是来自集中式代码库
  • 网站基本上是只读的，除了缓存目录（可以在每个主机上分开）
  • 第三方无法访问网站文件（即不共享）
  • 每个网站每月的点击量只有 2-10k

目标/要求：

  • 能够适应任何单个服务器因维护或错误而下线的情况
  • 以某种集中的方式定期（手动，只是正常的站点更新）进行少量文件更新，最好通过 FTP
  • 将更改传播到前端服务器最多需要 5 秒，这是可以接受的
  • 如果服务器意外离线，我很乐意接受最多 10 分钟的文件更改丢失
  • 在这个阶段，我们可能只会考虑 2 个全天运行的前端服务器，外加一个文件服务器
  • 可能会在 AWS 上实施
  • 可能会定期添加和删除更多前端服务器

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

以下是我想到的解决方案：

rsync 部署

文件服务器托管可通过 FTP 访问的站点文件的“主”副本，并通过 rsync 服务器公开这些副本。我有某种“部署”界面，可触发每个前端服务器 rsync 站点并“部署它”。

优点

  • 相当简单
  • 允许在文件服务器上使用可能有用的“暂存”版本
  • 每个前端服务器都有自己的文件副本，因此文件服务器离线也不会有问题

缺点

  • 有多可靠？
  • 可能会对已部署的内容和未部署的内容产生混淆

NFS

具有本地缓存​​的 NFS 文件服务器，定期 rsync 本地备份，然后通过切换绑定的挂载点到本地备份来实现故障转移。

优点

  • 可能支持书写（不是那么必要）
  • NFS 在某些方面更简单
  • 除非发生中断，否则它们应该始终保持同步

缺点

  • 我不确定本地 NFS 缓存的效果如何，以及它是否会自动使修改对象的缓存失效。如果没有本地缓存​​，NFS 会很慢吗？
  • 我确信我需要某种心跳来触发故障转移，并在主服务器恢复在线时挂载它

Gluster 等

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

优点

  • 允许读写
  • 我认为支持缓存，应该比非缓存的 NFS 更快？
  • 自动复制、恢复和故障转移

缺点

  • 我喜欢拥有一个可以快照和备份的单一“主”卷的想法，我不认为在 gluster 中有说“这个节点必须有一个完整的副本”的选项吗？
  • 由于服务器池规模如此之小，似乎很容易意外终止两台恰好拥有某些数据的唯一副本的服务器

所以，我的问题是：

  • NFS 真的是我唯一的选择吗？
  • 我还应该考虑其他选择吗？
  • 这些选项中是否有最适合我的需求的？

编辑：

谢谢大家的回复，我开始意识到，考虑到我的需求（相对较小），我把事情搞得太复杂了。我认为我的情况中的正确解决方案是，我需要引入一个明确的“部署”事件，以触发本地文件更新，无论是来自版本控制还是其他来源。

尽管文件会定期更新，但当分布在约 200 个站点时，实际情况是大多数站点不太可能每月更新超过一次，因此似乎没有必要建立一种随时同步任何文件上任何任意更改的机制。

答案1

复杂的想法...但是你可能把事情复杂化了。

想想看。在什么情况下您的 NFS 服务器会“宕机”？您试图防范哪种特定的故障模式？云托管提供商的存储和虚拟化平台是否能缓解其中一些问题？

就此目的而言，我非常喜欢 NFS。请注意，这通常使用裸机存储硬件，这种硬件具有足够的内部弹性来承受正常故障。但您正在计划云部署。

因此，我设想在 Web 服务器层前面部署集群负载平衡器，由集群 NFS 存储提供支持。NFS 存储需要提供虚拟 IP (VIP)到网络主机。一种常见的方法是使用DRBD和起搏器，但还有其他选择。

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

您可以使用 DNS 名称来挂载 NFS 并利用53 号公路（手动或自动地）在丢失主存储时更改 IP 目标。

一些想法。我倾向于避免在 Web 解决方案中使用全集群文件系统，但它们也可以作为选择。

答案2

在我处理的一个类似安装中，我以每台 Web 服务器都拥有完整数据副本的方式设置了 gluster。这意味着读取操作永远不必通过网络，并且对我们来说非常完美 - 数据量相当低，写入操作不频繁。

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

听起来不错！

相关内容