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