Pull to refresh

Почему стандартному vSwitch-у не нужен Spanning Tree протокол

Reading time6 min
Views12K
Сегодня мне хотелось бы немного отвлечься от vSphere 5 лихорадки и вспомнить основы стандартного vSwitch-а, а в частности каким образом он обходится без Spanning Tree Protocol.

Я предполагаю, что вы уже обладаете простейшими знаниями коммутации и знаете что такое vlan, switching loop, spanning tree протокол и некоторые виды link aggregation протоколов. Я постараюсь кратко пробежаться по основным возможностям стандартного vSwitch-а, делая акцент на фактах, которые показались мне интересными или же которые были не очень очевидны в официальной документации, по крайней мере для меня. Отсюда же вытекает и некоторая сумбурность нижеизложенного.

Основная цель стандартного vSwitch-а (или же vNetworking Standard Switch aka vSS) — это обеспечение связи между виртуальными машинами и физической сетевой инфраструктурой. В дополнение, он обеспечивает логическое разделение виртуальных машин используя Port Groups, предлагает различные алгоритмы балансирования в случае если у вас есть более чем один аплинк на одном ESXi хосте, обеспечивает шейпинг исходящего трафика от виртуальных машин к vSS, ну и наконец, позволяет обнаруживать сбой аплинка и автоматическое переключать трафик на оставшиеся аплинки.



Итак, в чем же основные отличия от физического коммутатора?

В отличие от физических коммутаторов, vSS не нужно заучивать MAC адреса всех устройств находящихся в том же broadcast домене. Поскольку всем виртуальным машинам MAC адреса назначаются самим ESXi, то vSS уже знает все адреса по умолчанию. Другой отличительной особенностью является то, что vSS совершенно четко делит порты на два типа — внутренние порты и аплинки, и применяет к ним разные правила коммутации.

Port Group и Vlan

Port Group определяет шаблон конфигурации (например номер Vlan, шейпинг, балансировка трафика) для внутренних портов. Когда вы подключаете виртуальную машину к vSS вы просто указываете какой Port Group использовать для нее и следовательно применяете заранее настроенные параметры. Например, вы можете указать, что для виртуальных машин определенной Port Group-ы в качестве аплинка использовать только определенный интерфейс, а остальные интерфейсы задействовать как резервные. Еще одним хорошим примером является ситуация, когда вы хотите настроить на виртальных машинах MS Network Load Balancing Cluster в Unicast режиме. В таком случае вам нужно будет создать отдельную Port Group-у для этих виртуальных машин и отключить в них опцию Notify Switches.

Очень часто Port Group сравнивают с vlan в физических коммутаторах, хотя на самом деле это совершенно неверное сравнение. Я думаю это происходит в силу того, что в большинстве случаев vSphere админы используют Port Group-ы для разделения своих виртуальных машин по разным vlan-ам. Однако, далеко не всегда между ними наблюдается прямое соответствие. Предыдущий пример про MS Networking Load Balancing отличное тому доказательство — в нашей vSphere две Port Group-ы: одна для MS Network Load Balancing серверов и вторая — для остальных серверов. При этом виртуальные машины обеих Port Group принадлежат одному и тому же Vlan-у.
Ну и из этого вытекает другое отличие Port Group-ы от Vlan. Компьютеры в разных vlan-ах не могут общаться напрямую. Им обязательно нужен будет либо L3 устройство для маршрутизации трафика, либо нужно будет включить bridging между vlan-ами, а вот между Port Group-ами юникастовый трафик может свободно передаваться.

Большим сюрпризом для меня было открытие vlan 4095 буквально вчера, а точней возможность слушать абсолютно весь трафик на vSS с его помощью. Как правило в официальной документации VMware vlan 4095 указывается как VGT — virtual guest vlan tagging. С его помощью мы можем пробрасывать vlan тэги до самой виртуальной машины и уже ей позволять принимать решения о том, что делать с этим трафиком. На практике это применяется не так уж и часто — чаще используется VST (virtual switch vlan tagging), когда vSS удаляет vlan тэги и отправляет трафик в соответствующую Port Group. У нас VGT не используется вообще, поэтому про него я читал мельком. Оказывается, если создать port group и назначить ей vlan 4095, включить Promiscious mode в этой Port Group и после этого поместить туда виртуальную машину, то можно расчехлять wireshark и спокойно заниматься сбором и анализом траффика со всех машин, подключенных к этому vSS. Другим полезным практическим применением является помещение виртуальной IDS в такую Port Group-у с целью инспекции трафика.

Аплинки — балансировка трафика

В vSphere 4.1 у вас может быть максимально 32 аплинка на одном виртуальном коммутаторе. Аплинк может быть использован только на одном vSS, то есть использовать тот же аплинк на другом vSS уже не получится. Это также значит, что трафик никогда не будет передаваться напрямую от одного vSS к другому vSS. Трафик между ними либо должен уйти по аплинку к L3 устройству, либо по внутренним виртуальным портам к виртуальной машине, которая исполняет роль L3 устройства.

