S
если нет задачи впихнуть кучи всего на одну машину в условиях жесткой ограниченности ресурсов - юзай виртуалки
Size: a a a
2019 March 25
A
для сети В ПРИНЦИПЕ быстрее machinectl поднять
чет вообще хз, что это, гипервизор или оркестратор контейнеров?
S
чет вообще хз, что это, гипервизор или оркестратор контейнеров?
lxd нового пакаления
S
идет искоробки
S
с systemd
A
тебе максимально уплотнить железо или чо ваще?
ну задача маршрутизации - это ЦПУ задача и ядровая. В случае с гипервизором, оверхед на системные вызовы и виртуализацию инструкций процессора (да, хардварная, но далеко не бесплатная)
В контейнере же нет оверхеда на ЦПУ (юзается тот же планировщик задач, что и у хоста) и на ядро намного меньше оверхед, т.к. нету скачков между гостем, гипервизором и хостом
В контейнере же нет оверхеда на ЦПУ (юзается тот же планировщик задач, что и у хоста) и на ядро намного меньше оверхед, т.к. нету скачков между гостем, гипервизором и хостом
A
из чего я и логически делал вывод, что контейнер будет быстрее, но хуже изоляция
S
+
A
и я подумал, что таки пожертвую немного изоляцией ради поддерживаемости и стабильности (гори в аду, xen)
S
Возьми ты qemu и не мучайся.
A
а Ваньков (и Белко немного) ) мне тут объяснял, что я фатально ошибаюсь, и мне нужен kvm, который будет точно быстрее.
A
вот я и охреневал, как так? это ломает всю картину о контейнерах
S
вот я и охреневал, как так? это ломает всю картину о контейнерах
тут очччень зависит от задач
A
я сейчас только про мою задачу
S
и от типа контейзации
S
machinectl практически без оверхеда даст пробросить напрямую интерфейсы хардварные
A
lxc тоже умеет хардварные интерфейсы прокидывать
A
network.type = phys
S
но cgroups через которые емнип это всё работает так или иначе вносит оверхед
S
lxc тоже умеет хардварные интерфейсы прокидывать
забудь про lxc и lxd