Когда перенести виртуализированный сервер на физический?

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

Мой вопрос, как вы говорите, когда эти времена? Я ищу измеримые данные и метрики, которые показывают, что перемещение сервера в его собственное физическое устройство может существенно повлиять на производительность. Лично я заинтересован в 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.

Я не эксперт в этом вопросе, но, вообще говоря: очень голодные приложения ввода / вывода (особенно те, которые пишут мало и быстро) - это те, кто получает свой собственный физический сервер.

Найти их тоже не очень сложно, вы просто запускаете монитор производительности и смотрите, что время ожидания ввода / вывода велико.

Кроме того, высокопроизводительные базы данных обычно получают собственный выделенный сервер по нескольким причинам:

1. Они хотят кэшировать все, что могут, использование оперативной памяти огромно
2. Они работают лучше с многопоточностью на нескольких ядрах (8-сторонний режим - это нормально), и вы, как правило, не хотите назначать более 1 виртуального процессора любому серверу из-за блокировки
3. Они очень требовательны к вводу / выводу при загрузке данных в кеш, ключевым фактором является низкая задержка при вводе / выводе.

Это очень сильно зависит от сервиса, который он выполняет.

Я обычно смотрю на ресурсы, которые используются, и определяю, действительно ли они являются узкими местами для этого гостя и предоставляемых им услуг.

Вот так вот:

Если у вас есть двухъядерный процессор (2vSMP), гостевая память 4 ГБ с веб-сервером (IIS), и вы не исчерпываете запросы ЦП и ОЗУ, возможно, гостю не нужно больше оборудования.

Мы сталкивались со случаями, когда запуск базы данных Oracle на платформе виртуализации приближался к тому же уровню производительности, что и аппаратный сервер аналогичного размера.

Очевидно, что если вы хотите использовать 16-ядерный сервер в качестве виртуальной машины, у вас могут возникнуть проблемы с его работой, а также с выделенным оборудованием.

Когда ВМ не хватает ресурсов (или, возможно, не хватает других ВМ для ресурсов), например:

1. Когда ввод-вывод виртуальной машины не может быть удовлетворен через хост
2. Когда виртуальная машина нуждается в большей пропускной способности сети, чем это возможно для совместного использования магистрали
3. Когда процессам виртуальной машины требуется больше ресурсов процессора, чем она может получить, например, если существует один процесс, который максимально использует виртуальный процессор
4. Если у него linux и ему нужно очень точное время (если он работает на хосте VMware linux хостов со временем дрейфа VMware. Это можно уменьшить с помощью ntp, однако для приложений, которые требуют очень точного времени, например kerberos, вы могли бы рассмотреть реальное оборудование)
5. Когда его Linux и нуждается в очень надежном диске (если он работает на хосте VMware - у VMware были проблемы, и я считаю, что у них все еще есть проблемы с SCSI под VMWare при определенных условиях. Исправление было выпущено, но оно все еще происходит, хотя и гораздо реже)

Я бы сказал, когда сервер находится в точке, где он потребляет достаточно ресурсов сервера, чтобы он не мог совместно использовать оборудование.

ESX, ESXi и Window Hyper V должны дать вам практически реальную производительность. Поэтому, пока одна из машин не использует 90% ресурсов сама по себе, вам не нужно переходить на реальное оборудование.

Исключение составляют случаи, когда вам не нужны такие вещи, как ваши 2 контроллера домена на одном устройстве, в случае сбоя оборудования.

Я сомневаюсь, что есть общий ответ на это, но если вы беспокоитесь о производительности, то это то, на что вы должны смотреть. Очевидным было бы проверить, максимально ли вы используете процессор, ввод / вывод, ...

Кроме того, тестирование производительности и тесты производительности также помогут вам решить, есть ли какое-либо наказание за виртуальность и целесообразно ли иметь одну виртуальную машину на хосте.

Сначала нужно определить, какой ресурс является узким местом.

Монитор производительности Windows ( perfmon ) предоставляет множество счетчиков для различных аспектов, таких как очередь дисков, статистика виртуальной памяти и т. Д.

Если вы привязаны к диску, предоставление виртуальной машине прямого доступа к диску вместо чего-то вроде файла VMX с VMWare может очень помочь.

Я думаю, что все зависит от двух факторов: