Главная Virtualization, Новое Эксперимент: Виртуализация и виртуальные жесткие диски
  • Эксперимент: Виртуализация и виртуальные жесткие диски

    Безымянный  Довольно часто, в системе «слабым местом» оказывается дисковая подсистема, что вполне понятно: ведь быстродействие жесткого диска всегда намного меньше, чем оперативной памяти или процессора. При виртуализации же, когда несколько виртуальных машин используют один и тот же жесткий диск (или массив) — вопрос быстродействия встает особенно остро.

    Заметнее всего падение быстродействия — при виртуализации серверов, очень активно обращающихся к жестким дискам: например — серверов баз данных, почтовых серверов. Здесь уже приходится идти на хитрости ради того, чтобы выиграть пару-тройку лишних IOps'ов.

    Рассмотрим работу с жесткими дисками в среде Hyper-V.

    1. VHD-файлы

    Наиболее известный способ, выбираемый по дефолту: использование в качестве дисков для виртуальной машины — файлов *.vhd (Virtual Hard Disk). Этот способ имеет три преимущества:

    • VHD-файлы могут храниться где угодно и могут быть легко перемещены;
    • Удобство создания резервных копий: копирование одного большого файла — намного легче и быстрее, чем копирование всего содержимого жесткого диска (VHD-файл может быть легко скопирован средствами VSS, без остановки самой виртуальной машины, а в случае бэкапа содержимого физического диска — может потребоваться перезагрузка как минимум гостевой ОС);
    • Рациональное использование дискового пространства: на одном физическом диске может храниться множество VHD-файлов, и каждой виртуальной машине можно отвести ровно столько дискового пространства, сколько ей необходимо

    Минус — один: меньшее быстродействие по сравнению с прямой работой с диском. Далее будет показано наглядно.

    2. Прямое обращение к физическому диску

    Hyper-V, помимо использования VHD-файлов — предоставляет возможность использования виртуальной машиной физических дисков. Плюс тут один: более высокое быстродействие в сравнении с VHD-файлами. Минусов же больше:

    • Немного сложнее создавать резервные копии и переносить информацию в другое место;
    • Менее рациональное использование дискового пространства (весь объем диска используется одной виртуальной машиной, не может регулироваться динамически и распределяться между несколькими виртуалками);

    Ну а теперь — перейдем от теории к практике.

    Эксперимент.

    В качестве экспериментального стенда использовался сервер HP ML150G5, снабженный четырёхъядерным процессором Intel® Xeon® E5420 2,5 ГГц и 4Гб оперативной памяти. Дисковая подсистема представлена двумя дисками объемом 72Гб с интерфейсом SAS, объединенными в массив RAID1 и двумя SATA-дисками объемом 250Гб, так же объединенными в RAID1. На сервере установлена ОС Microsoft Windows Server 2008 Std. 64bit с поддержкой Hyper-V. Других задач, помимо виртуализации у него нет. Далее — все эксперименты, о которых я буду писать в этом блоге — будут проводиться именно на этом сервере.

    Для чистоты эксперимента все действующие ВМ были остановлены, и создана новая ВМ с 512Мб ОЗУ и двумя жесткими дисками: один — для установки гостевой ОС, другой — для эксперимена. На ВМ была установлена ОС Microsoft Windows Server 2003 32bit, были установлены компоненты интеграции. Для создания нагрузки на диски и измерения параметров быстродействия была использована бесплатная утилита IOMeter. Параметры доступа к диску в IOMeter были заданы следующие:

    • Объем страницы: 64Кб;
    • 75% — случайный доступ, 25% — линейный;
    • 75% — чтение, 25% — запись.

    Опыт первый: VHD-файл.

    Как я уже писал выше, экспериментальная ВМ имеет два виртуальных жестких диска: на один устанавливается ОС, другой — используется для измерения быстродействия. В первом моем опыте я использовал VHD-файл фиксированного размера 10Гб. Файл размещался на зеркале из двух 250Гб SATA-дисков. Я получил следующие результаты:

    • Total I/O per sec: 111,5
    • Total MB per sec: 6,92
    • Average I/O Response Time: 9,0152 ms
    • Maximum I/O Response Time: 526,0630 ms

    Результаты сильно удручают: 7Мбайт в секунду — это очень и очень мало. Для примера, в хостовой ОС, копирование файла с одного массива на другой показывало скорость порядка 37-40Мбайт/c. Правда, это показания самой ОС, которые могут и не соответствовать действительности. Увы, судя по сайту разработчиков — последняя версия IOMeter'а вышла 27 июля 2006 года, так что не удивительно, что под Windows Server 2008 она хоть и запустилась, но корректно не работала: она просто не «видела» жесткие диски. Если кто-нибудь посоветует мне более новую утилиту, аналогичную IOMeter и нормально работающую под Windows Server 2008 — с меня пиво 🙂

    Время отклика — тоже очень и очень плохое: 9 миллисекунд в среднем, и 526 миллисекунд (просто вдумайтесь в это: больше, чем пол-секунды!) максимум. Вобщем — для, к примеру, веб-сервера вполне бы сгодилось, но устанавливать с таким быстродействием, к примеру, сервер БД какой-нибудь ERP-системы я бы не рискнул.

    Опыт второй: прямое обращение к диску.

    Теперь я удалил злосчастный VHD-файл и перевел наш 250Гб массив в режим Offline через консоль Computer Management (это — необходимое условие, чтобы Hyper-V «увидела» наш диск и его можно было бы подключить к ВМ). После этого — в свойствах тестовой ВМ вместо VHD-файла был подключен наш физический диск и так же — запущен IOMeter c теми же параметрами. Результаты получились следующие:

    • Total I/O per sec: 126,7
    • Total MB per sec: 7,9
    • Average I/O Response Time: 7,9362 ms
    • Maximum I/O Response Time: 96,1755 ms

    Сказать честно — результаты меня удивили. Я не ожидал такой маленькой разницы в iops и в mbps. Чем это вызвано — самому интересно. Вполне возможно, что здесь мы уперлись в потолок быстродействия SATA-дисков. А вот время отклика уже — намного лучше: 8 миллисекунд в среднем и 96 в максимуме, против 9 и 526 соответственно. Как видно, среднее время отклика улучшилось ненамного, возможно, что не улучшилось и вовсе: одна миллисекунда вполне укладывается в погрешность измерения. А вот максимальное время отклика — уменьшилось почти в 60 раз, что не может не радовать.

    Вывод.

    Из всего этого напрашивается следующий вывод: если планируется виртуализировать какие-либо задачи, требующие активного доступа к дискам — нужно использовать прямой доступ к диску. Во всех же остальных случаях я настоятельно рекомендую использовать, как и обычно, VHD. В случае, если использование прямого доступа необходимо — «соломоновым решением», наверное, будет использование двух виртуальных дисков у одной ВМ: один — в виде VHD — для установки ОС и приложений, а другой — с использованием прямого доступа — для хранения данных.

    P.S. У меня имеются подозрения, что на эксперимент сильно повлиял потолок быстродействия SATA-дисков. Недавно у нас в распоряжении оказалась дисковая полка HP MSA2000 с интерфейсом SAS. Завтра — попробую подключить эту полку к серверу, собрать на ней RAID10 и повторить эксперимент. О результатах — обязательно отпишусь. Оставайтесь на канале!

    Александр Косивченко

    • Рубрика: Virtualization,Новое
    • Автор: Александр Косивченко
    • Дата: Среда 01 Апр 2009

