Технический справочник. Сетевые подключения

1. Сетевые подключения хостов

На канальном уровне (уровень 2) zVirt позволяет конфигурировать bond-интерфейсы Linux, чтобы подключаться к сетям VLAN и задавать MTU для сетевых интерфейсов. Эти сети могут быть доступны сразу нескольким виртуальным машинам через мосты Linux.

В случае SR-IOV можно настроить количество виртуальных функций и их сопоставление с логическими сетями.

Протокол FCoE управляет своими собственными сетями VLAN. Сети VLAN, управляемые протоколом FCoE, используются исключительно для доступа к хранилищу. Они невидимы для Менеджера управления и всех виртуальных машин.

iSCSI управляет bond-интерфейсами iSCSI. Они не входят в видимую конфигурацию сети хостов zVirt. iSCSI можно использовать без bond-интерфейсов iSCSI, которые полезны только для повышения надежности хранилища iSCSI.

Все хосты в кластере должны использовать или IPv4, или IPv6 в качестве IP-стека для своей сети управления. Одновременное использование обоих стеков не поддерживается.

Можно настроить DNS-резолвер, который используется хостом.

Можно также управлять ролями сети и QoS.

2. Типы сетевых подключений на виртуальных машинах

В zVirt виртуальные сетевые карты виртуальных машин могут подключаться к следующим типам сетей:

Мосты Linux
Сетевые карты SR-IOV
Внутренняя система OVN в zVirt

На следующей схеме представлена структура этих трех подходов, где:

Хост 1 представляет мосты Linux
Хост 2 представляет сетевые карты SR-IOV
Хост 3 представляет OVN

Рисунок 1. Подключение ВМ к различным типам сетей

Таблица 1. Сравнение типов сетей
	Мост Linux	SR-IOV	Внутренняя система OVN в zVirt
Изоляция от сетей физических хостов	Уровень 3, Возможна отдельная IP-сеть	Уровень 2, Возможны отдельные сети VLAN	Изолирована
Миграция на лету	x	x	x
Политика QoS (QoS)	x
Зеркалирование портов (Port Mirroring)	x
конфигурация подключенной vNIC	x	x
Управление MAC-адресами	x	x	x
Распространение MTU	x		x
Фильтрация сети VLAN, может потребоваться настройка на физическом коммутаторе	x	x	Предварительная версия технологии, представленная для оценки (Technology Preview)
Защита от спуфинга MAC-адресов	x		x
Защита от спуфинга IP-адресов	x		x
Предварительно заданные сетевые фильтры	x
Пользовательская фильтрация Уровня 3/4			x
NAT
Объявления маршрутизатора/DHCP			x
Маршрутизатор Уровня 3			x
Производительность	**	***	*
инкапсуляция данных сети виртуальных машин	однородная сеть, VLAN	однородная сеть, VLAN	Стабильная сеть: GENEVE; Предварительная версия технологии, представленная для оценки (Technology Preview): однородная сеть, VLAN

2.1. Выбор сетевых подключений для различных сценариев

Мост Linux - наиболее проверенный вариант, который задан по умолчанию и подходит в большинстве случаев.

Для сценариев, где требуется очень низкая задержка сети или большое количество Ethernet-фреймов, рассмотрите возможность использования SR-IOV. Однако учтите, что для SR-IOV требуются аппаратная поддержка и дополнительная настройка.

Внутренние OVN-сети zVirt позволяют виртуальным машинам взаимодействовать друг с другом без ручной настройки сети.

Менеджер управления предоставляет только подмножество функций программно-определяемой сети (SDN) и пользовательских интерфейсов. Для использования всех функций SDN, аналогичных внутренней OVN-сети zVirt или сторонней SDN-сети, необходим дополнительный клиент, например CloudForms.

Все типы сетей можно объединить на одном хосте и подключить их к одной и той же виртуальной машине.

2.2. Взаимодействие с гостевой операционной системой

zVirt поддерживает первоначальную настройку виртуальной машины, предоставляя данные конфигурации через cloud-init (для виртуальных машин Linux) или через sysprep (для виртуальных машин Windows). Если внутри виртуальной машины работает qemu-guest-agent, то zVirt может сообщить IP-адреса виртуальной машины.

Если виртуальная машина использует сетевую карту VirtIO, то MTU логических сетей zVirt предоставляются гостевой операционной системе. Гостевая операционная система может выбрать MTU из объявлений маршрутизатора DHCPv4 или IPv6, если логическая сеть поддерживает эти объявления.

2.3. Сетевые подключения хоста и виртуальных машин

Мост Linux разделяет сетевые подключения виртуальных машин и хоста на третьем уровне OSI. Следовательно, хост и его виртуальные машины совместно используют конфигурацию сети, включая VLAN, бондинг и MTU.

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

IP-адрес, ассоциированный с мостом Linux, необязательно должен быть в той же подсети, что и виртуальные машины, которые используют мост для подключения. Если мосту назначен IP-адрес в той же подсети, в которой находятся виртуальные машины, использующие этот мост, то виртуальные машины могут обращаться к хосту внутри логической сети по его адресу. Как правило, не рекомендуется на хосте виртуализации запускать службы, доступные из сети.

3. Сетевая архитектура

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

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

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

4. Условия базового сетевого подключения

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

Логические сети
Сетевую карту (NIC)
Мост Linux
Bond-интерфейс
Виртуальную сетевую карту (vNIC)
Виртуальную локальную сеть (VLAN)

Сетевые карты, мосты Linux и виртуальные сетевые карты обеспечивают сетевое взаимодействие между хостами, виртуальными машинами, локальными сетями и сетью Интернет. При желании можно реализовать bond-интерфейсы и сети VLAN для повышения безопасности, отказоустойчивости и пропускной способности сети.

5. Сетевая карта

Сетевая карта (NIC) - это сетевой адаптер или адаптер LAN, который подключает компьютер к компьютерной сети. Сетевая карта работает как на физическом, так и на канальном уровне машины и обеспечивает сетевое подключение. На каждом хосте виртуализации в среде zVirt есть как минимум одна сетевая карта, хотя чаще их две или больше.

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

6. Мост Linux

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

Пользовательские свойства могут задаваться для подключения как по мосту, так и по Ethernet. VDSM передает определение настроек сети и пользовательские свойства хуку скрипта настройки сети.

7. Bond-интерфейсы

7.1. Общие сведения о bond-интерфейсах

В zVirt Node объединение сетевых портов реализовано средствами модуля ядра bonding.

