ovs внутренний порт/veth пар ограничение полосы пропускания

Question

Я делал некоторые эксперименты на ovs в эти дни. У меня есть 2 физических машины с открытым стеком, и туннель GRE настроен. Я добавляю 2 внутренних порта на br-int (мост интеграции) каждой машины и назначаю их в другое пространство имен (ns1, ns2, ns3, ns4) и ip из той же подсети (172.16.0.200,172.16.0.201,172.16.0.202,172.16 .0.203). После завершения настройки VM (в той же подсети) < -> виртуальные порты, виртуальный порт < -> виртуальный порт на одном и том же/разных узлах доступен (используйте ping для проверки). Тем не менее, странно, что проявляется: я использовал Iperf для тестирования пропускной способности, тестируя результат показывает, как следующее:

1. Физический узел < -> Физический узел: 1 Гб/с
2. В.М. < -> VM на одном компьютере : 10 Гбит/с
3. В.М. < -> VM на разных машинах: 1 Гб/с
4. VM < -> Виртуальный порт той же машине: 10 Гбит/с
5. VM < -> Виртуальный порт разные машины: 1 Гб/с
6. Виртуальный порт < -> Виртуальный порт той же машине:
7. Виртуальный порт 16 ГБ/с < -> Виртуальный порт разные машины: 100 ~ 200kb/s (WEIRD!)

Я попытался заменить внутренний порт с парами veth, такое же поведение появляется. Как я ожидаю, пара veth должна вести себя аналогично виртуальной машине, потому что у них есть отдельное пространство имен, а openstack VM использует тот же самый способ (пары Veth) для подключения к br-int. Но эксперимент показывает, что виртуальный порт (node1) -> Virtual port (node2) имеет ширину 1 ГБ/с, но виртуальный порт (node1) -> виртуальный порт (node2) имеет только 100 кбит/с? У кого-нибудь есть идея?

Благодарим за помощь.

Answer 1

При использовании GRE (или VXLAN или другой сети наложения) вам необходимо убедиться, что MTU внутри ваших виртуальных машин меньше, чем MTU ваших физических интерфейсов. Заголовок GRE/VXLAN/etc добавляет байты к исходящим пакетам, что означает, что пакет размера MTU, поступающий с виртуальной машины, будет больше MTU ваших интерфейсов хоста, что приведет к фрагментации и низкой производительности.

Это описано, например, here:

туннельные протоколы, такие как GRE включать в себя дополнительные заголовки пакетов, которые увеличивают накладные расходы и уменьшить пространство, доступное для полезной нагрузки или пользователя данных. Без знания инфраструктуры виртуальной сети, экземпляры пытаются отправить пакеты с использованием по умолчанию Ethernet максимум блок передачи (MTU) 1500 байт. Сети интернет-протокола (IP) содержат механизм MTU обнаружения пути (PMTUD) для обнаружения сквозного MTU и соответственно изменяют размер пакета. Однако некоторые системы и сети блокируют или иным образом не поддерживают поддержку PMTUD, вызывающие ухудшение производительности или сбоев подключения.

В идеале вы можете предотвратить эти проблемы, включив jumbo frames на физической сети, содержащей виртуальные сети арендатора.Jumbo поддерживает MTU до приблизительно 9000 байт, что отрицает влияние накладных расходов GRE на виртуальные сети. Однако многим сетевым устройствам нет поддержки для больших фреймов, а администраторы OpenStack часто не имеют контроля над сетевой инфраструктурой. Учитывая последние проблемы , вы также можете предотвратить проблемы с MTU, уменьшив MTU экземпляра , чтобы учесть накладные расходы GRE. Определение правильного значения MTU часто требует экспериментов, но 1454 байта работает в большинстве сред . Вы можете настроить DHCP-сервер, который назначает IP-адреса вашим экземплярам, ​​чтобы также настроить MTU.