Sr iov support что это

SR-IOV Support — что это в биосе? (AMD/Intel)

Приветствую друзья! SR-IOV Support — технология виртуализации устройств, позволяющая виртуальным машинам использовать аппаратные возможности устройства.

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

Также можно почитать инфу на VMware Docs (энглиш).

Информация для специалистов:

Если правильно понимаю, простыми словами SR-IOV — виртуализация, дающая доступ к реальным аппаратным функциям устройства. Сами устройства могут быть разные, чаще всего — сетевые платы. При помощи SR-IOV виртуальная машина будет передавать данные напрямую сетевой карте, что улучшит скорость/отклик работы сети в виртуалке.

Виртуальная машина — что это такое? Простыми словами — обычный ПК, который имеет свой процессор, свой обьем оперативной памяти, жесткий диск, операционку с установленным в ней софтом. Однако в теории все это — отдельный ПК. По факту — программа, которая эмулирует виртуальный ПК. Таких компьютеров может быть несколько, десятки. Они могут сдаваться в аренду (VPS). Работают 24 часа. Все они работают на специальном компе, который именуется сервером.

Примерный принцип работы SR-IOV показан на следующих скриншотах:

Правда понять смогут только профессионалы..

Нужно ли включать SR-IOV Support?

Опция SR-IOV Support нужна в первую очередь серверам, призвана для улучшения работы виртуальных машин.

Виртуальная машина всегда использует физические ресурсы ПК. Исключение — облачные машины, но пока все это сырое. Однако виртуальная машина никогда не будет иметь производительность, которая равна физической машины. Да, она высока, два года назад VMware заявляла — их виртуальные машины позволяют использовать до 80% производительности физической машины.

Можно сделать вывод — обычному домашнему пользователю данная опция не нужна. Если она была по умолчанию включена — пусть остается.

Если не знаете как было выставлено по умолчанию, и при этом присутствует пункт Auto — выберите его.

Physical Function и Virtual Function

Не совсем понятно значение данных терминов, поэтому привожу информацию из интернета:

Заключение

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Источник

Диалектика SATA-революции

Решение принято: начиная с чипсета 9-й серии жесткие диски подключаются напрямую к шине PCI Express, минуя SATA-контроллер. В итоге, производительность дисковой подсистемы увеличивается в полтора-два раза с соблюдением всех требований AHCI-стандарта, т.е. без потери программной совместимости:

Такова надводная часть айсберга. Каковы отдаленные последствия, связанные с нововведением? Обратимся к спецификации NVM Express, регламентирующей логику работы твердотельного диска на PCIe-шине.

Несколько слов о Non-Volatile Memory Host Controller Interface Specification

Место интерфейса NVMe отлично иллюстрирует статья Дейла Ландсмена из SanDisk «AHCI and NVMe as Interfaces for SATA».

Из нее всем интересующимся полезно будет узнать, что «AHCI was developed at a time when the purpose of the HBA in a system was to connect the CPU/Memory subsystem with the much slower rotating media-based storage subsystem. Such an interface has some inherent inefficiency when applied to SSD devices, which behave much more like DRAM than spinning media».

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

SR-IOV как зеркало хардверной революции

Вернемся к спецификации NVMe. При ее разработке изначально учитывалась возможность поддержки Single-Root Input-Output Virtualization:

Тем, кто незнаком с концепцией SR-IOV, в двух словах сообщим, что сие суть дальнейшее развитие идеи виртуализации, пришедшей на периферию. Физический девайс с помощью SR-IOV представляется как совокупность виртуальных устройств со всеми вытекающими последствиями: разграничение доступа, повышение производительности etc. В настоящее время используется виртуализация центрального процессора VT-x, виртуализация адресного пространства для bus-master устройств VT-d, но продвижение в сторону виртуализации периферийных устройств пока затруднено. Вернее так: на рынке уже полно сетевых адаптеров, которые поддерживают SR-IOV, но слишком далеки они от народа дороги они. Массового психоза, связанного с раздвоением и прочим клонированием девайсов не наблюдается. Пока нет виртуализируемых USB-контроллеров (а жаль, кстати!), как следствие – флеш-дисков и других накопителей, в т.ч. SATA. Так вот – будут.