Bond-интерфейс - это совокупность нескольких сетевых карт на едином программно-определяемом устройстве. Поскольку bond-интерфейс суммирует производительность входящих в него сетевых карт, чтобы действовать как единый сетевой интерфейс, он может обеспечить более высокую скорость передачи, чем одна сетевая карта. Кроме того, бондинг обеспечивает более высокую отказоустойчивость, так как bond-интерфейс выйдет из строя, только если выйдут из строя все входящие в него сетевые карты. Однако есть и ограничение: чтобы поддерживать одни и те же параметры и режимы, все сетевые карты в bond-интерфейсе должны быть от одного производителя и одной модели.

7.2. Режимы бондинга

zVirt использует Режим 4 по умолчанию, но поддерживает следующие общие режимы бондинга:

Режим 1 (active-backup) - переводит все сетевые интерфейсы в резервное состояние, в то время как один сетевой интерфейс остается активным. В случае отказа активного сетевого интерфейса один из резервных интерфейсов заменяет сбойный интерфейс в качестве единственного активного сетевого интерфейса в бонде. MAC-адрес соединения в режиме 1 виден только на одном порту, чтобы предотвратить путаницу, которая может возникнуть, если MAC-адрес соединения изменится на MAC-адрес активной сетевой интерфейсной карты. Режим 1 обеспечивает отказоустойчивость и поддерживается в zVirt.
Режим 2 (XOR) - выбирает сетевой интерфейс, через который будут передаваться пакеты, на основе результата операции XOR над MAC-адресами источника и назначения по модулю количества сетевых интерфейсов. Этот расчет гарантирует, что для каждого используемого MAC-адреса назначения будет выбрана одна и та же карта сетевого интерфейса. Режим 2 обеспечивает отказоустойчивость и балансировку нагрузки и поддерживается в zVirt.
Режим 4 (IEEE 802.3ad) - создает группы агрегации, в которых интерфейсы имеют одинаковые настройки скорости и дуплекса. Режим 4 использует все сетевые интерфейсы в активной группе агрегации в соответствии со спецификацией IEEE 802.3ad и поддерживается в zVirt.

7.3. Сравнение режимов объединения

Группа объединения (LAG - Link Aggregation Group) - общее название объединения портов, имеющих одинаковые настройки для обработки трафика определенного назначения. Со стороны zVirt Node группой объединения является bond-интерфейс и его подчиненные (Slaves) физические порты.

В таблице представлены требования к оборудованию и возможности для поддерживаемых режимов объединения.

Таблица 2. Cравнение режимов объединения
Требования	Active-Backup(Mode 1)	Load balance (Mode 2)	Dynamic link aggregation(Mode4,802.3ad/LACP)
Требование к коммутаторам	Специальной настройки портов коммутатора не требуется. Порты одной группы объединения могут подключаться в порты разных коммутаторов, не имеющих специального режима синхронизации таблиц коммутации (MLAG/Stack и т.д.).	Для большинства политик балансировки со стороны коммутаторов требуется настройка портов в рамках одной группы объединения в режиме Static EtherChannel. (2) Порты одной группы объединения могут подключаться в порты разных коммутаторов, но только при условии поддержки настройки единого Static EtherChannel на два коммутатора в рамках MLAG/vPC/Stack и т.д. (3)	Со стороны коммутаторов требуется настройка портов в рамках одной группы объединения в режиме LACP (Active/Passive EtherChannel в терминологии Cisco). Порты одной группы объединения могут подключаться в порты разных коммутаторов, но только при условии поддержки настройки единого Active EtherChannel на два коммутатора в рамках MLAG/vPC/Stack и т.д.
Поддержка балансировки трафика	Нет	Да	Да
Поддержка отказоустойчивости при отказе одного/нескольких портов	Да	Да	Да
Поддерживаемые режимы проверки	MII и ARP	MII	MII

Необходимо учитывать:

Политика балансировки Балансировка по VLAN и MAC источника (VLAN+SRC MAC) не требует настройки коммутатора, т.к. трафик с источником определенного MAC всегда попадает на один порт.
EtherChannel - устоявшееся определение для объединения портов, введенное производителем Cisco. Static EtherChannel подразумевает настройку объединения портов без использования какого-либо протокола согласования настроек между двумя сторонами (коммутатор и zVirt Node).
Единый EtherChannel возможно настроить для конфигурации коммутаторов, обменивающихся коммутационной информацией и имеющих единый уровень распределения трафика. Такая возможность присутствует в большинстве проприетарных решениях стекирования коммутаторов (единый Control Plane на весь стек) и в большинстве решений MLAG (Multichassis LAG - каждый коммутатор имеет свой Control Plane с синхронизацией между коммутаторами в рамках MLAG)

7.3.1. Режим Active-Backup

Режим Active-Backup обеспечивает отказоустойчивость для наиболее широкого списка коммутаторов и сетевых топологий физической сети. В объединении с режимом проверки ARP предоставляет настройки отказоустойчивого подключения к сети через независимые коммутаторы (см.Раздел проверки ARP).

В режиме Active-Backup со стороны гипервизора трафик ВМ отправляется через единственный порт, являющийся активным или Currently Active Slave в терминологии bond-интерфейса. Со стороны коммутатора все порты являются активными, а трафик отправляется в соответствии с заполнением таблицы FDB (Forward Data Base). Если отправляется широковещательный трафик или FDB не содержит записи по MAC-назначения, то такой кадр будет отправлен коммутатором во все порты. Со стороны zVirt Node пакет отправляется только в активный порт.

Если активный порт переходит в отключенное или неисправное состояние, то модуль bonding автоматически активирует резервный порт и начинает отправлять или принимать трафик через него. В момент активации порта со стороны гипервизора могут быть отправлены служебные сообщения GARP, NA и IGMP для оповещения коммутатора о перемещении MAC на другой порт. Данные оповещения касаются только IP/MAC на bond-интерфейсе, для IP/MAC ВМ оповещения не будут отправлены, это стоит учитывать при планировании инфраструктуры и выборе типа объединения портов.

Режим Active-Backup поддерживает следующие параметры:

