如您所见，我的两个 Windows Server 故障转移群集 (WSFC) 节点各有三个网络接口，将它们连接到三个不同的网络：
- 公共网络
- 由 WSFC 节点组成的私有网络
- 由 WSFC 节点和具有 WSFC Quorum Witness 文件共享的计算机组成的专用网络
我计划的这个网络配置是否有意义？我是否拥有“正确”数量的 NIC 和网络？我认为第二个 NIC/网络可能是不必要的。
我的两个 MongoDB 副本集节点也各有三个网络接口——与之前的情况非常相似：
- 公共网络
- 由主要和次要 MongoDB 副本集节点组成的私有网络
- 由主要、次要和仲裁 MongoDB 副本集节点组成的专用网络
这个网络配置有意义吗？我是否拥有“正确”数量的 NIC 和网络？我认为第二个 NIC/网络可能是不必要的。
这是我正在考虑的更简单的版本：
更新：
这里有两个问题，一个是针对MS集群的，另一个是针对Mongo的。
聚类分析
将公共、心跳、节点间通信和仲裁驱动器放置在何处的决定非常重要。集群架构也有所不同；如果两个节点位于相邻的机架中，而不是它们位于完全不同的数据中心，则您可以选择不同的 quroum 选项。
将心跳放在与公共接口相同的接口/子网上
这个理论认为，如果你失去了你的公共接口，你希望心跳失败，因为这个节点实际上是对用户的。
将心跳放在它自己的私有接口/子网上
该理论认为集群外部的某些东西正在仲裁谁在做什么角色，并且要避免不必要的节点死亡。
将WFS放在心跳网络上
如果两个节点在同一个整体网络中（同一组交换机支持两个节点的非公共网络），那么将 WFS 放在心跳网络上不会引入任何新的漏洞。
如果两个节点位于不同的网络故障域（例如不同的数据中心），这是一个坏主意。心跳网络提供“节点多数”仲裁选项，WFS 提供“文件共享多数”仲裁选项。您确实希望这两个选项位于不同的故障域中。
如果两个节点都在同一个数据中心，那么您修改后的图表就有意义了，尽管我本人会在公共方面进行心跳。
数据库
MongoDB 稍微简单一些。对于偶数个节点，您绝对希望第三个节点充当决胜局。他们很清楚这一点。但是，您的图表说明：
7是奇数。你不需要仲裁者。
与 Microsoft 集群不同，Mongo 的集群投票不关心网络的多个途径来打破投票僵局。因此，单独的仲裁和集群内部网络不会提供任何有意义的稳健性增加。你想要一个单独的仲裁网络的唯一原因是，如果复制流量预计会非常大，以至于选举数据包（实际上是心跳）会被推到堆栈的下方，以至于它会错过 10 秒的超时时间。