Что такое sr iov

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

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

Заключение

Источник

Что такое sr iov

Всем привет сегодня расскажу, что такое SR-IOV. Для чего он вам может пригодится, какие дает плюсы и плюшки, да и просто для расширения кругозора.

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

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

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

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

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

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

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

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

Источник

Русские Блоги

Основные принципы SR-IOV

Аннотация: познакомьтесь с концепцией SR-IOV, сценариями использования и методами настройки в VMware и KVM.

Часть 1: Задержка связи виртуализации:

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

Таким образом, считается, что существует проблема со связью между гипервизором и GuestOS. В это время я подумал о SR-IOV и хотел посмотреть, может ли SR-IOV обеспечить низкую задержку для служб, чувствительных к задержке.

Перед написанием этой статьи я только что видел, как Red Hat выпускает Red Hat Virtualization V4. В официальном документе есть «Аппаратные аспекты внедрения SR-IOV с Red Hat Virtualization».
Статья очень короткая, в основном она знакомит с предпосылками использования SR-IOV в Red Hat Virtualization:

Сначала здесь представлена ​​платформа виртуализации Red Hat V4.

Часть 2: виртуализация ввода-вывода

Часть 3: SR-IOV

SR-IOV（Single Root I/O Virtualization) позволяет операционной системе Windows и гипервизорам, таким как Microsoft Hyper-V или VMware ESXi, подключаться к серверу.Дисковое устройство ввода-вывода, Как и сейчас пара SR-IOVСетевое оборудованиеСделать то же самоеПакет，управлениечетныйобщий。

Преимущества SR-IOV

Стандарт SR-IOV обеспечивает эффективное совместное использование устройств PCIe между гостевыми доменами ввода-вывода.
Устройство SR-IOV может иметь сотни виртуальных функций (Virtual Function, VF), связанных с определенной физической функцией (Physical Function, PF).
Создание VF может динамически контролироваться PF через регистр, предназначенный для включения функции SR-IOV.
По умолчанию функция SR-IOV отключена, а PF действует как традиционное устройство PCIe.

Устройства с функцией SR-IOV могут воспользоваться следующими преимуществами:

Уменьшено количество адаптеров

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

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

Примечание. Некоторые изображения взяты из «PCI-SIG SR-IOV Primer»

Часть 4: Условия и методы настройки сетевых карт Intel для реализации SR-IOV в среде VMware

1. Требования к оборудованию:

2. Программные требования:

Метод конфигурации:
1) Создайте VF
Откройте SSH, войдите в ESXi, используйте следующую команду для создания VF

После завершения настройки перезапустите ESXi, посмотрите и создайте VF

Кроме того, этот шаг можно настроить в пакетном режиме как можно скорее через профиль хоста.

2) Назначьте VF виртуальной машине
Изменить виртуальную машину, добавить устройство PCI

Выберите VF и подтвердите.

Завершите раздачу VF.

3) GuestOS устанавливает драйвер VF.
Windos необходимо загрузить драйвер VF отдельно, CentOS 6.x поставляется с драйвером igbx.

Часть 5: Как настроить SR-IOV в Red Hat Virtualization

1) Создайте VF
Сначала проверьте физическую сетевую карту с помощью lscpi и создайте VF, перезагрузив параметры модуля ядра:

Или настройте в rc.local:

Посмотреть созданный VF

2) Назначьте VF виртуальной машине

Следующие шаги идентичны и не будут повторяться. SR-IOV здесь сегодня. Если вам интересно, рекомендую прочитать следующее:
《IBM Power Systems SR-IOV Technical Overview and Introduction》
《How to Configure Intel Ethernet Converged Network Adapter-Enabled VF on VMware ESXi 5.1》
《Implementing SR-IOV on HPE ProLiant Servers with VMware vSphere 5.1》
《Red_Hat_Enterprise_Linux-7-Virtualization_Deployment_and_Administration_Guide-en-US》

Источник

Оптимизация виртуальных серверов с помощью 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.

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

Источник

VirtIO или SR-IOV. Взгляд Mellanox

В статье, подготовленной специалистами компании Mellanox, рассматриваются достоинства и недостатки двух технологий виртуализации сетевого интерфейса в применении с аппаратными ускорителями — VirtIO и SR-IOV.

Обзор

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

Возможны три различных реализации виртуализации:

Лучшие примеры реализации сегодня:

VirtIO

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

SR-IOV

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

