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