Есть ли какие-либо преимущества в производительности виртуализации сервера приложений, помимо упрощения развертывания и администрирования?
Например, могу ли я разместить больше работающих пользователей на 4 виртуальных машинах сервера приложений на одном Xenserver, чем на 1 физическом сервере приложений с той же спецификацией оборудования?
Подавляющее большинство серверных рабочих нагрузок никогда не доводят системы до уровня, который полностью использует ресурсы современного сервера. По моему опыту, средняя физическая система работает с уровнями нагрузки 10% или меньше. Все решения виртуализации позволяют консолидировать эти нагрузки таким образом, чтобы обеспечить лучшее общее использование физического оборудования. Хорошие решения виртуализации предоставляют инструменты администрирования, которые упрощают управление несколькими системами, обеспечивают отказоустойчивость \ высокую доступность, динамическую миграцию, более простую подготовку рабочих нагрузок и множество других преимуществ.
Хотя, как правило, виртуализация требует компромиссов в производительности, но они относительно низкие. 5% для рабочих нагрузок общего назначения и в худшем случае 10-20%. Учитывая, что производительность сервера улучшается на 20–50% за поколение, компромисс с точки зрения производительности редко становится препятствием. Хотя это возможно, и эти крайние случаи следует исключить из виртуализации.
Есть несколько сценариев, в которых виртуальное решение может превзойти физическую реализацию на нескольких серверах. Подобно сценарию, в котором снижение виртуальной производительности недопустимо, такие ситуации редки, но они существуют. Многоуровневое приложение с интерфейсными службами \ уровнем приложения, которое полагается на сетевое подключение к одной или нескольким внутренним базам данных, например, может получить выгоду от эффективности виртуального сетевого стека в пределах одного виртуального хоста. @pjz привел несколько хороших примеров сценариев с одним типом рабочей нагрузки, в которых виртуализация может повысить общую производительность, потому что масштабирование (на несколько параллельных систем) легче выполнить эффективно, чем масштабирование (создание эффективного многопоточного приложения, масштабируемого до текущего сервера). ядро подсчитывает эффективно).
Учитывая ваш пример, ответ таков, что это зависит, но если сервер приложений, о котором вы говорите, - это XenApp, а гипервизор - XenServer, тогда я думаю, что вы сможете поддерживать больше пользователей, выбрав виртуальный маршрут, чем запускаемый изначально, при условии, что вы говорите о недавний сервер с большим количеством ядер. У VMware есть старая статья о XenApp, работающем на ESX 3.5, по сравнению с собственной производительностью, и они утверждают, что масштабирование лучше, когда серверы работают виртуально. Верны ли эти утверждения для современных гипервизоров XenApp и VMware, во многом зависит от того, насколько хорошо текущие версии XenApp обрабатывают архитектуры NUMA и многоядерное масштабирование на современном оборудовании, я подозреваю, что это все еще верно, хотя я бы принял их утверждения о улучшение на 30% с vSphere с некоторым уровнем скептицизма. Citrix утверждает, что XenApp на XenServer превосходит XenApp на vSphere, я не могу сказать, правда ли это, но поведение горизонтального масштабирования в виртуальных системах достаточно очевидно - этот технический документ Citrix показывает, что при аналогичных профилях рабочей нагрузки XenServer на базе двойного Xeon 5570 может поддерживать в 3 раза большее количество одновременных пользователей, чем физический сервер XenApp, работающий на двух ядрах сервера на базе X7350 (который является более старым поколением). Масштабирование с несколькими виртуальными машинами определенно работает довольно хорошо, но масштабирование с двухъядерных на четырехъядерные не очень эффективно. Это AMD презентация указывает на улучшение на 70% в количестве одновременных сеансов, которое может поддерживаться при переходе с двухъядерного на четырехъядерный. Я подозреваю, что масштабирование для XenApp, изначально работающего на основных серверах поколения 12 \ 16 \ 48, будет очень быстро ухудшаться, но я не могу найти в этом ничего окончательного.
Как вы отметили, основными преимуществами виртуализации являются простота администрирования, переключения при отказе и развертывания. А правильно спроектированный, современный теоретически приложение должно работать немного лучше прямо на оборудовании, чем на виртуальной машине под гипервизором. Я могу придумать следующие предостережения:
Если у вас есть многопроцессорный компьютер и однопоточное приложение, которое не позволяет нескольким своим копиям сосуществовать на одном компьютере, вы можете «обмануть» его, запустив каждую копию в виртуальной машине на одном компьютере.
Если у вас есть многопроцессорная 64-разрядная машина с 16+ ГБ ОЗУ, то 32-разрядное приложение, работающее на пределе доступной памяти (3-4 ГБ, верно?), Может работать лучше, если разделено на 4 vm находится под гипервизором на том же компьютере, поскольку это позволит ему адресовать больше памяти, чем в противном случае.
Производительность не является сильной стороной виртуализации; сильной стороной является то, что вы можете управлять 4 различными приложениями с конфликтующими требованиями к программной инфраструктуре на одной машине.