Ни один из этих недостатков не свойственен аппаратному ускорению на основе SR-IOV. Например, Microsoft уже решила проблему оперативной миграции для операционной системы Windows Server и разрешает миграцию виртуальных машин, которые используют полностью ускоренный ввод-вывод SR-IOV. Программное обеспечение, обеспечивающее миграцию виртуальных машин, находится в разработке в сообществе открытого исходного кода и скоро станет доступным в последующих коммерческих дистрибутивах. Точно так же функциональность более высокого уровня стандартизируется для таких функций, как качество обслуживания (Linux tc_flower API), работа в сети (ESXi, Nuage, Contrail и т. д.), Хранение (NFV через Fabrics, RDMA) и безопасность. Разрабатывается все больше приложений и виртуализированных сетевых функций, которые используют преимущества этих интерфейсов с возможностью прозрачного использования аппаратного ускорения.

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

Эволюция облачных дата-центров

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

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

Развертывание виртуальных вычислительных узлов стало обычным явлением в облачных и корпоративных дата-центрах. К сожалению, виртуальные коммутаторы на основе ядра (например, Open vSwitch или OVS) могут обеспечить пропускную способность только 200 Кбит / с. Основанный на DPDK vSwitch (OVS-DPDK) с интерфейсом VirtIO может обеспечить более высокую производительность до 7,5 Мбит / с, но при этом полностью загружаются 2 физических ядра центрального процессора. Обеспечивается улучшение в 25 раз. Этого достаточно для удовлетворения требований к пропускной способности многих пользователей. Однако, OVS-DPDK улучшает производительность за счет снижения эффективности использования вычислительной мощности и увеличения капитальных затрат. Масштабирование производительности приложения DPDK пропорционально количеству выделенных ядер ЦП. Выделение большего количества ядер для обработки пакетов означает меньшее количество доступных ядер для запуска приложений. Облачные провайдеры стремятся к максимальной эффективности своих центров обработки данных, их доход прямо пропорционален количеству сдаваемых в аренду виртуальных машин. Таким образом, программно-управляемое ускорение, связанное с загрузкой ЦП, снижает общую эффективность инфраструктуры центра обработки данных.

Тенденции развития технологий сетевых адаптеров Ethernet

Скорость Ethernet растет быстрее, чем растут возможности процессора. Существующие программные и аппаратные интерфейсы были недостаточно хороши для масштабирования пропорционально с улучшениями центрального процессора. Поставщики оборудования внедрили множество нововведений в свои драйверы для решения проблем оптимизации скорости передачи пакетов, пропускной способности, снижения задержки и разгрузки ЦП. Драйверы постоянно переписываются и оптимизируются, в аппаратное обеспечение добавляются новые функции. Программно-аппаратный интерфейс NIC также постоянно обновлялся из поколения в поколение. Двигаясь вперед, мы убеждены, что для адекватного решения проблем, связанных с высокими требованиями к приложениям, необходимо использовать аппаратные возможности интерфейсных карт. Интерфейс Ethernet NIC должен позволить производителям оборудования продолжать инновации для обеспечения наилучшей производительности. Правильный способ абстрагирования оборудования находится на уровне драйвера ОС. Использование аппаратного API «отраслевого стандарта», связанного с программным интерфейсом, таким как VirtIO, означает огромный компромисс в производительности, масштабируемости и гибкости.

Потребность в производительности огромна. От драйверов Ethernet ожидется производительность на уровне сотен миллионов пакетов в секунду. Ограничения интерфейса для хранения данных NVMe оправданы, однако они на порядок снижают производительность, что приводит к гораздо более низкой скорости ввода-вывода. Стандартизация аппаратных / программных интерфейсов для массовых потребителей, безусловно, необходима, но когда вам нужно иметь дело с гораздо более высокими скоростями — стандарты не успевают за растущими потребностями.

Сегодня собственные драйверы или драйверы SR-IOV являются единственным способом достижения максимальной производительности, не затрагивающим ядер ЦП.

Что такое ускорение VirtIO?

