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

Вещи, которые я никогда не вставлял бы VM:

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

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

Вещи, которые я препятствовал бы включению VM:

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

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

• Что-либо, что уже имеет большое узкое место. Это уже не играет хорошо с собой, это будет вряд ли играть хорошо с другими.

Существуют некоторые вещи, которые являются довольно потрясающими для включения VMs:

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

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

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

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

Существует две точки к выполнению виртуализации.

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

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

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

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

Кроме того, строго ограниченные во времени системы. Я просто выясняю tha гниль десяти центов Hyper-V (vm медленно отстающий, вся современная ОС в vm's делают это, часто повторно синхронизируются), не подыгрывает любезному с некоторыми строго ограниченными во времени приложениями, которые я разрабатываю. Плюс я собираюсь использовать "много" CPU там и планирую получить 12 базовых машин только для того приложения в производстве.

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

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

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