Является ли планирование банд в VMware серьезным недостатком?

Я читал некоторые технические статьи, а также эту статью о различиях между тем, как VMware и Hyper V планируют процессоры.

Мне было интересно, смогу ли я получить некоторую объективную информацию об этом. Может показаться, что планирование банд, используемое VMware, является ОГРОМНЫМ недостатком, но я не хочу просто пить клэдаид. Это серьезно влияет на производительность, или последние итерации гипервизоров VMware решают эту проблему?

Редактировать: когда я говорю о недостатке, я имею в виду «свободное планирование процессора» в Hyper V или как KVM это делает. В материале, который я читал, не говорилось о каких-либо проблемах с «планированием свободного процессора», которых можно избежать при планировании банд.

Как напевая « Кровавую Мэри» в темном освещенном зеркале в ванной, посмотрим, сможем ли мы показать Джейка Ошинса…

Планирование банды также упоминается как совместное планирование. Я думаю, что VMware предпочитает термин совместное планирование для планирования банд.

В версиях ESX до версии 3.x VMware использовала «строгое» совместное планирование, что имело недостатки синхронизации. В ESX 3.x и выше VMware переключился на «расслабленное» совместное планирование.

Расслабленное совместное планирование заменило строгое совместное планирование в ESX 3.x и было улучшено в последующих выпусках для достижения лучшего использования ЦП и поддержки широких многопроцессорных виртуальных машин. Расслабленное совместное планирование имеет несколько отличительных свойств по сравнению со строгим алгоритмом совместного планирования. Наиболее важно то, что, хотя в строгом алгоритме совместного планирования существование запаздывающего виртуального процессора приводит к одновременной остановке всей виртуальной машины. В расслабленном алгоритме совместного планирования ведущий vCPU решает, должен ли он самостоятельно останавливаться, основываясь на перекосе с самым медленным одноуровневым vCPU. Если перекос превышает пороговое значение, ведущий vCPU самостоятельно останавливается. Обратите внимание, что запаздывающий vCPU дает значительно меньший прогресс, чем самый быстрый vCPU, в то время как ведущий vCPU обеспечивает значительно больший прогресс, чем самый медленный одноуровневый vCPU. Отслеживая самый медленный одноуровневый vCPU, теперь каждый vCPU может самостоятельно принимать решение о совместном планировании. Как и co-stop, решение о совместном запуске также принимается индивидуально. Как только самый медленный одноуровневый vCPU начинает прогрессировать, совместно остановленные vCPU имеют право на совместный запуск и могут быть запланированы в зависимости от доступности pCPU. Это решает проблему фрагментации ЦП в строгом алгоритме совместного планирования, не требуя совместного планирования группы виртуальных ЦП. В предыдущем примере виртуальной машины с 4 виртуальными ЦП виртуальная машина может продвигаться вперед, даже если доступен только один свободный pCPU. Это значительно улучшает загрузку процессора. Отслеживая самый медленный одноуровневый vCPU, теперь каждый vCPU может самостоятельно принимать решение о совместном планировании. Как и co-stop, решение о совместном запуске также принимается индивидуально. Как только самый медленный одноуровневый vCPU начинает прогрессировать, совместно остановленные vCPU имеют право на совместный запуск и могут быть запланированы в зависимости от доступности pCPU. Это решает проблему фрагментации ЦП в строгом алгоритме совместного планирования, не требуя совместного планирования группы виртуальных ЦП. В предыдущем примере виртуальной машины с 4 виртуальными ЦП виртуальная машина может продвигаться вперед, даже если доступен только один свободный pCPU. Это значительно улучшает загрузку процессора. Отслеживая самый медленный одноуровневый vCPU, теперь каждый vCPU может самостоятельно принимать решение о совместном планировании. Как и co-stop, решение о совместном запуске также принимается индивидуально. Как только самый медленный одноуровневый vCPU начинает прогрессировать, совместно остановленные vCPU имеют право на совместный запуск и могут быть запланированы в зависимости от доступности pCPU. Это решает проблему фрагментации ЦП в строгом алгоритме совместного планирования, не требуя совместного планирования группы виртуальных ЦП. В предыдущем примере виртуальной машины с 4 виртуальными ЦП виртуальная машина может продвигаться вперед, даже если доступен только один свободный pCPU. Это значительно улучшает загрузку процессора. Как только самый медленный одноуровневый vCPU начинает прогрессировать, совместно остановленные vCPU имеют право на совместный запуск и могут быть запланированы в зависимости от доступности pCPU. Это решает проблему фрагментации ЦП в строгом алгоритме совместного планирования, не требуя совместного планирования группы виртуальных ЦП. В предыдущем примере виртуальной машины с 4 виртуальными ЦП виртуальная машина может продвигаться вперед, даже если доступен только один свободный pCPU. Это значительно улучшает загрузку процессора. Как только самый медленный одноуровневый vCPU начинает прогрессировать, совместно остановленные vCPU имеют право на совместный запуск и могут быть запланированы в зависимости от доступности pCPU. Это решает проблему фрагментации ЦП в строгом алгоритме совместного планирования, не требуя совместного планирования группы виртуальных ЦП. В предыдущем примере виртуальной машины с 4 виртуальными ЦП виртуальная машина может продвигаться вперед, даже если доступен только один свободный pCPU. Это значительно улучшает загрузку процессора. виртуальная машина может продвигаться вперед, даже если имеется только один свободный pCPU. Это значительно улучшает загрузку процессора. виртуальная машина может продвигаться вперед, даже если имеется только один свободный pCPU. Это значительно улучшает загрузку процессора.

Приведенный выше фрагмент взят из собственной документации VMware .

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

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

Хорошо, Райан, ты сделал мой день. Я не читаю этот форум так часто, как раньше, но я случайно зарегистрировался.

Red888, вы должны знать заранее, что я архитектор программного обеспечения, который работает над Hyper-V в Microsoft. Я предполагаю, что большинство людей, читающих это, вполне способны щелкнуть ссылку на мое имя под этим и обнаружить это, или даже погуглить меня, но для этого ответа полезно быть полностью уверенным, что люди, читающие это, не сомневаются в моей перспективе.

В общем случае планирование банд полезно, если гипервизор никак не влияет на поведение ОС, работающей на виртуальной машине. Именно поэтому VMware начал именно так. У них нет операционных систем, поэтому их целью было сделать так, чтобы существующие операционные системы работали хорошо. На их месте я бы начал.

Планирование банд, и VMware, вероятно, скажет, что я прав в этом, оставляет множество ограничений на то, как вы можете использовать физические процессоры в машине. Гипервизор часто не может найти подходящий ресурс на данный момент. Таким образом, они годами модифицировали свой алгоритм, ища способы улучшить планирование.

Microsoft (и, возможно, несколько других компаний) начали с другого взгляда. У нас есть Windows. Мы заставим Windows вести себя хорошо при виртуализации. И, таким образом, планирование банд не будет необходимости. Мы даже не потрудимся построить планировщик банды.

Интересно, что мы в Microsoft больше заботимся о том, чтобы Windows работала хорошо по сравнению с другими операционными системами, чем о том, что Hyper-V выглядит лучше, чем VMware, или KVM, или Xen, или Oracle, или Unisys и т. Д. Поэтому мы опубликовали интерфейсы, которые Windows использует для сотрудничества с гипервизором. Вот ссылка, если вам интересно, хотя я не рекомендую ее читать перед сном:

http://www.bing.com/search?q=Hypervisor+Top-Level+Functional+Specification+3.0a%3A+Windows+Server+2012&src=IE-SearchBox&FORM=IESR02

Таким образом, любой поставщик гипервизора может раскрыть материал, который будет вызывать совместное поведение из Windows. У некоторых из них есть. Я, честно говоря, не знаю, имеет ли VMware, или делает, или будет выставлять это. Вы должны спросить их, или кто-то, кто уделяет им много внимания. И если они это сделают, я был бы очень удивлен, если бы они не изменили свой планировщик, чтобы расслабиться еще больше. Это последнее утверждение, конечно, является чистой спекуляцией.

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

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