С выходом vSphere 5 VMware также выпустила отличный документ Multicast Performance on vSphere 5.0, рассказывающий об увеличении производительности обработки multicast трафика, но при этом никак не раскрывая техническую сторону вопроса.
Когда виртуальная машина настроена на получение трафика из какой-либо multicast группы она публикует соответствующий MAC адрес через свой сетевой интерфейс, и отправляет пакет на запрашивающий добавление её в группу. Виртуальный свитч (как vSS, так и vDS) никак не изменяя пакет отправляет его на физический свитч, который на основе, и благодаря, настройкам IGMP snooping`а на уровне физического хоста определяет через какой порт отправлять какую multicast группу, а vSwitch, в свою очередь, добавляет этот MAC адрес в свою таблицу переадресации.
Когда виртуальный свитч получает multicast трафик, то он переадресовывает его виртуальным машинам, входящим в эту multicast группу. Переадресация работает, как и в случае с unicast трафиком - на основе MAC адреса получателя. Так как vSwitch отслеживает,какие именно ВМ входят в какие именно multicast группы, то трафик переадресовывается не всем ВМ и всем интерфейсам, а только необходимым.
Если виртуальная машина отправляет запрос на удаление себя из multicast группы, её MAC адрес будет удалён из таблицы переадресации, после того как неизменённый пакет будет отослан на физический свитч. Если же данная виртуальная машина была последней на данном ESXi хосте, которая получала multicast трафик, то физический свитч также удалит этот хост из списка своих интерфейсов, через которые необходимо рассылать multicast трафик.
Если виртуальная машина переезжает на другой хост с помощью vMotion, то её настройки переедут вместе с ней. Целевой хост обновит свои таблицы переадресации согласно настройкам интерфейса виртуальной машины. Чтобы избежать возможной потери трафика из-за vMotion, виртуальный свитч целевого хоста отправляет IGMP запрос в ВМ, используя её unicast MAC адрес, чтобы физический свитч сразу получил информацию о новом местоположении ВМ. Это позволяет избежать потери трафика в ожидании следующего IGMP запроса от IGMP маршрутизатора.
Обычно IGMP маршрутизатором является какой-либо роутер в сети, и требуется для работы IGMP snooping на физических свитчах, которые, в свою очередь, используют эту информацию в своих таблицах переадресации IGMP трафика, и без которой не могут обеспечить работу IGMP snooping. Маршрутизатор отправляет запрос на адрес 224.0.0.1, общую multicast группу, а все ВМ в ответ отправляют информацию о том в какие-именно multicast группы они входят. Физический свитч, получая эту информацию, обновляет свои таблицы переадресации, и начинает пересылку трафика.
NIC Teaming физических интерфейсов также поддерживается, но механизм его работы зависит от используемого способа балансировки нагрузки.
Если активны все сетевые интерфейсы, а механизм балансировки нагрузки virtual source port ID или MAC hash based, то IGMP запрос на добавление будет выслан настроенным интерфейсом, и физический свитч обновит свою таблицу переадресации, и будет отсылать multicast трафик через соответствующий порт.
Если же один или несколько интерфейсов находятся в режиме ожидания, и начинают пересылать трафик только в случае выхода из строя активного интерфейса, то vSwitch вставит в поток IGMP запрос как в случае с vMotion.
В случае использования IP hash, физический свитч видит все физические интерфейсы как один интерфейс, и не сможет отправлять multicast трафик на разные интерфейсы, так как все физические интерфейсы являются членами всех групп. Физический интерфейс, используемый для передачи трафика в vSwitch, будет выбран согласно правилам балансировки нагрузки физического свитча.
Необходимо отметить, что для правильно работы агрегации каналов с несколькими физическими свитчами они должны быть объединены в стек, чтобы ESXi их воспринимал как один.
Оригинал: Kamau Wanguhu
Когда виртуальная машина настроена на получение трафика из какой-либо multicast группы она публикует соответствующий MAC адрес через свой сетевой интерфейс, и отправляет пакет на запрашивающий добавление её в группу. Виртуальный свитч (как vSS, так и vDS) никак не изменяя пакет отправляет его на физический свитч, который на основе, и благодаря, настройкам IGMP snooping`а на уровне физического хоста определяет через какой порт отправлять какую multicast группу, а vSwitch, в свою очередь, добавляет этот MAC адрес в свою таблицу переадресации.
Когда виртуальный свитч получает multicast трафик, то он переадресовывает его виртуальным машинам, входящим в эту multicast группу. Переадресация работает, как и в случае с unicast трафиком - на основе MAC адреса получателя. Так как vSwitch отслеживает,какие именно ВМ входят в какие именно multicast группы, то трафик переадресовывается не всем ВМ и всем интерфейсам, а только необходимым.
Если виртуальная машина отправляет запрос на удаление себя из multicast группы, её MAC адрес будет удалён из таблицы переадресации, после того как неизменённый пакет будет отослан на физический свитч. Если же данная виртуальная машина была последней на данном ESXi хосте, которая получала multicast трафик, то физический свитч также удалит этот хост из списка своих интерфейсов, через которые необходимо рассылать multicast трафик.
Если виртуальная машина переезжает на другой хост с помощью vMotion, то её настройки переедут вместе с ней. Целевой хост обновит свои таблицы переадресации согласно настройкам интерфейса виртуальной машины. Чтобы избежать возможной потери трафика из-за vMotion, виртуальный свитч целевого хоста отправляет IGMP запрос в ВМ, используя её unicast MAC адрес, чтобы физический свитч сразу получил информацию о новом местоположении ВМ. Это позволяет избежать потери трафика в ожидании следующего IGMP запроса от IGMP маршрутизатора.
Обычно IGMP маршрутизатором является какой-либо роутер в сети, и требуется для работы IGMP snooping на физических свитчах, которые, в свою очередь, используют эту информацию в своих таблицах переадресации IGMP трафика, и без которой не могут обеспечить работу IGMP snooping. Маршрутизатор отправляет запрос на адрес 224.0.0.1, общую multicast группу, а все ВМ в ответ отправляют информацию о том в какие-именно multicast группы они входят. Физический свитч, получая эту информацию, обновляет свои таблицы переадресации, и начинает пересылку трафика.
NIC Teaming физических интерфейсов также поддерживается, но механизм его работы зависит от используемого способа балансировки нагрузки.
Если активны все сетевые интерфейсы, а механизм балансировки нагрузки virtual source port ID или MAC hash based, то IGMP запрос на добавление будет выслан настроенным интерфейсом, и физический свитч обновит свою таблицу переадресации, и будет отсылать multicast трафик через соответствующий порт.
Если же один или несколько интерфейсов находятся в режиме ожидания, и начинают пересылать трафик только в случае выхода из строя активного интерфейса, то vSwitch вставит в поток IGMP запрос как в случае с vMotion.
В случае использования IP hash, физический свитч видит все физические интерфейсы как один интерфейс, и не сможет отправлять multicast трафик на разные интерфейсы, так как все физические интерфейсы являются членами всех групп. Физический интерфейс, используемый для передачи трафика в vSwitch, будет выбран согласно правилам балансировки нагрузки физического свитча.
Необходимо отметить, что для правильно работы агрегации каналов с несколькими физическими свитчами они должны быть объединены в стек, чтобы ESXi их воспринимал как один.
Оригинал: Kamau Wanguhu
Сообщения
Комментариев нет:
Отправить комментарий