Что важнее всего для хостинговой компании или для ИТ-отдела, которому необходимо организовать поддержку максимального количества задач на имеющемся оборудовании? Если компания работает по сервисно-ориентированной модели или продает сервисы, то практика показывает, что главное – это показатель прибыли на один сервер. Какие при этом используются технологии и за счет чего достигается плотность размещения, уже не так сильно волнует представителей бизнеса.
Тем не менее, вопрос, почему мы используем 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.
Кстати, в следующем посте мы расскажем об эволюции нашего распределенного хранилища и о его реальных возможностях для работы с ВМ и контейнерами.
Комментарии (25)
ildarz
04.06.2018 09:45Для того, чтобы такая статья приобрела минимально технический характер, а не вызывала впечатление рекламного буклета с нарисованными цветными фломастерами красивыми картинками, в ней не хватает подробного описания условий тестирования и сырых данных.
mrobespierre
04.06.2018 11:04Присоединяюсь к коллеге. KVM можно настроить так, что отставание будет тысячекратным или наоборот, меньше погрешности.
svaroq
04.06.2018 16:39Сила дефолта. Мы никак не настраиваем бесплатный KVM и продукты конкурентов. Берём их как есть. Если они не позаботились о том, чтобы дефолтная конфигурация их продукта обеспечивала максимальную производительность – это не наша вина, а их беда.
svaroq
04.06.2018 16:45Какие именно условия Вас интересуют? В пределах одного графика условия для всех испытуемых одинаковы: один и тот же стенд клиент-сервер, одна и та же конфигурация железа. Каждый продукт тестируется с дефолтными настройками, за исключением тех настроек, которые описаны в легенде к графику.
ildarz
04.06.2018 17:38Все условия. Если я оцениваю производительность, я хочу четко понимать, что и как протестировано, а паттерн нагрузки "нечто не пойми на чём при дефолтных настройках" не несет практического смысла. Нет описания даже настолько базовых вещей, как железо, конфиги VM и паттерны нагрузок, или какие конкретно патчи для meltdown/spectre ставились и куда.
Тестирование Hyper-V 2012 — тоже своеобразный подход. Хотел бы я посмотреть на вашу реакцию, увидь вы в блоге MS тестирование WS 1803 против ваших разработок 6-тилетней давности. ;)
Далее — vConsolidate. Тут занятно всё — и то, что разработка бенчмарка его авторами была свернута лет этак 8 назад, и то, что более-менее свежие ссылки из гугла относительно тестирований этим бенчмарком касаются исключительно openvz/virtuozzo.
Мы никак не настраиваем бесплатный KVM и продукты конкурентов.
И это еще один пример маркетинговой лапши. "Продукты конкурентов", очевидно, используются в крайне широком круге задач, и для оптимизации под разные задачи в разных средах нужны разные настройки. А дефолтная конфигурация там не столько про производительность, сколько про то, что оно должно для начала завестись на чём угодно из HCL, а потом его уже можно настраивать (это даже Hyper-V касается, хотя и в меньшей степени).
А конкретно про гипервизоры читать про дефолные настройки забавно еще и потому, что, скажем, дефолтная конфигурация VM там зависит даже не столько от самого гипервизора, сколько от системы управления. То есть диспетчер Hyper-V создаст виртуалку с одним конфигом, SCVMM с другим, Proxmox с третьим, RHEV с четвертым, и т.п. И как читатель должен угадывать, что вы на самом деле там тестируете?
svaroq
04.06.2018 21:56Нет описания даже настолько базовых вещей, как железо, конфиги 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.ildarz
05.06.2018 14:36эта информация доступна в Интернете. То же касается и патчей для Meltdown/Spectre. Достаточно загуглить
Ох. Вот понимаете, вроде бы вы делаете полезное дело — хотите обрисовать потенциальному потребителю преимущества вашего продукта. Но вместо того, чтобы просто прочитать статью и получить полезную информацию, я в итоге должен "загуглить" кучу всего — описания крайне малораспространенных и практически никем, кроме вас не используемых бенчмарков, попутно разбираясь с тем, насколько они вообще релевантны по отношению к текущему рынку ПО (и потом там что, бенчмарк вообще неконфигурирумый, паттерн наргрузки только один?); разбираться, какие версии ПО вы на самом деле используете (версию Hyper-V вы указали неверно, а как насчет остального?); должен каким-то образом понимать, какие конкретно патчи вы используете (ибо постоянно находятся новые варианты Spectre/Meltdown, для них выходят соответствующие патчи, старые патчи отзываются/перевыпускаются, патчи можно ставить только на хосты или внутри VM тоже, а был ли пропатчен микрокод процессора и чем, и т.д., и т.п.).
И при этом нет никакой гарантии, что, потратив кучу времени на выяснение всех этих деталей, я не найду ошибку в методике или не приду к выводу, что нагрузки в ваших тестах не имеют ничего общего с реальной жизнью (что вполне вероятно).
И, главное, штука в том, что у вас-то эта вся информация есть. Казалось бы, возьми да выложи, но в статье нет никаких подробностей.
Ведь согласитесь, если система управления создаёт VM c неоптимальной для производительности конфигурацией, то это – баг системы управления.
Не соглашусь. Во-первых, я уже писал, что дефолтные настройки могут быть рассчитаны на совместимость, а не на производительность. Во-вторых, система по умолчанию может попросту создавать VM, соответствующую минимальным системным требования для соответствующей ОС. Вполне очевидно, что к реальной эксплуатации это не будет иметь никакого отношения, и первое, что будет делать админ — менять конфиг (или настраивать собственные шаблоны для автоматизированного развертывания). Или другой факт — голая производительность не единственное, что интересует потребителя. Например, попутно может интересовать энергопотребление. И, в частности, при виртуализации на винде это весьма актуально — дефолтный профиль энергосбережения вовсе не max performance. Да и в целом люди, которым действительно нужна производительность, свои системы настраивают. Именно поэтому в общепринятных индустриальных тестах (SPEC, TPC и т.п.) не некие "дефолтные" конфиги используют, а каждый пытается выжать максимум из своей системы.
И, в любом случае, простое подробное описание тестируемых конфигураций сняло бы массу вопросов. Скорее всего, породило бы новые, но они, по крайне мере, были бы уже более по существу, а не просто в духе "Эмм… а что конкретно вы меряли-то?".
NorthDakota
04.06.2018 14:54Увидел ваши цены, пожалуй останусь на квм
ky0
04.06.2018 20:28Ага, тоже как-то рискнул запросить прайс. Поперхнулся кофе и радостно побежал за свежей версией Проксмокса.
boblenin
04.06.2018 17:29> В прошлом Virtuozzo работала со своим собственным, проприетарным гипервизором, но
> несколько лет назад мы поняли, что развивать его дороже и сложнее, чем оптимизировать
> достаточно удачный и эффективный KVM.
Разумно, конечно, но жаль. Virtuozzo была довольно-таки уникальной. И vzfs и то, как процессор разделялся, память.svaroq
04.06.2018 22:43Если Вы имеете в виду контейнерную виртуализацию, то в Virtuozzo 7 эта уникальность никуда не исчезла. В приведённой Вами цитате речь идёт о гипервизоре – мониторе виртуальных машин.
larrabee
04.06.2018 20:10Вы пишите о своих наработках на базе KVM. Отправляете ли вы эти патчи в апстрим и принимают ли их? Можно ли где то у вас на сайте их получить/скачать и нужно ли для этого быть вашим клиентом?
И QEMU и ядро Linux, частью которого является KVM, публикуются под GPLv2, соответственно исходники должны быть;).DenisLunev
05.06.2018 13:18Ну, это, казалось бы легко проверить в соответствующем репозитории. На самом деле, изменения достаточно активно вливаются и в KVM, и в QEMU. В позапрошлом и поза-поза-прошлом годах, когда на KVM forume статистика подводилась, Virtuozzo присутствовало в Top10 контрибьюторах от компаний в QEMU & Libvirt. В 2017 году Паоло эту статистику не предоставил, так что тут сказать не могу. Но, по нашим ощущениям, хуже быть не должно.
В mainstream ядро вклад тоже есть и не малый. Объем измеряется сотнями патчей только за этот год.
Касательно GPLv2 — вам стоит прочитать ее внимательно. Согласно лицензионному соглашению исходные тексты обязаны быть предоставлены людям, получившим бинарники системы, тем или иным способом.larrabee
05.06.2018 15:35Приятно это слышать, правда круто)
Касательно GPLv2 — вам стоит прочитать ее внимательно. Согласно лицензионному соглашению исходные тексты обязаны быть предоставлены людям, получившим бинарники системы, тем или иным способом.
Да, я это знаю. Как раз про это была эта часть моего вопроса:
… нужно ли для этого быть вашим клиентом?
Многие просто выкладывают исходники в открытый доступ, но не будучи вашим клиентом я не могу требовать их у вас.
arheops
04.06.2018 20:49Основная проблема virtuozzo как по мне — практически полное отсутствие совместимости с предыдущими релизами.
С какого перепугу вы считаете, что пользоваетль выберет вашу систему виртуализации, если ему прийдется все равно заново учить все команды и настройки?
Ладно бы выигрыш в производительности или удобстве был подавляющий, но он реально мал.
«Стандартный KVM» это что-то типа «обычного порошка», да?svaroq
04.06.2018 22:31Позвольте развеять Ваши заблуждения насчёт отсутствия совместимости с предыдущими релизами.
Во-первых, любой контейнер и любую VM, созданные на любой предыдущей версии Virtuozzo, можно смигрировать на 7.0. При этом контейнеры мигрируют с точно такой же скоростью как при миграции между двумя нодами с одной версией. В некоторых случаях с совсем старыми версиями возможно потребуется двухступенчатая миграция на промежуточную версию. Что же касается виртуальных машин, то несмотря на отличие в гипервизоре Vz6, на Vz7 предусмотрен простой и понятный механизм миграции виртуальных машин с Vz6. Миграция происходит медленнее, чем в случае с контейнерами, из-за необходимости конвертации диска в QCOW2.
Во вторых, что касается команд, в Vz7 есть все те же утилиты для управления виртуальными машинами и контейнерами, что и в предыдущих версиях, c сохранением их полной функциональности. Что же касается настроек, то поменялась только та часть из них, которая требовала переезда с ядра 2.6 на 3.10.
Nidere
05.06.2018 00:11А расскажите, пожалуйста, где можно о гипервизорах почитать?
Я правильно понимаю, что с их помощью можно делать «тонкие клиенты» на одном физическом устройстве?
Могут ли они использовать gpu?
Меня интересует возможность купить один мощный ПК домой и использовать его параллельно вдвоём-втроём.
Реально ли это? В играх тоже?eugenex15
05.06.2018 09:52для игр и windows (в том числе 10) года 2..3 назад использовал АСТЕР www.ibik.ru/ru/one-computer-many-monitors
+ тема Multiseat:
habr.com/post/210668
habr.com/post/153911
en.m.wikipedia.org/wiki/Multiseat_configuration
www.userful.com/locked-down-public-computing
MrMaxG
Сравнение с ESXi не делалось намеренно?
Gummio_7 Автор
В каком-то смысле да, так как задача ставилась сравнить производительность с KVM, на базе которого был разработан гипервизор в VZ7.
MrMaxG
Однако же с MS Hyper-V сравнение есть. К чему такая хитрая избирательность? :)
svaroq
VMware запрещает публикацию каких-либо сравнений своих продуктов с конкурентами без их согласия.