背景：我正在设置一个 Proxmox 集群，其中每个节点都有双 SFP+ NIC。我试图消除网络作为单点故障，这样如果交换机发生故障，整个集群就不会发生故障。我认为最简单的解决方案是设置 MLAG，但我发现交换机价格和功耗不切实际（而且我已经有几个 SFP+ 交换机，它们不支持 MLAG）。
建议的解决方案：我目前考虑将我的网络分成两部分，每个段/子网主要使用 NIC 中的一条链路，如果一条链路/交换机发生故障，则故障转移到另一条链路。明显的缺点是，当两个交换机/链路都启动时，我会损失一半的理论带宽，但我对此没意见，因为 proxmox 无论如何都建议为 ceph 使用专用的 10G+ 网络。
实施：我的计划是在每个节点上设置两个绑定 – 一个使用“链接 0”作为主链接，另一个使用“链接 1”。当一切正常时，ceph 将使用一个链接，所有其他流量将使用另一个链接。如果其中一个发生故障，则两者共享一个链接，直到一切恢复。接口文件如下所示。我在虚拟机中测试了它，它似乎运行良好。
我是不是漏掉了什么？这个想法很糟糕吗？
allow-hotplug ens192
iface ens192 inet manual
allow-hotplug ens224
iface ens224 inet manual
auto br0
iface br0 inet manual
bridge-ports ens192
bridge-stp enable
address-virtual 00:0c:29:be:48:93
address-virtual 00:0c:29:be:48:94
auto br1
iface br1 inet manual
bridge-ports ens224
bridge-stp enable
address-virtual 00:0c:29:be:48:95
address-virtual 00:0c:29:be:48:96
auto bond0
iface bond0 inet dhcp
bond-slaves br0-v0 br1-v0
bond-mode active-backup
bond-miimon 100
bond-primary br0-v0
auto bond1
iface bond1 inet dhcp
bond-slaves br1-v1 br0-v1
bond-mode active-backup
bond-miimon 100
bond-primary br1-v1
allow-hotplug ens192
iface ens192 inet manual
allow-hotplug ens224
iface ens224 inet manual
auto br0
iface br0 inet manual
bridge-ports ens192
bridge-stp enable
address-virtual 00:0c:29:be:48:93
address-virtual 00:0c:29:be:48:94
auto br1
iface br1 inet manual
bridge-ports ens224
bridge-stp enable
address-virtual 00:0c:29:be:48:95
address-virtual 00:0c:29:be:48:96
auto bond0
iface bond0 inet dhcp
bond-slaves br0-v0 br1-v0
bond-mode active-backup
bond-miimon 100
bond-primary br0-v0
auto bond1
iface bond1 inet dhcp
bond-slaves br1-v1 br0-v1
bond-mode active-backup
bond-miimon 100
bond-primary br1-v1
—
user@test:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
link/ether 00:0c:29:be:48:85 brd ff:ff:ff:ff:ff:ff
altname enp11s0
3: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UP group default qlen 1000
link/ether 00:0c:29:be:48:8f brd ff:ff:ff:ff:ff:ff
altname enp19s0
23: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 1e:64:8c:83:4e:e0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::1c64:8cff:fe83:4ee0/64 scope link
valid_lft forever preferred_lft forever
24: br0-v0@br0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond0 state UP group default qlen 1000
link/ether 00:0c:29:be:48:93 brd ff:ff:ff:ff:ff:ff
25: br0-v1@br0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond1 state UP group default qlen 1000
link/ether 00:0c:29:be:48:96 brd ff:ff:ff:ff:ff:ff
26: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 62:58:ea:0a:19:86 brd ff:ff:ff:ff:ff:ff
inet6 fe80::6058:eaff:fe0a:1986/64 scope link
valid_lft forever preferred_lft forever
27: br1-v0@br1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond0 state UP group default qlen 1000
link/ether 00:0c:29:be:48:93 brd ff:ff:ff:ff:ff:ff
28: br1-v1@br1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond1 state UP group default qlen 1000
link/ether 00:0c:29:be:48:96 brd ff:ff:ff:ff:ff:ff
33: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:be:48:96 brd ff:ff:ff:ff:ff:ff
inet 10.7.7.192/24 brd 10.7.7.255 scope global dynamic bond1
valid_lft 45138sec preferred_lft 45138sec
inet6 fe80::20c:29ff:febe:4896/64 scope link
valid_lft forever preferred_lft forever
34: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:be:48:93 brd ff:ff:ff:ff:ff:ff
inet 10.7.7.194/24 brd 10.7.7.255 scope global dynamic bond0
valid_lft 48026sec preferred_lft 48026sec
inet6 fe80::20c:29ff:febe:4893/64 scope link
valid_lft forever preferred_lft forever
最佳答案
1
这是一个糟糕的想法。您的所有绑定都不会看到物理链路已关闭或拥塞，因此它不会稳定。此外，一个绑定将接收来自另一个绑定的广播消息。
即使您想使用两个绑定，也不要使用网桥“将 NIC 分成两个”（或更多），而是使用 SR-IOV（它们称为 VF，即虚拟功能）创建虚拟 NIC 并绑定它们。这应该会更好。但它仍然无法最终阻止这种情况，我认为这是最有可能的故障模式：
如果您担心集群的弹性，请购买合适的交换机。没有办法解决这个问题。Mikrotik CRS 并不昂贵，而且它们支持 MLAG 等。
Proxmox 自己的建议是使用 4 个甚至 6 个专用 NIC：两个用于集群通信，两个用于存储网络，两个用于 VM 网络。
另一种方法是使用单个绑定和单个桥接，但使用多个 VLAN 和 mstpd，并创建两个 MSTI，一个用于 CEPH 和迁移网络（例如高流量），默认情况下通过一个 NIC，另一个用于主集群环以确保最低延迟。不过从未尝试过这个。
此外，Proxmox 还提供了一种即使一个网络中断也能维持集群消息传递的方法，并且无需任何绑定：Corosync（集群构建的基础）允许，因此您可以将一个 NIC 分配给一个环，将另一个 NIC 分配给另一个环，拥有两个网络，即使其中一个网络中断，集群仍将保持法定人数。
|
|