Когда виртуализация была новой, мы пытались виртуализировать все, но затем мы заметили случаи использования, когда наши виртуальные машины были намного медленнее, чем голый металл.
Принимая решение не виртуализировать, мы используем следующие правила:
У нас был такой опыт работы с Xen и DRDB, а также у Hyper-V не было общего доступа к DAS. Так ли обстоит дело со всеми гипервизорами?
Какие (другие) показатели мне следует искать при принятии решения о виртуализации приложения / сервера или нет?
Вы достигли основных показателей в своем вопросе:
Сеть IO
Вы хотите быть уверены, что предлагаемая вами рабочая нагрузка виртуализации не приведет к перегрузке сетевого подключения вашей хост-системы. В наши дни 10-гигабитных сетевых карт это не проблема для крупных предприятий, и небольшие предприятия часто могут получить необходимую им производительность от гигабитных (или объединенных / агрегированных гигабитных) сетевых карт.
Диск IO
Вы хотите быть уверены, что ваша дисковая подсистема (локальные диски, SAN, NAS) может обрабатывать дисковый ввод-вывод, который вы предлагаете.
При определении размера помните, что ваша фабрика SAN (коммутаторы и т. Д.) Также должна иметь возможность справляться с нагрузкой - у вас может быть система хранения über-SAN, которая может передавать терабит в секунду на свои диски, но если этот монстр подключен к паршивой 100-мегабитной сети iSCSI, и вы заполните свою сеть до того, как запоминающее устройство вспыхнет.
ОЗУ
В частности, «активная» оперативная память (потому что гипервизор может выгрузить неактивное содержимое, и никто этого не заметит). В идеале у вас достаточно физической оперативной памяти, которую гипервизору не нужно менять. На самом деле вы, вероятно, найдете золотую середину для чрезмерных обязательств.
Некоторые другие следует учитывать:
ЦП (и шаблоны рабочей нагрузки)
Если у вас есть несколько систем, которые выполняют задачи с интенсивным использованием ЦП, у вас могут возникнуть проблемы, если все они одновременно требуют процессора хост-системы. (например, если у вас есть 1 центральный процессор и 3 виртуальные машины, которые все хотят обрабатывать числа в полночь, каждая виртуальная машина будет видеть только ~ 1/3 производительности центрального процессора, поскольку гипервизор пытается разделить оспариваемый ресурс между ними).
Обратной стороной этого является то, что если у вас есть несколько систем, которые выполняют задачи с интенсивным использованием ЦП в разное время (например, в полночь, 3 часа ночи и 6 часов утра, и всегда заканчивают до того, как начнется следующий парень), вы можете виртуализировать их, и они никогда не будут знаю разницу.
Специальное оборудование
Некоторые гипервизоры (например, VMWare) позволяют пропускать через PCI и Storage Pass-thru. Другие не могут.
Если вам нужен доступ к оборудованию на хосте (например, к видеокарте или прямому доступу к диску), вам необходимо учесть это при планировании виртуализации.
Хронометраж
Гипервизоры стали лучше в этом, но задачи точного хронометража по-прежнему лучше подходят для выделенных физических серверов. Например, первичный NTP-сервер вашей организации должен быть физическим хостом (или маршрутизатором, если ваши маршрутизаторы могут работать как NTP-серверы).
Вещи, которые обычно плохо виртуализируются
Об этом есть много анекдотических данных, поэтому проведите небольшое исследование, прежде чем что-то виртуализировать.
В качестве нескольких примеров, проблемы хронометража, о которых я упоминал выше, системы VOIP (например, АТС Asterisk) и часто используемые базы данных, как правило, плохие кандидаты для виртуализации (первые два из-за проблем с точностью хронометража, базы данных обычно потому, что они вызывают, и страдают от нехватки ресурсов больше, чем другие рабочие нагрузки).
Каждая компания составляет локальный список вещей, которые, как они знают, не могут виртуализировать - по мере того, как вы находите свои элементы, убедитесь, что вы их документируете (включая причину, на случай, если однажды вы получите гипервизор, который решит проблему).
Как отмечалось в комментариях, не все программное обеспечение для виртуализации одинаково.
http://wiki.openvz.org/FAQ#What_is_the_performance_overhead.3F
Каковы накладные расходы на производительность? Около нуля. Нет уровня эмуляции, только изоляция безопасности, и все проверки выполняются на уровне ядра без переключения контекста.
Каковы ожидания производительности? Пиковая производительность достигается, когда только один контейнер имеет активные задачи. В этом случае он может использовать 100% доступных ресурсов: все процессоры, всю физическую память, весь диск и пропускную способность сети. OpenVZ не ограничивает вас однопроцессорной виртуальной машиной.
Хотя может показаться, что это не ответ: нет общих условий, при которых вы не должны использовать виртуализацию. Теперь у меня есть привычка развертывать оборудование с одним контейнером OpenVZ: их очень легко перенести с помощью предоставленных инструментов из-за аппаратной абстракции, которую виртуализация по своей сути обеспечивает. В качестве небольшого побочного эффекта стоимость лицензии на программное обеспечение, как правило, также ниже.