Vmware настройка trunk порта

Обновлено: 07.07.2024

В данной статье мы рассмотрим пример настройки агрегации для VMware vSAN.

Агрегация каналов позволяет объединять несколько сетевых подключений параллельно для увеличения пропускной способности и обеспечения избыточности. Когда группирование сетевых адаптеров настроено с помощью LACP, происходит распределение нагрузки сети vSAN по нескольким аплинкам. Однако это происходит на сетевом уровне, а не через vSAN.

Ознакомиться с общей информацией об агрегировании каналов можно в одной из моих статей про Агрегирование каналов Cisco

В то время как объединение каналов является очень свободным термином, для целей этой статьи основное внимание будет уделяться протоколу управления объединением каналов или LACP. В то время как IEEE имеет свой собственный стандарт LACP 802.3ad, некоторые производители разработали проприетарные типы LACP. Например, PAgP (протокол агрегации портов) похож на LAG, но является собственностью Cisco. Таким образом, руководство поставщика имеет решающее значение, и следует всегда придерживаться лучших практик поставщиков.

Основным выводом при реализации LACP является то, что он использует отраслевой стандарт и реализован с использованием port-channel. Там может быть много алгоритмов хеширования. Политика группы портов vSwitch и конфигурация канала порта (хэш) должны совпадать и соответствовать.

Добавляем LAG

Переходим в наш распределённый коммутатор и создаём новую группу агрегации. Указываем имя, количество портов агрегации, режим работы, а так же режим балансировки.

Обратите внимание, что если хост и коммутатор находятся в пассивном режиме, LAG не будет инициализирован, так как нет активной части, которая инициировала бы соединение.

Назначаем LAG для PortGroup

Назначаем созданную группу агрегации необходимой порт группе и переводим LAG в режим ожидания (Standby).

При подтверждение изменений появится предупреждающее окно, о том, что использование комбинации активных аплинков и LAG в режиме ожидания поддерживается только для переноса физических адаптеров между LAG и автономными аплинками. Нажимаем ОК.

Проверяем, что LAG добавился.

Настраиваем адаптеры на хостах

Переходим в меню “Добавление и редактирование хостов” нашего распределённого коммутатора, выбираем пункт “Редактирование хостов”, добавляем хосты, которые подключены к данному distributed switch.

Назначаем LAG-порты к соответствующим vmnic. По аналогии назначаем порты для других хостов.

Создаём PortChannel на Cisco

Тема конфигурации PortChannel затронута в одной из моих статей по настройке объединения портов (bonding) Cisco IOS и CentOS LACP

Рассмотрим пример нашего тестового стенда:

Проверьте какой алгоритм балансировки используется на физическом коммутаторе.

Проверяем состояние PortChannel.

Переводим LAG в активный режим

Возвращаемся к настройкам нашего распределённого коммутатора, переходим в настройки порт группы и переводим LAG в режим Active, а автономные аплинки - в раздел неиспользуемых.

Обратите внимание, что когда LAG выбран, как основной аплинк, режим балансировки порт группы наследуется от режима балансировки, указанного в LAG, о чём нас дополнительно информируют.

Ещё раз проверяем топологию сети.

Особое внимание хочу уделить тому факту, что данная настройка не увеличивает пропускную способность, а выполняет роль отказоустойчивости и балансировки нагрузки.

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Немножко общей теории о виртуальных локальных сетях. VLAN поддерживаются как стандартными, так и распределенными виртуальными коммутаторами. Суть их в том, чтобы возложить на коммутатор работу по анализу и контролю трафика на втором уровне модели OSI с целью создавать не связанные между собой сети без физической их изоляции друг от друга.

Рис. 2.22. Серверы (ВМ) подключены к одному коммутатору, но к разным VLAN

Что мы здесь видим?

