Несколько слов о реальной производительности гипервизора

    Пользователи виртуализированных систем, а особенно – сервис-провайдеры, очень часто задаются вопросом: «как выжать максимум из имеющегося железа?». И в этом контексте нам нередко приходится обсуждать гипервизор 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 (виртуальные машины)

    image В отличие от 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.

    Кстати, в следующем посте мы расскажем об эволюции нашего распределенного хранилища и о его реальных возможностях для работы с ВМ и контейнерами.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Какие параметры гипервизора вы считаете более важными?

    Virtuozzo
    37,00
    Разработчик ПО для контейнерной виртуализации
    Поделиться публикацией

    Комментарии 27

      0

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

        0

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

      0

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

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

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


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


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


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

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


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

              0
              Нет описания даже настолько базовых вещей, как железо, конфиги 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.
                0
                эта информация доступна в Интернете. То же касается и патчей для Meltdown/Spectre. Достаточно загуглить

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


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


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


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

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


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

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

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

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

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

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

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

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

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

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое