В чем разница между настройками Tun / Tap против Bridge + Vnet и Macvtap? (Для виртуализации KVM)


28

Я только что нашел много разных способов создания сетей KVM. Но я застрял о том, как правильно это сделать. Я обнаружил, что openstack использует macvtap для создания нейтронных сетей. И это выглядит хорошо.

Но какая разница и зачем использовать каждый способ.

Способ 1 [СТАРЫЙ? TUN / TAP]

http://www.shakthimaan.com/installs/debian-tun-tap-setup.html

/--------\   /----\   /----\   /----\   /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/   \----/   \----/   \----/   \--------/

Устаревший, верно?

Способ 2 [Bridge + Vnet] <- это то, что делает virt-manager

http://www.linux-kvm.com/content/using-bridged-networking-virt-manager

В основном вы создаете мостовой интерфейс с вашим физическим интерфейсом внутри и

auto br0
#iface br0 inet dhcp
iface br0 inet static
address 172.16.0.100
network 172.16.0.0
netmask 255.255.0.0
broadcast 172.16.255.255
gateway 172.16.0.1
   bridge_ports eth2
   bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

И когда вы запускаете виртуальную машину из virt-manager, интерфейс vnet создается и добавляется к мосту. По крайней мере, до тех пор, пока я не знаю. Интерфейс TUN / TAP не требуется.

Долгое время это работало довольно хорошо, но теперь с дерзостью я обнаружил проблемы.

https://bugs.launchpad.net/ubuntu/+source/core-network/+bug/1255516

Почему вы можете добавить новый интерфейс vnet на мост без интерфейса TAP?

Способ 3 [MACVTAP]

Последний интерфейс Macvtap.

http://virt.kernelnewbies.org/MacVTap

Он копирует программный интерфейс TUN / TAP, но делает это лучше. Не знаю, каким образом, но, кажется, лучше.

В чем преимущество macvtap перед вторым способом?

Что лучше?

Любая помощь в этом?

Ответы:


4

Это действительно зависит от того, чего именно вы хотите достичь

  • TAP / TUN

Неважно, виртуальная машина или физическая машина. TUN приносит вам туннелированную сеть и TAP устройство. Короче говоря, вы проходите через туннельную сеть, чтобы связаться с другой сетью.

Например, при настройке сети OpenVPN вы получите 10.8.0.6 на своем клиенте. Сервер VPN 10.8.0.1 направляет ваш запрос в другую сеть (например, 192.168.xx) позади. При использовании TAP вы получите IP-адрес (192.168.10.10/24) непосредственно из вашей целевой сети (192.168.10.x / 24). Просто.

  • Мост

«Linux Bridge» соединяет VNET (от ВМ) до физического Ethernet. Если вам нужна виртуальная машина (на основе KVM), мост должен быть между vnet и ethernet на хосте


Ммммм. Спасибо за ответ, но это не решает мои сомнения. Если вы увидите ссылки, вы обнаружите, что есть больше причин использовать ту или иную. Фактически мост теперь не работает хорошо на текущем стеке Linux для VM. Поэтому мне пришлось использовать MACVTAP.
Гонсало Агилар Дельгадо

2

Я бы сказал, что это зависит от вашего варианта использования.

Автоматизированные добавления / удаления виртуальных хостов?

Попробуйте Macvtap. Он также должен быть более производительным, чем macvlan (что примерно соответствует добавлению другого MAC к физическому устройству, информация о котором поступает туда, обрабатывается сетевым стеком) или дополнительным мостом, поскольку macvtap каким-то образом обходит сетевой стек и напрямую экспортирует символьное устройство. Но не приставай ко мне. Помимо того, что оба (macvlan / macvtap) используют одни и те же доступные режимы (VEPA / шпилька, мостовой, приватный), шпилька работает только в том случае, если ваш коммутатор поддерживает режим отражательного реле. (Пакеты, поступающие на физический коммутатор через порт x, должны иметь возможность снова покинуть коммутатор через тот же порт x.)

Поскольку eth0 (или тот, который вы используете) переводится в смешанный режим при использовании моста, говорят, что режимы macvXXX имеют более высокую пропускную способность.

Режимы также определяют «количество» изоляции (могут ли vhosts видеть трафик друг друга? Как насчет hv?). Как это работает под капотом я пока не знаю.

veth (виртуальные пары Ethernet) несколько похожи для изоляции: вы определяете два виртуальных интерфейса: один подключается к мосту, другой - к вашей виртуальной машине. Там изоляция осуществляется путем помещения vm-интерфейса в собственное пространство имен, чтобы устройства были несколько изолированы. Весь трафик собирается на мосту, но один vhost не может видеть vNIC другого.

Если вы работаете с мостом, у вас есть дополнительные настройки, и когда мост не работает, все ваши подключения. При восстановлении моста вам, возможно, придется снова подключить все виртуальные интерфейсы к мосту (или просто перезагрузить полную версию hv ...).

Итог: если вы не часто меняете свою топологию, просто переходите к мостовому соединению, поскольку вы найдете в нем наибольшую информацию, что лучше, чем чтение кода ядра. Черт возьми, даже самому пакету iproute2-doc не хватает большей части информации, которую действительно имеет iproute2, даже когда вы запускаете новейшие версии. Попробуйте узнать об этом man ip-tcp_metricsиз доступных manpages или ip-crefs.ps ...


Я даже не помню, как писал это, тем более, где я нашел всю эту информацию. :(
sjas

0

Эти методы делают принципиально разные вещи. Чтобы понять почему, вам нужно понять многоуровневую модель сетевого взаимодействия. Для наших целей здесь важны слои 1, 2 и 3:

  • Уровень 1 является физическим уровнем - он определяет такие вещи, как то, какие кабели вы можете использовать, какие схемы напряжения / тока представляют 1 и 0 на этом кабеле, как устройства на каждом конце кабеля согласовывают, с какой скоростью передачи данных они работают, и так далее.
  • Уровень 2 является канальным уровнем - он определяет, какие языковые объекты на каждом конце кабеля общаются друг с другом. Устройства Ethernet на этом уровне имеют такие вещи, как кадры и MAC-адреса.
  • Уровень 3 - это сетевой уровень - он определяет, как устройства используют прямую связь уровня 2 с другим устройством для доступа к третьему устройству, к которому они не могут подключиться напрямую на уровне 2. Устройства на этом уровне имеют IP-адреса и таблицы маршрутизации.

MACVLAN / MACVTAP

MACVLAN создает виртуальный уровень 2 или устройство канального уровня со своим собственным MAC-адресом, который совместно использует уровень 1 или физический уровень с существующим устройством. Наиболее очевидно понятный случай, когда у вас есть устройство Ethernet, подключенное к сети, и вы создаете устройство MACVLAN на основе этого устройства Ethernet; Теперь у вас есть два Ethernet-устройства с разными MAC-адресами, но оба они передают свои кадры по одному и тому же кабелю. Я буду говорить о MACVTAP немного дальше.

Интерфейсы MACVLAN могут взаимодействовать несколькими различными способами с существующим интерфейсом Ethernet, в частности, когда на одном из интерфейсов появляется кадр, который адресован другому:

  • В приватном режиме рамка выбрасывается; два интерфейса не могут взаимодействовать друг с другом, только с внешними устройствами.
  • В режиме vepa кадр отправляется через физический уровень, как и любой другой кадр. Если у вас есть устройство, подключенное к коммутатору, который достаточно умен, чтобы определить, что кадр необходимо отправить обратно на тот же порт, на который он поступил, то он будет получен тем же физическим уровнем, который его отправил, а затем уровень 2 будет используйте MAC, чтобы отправить его на предполагаемый сетевой интерфейс.
  • В режиме моста , когда кадр появляется на одном устройстве, проверяется, предназначен ли он для другого, и если да, то он отправляется туда без прохождения уровня 1.
  • Есть также пара более неясных режимов.

Обратите внимание, что интерфейсы MACVLAN имеют важное ограничение: они не способны к изучению адресов. Таким образом, вы не можете соединить интерфейс MACVLAN со вторым физическим устройством и ожидать, что сможете подключиться к этому второму физическому устройству через первое. Это работает с исходным интерфейсом Ethernet, но не с подключенным к нему интерфейсом MACVLAN.

TUN / TAP

Интерфейс TAP также является новым виртуальным устройством уровня 2, но к нему не подключен уровень 1. Вместо этого программа может получить дескриптор файла, представляющий физический уровень. Затем он может записать необработанные данные кадра Ethernet в этот файловый дескриптор, и ядро ​​будет обрабатывать его как любой другой пакет Ethernet, полученный на реальном физическом интерфейсе.

Главное в интерфейсах TAP то, что физический уровень находится в режиме пользователя; любое программное обеспечение с соответствующими разрешениями может генерировать кадры Ethernet любым удобным для них способом и превращать их во что-то, что ядро ​​рассматривает так же, как реальный физический интерфейс. Это делает их очень полезными для таких вещей, как VPN и туннелирование; Вы можете написать любое программное обеспечение для туннелирования, которое вам нравится, в пространстве пользователя, и вам не нужно вмешиваться в пространство ядра, чтобы поместить кадры в сетевой стек, вы просто создаете устройство TAP и записываете кадры в его файловый дескриптор.

Устройства TUN аналогичны устройствам TAP, за исключением того, что они работают на уровне 3 вместо уровня 2, и программное обеспечение пользовательского режима должно записывать необработанные IP-пакеты в файловый дескриптор вместо необработанных кадров Ethernet.

Возвращаясь к устройствам MACVTAP , это своего рода смешение между интерфейсами MACVLAN и TAP. Как и интерфейсы TAP, программа пользовательского режима может получить дескриптор файла и записать в него необработанные кадры Ethernet. Подобно интерфейсу MACVLAN, эти кадры затем отправляются через физический уровень реального устройства Ethernet. Это позволяет вам легко адаптировать программное обеспечение, написанное для использования устройств TAP, вместо устройства MACVLAN.

VNET

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

Все они делают подобные вещи, но имеют немного разные возможности. Все они могут быть использованы для подключения виртуальной машины к сети Ethernet:

  • Продукт виртуализации может взять кадры Ethernet у гостя и записать их в дескриптор файла для устройства TAP. Этому устройству TAP может быть назначен его собственный IP-адрес, или оно может быть подчинено мосту вместе с интерфейсом Ethernet для совместного использования IP-адреса хоста, или iptables может быть настроен для пересылки трафика по нему с помощью NAT.
  • Продукт виртуализации может, что Ethernet кадры от гостя и записать их в дескриптор файла для устройства MACVTAP; затем они передаются непосредственно на физический уровень устройства Ethernet, фактически давая виртуальной машине «реальное» устройство Ethernet (хотя обратите внимание, что можно создавать устройства MACVLAN / MACVTAP для других типов сетевых интерфейсов, таких как мосты).
  • Продукт виртуализации может подключить драйвер virtio в гостевой системе к драйверу virtio в хосте для очень эффективной работы в сети.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.