KVM + disk IO ( Тесты производительности дисковой подсистемы KVM. )

OS: Debian Linux Squeeze 6.0.4 (amd64).
Application: KVM 0.12.5 (Kernel-based Virtual Machine).

Задача: выбор типа виртуального диска KVM и параметров конфигурации, создающих наименьшее сопротивление трафику ввода/вывода.

Методика:


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

Варианты тестов:



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



Видно, что ядра процессора готовы переключатся между частотой в 1.20 GHz и 2.70 GHz, шагами по 2.7 GHz, 1.8 GHz и 1.2 GHz. По умолчанию выбрана схема "подачи частоты" по необходимости, что меня не устраивает. Профиль "cpufreq" в Debian Squeeze меняется прямо в скрипте инициализации:




Заранее, не тратя время на автоматизацию процесса, вручную создаём тестовый виртуальный сетевой интерфейс и подключаем его к виртуальному системному "мосту" (можно этого и не делать, обходясь поддержкой встроенного в KVM NAT, но мне хотелось простого прямого доступа к тестируемым машинам):


Теперь пишем скрипт, с помощью которого будем формировать строку запуска виртуальной машины:



Вначале мы запускаем скрипт для установки системы в виртуальную машину, применяя к переменной "BOOTORDER" значение "d", потом запускаем уже установленную систему со значением переменной - "c".

В моём случае дисковый контроллер "virtio" нестабильно себя вёл, запросто мог "увидеть" диск при одном запуске и "не увидеть" его-же при следующем. Пришлось от него отказаться в пользу привычного IDE, в конце-концов тесты на сравнительные, а не абсолютные показатели.

В соответствии с планом пришлось несколько раз устанавливать тестовые операционные системы на вновь создаваемые виртуальные диски. Сценарий установки был неизменен и таков:


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



Непосредственно перед каждым запуском теста в тестовой виртуальной машине операционной системе носителя отдавалось указание принудительно записать содержимое "кеша" дисковой подсистемы на физические носители с помощью соответствующей команды:


Так-же, после каждого теста на упаковку и распаковку массы файлов вручную запускались, последовательно, тесты на скорость записи/чтения в файловую систему с помощью утилит dd и hdparm, что давало возможность подтвердить тренды основных тестов с помощью утилиты "tar":

Вначале в обычном режиме:


Потом, по возможности минуя дисковые "кеши", с использованием "прямого доступа":


Напоследок - тест чтения:


Далее - более детально о подготовке виртуальных дисков.

В первой серии тестов использовался раздел диска (он-же - LVM-раздел). С этим всё просто - указываем KVM на него, как на виртуальный диск, не настраивая ничего.

Все дальнейшие тесты проводились на файловой системе XFS (Silicon Graphics FS), под которую был отформатирован тот-же раздел. Почему XFS? А вот нравится она мне.

Перед форматированием зачищалась начальная область используемого блочного устройства, чтобы затереть всё, что может быть воспринято как "мета"-данные, на всякий случай:


Создаем файловую систему XFS:


Где:


Файловая система монтировалась следующим образом, вручную:


Пару раз, в качестве развлечения, файловая система монтировалась в режиме "синхронной" записи:


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

По подготовке файлов дисков виртуальных машин - далее.

Если обеспечение компактности виртуального диска стоит прежде обеспечения максимальной производительности дисковой подсистемы, то RAW-диск можно создать с помощью утилиты "kvm-img":


Следует иметь в виду, что для реальной производственной эксплуатации RAW-диск лучше создавать не с помощью утилиты "kvm-img", которая лишь расставляет точки "мета"-данных, а заполнить всё выделенное для файла виртуального диска пространство "нулями" с помощью утилиты "dd", заранее подготавливая всё виртуальное дисковое пространство к немедленному использованию:


Это долго, да, но оно того стоит (заранее полностью подготовленный утилитой "dd" диск демонстрирует скорость доступа на 10-15% большую, нежели для диска, лишь размеченного для последующего заполнения данными утилитой "kvm-img"):


Подход при подготовке виртуального диска формата QCOW2 (QEMU Copy-On-Write), предлагаемого разработчиками KVM, схож с методом подготовки RAW-дисков. Можно создать диск путём объявления наличия файла объёма, ограниченного определённым значением, начальный (для стороннего наблюдателя) размер которого будет минимален (режим по умолчанию):


Виртуальный диск при этом создаётся за доли секунды, размер исходного файла крошечный, около 200KB.

Лучше создавать виртуальный диск QCOW2 с разметкой его "мета"-данными (размеченный "мета"-данными диск демонстрирует скорость доступа на 5-7% большую, нежели диск, не размеченный таким образом):


Файл при этом создаётся соответствующего размера, в нашем случае - 100 Гигабайт.

На этом об обстоятельствах - всё.

Работа проводилась с полным соблюдением заявленных выше условий; ушло на это почти три рабочих дня. Каждый тест прогонялся по два раза, после выводилось среднее арифметическое. Все результаты подтверждались контрольными тестами с помощью утилит "dd" и "hdparm". Была мысль выложить "полотенце" таблицы с результатами, но решил ограничится графиками вариантов конфигурации, позволяющих достигнуть максимальной производительности дисковой подсистемы.

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


Видно, что пиковая производительность достигается с использованием "кеша" типа "writethrough" (что предусмотрено по умолчанию). Я бы рекомендовал отключать виртуальный "кеш" вообще - стабильнее показатели скорости записи и чтения.

Вариант второй, с использованием RAW-файла, размещённого на файловой системе XFS:


Видно, что пиковая производительность достигается с использованием "кеша" типа "writeback" ("кеш" файловой системы помогает). Забавно, но использование "кеша" типа "writethrough" (включаемого по умолчанию) демонстрирует просто провальные показатели скорости дисковой подсистемы (привет всем, кто пробовал KVM и разочаровался в нём по причине крайне медленной работы). Если физический дисковый контроллер достаточно серьёзный, с кешем на аккумуляторах, то из RAW-файла можно выжимать максимум, используя виртуальное "кеширование" с алгоритмом "writeback"; в противном случае рекомендую отключить вообще виртуальный "кеш", для пущей сохранности данных (вдруг системный блок отключится более неожиданно, чем обычно).

Вариант третий, с использованием QCOW2-файла, размещённого на файловой системе XFS:


Видно, что картина в общем повторяет вариант с XFS+RAW, только показатели ниже на 20-25%. Ну, что-же - формат удобный более для лабораторных условий, когда виртуальными машинами нужно постоянно вертеть-крутить, нежели для эксплуатации в производственных условиях, требующих максимальной отдачи в неизменном окружении.

Естественно, что усреднённая скорость обработки массива файлов разного размера существенно ниже пиковых возможностей потоковой записи виртуального или физического дискового устройства. В частности, максимальные достигнутые усреднённые значения скорости записи утилитой "tar" на виртуальный диск не превысили 30 (тридцати) Мегабайт в секунду, в то время как утилита "dd" демонстрировала скорость небуферизированой записи в 78 (семьдесят восемь) Мегабайт в секунду.