GARP/NA/IGMP при активации (num_grat_arp, num_unsol_na, resend_igmp) - отправка оповещений Gratuitous ARP (IPv4), Neighbor Advertisements (IPv6) и IGMP (сообщение IGMP membership report) при активации резервного порта. Этот механизм позволяет актуализировать таблицу FDB и IGMP snooping на коммутаторе. Параметр указывает количество повторов отправки сообщений. По умолчанию одно сообщение.
Приоритетный порт (primary) - параметр указывает, какой порт по умолчанию является активным при активации bond-интерфейса.
Политика восстановления порта (primary_reselect) - политика определяет, какой порт будет активным при восстановлении Приоритетного порта (primary).
- Возврат к приоритетному интерфейсу всегда - Приоритетный порт станет активным при восстановлении работоспособности вне зависимости от других условий.
- Возврат к приоритетному порту, если его скорость больше - Приоритетный порт станет активным, если его скорость больше, чем у текущего активного (например, 10 Гбит/с у Приоритетного порта и 1 Гбит/с у текущего активного).
- Возврат к приоритетному интерфейсу, если активный порт отказал - Приоритетный порт станет активным только в случае, если текущий активный порт отказал.
Период отправки оповещений, мс (peer_notif_delay) - Интервал отправки оповещений GARP/NA/IGMP при активации резервного порта. Применимо, если значение параметра GARP/NA/IGMP при активации равно 2 или более. Если в параметре Период отправки оповещения указать значение 0, то он будет равен периоду проверки MII (miimon).

Для режима Active-Backup доступны проверки работоспособности порта Media Independent Interface (MII) и ARP. Сведения о режимах проверки см. разделе Проверка работоспособности порта.

7.3.2. Режим Load balance

Режим Load balance обеспечивает как отказоустойчивость портов, так и балансировку трафика между физическими портами. Данный режим требует настройки коммутаторов для всех режимов балансировки, кроме режима Балансировка по VLAN и MAC источника (vlan+srcmac), но не требует согласования настроек портов посредством какого-либо протокола. Это может приводить к ошибкам настройки со стороны администратора, т.к. со стороны коммутатора и гипервизора могут быть добавлены несимметричные порты в группу объединения.

В режиме Load balance со стороны гипервизора и коммутатора активны все порты, то есть трафик может отправляться и приниматься через все работоспособные порты в рамках группы объединения. Перед отправкой пакета в сторону коммутатора bond-интерфейс вычисляет хэш заголовка пакета (используемые поля заголовка зависят от типа балансировки) и остаток от деления на количество физических портов в bond-интерфейсе. Результат данной операции определяет, через какой физический порт будет отправлен пакет (Ethernet-кадр). Распределение входящего трафика зависит от настроек коммутатора, его политики балансировки. Это приводит к тому, что пакет в рамках одной сессии может быть отправлен через один порт, а обратный трафик получен через другой, что является нормальной ситуацией и не влияет на работоспособность. Рекомендуется использовать идентичные настройки балансировки со стороны коммутатора и гипервизора.

Режим Load balance в качестве параметров для настройки поддерживает только Политику балансировки Подробную информацию см. в разделе Политики балансировки.

При использовании политики балансировки Балансировка по VLAN и MAC источника (vlan+srcmac) настройка коммутатора в режиме Static EtherChannel необязательна, поскольку при штатной работе bond-интерфейса трафик от определенного MAC всегда будет проходить через единственный порт.

Для режима Load balance доступна только проверка работоспособности порта Media Independent Interface (MII). Сведения о режимах проверки см. разделе Проверка работоспособности порта.

7.3.3. Режим Dynamic link aggregation

Режим Dynamic link aggregation обеспечивает как отказоустойчивость к отказу портов, так и балансировку трафика между физическими портами и использует протокол LACP (Стандарт IEEE 802.3ad) для согласования настроек и состояния портов bond-интерфейса с группой объединения (LAG) на стороне коммутатора.

В режиме Dynamic link aggregation со стороны гипервизора и коммутатора активны или все порты, или 8 портов, а остальные находятся в резерве. Трафик может отправляться и приниматься через все активные порты в рамках группы объединения. Перед отправкой пакета в сторону коммутатора bond-интерфейс вычисляет хэш заголовка пакета (используемые поля заголовка зависят от типа балансировки) и остаток от деления на количество физических портов в bond-интерфейсе. Результат данной операции определяет, через какой физический порт будет отправлен пакет (Ethernet-кадр). Распределение входящего трафика зависит от настроек коммутатора и его политики балансировки. В данном случае пакет в рамках одной сессии может быть отправлен через один порт, а обратный трафик получен через другой, что является нормальной ситуацией и не влияет на работоспособность. При этом рекомендуется использовать идентичные настройки балансировки со стороны коммутатора и гипервизора.

Режим Dynamic link aggregation поддерживает следующие параметры:

Политика балансировки (xmit_hash_policy) - алгоритм выбора порта для отправки конкретного пакета (Подробную информацию см. в разделе Политики балансировки).
Системный приоритет LACP (ad_actor_sys_prio) - значение системного приоритета в рамках протокола LACP со стороны zVirt Node. Активные порты в объединении Bond определяются коммутатором или узлом zVirt Node с наименьшим значением приоритета, особенно если количество портов в группе превышает восемь. Диапазон допустимых значений — от 1 до 65595. По умолчанию установлен наивысший приоритет — 65535.
LACP port key (ad_user_port_key) - значение, которое используется для формирование параметра Actor_key в рамках протокола LACP. Параметр Port-key присваивается каждому порту внутри bond-интерфейса и проверяется на второй стороне на этапе согласования и дальнейшей работы LACP. В большинстве случаев модификация данного значения не требуется. Допустимы значения о 0 до 1023. По умолчанию назначается 0.
Кол-во интерфейсов для активации (min_links) - определяет минимальное количество работоспособных портов для активации bond-интерфейса и начала передачи трафика через агрегированную группу каналов (LAG). Допустимы значения от 0 до 7. Значение по умолчанию — 0, что аналогично требованию наличия хотя бы одного рабочего порта.
Период отправки LACPDU (lacp_rate) - период отправки служебных сообщений LACPDU для проверки работоспособности и настроек порта. Допустимы значения slow и fast. По умолчанию используется значение slow, при котором пакеты LACPDU отправляются раз в 30 секунд. Значение fast предполагает передачу пакетов каждую секунду. Настройки на стороне коммутатора могут различаться, однако в большинстве ситуаций bond-интерфейс функционирует даже при разных значениях параметра lacp_rate между zVirt Node и коммутатором.

Для режима Dynamic link aggregation доступна только проверка работоспособности порта Media Independent Interface (MII). Сведения о режимах проверки см. разделе Проверка работоспособности порта.

7.4. Политики балансировки

Балансировка трафика обеспечивает распределение только исходящего трафика. Входящий трафик балансируется согласно политикам на коммутаторе/коммутаторах.

Применимы следующие политики балансировки:

Балансировка по MAC (layer2) - распределение трафика между портами осуществляется на основании MAC-адресов источника и назначения пакета. При штатной работе группы объединения все пакеты, у которых совпадает и MAC источника, и MAC назначения будут всегда отправляться через один и тот же порт. Таким образом, взаимодействие двух виртуальных машин в стандартных сетях будет проходить через один порт.
Балансировка по MAC + IP (layer2+3) - распределение трафика между портами осуществляется на основании MAC-адреса отправителя, IP-адреса отправителя, MAC-адреса получателя и IP-адреса получателя, указанных в пакете. При штатной работе группы объединения все пакеты, у которых совпадают перечисленные атрибуты пакета, будут отправляться через один и тот же порт. В большинстве случаев взаимодействие между двумя виртуальными машинами также осуществляется через один порт, если каждая машина использует единственный IP-адрес.
Балансировка по IP + Port (layer3+4) - распределение трафика между портами зависит от IP-адреса источника, L4-порта источника (например, TCP-порта, если применимо), IP-адреса назначения и L4-порта назначения (если применимо). При штатной работе группы объединения все пакеты в рамках одной TCP/UDP сессии будут отправляться через один и тот же порт. Таким образом, каждая установленная TCP/UDP сессия будет распределяться по активным портам независимо от других сессий. Данный тип балансировки является наиболее гранулярным для стандартных сетей zVirt, то есть при большом количестве взаимодействий ВМ между собой трафик будет распределяться наиболее равномерно между всеми активными физическими портами.
Балансировка по MAC + IP инкапсулированного пакета (layer2+3) - алгоритм балансировки аналогичен политике Балансировка по MAC (layer2), но при распределении трафика по портам учитываются внутренние MAC-адрес источника и MAC-адрес назначения в пакете. Под внутренними подразумеваются атрибуты вложенного пакета. Вложенность иcпользуетcя в рамках программной сети (SDN). Политика применима для тех групп объединения, где преимущественно проходит трафик SDN.
Балансировка по IP + Port инкапсулированного пакета (layer3+4) - алгоритм балансировки аналогичен политике Балансировка по IP + Port (layer3+4), но для распределения трафика по портам учитываются внутренние MAC-адреса источника, IP-адрес источника, MAC-адрес назначения и IP-адрес назначения в пакете. Под внутренними подразумеваются атрибуты вложенного пакета. Политика применима для тех групп объединения, где преимущественно проходит трафик SDN.
Балансировка по VLAN и MAC источника (vlan+srcmac) - при распределении трафика между портами учитываются VLAN-тег и MAC-адрес источника в пакете. Данная политика не учитывает атрибуты пакета, связанные с его получателем, что позволяет направить весь трафик с определённого порта виртуальной машины (при условии использования единственного MAC-адреса) в конкретный физический порт. Благодаря этому исключается необходимость применять Static EtherСhannel на коммутаторах, поскольку при штатной работе группы объединения пакеты с одинаковым MAC-адресом всегда будут отправляться через один порт.

Протокол UDP не предусматривает формирование постоянных соединений или сессий. В данном случае под сессией подразумевается сетевой трафик, обладающий одними и теми же атрибутами IP-адреса и UDP-порта как у отправителя, так и у получателя.

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

Если используется политика Балансировка по VLAN и MAC источника (vlan+srcmac) и на коммутаторах не настроен EtherChannel, то коммутатор будет отправлять пакеты согласно своей таблице FIB (Forwarding information Base).

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

Политика балансировки	Преимущества	Недостатки	Область применения
Балансировка по MAC (layer2)	Низкая сложность (вычислительная стоимость) выбора порта для отправки пакета	Низкая гранулярность распределения трафика по портам Со стороны коммутатора требуется настроенная группа объединения портов (EtherChannel)	Стандартные сети zVirt Хосты с большим количеством ВМ без преобладания трафика одной/нескольких ВМ над остальными
Балансировка по MAC + IP (layer2+3)	Средняя сложность (вычислительная стоимость) выбора порта для отправки пакета	В большинстве сценариев распределение трафика по портам будет схожим с политикой Балансировка по MAC (layer2). Требуется настройка группы объединения портов (EtherChannel) на коммутаторах.	Стандартные сети zVirt Хосты, на которых размещены ВМ с функциями вложенной виртуализации, контейнерной виртуализацией или сложными сервисами, использующими несколько IP-адресов.
Балансировка по IP + Port (layer3+4)	Наибольшая гранулярность распределения трафика по портам для большинства типа трафика. Не требует анализа трафика для принятия решения о достижимой эффективности балансировки.	Большая сложность (вычислительная стоимость) выбора порта для отправки пакета по сравнению с другими политиками. Со стороны коммутатора требуется настроенная группа объединения портов (EtherChannel).	Стандартные сети zVirt Стандартное применение ВМ (разнородные сервисы).
Балансировка по MAC + IP инкапсулированного пакета (layer2+3)	Может выполнять балансировку пакетов, использующих инкапсуляцию сетей (протоколы VXLAN, GENEVE)	Не применимо для трафика, не использующего инкапсуляцию сетей. Большая сложность (вычислительная стоимость) выбора порта для отправки пакета по сравнению с другими политиками. В большинстве сценариев все взаимодействия между двумя ВМ в SDN-сетях будут отправлены через один порт. Требуется настройка группы объединения портов (EtherChannel) на коммутаторах.	Виртуальные сети SDN Хосты, на которых размещены ВМ с функциями вложенной виртуализации, контейнерной виртуализацией или сложными сервисами, использующими несколько IP-адресов.
Балансировка по VLAN и MAC источника (vlan+srcmac)	Низкая сложность (вычислительная стоимость) выбора порта для отправки пакета. Настройка группы объединения портов (EtherChannel) на коммутаторах не обязательна. Политика больше всего приближена к политике балансировки VMware vSphere Route based on the originating virtual port	Наименьшая гранулярность распределения трафика по портам. Возможно получение со стороны ВМ дублирующих пакетов широковещательного трафика.	Стандартные сети zVirt. Сложные топологии физической сети. Стандартное применение ВМ (разнородные сервисы).

Политика балансировки

Преимущества

Недостатки

Область применения

Балансировка по MAC (layer2)

Низкая сложность (вычислительная стоимость) выбора порта для отправки пакета

Низкая гранулярность распределения трафика по портам
Со стороны коммутатора требуется настроенная группа объединения портов (EtherChannel)

Стандартные сети zVirt
Хосты с большим количеством ВМ без преобладания трафика одной/нескольких ВМ над остальными

Балансировка по MAC + IP (layer2+3)

Средняя сложность (вычислительная стоимость) выбора порта для отправки пакета

В большинстве сценариев распределение трафика по портам будет схожим с политикой Балансировка по MAC (layer2).
Требуется настройка группы объединения портов (EtherChannel) на коммутаторах.

Стандартные сети zVirt
Хосты, на которых размещены ВМ с функциями вложенной виртуализации, контейнерной виртуализацией или сложными сервисами, использующими несколько IP-адресов.

Балансировка по IP + Port (layer3+4)

Наибольшая гранулярность распределения трафика по портам для большинства типа трафика.
Не требует анализа трафика для принятия решения о достижимой эффективности балансировки.

Большая сложность (вычислительная стоимость) выбора порта для отправки пакета по сравнению с другими политиками.
Со стороны коммутатора требуется настроенная группа объединения портов (EtherChannel).

Стандартные сети zVirt
Стандартное применение ВМ (разнородные сервисы).

Балансировка по MAC + IP инкапсулированного пакета (layer2+3)

Может выполнять балансировку пакетов, использующих инкапсуляцию сетей (протоколы VXLAN, GENEVE)

Не применимо для трафика, не использующего инкапсуляцию сетей.
Большая сложность (вычислительная стоимость) выбора порта для отправки пакета по сравнению с другими политиками.
В большинстве сценариев все взаимодействия между двумя ВМ в SDN-сетях будут отправлены через один порт.
Требуется настройка группы объединения портов (EtherChannel) на коммутаторах.

Виртуальные сети SDN
Хосты, на которых размещены ВМ с функциями вложенной виртуализации, контейнерной виртуализацией или сложными сервисами, использующими несколько IP-адресов.

Балансировка по VLAN и MAC источника (vlan+srcmac)

Низкая сложность (вычислительная стоимость) выбора порта для отправки пакета.
Настройка группы объединения портов (EtherChannel) на коммутаторах не обязательна.
Политика больше всего приближена к политике балансировки VMware vSphere Route based on the originating virtual port

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

Стандартные сети zVirt.
Сложные топологии физической сети.
Стандартное применение ВМ (разнородные сервисы).

7.5. Проверка работоспособности порта

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

Поддерживаются следующие режимы проверки:

MII (Media Independent Interface) - проверка состояния порта на основе информации от драйвера сетевой карты. Порт в состоянии UP считается работоспособным, порт в состоянии Down или со скоростью 0 считается не работоспособным.
ARP - проверка на основе анализа трафика протокола ARP. Обеспечивает выявление отказов не только отдельного порта, но и всей инфраструктуры портов и оборудования в пределах L2-сегмента. Проверка ARP используется только для режима объединения Active-Backup (Mode 1).

7.5.1. MII

Проверка работоспособности порта MII заключается в периодическом опросе сетевого драйвера относительно текущего статуса порта и применяется преимущественно при подключении узлов zVirt Node к сети.

Проверка MII способна выявить следующие ситуации:

Административное отключение порта со стороны коммутатора или zVirt Node;
Неисправность кабеля/оптического волокна, соединяющего порт сетевой карты zVirt Node и коммутатора;
Неисправность приемо-передающего устройства (оптический модуль);
Некорректная настройка портов со стороны коммутатора и zVirt Node, не позволяющая перевести порт в состояние UP (режим передачи, скорость и т.д.).

При этом проверка не позволяет определить, корректность настроек со стороны коммутатора в соответствии с параметрами bond на стороне zVirt Node (в режиме Dynamic link aggregation такое несоответствие определит протокол LACP) и готовность коммутатора обрабатывать трафик. Для этого на коммутаторе должен быть настроен аналогичный функционал.

На рисунке представлена схема подключения zVirt Node к сетевой инфраструктуре и отработка отказов.

На данной схеме Коммутатор 1 и Коммутатор 2 объединены по технологии MLAG/Stack или аналогичной, что позволяет им обмениваться коммутационной информацией и создавать единую группу объединения(LAG) из Портов 1. Порты 2 коммутаторов служат для синхронизации MLAG/Stack и обмена трафиком, Порты 3 служат для подключения к сети предприятия.

В случае отказа соединения между Порт 1 zVirt Node и Порт 1 Коммутатора 1 произойдет отработка механизма MII со стороны интерфейса bond0, что автоматически приведет к переносу всего трафика на Порт 2 со стороны zVirt Node. Коммутатор 1 аналогично должен определить отказ порта и перевести весь трафик на Порт 1 Коммутатора 2. За счет использования технологии MLAG/Stack и синхронизации коммутаторов трафик, проходящий из сети предприятия в стону zVirt Node через Коммутатор 1 будет перенаправлен через Коммутатор 2.

При отказе Порта 3 Коммутатора 2 аналогично весь трафик будет доставлен, ВМ в сетях

Для проверки MII возможно настроить следующие параметры:

Период проверки, мс (miimon) - периодичность опроса состояния порта. Данный параметр обозначает временной промежуток, в течение которого пакеты могут быть потеряны с момента отказа соединения до момента детектирования отказа и переноса трафика. Рекомендуемое значение - 1000 мс (1 секунда), большинство протоколов способны корректно отработать потерю трафика в течение указанного времени.
Задержка отключения порта, мс (downdelay) - промежуток времени от момента выявления потери соединения до исключения порта из работы и перенаправления трафика на другой порт. Применяется в случаях, когда в физической сети наблюдается нестабильная работа с кратковременными потерями сигнала на порте, не требующими перемещения трафика с порта.
Задержка активации интерфейса, мс (updelay) - время, прошедшее от момента определения восстановления или повторного включения порта до его активации в составе группы объединения (перенос на этот порт трафика). Применяется в случаях, когда физическая сеть работает нестабильно, происходят частые кратковременные переподключения порта или со стороны коммутатора требуется время для готовности принимать трафик на активном порту.

7.5.2. ARP

Анализ работоспособности порта на основе ARP-трафика позволяет выявлять отказ соединения не только между портом zVirt Node и коммутатором, но и на пути следования трафика до маршрутизатора (в рамках широковещательного домена). Данная проверка актуальна для режима Active-Backup (Mode 1), так как в нём допускается подключение портов одного bond(группы объединения со стороны zVirt Node) к независимым коммутаторам, не имеющим прямого соединения между собой. На рисунке представлена схема подключения zVirt Node к двум коммутаторам, имеющим общее соединение с устройством, выполняющим роль шлюза в сети. Проверка, основанная на анализе ARP-трафика, позволяет определить отказ соединения между Маршрутизатором и Коммутатором 1 и переключить трафик на Порт 2 zVirt Node.

Алгоритм проверки работоспособности порта на основе анализа трафика ARP-протокола следующий:

Активный порт в составе bond периодически отправляет ARP-запрос к проверочному адресу, который часто является шлюзом сети.
Поскольку ARP-запросы распространяются широковещательно, то данные запросы достигают как "проверочного" адреса, так и неактивного порта в составе bond.
Получив запрос Проверочный адрес формирует ответ, который возвращается обратно на активный порт.
В зависимости от выбранного параметра Политика проверки (arp_validate) принимается решение о работоспособности каждого порта.
На основе принятого решения о работоспособности портов выполняется назначение/сохранение активной роли порта.

Важно учитывать, что IP-адреса на портах в составе bond и проверочные адреса должны быть в нетегированной сети.

Для проверки ARP возможно настроить следующие параметры:

Интервал проверки, мс (arp_interval) - интервал проверки в миллисекундах. Значение 0 - отключить проверку.
Список проверочных IP (arp_ip_target) - перечень IP-адресов для проверки методом ARP (проверочные адреса). Допускается добавлять до 16 адресов.
Политика проверки (arp_validate) - политика проверки, указывающая как будет определяться работоспособный и неработоспособный порты.
Количество доступных IP (arp_all_targets) - параметр, указывающий, сколько проверочных адресов должны быть доступны: любой IP-адрес из списка (достаточно ответа от одного проверочного адреса) или все IP-адреса из списка (если хотя бы один адрес не ответит на запрос, то проверка считается не успешной).

Название политики	Условие проверки активного порта	Условия проверки неактивного порта	Сценарии использования
любой трафик / любой трафик (none 0)	Порт считается работоспособными, если получает любой трафик.	Порт считается работоспособными, если получает любой трафик.	Диагностика подключения, временное упрощение/ослабление политики. Данная политика схожа с методом MII тем, что отсутствие трафика наиболее вероятно из-за отказа соединения. Таким образом проверяется непосредственно соединение до порта zVirt Node с ограничениями.
ответ ARP / любой трафик (active 1)	Порт считается работоспособными, если получает ответ от проверочного(-ых) IP.	Порт считается работоспособными, если получает любой трафик.	Используется в сетевых топологиях, где активный и неактивный порты находятся в сегментированных с точки зрения L2-доменах. В таких конфигурациях широковещательный запрос активного порта не достигает неактивного порта и фактически, с помощью метода ARP проверяется только состояние активного порта. В итоге проверка сводится к тому, активный порт контролирует доступность шлюза или проверочного адреса, а состояние неактивного порта оценивается косвенно — проверяется наличие физического соединения между коммутатором и самим неактивным портом.
любой трафик / запрос ARP (backup 2)	Порт считается работоспособными, если получает любой трафик.	Порт считается работоспособными, если получает ARP-запрос (широковещательный трафик) от активного порта.	Фактически методом ARP проверяется неактивный порт. Подходит для тех топологических схем, где проверяемый адрес физически отсутствует, следовательно, соответственно ответа от него не может быть. Рекомендуется использовать в ситуациях, когда коммутаторы, к которым подключены узлы zVirt Node, становятся единой точкой отказа, как показано на приведённой ранее схеме.
ответ ARP / запрос ARP (all 3)	Порт считается работоспособными, если получает ответ от проверочного IP-адреса.	Порт считается работоспособными, если получает ARP-запрос от активного порта.	Наиболее предпочтительный вариант проверки, при котором однозначно определяется работоспособность соединений от портов bond до сетевого шлюза. Рекомендуется в качестве проверочного IP-адреса использовать отказоустойчивый адрес (шлюз), чтобы временный отказ шлюза сети не приводил к переключению портов.
любой ARP / любой ARP (filter 4)	Порт считается работоспособными, если получает любой трафик протокола ARP. Остальной трафик отфильтровывается и не учитывается для определения работоспособности порта.	Порт считается работоспособными, если получает любой трафик протокола ARP. Остальной трафик отфильтровывается и не учитывается для определения работоспособности порта.	Политика аналогична политике любой трафик / любой трафик (none 0), но отличается тем, что оценка работоспособности основывается не на общем объёме трафика, а исключительно на трафике протокола ARP. Может быть применима в сетях, где большой объем широковещательного трафика.
ответ ARP / любой ARP (filter active 5)	Порт считается работоспособными, если получает ARP-ответ от проверочного(ых) IP.	Порт считается работоспособными, если получает любой трафик протокола ARP. Остальной трафик отфильтровывается и не учитывается для определения работоспособности порта.	Политика аналогична политике ответ ARP / любой трафик (active 1), но отличается тем, что оценка работоспособности основывается не на общем объёме трафика, а исключительно на трафике протокола ARP. Может быть применима в сетях, где большой объем широковещательного трафика.
любой ARP / запрос ARP (filter backup 6)	Порт считается работоспособными, если получает любой трафик протокола ARP.	Порт считается работоспособными, если получает ARP-запрос от активного порта.	Политика аналогична политике любой трафик / запрос ARP (backup 2) но отличается тем, что оценка работоспособности основывается не на общем объёме трафика, а исключительно на трафике протокола ARP. Может быть применима в сетях, где большой объем широковещательного трафика.

Название политики

Условие проверки активного порта

Условия проверки неактивного порта

Сценарии использования

любой трафик / любой трафик (none 0)

Порт считается работоспособными, если получает любой трафик.

Диагностика подключения, временное упрощение/ослабление политики. Данная политика схожа с методом MII тем, что отсутствие трафика наиболее вероятно из-за отказа соединения. Таким образом проверяется непосредственно соединение до порта zVirt Node с ограничениями.

ответ ARP / любой трафик (active 1)

Порт считается работоспособными, если получает ответ от проверочного(-ых) IP.

Порт считается работоспособными, если получает любой трафик.

Используется в сетевых топологиях, где активный и неактивный порты находятся в сегментированных с точки зрения L2-доменах. В таких конфигурациях широковещательный запрос активного порта не достигает неактивного порта и фактически, с помощью метода ARP проверяется только состояние активного порта. В итоге проверка сводится к тому, активный порт контролирует доступность шлюза или проверочного адреса, а состояние неактивного порта оценивается косвенно — проверяется наличие физического соединения между коммутатором и самим неактивным портом.

любой трафик / запрос ARP (backup 2)

Порт считается работоспособными, если получает любой трафик.

Порт считается работоспособными, если получает ARP-запрос (широковещательный трафик) от активного порта.

Фактически методом ARP проверяется неактивный порт. Подходит для тех топологических схем, где проверяемый адрес физически отсутствует, следовательно, соответственно ответа от него не может быть. Рекомендуется использовать в ситуациях, когда коммутаторы, к которым подключены узлы zVirt Node, становятся единой точкой отказа, как показано на приведённой ранее схеме.

ответ ARP / запрос ARP (all 3)

Порт считается работоспособными, если получает ответ от проверочного IP-адреса.

Порт считается работоспособными, если получает ARP-запрос от активного порта.

Наиболее предпочтительный вариант проверки, при котором однозначно определяется работоспособность соединений от портов bond до сетевого шлюза. Рекомендуется в качестве проверочного IP-адреса использовать отказоустойчивый адрес (шлюз), чтобы временный отказ шлюза сети не приводил к переключению портов.

любой ARP / любой ARP (filter 4)

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

Политика аналогична политике любой трафик / любой трафик (none 0), но отличается тем, что оценка работоспособности основывается не на общем объёме трафика, а исключительно на трафике протокола ARP. Может быть применима в сетях, где большой объем широковещательного трафика.

ответ ARP / любой ARP (filter active 5)

Порт считается работоспособными, если получает ARP-ответ от проверочного(ых) IP.

Политика аналогична политике ответ ARP / любой трафик (active 1), но отличается тем, что оценка работоспособности основывается не на общем объёме трафика, а исключительно на трафике протокола ARP. Может быть применима в сетях, где большой объем широковещательного трафика.

любой ARP / запрос ARP (filter backup 6)

Порт считается работоспособными, если получает любой трафик протокола ARP.

Порт считается работоспособными, если получает ARP-запрос от активного порта.

Политика аналогична политике любой трафик / запрос ARP (backup 2) но отличается тем, что оценка работоспособности основывается не на общем объёме трафика, а исключительно на трафике протокола ARP. Может быть применима в сетях, где большой объем широковещательного трафика.

7.6. Конфигурация коммутатора для бондинга

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

Для каждого типа коммутатора важно настроить бондинг коммутатора по протоколу Link Aggregation Control Protocol (LACP), а не по протоколу Cisco Port Aggregation Protocol (PAgP).

8. Виртуальные сетевые карты (vNICs)

Виртуальные сетевые карты (vNIC) — это виртуальные сетевые интерфейсы, основанные на физических сетевых картах хоста. У каждого хоста может быть несколько сетевых карт, и каждая сетевая карта может быть базой для нескольких vNIC.

При подключении vNIC к виртуальной машине Менеджер управления создает несколько ассоциаций между виртуальной машиной, к которой подключена vNIC, самой vNIC и сетевой картой физического хоста, на которой базируется vNIC. Так, когда vNIC подключена к виртуальной машине, новая vNIC и MAC-адрес создаются на сетевой карте физического хоста, на которой базируется vNIC. Как только виртуальная машина запускается первый раз после подключения этой vNIC, libvirt назначает PCI-адрес для vNIC. Затем MAC-адрес и PCI-адрес используются для получения имени vNIC (например, eth0) на виртуальной машине.

Процесс назначения MAC-адресов и ассоциирования этих MAC-адресов с PCI-адресами несколько отличается при создании виртуальных машин на основе шаблонов или снимков:

Если PCI-адреса уже были созданы для шаблона или снимка, то виртуальные сетевые карты (vNIC) на виртуальных машинах, созданных на основе этого шаблона или снимка, упорядочиваются по этим PCI-адресам. Затем MAC-адреса распределяются на vNIC в этом порядке.
Если PCI-адреса еще не были созданы для шаблона, то виртуальные сетевые карты (vNIC) на виртуальных машинах, созданных на основе этого шаблона, упорядочиваются по алфавиту. Затем MAC-адреса распределяются на vNIC в этом порядке.
Если PCI-адреса еще не были созданы для снимка, то Менеджер управления распределяет новые MAC-адреса на vNIC на виртуальных машинах, созданных на основе этого снимка.

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

При запуске команды ip addr show на хосте виртуализации отображаются все vNIC, ассоциированные с виртуальными машинами на этом хосте. Также видны все сетевые мосты, которые были созданы для поддержки логических сетей, и все сетевые карты, используемые хостом.

