Vmware distributed switch настройка

Обновлено: 02.07.2024

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

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

А в случае создания распределенного коммутатора вы получаете один-един-ственный (логически) коммутатор, существующий сразу на всех серверах ESX(i).

Вы настраиваете только этот, логически единый коммутатор. Новую группу портов из примера выше вы создадите один раз, и она появится для всех серверов ESX(i), входящих в распределенный коммутатор.

ВМ, даже при миграции с сервера на сервер, остаются не только на том же коммутаторе, но и даже на том же порту распределенного виртуального коммутатора (это называют Network vMotion). Это позволяет проще настраивать политики безопасности, осуществлять мониторинг трафика ВМ, привязываясь даже к отдельному порту вКоммутатора.

В отличие от стандартных виртуальных коммутаторов VMware, distributed vSwitch поддерживают Private VLAN и двухсторонний traffic shaping (о том, что это такое, см. в разделах 2.4.2 и 2.4.4). В версии 4.1 в список уникальных возможностей распределенных коммутаторов добавились такие функции, как:

- Network IO Control - возможность гибко настраивать минимально и максимально доступные ресурсы пропускной способности для трафика разных типов. Подробности о NIOC см. в главе 6, посвященной распределению ресурсов;

- Load Based Teaming - балансировка нагрузки между физическими контроллерами одного вКоммутатора в зависимости от нагрузки на каждый контроллер.

Еще один плюс - распределенный вКоммутатор доступен в реализациях от VMware и от Cisco.

Вариант от Cisco, распределенный виртуальный коммутатор Cisco Nexus 1000V, приобретается независимо от vSphere (но подойдет не любая лицензия vSphere, на момент написания - только Enterprise Plus). Он обладает всеми возможностями, присущими сетевому оборудованию от Cisco. Позволяет добиться того, что все используемые коммутаторы в сети компании созданы одним производителем (здесь имеется в виду Cisco), и сетевые администраторы могут управлять ими точно так же, как коммутаторами физическими, снимая, таким образом, эти задачи с администратора vSphere. Однако рассмотрение настроек и возможностей этого решения в данной книге описано не будет.

Здесь будет описан распределенный виртуальный коммутатор от VMware. Возможность им пользоваться появляется после активации лицензии, дающей на него право, - сегодня это vSphere Enterprise Plus (и ее ознакомительный 60-дневный период после установки vSphere, Evaluation-лицензия).

Как я уже сказал, dvSwitch - объект скорее логический, как таковой существующий только для vCenter. Мы создали один распределенный вКоммутатор, но на каждом сервере, для которых он существует, автоматически создаются стандартные вКоммутаторы, скрытые от нас (рис. 2.11). Таким образом, де-факто распределенный коммутатор является шаблоном настроек. Мы создаем его и указываем настройки в vCenter - это control plane по документации VMware, то есть уровень управления. А после включения в созданный распределенный коммутатор серверов ESX(i) vCenter создает на них стандартные коммутаторы, скрытые от нас. По документации VMware это IO Plane, прикладной уровень. За всю работу отвечают скрытые коммутаторы на серверах ESX(i), все управление осуществляется только через vCenter.

Рис. 2.11. Иллюстрация сути распределенного виртуального коммутатора Источник: VMware

Минусом такой схемы распределенного виртуального коммутатора VMware является возросшая сложность, в частности зависимость от vCenter. vCenter является управляющим элементом для dvSwitch, и при недоступности vCenter у администратора нет возможности менять настройки распределенного коммутатора и даже переключать виртуальные машины на другие группы портов. Однако даже при недоступности vCenter сеть будет продолжать работать - ведь за техническую сторону вопроса отвечают скрытые от нас коммутаторы на каждом ESX(i), теряется только возможность изменения настроек.

Кстати, подключение самого vCenter к распределенному коммутатору не поддерживается VMware.

Подключитесь клиентом vSphere к vCenter. Предполагается, что в иерархии vCenter уже создан объект Datacenter, уже добавлены серверы. Распределенный виртуальный коммутатор создается для объекта Datacenter, и существовать для серверов из разных Datacenter один dvSwitch не может.

Пройдите Home ^ Networking. В контекстном меню объекта Datacenter выберите пункт New vNetwork Distributed Switch.

В запустившемся мастере нас спросят:

- Name - имя создаваемого вКоммутатора. Влияет только на удобство;

- Number of dvUplink ports - максимальное количество подключений ко внешней сети - привязанных vmnic - на каждом сервере. Обратите внимание: один такой вКоммутатор может существовать для серверов с разной конфигурацией, с разным количеством доступных сетевых контроллеров -а здесь мы ограничиваем максимальное число используемых для данного dvSwitch контроллеров на одном сервере;

- дальше вам предложат выбрать серверы, для которых будет существовать создаваемый вКоммутатор. Выбор можно осуществить или изменить позже. Если будете выбирать серверы сейчас, то вам покажут свободные физические сетевые контроллеры на каждом выбранном сервере - и вы сможете выбрать те из них, что будут использоваться для создаваемого вКоммута-тора. По ссылке View Details вам покажут исчерпывающую информацию о физическом сетевом контроллере - драйвер, производитель, статус подключения (link status), PCI-адрес, доступные через него подсети IP - не покажут здесь только MAC-адрес;

- на последнем шаге можно будет снять флажок Automatically create a default port group. Если он стоит, то автоматически будет создана группа портов со 128 портами и именем по умолчанию. Имя по умолчанию малоинформативно, поэтому я рекомендую этот флажок снимать и создавать группу портов самостоятельно, после создания вКоммутатора.

Обратите внимание. У стандартных вКоммутаторов число портов настраивается для них самих, группы портов «безразмерные». У распределенных вКоммутаторов наоборот. Вы можете создать до 248 распределенных виртуальных коммутаторов для сервера. На одном сервере может быть до 4096 портов стандартных и распределенных вКоммутаторов. Это означает, что если не задавать заведомо огромных значений числа портов, то с ограничениями с этой стороны вы не столкнетесь.

Когда вы создали dvSwitch, то на странице Home ^ Inventory ^ Networking вы видите картинку примерно как на рис. 2.12.

Здесь «Demo_dvSwitch» - это сам объект - распределенный вКоммутатор. Объект «Demo_dvSwitch-DVUplinks-28» - это группа портов, в которую объединены его подключения ко внешним сетям. То есть те порты вКоммутатора, к ко-

Рис. 2.12. Свежесозданный dvSwitch

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

Ну и «Demo_dvPortGroup» - созданная вручную группа портов, туда можно подключать ВМ, а также виртуальные сетевые контроллеры Service Console и VMkernel.

Обратите внимание. При использовании стандартных виртуальных коммутаторов невозможно поместить в одну группу портов виртуальные машины и интерфейс VMkernel или Service Console. На распределенных виртуальных коммутаторах VMware это возможно, на dvSwitch в одной группе портов могут сосуществовать и ВМ, и интерфейсы SC и VMkernel в любых сочетаниях.

Кстати говоря, объект «VM Network» на этом рисунке - это группа портов на стандартных виртуальных коммутаторах серверов этого vCenter.

Тут собираю интересное по интересующей меня теме виртуализации.

Главная страница
Книга по vSphere
Performance - как правильно мониторить
VMware Certification
Курсы VMware
Подборка важных материалов

Подпишись на обновления по RSS

Посты по email

Обо мне

Последние комментарии

Подпишись на комментарии

Комментарии Комментарии

Архив блога

Ярлыки

воскресенье, 28 ноября 2010 г.

VLAN + vSphere Distributed Switch + HP GbE2c Layer 2/3

Мне приходится вести довольно обширную переписку. Угадайте по какой теме :)

Может быть, не всегда есть возможность ответить развернуто, а иногда ответ я и не знаю, но без внимания я не оставляю ни одного письма.

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

Настройка VLAN на vSphere Distributed Switch и блейд-свитче HP GbE2c Layer 2/3.