Все серверы (в нашем случае это ВМ, но для VLAN это не принципиально) подключены к одному коммутатору (слева), но на этом коммутаторе настроены несколько VLAN, и все ВМ подключены к разным (справа). Это означает, что на коммутаторе (в случае виртуальных машин - на вКоммутаторе) мы сделали настройку - порт для ВМ1 принадлежит виртуальной сети 1 (с идентификатором VLAN порт для ВМ2 принадлежит VLAN 2 и т. д. Это означает, что эти ВМ друг с другом взаимодействовать не могут, им не даст такой возможности сам коммутатор. Изоляция между серверами (ВМ) получается практически такой же, как если бы они были подключены к разным коммутаторам.

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

В общем случае VLAN - это разделение всей нашей сети на несколько как будто бы не связанных сегментов. Именно всей сети, а не отдельно взятого коммутатора.

- для того чтобы уменьшить домены широковещательной рассылки, следовательно, снизить нагрузку на сеть;

- для того чтобы повысить безопасность - хотя устройства подключены в одну сеть физически, находясь в разных vlan, они не смогут взаимодействовать по сети.

Если используются VLAN, то коммутаторы (обычно этим занимаются именно коммутаторы) добавляют в каждый кадр поле, в которое записывают так называемый «vlan id» (тег VLAN, идентификатор VLAN) - число в диапазоне от 1 до 4094. Получается, для каждого порта указано, кадры с каким vlan id могут пройти в порт, а в кадрах прописано, к какому vlan относится каждый кадр. Эту операцию называют «тегированием», добавлением в кадр тега vlan.

Обычно VLAN настраиваются на коммутаторах, и только коммутаторы о них знают - с точки зрения конечного устройства (такого, как физический сервер или виртуальная машина) в сети не меняется ничего. Что означает настроить vlan на коммутаторе? Это означает для всех или части портов указать vlan id, то есть vlan с каким номером принадлежит порт. Теперь если сервер подключен к порту с vlan то коммутатор гарантированно не перешлет его трафик в порты с другим vlan id, даже если сервер посылает широковещательный трафик.

Один VLAN может распространяться (и, как правило, распространяется) на несколько коммутаторов. То есть устройства, находящиеся в одном VLAN, могут физически быть подключены к разным коммутаторам.

Если за настройки сети отвечаете не вы, то формально, с точки зрения администрирования ESX(i), нам достаточно знать: ESX(i) поддерживает VLAN. Мы можем настроить vlan id для групп портов на вКоммутаторе, и они будут тегировать и ограничивать проходящий через них трафик.

Если тема настройки VLAN вас касается, то несколько слов подробнее.

У вас есть три принципиально разных варианта настройки vlan:

- external switch tagging, EST - установка тегов VLAN только на внешних, физических, коммутаторах. За VLAN отвечают только физические коммутаторы, на вКоммутаторы трафик приходит без тегов VLAN;

- virtual switch tagging, VST - установка тегов VLAN на виртуальных коммутаторах. Коммутаторы физические настраиваются таким образом, чтобы теги VLAN не вырезались из кадров, передаваемых на физические интерфейсы серверов ESX(i), то есть виртуальным коммутаторам;

- virtual guest tagging, VGT - установка тегов VLAN на гостевой ОС в виртуальной машине. В этом случае коммутаторы (и виртуальные, и физические) не вырезают тег VLAN при пересылке кадра на клиентское устройство (в нашем случае на ВМ), а теги VLAN вставляются в кадры самим клиентским устройством (в нашем случае виртуальной машиной).

EST - схема на рис. 2.23.

Рис. 2.23. External switch tagging

Этот подход хорош тем, что все настройки VLAN задаются только на физических коммутаторах. Вашим сетевым администраторам не придется задействовать в этом вКоммутаторы ESX(i) - порты физических коммутаторов, куда подключены физические сетевые контроллеры ESX, должны быть настроены обычным образом, чтобы коммутаторы вырезали тег VLAN при покидании кадром порта. Минус подхода EST в том, что на каждый VLAN нам нужен выделенный физический сетевой контроллер в ESX(i).

Таким образом, при реализации схемы EST уже физические коммутаторы пропускают в порты к ESX(i) пакеты только из нужных VLAN (5 и 15 в моем примере). Виртуальные машины и виртуальные коммутаторы про VLAN ничего не знают.

VST - схема на рис. 2.24.

Рис. 2.24. Схема Virtual switch tagging

Этот подход предполагает настройку VLAN и на вКоммутаторах. Удобен тем, что на один вКоммутатор (и на одни и те же vmnic) может приходить трафик множества VLAN. Из минусов - требует настройки на стороне и физических, и виртуальных коммутаторов. Те порты физических коммутаторов, к которым подключены контроллеры серверов ESX(i), следует настроить «транковые», то есть пропускающие пакеты из всех (или нескольких нужных) VLAN, и не вырезающие теги VLAN при проходе кадра сквозь порт. А на вКоммутаторах надо сопоставить VLAN ID соответствующим группам портов. Впрочем, это несложно -Configuration ^ Networking ^ свойства vSwitch ^ свойства группы портов ^ в поле VLAN ID ставим нужную цифру.

VGT - схема на рис. 2.25.

Этот подход хорош в тех редких случаях, когда одна ВМ должна взаимодействовать с машинами из многих VLAN одновременно. Для этого вКоммутатор мы настроим не вырезать теги VLAN из кадров к этой ВМ (фактически сделаем транковый порт на вКоммутаторе). Чтобы настроить транковый порт на стандартном виртуальном коммутаторе VMware, необходимо для группы портов, к которой подключена ВМ, в качестве VLAN ID прописать значение «4095». Пройдите Configuration ^ Networking ^ свойства vSwitch ^ свойства группы портов ^ в поле VLAN ID.

Рис. 2.25. Схема Virtual guest tagging

Минус конфигурации в том, что внутри ВМ должно быть ПО, обрабатывающее VLAN, - так как вКоммутатор теги VLAN вырезать не будет и они будут доходить прямо до ВМ. На физических серверах очень часто этим ПО является драйвер сетевых контроллеров. Это актуально и для ВМ.

Для реализации схемы VGT виртуальные машины должны использовать виртуальные сетевые карты типа e1000 или vmxnet3.

Драйверы vmxnet3 для Windows из состава VMware Tools позволяют настраивать VLAN, но какой-то один - см. рис. 2.26.

Рис. 2.26. Настройка VLAN в драйвере vmxnet3

Рис. 2.27. Настройка VLAN в драйвере e1000/Intel Pro 1000

К сожалению, Intel не предоставляет специального драйвера для 64-битных операционных систем.

Кроме стандартных виртуальных коммутаторов VMware, некоторые лицензии позволяют использовать распределенные виртуальные коммутаторы VMware. У них немного больше возможностей работы с VLAN (они позволяют использовать Private VLAN) и чуть-чуть по-другому выглядят окна настройки. Подробности см. в следующем разделе.

В статье расскажу опыт построения сетевого взаимодействия между физическими компьютерами и виртуальными машины, созданными в среде VMWare Esxi 6.7. Организация маршрутизации между всеми устройствами осуществляется с помощью Mikrotik CHR.

И так, приступим

Введение

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

Приведу первоначальную топологию.

Коммутатор D-Link. К нему подключены физические машины и сервер с VMWare ESXI. Сам коммутатор подключен к вышестоящему оборудованию организации.
Некоторый парк физических машин.
Набор виртуальных машин.
Одна виртуальная машины, на которой установлен Windows Server и AD.

Задача

Необходимо по 2 физические машины и 2 виртуальные машины объединить в одно адресное пространство. При этом нельзя затрагивать общую инфраструктуру организации. Каждый сформированный набор машин должен быть изолирован друг от друга, но должны быть обеспечены выходом в интернет и доступом к AD.

Реализация

Первоначально начнем с того, что на коммутаторе порты к которым подключены физические машины поместим в собственные VLAN, которых нет в инфраструктуре организации. В итоге получается что в каждом VLAN оказывается по две физические машины. Далее все созданные VLAN помешаем на сервер где установлен VMWare.

На виртуальном switch VMWare получаем следующую структуру:

Для того, чтобы организовать маршрутизацию и разделение на подсети используем Mikrotik CHR. На сервере VMWare разнесем созданные VLAN между виртуальными машинами и Mikrotik. В итоге получаем следующим вид для каждого VLAN:

Новая топологию с Mikrotik CHR выглядит следующим образом:

На виртуальный маршрутизатор в итоге приходят следующие интерфейсы:

Интерфейс для доступа к внутренней сети организации
Интерфейс с реальным IP адресов
Интерфейс каждого созданного VLAN

Настройка Mikrotik CHR

Для всех созданных интерфейсов на маршрутизаторе добавим комментарий и определим наименование.

Теперь для каждого интерфейса можем определить собственное адресное пространство, в каждом адресном пространстве DNS сервером будет являться виртуальная машина с Windows Server и AD. Тем самым каждое устройство сможет быть добавлено в созданную AD. Внутри AD дополнительно укажем DNS сервера организации.

Для обеспечения изолированности каждой подсети друг от друга создадим соответствующее правило, но при этом обеспечим доступ к сети где располагаются Windows Server с AD (цепочка forward). Также запретим ICMP пакеты между сетями (цепочка input).

Для упрощения работы помещаем нужные интерфейсы в один список, тем самым обеспечиваем удобства в настройке firewall.

После всех настроек получаем следующую ситуация из DHCP сервера:

Как видим машины занимают адреса из определенных сетей.

Используя виртуальный Mikrotik CHR обеспечивается возможность взаимодействия между физическими машинами и виртуальными. Разделение каждого набора машин в собственное адресное пространство позволяет изолировать созданные объекты.

Вы хотите узнать, как настроить соединительную линию VLAN на Vmware ESXi? В этом уроке мы покажем вам все шаги, необходимые для создания VLAN и настройки соединительной линии с использованием сервера Vmware ESXi.

Этот учебник был протестирован на Vmware ESXi 6.5

Этот учебник был протестирован на Vmware ESXi 6.7

В приведенном выше видео показано, как настроить VLAN с использованием старых версий Vmware ESXi 6, 5.5 и 5

Vmware ESXi Playlist:

На этой странице мы предлагаем быстрый доступ к списку видеороликов, связанных с Vmware ESXi.

Не забудьте подписаться на наш канал YouTube, названный FKIT.

Учебное пособие по VMware ESXi:

На этой странице мы предлагаем быстрый доступ к списку руководств, связанных с Vmware Esxi.

Учебное пособие - Конфигурация внешних линий Vmware ESXi

Во-первых, вам нужно получить доступ к веб-интерфейсу Vmware.

Откройте программное обеспечение браузера, введите IP-адрес вашего сервера Vmware ESXi и получите доступ к веб-интерфейсу.

На экране приглашения введите регистрационную информацию администратора.

После успешного входа в систему появится панель управления Vmware.

На панели управления Vmware выберите «Сетевое меню».

Откройте вкладку Группы портов.

На следующем экране вам необходимо настроить следующие элементы:

• Имя - введите идентификатор на свой Vlan.
• VLAN ID - введите идентификационный номер VLAN.

После завершения настройки нажмите кнопку «Добавить».

Если вам нужно добавить еще одну VLAN, нажмите еще раз на группе «Группа портов».

Выполните такую же конфигурацию во второй VLAN.

Не забудьте сохранить конфигурацию.

Чтобы проверить конфигурацию, откройте меню «Сеть».

Откройте вкладку Виртуальные коммутаторы.

Нажмите Виртуальный коммутатор.

В правой части экрана вы можете увидеть конфигурацию соединительной линии.

В нашем примере мы видим, что VLANS 100, 200 и 0 могут проходить через интерфейс VMNIC1.

VLAN 0 означает сетевой пакет без какого-либо тега VLAN.

Имейте в виду, что Vmware-интерфейс VMNIC1 должен быть подключен к порту коммутатора, предварительно настроенному как соединительная линия.

Порт коммутатора должен быть настроен для обеспечения трафика VLANS 100, 200.

Порт коммутатора также должен установить VLAN по умолчанию.

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

Как правило, все сетевые коммутаторы устанавливают VLAN1 как собственную VLAN.

Поздравляем! Вы успешно сконфигурировали соединительную линию VLAN на Vmware ESXi.

Приветствую всех. Сегодня я постараюсь внести ясность в такую неоднозначную и вызывающую много споров тему, как агрегирование каналов в Vmware. Многие (в том числе и производители оборудования) для описания агрегирования каналов применяют такие термины как LACP, 802.3ad, Ethernet trunk, NIC Teaming, Port Channel, Port Teaming, Link Bundling, NIC bonding, EtherChannel, link aggregation и некоторые другие. В целом, технология агрегирования каналов, это технология позволяющая объединить несколько физических каналов в один логический. Такое объединение позволяет увеличивать пропускную способность (он же Load Distribution или Load Balancing) и надежность канала (она же Failover). В данной статье, возможно, я сделал какие-то неверные выводы и буду благодарен за дополнения и комментарии. Для написания статьи я придерживался мануала Cisco IEEE 802.3ad Link Bundling, ибо только в нем нашел более менее систематизированные понятия.

Введение в агрегирование каналов (NIC Teaming)

Для начала, давайте разберемся в терминологии. В связи с большой путаницей в понятиях, я буду придерживаться следующего списка:

Агрегирование каналов - собственно, общее наименование любого из видов объединения физических каналов в логический.
EtherChannel - это просто название технологии Cisco, описывающей агрегацию каналов (не протокол ил стандарт).
Teaming (или NIC Teaming) - по аналогии с Cisco, это так же название технологии агрегации каналов в компании Vmware (и некоторых других, например Intel и HP).
Link Aggregation Control Protocol (LACP) - протокол агрегации каналов, имеющий возможности автоматически создавать агрегацию (посредством пересылки LACP PDU пакетов). Протокол LACP описан в стандарте IEEE 802.3ad (как утверждает Microsoft, он же имеет маркировку IEEE 802.1ax, хотя в Cisco я не нашел упоминания 802.1ax).
IEEE 802.3ad - стандарт, описывающий протоколы и принципы агрегирования каналов. Так же, включает описание балансировки трафика агрегированных каналов.
LAG (Link Aggrigation Group) - в терминологии Vmware это и есть логический канал, объединяющий в себе uplink порты.

Далее, давайте рассмотрим что же такое агрегирование каналов без привязки к производителю. Из терминов выше - ясно, что это технология объединения физических интерфейсов в логический. Какую-то часть функционала данной технологии выполняет протокол STP, позволяющий использовать несколько физических интерфейсов для отказоустойчивости. Но данный протокол не позволяет осуществлять балансировку трафика и по сути в какой-то один момент времени использует только один физический линк для передачи данных. Хотя агрегирование позволяет увеличить пропускную способность канала, но не стоит рассчитывать на идеальную балансировку нагрузки между всеми интерфейсами в агрегированном канале. Технологии по балансировке нагрузки в агрегированных каналах, как правило, ориентированы на балансировку по таким критериям: MAC-адресам, IP-адресам, портам отправителя или получателя (по одному критерию или их комбинации). Агрегирование каналов у многих производителей сетевого оборудования возможно только в режиме "точка-точка". То есть возможно агрегировать каналы начинающиеся на одном устройстве и заканчивающиеся на другом устройстве. Т.к. цель данной статьи - рассмотреть NIC Teaming на Vmware, то для упрощения будем придерживаться ситуации, когда наш хост использует один физический коммутатор для агрегирования каналов.

Какие же требования необходимо выполнить, чтобы агрегирование каналов заработало корректно?

Максимальное количество поддерживаемых интерфейсов в агрегированном канале определяется производителем оборудования. (наиболее частая цифра 4 или 8 интерфейсов, в Vmware на текущий момент - 32)
Все физические интерфейсы в агрегированном канале должны иметь одинаковые настройки скорости и режима full-duplex. (при этом, LACP не поддерживает half-duplex mode).
Все физические интерфейсы в агрегированном канале должны иметь одинаковые настройки протокола агрегирования (LACP, статический и др.).
VMware поддерживает только один канал EtherChannel на vSwitch или vNetwork Distributed Switch (vDS)

Режим работы EtherChannel

Теперь давайте рассмотрим нюансы работы протокола LACP на примере оборудования Cisco (имеющие отношение к Vmware vSphere). Итак, оборудование Cisco, поддерживающее EtherChannel может настроить этот самый EtherChannel в нескольких режимах. За это отвечает команда channel-group (подробней - в ссылках в документе IEEE 802.3ad Link Bundling). Из всех возможных режимах в Cisco, Vmware поддерживает только 3 (до версии 5.5 - только 1). Рассмотрим режимы EtherChannel :

channel-group номер_группы mode active
Данный режим включает Link Aggregation Control Protocol (LACP) на интерфейсе постоянно . То есть Cisco в любом случае является источником LACP PDU пакетов. Скажем так - является активным инициатором.

channel-group номер_группы mode passive
LACP включается только когда обнаружено поступление LACP пакетов от другой стороны. Скажем так - является пассивным инициатором.

channel-group номер_группы mode on
Данный режим включает EtherChannel без использования каких-либо протоколов согласования . Это так называемый статический EtherChannel или статический NIC Teaming или статическая агрегация. Назвать данный режим LACP - нельзя. Т.к. для его работы не используется функционал протокола LACP. Т.е. не происходит автоматического согласование канала на основе обмена LACP пакетами.

channel-group номер_группы mode
Это другие возможные режимы работы, но они нам не интересны, т.к. используют для согласования проприетарный протокол PAgP и vSphere не поддерживаются.

Работа протокола LACP будет возможна, при следующих конфигурациях сторон:

То есть, не работающая конфигурация, когда обе стороны настроены в LACP passive режиме. Статическая агрегация IEEE 802.3ad возможна только когда обе стороны настроены в статическом режиме.

Балансировка нагрузки EtherChannel

Например, на схеме, все устройства находятся в одном VLAN. Шлюз по умолчанию маршрутизатор R1. Если коммутатор sw2 использует метод балансировки по MAC-адресу отправителя, то балансировка выполняться не будет, так как у всех фреймов MAC-адрес отправителя будет адрес маршрутизатора R1. Аналогично, если коммутатор sw1 использует метод балансировки по MAC-адресу получателя, то балансировка выполняться не будет, так как у всех фреймов, которые будут проходить через агрегированный канал, MAC-адрес получателя будет адрес маршрутизатора R1.

Агрегация каналов ( NIC Teaming ) в VMware

Начнем с истории, а точнее, с версий vmware - до 5.5. Официально, до версии 5.5 в vSphere отсутствовала поддержка агрегирования каналов по протоколу LACP. Можете сравнить документы what's new для версии 5.1 и 5.5. Хотя, в документации vSphere Networking Guide ESXi 5.1 уже есть упоминание о включении LACP на uplink интерфейсе. Будем считать, что полноценна поддержка появилась в 5.5.

NIC Teaming в Vmware vsphere до 5.5 (5.1.x, 4.x)

Примеров данных конфигураций в интернете полно. Пожалуй, лучшая статья, которая в достаточной степени описывает технологию и настройку NIC Teaming на Vmware (для версий VMware ESX 3.0.x,VMware ESX(i) 3.5.x, VMware ESX(i) 4.0.x, VMware ESX(i) 4.1.x, VMware ESXi 5.0.x и VMware ESXi 5.1.x) размещена на сайте Михаила Михеева - LACP, 802.3ad, load based IP hash и все такое (см.ссылки). Копипастить одно и то же смысла не вижу, поэтому - читайте ). Если все же есть непреодолимое желание использовать LACP с vSphere младше 5.5, вам потребуется установить виртуальный коммутатор Cisco Nexus 1000V (или IBM 5000v).

NIC Teaming по протоколу LACP в Vmware vsphere 5.5.x

VMware ESXi 5.5.x, как и прошлые версии поддерживает работу в режиме статического тиминга. Настройка его ни чем не отличается от той, которая написана в статье LACP, 802.3ad, load based IP hash и все такое. Далее, нас интересует настройка NIC Teaming с использованием согласования по протокол LACP на Vmware. В чем же польза LACP по сравнению с static aggregation:

Возможность использовать Hot-Standby Ports.

Проверка корректности конфигурации. Агрегация каналов

Failover (обнаружение отказа). Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Архитектурно, LACP'ом в vSphere управляет модуль ядра, который взаимодействует с демоном lacp _ uw. Ключевое отличие настройки статической агрегации от LACP на vSphere Distributed Switch заключается в следующем: При использовании NIC teaming в статической конфигурации на vSphere Distributed Switch мы создавали т.н. Uplink порты, которым сопоставляли физические vmnic интерфейсы хостов. А уже Uplink интерфейс использовали в качестве исходящего интерфейса взаимодействия с внешним миром. А виртуальные машины, работая на каком-либо из хостов выбирали из ассоциированного с Uplink физического интерфейса - нужный. При этом, группировка и балансировка происходила на уровне созданных Uplink интерфейсов в настройках распределенных порт-групп в разделе “Teaming and failover”. При настройке Link Aggregation Control Protocol мы создаем т.н. LAG (Link Aggrigation Group) - некая сущность, аналогичная Port Channel в Cisco - логический интерфейс, который объединяет физические интерфейсы и на уровне которой применяются настройки LACP (active-passive) и Load Balancing, к которой ассоциируются физические интерфейсы одного хоста. А Уже к этому самому LAG присоединяются/ассоциируются физические vmnic интерфейсы. И этот же LAG используется в качестве исходящего интерфейса. "На пальцах" тяжело понять данный абзац. Необходима практика )

