Назад | Перейти на главную страницу

VSwitch перепутал с виртуальными машинами в одной подсети, но в разных VLAN

В мультитенантной виртуализированной среде LAN вполне вероятно, что разные клиенты будут иметь виртуальные машины в одной подсети (например, 192.168.1.0/24) и размещаться в одной среде виртуального сервера. Перекрывающиеся подсети не являются проблемой для клиентов, потому что им не нужно общаться друг с другом. Но когда эти серверы виртуализированы в одной и той же среде виртуальных серверов (например, Vmware или Sparc), они больше не могут отправлять трафик по сети, даже если два сервера находятся в разных VLAN (виден только первоначальный запрос ARP). Я ожидал, что разделение VLAN позволит VSwitch обрабатывать трафик для каждой виртуальной машины отдельно, несмотря на перекрытие. Физический коммутатор делает это, рассматривая каждую VLAN как отдельный домен уровня 2 и не использует информацию заголовка IP при принятии решения о пересылке. Однако должно быть что-то (возможно, определенное в стандартах), что заставляет VSwitch игнорировать различные VLAN в своем решении о пересылке и вместо этого проверять IP-заголовок и делать ложное предположение, что он может удовлетворить требования к подключению путем локального переключения. Кто-нибудь знает, есть ли основанная на стандартах причина, по которой это происходит, или имеет опыт такой ситуации и выявил основную причину?

«В мультитенантной виртуализированной среде LAN вполне вероятно, что разные клиенты будут иметь виртуальные машины в одной подсети»

Только если это неправильно спроектировано, построено и закреплено, с какой стати кто-то может допустить это?

«и размещаться в единой виртуальной серверной среде»

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

Но когда эти серверы виртуализированы в одной и той же среде виртуального сервера (например, Vmware или Sparc), они больше не могут отправлять трафик по сети, даже если два сервера находятся в разных VLAN (виден только первоначальный запрос ARP).

Опять же, это могло быть только в том случае, если система была спроектирована, построена или закреплена неправильно.

Я ожидал, что разделение VLAN позволит VSwitch обрабатывать трафик для каждой виртуальной машины отдельно, несмотря на перекрытие.

Опять же, должно / может / могло бы, если бы все было сделано правильно.

Физический коммутатор делает это, рассматривая каждую VLAN как отдельный домен уровня 2 и не использует информацию заголовка IP при принятии решения о пересылке. Однако должно быть что-то (возможно, определенное в стандартах), что заставляет VSwitch игнорировать различные VLAN в своем решении о пересылке и вместо этого проверять IP-заголовок и делать ложное предположение, что он может удовлетворить требования к подключению путем локального переключения.

Нет, если вы не используете VMware NSX / NSX-T или изо всех сил стараетесь заставить vswitch работать с трафиком уровня 3, вы получите только простой виртуальный коммутатор L2, который даже не знает, что вы говорите IP у всех.

Кто-нибудь знает, есть ли основанная на стандартах причина, по которой это происходит, или имеет опыт такой ситуации и выявил основную причину?

Я думаю, что это пробел в знаниях, будь то вы или кто-то другой, кто занимается вашим проектированием / реализацией виртуализации. Если у вас есть две VLAN / группы портов на вашем vSwitch, в них может проходить одинаковый IP-трафик. Он будет переключать трафик между vNIC в любой VLAN / группе портов, но не между ними. Очевидно, что ваши восходящие каналы должны где-то заканчиваться, обычно это коммутатор или маршрутизатор L3, и в этот момент у вас возникнет проблема, так как у вас будут дублирующиеся IP-адреса, и вам придется обойти это через NAT или аналогичный, но этот дизайн идеально подходит работоспособный. Где и как вы собираетесь бороться с дублированием диапазона?

«В многопользовательской виртуализированной среде LAN вполне вероятно, что разные клиенты будут иметь виртуальные машины в одной и той же подсети (например, 192.168.1.0/24) и размещаться в одной среде виртуального сервера».

Определенно возможно установить такой уровень 3 в многопользовательской среде. Однако необходимо убедиться, что вышестоящие коммутаторы и брандмауэры могут обрабатывать одни и те же подсети, маршрутизируемые через эти устройства. Например, CustomerA мог иметь VLAN 10 с подсетью 10.10.10.1/24, а CustomerB мог иметь VLAN 11 с подсетью 10.10.10.1/24. VMware не будет заботиться об этом, и у него не будет проблем с этим (или, как вариант, иметь среду NSX с виртуальными проводами, настроенными для этой настройки). Однако ваши восходящие коммутаторы / маршрутизаторы / брандмауэры должны поддерживать эту настройку. Примером этого является использование VMware vCloud Director с NSX. Каждый клиент имеет полный контроль над своими подсетями, и многие из них могут перекрываться. Используя виртуальные провода NSX, VMware сохраняет эти сети изолированными друг от друга. Если вышестоящие коммутаторы либо поддерживают VXLAN, либо являются строго уровнем 2, это работает нормально. (Источник: я работал над такой конфигурацией в течение многих лет).

«Перекрывающиеся подсети не являются проблемой для клиентов, потому что им не нужно взаимодействовать друг с другом. Но когда эти серверы виртуализированы в одной среде виртуальных серверов (например, Vmware или Sparc), они больше не могут отправлять трафик на провод, даже если два сервера находятся в разных VLAN (виден только первоначальный запрос ARP) ".

Похоже на проблему с сетью, а не на уровень виртуализации.

«Я ожидал, что разделение VLAN позволит VSwitch обрабатывать трафик для каждой виртуальной машины отдельно, несмотря на перекрытие. Физический коммутатор делает это, рассматривая каждую VLAN как отдельный домен уровня 2 и не использует в нем информацию заголовка IP. решение о пересылке.Однако должно быть что-то (возможно, определенное в стандартах), что заставляет VSwitch игнорировать различные VLAN в своем решении о пересылке и вместо этого проверять заголовок IP и делать ложное предположение, что он может удовлетворить требования к подключению путем локального переключения. Кто-нибудь знает, существует ли основанная на стандартах причина, почему это происходит, или имеет опыт такой ситуации и выявил основную причину? "

VSwitch обрабатывает трафик для каждого vSwitch отдельно при условии, что группы портов имеют соответствующие теги VLAN. Однако, опять же, вышестоящие коммутаторы должны это учитывать. Например, если ваше переключение - это подключение только на уровне 2, то, что вы наденете для уровня 3 в своей виртуализации, будет зависеть от вас. Скорее всего, ваша коммутация и маршрутизаторы относятся к уровню 3, что означает, что ваши гипервизоры - не единственное, что разделяет эти подсети и вызывает у вас проблемы. В этом случае вы должны использовать отдельные подсети, и ваша сетевая группа сможет помочь вам это настроить.