Сегодня мне бы хотелось немного отдохнуть от лихорадки vSphere 5 и вспомнить основы стандартного vSwitch, и в частности, как он обходится без протокола Spanning Tree. Я предполагаю, что вы уже имеете базовые знания о коммутации и знаете, что такое vlan, петля коммутации, протокол связующего дерева и некоторые типы протоколов агрегации каналов.
Я постараюсь кратко рассмотреть основные возможности стандартного vSwitch, остановившись на фактах, которые показались мне интересными или которые были не очень очевидны в официальной документации, по крайней мере для меня.
Это также приводит к некоторой путанице в изложенном ниже.
Основная цель стандартного vSwitch (или стандартного коммутатора vNetworking, также известного как vSS) — обеспечить связь между виртуальными машинами и физической сетевой инфраструктурой.
Кроме того, он обеспечивает логическое разделение виртуальных машин с помощью групп портов, предлагает различные алгоритмы балансировки в случае, если у вас более одного аплинка на одном хосте ESXi, обеспечивает формирование исходящего трафика от виртуальных машин к vSS и, наконец, позволяет обнаруживать аплинк сбое и автоматически переключать трафик на оставшиеся восходящие каналы.
Так в чем же основные отличия от физического коммутатора? В отличие от физических коммутаторов, vSS не нужно изучать MAC-адреса всех устройств, расположенных в одном широковещательном домене.
Поскольку всем виртуальным машинам MAC-адреса назначаются самим ESXi, vSS уже знает все адреса по умолчанию.
Еще одной отличительной особенностью является то, что vSS четко разделяет порты на два типа — внутренние порты и аплинки и применяет к ним разные правила коммутации.
Группа портов и Vlan Группа портов определяет шаблон конфигурации (например, номер Vlan, формирование, балансировку трафика) для внутренних портов.
Когда вы подключаете виртуальную машину к vSS, вы просто указываете, какую группу портов использовать для нее, и, следовательно, применяете предварительно настроенные параметры.
Например, вы можете указать, что для виртуальных машин определенной группы портов использовать только определенный интерфейс в качестве аплинка, а остальные интерфейсы использовать как резервные.
Еще одним хорошим примером является ситуация, когда вы хотите настроить кластер балансировки сетевой нагрузки MS в режиме одноадресной рассылки на виртуальных машинах.
В этом случае вам нужно будет создать отдельную группу портов для этих виртуальных машин и отключить в них опцию Notify Switches. Очень часто Port Group сравнивают с vlan в физических свитчах, хотя на самом деле это совершенно неверное сравнение.
Я думаю, это происходит из-за того, что в большинстве случаев администраторы vSphere используют группы портов для разделения своих виртуальных машин на разные vlan. Однако между ними не всегда существует прямое соответствие.
Предыдущий пример с балансировкой нагрузки сети MS является отличным тому подтверждением — наша vSphere имеет две группы портов: одну для серверов балансировки нагрузки сети MS, а вторую для других серверов.
В этом случае виртуальные машины обеих групп портов принадлежат одному Vlan. Ну и отсюда вытекает еще одно отличие между Port Groups и Vlan. Компьютеры в разных виртуальных локальных сетях не могут взаимодействовать напрямую.
Им обязательно понадобится либо устройство L3 для маршрутизации трафика, либо потребуется включить мост между вланами, но одноадресный трафик может свободно передаваться между группами портов.
Большим сюрпризом для меня стало открытие буквально вчера vlan 4095, а точнее возможность прослушивать с его помощью абсолютно весь трафик на vSS. Как правило, в официальной документации VMware vlan 4095 обозначается как VGT — тегирование виртуального гостевого vlan. С его помощью мы можем пересылать теги vlan самой виртуальной машине и давать ей возможность принимать решения о том, что делать с этим трафиком.
На практике это используется не очень часто — чаще используется VST (виртуальный коммутатор vlan tagging), когда vSS удаляет теги vlan и отправляет трафик в соответствующую группу портов.
Мы вообще не используем VGT, поэтому я читал о нем лишь вкратце.
Получается, что если создать группу портов и назначить ей влан 4095, включить в этой группе портов режим Promiscious и затем разместить там виртуальную машину, то можно раскрыть Wireshark и спокойно собирать и анализировать трафик со всех машин, подключенных к этому vSS. .
Еще одним полезным практическим применением является размещение виртуальной IDS в такой группе портов с целью проверки трафика.
Uplinks - балансировка трафика В vSphere 4.1 вы можете иметь максимум 32 восходящих канала на одном виртуальном коммутаторе.
Восходящий канал можно использовать только на одном vSS, то есть использование того же восходящего канала на другом vSS будет невозможно.
Это также означает, что трафик никогда не будет передаваться напрямую от одного vSS к другому vSS. Трафик между ними должен идти либо по восходящему каналу к устройству L3, либо через внутренние виртуальные порты к виртуальной машине, играющей роль устройства L3. В 99% ситуаций ваш хост ESXi будет иметь более одного восходящего канала, и вам придется решить, как вы будете балансировать трафик по двум или более восходящим каналам.
По умолчанию эти правила применяются к vSS, но при желании вы можете изменить их и для определенных групп портов.
В vSS существует три основные политики балансировки трафика:
- Маршрут на основе идентификатора порта исходного виртуального коммутатора.
Допустим, у вас есть 6 виртуальных машин, и единственный vSS имеет два восходящих канала.
Когда вы включаете первую виртуальную машину, vSS назначает ей первый аплинк, который эта виртуальная машина будет постоянно использовать, пока вы ее не выключите и не включите снова.
Второй машине будет назначен второй восходящий канал, третьей снова будет назначен первый и так далее.
Переключение на другой восходящий канал может произойти только в случае сбоя основного канала.
Трафик от физического коммутатора к виртуальной машине всегда будет возвращаться по одному и тому же восходящему каналу, поскольку только на этом восходящем канале физический коммутатор будет знать MAC-адрес виртуальной машины.
- Маршрут на основе хэша MAC-адреса источника.
По сути тот же метод, что и предыдущий, за исключением того, что в этом случае для выбора восходящего канала будет использоваться хэш MAC-адреса виртуальной машины.
- Маршрут на основе хеша IP — в этом случае vSS использует хеш IP-адресов источника и назначения для выбора восходящего канала.
То есть сеанс между двумя IP-адресами всегда будет проходить по одному и тому же восходящему каналу, что будет гарантировать нам правильный порядок доставки пакетов.
Физическому коммутатору также необходимо будет включить поддержку 802.3ad, чтобы он делал то же самое — хешировал адреса источника и назначения, использовал для них только один аплинк, опять же обеспечивая правильный порядок прихода пакетов.
Кстати, совсем не критично, если трафик от виртуальной машины идет через один аплинк, а возвращается через другой.
Аналогично в ESXi вы создаете 2 группы портов на одном vSS. Для первой группы портов первый аплинк указывается как активный, второй – резервный.
Вторая группа портов настроена с точностью до наоборот. Таким образом, вы достигаете более эффективного использования полосы пропускания вплоть до физического коммутатора, не жертвуя при этом избыточностью.
Иногда администраторы vSphere выделяют отдельную пару аплинков только для трафика vMotion или FT, что мне кажется пустой тратой интерфейсов, поскольку трафик vMotion или FT балансируется более чем по одному интерфейсу в очень редких случаях.
Большую часть времени один из интерфейсов просто будет простаивать.
Формирование исходящего трафика При использовании vSS мы можем формировать только исходящий трафик от виртуальных машин к vSS. В принципе, этого, например, достаточно для формирования трафика vMotion. Но, увы, формировать входящий трафик с физических машин мы не сможем.
Так почему же vSS не нужен протокол связующего дерева?
- Все пакеты STP BPDU, отправленные физическим коммутатором виртуальному коммутатору, просто игнорируются.
- Любой пакет, который vSS получает через один из восходящих каналов, никогда не будет отправлен через другой восходящий канал.
Единственный путь для этого — к одной из виртуальных машин или к интерфейсу ВМК.
То есть шлейфа через vSS больше не будет
- Когда vSS отправляет широковещательную, многоадресную рассылку или пакет с пока неизвестным одноадресным адресом, физический коммутатор обязательно пересылает его на все порты.
Поэтому vSS проверяет адрес источника во всех входящих пакетах и если там обнаруживается MAC-адрес одной из виртуальных машин или интерфейса ВМК, то такой трафик игнорируется.
Таким образом решается проблема закольцовывания физического коммутатора.
- Широковещательный и многоадресный трафик, отправляемый виртуальной машиной, будет отправляться на все порты одной группы портов.
Копия этого трафика будет отправлена на физический коммутатор поверх только одного восходящего канала, выбранного в соответствии с политикой балансировки трафика.
- Поскольку vSS уже знает все MAC-адреса, он отбросит все пакеты, адресованные незнакомому MAC-адресу.
Если тот же пакет отправлен виртуальной машиной неизвестному получателю, то он будет отправлен в обычном порядке через уже выбранный механизмом балансировки трафика восходящий канал.
Большую часть информации я собрал из замечательного блог товарищ Иван Пепельняк и официальная документация VMware. Теги: #Виртуализация #Стандартный vSwitch STP
-
Советы По Конвертации Mp4 В Wmv
19 Oct, 24 -
Ddr4 Поступит В Продажу В Следующем Месяце
19 Oct, 24