Комментарии

  1. Было б интересно почитать. Хотя мне кажется 8 мб/с для гостевой системы- мало. Погрешность проги при измерении? Возможно.

  2. Да вот сам не знаю, в чем было дело. Грешить могу только на SATA и фиговый контроллер. Хотя может и руки у меня кривые — ибо iometer первый раз в руках держал))

  3. Сейчас планирую переход с ESX на Win гипервизор. Попробую прогнать эту прогу, заодно посмотреть результаты.

  4. Если вам не трудно, вы не могли бы поделиться результатом замеров.

  5. А на ESX не проводили аналогичные замеры? Какая там ситуация интересно... =/

  6. Да 8 МБ при случайном доступе по 64 КБ вполне нормальный результат!

  7. один из вариантов замеров скорости диска для ESX

    www.vm4.ru/2009/04/vmdk_14.html

  8. 8 мб для рандомного чтения очень даже нормально.

    пара вопросов, о настройках — Iometr

    под тесты был отдан неразмеченный диск? если нет, то какого размера тестовый файл iobw.tst ?

    в тестировании у вас outstanding ios какой выставлен?

    *Для примера, в хостовой ОС, копирование файла с одного массива на другой показывало скорость порядка 37—40Мбайт/c.*

    это линейное чтение, ничего удивительного, в IOmetr можно сэмулировать линейное чтение — размер блока 64кб + 100 процентов Sequintail + 100 процентов read

    Под руками есть ML150 G3 + Xeon 5110 + 5gb + 4 sata на 250 gb

    Если есть желание можно провести тесты скорострельности дисковой виртуалок поднятых под ESXi, но только в сравнении с VHD, при этом хранилище для VHD — одиночный диск (как в 150G5 так и в 150G3 в набортном чипсете используется Adaptec Pseudo Device, ESXi raid массивы на этом чипе не поддерживает, ибо софтовый)

Опубликовать

Я не робот.