Re: [devel] подсистема настройки сети в дистрибутивах

["Alexey V. Vissarionov" <gremlin@altlinux.org>]

Good ${greeting_time}!

On 2024-04-18 18:04:24 +0300, Alexey Shabalin wrote:

 >>> - в рабочей станции и других дистрибутивах с GUI используют
 >>> NetworkManager
 >>> - в сервере есть попытка перехода на systemd-networkd (почему
 >>> поытка - ниже :). etcnet оставлен как запасной вариант.
 >> Все это - решения для рабочих станций. Ну, еще в совсем простых
 >> сетях можно для локальных серверов как-то что-то наколхозить.
 > На самом деле все сложное в сетях должно делаться на сетевом
 > оборудовании.

А у этого сетевого оборудования внутри волшебство происходит?

Не говоря уж о том, что по-настоящему большие сети используют
роут-серверы. А, наоборот, совсем маленькие - одиночные серверы,
на которых вообще все: и пара внешних каналов (с балансировкой
между ними), и несколько локальных сетей (как минимум проводную
сеть и WiFi сейчас принято разделять), и почта, и телефония, и
файлохранилище. И из сетевого оборудования у них - только свитчи.

 > А на сервера или рабочие станции сеть должна подаваться в
 > максимально простом виде. Для надежности.

Если не пытаться работать с ядерным сетевым стеком, как с демоном
в userspace, его надежность превосходит, например, надежность
дисковой подсистемы.

 > В "сложном" виде (bonding, тэгированные vlan) сеть подается
 > на хосты виртуализации или програмные маршрутизаторы.

Хосты виртуализации по определению выполняют функции софтроутеров.

А еще серверы умеют не только подключаться к существующим сетям,
но и создавать их.

 > Netplan умеет типовые простые и сложные сети. Понятно, что
 > можно найти особенный случай, который не поддерживается. Его
 > тоже можно решить pre и post хуками, запуская скрипты.

И вся красивая модель управления сетевым стеком через managed
configuration идет коту под хвост :-)

Я через эти грабли еще лет 15 назад прошел. И нашел рабочее
решение, которое с большой вероятностью (могу уточнить днем)
работает до сих пор.

 >> Конфигурация сети - это не демон, для нее reload|restart
 >> хоть и возможны технически, но особого смысла в абсолютном
 >> большинстве случаев не имеют.
 > У нас разные клиенты :) Кто-то настраивает сеть через
 > web-интерфейс PVE, и не ожидает, что нажав кнопку Apply
 > потеряет доступ к хосту. А теряет потому, что network
 > reload на самом деле restart.

Для десктопа (за консолью которого и работает пользователь)
это вполне приемлемо. А если использовать десктопную схему
конфигурации сети на сервере - ну что ж, любой инструмент,
используемый не по назначению, превращается в грабли.

 >>> Предложение: Давайте рассмотрим вариант использовать в
 >>> дистрибутивах netplan [...]
 >>> умеет настраивать bond, bridge, vlan,
 >> VLAN? Вот прямо с перенумерацией и QinQ?
 > да, networkd умеет, в том числе и 802.1ad

Даже любопытно посмотреть, как оно с нетривиальными случаями
перенумерации справится.

 >>> openvswitch, wireguard, wifi, тунели. Вроде все что нам
 >>> обычно нужно.
 >> Как насчет хотя бы VRF? :-)
 > Да. Смотри
 > https://github.com/canonical/netplan/blob/main/examples/vrf.yaml

Так это ж совсем примитив... Ладно, будем считать, что хотя бы
про ip rule оно знает.

 >>> Если перерабатывать alterator-eth, то может сразу на
 >>> использование netplan, который умеет генерировать настройки
 >>> для NM и networkd?
 >>> PS: я не призываю удалять etcnet из сизифа. Я говорю о
 >>> дистрибутивах, которые по факту уходят от использования etcnet.
 >> Для десктопов оно избыточно (еще больше, чем NM), для серверов
 >> малопригодно... что остается-то, ноутбуки?
 > А мне кажется пригодно для для всех трех случаев.

Вот-вот, "кажется". А я говорю (особенно про серверы) на основании
опыта промышленной эксплуатации. В том числе с обеспечением SLA.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net