Давайте рассмотрим задачу организации сети с несколькими vlan на распределенном свитче.

Когда и кому это может понадобиться?

Рассмотрим конкретную практическую задачу.

Есть хост ESX(блейд-лезвие), с четырьмя сетевыми интерфейсам подключенный в блейд-свитч HP GbE2c Layer 2/3. Один интерфейс ESX хоста, как описывалось выше, отведен под Service Console, а второй VMkernel Port для vMotion. Двум оставшимся интерфейсам соответствуют два распределенных свитча Distributed Switch 1&2, позволяющие вывести две группы виртуальных машины в две изолированных сети. Появляется третья группа виртуальных машин, которым необходима третья изолированная сеть. Решено настроить vlan`ы на одном из двух существующих распределенных свитчей.

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

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

Настройка очень проста. Каждая группа портов виртуального распределенного свитча, соответствующая отдельной изолированной сети, должна находиться в отдельном vlan`е. Порты-аплинки между свитчами, должны быть сконфигурированы как tagged порты (т.е. могут пропускать через себя трафик разных vlan`ов).

Для распределенного коммутатора Distributed Switch 2 необходимо сделать следующие настройки:

1. Создаем 2-е группы портов на одном распределенном коммутаторе.

2. В настройках 1-й группы портов в пункте VLAN указать VLAN Type = VLAN и задать VLAN ID (для текущего примера VID=6).

3. В настройках 2-й группы портов в пункте VLAN указать VLAN Type = VLAN и задать VLAN ID (для текущего примера VID=5).

4. В настройках Uplink-группы в пункте VLAN указать VLAN Type = VLAN Trunking. В поле VLAN trunk range указать VLAN ID, для vlan, созданных выше.

На этом вся конфигурации виртуальной среды завершена. Остается настроить физический блейд-свитч.

Ниже приведена настройка для свитча HP GbE2c Layer 2/3. Хосты ESX подключены к внутренним портам 1,2,9,10. Порт 21, 23 внешние аплинки в разные сети.

Включаем тегирование и задаем default vlan внутренних портов.

/cfg/port 1
tag e
pvid 5
/cfg/port 2
tag e
pvid 5
/cfg/port 9
tag e
pvid 5
/cfg/port 10
tag e
pvid 5

Создаем Vlan, включаем их, задаем имя и порты

В данной статье мы рассмотрим пример настройки агрегации для 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, о чём нас дополнительно информируют.

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

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

Введение в виртуализированный VMware 10 - Введение в распределенный коммутатор (распределенный коммутатор)

Distributed Switch

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

vSphere Distributed Switch (VDS) позволяет настроить коммутацию доступа к виртуальным машинам для всего центра обработки данных из централизованного интерфейса, что упрощает сетевые подключения виртуальных машин. VDS может предоставить:

· Упрощенная конфигурация сети виртуальной машины

· Более мощные функции сетевого мониторинга и устранения неполадок

· Поддержка расширенного vSphere Функция сетевого подключения

Упростите настройку сети виртуальной машины

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

Централизованное управление конфигурацией портов виртуального коммутатора, именованием групп портов, настройками фильтров и т. Д.

Link Aggregation Control Protocol (LACP) - согласование и автоматическая настройка агрегации каналов между хостом vSphere и физическим коммутатором уровня доступа.

· Имеется функция проверки работоспособности сети, с помощью которой можно проверить конфигурацию vSphere для физической сети.

Более мощные функции сетевого мониторинга и устранения неполадок

vSphere Distributed Switch обеспечивает широкие возможности мониторинга и устранения неполадок для ваших сотрудников, работающих с сетевым подключением.

· Поддерживает протоколы RSPAN и ERSPAN, обеспечивая удаленный анализ сети.

IPFIX Netflow версии 10

· Функции отката и восстановления для исправления и обновления конфигурации сети

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

· Сетевой дамп ядра (сетевой дамп), хост отладки без локального хранилища

Поддержка расширенных сетевых функций vSphere

Распределенный коммутатор vSphere предоставляет строительные блоки для многих расширенных сетевых функций в среде vSphere.

Основной строительный блок Network I / O Control (NIOC)

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

· Поддержка сторонних расширений виртуальных коммутаторов, таких как виртуальные коммутаторы CiscoNexus 1000V и IBM 5000v.

· Поддержка SR-IOV (виртуализация ввода-вывода с одним корнем) для достижения низкой задержки и высокой рабочей нагрузки ввода-вывода

Функция фильтрации BPDU не позволяет виртуальной машине отправлять BPDU на физический коммутатор.

Подробная техническая информация

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

vSphere Сетевой коммутатор можно разделить на две логические части. Эти две части - плата данных и плата управления.

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

Панель управления - это структура управления, используемая оператором для настройки функций платы данных. . В стандартном коммутаторе vSphere (VSS) каждый стандартный коммутатор имеет плату данных и плату управления. Такой дизайн позволяет администратору настраивать и поддерживать каждую VSS отдельно.

VMware В выпуске vSphere 4.0 При запуске vSphere Distributed Switch 。 VDS Рассмотрение сети как агрегированного ресурса снижает нагрузку на управление каждой конфигурацией виртуального коммутатора на уровне хоста. Виртуальные коммутаторы на каждом уровне хоста абстрагируются в большой VDS, который охватывает несколько хостов на уровне центра обработки данных. В этой конструкции плата данных хранится локально для каждого VDS, но плата управления использует централизованный механизм, используя vCenter Server в качестве точки управления для всех настроенных экземпляров VDS.

Каждая служба vCenter r Экземпляр может поддерживать до 128 А VDS , Каждый VDS Может управлять до 500 Хосты. В VDS используются многие концепции, связанные с настройкой и управлением стандартного коммутатора, но также были внесены некоторые изменения, чтобы можно было управлять несколькими коммутаторами.

Распределенная группа виртуальных портов (группа портов DV)Это группа портов, связанная с VDS, и параметры конфигурации порта указываются для каждого порта-члена. Группа портов DV определяет способ подключения к сети через VDS. Параметры конфигурации аналогичны параметрам группы портов на стандартном коммутаторе. Здесь настраиваются идентификатор VLAN, параметры настройки трафика, безопасность порта, группировка и балансировка нагрузки, а также другие параметры. Каждый VDS поддерживает до 10 000 статических групп портов.

Распределенный виртуальный восходящий канал (dvUplink)Это новая концепция, представленная в VDS. dvUplink обеспечивает уровень абстракции для физической сетевой карты (vmnic) на каждом хосте. Стратегии связывания сетевых карт, балансировки нагрузки и переключения при отказе в группах портов VDS и DV применяются к dvUplink, а не к vmnics на отдельных хостах. Каждый vmnic на каждом хосте сопоставляется с dvUplink, поэтому независимо от того, как выделяется vmnic, группировка и переключение при отказе могут быть согласованными.

преданный VLAN

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

Network vMotion

Когда виртуальная машина перемещается с одного хоста на другой в VDS, Network vMotion отслеживает состояние сетевого подключения виртуальной машины (например, счетчики и статистику портов). Таким образом, независимо от расположения виртуальной машины или истории миграции vMotion, может быть предоставлено согласованное представление виртуального сетевого интерфейса. Использование vMotion для миграции виртуальных машин между хостами может значительно упростить мониторинг сети и устранение неполадок.

Двухсторонняя регулировка потока

VDS расширяет функцию корректировки исходящего трафика стандартного коммутатора до функции корректировки двустороннего трафика. Политики корректировки исходящего (от виртуальной машины к сети) и текущего входящего (от сети к виртуальной машине) трафика в настоящее время могут применяться к определениям групп DV-портов. Если вы хотите ограничить поток в виртуальную машину или группу виртуальных машин или из них, чтобы защитить виртуальную машину или другой трафик в сети с избыточной подпиской, настройка потока очень полезна. Стратегия определяется тремя характеристиками: средней полосой пропускания, максимальной пропускной способностью и размером пакета.

Поддержка сторонних виртуальных коммутаторов

VDS имеет масштабируемость коммутатора и может легко интегрировать сторонние платы управления, платы данных и пользовательские интерфейсы. К ним относятся Cisco Nexus 1000v и IBM 5000v.

Улучшения vSphere 5.1 VDS

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

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

3. Привязка сетевого адаптера

Эта функция отправляет и принимает пробные пакеты Ethernet уровня 2 через физический интерфейс восходящей линии связи VDS через определенные интервалы времени. В зависимости от конфигурации сетевого устройства, напрямую подключенного к VDS через физический интерфейс восходящей линии связи, пакеты REQ и ACK принимаются или отклоняются. При отбрасывании пакетов система укажет на проблему конфигурации и отобразит предупреждение в представлении VMware vSphere® Client ™.

Резервное копирование и восстановление конфигурации VDS

Конфигурация VDS управляется через vCenter Server, и все детали конфигурации виртуальной сети хранятся в базе данных VMware vCenter ™. vSphere 5.1 добавляет функцию резервного копирования и восстановления информации о конфигурации VDS. Пользователи могут делать снимки конфигурации VDS и конфигурации на уровне группы портов. Информация резервного копирования VDS может использоваться для создания системы контроля версий для отслеживания и контроля изменений конфигурации виртуальной сети. Это позволяет пользователю восстановить любую предыдущую конфигурацию сети, включая восстановление после сбоя базы данных vCenter Server. Сохраненную конфигурацию VDS также можно использовать в качестве шаблона для создания аналогичных конфигураций VDS в других средах.

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

Сеть управления vSphere настраивается на каждом хосте и используется для связи с vCenter Server и взаимодействия с другими хостами во время настройки и работы VMware vSphere® High Availability (vSphere HA). Это важно для централизованного управления хостами через vCenter Server. Если сеть управления на хосте отключена или неправильно настроена, vCenter Server не сможет подключиться к хосту и не сможет централизованно управлять инфраструктурой vSphere. К

Функция автоматического отката и восстановления, представленная в vSphere 5.1, решает проблему всех пользователей, использующих сеть управления на VDS. Во-первых, функция автоматического отката автоматически обнаружит любые изменения конфигурации в сети управления. Если хост не может подключиться к системе vCenter Server после применения изменений, изменения будут возвращены к предыдущей рабочей конфигурации. Во-вторых, пользователи также могут перенастроить сеть управления VDS для каждого хоста через DCUI.

Поддержка протокола управления агрегацией каналов

Link Aggregation Control Protocol (LACP) - это основанный на стандартах метод. Под его контролем несколько физических сетевых каналов могут быть связаны вместе, чтобы сформировать логический канал, тем самым достигая цели увеличения пропускной способности и увеличения избыточности. LACP поддерживает сетевые устройства для согласования автоматической привязки канала путем отправки пакетов LACP на одноранговые устройства. vSphere 5.1 добавляет поддержку основанных на стандартах протоколов агрегации каналов.

Единый корень (SR) -Виртуализация ввода-вывода (SR-IOV)

Виртуализация ввода-вывода с одним корнем - это стандарт, который позволяет предоставлять адаптер PCI Express (PCIe) виртуальным машинам в виде нескольких отдельных логических устройств. Гипервизор управляет физическими функциями (PF), а виртуальные функции (VF) используются виртуальными машинами. В гипервизоре сетевые устройства, поддерживающие SR-IOV, обладают преимуществами прямого ввода-вывода, включая уменьшение задержки и снижение загрузки ЦП хоста. Платформа VMware vSphereПрямой путь к виртуальной машинеФункция (сквозной) предоставляет клиентам аналогичные преимущества, но для каждой виртуальной машины требуется физический адаптер. В SR-IOV функция передачи от одного адаптера к нескольким виртуальным машинам может быть предоставлена через виртуальные функции.

Фильтрация блоков данных протокола моста (BPDU)

Повышенная масштабируемостьВ следующей таблице перечислены данные о масштабируемости VDS vSphere 5.1:

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