Трафик и так и так не ходил через роутер а замыкался на бридже.
Тут рекомендуется почитать вот эту тему, особенно последние комментарии по cgroups
LXC
Если кратко, то петля TrueNAS → PVE NFS → PBS MP на самом деле не является петлей.
С точки зрения процессора и операционной системы NFS шара на PVE хосте становится доступной PBS практически без каких-либо накладных расходов, для нее просто предоставляется доступ процессам внутри PBS без виртуализации и прочих вещей т.к. процесс LXC контейнера работает на хосте PVE, а устройства внутри LXC контейнера являются устройствами хоста
При этом мы используем общий файловый кеш на уровне хоста, общий драйвер NFS на уровне ядра ОС и на минимальном уровне изоляции ЦП
VM
Когда мы говорим про TrueNAS → PBS VM → NFS, то вроде бы петли нет, но…
Мы имеем петлю на уровне гипервизора т.к. NFS шару все равно обслуживает процессор хоста, но внутри виртуального окружения, модули ядра PBS все равно находятся на определенном уровне изоляции ЦП, путь это и не так критично в последнее время за счет использования паравиртуализации
При этом, файловый кеш тоже виртуализируется, без балунинга использование оперативной памяти и кэша становится не столь эффективным
А обработчик работы с сетью находится внутри планировщика виртуалки, которая внутри планировщика хоста, получается этакая матрешка
Условно
Можно представить оперативную память и файловый кеш в виде футбольного поля и футболилстов
В случае NFS шары на хосте мы получаем в наше распоряжение все поле и игроки могут перемещаться без ограничений по всему полю, если где-то надо усилить давление, то остальные участки можно освободить и все силы перебросить в одну точку, например, процесс бэкапирования или валидации архива.
В случае с виртуалкой и выключеным балунингом мы получаем футбольное поле, где игроки могут двигаться строго в отведенных для них участках, например, как в настольном футболе. Пока одни игроки отдуваются по полной другие будут ходить в своей зоне и ждать мяча. Например, выделили 2ГБ для PBS и он пытается тасовать там чанки резервных копий в то время, как Helper Scripts Local со своими 2ГБ оперативки загрузил все скрипты в свой файловый кеш и тако ждет когда же вы откроете его страницу для установки очередного сервиса и будет держать у себя этот файловый кеш все доступное ему время и его вообще не волнуют проблемы других виртуалок.
Но как можно понять из этой многоходовочки: VM дает пусть и худшие результаты, зато предсказуемые т.к. если для виртуалки были выделены ресурсы, то она сама распоряжается ими и когда понадобится выполнить запрос в БД этот запрос выполнится за предсказуемое время т.к. данные загружены в оперативную память. С LXC/OpenVZ может оказаться так, что платим мы за 2 ядра 2 гига, а по факту, другой контейнер выгрузил нашу БД из памяти и пытается съесть весть процессор.
Собственно, поэтому раньше OpenVZ виртуалки были дешевые, а KVM/Xen раза в 1.5/2 дороже, но потом все хостинги перешли на KVM именно по причине нормальной изоляции и гарантированных ресурсов без падений (надо понимать, что оверсеинг ресурсов имеет место быть, но с процессором это легче и решается “тротлингом”, а с оперативкой получаем уже не тормоза а OOM ошибки и негатив от клиентов)
Фух, что-то я разогнался…