Наши клиенты часто задают вопросы о том, какое из поддерживаемых в VMmanager типов хранилищ данных самое лучшее, самое быстрое, и какое выбрать в их случае. К сожалению, ответить на этот вопрос просто так не получится.
Поэтому мы решили провести тестирование производительности хранилищ данных.
Компания ISPsystem еще в начале марта 2013 анонсировала выход нового программного продукта для управления виртуализацией — VMmanager. Решение адаптировано как для хостинга виртуальных машин, так и для построения облака.
VMmanager поддерживает несколько типов хранилищ данных. Под термином “хранилище данных” подразумевается описание способа хранения виртуальных дисков. Эти типы разделяются на сетевые и локальные. К сетевым относятся: iSCSI, NFS и RBD. К локальным — LVM и DIR (файловая система).
Каждое из представленных имеет свои недостатки и преимущества. К примеру, при использовании сетевых хранилищ данных, когда встает вопрос миграции виртуальной машины, нет необходимости переносить образ на другой узел кластера.
Как наиболее доступные и распространенные, мы решили взять локальные хранилища данных LVM, DIR (с форматом RAW и форматом Qcow2) чтобы ответить на вопрос: какое из локальных хранилищ наиболее быстрое при чтении или записи.
Для справки:
Для тестирования был выбран сервер такой конфигурации:
Само тестирование проводилось с помощью приложения fio, которое было описано в статье хабровчанина amaramo — “Как правильно мерять производительность диска”. Утилита доступна на официальном сайте в виде исходных кодов.
Мы воспользовались репозитарием EPEL для установки в Centos:
Проводилось отдельное тестирование как чтения, так и записи. В качестве ключевого значение было выбрано количество IOPS.
Параметры fio были следующие:
Тестирование чтения:
[readtest]
blocksize=128k
filename=/dev/vdb
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=16
Тестирование записи:
[writetest]
blocksize=128k
size=100%
filename=/dev/vdb
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=16
Каждый тест запускался по три раза. Перед каждым запуском диск заполнялся “нулями” с помощью приложения dd:
и сбрасывался дисковый кэш операционной системы:
Так как тестирование производилось на том же физическом массиве, где установлена операционная система, то системные приложения могли влиять на полученные значения. Поэтому в качестве результирующего значение бралось медиана. Так как при некоторых запусках значение отличалось на порядок.
Для тестирования создавался виртуальный диск размером 50000 МБ. Размер взят не случайно. Как наиболее ходовой размер диска для виртуальных серверов. Все диски к виртуальным машинами подключались с использование драйвера virtio. Паравиртуальные драйвера (virtio) используются при работе с основными устройствами в виртуальном окружении. Использование этих драйверов в общем случае повышает производительность виртуальной дисковой подсистемы. Эти драйвера присутствуют в ядре Linux начиная с 2.6.25 версии.
При первом способе тестирования использовался sda4 (на котором позже и создавался как LVM, так и диски для виртуальных машин) с добавлением в параметрах fio — size=50G.
Для тестирования при втором способе создавалась LVM группа томов, и в этой группе LVM раздел размером 500000 МБ, как для виртуальной машины.
При тестировании хранилища DIR c форматами RAW и Qcow2 сами образы дисков располагались в виде файлов в файловой системе ext4 в директории /vm.
В пятом способе тестирования делался один проход и заполнение диска “нулями” не проводилось. Так как интересовала производительность как раз сразу после создания снимка файловой системы.
Таблица результатов
Исходя из данных таблицы, можно придти к следующим выводам.
Поэтому мы решили провести тестирование производительности хранилищ данных.
Компания ISPsystem еще в начале марта 2013 анонсировала выход нового программного продукта для управления виртуализацией — VMmanager. Решение адаптировано как для хостинга виртуальных машин, так и для построения облака.
VMmanager поддерживает несколько типов хранилищ данных. Под термином “хранилище данных” подразумевается описание способа хранения виртуальных дисков. Эти типы разделяются на сетевые и локальные. К сетевым относятся: iSCSI, NFS и RBD. К локальным — LVM и DIR (файловая система).
- iSCSI — протокол управления удалёнными хранилищами, позволяющий пересылать данные на большие расстояния, используя отправку команд SCSI по IP-сети.
- NFS — сетевое хранилище. Оно гораздо медленнее чем локальное, его рекомендуется использовать только для размещения дополнительных виртуальных дисков.
- RDB — известна так же как Ceph RADOS block device. Это распределенная файловая система. На Хабре проходила статья-руководство по установке Ceph FS с краткой справкой от пользователя ilaskov.
- LVM — является наилучшим решением для использования в качестве основного локального хранилища.
- Файловая система — в качестве хранилища будет использована файловая система сервера. Образы виртуальных дисков хранятся в виде RAW-файлов.
Каждое из представленных имеет свои недостатки и преимущества. К примеру, при использовании сетевых хранилищ данных, когда встает вопрос миграции виртуальной машины, нет необходимости переносить образ на другой узел кластера.
Как наиболее доступные и распространенные, мы решили взять локальные хранилища данных LVM, DIR (с форматом RAW и форматом Qcow2) чтобы ответить на вопрос: какое из локальных хранилищ наиболее быстрое при чтении или записи.
Для справки:
- RAW — это полный образ блочного устройства без какого-либо внутреннего формата.
- Qcow2 — это формат образа диска QEMU. Это аббревиатура формата Copy-On-Write (копирование в процессе записи).
Для тестирования был выбран сервер такой конфигурации:
- CPU: Intel Core2Quad CPU Q6600
- RAM: 8ГБ
- HDD: RAID-10 Adaptec ASR3405 4x150ГБ SAS
- OS: Centos 6
Само тестирование проводилось с помощью приложения fio, которое было описано в статье хабровчанина amaramo — “Как правильно мерять производительность диска”. Утилита доступна на официальном сайте в виде исходных кодов.
Мы воспользовались репозитарием EPEL для установки в Centos:
- wget dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
- rpm -Uvh epel-release-6*.rpm
- yum --enable-repo=epel install fio
Проводилось отдельное тестирование как чтения, так и записи. В качестве ключевого значение было выбрано количество IOPS.
Параметры fio были следующие:
Тестирование чтения:
[readtest]
blocksize=128k
filename=/dev/vdb
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=16
Тестирование записи:
[writetest]
blocksize=128k
size=100%
filename=/dev/vdb
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=16
Каждый тест запускался по три раза. Перед каждым запуском диск заполнялся “нулями” с помощью приложения dd:
- dd if=/dev/zero of=/dev/vdb bs=4096 conv=noerror
и сбрасывался дисковый кэш операционной системы:
- echo 3 > /proc/sys/vm/drop_caches
Так как тестирование производилось на том же физическом массиве, где установлена операционная система, то системные приложения могли влиять на полученные значения. Поэтому в качестве результирующего значение бралось медиана. Так как при некоторых запусках значение отличалось на порядок.
Для тестирования создавался виртуальный диск размером 50000 МБ. Размер взят не случайно. Как наиболее ходовой размер диска для виртуальных серверов. Все диски к виртуальным машинами подключались с использование драйвера virtio. Паравиртуальные драйвера (virtio) используются при работе с основными устройствами в виртуальном окружении. Использование этих драйверов в общем случае повышает производительность виртуальной дисковой подсистемы. Эти драйвера присутствуют в ядре Linux начиная с 2.6.25 версии.
При первом способе тестирования использовался sda4 (на котором позже и создавался как LVM, так и диски для виртуальных машин) с добавлением в параметрах fio — size=50G.
Для тестирования при втором способе создавалась LVM группа томов, и в этой группе LVM раздел размером 500000 МБ, как для виртуальной машины.
При тестировании хранилища DIR c форматами RAW и Qcow2 сами образы дисков располагались в виде файлов в файловой системе ext4 в директории /vm.
В пятом способе тестирования делался один проход и заполнение диска “нулями” не проводилось. Так как интересовала производительность как раз сразу после создания снимка файловой системы.
Таблица результатов
| № | Тип хранилища | Результат теста на чтение, IOPS | Результат теста на запись, IOPS |
| 1 | Чтение/запись на физическом сервере | 843 | 331 |
| 2 | LVM-раздел на физическом сервере | 848 | 559 |
| 3 | Виртуальная машина на DIR (RAW) | 668 | 545 |
| 4 | Виртуальная машина на DIR (Qcow2) | 621 | 463 |
| 5 | Виртуальная машина на DIR (Qcow2) + snapshot | 615 | 56 |
| 6 | Виртуальная машина на LVM | 854 | 557 |
Исходя из данных таблицы, можно придти к следующим выводам.
- Наиболее быстрым является использование LVM-хранилища.
- Но при этом RAW-хранилище является наиболее простым для проведения над ним различных операций: изменение размера, изменение разметки диска, запуск на другой виртуализации без конвертации или конвертация в формат Qcow2.
- Плюсом Qcow2 является поддержка снимков файловой системы (снапшоты), но их использование очень сильно замедляет запись. Скорость записи снижается по причине того, что происходит ожидание завершения перезаписи всех блоков относительно снапшота.