单个 NFS 服务器到冗余 NFS 存储

Vin*_*per 3 nfs kvm-virtualization

目前,我们有 6 台安装了 Proxmox VE 的物理主机。这些主机正在运行许多虚拟机。主要是 Windows Server 2008 R2。主机是具有中央 RAID5 存储的英特尔刀片服务器,可以访问英特尔共享 LUN。中央存储与其中一台刀片服务器物理连接,并包含 VM 的所有磁盘映像。VM 主机通过中央 NFS 存储访问这些虚拟机的磁盘映像。由于这个 NFS 主机只是一台机器,我们无意中创建了一个单点故障。例如,如果 NFS 主机由于某种原因无法启动,则所有 VM 都无法访问其磁盘映像,也不会运行。

主要问题是如何以及使用什么软件将这个 NFS 存储位置转换为一个冗余的、可能与另一个存储设备同步的存储设备,而不会对现有的 VM 磁盘映像造成任何损害。它可能是一个类似故障转移的系统,一个 NFS 主机被关闭,另一个 NFS 主机接管。消除这种 SPoF 的最佳解决方案是什么?

vor*_*aq7 6

冗余 NFS(实际上,任何冗余存储)都不是小事。
如果您真的希望它运行良好,请计划在这方面花费大量时间(和资金)。

通常有两种选择可供您选择:

选项 1:购买冗余存储设备

这是最快(通常也是最昂贵)的选择。选择一家生产具有冗余功能的存储设备以满足您的需求的供应商,给他们公司信用卡,并尽量不要在发票上留下眼泪。

这条路线的两个主要好处是它很快(你得到一个预先构建的解决方案,你可以按照手册推出)并且它是受支持的(如果你有问题,你打电话给供应商并大喊直到他们解决它)。


选项 2:自己构建

该站点对使用 Debian Linux 构建冗余 iSCSI/NFS 集群有一个很好的概述。这是从 2009 年开始的,但原则是合理的。
有关如何构建此类环境的具体分步说明超出了 Server Fault 的范围,但我可以粗略地概述一下您需要什么:

  • 共享(或复制)存储
    为了在存储层上实现冗余,您需要从多个位置访问相同的数据——要么实时复制,要么将所有内容连接到共享磁盘池。
    SAN 是满足共享存储要求的常用方法。这仍然是单点故障,但是当您将所有鸡蛋放入其中一个篮子时,您可以确保它是一个非常好的篮子。
    如果您选择走这条路线,DRBD 或 ZFS 复制可以满足复制存储的要求 - 它可能比 SAN 便宜,而且这两种技术都已发展到非常可靠的状态。
  • 多个“前端”系统
    既然您已经确定了存储,您需要通过冗余“前端”系统访问它——这些是运行 NFS 服务器的机器(或任何用于提供磁盘的机器)给客户)。
    您至少需要两个,运行高可用性/故障转移软件,以便如果/当您丢失一个时,另一个可以接管。IP 故障转移是这里的“简单”选项(如果一个框出现故障,另一个则假定为“实时”IP 地址)。
  • 存储的多条物理路径
    如果一切都通过一根电线,那么世界上所有的存储冗余都无济于事。
    您需要确保客户端机器有多个物理路径返回到存储前端,否则发生故障的交换机会让您面临与您试图摆脱的相同的单点故障情况。

构建您自己的冗余存储通常需要比供应商解决方案更长的时间,并且您自己支持它(这意味着您需要对所涉及的技术感到满意)。
主要优势是成本(您通常可以比供应商提供的解决方案更便宜地构建环境)和灵活性(您可以定制解决方案以满足您的需求并与您环境的其他部分集成 - 例如您的备份系统)。


你需要的东西

在投入生产之前,您需要一个测试计划*
理想情况下,您甚至应该在开始构建之前就拥有它(了解您要防御的故障将有助于您设计系统)。

您在测试中的目标是证明绝对最坏的故障汇合不会让您处于丢失数据的位置(理想情况下不会因为您的存储变得无法访问而导致中断)。
您可能无法找到或测试所有可能的故障场景,但请写下您能想到的所有故障场景,并确保对其进行测试。您不想等到第一天使用现场生产时才发现备用计算机中丢失一个磁盘会导致主计算机崩溃——到那时修复已经太晚了。