Есть, правда, одно «но». В силу того, что NVMe-контроллер становится частью жесткого диска, а сам накопитель подключается как PCI Express устройство, поддержка SR-IOV будет зависеть не только от чипсета и платформы, но и от накопителя. Это означает дальнейшую дивергенцию любительского (офисного) и профессионального (серверного) оборудования. Таковы перспективы будущего, на наш взгляд.

Источник

Включаем поддержку SR-IOV для виртуальных машин Hyper-V

SR-IOV (Single Root Input/Output Virtualization) это технология виртуализации аппаратных устройств хоста, позволяющая предоставить виртуальным машинам прямой доступ к устройствам. Технология позволяет виртуализировать различные виды устройств, но чаще всего используется для виртуализации сетевых адаптеров. В этой статье мы расскажем, как правильно включить и настроить SR-IOV для сетевых адаптеров виртуальных машин на сервере Hyper-V.

SRV-IOV поддерживается в Hyper-V начиная с версии 2012, в том числе в бесплатном Hyper-V Server. Мы не будем погружаться в теорию SR-IOV, вы можете найти подробное описание технологии в сети. Для практического понимания достаточно знать, что SR-IOV позволяет предоставить доступ виртуальным машинам непосредственно к физическим сетевым адаптерам хоста, минуя обработку трафика виртуальными коммутаторами Hyper-V. Один физический сетевой адаптер в режиме SR-IOV может обслуживать несколько виртуальных машин.

Благодаря использованию SR-IOV для виртуальных машин Hyper-V вы существенно увеличите пропускную способность, снизите сетевую задержку и уменьшите нагрузку на CPU, вызванную необходимостью обрабатывать сетевой трафик программными средствами Hyper-V.

Чтобы SRV-IOV работала на вашем хосте Hyper-V нужно выполнять ряд условий.

В первую очередь нужно включить поддержку SR-IOV и виртуализации в BIOS вашего сервера. В зависимости от вендора и модели сервера эти настройки могут отличаться.

Каких-то пунктов может и не быть, даже пункта SR-IOV. Но это не означает, что SR-IOV не поддерживается сервером. Например, на материнских платах Supermicro пункт SR-IOV может отсутствовать, и при этом есть отключенный по умолчанию пункт ASPM. Если включить ASPM и поддержку виртуализации, то SR-IOV включится автоматически.

Вы можете проверить, поддерживается ли технология SR-IOV вашим Hyper-V сервером на аппаратном уровне с помощью PowerShell:

Если ваш сервер поддерживает эту функцию, то в поле IovSupport будет указано True. Если не поддерживает, то False. При этом в пункт IovSupportReasons будет описание причины, из-за которой SR-IOV не поддерживается. Причина как правило указывается довольно подробно. Вот типовые причины:

Полный вывод команды get-vmswitch | fl *iov* дает ряд полезной информации. Например:

Такие цифры сразу покажут сколько виртуальных устройств IOV доступно и сколько уже использовано виртуальными машинами.

При создании виртуального коммутатора Hyper-V нужно установить галочку поддержки SR-IOV — Enable single-root I/O virtualization (SR-IOV).

Либо включать опцию EnableIOV при создании коммутатора из командной строки PowerShell:

Причём наличие поддержки SR-IOV на самом хосте гипервизора вовсе не означает, что оно заработает на конкретном виртуальном коммутаторе. Нужно что бы этот коммутатор был привязан к сетевому адаптеру с поддержкой SR-IOV.

Есть еще один нюанс. На материнской плате может быть несколько сетевых адаптеров, но SR-IOV может поддерживаться только на части из них. Причём поддержка SR-IOV самим адаптером по даташиту вовсе не означает, что оно работает на данной конкретной материнской карте!

Поэтому после сборки коммутатора проверьте его командой:

get-vmswitch | select IovSupport, IovSupportReasons, IovEnabled

Параметр IovEnabled показывает включен ли он.

Список сетевых адаптеров с поддержкой SR-IOV можно вывести с помощью PowerShell:

Get-NetAdapterSriov | sort name | ft Name, InterfaceDescription, SriovSupport

После того, как SR-IOV включен на уровне гипервизора и виртуального коммутатора, теперь его можно включить в виртуальных машинах (по умолчанию выключено). Опция Enable SR-IOV доступ в секции Hardware Acceleration сетевой карты виртуальной машины.

Либо можно включить SR-IOV для сетевого адаптера виртуальной машины через PowerShell:

Ошибки при работе SR-IOV пишутся на Hyper-V в отдельный журнал в Event Viewer:

Если SR-IOV работает штатно, то при запуске виртуальной машины в логе будут такие записи:

Технология SR-IOV дает хороший буст сетевой производительности виртуальных машин и гипервизора в целом. Максимальные результаты от использования SR-IOV вы заметите на хостах Hyper-V с большим трафиком виртуальных машин, который вызывает сильную нагрузку на хостовые CPU.

Спасибо. А нет ли опыта включения SR-IOV на материнских платах ASUS?
Вот какой результат дает диагностика:
(get-vmhost).IovSupport
True
(get-vmhost).IovSupportReasons

Вторая функция ничего не возвращает.

Если функция (get-vmhost).IovSupportReasons не возвращает ничего, то это не означает, что все работает.
В логах есть несколько ошибок:
Master_179_0_0: EXT_QP_MAX_RETRY_LIMIT/EXT_QP_MAX_RETRY_PERIOD registry keys were requested by user but FW does not support this feature. Please upgrade your firmware to support it.
For more details, please refer to WinOF User Manual.
Master_179_0_0: SRIOV cannot be enabled. Running in single-function mode.
Bios на материнке и сетевых картах последний. Вполне вероятно, что MB Asus bios не поддерживает эту функцию.

Да, я не совсем верно выразился. IovSupport=True не означает, что SR-IOV работает. Это означает, что хост в принципе поддерживает эту технологию и, в частности, то, что она включена в BIOS’е.
При этом (get-vmhost).IovSupportReasons возвращает либо «ОК» либо пустое значение (вероятно в зависимости от версии ОС, но это не точно). Короче IovSupportReasons имеет смысл если IovSupport=False.
Но что бы технология заработала нужна ещё поддержка стороны сетевого адаптера. И об этом мы узнаем собрав коммутатор и проверив в нём вывод:
get-vmswitch | select IovSupport, IovSupportReasons, IovEnabled
Если сетевой адаптер не поддерживает технологию или производитель мамки не посчитал нужным её реализовывать, то увы. Видимо это как раз ваша ситуация. Мать вероятно не серверная?
(собственно в посте всё это написано, тут я ничего нового не сказал)

Кстати я предпочитаю команды:
get-vmhost | fl
и
get-vmswitch | fl

Они дают более подробный вывод.

>Мать вероятно не серверная?
Верно, игровая.
IovVirtualFunctionCount : 8
IovVirtualFunctionsInUse : 0
Написал производителям БИОСа, может помогут разобраться.

Можно полный вывод «get-vmswitch | fl» увидеть? Любопытно.
Вообще я предполагаю, что на не серверных матерях мало шансов встретить рабочую реализацию. Тем более если сетевуха интегрированная, скорее всего она в принципе такое не умеет. Можно попробовать воткнуть PCI-E сетевую карту. Но опять же предполагаю, что это должна быть серверная сетевая карта, а они стоят весьма нарядно.

У вас там никакой тиминг не используется случайно? Смущает «NetAdapterInterfaceDescription : Teamed-Interface».

12582 Network Adapter (D177948B-D880-42BC-ADDC-46B26F6FBFA8) started successfully. (Virtual Machine ID 364A642F-EB19-4900-B2F5-1AE3236FF9AE)

