Виртуализация имеет несколько больших преимуществ, но бывают случаи, когда виртуализированному серверу требуется более высокая производительность, и его следует переместить на физический.
Мой вопрос в том, как узнать, когда это сейчас? Я ищу измеримые данные и показатели, которые показывают, что перемещение сервера в его собственный физический блок может существенно повлиять на производительность. Лично меня интересует Windows, но, по-видимому, основные элементы одинаковы для всех платформ.
Я не согласен с тем, что виртуальный сервер нужно было бы перевести на физический из-за производительности. Гипервизоры теперь настолько близки к «металлу», что практически (каламбур) производительность не падает. Особенно сейчас, когда многие производители плат включают в чипсеты гипервизоры. Если вы возьмете два сервера с одинаковым оборудованием, один с одним гостем, а другой с точной копией этого гостя на физическом оборудовании, я думаю, вам будет трудно заметить разницу в производительности.
Однако есть и другие причины, по которым вам может понадобиться физический сервер, а не виртуальный. Один из них - аппаратная совместимость. Если вашему приложению требуется нестандартное оборудование с собственной уникальной шиной, возможно, вы не сможете запустить его на виртуальной машине.
Мне не терпится услышать, что говорят другие. Отличный вопрос.
ПРИМЕЧАНИЕ. У нас есть серверы, которые были виртуализированы, а затем снова установлены на том же оборудовании только для того, чтобы иметь возможности снимков / vmotion, которые нам нравятся.
Я не эксперт в этом вопросе, но в целом: очень голодные приложения ввода-вывода (особенно те, которые пишут мало и быстро) - это те, у кого есть собственный физический сервер.
Их тоже не очень сложно найти, вы просто запускаете монитор производительности и ищите большое время ожидания ввода-вывода.
Кроме того, высокопроизводительные базы данных обычно получают собственный выделенный сервер по нескольким причинам:
Единственный случай, когда мне пришлось выполнить V2P, был для блока MS SQL, который работал на двух двухъядерных процессорах 3,2 ГГц (общий процессор 14,4 ГГц), который мы перенесли в кластер ESX 2.5, где базовое оборудование было новее с большим количеством более медленные (2,4 ГГц IIRC) ядра. Добавив ~ 10% накладных расходов даже с 4 виртуальными ЦП, эта виртуальная машина могла бы получить только эффективный совокупный процессор с частотой 8-8,5 ГГц. 60% пиковых ЦП перед миграцией превратились в 90–100% после миграции, заказчику требовался запас, поэтому мы вернулись к физическому. Чтобы конкретно ответить на ваш вопрос, мы увидели, что приставка работает на 100% ЦП в Perfmon и в клиенте VI. Лучшим решением (на мой взгляд) было бы обновление до более быстрых процессоров, но есть крайние случаи, подобные этому, когда это не экономично, особенно с тенденцией к более медленным процессорам с большим количеством ядер, которые мы видели с введением процессоров Opterons \ Core.
С ESX 4 мы могли увеличить количество таких блоков до 8 виртуальных ЦП, но в то время это было невозможно.
Что касается поиска потолков производительности, которые могут указывать на то, что вам нужно отказаться от своей виртуальной машины, а затем с помощью гостя Windows в среде VMWare, тогда комбинация Perfmon и VI Client должна быть более чем подходящей для задачи поиска любых виртуальных машин, которые сами по себе ограничены в производительности . Добавьте к этому аналитику SAN, если вы можете, но если SAN обнаружит проблему, вы почти наверняка сможете переделать хранилище, чтобы изолировать и \ или улучшить тома, на которых хранятся виртуальные диски виртуальной машины. То же самое применимо к любой другой комбинации ОС / гипервизора - получайте любую внутреннюю статистику, которую вы можете, но коррелируйте их с представлением гипервизора о том, что происходит, потому что 100% ЦП, сообщаемое внутри виртуальной машины (например), не обязательно означает, что гипервизор никогда не сможет доставить больше производительности, просто этого не было на тот момент.
Это очень сильно зависит от выполняемой службы.
Обычно я смотрю на используемые ресурсы и определяю, действительно ли они являются узкими местами для этого гостя и предоставляемых им услуг.
Вот так:
Если у вас есть двухъядерный (2vSMP), гостевой компьютер с 4 ГБ ОЗУ, на котором работает веб-сервер (IIS), и вы не используете максимальное количество запросов ЦП и ОЗУ, то, возможно, гостю не нужно больше оборудования.
Мы сталкивались со случаями, когда запуск Oracle Database на платформе виртуализации приближался к той же производительности, что и аппаратный сервер аналогичного размера.
Очевидно, что если вы хотите иметь 16-ядерный сервер в качестве виртуальной машины, у вас могут возникнуть проблемы с его работой, а также с выделенным оборудованием.
Когда виртуальной машине не хватает ресурсов (или, возможно, другим виртуальным машинам не хватает ресурсов), например:
Я бы сказал, что это когда сервер находится в точке, где он потребляет достаточно ресурсов сервера, что он не может совместно использовать оборудование.
ESX, ESXi и Window Hyper V должны дать вам почти реальную производительность. Итак, пока одна из машин не использует 90% ресурсов сама по себе, вам не нужно переходить на реальное оборудование.
Исключениями являются то, что вам не нужны такие вещи, как 2 контроллера домена на одном устройстве, если оборудование выйдет из строя.
Я сомневаюсь, что есть общий ответ на этот вопрос, но если вы беспокоитесь о производительности, то вам следует обратить внимание на это. Очевидным было бы проверить, вы загружаете CPU, I / O, ...
Но также, тестирование производительности и тесты также поможет вам решить, есть ли какие-либо штрафы за виртуальность и разумно ли иметь одну виртуальную машину на хосте.
Сначала вам нужно определить, какой ресурс является узким местом.
Монитор производительности Windows ( перфмон ) предоставляет множество счетчиков для различных аспектов, таких как очередь диска, статистика виртуальной памяти и т. д.
Если вы привязаны к диску, предоставление виртуальной машине прямого доступа к диску вместо чего-то вроде файла vmx с помощью VMWare может очень помочь.
Думаю, все зависит от двух факторов:
только мой 2цт.