[root@host-01 ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:21:86:a2:85:cd brd ff:ff:ff:ff:ff:ff
    inet6 fe80::221:86ff:fea2:85cd/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:21:6b:cc:14:6c brd ff:ff:ff:ff:ff:ff
5: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 4a:d5:52:c2:7f:4b brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
7: bond4: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
10: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
11: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:21:86:a2:85:cd brd ff:ff:ff:ff:ff:ff
    inet 10.64.32.134/23 brd 10.64.33.255 scope global ovirtmgmt
    inet6 fe80::221:86ff:fea2:85cd/64 scope link
       valid_lft forever preferred_lft forever

Консольный вывод команды отображает несколько устройств: одно loopback-устройство (lo), одно Ethernet-устройство (eth0), одно беспроводное устройство (wlan0), одно фиктивное устройство VDSM (;vdsmdummy;), пять bond-устройств (bond0, bond4, bond1, bond2, bond3) и один сетевой мост (ovirtmgmt).

Все vNIC входят в устройство сетевого моста и логическую сеть. Членство в мосте может быть отображено с помощью команды brctl show:

[root@host-01 ~]# brctl show
bridge name bridge id  STP enabled interfaces
ovirtmgmt  8000.e41f13b7fdd4 no  vnet002
       vnet001
       vnet000
       eth0

Консольный вывод команды brctl show показывает, что vNIC virtio - члены моста ovirtmgmt. Все виртуальные машины, с которыми ассоциированы vNIC, подключены к логической сети ovirtmgmt. Сетевая карта eth0 также является членом моста ovirtmgmt. Устройство eth0 подключено к коммутатору, который обеспечивает подключение за пределами хоста.

9. Виртуальная локальная сеть (VLAN)

VLAN (виртуальная локальная сеть) - это атрибут, применимый к сетевым пакетам. Сетевые пакеты могут быть "тегированы" в пронумерованную сеть VLAN. VLAN - функция безопасности, используемая для изоляции сетевого трафика на уровне коммутатора. Сети VLAN отделены друг от друга и являются взаимоисключающими. Менеджер управления знает о VLAN и может тегировать и перенаправлять трафик, но для реализации VLAN требуется коммутатор, поддерживающий VLAN.

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

10. Метки сети

Метки сети можно использовать для упрощения некоторых административных задач, связанных с созданием и администрированием логических сетей, а также ассоциированием этих логических сетей с сетевыми интерфейсами физического хоста и bond-интерфейсами.

Метка сети — это метка в виде читаемого текста, которую можно подключить к логической сети или сетевому интерфейсу физического хоста. При создании метки руководствуйтесь следующими правилами:

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

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

Ассоциации меток сети

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

Метки сети и кластеры

Когда логическая сеть с меткой добавляется в кластер, и в этом кластере есть сетевой интерфейс физического хоста с такой же меткой, логическая сеть автоматически добавляется в этот сетевой интерфейс физического хоста.
Когда логическая сеть с меткой отключается от кластера, и в этом кластере есть сетевой интерфейс физического хоста с такой же меткой, логическая сеть автоматически отключается от этого сетевого интерфейса физического хоста.

Метки сети и логические сети с ролями

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

11. Сетевые подключения кластера

Сетевые объекты на уровне кластера включают в себя:

Кластеры
Логические сети

Центр данных — это логическая группа из нескольких кластеров, при этом каждый кластер — это логическая группа из нескольких хостов. Содержимое отдельного кластера показано на следующей диаграмме:

Рисунок 2. Сетевые подключения внутри кластера

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

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

12. Логические сети

Логические сети позволяют среде zVirt разделять сетевой трафик по типам. Например, сеть ovirtmgmt создается по умолчанию во время установки zVirt и используется для управления взаимодействием между Менеджером управления и хостами. Обычно логические сети используются для группировки сетевого трафика, к которому предъявляются аналогичные требования и который используется похожим образом. Во многих случаях сеть хранения и сеть отображения создаются администратором для изоляции трафика каждого соответствующего типа в целях оптимизации и устранения ошибок.

zVirt поддерживает следующие типы логических сетей:

Логические сети, передающие только сетевой трафик хостов, например трафик хранения или миграции
Логические сети, передающие сетевой трафик хостов и виртуальных машин
Логические сети, передающие только сетевой трафик виртуальных машин, например, сети OVN

Логические сети определяются на уровне центра данных.

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

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

Системный администратор хочет протестировать веб-сервер с помощью логической сети.

В центре данных Purple в кластере Pink есть два хоста: Red и White. Как хост Red, так и хост White по умолчанию используют логическую сеть ovirtmgmt для всех сетевых функций. Системный администратор, ответственный за кластер Pink, решил изолировать сетевое тестирование веб-сервера, поместив веб-сервер и некоторые клиентские виртуальные машины в отдельную логическую сеть. Он решил назвать новую логическую сеть test_logical_network.

Он создал новую логическую сеть под именем test_logical_network для центра данных Purple с возможностью тегирования VLAN. Тегирование VLAN необходимо, когда две логические сети подключены к одной и той же физической сетевой карте. Он применил test_logical_network к кластеру Pink.
На хосте Red он подключил test_logical_network к физической сетевой карте, которая будет включена в мост, созданный Менеджером управления. Сеть не работала, пока системный администратор не установил соответствующий мост на всех хостах в кластере, добавив физический сетевой интерфейс на каждом хосте в кластере Pink к test_logical_network, а потом сделав то же самое на хосте White. Когда на обоих хостах White и Red логическая сеть test_logical_network через мост подключена к физическому сетевому интерфейсу, она готова к работе и использованию виртуальными машинами.
Системный администратор ассоциирует виртуальные машины на хостах Red и White с новой сетью.

13. Обязательные сети, опциональные сети и сети виртуальных машин

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

Опциональная сеть - это логическая сеть, которая не была явно обозначена как Обязательная (Required). Опциональные сети можно реализовать только на использующих их хостах. Наличие или отсутствие опциональных сетей не влияет на статус работоспособности (Operational status) хоста. Когда необязательная сеть становиться неработоспособной, виртуальные машины, работающие в этой сети, не переносятся на другой хост, что позволяет избежать избыточных операций ввода/вывода, связанных с массовой миграцией. Обратите внимание, что при создании логической сети и добавлении ее в кластеры флажок Обязательная (Required) стоит по умолчанию.

Чтобы изменить обозначение сети как Обязательной (Required), на Портале администрирования в разделе Сеть перейдите в подраздел Сети, выберите нужную сеть, откройте вкладку Кластеры (Clusters) и нажмите кнопку Управление сетью (Manage Network).

Сеть виртуальных машин с отметкой Сеть ВМ (VM network, network vm ) в пользовательском интерфейсе - это логическая сеть, предназначенная для передачи только сетевого трафика виртуальных машин. Сеть виртуальных машин может быть обязательной или опциональной. Виртуальные машины, использующие опциональную сеть ВМ, запускаются только на хостах с этой сетью.

14. Зеркалирование портов (Port Mirroring)

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

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

Зеркалирование портов включается или выключается в профилях vNIC логических сетей и имеет следующие ограничения:

Горячая привязка vNIC к профилю, в котором включено зеркалирование портов, не поддерживается.
Зеркалирование портов нельзя изменить, когда профиль vNIC подключен к виртуальной машине.

Учитывая вышеуказанные ограничения, рекомендуется включить зеркалирование портов на дополнительном выделенном профиле vNIC .

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

15. Сетевые конфигурации хоста

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

К основным типам сетевых конфигураций относятся:

Конфигурация "Мост и сетевая карта" (Bridge and NIC configuration).

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

Пример этой конфигурации - автоматическое создание сети ovirtmgmt при установке Менеджера управления. Затем во время установки хоста Менеджер управления устанавливает VDSM на хосте. В результате установки VDSM создается мост ovirtmgmt, который получает IP-адрес хоста для обеспечения связи с Менеджером управления.

Конфигурация "Мост, VLAN и сетевая карта" (Bridge, VLAN, and NIC configuration).

VLAN может быть включена в конфигурацию "Мост и сетевая карта", чтобы обеспечить безопасный канал для передачи данных по сети. В этой конфигурации возможно подключение нескольких мостов к одной сетевой карте, использующей несколько VLAN.
Конфигурация "Мост, bond-интерфейс и VLAN" (Bridge, Bond, and VLAN configuration).

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

Конфигурация "Несколько мостов, несколько VLAN и сетевая карта" (Multiple Bridge, Multiple VLAN, and NIC configuration).

Конфигурация подключает сетевую карту к нескольким сетям VLAN.

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

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