12597 Network Adapter (364A642F-EB19-4900-B2F5-1AE3236FF9AE—D177948B-D880-42BC-ADDC-46B26F6FBFA8) Connected to virtual network. (Virtual Machine ID 364A642F-EB19-4900-B2F5-1AE3236FF9AE)

12584 Network Adapter (364A642F-EB19-4900-B2F5-1AE3236FF9AE—D177948B-D880-42BC-ADDC-46B26F6FBFA8) allocated a virtual function. (Virtual Function ID 0 LUID 0:22233d77 Virtual Machine ID 364A642F-EB19-4900-B2F5-1AE3236FF9AE)

12589 The description for Event ID 12589 from source Microsoft-Windows-Hyper-V-SynthNic cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

rds5
364A642F-EB19-4900-B2F5-1AE3236FF9AE
364A642F-EB19-4900-B2F5-1AE3236FF9AE—D177948B-D880-42BC-ADDC-46B26F6FBFA8
Network Adapter
0
0:22233d77
%%2147942431
0x8007001F

The system cannot find message text for message number 0x%1 in the message file for %2

12586 Network Adapter (364A642F-EB19-4900-B2F5-1AE3236FF9AE—D177948B-D880-42BC-ADDC-46B26F6FBFA8) freed a virtual function. (Virtual Function ID 0 Virtual Machine ID 364A642F-EB19-4900-B2F5-1AE3236FF9AE)

материнская плата SuperMicro H12SSL-NT, ОС Server 2019 Standart.

почемуто на родных сетевых картах Broadcom 10GBASE-T показывает SriovSupport — Not Supported, что странно.

Отдельно поставили Intel X520 — там показывает Supported. Собственно SR-IOV нам только на Intel и нужен. Но всёже загадка почему на Broadcom не работает.

да и (get-vmhost).IovSupportReasons не показывает вообще ничего, но (get-vmhost).IovSupport показывает нормально True.

виртуальный коммутатор вроде создал, вроде работает, но не пойму всё ли правильно или нет. У меня кстати тоже нету в журналах Hyper-V-SynthNic, но в остальных вообще ниодной ошибки.

«почемуто на родных сетевых картах Broadcom 10GBASE-T показывает SriovSupport — Not Supported»
Это где так показывает? В информации о коммутаторе собранном на Броадкомах? IovSupportReasons при этом что показывает?

«Но всёже загадка почему на Broadcom не работает»
Потому что этот броадком может не поддерживать данную технологию либо она может быть не реализована производителем матери. У меня Супермикра с четырьмя сетевухами Интел на борту. Все эти сетевухи по даташиту поддерживают SR-IOV. Но работает оно только на двух.

«да и (get-vmhost).IovSupportReasons не показывает вообще ничего»
Это нормально. В Reasons показывает причину почему НЕ работает. А если работает там будет либо «OK» либо просто пусто (от версии ОС зависит видимо).

«виртуальный коммутатор вроде создал, вроде работает»
Если «get-vmswitch | fl» выдает IovSupport=True и IovEnabled=True значит всё работает.

Get-NetAdapterSriov | sort name | ft Name, InterfaceDescription, SriovSupport

Name InterfaceDescription SriovSupport
—- ——————— ————
LAN1(MAIN) Intel(R) Ethernet Server Adapter X520-2 #2 Supported
LAN2(GUEST) Supermicro 10GBASE-T Ethernet Controller #2 NotSupported
LAN3(BACKUP) Intel(R) Ethernet Server Adapter X520-2 Supported
WAN(INTERNET) Supermicro 10GBASE-T Ethernet Controller NotSupported

В информации о коммутаторе собранном на Броадкомах?

не, на броадкомах как раз не собирал. Нам надо как раз на Intel.

Потому что этот броадком может не поддерживать данную технологию либо она может быть не реализована производителем матери.

ну както странно. Современная материнка под AMD EPYC на базе ZEN2 и ZEN3 (именно новая модель а не новая ревизия старой от первых EPYC под новые), современные 10Гбит\с сетевые адаптеры Dual 10GBase-T LAN via Broadcom BCM57416, и показывает NotSupported.

Если «get-vmswitch | fl» выдает IovSupport=True и IovEnabled=True значит всё работает.

Ну вот кстати командлет Get-NetAdapterSriov (про который я не знал) показывает же информацию поддерживается ли и если не поддерживается, то почему. Скажем у меня вывод такой:
Name : Ethernet 6
InterfaceDescription : Intel(R) I350 Gigabit Network Connection #3
Enabled : True
SriovSupport : Supported
SwitchName : DefaultSwitchName
NumVFs : 6

Name : Ethernet 7
InterfaceDescription : Intel(R) I350 Gigabit Network Connection #4
Enabled : True
SriovSupport : Supported
SwitchName : DefaultSwitchName
NumVFs : 6

Name : Ethernet 5
InterfaceDescription : Intel(R) Ethernet Controller X540-AT2 #2
Enabled : True
SriovSupport : NoVfBarSpace
SwitchName : DefaultSwitchName
NumVFs : 62

Name : Ethernet 4
InterfaceDescription : Intel(R) Ethernet Controller X540-AT2
Enabled : True
SriovSupport : NoVfBarSpace
SwitchName : DefaultSwitchName
NumVFs : 62

На обоих X540 указано NoVfBarSpace (расшифровку причин можно посмотреть здесь: https://docs.microsoft.com/en-us/powershell/module/netadapter/get-netadaptersriov?view=windowsserver2019-ps).
И возможно даже кручением разных настроек в биосе удастся заставить работать. Но большая проблема в том, то в биосе Супермикро (да и любой другой мастери, что уж) есть много мало понятных параметров вида «XXX: Enabled/Disabled», а описание этих параметров в мануле вот такое «Эта настройка включает/выключает XXX» (спасибо, кэп, а то ятак-то не понял). А вот что такое этот XXX хрен где найдёшь.
Я намедни новый сервак на Супермикро поднимал. Крутнул в биосе один такой вот параметр без описания, который, как мне казалось, отвечает всего лишь за энергосбережение на процессоре. Так после этого винда виснуть начала при попытке включения HVCI. Так что на боевом сервере я бы поостерёгся такие эксперименты проводить. Если сервер еще не в работе, то можно покрутить конечно.

«не, на броадкомах как раз не собирал. Нам надо как раз на Intel.»
Ну собрал же, работает как надо. Чего переживать-то? 🙂

«ну както странно»
Заметь, что в расшифровке нет даже варианта такого — «NotSupported». Т.е. похоже, что это банально не поддерживается сетевым адаптером. Если интересно надо поискать даташит на адаптер и посмотреть там. У Интела такая инфа точно есть на ark.intel.com. Насчет Броадкома не уверен, что найти получится.

вот тут хз. Энергосберегайки и всякое прочее по дефолту. только всевозможные виртуализации включил — SVM и SR-IOV. параметров типа IOMMU и ASPM вообще не нашёл. Но мне кажется еслиб дело было в них, врядли бы и на Intel заработало, однако там вроде работает.

откопал даташит по бродкому, написано SR-IOV with up to 128 VFs. тоесть вроде поддерживается.

да вот мало ли потом понадобится вдруг и на бродкомах сделать SR-IOV, а он не может. печально.
Ввёл просто Get-NetAdapter — где у вас NoVfBarSpace у меня показывает просто NotSupported, однако NumVFs показывает как в даташите — 128.

Get-NetAdapterSriov

Name : LAN3(BACKUP)
InterfaceDescription : Intel(R) Ethernet Server Adapter X520-2
Enabled : True
SriovSupport : Supported
SwitchName : DefaultSwitchName
NumVFs : 62

Name : LAN1(MAIN)
InterfaceDescription : Intel(R) Ethernet Server Adapter X520-2 #2
Enabled : True
SriovSupport : Supported
SwitchName :
NumVFs : 62

Name : LAN2(GUEST)
InterfaceDescription : Supermicro 10GBASE-T Ethernet Controller #2
Enabled : True
SriovSupport : NotSupported
SwitchName : Default Switch
NumVFs : 128

Name : WAN(INTERNET)
InterfaceDescription : Supermicro 10GBASE-T Ethernet Controller
Enabled : True
SriovSupport : NotSupported
SwitchName : Default Switch
NumVFs : 128

Источник

Оптимизация виртуальных серверов с помощью SR-IOV

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

Виртуализация серверов применяется ныне практически во всех центрах обработки данных. С одной стороны, это способствует снижению расходов, с другой — оптимизации ресурсов в ЦОД.Появившаяся недавно технология виртуализации SR-IOV позволяет повысить эффективность использования физических ресурсов для виртуальных машин.

В своем исследовании «Market Analysis Perspective: Worldwide Enterprise Virtualization Software, 2010 — Server Virtualization» аналитики IDC отметили, что количество виртуализированных серверов растет и, как ожидается, в 2014 году их будет уже более 18,4 млн. Кроме того, по словам участников опроса, им удалось сэкономить около 25% расходов на аппаратное обеспечение и соответствующую инфраструктуру. Ввиду такого колоссального увеличения числа виртуальных сред стремление к оптимизации процессов ввода/вывода на виртуальных серверах привело к появлению новых сетевых технологий, таких как Converged Enhanced Ethernet (CEE), Data Center Bridging (DCB), Fibre Channel over Ethernet (FСoE) и Virtual NIC. Новым стандартом является технология Single Root I/O Virtualization (SR-IOV), разработанная PCI SIG (Special Interest Group).

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

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

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

Внедрение четырехъядерных процессоров Intel и AMD, начавшееся в 2009 году, только укрепляет эту тенденцию. В наши дни в связи с появлением нового поколения серверов, которые могут иметь до 8 ядер и поддерживать до 16 одновременных потоков, следует ожидать ее дальнейшего развития. Вместе с увеличением количества ядер возрастает и объем памяти серверов — еще один решающий аргумент в пользу виртуализации. Помимо ядер и ресурсов памяти, существует еще и третий компонент, позволяющий повысить эффективность операций ввода/вывода, чтобы обеспечить виртуальным машинам достаточную скорость передачи данных по сети. В этом помогут высокопроизводительные порты Ethernet на 10 Гбит/с, эффективная разгрузка протоколов (Offload) для сокращения числа процессорных циклов и внедрение новых технологий, в частности SR-IOV.

ЧТО ТАКОЕ SR-IOV?

SR-IOV — это стандарт PCI-SIG, разработанный для виртуальных серверов. Спецификация SR-IOV позволяет делить карту PCI Express на физические и виртуальные карты благодаря использованию концепции физических и виртуальных функций (см. Рисунок 1).

Рисунок 1. Технология SR-IOV призвана обеспечить повышение производительности при взаимодействии виртуальных машин с сетевыми ресурсами.

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

Виртуальная функция. Виртуальные функции назначаются виртуальным машинам и ограничиваются управлением трафиком данных (потоки ввода/ вывода). Они не предусматривают воз© ITP Verlag можности администрирования физических устройств. Гипервизор предоставляет виртуальные функции различным виртуальным машинам, благодаря чему они получают устройство ввода/вывода, но при этом виртуальные машины не имеют сведений о физических параметрах адаптеров. Управлением физических устройств занимается гипервизор.

Хотя стандарт SR-IOV ориентирован на процессы ввода/вывода в сетях и устройствах хранения, до сих пор он используется только в сетях. Разработки, нацеленные на повышение производительности виртуальных серверов, фокусируются главным образом на трафике данных, поскольку на него приходится основная доля операций ввода/вывода и отводится наибольшая часть ресурсов сервера. Операции ввода/вывода в памяти порождают меньше накладных расходов (Overhead) и обычно достигают максимальной скорости, поддерживаемой соединением.

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

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

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

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

Перри Икхаут — менеджер по региону Центральная Европа в компании Emulex.

Поделитесь материалом с коллегами и друзьями

Источник