Pull to refresh

Comments 27

Сравнение с ESXi не делалось намеренно?

В каком-то смысле да, так как задача ставилась сравнить производительность с KVM, на базе которого был разработан гипервизор в VZ7.

Однако же с MS Hyper-V сравнение есть. К чему такая хитрая избирательность? :)
VMware запрещает публикацию каких-либо сравнений своих продуктов с конкурентами без их согласия.
А как такое возможно?

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

Присоединяюсь к коллеге. KVM можно настроить так, что отставание будет тысячекратным или наоборот, меньше погрешности.
Сила дефолта. Мы никак не настраиваем бесплатный KVM и продукты конкурентов. Берём их как есть. Если они не позаботились о том, чтобы дефолтная конфигурация их продукта обеспечивала максимальную производительность – это не наша вина, а их беда.
VZ тоже не настраиваете, разумеется?
Разумеется настраиваем в процессе разработки. Но релизная версия ни коим специальным образом не настраивается для тестирования производительности. Берётся как есть.
Какие именно условия Вас интересуют? В пределах одного графика условия для всех испытуемых одинаковы: один и тот же стенд клиент-сервер, одна и та же конфигурация железа. Каждый продукт тестируется с дефолтными настройками, за исключением тех настроек, которые описаны в легенде к графику.

Все условия. Если я оцениваю производительность, я хочу четко понимать, что и как протестировано, а паттерн нагрузки "нечто не пойми на чём при дефолтных настройках" не несет практического смысла. Нет описания даже настолько базовых вещей, как железо, конфиги VM и паттерны нагрузок, или какие конкретно патчи для meltdown/spectre ставились и куда.


Тестирование Hyper-V 2012 — тоже своеобразный подход. Хотел бы я посмотреть на вашу реакцию, увидь вы в блоге MS тестирование WS 1803 против ваших разработок 6-тилетней давности. ;)


Далее — vConsolidate. Тут занятно всё — и то, что разработка бенчмарка его авторами была свернута лет этак 8 назад, и то, что более-менее свежие ссылки из гугла относительно тестирований этим бенчмарком касаются исключительно openvz/virtuozzo.


Мы никак не настраиваем бесплатный KVM и продукты конкурентов.

И это еще один пример маркетинговой лапши. "Продукты конкурентов", очевидно, используются в крайне широком круге задач, и для оптимизации под разные задачи в разных средах нужны разные настройки. А дефолтная конфигурация там не столько про производительность, сколько про то, что оно должно для начала завестись на чём угодно из HCL, а потом его уже можно настраивать (это даже Hyper-V касается, хотя и в меньшей степени).


А конкретно про гипервизоры читать про дефолные настройки забавно еще и потому, что, скажем, дефолтная конфигурация VM там зависит даже не столько от самого гипервизора, сколько от системы управления. То есть диспетчер Hyper-V создаст виртуалку с одним конфигом, SCVMM с другим, Proxmox с третьим, RHEV с четвертым, и т.п. И как читатель должен угадывать, что вы на самом деле там тестируете?

Нет описания даже настолько базовых вещей, как железо, конфиги VM и паттерны нагрузок, или какие конкретно патчи для meltdown/spectre ставились и куда.

Согласен, конфигурацию железа и VM/контейнеров действительно стоит добавить. Каковы паттерны нагрузок в тестах vConsolidate и DVD Store, можно узнать из их описания, эта информация доступна в Интернете. То же касается и патчей для Meltdown/Spectre. Достаточно загуглить KTPI, IBRS, IBPB.
Тестирование Hyper-V 2012 — тоже своеобразный подход.

2012 R2 – это гостевая операционная система. Использовалась в тесте как наиболее распространённая на данный момент серверная версия Windows. Хостовый гипервизор – на базе Windows Server 2016. Виртуальные машины – второго поколения. То, что это не упомянуто в статье – наше упущение, исправимся.
Далее — vConsolidate.

Есть много мнений на этот счёт. Для нас это – нестареющая классика. Бенчмарк позволяет оценить одновременно производительность и плотность размещения виртуальных сред эмулируя внутри них разнотипную нагрузку: Java, Web, DB. Что 8 лет назад, что сейчас – это самые популярные виды нагрузок. Много ли было за это время изобретено новых бенчмарков, позволяющих делать то же самое для гостевых Windows?
«Продукты конкурентов», очевидно, используются в крайне широком круге задач, и для оптимизации под разные задачи в разных средах нужны разные настройки.

Безусловно. Если перемножить все задачи, среды, настройки и гипервизоры, мы получим великое множество конфигураций. И чтобы сравнить их все между собой, не хватит человеческой жизни. Именно поэтому мы используем дефолтную конфигурацию для каждого продукта, в том числе и для наших.
А конкретно про гипервизоры читать про дефолные настройки забавно еще и потому, что, скажем, дефолтная конфигурация VM там зависит даже не столько от самого гипервизора, сколько от системы управления.

Отчасти Вы правы. Такие базовые вещи как количество vCPU или vRAM мы конечно же приводим к одному знаменателю. Следующее, что может значительно влиять на производительность – типы эмулируемых виртуальных устройств – диска, сетевой карты и т.д. К сожалению мы не располагаем достаточным количеством времени, чтобы протестировать на предмет производительности все комбинации виртуальных устройств у конкурентов и поэтому полагаемся на дефолт, который предлагает система управления. Ведь согласитесь, если система управления создаёт VM c неоптимальной для производительности конфигурацией, то это – баг системы управления. Кроме того, в каких-то частных ситуациях мы полагаемся на общеизвестные факты о том какой тип устройства обладает более высокой производительностью. Например, известно, что на данный момент наилучшим решением блочного драйвера для KVM является Virtio-SCSI. Мы используем его у себя в качестве дефолтного и естественно, когда сравниваем себя с бесплатным KVM, и там используем Virtio-SCSI.
эта информация доступна в Интернете. То же касается и патчей для Meltdown/Spectre. Достаточно загуглить

Ох. Вот понимаете, вроде бы вы делаете полезное дело — хотите обрисовать потенциальному потребителю преимущества вашего продукта. Но вместо того, чтобы просто прочитать статью и получить полезную информацию, я в итоге должен "загуглить" кучу всего — описания крайне малораспространенных и практически никем, кроме вас не используемых бенчмарков, попутно разбираясь с тем, насколько они вообще релевантны по отношению к текущему рынку ПО (и потом там что, бенчмарк вообще неконфигурирумый, паттерн наргрузки только один?); разбираться, какие версии ПО вы на самом деле используете (версию Hyper-V вы указали неверно, а как насчет остального?); должен каким-то образом понимать, какие конкретно патчи вы используете (ибо постоянно находятся новые варианты Spectre/Meltdown, для них выходят соответствующие патчи, старые патчи отзываются/перевыпускаются, патчи можно ставить только на хосты или внутри VM тоже, а был ли пропатчен микрокод процессора и чем, и т.д., и т.п.).


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


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


Ведь согласитесь, если система управления создаёт VM c неоптимальной для производительности конфигурацией, то это – баг системы управления.

Не соглашусь. Во-первых, я уже писал, что дефолтные настройки могут быть рассчитаны на совместимость, а не на производительность. Во-вторых, система по умолчанию может попросту создавать VM, соответствующую минимальным системным требования для соответствующей ОС. Вполне очевидно, что к реальной эксплуатации это не будет иметь никакого отношения, и первое, что будет делать админ — менять конфиг (или настраивать собственные шаблоны для автоматизированного развертывания). Или другой факт — голая производительность не единственное, что интересует потребителя. Например, попутно может интересовать энергопотребление. И, в частности, при виртуализации на винде это весьма актуально — дефолтный профиль энергосбережения вовсе не max performance. Да и в целом люди, которым действительно нужна производительность, свои системы настраивают. Именно поэтому в общепринятных индустриальных тестах (SPEC, TPC и т.п.) не некие "дефолтные" конфиги используют, а каждый пытается выжать максимум из своей системы.


И, в любом случае, простое подробное описание тестируемых конфигураций сняло бы массу вопросов. Скорее всего, породило бы новые, но они, по крайне мере, были бы уже более по существу, а не просто в духе "Эмм… а что конкретно вы меряли-то?".

Увидел ваши цены, пожалуй останусь на квм
Ага, тоже как-то рискнул запросить прайс. Поперхнулся кофе и радостно побежал за свежей версией Проксмокса.
> В прошлом Virtuozzo работала со своим собственным, проприетарным гипервизором, но
> несколько лет назад мы поняли, что развивать его дороже и сложнее, чем оптимизировать
> достаточно удачный и эффективный KVM.

Разумно, конечно, но жаль. Virtuozzo была довольно-таки уникальной. И vzfs и то, как процессор разделялся, память.
Если Вы имеете в виду контейнерную виртуализацию, то в Virtuozzo 7 эта уникальность никуда не исчезла. В приведённой Вами цитате речь идёт о гипервизоре – мониторе виртуальных машин.
Вы пишите о своих наработках на базе KVM. Отправляете ли вы эти патчи в апстрим и принимают ли их? Можно ли где то у вас на сайте их получить/скачать и нужно ли для этого быть вашим клиентом?
И QEMU и ядро Linux, частью которого является KVM, публикуются под GPLv2, соответственно исходники должны быть;).
Ну, это, казалось бы легко проверить в соответствующем репозитории. На самом деле, изменения достаточно активно вливаются и в KVM, и в QEMU. В позапрошлом и поза-поза-прошлом годах, когда на KVM forume статистика подводилась, Virtuozzo присутствовало в Top10 контрибьюторах от компаний в QEMU & Libvirt. В 2017 году Паоло эту статистику не предоставил, так что тут сказать не могу. Но, по нашим ощущениям, хуже быть не должно.

В mainstream ядро вклад тоже есть и не малый. Объем измеряется сотнями патчей только за этот год.

Касательно GPLv2 — вам стоит прочитать ее внимательно. Согласно лицензионному соглашению исходные тексты обязаны быть предоставлены людям, получившим бинарники системы, тем или иным способом.
Приятно это слышать, правда круто)
Касательно GPLv2 — вам стоит прочитать ее внимательно. Согласно лицензионному соглашению исходные тексты обязаны быть предоставлены людям, получившим бинарники системы, тем или иным способом.

Да, я это знаю. Как раз про это была эта часть моего вопроса:
… нужно ли для этого быть вашим клиентом?

Многие просто выкладывают исходники в открытый доступ, но не будучи вашим клиентом я не могу требовать их у вас.
Основная проблема virtuozzo как по мне — практически полное отсутствие совместимости с предыдущими релизами.
С какого перепугу вы считаете, что пользоваетль выберет вашу систему виртуализации, если ему прийдется все равно заново учить все команды и настройки?
Ладно бы выигрыш в производительности или удобстве был подавляющий, но он реально мал.
«Стандартный KVM» это что-то типа «обычного порошка», да?
Позвольте развеять Ваши заблуждения насчёт отсутствия совместимости с предыдущими релизами.
Во-первых, любой контейнер и любую VM, созданные на любой предыдущей версии Virtuozzo, можно смигрировать на 7.0. При этом контейнеры мигрируют с точно такой же скоростью как при миграции между двумя нодами с одной версией. В некоторых случаях с совсем старыми версиями возможно потребуется двухступенчатая миграция на промежуточную версию. Что же касается виртуальных машин, то несмотря на отличие в гипервизоре Vz6, на Vz7 предусмотрен простой и понятный механизм миграции виртуальных машин с Vz6. Миграция происходит медленнее, чем в случае с контейнерами, из-за необходимости конвертации диска в QCOW2.
Во вторых, что касается команд, в Vz7 есть все те же утилиты для управления виртуальными машинами и контейнерами, что и в предыдущих версиях, c сохранением их полной функциональности. Что же касается настроек, то поменялась только та часть из них, которая требовала переезда с ядра 2.6 на 3.10.
А расскажите, пожалуйста, где можно о гипервизорах почитать?
Я правильно понимаю, что с их помощью можно делать «тонкие клиенты» на одном физическом устройстве?

Могут ли они использовать gpu?

Меня интересует возможность купить один мощный ПК домой и использовать его параллельно вдвоём-втроём.
Реально ли это? В играх тоже?

Спасибо огромное!

Sign up to leave a comment.