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