Виртуальные коммутаторы соединяют виртуальные машины с физической сетью. Они обеспечивают связь между виртуальными машинами на одном хосте Горизонт-ВС или на разных хостах Горизонт-ВС. Они также поддерживают службы, такие как iSCSI, NFS и доступ к сети управления.
       Виртуальный коммутатор хоста обеспечивает (рисунок 59):


Рисунок 59 – Структура виртуального коммутатора


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



Рисунок 60 – Подсети виртуального коммутатора


       Хост Горизонт-ВС поддерживает передачу тегированного трафика (802.1q). При настройке VLAN ID для виртуальной сети трафик ВМ, подключенных к данной сети, передается с нужным тегом VLAN ID. Виртуальные сети с разными VLAN ID изолированы друг от друга.



Рисунок 61 – Структура использования протокола VLAN виртуальнsv коммутатором


       В Горизонт-ВС виртуальный коммутатор поддерживает следующие режимы отказоустойчивости/балансировки трафика (таблица 9).
       Таблица 9 – Режимы отказоустойчивости/балансировки трафика

Режим

Описание

LACP

Balance-TCP

Балансировка на основании хеша MAC-адреса, IP-адреса и TCP-порта. При несогласовании LACP с физическим свитчом возможен переход на Active-Backup.

Да

Balance-SLB

Балансировка на основании хеша MAC-адреса источниками выходного VLAN. Периодическая перебалансировка.

Нет

Active-Backup
(по умолчанию)

Один линк в bond является активным, остальные запасными (без балансировки).

Нет


       Виртуальный коммутатор поддерживает протокол LACP для согласования bond с физическим коммутатором

       Можно настроить следующие режимы LACP:

       При несогласовании LACP с физическим коммутатором возможны следующие варианты (таблица 10).
       Таблица 10 – Режимs работы LACP

Опция «LACP Fallback to Active-Backup»

Поведение при несогласовании LACP

Включена

Переход на режим Active-Backup

Выключена (по умолчанию)

Все адаптеры будут disabled


       При отказе физического адаптера в bond трафик ВМ продолжает передаваться по другим физическим адаптерам этого же bond

Рисунок 62 – Принцип отказоустойчивости виртуального коммутатора

 
Во избежание петель необходимо всегда объединять физические аплинки хоста в bond. Протокол STP по умолчанию выключен. На него нельзя полагаться как на инструмент предотвращения петель.
У виртуального свитча должен быть только один логический аплинк== bond. Разные виртуальные свитчи имеют разные bond в качестве аплинков.

  2. Рисунок 63 – Принцип возникновения петли