Adaptive hypervisor что это
Почему бы не включить «Включить адаптивный гипервизор» в Parallels 11
В последних версиях Parallels Desktop для Mac в конфигурацию включен флажок «Включить адаптивный гипервизор».
Configure > Options > Optimization > Performance > Enable Adaptive Hypervisor
Почему это не включено по умолчанию? Какой минус?
Использует ли это аппаратные функции, такие как Intel в процессоре?
Чтобы настроить Parallels Desktop на автоматическую оптимизацию производительности для Mac OS X или Windows в зависимости от того, с каким приложением или программой вы работаете в данный момент:
Выберите «Включить адаптивный гипервизор». Когда вы используете программу Windows, больше ресурсов отводится Windows, а когда вы используете приложение Mac OS X, больше ресурсов отводится Mac OS X.
Так значит ли эта функция нечто большее, чем просто «освободить процессор в фоновом режиме»? Если это все, что это значит, то почему бы не включить это по умолчанию? Похоже, что продукт предназначен для обычных пользователей настольных компьютеров, которым просто нужно использовать приложение для Windows, поэтому кажется, что эта функция должна быть включена по умолчанию. Тот факт, что это не значение по умолчанию, заставляет меня задуматься о том, есть ли недостаток или риск.
1 ответ 1
Это в их собственных документах:
Если вы одновременно используете много приложений в основной и гостевой ОС, вам может не хватить ресурсов ЦП. В текущей версии Parallels Desktop представлена технология Adaptive Hypervisor, которая помогает наиболее эффективно распределять ресурсы ЦП между основной и гостевой ОС.
Обычно, если у вас есть четырехъядерный процессор, вы можете назначить 1 ядро VM1, 1 ядро VM2 и 2 ядра для ОС хоста. Этот параметр изменяет балансировку на лету при необходимости. Это другой способ делать вещи. Ни то, ни другое.
Гипервизоры. Что же это и как работает виртуальный сервер?
История о том, как программное обеспечение отделившись от оборудования подарило нам виртуализацию и облачную вычислительную среду.
Технологию гипервизоров часто упускают из вида, отдавая предпочтении более популярной и модной концепции виртуализации. Но поверьте, вы не сможете получить истинного удовольствия от применения виртуализации, пока не поймете, что такое гипервизор и как он работает в вычислительной системе.
О преимуществах виртуального сервера и облачных вычислений уже сказано много слов и написано огромное количество статей, настолько много, что кажется будто эта технология уже устарела в быстро развивающемся мире ИТ инфраструктуры. Однако, все же стоит выбросить такие мысли из головы, ведь технология гипервизоров как раз может помочь в стимулировании инноваций в мире облачных вычислений.
Что такое гипервизор?
Гипервизор — это процесс, который отделяет операционную систему компьютера и приложения от базового физического оборудования. Обычно представляет собой программное обеспечение, хотя создаются и встроенные гипервизоры, например, для мобильных устройств.
Гипервизор является движущей силой концепции работы VPS и виртуализации, позволяя физическому хост-компьютеру управлять несколькими виртуальными машинами в качестве гостевых ОС, что в свою очередь помогает максимально эффективно использовать вычислительные ресурсы, такие как память, пропускная способность сети и количество циклов процессора.
История гипервизоров
В конце 1960-х и вплоть 1970-х годов, большинство систем виртуализации и гипервизоров были замечены на мейнфреймах, разработанных компанией IBM. Использовались они для разработки процессов использования компьютера в режиме разделения времени, для тестирования новых операционных систем и идей для их усовершенствования или даже для изучения новых аппаратных концепций. Виртуализация позволила программистам развертывать системы и устранять неисправности, не подвергая угрозам стабильность основной производственной системы, ну и к тому же она позволила уйти от развертывания дополнительных дорогостоящих систем.
В середине 2000-х годов гипервизоры выходят на новый уровень, когда Unix, Linux и другие похожие на Unix операционные системы начали использовать технологии виртуализации. В чем же причины роста интереса к гипервизорам и виртуализации? Ну, во-первых, причина заключалась в улучшении аппаратных возможностей и мощностей, которые теперь позволили бы одной машине выполнять более синхронизированную работу; во-вторых, усиление контроля издержек, что привело к консолидации серверов; в-третьих, значимую роль сыграла безопасность и надежность благодаря усовершенствованию архитектуры гипервизоров; и конечно последняя, но не менее важная причина — возможность запуска зависимых от ОС приложений в различных аппаратных или операционных средах. Кроме того, в 2005 году разработчики процессоров начали добавлять аппаратную виртуализацию в свои продукты на базе x86, расширяя доступность (и преимущества) виртуализации для ПК и серверной аудитории.
Преимущества гипервизоров
Несмотря на то, что виртуальные машины могут работать на одном и том же физическом оборудовании, они по-прежнему логически отделены друг от друга. Это означает следующее — если на одной виртуальной машине произошла ошибка, системный сбой или вредоносная атака, то это не распространяется на другие виртуальные машины независимо от того, установлены они на этом же компьютере или на других физических машинах.
Виртуальные машины также очень мобильны — поскольку они не зависят от основного оборудования, их можно перемещать или переносить между локальными или удаленными виртуальными серверами. И сделать это намного проще, в сравнении с традиционными приложениями, привязанными к физическому оборудованию.
Существует два типа гипервизоров с очень «креативными» названиями «ТИП 1» или «ТИП 2». Гипервизоры типа 1, иногда называемые «автономными гипервизорами», запускаются непосредственно на аппаратном обеспечении хоста для управления оборудованием и управления гостевыми виртуальными машинами. К современным гипервизорам первого типа относятся: Xen, Oracle VM Server для SPARC, Oracle VM Server для x86, Microsoft Hyper-V и VMware ESX / ESXi. Под управлением Hyper-V, кстати, работают все серверы VDS Windows на хостинге VSP.house.
Гипервизоры типа 2, иногда называемые «хостовыми гипервизорами», запускаются на обычной ОС, как и другие приложения в системе. В этом случае гостевая ОС выполняется как процесс на хосте, а гипервизоры разделяют гостевую ОС и ОС хоста. Примеры гипервизоров второго типа: VMware Workstation, VMware Player, VirtualBox и Parallels Desktop для Mac.
На данный момент можно выделить трех основных крупнейших разработчиков гипервизоров: VMware, Microsoft и Citrix Systems.
Контейнеры против гипервизоров
В последние годы контейнерные технологии стали популярными в качестве возможной замены гипервизоров. Причина в том, что они могут размещать больше приложений на одном физическом сервере, чем виртуальная машина.
Один из публицистов в статье 2016 для Network World высказал интересное мнение. Он заявил, что виртуальные машины используют много системных ресурсов, ведь каждая виртуальная машина запускает не только полную копию операционной системы, но и виртуальную копию всего оборудования, на котором должна запускаться операционная система. Соответственно, быстро возникает необходимость в использовании большого количества запоминающих устройств и машинных циклов. А все, что требуется контейнеру, — это операционная система, поддерживающая программы и каталоги, а также системные ресурсы для запуска конкретной программы.
Однако, не стоит думать, что контейнеры обязательно заменят гипервизоры и виртуальные машины, ведь существуют проблемы безопасности и практического использования виртуальных машин. Скорее всего компании будут использовать оба метода в совокупности. И кстати о безопасности, некоторые считают, что контейнеры менее безопасны, чем гипервизоры. Причина в том, что в контейнерах имеется только одна ОС, которую используют приложения, в то время как виртуальные машины изолируют не только приложения, но и ОС. Если одно из приложений попадает под угрозу, оно может атаковать и ОС в контейнере, что влияет в свою очередь и на другие приложения. В тоже самое время если на виртуальной машине приложение становится уязвимым, то оно сможет оказать вредоносное действие исключительно на одну ОС на сервере, а другие приложения или ОС на виртуальной машине остаются в безопасности.
Проблемы безопасности гипервизоров
Хотя благодаря многим мерам предосторожности гипервизоры считаются более безопасными, чем контейнеры, это не означает того факта, что у гипервизоров нет вообще проблем, связанных с безопасностью. Например, в теории хакеры могут создавать вредоносные программы и руткиты, которые устанавливаются под ОС как гипервизор. Этот процесс, известный как «гиперджекинг», сложно обнаружить, так как вредоносное ПО может перехватывать действия операционной системы (например, ввод пароля) без необходимости защиты от вредоносного ПО, поскольку данное вредоносное ПО уже работает под ОС.
Профессионалы в мире виртуализации могут бесконечно вести дискуссии и споры о том, можно ли обнаружить присутствие руткита на базе гипервизора. Уже даже созданы несколько подходов на эту тему, одними внедрена концепция вредоносного ПО (SubVirt и Blue Pill), другие продемонстрировали антируткит Hooksafe, который обеспечивает эффективную защиту ОС от руткитов режима ядра без заметных потерь в производительности.
Расширение возможностей гипервизора
Концепция гипервизоров не ограничивается только работой сервера. Например, гипервизоры хранилища используют ту же концепцию, применяя ее к хранилищу данных. Гипервизор хранения может работать на физическом оборудовании, как виртуальная машина, внутри операционной системы гипервизора или в более крупной сети хранения. Гипервизоры хранилища также, как и обычные гипервизоры, могут работать на определенном оборудовании или быть независимыми от оборудования.
Помимо хранения, гипервизоры являются ключом для других процессов виртуализации, включая виртуализацию рабочего стола, виртуализацию ОС и виртуализацию приложений.
Также встречается еще и встроенные гипервизоры. Что же это такое? Встроенные гипервизоры поддерживают требования встроенных систем. Они немного отличаются от гипервизоров, ориентированных на серверные и настольные приложения. Встроенный гипервизор с самого начала внедряется во встроенное устройство, а не загружается при последующем развертывании устройства. Во встроенной системе различные компоненты обычно функционируют совместно для обеспечения функциональности устройства.
5 советов, как разогнать Parallels Desktop
С решением Parallels Desktop мы знакомы уже лет 7. Как это ни парадоксально, до сих пор потребность в работе с Windows (у кого-то Linux) на Mac сохраняется. Каждый год, в каждой новой версии разработчики Parallels стараются сделать ее быстрее предыдущей, однако вопросы о том, сколько памяти потребляет виртуальная машина и как сделать так, чтобы гостевая операционная система работала так же быстро, как нативная, похоже, не исчезают (и не исчезнут до тех пор, пока аппаратные возможности не позволят запускать одновременно Windows и Mac OS X, оставляя при этом больше свободных ресурсов для приложений).
Способ 1: полезные настройки
Например, в меню Parallels Desktop выберите Preferences, затем Advanced. Отключите там возможность отправки детализированных логов (Use detailed log messages). Эту функцию стоит включать, только если у вас есть какие-то проблемы, связанные с работой виртуальной машины, и вы по этому поводу общаетесь с техподдержкой Parallels. Сбор детализированных логов потребляет больше ресурсов.
А теперь поиграем с настройками производительности и энергопотребления. В меню Virtual Machine выбираем последовательно: Configure, Options, Optimization. В разделе Performance выбираем Faster Virtual Machine и ставим галочки рядом с Enable Adaptive Hypervisor и Tune Windows for Speed. Опции Faster Virtual Machine и Enable Adaptive Hypervisor устанавливают приоритет процессам виртуальной машины над процессами OS X. Tune Windows for speed ускоряет загрузку Windows и оптимизирует работу приложений в виртуальной машине.
Дальше, что ест много ресурсов? Правильно, видео и 3D-графика. Поэтому можно уменьшить количество видеопамяти, отведенной для виртуальной машины. По умолчанию ее значение равняется 256 Мб. Для офисной работы и даже для двухмерной графики (например, Photoshop) это излишне. В меню Virtual Machine выбираем Configure, затем Hardware, и в разделе Video снижаем значение Video memory до 128 Мб. Там же можно выбрать режим ускорения 3D, либо вовсе отключить его (особенно полезно тем, у кого не очень новый Мак).
Что еще можно сделать? Например, попробуйте отключить доступ к папкам Windows из OS X. Это можно сделать в разделе Sharing на вкладке Options.
Но все это мелочи, а теперь о важном – о самостоятельном регулировании количества процессоров и памяти, которые можно назначить виртуальной машине. По дефолту у всех в настройках виртуальной машины стоит 1 процессор и 1 Гб памяти, и по умолчанию у многих чешутся руки непременно добавить себе всего и побольше. При этом юзеры забывают о том, что виртуальные процессоры и память не ведут себя в точности так же, как «железные», «больше памяти» не всегда будет значить «шустрее летает», а передоз иногда может просто навредить.
На самом деле в большинстве случаев лучшая производительность будет, если оставить один процессор на одну виртуальную машину. Несколько процессоров может потребоваться только в случае, если вы запускаете несколько приложений, каждое из которых связано с обработкой больших массивов данных, например, научные вычисления или системы онлайн-трейдинга. При этом минимум назначенной памяти должен соответствовать тому минимуму, который в системных требованиях рекомендуют для вашей гостевой ОС (они обычно вывешены на сайте ее разработчика).
Если вы не уверены, что настройки по умолчанию спасут отца русской демократии ваши приложения, то нужно сначала все протестировать. Допустим, у вас виртуальная машина Windows и обычно вы работаете с Microsoft Office Suite, FireFox и парой других приложений. Запустите под дефолтными настройками свой Windows и по нескольку файлов приложений, с которыми вы обычно работаете, скажем, откройте несколько сообщений в Microsoft Outlook, 3 документа Microsoft Word, пару файлов Microsoft Excel, 10 вкладок в Firefox и IE до кучи, презентацию PowerPoint и еще пару приложений – и поработайте с ними немного. Кликните правой кнопкой мыши на панели задач Windows и запустите Диспетчер задач. Переключитесь на вкладку Приложения и проверьте, сколько сейчас чего используется.
Обычно можно увидеть, что все запущенное потребляет около 80% памяти и меньше 1% процессора, значит, установленного по умолчанию достаточно, чтобы все прилично работало. Однако если вы будете использовать что-нибудь флешовое, этого может не хватить (о флеше мы поговорим в хинте ниже).
Если показатели не радуют, то выключаем Windows через кнопку Пуск. После завершения работы ОС идем в верхнее меню Virtual Machine, выбираем Configure, затем General. Здесь с небольшим запасом выставляем значение оперативной памяти, показанное Диспетчером задач Windows с небольшим запасом, скажем, в 15%. Мы рекомендуем добавлять не более 256-512 Мб за раз. В итоге: по сравнению даже с дефолтными настройками количество памяти снизится. Сэкономленный объем быстрой (в отличие от жесткого диска) памяти останется у Mac OS X. “Хост” не будет тормозить, а значит, будет быстрее работать и виртуальная машина.
Способ 2: используем неиспользуемое
Способ 3: снапшоты
Люди, которые используют снапшоты, часто забывают удалить их. Люди, которые забывают удалить снапшоты, часто забывают о том, сколько дискового пространства они едят.
Снапшоты обычному пользователю без надобности, зато их в больших количествах (особенно, если подключен режим автоматического их создания во время работы виртуальной машины) плодят товарищи разработчики в гостевых ОС и любители что-нибудь эдакое установить или реконфигурировать (чтобы можно было всегда откатиться назад). Если вам ничего этого не нужно, лучше проверить, не включен ли режим автоматического создания снапшотов SmartGuard (и выключить его) в разделе Backup на вкладке Options. А если снапшоты вам нужны и полезны, но от случая к случаю, то там же можно выбрать следующую опцию Custom, тогда вы сможете сами ограничить частоту и максимальное количество хранимых снапшотов (по умолчанию максимум – это 100 штук, когда появляется 101 – самый старый удаляется). Опция Notify me before snapshot creation позволит отклонить создание ненужного снапшота и информировать о его создании.
Правда, все равно потом забудете, поэтому вот как удалить снапшот:
Все упомянутое – это для версий с 6 по 8, а также с версии 8 в Parallels Desktop есть возможность удалять снапшоты даже если места на диска меньше, чем размер снапшота.
Способ 4: управляем прожорливыми приложениями
Во-первых, «торможение» вполне может возникать из-за использования некоторых антивирусов. Попробуйте применять только те антивирусные программы, которые предлагает Parallels Desktop – их выбирали, исходя из того, что они оптимально работают в виртуальной машине. В 9-й версии Parallels Desktop, кстати, сейчас есть довольно удобный мастер безопасности, где все операции со всеми доступными антивирусными программами можно сделать в одном окне. Если у вас антивирус «не из списка», попробуйте его временно выключить и посмотреть на показатели.
Во-вторых, есть серьезные жалобы на Adobe Flash, который неконтролируемо кушает память, особенно если вы активно серфите по Интернету, а там много флешевых баннеров. Под браузер выделяется память операционной системы. Кэш переполняется, и данные сбрасываются на жесткий диск в файл подкачки (swap). Если у вас долго висит свернутый (а не закрытый) браузер, то в «свопе» накапливается огромное количество данных.
Поэтому посматривайте на параметр Swap used в Activity Monitor. Если количество данных там растет и стало явно больше 1 Гб, вероятно, какое-то приложение не отпускает свою память.
Профилактика очень простая – периодически закрывать браузер целиком, используя Cmd+Q, и вообще, почаще пользоваться этой функцией.
Способ 5: SSD, и еще раз SSD
По словам разработчиков, 30% пользователей Parallels Desktop уже используют Маки с SSD и от них никаких жалоб на прожорливость продукта не поступает. Дело в том, что Parallels Desktop использует многопоточные операции ввода-вывода при работе с жестким диском, что дает особенно ощутимый прирост производительности на Маках с SSD. Кроме того, информация о типе диска предоставляется гостевой ОС, благодаря чему та может использовать свои собственные механизмы для оптимизации работы с SSD.
В новой версии 12 Parallels Desktop для Mac появилась новая опция конфигурации. На панели конфигурации> Оборудование> Процессор и память> Расширенные настройки> Hypervisor есть всплывающее меню для:
Какой из них мне следует использовать при запуске macOS Sierra в качестве гостевой ОС?
В чем именно разница, плюсы и минусы каждого?
В справке приложения Parallels ничего не говорится об этой новой настройке.
Каркас гипервизора предоставляет API-интерфейсы C для взаимодействия с технологиями виртуализации в пользовательском пространстве без необходимости написания расширений ядра (KEXT). В результате приложения, созданные с использованием этой платформы, подходят для распространения в Mac App Store.
Если вы хотите запустить виртуальную машину Window 10 для тестирования или определенного приложения, то либо Hypervisor, вероятно, будет работать нормально.
Если вы хотите загрузить хост Linux для разработки, которую вы хотите сделать доступной, независимо от того, находитесь ли вы на своем компьютере или нет, вам, вероятно, нужен гипервизор Parallels.
В этом сообщении на форуме Parallels четко говорится об использовании Parallels Hypervisor:
Привет, гипервизор Apple не справляется со следующими вопросами по сравнению с гипервизором Parallels:
Производительность: медленнее при запуске и завершении работы виртуальной машины
Стабильность: может зависать чаще
Потеря функциональности: нет PMU, вложенная виртуализация, термический мониторинг, профилирование энергии
Apple в настоящее время ограничивает возможности разработчиков по внедрению kexts (расширений ядра) на ваше устройство. Они делают это потому, что разработчики программного обеспечения, которые полагаются на kexts, как правило, более чем способны производить неоптимальные системы, способные дестабилизировать Mac. И VMware, и Parallels используют kexts; Продукты обеих компаний легко способны дестабилизировать Mac, и обе компании производят неоптимальное программное обеспечение. Я использовал VMWare (Fusion) и Parallels на Mac; из этих двух я нашел Fusion самым стабильным.
Платформа гипервизора (выпущенная в Yosemite около 3 лет назад) позволит поставщикам программного обеспечения получать продукты виртуализации в Mac App Store. Фреймворк предназначен не для разработчиков, это механизм, который используется разработчиками для получения нужных вам продуктов. Сейчас появилось немало бесплатных продуктов, поддерживающих эту платформу. Как разработчик, я не могу дождаться, когда появятся другие продукты для виртуализации, на которых я смогу запустить Windows (для разработки программного обеспечения). Я с нетерпением жду свободной виртуализации kext. Скорее всего, компромиссом будет сокращение или устранение уловок, которые обременяют хост-систему. Так что, никаких модных оконных скинов; кому это все равно интересно? Нет «бок о бок» (скрытый рабочий стол Windows); опять не интересуюсь я всегда бегаю в окне или во весь экран. Нет ускоренных игр, хотя я Я не уверен в этом. Но, если вы ищете игровой автомат, переходите на родной или создайте его. Я ищу стабильную, оптимизированную, быструю и эффективную виртуализацию. В настоящее время ни VMWare, ни Parallels не предоставляют этого.
Я собирался попробовать Parallels Desktop Lite; но если это без ошибок и работает, зачем мне подписка на 60 фунтов стерлингов за год? По европейскому законодательству, если продукт содержит ошибки, я имею право на исправление; Я не должен был платить за это. Я не заинтересован в компаниях, чья бизнес-модель заключается в том, чтобы привязать меня к подписке, потому что они предоставляют мне программное обеспечение с ошибками.
(@basil) обновление: это Parallels Lite работает с высокой Сьерра 
Несколько слов о реальной производительности гипервизора
Пользователи виртуализированных систем, а особенно – сервис-провайдеры, очень часто задаются вопросом: «как выжать максимум из имеющегося железа?». И в этом контексте нам нередко приходится обсуждать гипервизор KVM и отличия между разными версиями Virtuozzo. В этом посте мы расскажем о ряде тестов последней системы виртуализации вместе с оценками реальной производительности при типовых нагрузках, а также с учетом патчей Meltdown и Spectre.
Что важнее всего для хостинговой компании или для ИТ-отдела, которому необходимо организовать поддержку максимального количества задач на имеющемся оборудовании? Если компания работает по сервисно-ориентированной модели или продает сервисы, то практика показывает, что главное – это показатель прибыли на один сервер. Какие при этом используются технологии и за счет чего достигается плотность размещения, уже не так сильно волнует представителей бизнеса.
Тем не менее, вопрос, почему мы используем KVM в виде гипервизора в Virtuozzo 7, и чем мы в таком случае отличаемся от простой OpenSource-системы виртуализации, задают очень часто. И сегодня хочется дать на него ответ.
В прошлом Virtuozzo работала со своим собственным, проприетарным гипервизором, но несколько лет назад мы поняли, что развивать его дороже и сложнее, чем оптимизировать достаточно удачный и эффективный KVM. Тем не менее, KVM не является эталоном производительности, и как любая OpenSource-платформа требует доработки напильником. Этим и занимается часть нашего отдела разработки. Мы оптимизируем код, интегрируем его с платформой хранения данных и другими компонентами, за счет чего достигается повышение производительности и плотности размещения.
Сравнение с другими гипервизорами
Одним из тестов, которые мы используем для оценки производительности, является DVD Store. Он использует классический набор серверного программного обеспечения: Linux, Apache, MySQL, PHP (LAMP). Внутри каждой виртуальной машины тест эмулирует работу онлайн-магазина по продаже DVD. Результатом теста является количество транзацкий совершенных суммарно во всех виртуальных машинах (ось ординат). Количество виртуальных машин, вовлеченных в тест, увеличивается последовательно от 1 до 100 (ось абсцисс).
LAMP: OpenSource QEMU KVM vs Virtuozzo @ CentOS 7.4 (виртуальные машины)
Как видно на графиках выше, производительность виртуальных машин с CentOS Linux 7.4 работающих на гипервизоре Virtuozzo 7 оказывается до 30% выше, чем при запуске аналогичной нагрузки на стандартном KVM. Наибольшая разница наблюдается в точке CPU-оверкоммита, где суммарное количество ядер процессоров, выделенных всем виртуальным машинам, достигает количества физических ядер CPU сервера. Для данного сервера эта точка соответствует 20 виртуальным машинам. Кроме того, ядро Virtuozzo 7 и адаптивная политика управления памятью обеспечивают стабильную работу виртуальных машин после точки RAM-оверкоммита, где суммарное количество оперативной памяти, выделенное всем виртуальным машинам, превышает размер физической памяти сервера. При такой нагрузке стандартный KVM вовсе не может создать условия для нормальной работы.
Другое сравнение было проведено между гипервизорами Virtuozzo 7 и Microsoft Hyper-V 3.0. Здесь производительность оценивалась с помощью теста vConsolidate, а в качестве гостевой операционной системы виртуальных машин использовалась Windows Server 2012 R2.
vConsolidate: Hyper-V vs Virtuozzo @ Windows 2012 R2 (виртуальные машины)
В отличие от DVD Store, в vConsolidate нагрузка не одинакова для всех виртуальных машин. В этом тесте они разделены на так называемые CSU (Consolidation Stack Units). Каждая CSU – это группа из четырех виртуальных машин, нагрузку в которых создают SPECjbb, WebBench и SysBench (OLTP). Четвертая ВМ в каждой CSU – idle, то есть без нагрузки. Количественным результатом является среднее геометрическое от результатов трех вышеупомянутых тестов, полученных суммарно из всех виртуальных машин (ось ординат). Количество CSU, вовлеченных в тест, увеличивается последовательно от 1 до 24 (ось абсцисс).
Для обоих гипервизоров тест проводился дважды: с установленными патчами для уязвимостей Meltdown и Spectre, а также без них. Аппроксимация результатов показывает, что Virtuozzo 7 в среднем демонстрирует на 15% более высокую производительность, чем «родной» гипервизор Microsoft.
Meltdown и Spectre
Как известно, 4 января 2018 года всё IT-сообщество было взбудоражено обнаружением масштабных концептуальных уязвимостей во всех процессорах Intel, за исключением Itanium и старых Atom (до 2013 года). Использование этих уязвимостей позволяет любому непривилегированному процессу в системе получить доступ к данным ядра (Meltdown) или данным другого процесса (Spectre). Разработчики ПО сосредоточились на выпуске обновлений программно устраняющих эти уязвимости. Однако у пользователей, естественным образом, возникли вопросы о том, как эти обновления сказались на производительности систем.
Мы проверили насколько патчи для Meltdown и Spectre влияют на производительность контейнеров с CentOS Linux 7.4 на примере теста vConsolidate. Затем мы провели еще одно измерение – с ядром скомпилированным модифицированным компилятором с опцией «Retpoline» (такую возможность, например, предлагают GCC и Clang/LLVM).
Производительность с Retpoline: vConsolidate @ CentOS 7.4 (контейнеры)
Как видно на графиках выше, применение патчей против Meltdown и Spectre значительно снижает производительность контейнеров. Причем самым «тяжелым» оказался патч для Spectre-V2. Однако использование компилятора с новой опцией Retpoline позволяет безопасно отказаться от этого патча на системах с процессорами старше Skylake и отыграть целых 25% производительности. Впрочем, около 5% мы всё же потеряли из-за патчей для Meltdown и Spectre-V1.
Производительность с Retpoline: vConsolidate @ CentOS 7.4 (виртуальные машины)
В случае с CentOS Linux 7.4 внутри виртуальных машин ситуация выглядит немного радужнее: патчи для Meltdown и Spectre ухудшают производительность всего на 15%, а разница в производительности непропатченного ядра и ядра скомпилированного с Retpoline составляет всего 1-2%. Таким образом, использование нового компилятора позволило практически полностью скомпенсировать падение производительности. Однако стоит учесть, что все три измерения проводились на одних и тех же виртуальных машинах – с непропатченными ядрами гостевых ОС. Обновление гостевых ОС повлечет дополнительное ухудшение производительности пользовательских приложений.
Производительность с Retpoline: vConsolidate @ Windows 2012 R2 (виртуальные машины)
Последний на сегодня график – аналогичное сравнение, но уже с виртуальными машинами Windows Server 2012 R2. Здесь замедление от патчей было не так велико и составило около 10%, а использование ядра с Retpoline позволило сократить разницу до 2-3% относительно непропатченного ядра.
Заключение
Безусловно, у немодифицированного KVM есть свои плюсы, и основное достоинство — это его бесплатность. Но проведенные тесты доказывают, что частные доработки и модернизация позволяют повысить отдачу от используемой инфраструктуры. То есть, если вам нужно разместить максимум контейнеров и виртуальных машин, обеспечить для них постоянное хранение – всё это на одной платформе и с минимумом шаманских танцев – улучшенный KVM оказывается намного результативнее, особенно если сервисы, работающие на платформе, показывают хорошую маржу и приносят реальные деньги. В этом случае стоимость лицензий и поддержки с лихвой окупается в кратчайшие сроки.
Сильной стороной VZ7 остается поддержка разных типов ВМ и контейнеров на одной платформе, причём с более высокой производительностью для каждой категории виртуальных объектов. Однако и здесь нельзя говорить о панацее. Например, если повышение плотности не принесёт организации дополнительных финансов, а собственный персонал вполне может администрировать и допиливать OpenSource-решения, тогда логика склоняет к использованию открытых инструментов, в том числе CentOS и оригинального KVM.
Кстати, в следующем посте мы расскажем об эволюции нашего распределенного хранилища и о его реальных возможностях для работы с ВМ и контейнерами.