VirtIO — это стандартный программный интерфейс для виртуального представления одного физического устройства на нескольких виртуальных машинах. Текущие реализации VirtIO требуют, чтобы гипервизор (также известный как VirtIO backend vhost) обрабатывал запрос VirtIO, отправляемый виртуальной машиной (внешний интерфейс VirtIO), для связи с физическим драйвером NIC, который потребляет ресурсы процессора. Архитектура VirtIO с аппаратным ускорением подразумевает, что серверная часть (по крайней мере, путь к данным) реализована аппаратно, что освобождает ресурсы гипервизора для возможного достижения более высокой скорости передачи пакетов. Методы аппаратного ускорения VirtIO, такие как vDPA (ускорение виртуальной плоскости данных), заблокированы и являются специфическим механизмом ускорения стандартного API программного обеспечения virtio. Эта техника, хотя и интересная, имеет свои достоинства и недостатки.

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

Ниже приведены преимущества VirtIO API:

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

Ряд проблем, которые необходимо преодолеть для развития VirtIO описан ниже.

Стандарт ускорения VirtIO развивается

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

Ниже приведены различные версии спецификаций ускорения VirtIO и проблемы с каждой из них:

1. VirtIO 0.95 устарело. Аппаратное ускорение не может быть полностью ускорено, поскольку оно обменивается данными через PIO (требуется некоторое вмешательство в гипервизор).

2. VirtIO 1.0 определяет, как более старые драйверы, использующие 0.95, могут опционально поддерживаться новыми устройствами. Самое главное, VirtIO 1.0 добавляет поддержку пространства памяти PCI. Это потенциально позволяет гостевому драйверу обмениваться данными с аппаратным устройством, однако это не так просто, как кажется. Основная структура / протокол, используемый для разделения, довольно сложна и включает много операций чтения / записи PCI. VirtIO1.0 входит в стандартный дистрибутив Linux, такой как Red Hat Enterprise Linux 7.2, с апреля 2014 года и до сих пор не получил широкого распространения из-за узких мест PCI.

3. Спецификация VirtIO 1.1 расширяет 1.0, но полностью обратно совместима (с использованием битов возможностей). Она все еще находится в стадии разработки и не выпущена официально. VirtIO 1.1 представляет упакованную оптимизацию virtqueue, которая более проста и требует меньше операций чтения / записи PCI. Это позволяет повысить производительность, особенно для аппаратного обеспечения. Она также вводит биты возможностей, необходимые для согласования с оборудованием:

Подводя итог, можно сказать, что VirtIO 1.1 явно поддерживает связь с оборудованием в отличие от VirtIO 1.0. Следовательно, все сводится к тому, могут ли НОВЫЕ бэкэнд-драйверы гипервизора вводить механизмы, обеспечивающие корректную работу для гостей, использующих драйверы СУЩЕСТВУЮЩИЕ — различные поколения реализаций VirtIO в ядре Linux, DPDK, Windows и т. д.

Ускорение VirtIO требует определенных манипуляций

Драйвер VirtIO включен в исходные ядра и во многие дистрибутивы Linux, включая Red Hat Enterprise Linux, CentOS, Canonical, Ubuntu, Suse и т. д. Нет необходимости в его дополнительной установке. Архитектура Mellanox обеспечивает обратную и прямую совместимость драйвера ОС с оборудованием, развернутым на сервере. Драйвер доступен из коробки вместе с лучшими в отрасли показателями для SR-IOV. Для любых новых функций, которые недоступны в восходящем потоке, Mellanox поддерживает механизм OFED для обработки таких исключений.

В отличие от SR-IOV, VirtIO Acceleration не поддерживается по умолчанию всеми операционными системами. Якобы стандартный драйвер VirtIO должен быть изменен, чтобы соответствовать конкретному оборудованию. Следовательно, для развертывания решения VirtIO вам необходимо изменить ОС и установить такой драйвер.

VirtIO Acceleration не зависит от оборудования

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

Для ускорения VirtIO требуется поддержка живой миграции

Поддержка динамической миграции для любого аппаратного ускорителя (оборудование Intel VirtIO, оборудование Mellanox VirtIO, Mellanox SR-IOV, Intel SR-IOV и т. Д.) требует проверки:
1. Last_used_idx — состояние серверной части.
2. Dirty_used_ring_bitmap — это запрос временной страницы. Поскольку согласование зависит от устройства, оно потребует реализации для конкретного устройства (следовательно, нестандартной).

Мы можем логически разделить поддержку VirtIO для живой миграции на три части:

1. Внешняя память virtq и сохранение / восстановление состояния. Поддержка миграции действительно сохраняется без проблем при работе с VirtIO с аппаратным ускорением.

