Вопрос или проблема
Контекст: Я настраиваю кластер Proxmox, в котором каждый узел имеет двойные сетевые карты SFP+. Я пытаюсь устранить сеть как единую точку отказа, чтобы, если один из коммутаторов выйдет из строя, весь кластер не упал. Я думаю, что самым простым решением было бы настроить MLAG, но я обнаруживаю, что цены на коммутаторы и потребление энергии непрактичны (плюс у меня уже есть несколько коммутаторов SFP+, которые просто не поддерживают MLAG).
Предлагаемое решение: В настоящее время я думаю, что могу разделить свою сеть на две части, каждый сегмент/подсеть в основном используя одну из связей в сетевой карте, и переходя на другую, если связь/коммутатор выйдут из строя. Очевидный недостаток заключается в том, что я теряю половину теоретической пропускной способности, когда оба коммутатора/связи работают, но меня это устраивает, так как Proxmox рекомендует выделенную сеть 10G+ для Ceph.
Реализация: Мой план состоит в том, чтобы настроить два канала на каждом узле – один используя “связь 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
Ответ или решение
Тема использования двух соединений на одних и тех же линках с разными первичными соединениями в контексте настройки кластера Proxmox вызывает ряд вопросов. Рассмотрим предложенное вами решение более подробно, а также укажем на его преимущества и недостатки.
Основные аспекты проблемы
Ваша цель — избежать потери связи в кластере, если один из свитчей выходит из строя. Вы предложили разделить сеть на два сегмента, используя разные интерфейсы для разных типов трафика и создавая резервирование для каждого из соединений.
Подход к решению
-
Два канала (bond) на каждый узел: Вы предлагаете настроить два канала на каждом узле, каждый из которых будет использовать один из доступных интерфейсов как первичный. В случае сбоя одного из интерфейсов трафик будет перераспределен через другой интерфейс.
-
Режим работы канала: Вы выбрали режим
active-backup, при котором только одно соединение активно, в то время как второе находится в резерве. Это разумный выбор, учитывая вашу цель повысить доступность.
Преимущества вашего подхода
- Резервирование: Использование двух каналов позволяет создавать слой защиты от сбоев. Если один свитч или линк выходит из строя, другой будет использоваться для передачи трафика.
- Разделение трафика: Разделение сетевых потоков позволяет оптимизировать использование ресурсов и повысить производительность при наличии активных соединений.
- Простота реализации: Учитывая вашу конфигурацию и тестирование в виртуальной среде, реализация данного подхода не требует значительных дополнительных затрат.
Возможные недостатки и риски
-
Потеря пропускной способности: Основным недостатком является снижение потенциальной пропускной способности сети во время нормальной работы, поскольку трафик, происходящий через оба канала, не суммируется.
-
Сложность администрирования: Две дополнительные конфигурации могут усложнить администрирование и устранение неполадок в будущем. Это может быть важным фактором, если вы не планируете выделять много времени на управление сетью.
-
Отсутствие полной избыточности: Если каждый из ваших соединений зависит от нижестоящих элементов (например, свитчей), остается риск того, что отказ другого элемента может привести к отключению. Убедитесь, что у вас достаточная избыточность на уровне свитчей.
Рекомендации
-
Тестирование Failover: Проверьте, как ваша система будет реагировать на сбои. Убедитесь, что автоматическое переключение работает корректно и не вызывает неожиданных проблем.
-
Мониторинг и алерты: Внедрите систему мониторинга, которая будет отслеживать состояние каналов и обеспечивать вас уведомлениями о любых сбоях.
-
Документация и обучение: Обеспечьте полное документирование конфигурации сети и обучение вашей команды для успешного управления и устранения неполадок.
Заключение
Ваша идея не является ужасной, однако требует осознанного подхода к реализации. Учитывая потенциальные риски и недостатки, важно тщательно тестировать и мониторить сеть, чтобы гарантировать необходимую степень надежности. С правильной реализацией ваш план сможет обеспечить более высокую доступность и надежность вашего кластера Proxmox.