Skip navigation

Источник: PowerPath VE Versus Round Robin on VMAX – Round 3 (TKO)


Появился очередной тест производительности "PowerPath VE vs Round Robin (RR)" от автора блога www.virtualinsanity.com. Кто не знаком с результатами предыдущих тестов, рекомендую с ними ознакомиться: Тест 1, Тест 2.

Статьи на эту же тему, но только в русскоязычных блогах, вы можете прочитать здесь: Multipathing Часть 1, Multipathing Часть 2 и Параметр IOOperation Limit.

На этот раз автор подошел к этому тесту более обстоятельно. Было задействовано 3 хоста ESXi 5.0, на которых было создано по три (3) Win2008R2 виртуальные машины. В каждой виртуальной машине был запущен IOMeter со своим профилем нагрузки. Вот сводная табличка, где показано, какой профиль IOmeter и на какой ВМ использовался:

testvmsetup.png

Затем было проведено три теста. Первый тест, "Round Robin IOPS=1", дал нам 20,673 IOps. При этом среднее время задержки на чтении (read latency) составляет 7.69 ms, а среднее время задержки на запись (write latency) - 7.5 ms.


Тест "Round Robin IOPS=1000" дал просто ужасные показатели производительности. Общее количество операций ввода-вывода в секунду по сравнению с "Round Robin IOPS=1" меньше на 9000 IOps, а задержка на запись и чтение увеличилась, в среднем, на 40 процентов. Поскольку основная часть профилей IOmeter - это последовательный доступ, то такая большая разница между результатами двух тестов имеет место быть. Ну, а теперь, вернемся к результатам тестов.


Тест с использованием на хостах "PowerPath VE" показывает, что общее количество IOps по сравнению с тестом "Round Robin IOPS=1" увеличилось на 6% и, при этом, на 15% уменьшилось время задержки на чтение (read latency).


Сводная таблица по результатам всех тестов:

results.png

Использовать PowerPath VE или нет - дело каждого. Но автор этого теста для своей VMware среды предпочел использовать PowerPath VE.

Автор блога vTexan.com опубликовал очередную статью касательно VMware View 5 (предыдущие статьи этого автора на тему настройки VMware View вы можете найти здесь). Статья под названием: "Setting up the View 5 Event Database" повествует нам о том, как правильно создать и настроить в админ-панели базу данных для событий (Event Database), генерируемых VMware View 5.

На стареньком сервере Dell PowerEdge 1950 решил я поставить ESXi 5. В этом сервере только два жестких диска, поэтому я собрал зеркало и, затем, накатил гипервизор. ESXi встал без каких-либо проблем. После первоначальной настройки я запустил vSphere Client и соединился напрямую с этим сервером. После удачного соединения полез я в настройки хранилищ. И что-то дернуло меня переименовать одно единственное хранилище datastore1 на что-то более внятное и логичное. Но вместо того, чтобы взять и просто переименовать, я взял и удалил его.


По всей видимости, эта привычка у меня осталась еще от VMware ESXi 4.x, когда нужно было заново пересоздавать датасторы с другим, нужным размером блока, чтобы иметь возможность создавать vHDD размером до 2 Tb. Ну, так вот. Удалить-то я удалил, а вот создать заново не получилось. Выдает вот такую ошибку:

error1.jpg

для наглядности вот полное окно с ошибкой:

error2.jpg

В это время в лог-файле /var/log/hostd.log появляются вот такие записи:

error5.JPG

Подсоединившись к хосту ESXi через SSH и набрав команду:

# df -h

я убедился, что датастора VMFS-5 на этом диске нет:

df.jpg

Тыкание в GUI ни к чему не привело. На том же диске, где до недавнего времени находился удаленный VMFS-5 том, заново его создать не получается. Судя по сообщению об ошибке:

Host cannot perform a partition table conversion

в vSphere 5, если ты удалил том VMFS-5 с диска, на котором располагаются и другие системные разделы ESXi 5, то заново создать датастор на том же диске у вас не получится. Вот так вот.


Кстати говоря, про такое поведение есть статья в VMware KB, на которую я наткнулся уже после написания этого текста. Так вот, в данной статье в качестве решения этой проблемы (когда вам очень сильно нужно локальное хранилище) рекомендуют просто переустановить ESXi на сервере.