Назад | Перейти на главную страницу

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

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

Мне нужно взять HBA, к которому привязаны мои диски хранения, и передать его в виртуальную машину (возможно, xen), чтобы разрешить создание настройки типа vSAN. Я хочу сделать это, чтобы реализовать настройку типа SAN на одном сервере.

Когда я расспрашивал окружающих, люди говорили мне, что IOPS будет хуже, чем у baremetal. Я как бы учел это в своей настройке, но это заставило меня задуматься, насколько это повредит системе?

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

Ах да, кстати, здесь в основном рассматривается файловая система ZFS. Возможно, работает на FreeBSD (включая такие вещи, как FreeNAS и NexantaStor) или OpenIndiana.

Спасибо!

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


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

Ваша установка будет следующей:

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

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

Затем перезагрузитесь (я предполагаю, что у вас есть удаленная консоль, поэтому вы можете делать это удаленно), загрузитесь с 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).

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

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

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

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

Хотя настоящий ответ.

Да, есть вероятность задержки или снижения производительности из-за запуска хранилища в режиме сквозной передачи VT-d.

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

Настоящая проблема, которую вы должны иметь, заключается в том, будет ли решение вообще работать! VT-d может быть темпераментным и работает не со всеми адаптерами.

Так что проверьте сами на своих рабочих нагрузках!