Так что на самом деле, каковы издержки виртуализации и когда я должен быть обеспокоен?

Я ищу хорошие правила, чтобы понять, когда НЕ нужно виртуализировать машину.

Например, я знаю, что полностью привязанный к процессору процесс с почти 100% -ной загрузкой, вероятно, не является хорошей идеей для виртуализации, но есть ли смысл запускать что-то, что использует ЦП большую часть времени «в значительном объеме» (скажем, 40 или 50%)?

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

Может ли кто-то суммировать намеки на виртуализацию в зависимости от рабочей нагрузки или количества гостевых машин по сравнению с ресурсами хоста?

Обычно я виртуализируюсь на хостах Windows, используя VirtualBox или VMWare, но я предполагаю, что это довольно общий вопрос.

Дисковая подсистема. Это обычно наименее распространенный ресурс. Память, конечно, но эта очевидна.

Ограничения дисковой подсистемы работают в обоих направлениях. Если система использует много дискового ввода-вывода, другие гости замедляются. Если этот гость находится в работе, возможно, ему нужен быстрый ответ на веб-запросы. Это может быть очень разочаровывающим, а также серьезной причиной, почему бы не арендовать виртуальное оборудование. Вы можете минимизировать эту проблему, используя выделенные диски.

Использование только 512 МБ памяти в гостевой системе помещает весь дисковый кеш на хост. И это не поровну между гостями.

Не беспокойтесь о CPU IO. Таким образом, виртуализация является очень эффективной, часто связанной с несколькими процессами, работающими в одной системе. Я редко вижу, чтобы мультиксейонные системы работали на 100% на процессоре.

редактировать: опечатки

Вещи, которые я бы никогда не положил в ВМ:

• Все, что использует конкретное оборудование, которое нельзя виртуализировать: обычно графику, довольно много аппаратных модулей безопасности, что-нибудь с настроенными драйверами (например, сетевые драйверы специального назначения).

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

Вещи, которые я бы не рекомендовал помещать в виртуальную машину:

• Программное обеспечение, которое уже прилагает усилия для использования всех ресурсов в аппаратном обеспечении. Машины, работающие как часть «больших данных», такие как hadoop, обычно предназначены для работы на голом металле.

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

• Все, что уже имеет большое узкое место. Он уже не очень хорошо играет сам по себе, вряд ли будет хорошо играть с другими.

Есть несколько вещей, которые очень удобно использовать в виртуальных машинах:

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

• Приложения, которые плохо масштабируются (или легко) самостоятельно. Устаревший код довольно часто попадает в эту категорию. Если приложение не расширится, чтобы занять сервер, используйте много маленьких виртуальных серверов.

• Проекты / приложения, которые начинаются с малого, но растут. Гораздо проще добавлять ресурсы в виртуальную машину (а также переходить на новое, более крупное оборудование), чем начинать с чистого листа.

Кроме того, я не уверен, преувеличиваете ли вы необходимость размещения огромного количества виртуальных машин на одном хосте, но если вы пытаетесь использовать большое соотношение ВМ: HW, вы можете вместо этого рассмотреть ESX, Xen, KVM. Вам будет намного лучше, чем использовать VMware или virtualbox в Windows.

Есть два аспекта производительности виртуализации.

• общее узкое место
• эмуляция

На общих узких местах, кто еще на том же железе? Если вы находитесь в виртуализированной среде, вы очень зависите от честного с вами партнера по хостингу.

Я думаю, что главный вопрос для необработанной производительности (особенно интерактивности) - какие части системы виртуализации эмулируются. Это отличается в зависимости от настройки. Диск и сеть являются типичными кандидатами. Как правило, эмуляция удваивает «затраты» производительности на выполнение действия, поэтому любое время задержки оборудования следует считать двойным, а любое значение обработки должно быть уменьшено вдвое.

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

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

OTOH, если вы хотите консолидировать несколько машин, которые в основном все время простаивают, виртуализация - это путь вперед.

Хороший ответ от antRiR.

Кроме того, критичные по времени системы. Я просто выясняю, что Hyper-V dime rot (виртуальный компьютер медленно отстает, все современные ОС в VM делают это, часто ресинсируются) не очень-то хорошо играют с некоторыми критичными по времени приложениями, которые я разрабатываю. Кроме того, я собираюсь использовать здесь «много» процессоров и планирую получить 12-ядерную машину только для этого приложения в производстве.