Тестирование производительности нескольких типов накопителей в виртуальной среде
Технологии виртуализации сегодня востребованы не только в сегменте «большого бизнеса», но и в 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 ТБ. Применение одиночных жестких дисков, особенно если нет требований к объему, в описываемом сценарии недорогой виртуализации для небольшой нагрузки можно считать типичным вариантом если совсем экономить или «лепить из того, что было» и не включить этот вариант в рассмотрение было бы неправильным.
На чтении все варианты, кроме последнего, показывают примерно одинаковые результаты на уровне 190 МБ/с (только при большой нагрузке с iodepth=256 у passthrough и LVM результаты снижаются до 150 МБ/с). Тогда как raw, благодаря кэшированию на хосте, «улетает в космос» и на его фоне остальных уже не видно. С одной стороны, можно сказать, что используемый тест и настройки системы не позволяют корректно оценить скорость данной конфигурации и показывают производительность не диска, а оперативной памяти. С другой стороны, кэширование является одной из наиболее эффективных и распространенных технологий увеличения производительности и если она работает, было бы странно от нее отказываться. Но не забываем про надежное питание в подобных конфигурациях.
На записи такого эффекта уже нет, так что на последовательных операциях все конфигурации примерно одинаковы — максимальная скорость около 190 МБ/с. Хотя raw все-таки ведет себя иначе, чем другие — при небольшой нагрузке он медленнее, но при максимальной не снижает скорость, как остальные. По задержкам отличий нет.
Использование кэша хост-системы хорошо заметно и на операциях случайного чтения — здесь raw стабильно самый быстрый и показывает до 950 IOPS. Примерно в два раза медленнее lvm — до 450 IOPS. Ну, а сам жесткий диск, в том числе и при «пробросе» в гостевую систему, показывает около 200 IOPS. Распределение участников на графике задержек согласуется со скоростями.
На операциях случайной записи лучше всех показала себя конфигурация с lvm, обеспечившая до 400 IOPS. За ней идет raw (~330 IOPS), а замыкают список последние два участника с 290 IOPS. По задержкам заметных отличий нет.
В общем случае, если вам не требуются функции, обеспечиваемые lvm, и ключевым критерием не является скорость случайной записи, при размещении виртуальных дисков на локальном хранилище с точки зрения скорости лучше использовать raw. Применение технологии проброса физического диска в виртуальную машину не дает преимуществ по производительности в данном случае. Но она может быть интересна, если требуется подключить в виртуалку накопитель с существующими данными.
Второй участник теста — SSD Samsung 850 EVO. Учитывая его возраст и работу в системе без TRIM, в некоторых тестах (в частности последовательной записи) он уже проигрывает винчестеру. Тем не менее, благодаря существенному выигрышу в производительности на случайных операциях перед традиционным жестким диском, он очень даже интересен и для виртуальных машин.
Результат последовательного чтения в режиме raw можно прокомментировать аналогично варианту с жестким диском. Но здесь более интересно то, что первые две конфигурации показывают стабильные 370 МБ/с при большой нагрузке, тогда как lvm способен только на 190 МБ/с. Задержки для этого режима тоже более высокие.
На операциях записи, как уже было сказано, данный твердотельный накопитель в своем текущем состоянии выглядит не очень интересно и показывает скорость на уровне 100 МБ/с. Что касается сравнения конфигураций, то в этом тесте raw проигрывает при невысокой нагрузке как по скорости, так и по задержкам.
Случайные операции являются основным «козырем» SSD. Здесь мы видим, что любые «виртуальные» варианты заметно проигрывают «чистому» накопителю — они обеспечивают только 30 000 IOPS, тогда как сам SSD способен работать в три раза быстрее. Судя по всему, здесь ограничением выступает уже программно-аппаратная платформа. Тем не менее, задержки в этом тесте не превышают 7 мс, так что маловероятно, что эту разницу в IOPS можно будет заметить приложениях общего характера.
А на случайной записи уже другая расстановка сил. «Реальный» диск здесь уже проигрывает, хотя и незначительно. Он способен показать до 4 200 IOPS. lvm и passthrough на одну-две сотни больше, а raw уже добирается до 5 500 IOPS. На графике задержек из интересного явно видео перелом на iodepth=32.
Тестирование показало, что SSD ведет себя в данном сценарии отличным от HDD образом. Во-первых, последовательное чтение с lvm заметно отстает от других вариантов. Во-вторых, виртуальные диски на SSD заметно теряют в IOPS на случайном чтении.
Третий участник несколько выбивается из «недорого», однако этот продукт сам по себе очень интересен и для универсального «ускорителя» дисковых операций и способен конкурировать по скорости не только с одиночными накопителями, но и RAID-массивами. Речь пойдет о Intel Optane. В данном случае использовалась модель 900P для шины PCIe 3.0×4, объемом 280 ГБ.
Intel Optane уже способен посоревноваться с оперативной памятью в этом тесте. Разница уже не на порядок, как у других участников, а всего в два-три раза. При этом при росте нагрузки значения практически сравниваются. Задержки как в тестах выше ниже у конфигурации raw.
В операциях последовательной записи «чистый» накопитель даже проигрывает другим участникам — с ростом нагрузки они выходят на стабильные 2 150 МБ/с, а он снижает скорость примерно до 1 700 МБ/с. Задержки в данном случае можно не сравнивать.
Операции случайного чтения у данной модели твердотельного накопителя при доступе к нему с хоста способны обеспечить почти 200 000 IOPS (скорость при этом будет на уровне 760 МБ/с). А вот все остальные схемы подключения, как мы видели выше для SSD с интерфейсом SATA, ограничиваются на уровне 35 000 IOPS, что не может не огорчать. Соответственно выше у них и задержки, примерно в пять раз.
На случайной записи эта без сомнения уникальная модель накопителя показывает практически такие же результаты, как и на случайном чтении — около 190 000 IOPS для прямого подключения и 35 000 IOPS для остальных вариантов. Задержки тоже совпадают с графиком на операциях чтения. С другой стороны, более 700 МБ/с в случайной записи небольшими блоками — таких результатов надо еще поискать.
Применение накопителя Intel Optane для исследуемой задачи показывает, что существенного снижения скорости на последовательных операциях в гостевых операционных системах для него не будет. А вот если вам требуются высокие IOPS на случайном чтении или записи, то данная платформа будет ограничивать производительность на уровне 35 000 IOPS, хотя сам накопитель в пять раз быстрее.
Тестирование показало, что при построении систем хранения для виртуальных серверов стоит обращать внимание на определенные потери от виртуализации, если для ваших виртуальных машин важна скорость. В большинстве проверенных конфигураций виртуальные диски показывают значительно отличающиеся от физических устройств показатели скорости. При этом для традиционных жестких дисков разница обычно относительно невелика, поскольку они сами по себе не такие уж и быстрые. Для твердотельных накопителей с интерфейсом SATA можно отметить существенные потери в IOPS при случайном доступе, но даже с учетом этого, они остаются кардинально более быстрыми в этих задачах, чем винчестеры. Накопитель Intel Optane конечно очень много потерял в виртуальной среде на случайных операциях, но даже в этом случае продолжает оставаться феноменально быстрым на записи. Да и на последовательных операциях к нему нет замечаний. Еще одним существенным плюсом данного устройства является стабильная производительность — ему не требуются никакие специальные операции очистки, так что независимо от состояния и прошлой истории, а также ОС и ее настроек, в любое время скорость будет постоянна. Но, как обычно, бесплатно ничего не бывает. Intel Optane 900P является не только уникально быстрым, но уникально дорогим.
