Сообщество VLAN

Сообщество VLAN, которое позволяет участникам общаться друг с другом и
Разнородный VLAN. Думайте об этом как о конференц-зале - все в конференции
комната может общаться друг с другом, но не может общаться с теми, кто находится за пределами комнаты
без посторонней помощи. Например, предыдущая диаграмма показывает две VLAN сообщества: 200
и 250. Любые виртуальные машины, размещенные в Community VLAN 200, смогут общаться друг с другом.
а также отправлять трафик в Promiscuous VLAN. Однако они не могут отправлять трафик на
другая Community VLAN 250 или изолированная VLAN 600 без прямой помощи со стороны
устройство маршрутизации в Promiscuous VLAN или выше сетевого стека. фигура
9.11 иллюстрирует потоки трафика между вторичными VLAN.
Вы можете иметь столько VLAN сообщества, сколько пожелаете, вплоть до ограничения идентификатора VLAN ID.
из 4094.
Изолированная VLAN
FinalSecondary VLAN type - это изолированная VLAN. В дополнение к правилам, которые мы рассмотрели для VLAN сообщества, виртуальные машины внутри изолированной VLAN даже не могут общаться с одним
еще один. Любой трафик уровня 2, который пытается перейти с одной виртуальной машины на другую, будет просто
отброшен. Виртуальные машины могут общаться только с Promiscuous VLAN и за ее пределами.
ПОДСКАЗКА
Зачем использовать изолированную VLAN? Этот особый тип VLAN имеет фантастическое применение для рабочих нагрузок, которыми будут пользоваться гостевые пользователи, например, киоски. Если вы размещаете интернет лицом
шлюз устройства в Promiscuous VLAN, вы можете убедиться, что каждый киоск заблокирован от
друг друга, но все еще может достичь Интернета. На самом деле, в большинстве «гостиничных» ситуаций используется
Изолированная VLAN именно по этой причине. Тем не менее, будьте осторожны с тем, что вы делаете в Интернете - кто-то
вероятно, отслеживает вашу деятельность.
Группы распределенных портов
Поскольку несколько хостов могут использовать VDS, группы портов также должны быть распределены. Эта
означает, что ни один хост не владеет какой-либо частью VDS, включая группы распределенных портов.
Фактически, если порт VMkernel хочет жить в VDS, он должен использовать группу распределенных портов.
Это отличается от стандартной конфигурации vSwitch тем, что вам необходимо создавать специальные сетевые адаптеры VMkernel непосредственно в vSwitch. Кроме того, несколько VMkernel
порты могут совместно использовать одну и ту же распределенную группу портов.
ПОДСКАЗКА
VDS принадлежит контейнеру vCenter Datacenter, а не хосту, и не может охватывать
более одного центра обработки данных. Это означает, что вы можете создавать группы портов на VDS, который
будет использоваться хостами в любом кластере, который находится в контейнере Datacenter, или даже
хосты, которых нет в кластере. Однако эти группы портов не могут использоваться хостами в
другой Datacenter контейнер. Это делает распределенные группы портов чрезвычайно мощными и
очень масштабируемый
Каждая распределенная группа портов имеет доступ ко всем восходящим каналам, связанным с VDS. Дополнительно,
параметры конфигурации и политики, такие как значения безопасности и группирования, применяются
непосредственно в распределенную группу портов. Это означает, что вы можете иметь один распределенный порт
группа, которая устанавливает все восходящие каналы активными и использует VLAN 100, в то время как другая группа портов использует
активный / пассивный микс в VLAN 200. Распространено создавать модульную конструкцию с различными
групп портов для различных задач, таких как одна для каждой VLAN, на которой будут работать ваши гостевые машины
использование, vMotion, управление, протоколирование отказоустойчивости и многое другое. Мы много расскажем о
эта тема в главе 13 «Распределенный дизайн vSwitch».
Порты VMkernel
Поскольку хосту все еще нужны порты VMkernel (виртуальные адаптеры) для обработки таких задач, как трафик управления и vMotion, все еще нужны порты VMkernel с VDS. Это
где все может стать немного сложнее. Порты VMkernel уникальны для каждого хоста, потому что
каждый хост имеет свою собственную схему нумерации vmk и детали конфигурации IP. Следовательно,
Порты VMkernel настраиваются на каждом хосте в vCenter, так же, как и при использовании стандартного vSwitch.
Разница в том, что каждый порт VMkernel существует в распределенной группе портов. Когда
хост был добавлен в VDS, варианты размещения его портов VMkernel на распределенном порту
группа появляется. Порт VMkernel использует базовые правила из распределенной группы портов.
функционировать. Следовательно, базовая аппаратная конфигурация определяется групповыми политиками распределенных портов, а индивидуальность порта VMkernel - IP-адрес, подсеть.
маска, максимальная единица передачи (MTU) и т. д. - определяется самим хостом. фигура
9.12 показаны порты VMkernel хоста в VDS.
Виртуальные машины
При работе с виртуальными машинами, подключенными к VDS, требуется очень мало оперативных изменений.
Виртуальные машины могут использовать порты в любой распределенной группе портов, даже те, для которых вы выделены
ваши порты VMkernel для использования. Часто лучше создать определенные группы портов только для вашего
ВМ и использовать схему именования, которая лучше всего описывает сеть, например сегмент IP
диапазон и VLAN ID.
В качестве дополнительного бонуса, имейте в виду, что, поскольку группы портов распределены, размещение
Виртуальная машина в распределенной группе портов снижает риск, что vMotion может привести к хаосу из-за неправильной настройки политики или идентификатора VLAN на хосте назначения. У каждого хоста точно такой же
Настройки группы портов. Это немного упрощает устранение неполадок в сети, так как вы часто можете
определите, что физическая сеть на хосте не настроена должным образом, без особых усилий по устранению неполадок.
Формирование трафика
Мы уже достаточно углубились в концепцию и математику формирования трафика в главе 8 «Стандартный коммутатор vSphere». Вы должны хорошо разбираться в том, как определить свои средние, максимальные и пиковые размеры - если нет, вернитесь к главе и прочитайте раздел по формированию трафика.
Причина, по которой мы начинаем формировать трафик во второй раз, связана с найденной дополнительной функцией
в Distributed vSwitch - возможность формирования входного и выходного трафика.
Стандартный vSwitch ограничен только входным формированием.
выход
Egress - это концепция управления трафиком, который покидает VDS. Это может быть из
VDS на виртуальную машину или порт VMkernel, или даже когда трафик передается от одной виртуальной машины к другой.
Параметры конфигурации формирования трафика такие же, как и во входном формировании, но
применяется для трафика, проходящего в другом направлении. Такой трафик иллюстрируется
НОТА
Один действительно отличный способ использовать формирование выходного трафика - это контролировать количество полосы пропускания.
это может использоваться для трафика с несколькими сетевыми картами vMotion. Существует угловой случай, когда несколько источников
хосты могут быть виртуальными машинами vMotion для одного хоста назначения. Без формирования выходного трафика,
или какое-то физическое формирование трафика на вышестоящем коммутаторе, вы можете столкнуться с нетривиальным объемом трафика на ваших хост-ссылках. Мы рассмотрим это более подробно в
Глава 19, «Архитектура Multi-NIC vMotion».
Балансировка нагрузки
Еще одна особенность, доступная только в Distributed vSwitch, - это новая форма распределения нагрузки, называемая «маршрут на основе физической нагрузки NIC», которую часто называют «На основе нагрузки».
Teaming (LBT). Эта политика маршрутизации была впервые введена в vSphere 4.1 и является единственной
действительно активная политика балансировки нагрузки. Все остальные политики используют произвольные
фактор для определения пути восходящей линии связи, такой как IP-адрес или виртуальный порт, тогда как LBT
при определенных условиях активно отслеживает и перенаправляет трафик на различные каналы связи.
Маршрут основан на физической нагрузке сетевого адаптера
Давайте подробнее рассмотрим, как работает эта политика, представив пример сценария. Представьте, что у вас есть пять виртуальных машин на одном физическом хосте vSphere, которые отправляют и получают трафик Ethernet в одной группе распределенных портов. Группа портов имеет случайным образом
назначил VM1, 2 и 3 на uplink1, в то время как VM4 и VM5 используют uplink2. Вдруг,
VM1 начинает отправлять огромный объем трафика, который насыщает всю доступную пропускную способность
на uplink1 в течение более 30 секунд, как указано
При любой другой политике балансировки нагрузки насыщение на линии вверх1 будет продолжаться до
VM1 завершил отправку данных по сети. Между тем, uplink2 может испытывать
очень мало трафика или даже простаивать. Какая трата!
LBT будет следить за восходящими линиями и запускать, когда их значение будет на 75% выше или выше
не менее 30 секунд. Значения триггера не могут быть изменены. В это время это сделает
решение переместить некоторые из виртуальных сетевых адаптеров ВМ в другую активную восходящую линию, при условии, что
другая восходящая линия связи не имеет достаточной пропускной способности, чтобы принять новую виртуальную машину. Имейте в виду, что
LBT не будет перемещать трафик в резервный или неиспользованный канал связи, поэтому вам не нужно беспокоиться о
это нарушает ваш порядок отработки отказа.
В примере сценария на рисунке 9.15 LBT перенес VM2 и VM3 в uplink2,
которая решает ситуацию «шумного соседа», когда VM1 вызывает конфликт за пропускную способность сети.
Важно понимать несколько ограничений LBT:
■ Виртуальный сетевой адаптер виртуальной машины не может использовать несколько восходящих каналов одновременно. Политика
перемещает виртуальный сетевой адаптер из одной восходящей линии связи в другую во время конфликтов, но делает
не распределять сетевой трафик одной виртуальной машины по нескольким восходящим каналам.
Если у вас очень интенсивный трафик, который заканчивается менее чем за 30 секунд, LBT не
вызвать миграцию. Этот 30-секундный порог существует для предотвращения побоев: бесполезно,
повторяющаяся, дорогая работа.
НОТА
Хотя почти вся документация для LBT рассказывает о возможности виртуальной виртуальной миграции
NIC, важно понимать, что он также может перемещаться по портам VMkernel. если ты
находятся в среде конвергентной инфраструктуры с ограниченным количеством восходящих каналов, это может
выгодно использовать LBT для перемещения по порту VMkernel, назначенному для управления
или vMotion во времена насыщения полосы пропускания восходящей линии связи. Не забывайте, что LBT не может вызвать
трафик для порта VMkernel для одновременного использования нескольких восходящих каналов - он будет только перемещать
Порт VMkernel от одного восходящего канала к другому.
Вы можете задаться вопросом, как работает LBT, когда у вас есть несколько распределенных групп портов.
делиться тем же набором ссылок. В конце концов, каждая группа портов может иметь различную группировку
применяется политика, некоторые используют LBT, другие используют идентификатор виртуального порта и, возможно, некоторые используют
явный порядок отработки отказа. К счастью, потому что LBT контролирует насыщенность на восходящих каналах, это
очень хорошо сочетается с другими политиками. Если какой-либо восходящий канал в VDS становится насыщенным на 75% или
выше в течение 30 секунд, любая группа распределенных портов с настроенными триггерами политики LBT
и попытки перемещаться вокруг рабочих нагрузок. Нет необходимости иметь одну гигантскую группу портов
со всеми виртуальными машинами внутри.
На рисунке 9.16 виртуальные машины были разделены на две разные группы портов: зеленую с использованием
«Маршрут на основе исходного идентификатора виртуального порта» (по умолчанию) и оранжевый с использованием LBT.
Когда VM1 начинает отправлять огромные объемы трафика, что приводит к тому, что uplink1 достигает 75% или
более высокая насыщенность в течение 30 секунд или дольше, группа портов с поддержкой LBT theorange все еще может
переместите VM2 и VM3 в uplink2, чтобы уменьшить насыщенность.
--------------------------
СЕРВЕР аналог: https://t.co/J4VM6KrsWs