2. Сохранение / восстановление состояния серверной части virtq. Хотя сами очереди находятся в памяти и, таким образом, мигрируют вместе с другим состоянием виртуальной машины, серверная часть VirtIO также поддерживает внутренние состояния (такие как смещения LRO, смещения объединяемых буферов RX, счетчик переноса очереди пакетов). В решении с аппаратным ускорением qemu не знает об этих внутренних состояниях, и ему нужно будет запросить ускоренное устройство. В этом отношении решение VirtIO с аппаратным ускорением потребует такого же дополнительного протокола для аппаратного устройства VirtIO, что и решение SR-IOV.

3. Отслеживание временных страниц. Гипервизор не осведомлен о страницах, записываемых аппаратным ускорителем. Восстановление информации о временных страницах для решения VirtIO с аппаратным ускорением требует такого же (зависящего от устройства) дополнительного протокола, который потребуется для решения SR-IOV.

Таким образом, поддержку динамической миграции в OVS необходимо связать с аппаратным ускорением (на основе SR-IOV или vDPA). vDPA не решит проблему динамической миграции только потому, что ускоряет традиционный интерфейс virtio. Живая миграция одинаково зависима от оборудования как для vDPA, так и для SR-IOV. Обратите внимание, что поддержка живой миграции для VirtIO Acceleration не является стандартной, в отличие от заявлений конкурентов в отрасли. Лучшее, что мы можем сделать, — это подготовить общую среду динамической миграции с использованием методов ускорения VirtIO и SR-IOV.

VirtIO Acceleration не встроена в гипервизор

Почти все преимущества VirtIO выглядят убедительно по сравнению с SR-IOV, однако это не так.

VirtIO — стандартный интерфейс.
• Он был разработан как программный интерфейс и, следовательно, еще не стандартизирован для оборудования. Он все еще развивается.

VirtIO сейчас есть во всех дистрибутивах Linux.
• Да, однако весьма вероятно, что он не будет работать из коробки для оборудования ускорения VirtIO.
• Драйверы Mellanox также имеют статический интерфейс virtio и уже несколько лет входят в стандартные дистрибутивы Linux. Они также не будут работать с любым оборудованием для ускорения VirtIO из коробки.

VirtIO не требует установки SR-IOV в BIOS и не ограничивается несколькими VF.
• Даже если VirtIO не нужно настраивать VF для создания интерфейсов vNIC, все равно потребуется создавать кольца дескрипторов для каждого из интерфейсов VirtIO. Аппаратному обеспечению по-прежнему потребуются возможности для поддержки каждого программного интерфейса VirtIO, привязанного к аппаратным ресурсам. Не имеет значения, где выполняется эта конфигурация. Кроме того, у любого оборудования есть ограничения по масштабированию, что справедливо и для оборудования ускорения VirtIO.

VirtIO поддерживает живую миграцию
• Это верно при запуске VirtIO на гипервизоре, поскольку гипервизор может отслеживать временные страницы. Однако после аппаратной разгрузки необходимо добавить дополнительные механизмы для отслеживания записи устройством DMA. Следовательно, поддержка живой миграции непрозрачна. Эти проблемы уже решены в других аппаратных интерфейсах, таких как SR-IOV.

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

Ускорение на базе SR-IOV

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

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

Ускорение SR-IOV высвобождает ресурсы гипервизора, однако в реализации на основе SR-IOV виртуальная машина взаимодействует напрямую с физическим устройством. При этом используется собственный интерфейс физического устройства, предоставляемый поставщиком оборудования. SR-IOV — это отраслевой стандарт для ускорения решений хранения данных, включая RDMA, NVMe-over-Fabrics и сетевые решения, включая DPDK и ASAP2 OVS Offloads.

Технология ускоренной коммутации и обработки пакетов (ASAP2) Mellanox использует преимущества SR-IOV для значительного ускорения канала передачи данных виртуального коммутатора, освобождая ядра ЦП для выполнения приложений и других рабочих нагрузок. Пути управления API остаются неизменными, что обеспечивает прозрачную поддержку существующих программно-определяемых сетевых контроллеров (SDN).

Рисунок 2: Блок-схема разгрузки OVS с использованием режима ASAP2 SR-IOV

Как показано на рисунке 2, виртуальные машины устанавливают прямой доступ к оборудованию Mellanox ConnectX-5 NIC через виртуальную функцию (VF) Single Root IO Virtualization (SR-IOV) для достижения максимальной производительности сетевого ввода-вывода в виртуализированной среде. Одна из проблем, связанных с устаревшей реализацией SR-IOV, заключается в том, что она полностью обходит гипервизор и виртуальный коммутатор. При этом, виртуальный коммутатор не знает о существовании виртуальных машин в режиме SR-IOV. В результате, плоскость управления SDN не может влиять на решения о пересылке для этих виртуальных машин. Основанная на стандартах технология разгрузки OVS, такая как ASAP2, решает эту проблему за счет переноса операций обработки пакетов с виртуального коммутатора и медленного пути данных virtio к электронному коммутатору ConnectX и более быстрой плоскости пересылки SR-IOV. При перемещении пути данных от virtio к SR-IOV, ASAP2 позволяет OVS по-прежнему программировать конвейер плоскости данных электронного коммутатора. Происходит это через стандартный открытый поток, такой как управление SDN. ASAP2 использует драйверы SR-IOV, которые присутствуют во всех основных дистрибутивах Linux. Посему, клиенты могут воспользоваться преимуществами более быстрой обработки пакетов при одновременном высвобождении ресурсов ЦП. Таким образом, достигается максимальная эффективность облачного центра обработки данных.

Поддержка живой миграции для SR-IOV

Для SR-IOV выполняется живая миграция. Живая миграция не уникальна для VirtIO, она также может поддерживаться для устройств SR-IOV. Фактически, в операционной системе Windows он поддерживается в течение многих лет и был развернут крупными поставщиками облачных услуг. Процесс миграции включал переход от собственного драйвера к эмуляции на очень ограниченное время и переключение обратно на драйвер. Это все, что необходимо для перехода на драйвер SR-IOV и получения максимальной производительности.

Преимущества аппаратного ускорения SR-IOV

Ниже приведены основные преимущества ускорения SR-IOV:

1. Производительность «чистого металла» (BW, PPS, Latency)
• Уникальные инновационные функции IHV

2. Родной драйвер IHV в ВМ
• Аппаратный интерфейс полностью прямо- и обратно- совместим, начиная с ConnectX-4

3. Нулевое использование ЦП для эмуляции сетевой карты.
• Родной сетевой адаптер открыт для виртуальной машины

4. Поддержка живой миграции

Сравнение производительности

Этот раздел отличается от оригиналбного, содержащего красивые, но несколько «маркетинговые» графики c неточностями и ошибками.

Тесты производительности по данным dpdk.org

Регулярно обновляющиеся результаты тестов публикуются здесь: https://core.dpdk.org/perf-reports/
Здесь использованы данные из отчета Release 20.05 (май 2020 года).

Для составления DPDK Vhost/Virtio Performance Report проводятся тесты по двум схемам, характеризующим производительность и масштабируемость «по вертикали» — схема устройство — виртуальная машина — устройство Phy-VM-Phy или PVP (Рис. 1)
и «по горизонтали» — схема виртуальная машина — виртуальная машина в пределах одного хоста Vhost VM to VM или VM2VM (Рис. 2)

Рис. 1. Схема тестирования PVP Рис. 2. Схема тестирования VM2VM

В Таблице 1 и на графике (Рис. 3) приведенна пропускная способность по схеме PVP в мегапакетах/с (Mpps) для двух версий Virtio — 1.0 (Split Ring) и 1.1 (Packet Ring). Для сравнения добавлена теоретически возможная скорость 40-гигабитной линии.

Таблица 1 Рис. 3 Производительность

Производительность по схеме VM2VM составляет 43.4Гигабит/с

Преимущество ускорения SR-IOV

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

Скорость передачи пакетов: для размера пакета 64 Б

SR-IOV показало преимущество в пропускной способности в 8,5 раз по сравнению с DPDK Vhost/Virtio при полной (!) разгрузке ЦП в отличие от DPDK Vhost/Virtio, полностью занимающей 2 ядра ЦП.

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

Производительность: Линейная пропускная способность для пакета размером 1500 Байт

Пропускная способность OVS VirtIO не превышает 30 Гбит / с из-за ограничений программного интерфейса Virtio.

Разгрузка ASAP2 OVS, которая использует ускорение пути данных SR-IOV, почти линейно масштабируется до скорости 91 Гбит / с (на сетевом адаптере ConnectX-5 100 Гбит / с). Скорость передачи пакетов достигает 66 миллионов пакетов в секунду для пакетов размером 64 байта без использования ЦП для обработки пакетов.

Источник