我对 Hyper-V 下的文件服务器群集感到束手无策。我希望有人能帮助我解决这个看似死胡同的技术难题（例如，强制群集虚拟机使用 iSCSI 驱动器，而通常连接的 VHDX 驱动器就足够了），而逻辑和理性通常会提供合乎逻辑的解决方案。
我的硬件：
我将要最终将运行三台服务器，但现在一切都在一台服务器上进行。其中一台辅助服务器将纯粹作为见证/仲裁服务器存在，另一台功能稍强的服务器将充当紧急备份（具有额外的存储空间，但不是冗余的），以容纳辅助 AD VM 和一组群集 VM 的另一半：SQL VM 和文件系统 VM。请注意，这些都是群集的折旧节点，主节点将位于功能最强大的第一台机器上。
我的重型升降机是一台机器，它还包含网络上所有真正的冗余存储。如果这让任何人感到毛骨悚然，那就太糟糕了。它有一个 6TB（可用）RAID-10 阵列，并且（最终）将容纳上述两个集群的主要节点，但现在正在容纳全部VM。目前是：DC01、DC02、SQL01、SQL02、FS01 和 FS02。最终，我将添加其他 VM 来处理 Exchange、Sharepoint 和 Lync，但仅限于此主服务器（辅助服务器无法处理超过三或四台 VM，所以为什么要增加它的负担？AD、SQL 和 FS VM 对业务来说是最重要的）。
如果有人现在说：“等等，文件服务器用 SAN 或 NAS 怎么样？”那太糟糕了。主机上存在的东西就是我必须处理的。
我跟着这些说明，但我似乎无法让事情正常运转。为了使文件服务器真正冗余，我不能相信任何一台机器保存网络上唯一的数据存储。因此，我在主机的 VM 主机上创建了一组 iSCSI 驱动器，并将一个驱动器连接到每个文件服务器 VM。最终结果是，我希望我的 FS01 及其 iSCSI“驱动器”位于重型升降机上，而 FS02 将位于辅助机器上，那里也有自己的 iSCSI“驱动器”。也就是说，两个 iSCSI 驱动器都不会与另一个驱动器位于同一台机器上。因此，集群 FS 将完全复制彼此之间的 iSCSI 驱动器的内容，这样如果一台物理机器（或 FS VM）出现故障，另一台物理机器将在其自己的 iSCSI 驱动器上获得完整的数据副本。
当我尝试在故障转移群集管理器中应用文件服务器角色时，就会出现问题。实际上，问题甚至更早出现——添加磁盘时就会出现问题。由于我已将每个磁盘优先添加到特定 VM（通过 DNS 主机名限制启动器，并添加双向 CHAP 身份验证），因此会强制每个 VM 控制自己的 iSCSI 磁盘。但是，当我尝试将磁盘添加到故障转移群集管理器中存储的磁盘部分时，整个过程会因该对中的随机磁盘而失败。也就是说，一个磁盘将联机，但另一个磁盘将保持脱机状态，因为它没有正确的“所有者节点”。我的意思是，真的——WTF？当然它没有正确的所有者节点，两个驱动器都显示相同的节点名称！！我似乎无法让一个驱动器以一个节点名称显示为所有者，而另一个驱动器以另一个节点名称显示为所有者。而且由于两个驱动器都不“联机”，我无法创建池以应用于群集角色。这真是进退维谷！
我还有很多东西要补充，但我今天要下班了，我得把事情收拾一下。我会在明天早上上班时尽量补充更多内容。
我的主要目标是在每台机器上安装一个文件服务器虚拟机，在每台机器上安装存储，但当一台物理机器发生故障时，可以进行透明的故障转移。本质上，故障转移文件系统不关心哪台机器发生故障——存储内容在每台机器上均等复制。我是否朝着正确的方向前进？
答案1
你感到沮丧的原因是因为你试图做一些你不应该做的事情。
你说
如果现在有人说，“等等，文件服务器使用 SAN 或 NAS 怎么样？”，那太糟糕了。
你说得对。可惜你。
你尝试做的事情无法正常工作。群集磁盘必须是相同的集群成员之间共享磁盘。您无法制作单独的磁盘，以某种方式复制数据，并将其用作集群卷。它不是那样工作的。这就是为什么集群磁盘通常位于 SAN 而不是本地存储上的原因。
与集群相比，使用 DFS 复制和命名空间可能更好。它与集群略有不同，但如果您需要使用单独的磁盘，因为您没有合适的共享存储，那么它是最好的选择。
补充说明：
这样，集群 FS 将在彼此之间完全复制 iSCSI 驱动器的内容，这样如果一台物理机器（或 FS VM）出现故障，另一台物理机器就会在其自己的 iSCSI 驱动器上获得数据的完整副本。
这不是集群的工作方式。你不能这样做。
我似乎无法让一个驱动器以一个节点名称显示为所有者，而另一个驱动器以另一个节点名称显示为所有者。
再次强调 - 因为这不是它的工作原理。如果您尝试将磁盘添加到群集，则应该在群集之间共享集群中的所有节点。这就是它的工作原理。这是尝试向所有成员都无法看到的集群添加磁盘的预期结果。
我的主要目标是在每台机器上都有一个文件服务器虚拟机，在每台机器上都有存储，但如果一台物理机器出现故障，则可以进行透明的故障转移。
如果您希望每台机器都有独立的存储，那么您就不需要集群。您最好使用 DFS 命名空间和复制。它与集群不同，但对于简单的文件服务需求，您通常可以实现类似的结果。
我强烈建议您阅读Windows 故障转移群集在尝试做其他任何事情之前，请先阅读文档。
答案2
您链接的文章将一台服务器设置为 iSCSI 目标，两台 Hyper-V 服务器都连接到该目标以进行共享存储（您没注意到吗？）。这意味着，它充当 NAS/SAN 类设备，并提供共享存储，其他两台主机都连接到该共享存储进行存储。您尝试执行的操作完全不同。
..我是否朝着正确的方向前进？
坦白说，没有。
正如 MDMarra 所建议的，DFS 是我会考虑实现这一目标的技术。如果您希望 Exchange 也采用同样的技术，那么您可以为数据库设置 DAG，为 CAS 服务器设置 CAS 阵列。对于 SQL 2012，您可以考虑 SQL Always On。
这些技术是专门为这些目的而构建的，并且都不依赖于 Hyper-V。如果您想在所有这些方面利用 Hyper-V，我建议您查看 2012 年的 Hyper-V 副本。它不一定为您提供自动故障转移，但它会创建您认为需要的数据的冗余副本。
编辑：所有这些事情都是在你的最后一个问题。
edit2：如果你不能忍受 DFS 的限制，并且想要在 Hyper-V 中或之外设置文件服务器集群，请阅读集群要求这样做。特别要注意存储部分，它以“您必须使用共享存储”开头。您正在设置的不是共享存储。