Я читал несколько технических статей, а также вот этот относительно различий между способами, которыми VMware и Hyper v выполняют планирование ЦП.
Мне было интересно, могу ли я получить объективную информацию по этому поводу. Казалось бы, групповое планирование, используемое VMware, является ОГРОМНЫМ недостатком, но я не хочу просто пить кулэйд. Влияет ли это серьезно на производительность, или же последние версии гипервизоров VMware решают эту проблему?
Изменить: когда я говорю о недостатке, я имею в виду «планирование свободного процессора» Hyper V или, как это делает KVM. В материале, который я читал, не говорилось о каких-либо проблемах с «планированием свободного процессора», которых можно избежать с помощью группового планирования.
Как пение Кровавая Мэри в темное зеркало в ванной, давайте посмотрим, сможем ли мы заставить появиться Джейка Ошинса ...
Групповое планирование также называется совместным планированием. Я думаю, что VMware предпочитает термин совместное планирование, а не групповое планирование.
В версиях ESX до версии 3.x VMware использовала «строгое» совместное планирование, которое имело недостатки синхронизации. В ESX 3.x и выше VMware перешла на «расслабленное» совместное планирование.
Упрощенное совместное планирование заменило строгое совместное планирование в ESX 3.x и было усовершенствовано в последующих выпусках для достижения лучшего использования ЦП и поддержки широких многопроцессорных виртуальных машин. Расслабленное совместное планирование имеет несколько отличительных свойств по сравнению со строгим алгоритмом совместного планирования. Самое главное, что в алгоритме строгого совместного планирования наличие запаздывающего виртуального ЦП приводит к совместной остановке всей виртуальной машины. В упрощенном алгоритме совместного планирования ведущий виртуальный ЦП решает, следует ли ему совместно останавливаться, основываясь на расхождении с самым медленным соседним виртуальным ЦП. Если перекос превышает пороговое значение, ведущий виртуальный ЦП само останавливается. Обратите внимание, что отстающий виртуальный ЦП - это тот, который делает значительно меньший прогресс, чем самый быстрый аналогичный виртуальный ЦП, а ведущий виртуальный ЦП - это тот, который делает значительно больший прогресс, чем самый медленный аналогичный виртуальный ЦП. Отслеживая самый медленный аналогичный виртуальный ЦП, теперь каждый виртуальный ЦП может принимать собственное решение о совместном планировании независимо. Как и со-стоп, решение о со-старте также принимается индивидуально. Как только самый медленный из сестринских виртуальных ЦП начинает работать, совместно остановленные виртуальные ЦП имеют право на совместный запуск и могут быть запланированы в зависимости от доступности pCPU. Это решает проблему фрагментации ЦП в алгоритме строгого совместного планирования, поскольку не требует совместного планирования группы виртуальных ЦП. В предыдущем примере виртуальной машины с 4 vCPU виртуальная машина может продвигаться вперед, даже если доступен только один свободный pCPU. Это значительно улучшает загрузку процессора.
Приведенный выше фрагмент взят из собственного документация.
Таким образом, VMware больше не использует строгое расписание групп. Я бы рассматривал документацию непосредственно от поставщика как более авторитетную.
Единственное, что даст вам точные цифры, - это эталонный тест, и он будет полностью зависеть от типов кода, выполняемого процессорами. Но я могу вам сказать, что если бы VMware находилась в таком невыгодном положении, то у них все еще не было бы львиной доли рынка виртуализации.
Хорошо, Райан, ты сделал мой день. Я не читаю этот форум так часто, как раньше, но мне довелось проверить.
Red888, вы должны знать заранее, что я архитектор программного обеспечения, работающий над Hyper-V в Microsoft. Я предполагаю, что большинство людей, читающих это, вполне способны щелкнуть ссылку с моим именем под этим и обнаружить это, или даже погуглить меня, но для этого ответа полезно быть полностью уверенным, что люди, читающие это, не сомневаются в моей точке зрения.
В общем, групповое планирование полезно, если гипервизор не имеет возможности повлиять на поведение ОС, работающей в виртуальной машине. Конечно, именно поэтому VMware начинала именно так. У них нет операционных систем, поэтому их целью было заставить существующие операционные системы работать хорошо. На их месте я бы начал с этого.
Групповое планирование, и VMware, вероятно, скажет, что я прав в этом, оставляет множество ограничений на то, как вы можете использовать физические процессоры на машине. Гипервизор часто не может найти подходящий ресурс на данный момент. Поэтому с годами они модифицировали свой алгоритм, ища способы сделать планирование более эффективным.
Microsoft (и, вероятно, несколько других компаний) начали с другой точки зрения. У нас есть Windows. Мы заставим Windows хорошо себя вести при виртуализации. Таким образом, планирование банды не потребуется. Мы даже не будем строить планировщик банды.
Интересно, что мы в Microsoft больше заботимся о том, чтобы Windows хорошо работала по сравнению с другими операционными системами, чем о том, чтобы Hyper-V выглядел лучше, чем VMware, KVM, Xen, Oracle или Unisys и т. Д. Поэтому мы опубликовали интерфейсы, которые Windows использует для взаимодействия с гипервизором. Вот ссылка, если вам интересно, хотя я не рекомендую читать перед сном:
Таким образом, любой поставщик гипервизора может предоставить информацию, которая вызовет совместное поведение Windows. У некоторых из них есть. Я, честно говоря, не знаю, есть ли у VMware, делает или раскроет это. Вы должны спросить их или кого-то, кто уделяет им много внимания. И если они это сделают, я был бы очень удивлен, если бы они не изменили свой планировщик, чтобы еще больше расслабиться. Это последнее заявление, конечно же, чисто предположение.
Итак, мой основной ответ заключается в том, что я сомневаюсь, что вам следует принимать решение о покупке в 2014 году, исходя из того, как работает планировщик гипервизора. Я подозреваю, что они все уже довольно хороши. Несколько лет назад это могло быть неправдой.
Вам следует попробовать свои рабочие нагрузки в различных системах и посмотреть, как они работают. Готов поспорить, ваша максимальная производительность зависит от того, соответствуют ли ваше хранилище и сеть вашим потребностям.