Как я могу определить снижение производительности VT-d против baremetal?

Я больше не рекомендую такой тип сквозной настройки. В большинстве случаев это проигрыш, особенно в отношении надежности и производительности.

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

Отказ от ответственности: у меня нет опыта работы с Xen, поэтому я пишу относительно ESXi, но концепции схожи.

Что касается вашего первоначального вопроса "Как проверить разницу производительности между baremetal и VM с помощью passthrough?":

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

• Материнская плата серверного уровня с процессором Intel Xeon, поддерживающим VT-d (есть альтернативы, но я бы сказал проще)
• Один SATA SSD от 20 до 30 ГБ, в зависимости от вашей ОС (также может быть HDD, но он будет немного медленнее)
• Ваш HBA с чипом LSI, который поддерживает ваши диски
• Два сетевых адаптера Intel могут быть встроены, подключены к PCIe или к обоим, но они должны быть одной модели. У большинства плат они уже есть, но только у некоторых по 10 Гбит. Если вы используете 1 Гбит, вы обычно максимально увеличите производительность при последовательном чтении и записи примерно на 4 дисках или одном SSD, поэтому я бы рекомендовал 10 Гбит (также внутренняя сеть в большинстве случаев 10 Гбит, так что это было бы более интересно).
• Флешка для гипервизора

Сначала установите гипервизор на USB-накопитель и настройте его. Разбейте ваш SSD на 2 части. Перезагрузите и установите свою ОС с исходным кодом, как обычно, на первый слайс. Используйте HBA вместе с другими дисками и настройте один или несколько пулов для тестов производительности. Сделайте те тесты и запишите результаты. Вы должны как минимум проверить локальную производительность из командной строки и производительность сети с нужными протоколами (iSCSI, NFS, SMB). По возможности также проверьте SSD (не обязательно). Если закончите, экспортируйте ваш пул (ы).

Затем перезагрузите компьютер (я полагаю, у вас есть Remote Console, так что вы можете сделать это удаленно), загрузитесь с USB-накопителя вместо локального SSD. Теперь используйте второй слайс SSD для создания виртуальной файловой системы, которая охватывает весь слайс 2. На эту VFS установите вашу систему с того же ISO, что и раньше, но теперь как виртуальную машину. Выполните настройку в гипервизоре и назначьте одну физическую сетевую карту и ваш HBA этой новой виртуальной машине. Также назначьте хотя бы один виртуальный сетевой адаптер для этой виртуальной машины (или более, если вы хотите тестировать разные типы). Назначьте как можно больше оперативной памяти для виртуальной машины, чтобы сделать условия похожими.

Затем загрузите виртуальную машину, настройте ее и снова из нее (через VNC или SSH) импортируйте ваш пул. Теперь вы можете выполнять те же тесты, что и раньше (локальный и удаленный), как для физического, так и для виртуального адаптеров, и отмечать любые различия. Кроме того, вы можете создать вторую виртуальную машину, но теперь она находится на общем томе NFS или iSCSI, обслуживаемом из вашего пула. Тесты на этой виртуальной машине многое расскажут о вашем последующем сценарии использования в качестве хоста виртуальной машины.

Некоторые мысли помимо показателей производительности. Мне нравится эта настройка по нескольким причинам:

1. Это очень похоже на собственную настройку: если ваш сервер умирает, вы можете удалить все диски и подключить их к любому другому хосту - если на хосте есть гипервизор, вы можете просто продолжать использовать их после загрузки небольшой виртуальной машины хранения; и даже если нет, у вас уже есть все данные и сетевые ресурсы, готовые мгновенно, потому что все находится в самом пуле. При традиционной настройке вам придется беспокоиться о контроллере RAID того же типа, о поддержке файловой системы, и потребуется гипервизор (или копирование данных с виртуальных дисков).
2. На удивление стабильно, если компоненты хорошо играют вместе: если вы купите хорошее оборудование, у вас будет намного меньше проблем; и даже если возникнут проблемы, ваши данные будут сохранены (по крайней мере, если вы не отключите синхронизированные записи, что вы никогда не должны делать с виртуальными машинами!). И даже если вы потеряете данные по какой-либо причине, вы узнаете об этом раньше, чем с другими файловыми системами.
3. Это дешевле / эффективнее: вы фактически виртуализировали свою полную сеть SAN, но вам не нужны два корпуса, два стоечных пространства, два резервных блока питания, два процессора и так далее. С другой стороны, тот же бюджет дает вам гораздо больше - вместо двух обычных серверов вы можете получить более мощный со всеми приятными функциями (избыточное питание, многолучевое распространение HBA), и ваши ресурсы (память, питание и т. Д.) Могут быть используется как вам это нужно.
4. Он гибкий: вы можете использовать лучшую операционную систему для каждой задачи. Например, используйте Oracle Solaris - дистрибутив illumos, такой как OpenSolaris, OmniOS или Nexenta, для своей виртуальной машины хранения, чтобы получить все новейшие функции и стабильность, которую они предлагали годами. Затем добавьте Windows Server для Active Directory, FreeBSD или OpenBSD для внутренней или внешней маршрутизации и сетевых задач, различные дистрибутивы linux для прикладного программного обеспечения или баз данных и т. Д. (Если вы не хотите накладных расходов, но хотите гибкости, вы можете попробовать SmartOS на голый металл, хотя тогда ваш выбор гипервизора ограничен KVM).

Есть, конечно, минусы. Один упомянутый, аппаратное обеспечение должно соответствовать. Дополнительно:

1. Производительность, скорее всего, никогда не будет такой же хорошей, как при традиционной настройке. Вы можете потратить на это немалые деньги (больше оперативной памяти, ZIL на SSD или NVMe, больше дисков, только SSD-диски), но если производительность - ваша первая задача, виртуальные машины - не лучший выбор, ZFS - не лучший выбор и то и другое вместе тоже не лучший выбор. Это компромисс, от которого вы не можете избежать, у вас есть безопасность и гибкость, но не максимальная производительность.
2. Вам нужно немного подготовиться к загрузке, выключению и потере мощности. Практическое правило: ваша виртуальная машина хранения должна быть первой, чтобы полностью загрузиться, и последней, чтобы полностью загрузиться. Проверьте и определите время загрузки, чтобы узнать, как долго вы должны ждать, прежде чем запускать другие машины. Завершение работы не так критично, преждевременное завершение работы примерно равно потере мощности для отдельных виртуальных машин (что безопасно, если ваше прикладное программное обеспечение, операционная система, гипервизор и уровень хранения согласны использовать только синхронизирующие записи для чего-либо важного).
3. Обновления могут быть немного больше времени. Помните, что если вы измените свою виртуальную машину хранения, все другие виртуальные машины должны быть закрыты (или будут принудительно выключены). Поэтому спланируйте еще какое-то время простоя (это, конечно, то же самое, что и при физической настройке, когда ваша SAN будет недоступна для обновлений). Также вам следует тщательно протестировать все обновления основных функций (гипервизор, сетевые драйверы, драйверы виртуальной сети, драйверы хранилища, ВМ хранилища), поскольку вы не хотите, чтобы ошибка приводила к нестабильному поведению NFS в случайные моменты времени.
4. Вы все еще делаете резервные копии, верно?;)