В 99% ситуаций у вашего ESXi хоста будет более чем один аплинк и вам придется решать как вы будете балансировать трафик поверх 2 и более аплинков. По умолчанию эти правила применяются к vSS, но вы при желании можете изменить их так же и на определенных Port Group-ах.

В vSS существует три основные политики балансировки трафика:
  • Route based on the originating virtual switch port ID — скажем у вас есть 6 виртуальных машин и у единственного vSS есть два аплинка. При включении первой виртуальной машины vSS назначает ей первый аплинк, который и будет постоянно использовать эта виртуальная машина, пока вы ее не выключите и не включите снова. Второй машине будет назначен второй аплинк, третьей — снова первый, ну и так далее. Переключение на другой аплинк может состояться только в случае падения основного линка. Трафик от физического коммутатора к виртуальной машине всегда будет возвращаться по тому же самому аплинку, ибо только на этом аплинке физический коммутатор будет знать MAC адрес виртуальной машины.
  • Route based on source MAC hash — По сути тот же самый метод как и предыдущий, разве что в этом случае будет использоваться хэш MAC адреса виртуальной машины для выбора аплинка.
  • Route based on IP hash — в этом случае vSS использует хэш айпи адреса источника и назначения для выбора аплинка. То есть сессия между двумя айпи адресами всегда будет идти поверх одного и того же аплинка, что будет нам гарантировать правильный порядок доставки пакетов. На физическом коммутаторе тоже будет необходимо включить поддержку стандарта 802.3ad, с тем чтобы он делал то же самое — хэшировал адреса источника и назначения, использовал только один аплинк для них, опять же обеспечивая правильный порядок прибытия пакетов. Кстати, совершенно не критично если трафик от виртуальной машины идет по одному аплинку, а возвращается по другому.

Один из распространненых сценариев распределения трафика очень похож на тот, что применятся на физических коммутаторах при помощи Spanning Tree протокола, когда разные vlan-ы ходят по разным аплинкам, до того момента пока один из аплинков не «падает» и тогда весь трафик этих vlan-ов переключается на оставшиеся аплинки. Точно так же в ESXi вы создаете 2 Port Group-ы на одном vSS. Для первой Port Group-ы первый аплинк указывается как активный, второй — резервный. С точностью до наоборот настраивается вторая Port Group. Таким образом вы добиваетесь более эффективного использования полосы пропускания до физического коммутатора и при этом не теряете избыточности.

Иногда vSphere админы выделяют отдельную пару аплинков только для vMotion или FT трафика, что кажется мне пустой тратой интерфейсов, ибо vMotion или же FT трафик балансируется поверх более чем одного интерфейса в очень редких случаях. Большую часть времени один из интерфейсов будет просто простаивать.

Шейпинг исходящего трафика
В случае использования vSS мы можем шейпить только исходящий трафик от виртуальных машин к vSS. В принципе этого, например, хватает чтобы шейпить vMotion трафик. Но, увы, шейпить входящий трафик от физических машин мы не сможем.

Итак, почему же vSS не нужен Spanning Tree протокол?

  • Все STP BPDU пакеты отправленные физическим коммутатором виртуальному коммутатору просто напросто игнорируются
  • Любой пакет, который vSS получает через один из аплинков никогда не будет отправлен через другой аплинк. Единственный путь для него — к одной из виртуальных машин или к VMK интерфейсу. То есть петли через vSS уже не будет
  • Когда vSS отправляет широковещательный, мультикастовый или же пакет с еще неизвестным юникастовым адресом физический коммутатор в обязательном порядке перенаправит его во все порты. Поэтому vSS проверяет адрес источника во всех входящих пакетах и если там обнаруживается MAC адрес одной из виртуальных машин или VMK интерфейса, то такой трафик игнорируется. Таким образом проблема петли через физический свитч решена
  • Броадкастовый и мультикастовый трафик отправленный виртуальной машиной будет разослан по всем портам той же Port Group-ы. Копия этого трафика будет отправлена физическому коммутатору поверх только одного аплинка, выбранного в соответствии с политикой балансировки трафика
  • Так как vSS уже знает все MAC адреса, то он будет отбрасывать все пакеты адресовнные незнакомому MAC адресу. Если же такой же пакет неизвестному адресату отправлен виртуальной машиной, то его в обычном порядке направят через уже выбранный механизмом балансировки трафика аплинк

Все это в принципе доказывает, что у вас может быть множество аплинков между vSS и физическим коммутатором, но при этом вам совершенно не нужен сложный в поиске неисправностей Spanning Tree Protocol.

Большую часть информации я скомпилировал из замечательнейшего блога товарища Ivan Pepelnjak и официальной документации VMware.
Tags:
Hubs:
Total votes 24: ↑21 and ↓3+18
Comments9

Articles