Типовой пример настройки NIC Teaming по протоколу LACP

Давайте на практике посмотрим как это выглядит. Предположим, что у нас уже создан некий Distributed Switch 5.5.0. Со свичом ассоциированы необходимые хосты. Создана некая портгруппа виртуальных машин в конфигурациях по умолчанию. Например:

Далее, перед настройкой LACP давайте рассмотрим некоторые аспекты настройки:

Из физических NIC какого-то одного хоста возможно подключение одного физического NIC только к одному порту LAG, при этом, один порт LAG может включать в себя множество физических интерфейсов с различных хостов ассоциированных с данным распределенным коммутатором.
Физические NIC хоста, включенные в LAG должны быть подключены к интерфейсам физического свича, которые (интерфейсы свича) должны быть настроены на аналогичный агрегированный канал (port channel).
При настройке LACP необходимо учитывать ограничения, актуальные для текущей версии:
LACP не совместим с software iSCSI multipathing.

Итак, последовательность настройки LACP на Vmware следующая:

Назначить LAG как Standby интерфейс в настройке Teaming and Failover Order в Distributed Port Group.

Это рекомендованная мануалом последовательность. На самом деле, можно обойтись без шага №2. Просто задав ассоциацию свободных физических NIC к созданному LAG. Но тем не менее, давайте рассмотрим каждый шаг:

В vSphere Web Client переходим на наш созданный distributed switch.

Ассоциировать физические интерфейсы с LAG
1. . Убеждаемся, что все порты, которые планируется ассоциировать с LAG сконфигурированы и скоммутированы на физическом коммутаторе.
2. . Убеждаемся, что все физические NIC имеют одинаковые настройки скорости и
В поле Failover order с помощью стрелок перемещаем наш созданный LAG в раздел Active, все остальные аплинки (если такие имеются) перемещаем в

Резюме

В текущей статье я постарался описать особенности работы с агрегированными каналами. Постарался описать статическую конфигурацию NIC Teaming и конфигурацию по протоколу LACP. Упор сделан не столько на практику, сколько на теорию и предоставление источников дальнейшего чтения для углубления изучения ) ИМХО, обзор получился несколько поверхностным, по возможности буду наполнять статью.

Читайте также: