Тестирование производительности нескольких типов накопителей в виртуальной среде

    Технологии виртуализации сегодня востребованы не только в сегменте «большого бизнеса», но и в SMB и у домашних пользователей. В частности для небольших компаний сервера виртуализации могут применяться для реализации некоторого числа не очень ресурсоемких служебных сервисов. При этом речь обычно идет об автономных серверах на базе одно- или двухпроцессорных платформ, с относительно небольшим объемом оперативной памяти в 32-64 ГБ и без специальных высокопроизводительных СХД. Но за всей чередой преимуществ нужно отдавать себе отчет, что с точки зрения производительности виртуальные системы отличаются от реальных. В этой статье будет проведено сравнение скорости локальных накопителей разных типов (HDD, SSD и NVMe) для нескольких конфигураций виртуальных машин с целью оценить потери от их виртуализации. Никто не спорит, что в «правильных» реализациях систем виртуализации лучше использовать внешнюю СХД, но в бюджетном варианте можно обойтись и локальными дисками.

    Тестирование проводилось на сервере следующей конфигурации: материнская плата Asus Z10PE-D16, два процессора Intel Xeon E5-2609 v3, 64 ГБ оперативной памяти. В качестве среды виртуализации был выбран Proxmox VE версии 5.2 – система с открытым исходным кодом на базе Debian. Для его установки использовался отдельный SATA SSD, а тестируемые накопители подключались отдельно на другие интерфейсы и порты.

    Cначала протестируем накопитель из хост-платформы. Второй вариант – проброс в виртуалку (для нее применяется KVM и Debian 9, выделено 2 ядра и 8 ГБ оперативной памяти) как физического диска. Третья конфигурация – виртуальный диск на LVM. Четвертая – RAW-файл на томе с файловой системой ext4. В последних двух вариантах был выбран размер диска в 64 ГБ. Так что дополнительным результатом статьи может быть сравнение LVM и RAW для хранения образов виртуальных дисков.

    Для измерения скорости будет использоваться утилита fio с шаблонами последовательного чтения и записи с блоком в 256 КБ и случайных операций с блоком в 4 КБ. Тесты проводились с параметром iodepth от 1 до 256 с целью эмуляции разной нагрузки. Для последовательных операций оцениваем скорость в МБ/с, для случайных – IOPS. Кроме того, смотрим и на средние задержки (clat из отчета теста).

    Начнем с традиционного жесткого диска, в роли которого выступил немолодой HGST HUH728080ALE640 – накопитель с интерфейсом SATA и объемом 2 ТБ. Применение одиночных жестких дисков, особенно если нет требований к объему, в описываемом сценарии недорогой виртуализации для небольшой нагрузки можно считать типичным вариантом если совсем экономить или «лепить из того, что было» и не включить этот вариант в рассмотрение было бы неправильным.

    image

    image

    На чтении все варианты, кроме последнего, показывают примерно одинаковые результаты на уровне 190 МБ/с (только при большой нагрузке с iodepth=256 у passthrough и LVM результаты снижаются до 150 МБ/с). Тогда как raw, благодаря кэшированию на хосте, «улетает в космос» и на его фоне остальных уже не видно. С одной стороны, можно сказать, что используемый тест и настройки системы не позволяют корректно оценить скорость данной конфигурации и показывают производительность не диска, а оперативной памяти. С другой стороны, кэширование является одной из наиболее эффективных и распространенных технологий увеличения производительности и если она работает, было бы странно от нее отказываться. Но не забываем про надежное питание в подобных конфигурациях.

    image

    image

    На записи такого эффекта уже нет, так что на последовательных операциях все конфигурации примерно одинаковы – максимальная скорость около 190 МБ/с. Хотя raw все-таки ведет себя иначе, чем другие – при небольшой нагрузке он медленнее, но при максимальной не снижает скорость, как остальные. По задержкам отличий нет.

    image

    image

    Использование кэша хост-системы хорошо заметно и на операциях случайного чтения – здесь raw стабильно самый быстрый и показывает до 950 IOPS. Примерно в два раза медленнее lvm – до 450 IOPS. Ну а сам жесткий диск, в том числе и при «пробросе» в гостевую систему, показывает около 200 IOPS. Распределение участников на графике задержек согласуется со скоростями.

    image

    image

    На операциях случайной записи лучше всех показала себя конфигурация с lvm, обеспечившая до 400 IOPS. За ней идет raw (~330 IOPS), а замыкают список последние два участника с 290 IOPS. По задержкам заметных отличий нет.

    В общем случае, если вам не требуются функции, обеспечиваемые lvm, и ключевым критерием не является скорость случайной записи, при размещении виртуальных дисков на локальном хранилище с точки зрения скорости лучше использовать raw. Применение технологии проброса физического диска в виртуальную машину не дает преимуществ по производительности в данном случае. Но она может быть интересна, если требуется подключить в виртуалку накопитель с существующими данными.

    Второй участник теста – SSD Samsung 850 EVO. Учитывая его возраст и работу в системе без TRIM, в некоторых тестах (в частности последовательной записи) он уже проигрывает винчестеру. Тем не менее, благодаря существенному выигрышу в производительности на случайных операциях перед традиционным жестким диском, он очень даже интересен и для виртуальных машин.

    image

    image

    Результат последовательного чтения в режиме raw можно прокомментировать аналогично варианту с жестким диском. Но здесь более интересно то, что первые две конфигурации показывают стабильные 370 МБ/с при большой нагрузке, тогда как lvm способен только на 190 МБ/с. Задержки для этого режима тоже более высокие.

    image

    image

    На операциях записи, как уже было сказано, данный твердотельный накопитель в своем текущем состоянии выглядит не очень интересно и показывает скорость на уровне 100 МБ/с. Что касается сравнения конфигураций, то в этом тесте raw проигрывает при невысокой нагрузке как по скорости, так и по задержкам.

    image

    image

    Случайные операции являются основным «козырем» SSD. Здесь мы видим, что любые «виртуальные» варианты заметно проигрывают «чистому» накопителю – они обеспечивают только 30 000 IOPS, тогда как сам SSD способен работать в три раза быстрее. Судя по всему, здесь ограничением выступает уже программно-аппаратная платформа. Тем не менее, задержки в этом тесте не превышают 7 мс, так что маловероятно, что эту разницу в IOPS можно будет заметить приложениях общего характера.

    image

    image

    А на случайной записи уже другая расстановка сил. «Реальный» диск здесь уже проигрывает, хотя и незначительно. Он способен показать до 4 200 IOPS. lvm и passthrough на одну-две сотни больше, а raw уже добирается до 5 500 IOPS. На графике задержек из интересного явно видео перелом на iodepth=32.

    Тестирование показало, что SSD ведет себя в данном сценарии отличным от HDD образом. Во-первых, последовательное чтение с lvm заметно отстает от других вариантов. Во-вторых, виртуальные диски на SSD заметно теряют в IOPS на случайном чтении.

    Третий участник несколько выбивается из «недорого», однако этот продукт сам по себе очень интересен и для универсального «ускорителя» дисковых операций и способен конкурировать по скорости не только с одиночными накопителями, но и RAID-массивами. Речь пойдет о Intel Optane. В данном случае использовалась модель 900P для шины PCIe 3.0 x4, объемом 280 ГБ.

    image

    image

    Intel Optane уже способен посоревноваться с оперативной памятью в этом тесте. Разница уже не на порядок, как у других участников, а всего в два-три раза. При этом при росте нагрузки значения практически сравниваются. Задержки как в тестах выше ниже у конфигурации raw.

    image

    image

    В операциях последовательной записи «чистый» накопитель даже проигрывает другим участникам – с ростом нагрузки они выходят на стабильные 2 150 МБ/с, а он снижает скорость примерно до 1 700 МБ/с. Задержки в данном случае можно не сравнивать.

    image

    image

    Операции случайного чтения у данной модели твердотельного накопителя при доступе к нему с хоста способны обеспечить почти 200 000 IOPS (скорость при этом будет на уровне 760 МБ/с). А вот все остальные схемы подключения, как мы видели выше для SSD с интерфейсом SATA, ограничиваются на уровне 35 000 IOPS, что не может не огорчать. Соответственно выше у них и задержки, примерно в пять раз.

    image

    image

    На случайной записи эта без сомнения уникальная модель накопителя показывает практически такие же результаты, как и на случайном чтении – около 190 000 IOPS для прямого подключения и 35 000 IOPS для остальных вариантов. Задержки тоже совпадают с графиком на операциях чтения. С другой стороны, более 700 МБ/с в случайной записи небольшими блоками – таких результатов надо еще поискать.

    Применение накопителя Intel Optane для исследуемой задачи показывает, что существенного снижения скорости на последовательных операциях в гостевых операционных системах для него не будет. А вот если вам требуются высокие IOPS на случайном чтении или записи, то данная платформа будет ограничивать производительность на уровне 35 000 IOPS, хотя сам накопитель в пять раз быстрее.

    Тестирование показало, что при построении систем хранения для виртуальных серверов стоит обращать внимание на определенные потери от виртуализации, если для ваших виртуальных машин важна скорость. В большинстве проверенных конфигураций виртуальные диски показывают значительно отличающиеся от физических устройств показатели скорости. При этом для традиционных жестких дисков разница обычно относительно невелика, поскольку они сами по себе не такие уж и быстрые. Для твердотельных накопителей с интерфейсом SATA можно отметить существенные потери в IOPS при случайном доступе, но даже с учетом этого, они остаются кардинально более быстрыми в этих задачах, чем винчестеры. Накопитель Intel Optane конечно очень много потерял в виртуальной среде на случайных операциях, но даже в этом случае продолжает оставаться феноменально быстрым на записи. Да и на последовательных операциях к нему нет замечаний. Еще одним существенным плюсом данного устройства является стабильная производительность – ему не требуются никакие специальные операции очистки, так что независимо от состояния и прошлой истории, а также ОС и ее настроек, в любое время скорость будет постоянна. Но, как обычно, бесплатно ничего не бывает. Intel Optane 900P является не только уникально быстрым, но уникально дорогим.
    Поделиться публикацией
    Комментарии 18
      0
      С одной стороны, можно сказать, что используемый тест и настройки системы не позволяют корректно оценить скорость данной конфигурации и показывают производительность не диска, а оперативной памяти.

      Вы хотя бы написали, какие настройки у вас для диска стоят, какой контроллер virtio, scsi, sata и какой режим кэширования. От этого значения могут отличаться на порядки.
      Если делать тесты в плане замера потерь от железа, то надо ставить directsync, если же нужна максимальная производительность с допустимыми потерями, то включается writeback.
        0
        Использовался режим Virtio с no cache.
          0

          А кто нибудь использует virtio в работе? У меня более менее стабильно работает только virtio scsi. Правда proxmox не использую.

            0
            Давно используем в проксмокс, проблем нет.
            Простой виртио не рекомендуется, VirtIO block may get deprecated in the future.
            Во времена 2003 винды были проблемы с определенными версиями, примерно как у старого линукса, нечетные версии нестабильны, четные стабильны.
        0
        Применение одиночных жестких дисков, особенно если нет требований к объему, в описываемом сценарии недорогой виртуализации для небольшой нагрузки можно считать типичным вариантом если совсем экономить или «лепить из того, что было» и не включить этот вариант в рассмотрение было бы неправильным.

        За такие «типичные» варианты я бы ноги сразу отрывал всем, кто их упоминает.

        Про показатели разных типов дисков написано тут вагон и маленькая тележка, при чём уже довольно давно, но с тех пор ничего не изменилось.

        На каком объёме данных проходили тесты то? Диски предварительно заполнялись или нет? Какое время тестирования для флеша?

        Ясное дело, что виртуализация вносит свои коррективы, но имхо Proxmox VE — далеко не показатель. ВОзьмите ради интереса хайпер-в или вмваре
          0
          Про показатели разных типов дисков написано тут вагон и маленькая тележка, при чём уже довольно давно, но с тех пор ничего не изменилось.

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

          На каком объёме данных проходили тесты то? Диски предварительно заполнялись или нет? Какое время тестирования для флеша?

          Тесты проводились на блочных устройствах без ограничения объема. В случае виртуальных дисков на lvm и в формате raw диски имели объем 64 ГБ, как и указано в тексте. Диски предварительно не заполнялись. Время тестирования для каждого шаблона — пять минут.

          ВОзьмите ради интереса хайпер-в или вмваре

          Мне был интересен Proxmox. В принципе, можно попробовать повторить на vmware.

          0
          Спасибо за тесты, однако есть несколько вопросов по ним:

          • Сколько времени проводились тесты?
          • Какой scheduler у дисков/ssd использовали?
          • Почему для последовательной записи использовали именно 256К блоки?

          P.s. Обычно используют опции sync, direct чтобы не мерить кэш.

          P.P.s. Тесты проводились в один поток, а это обычно не свойственно виртуализации. Было бы интереснее увидеть (iops\BW\lat) / threads.
            0
            Сколько времени проводились тесты?

            Один шаблон — пять минут.

            Какой scheduler у дисков/ssd использовали?

            Это отдельная история. Добавлять еще один параметр в эту статью не стал. Иначе бы история существенно занянулась. Так что все «из коробки».

            Почему для последовательной записи использовали именно 256К блоки?

            Так исторически сложилось. Не стояло задачи «выжать все», а так конечно можно было бы еще много разных параметров накрутить. Обычно можно использовать «блок достаточно большого размера». Так что увеличение, скажем до 512 КБ или 1024 КБ, мало что изменит.

            P.s. Обычно используют опции sync, direct чтобы не мерить кэш.

            Для самого fio конечно direct=1. Но все-таки «что б не мерить кэш» — это неоднозначный вопрос.

            P.P.s. Тесты проводились в один поток, а это обычно не свойственно виртуализации. Было бы интереснее увидеть (iops\BW\lat) / threads.

            Тесты проводились с изменением параметра iodepth от 1 до 256. Возможно стоило еще обратить внимание на numjobs. Надо будет попробовать и сравнить результаты.
              0

              Если Proxmox "из коробки", то у него scheduler по-умолчанию — deadline.

                0
                Читал несколько статей о выборе scheduler для «не жестких дисков». Результаты тестов, на мой взгляд, неоднозначные. Для конкретной задачи (например, базы данных) можно подобрать оптимальный, если сначала определиться с критериями. Для синтетических тестов это менее интересно/полезно.
                А NVMe — это уже другая история и там обычные scheduler не используются.
            0
            Интересно было бы увидеть qcow2 под нагрузкой.
            Все-таки это формат по-умолчанию в том же прокмоксе
            На реддите проскакивало, что raw и qcow2 ноздря в ноздрю идут на тестах, а zvol никак не определится с позицией
            Еще в qcow2 можно тюнинговать как минимум: L2 кеширование, preallocation, ну и lazy_refcounts (но по нему никакой информации кроме devel-переписки не нашел)
            Лично я пока все эти настройки не крутил — хватает дефолтных с SSD дисками
              0
              Вопрос стоял не в «получить максимальные результаты на данном железе настройкой ПО и выбором опций/параметров/режимов». Хотя конечно решение этой задачи очень даже интересно и полезно на практике.
              0

              Вы осуществляя последовательное чтение одного 2ТБ жеского диска получили скорость в тысячи МБ/с? Вы издеваетесь что ли?! =)


              Простите ради бога, но выглядит что вы что-то не то делали и получили какие-то подозрительные результаты.

                0
                Могу только предложить еще раз прочитать текст, а не только посмотреть на картинки.
                0
                Когда я читаю обзоры дисков и вижу что-то очередь 256, то у меня всегда вопрос: а какие выводы можно делать из показателей очереди 8 и больше? Ну то есть если очередь 8, то всё, не имеет смысла дальше смотреть, диск уже захлебнулся. Дальше уже только вопрос, как быстро он всплывет.
                Всё бы ничего, но из-за этого диапазона приходится использовать логарифмические шкалы и самое интересная часть графика (очереди 1 и 2) сравнить уже сложно. На графике задержек 1 и 1,5 мс почти в одной точке, а реально это разница в полтора раза.
                  0
                  «Диск» — именно жесткий диск или накопитель в общем смысле этого слова? Причин попробовать 256 несколько — на реальной нагрузке (файловый сервер) видел 150 и более, некоторые конфигурации и на этом значении не упираются в свой предел, часто интересно смотреть до какого значения можно увеличивать очередь с сохранением задержек ниже заданных.

                  Да, формально 1 и 1,5 — разница в полтора раза. Но найти приложение, которое это заметит, непросто.
                    0
                    150 на протяжении секунд/минут или на протяжении часов/суток? Если первое, то, да ну бывает по каким-то причинам. Например, СУБД пошла read-ahead делать или что-то подобное — на этом очередь может прыгать и до 300 и до 500 и до 1000. Сервер знает, то читать и поставил в очередь. Я больше с СУБД сталкиваюсь, поэтому мне эта ситуация знакома и обычна. Для OLTP такой всплеск в целом неприятен, но если это не авария, то он «рассасывается».
                    Но тут такой момент, что с точки зрения разгребания между очередью 16 и очередью 256 разницы почти нет. У вас это тоже в графиках видно: посмотрите, latency просто линейно растет (там обе шкалы логарифмические, поэтому в итоге всё равно линейно). Как в супермаркете: если очередь 5 человек, то ждать 10 минут, если очередь 10 человек, то 20. Наверное есть какая-то оптимизация, объединение смежных чтений, перестановки и т.п., но в реальности картина простая: есть большая очереди и её не волшебное разгребание. Этот диапазон линеен, его не интересно смотреть.

                    Но найти приложение, которое это заметит, непросто

                    Любое критичное к дисковой производительности приложение. СУБД, например.

                      0
                      Если смотреть только на «задержки-очередь», то конечно почти везде все линейно. Но на «скорость-очередь» разница между 16 и 256 обычно заметна. Можно было бы ограничиться скажем 128, но все-таки удобнее иметь дополнительные точки для более четкого понимания, что «полка» точно наступила.

                      В описанной задаче речь не идет про СУБД. Хотя конечно Intel Optane с базами данных смотрелся бы скорее всего отлично.

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

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