Результаты тестирования FC и Software iSCSI под MS Hyper-V R2

Компания NetApp опубликовала результаты тестирования 4Gb FC и Software iSCSI по 1Gb Ethernet и 10Gb Ethernet в среде MS Hyper-V R2 с использованием своей системы хранения NetAp FAS3160A (система midrange-класса).

Тестирование производилось с помощью IOmeter (о котором я уже не раз писал в блоге), с 4 хост-серверов IBM x3550 (1x Quad-core Intel Xeon E5420, 2,5GHz), на каждом из которых бы установлен Windows 2008 R2 c Hyper-V role и 8 виртуальными машинами в каждом, с Windows 2008 64-bit Enterprise edition (итого 32 виртуальных машины). Интерфейсы каждого сервера: FC – QLogic QLE2462, Gigabit Ethernet – Intel PRO/1000 PT dual port, 10G Ethernet – Intel Ethernet Server Adapter X520, включались в коммутаторы Brocade 200E, Cisco 4948 Ethernet Switch и Fujitsu XG1200 соотвественно.
Особое внимание при тестировании уделялось получению результатов, приближенных к “боевым”, позволяющим использовать их для оценки реальной, “живой” инфраструктуры Hyper-V.

Использовался паттерн: 100% Random, 75% Read, 4KB и 8KB Request size.

Тесты показали сравнительно незначительную разницу между всеми тремя вариантами (4Gb FC, 1Gb software iSCSI, 10Gb software iSCSI) как в IOPS, так и в Latency. Дополнительная загрузка задачи softwre iSCSI initiator составила 3-5 процентов, в том числе и на 512 outstanding IOs (очень высокая загрузка), и разница со значением загрузки при использовании FC уменьшалась с повышением объемов загрузки (Outstanding IOs).

Показательно почти полное отсутствие значимого отличия по быстродействию между 4Gb FC и 1Gb iSCSI на рассматриваемой задаче.
Отсутствие значительной разницы между 1Gb Ethernet и 10Gb Ethernet по видимому связано с тем, что Software iSCSI initiator на 10G Ethernet перестал быть эффективен, и, возможно, следует рассмотреть использование iSCSI HBA для таких высокоскоростных решений.
Также сравнительно небольшую разницу дает включение и использование Jumbo Frames как на 1G Ethernet, так и на 10G Ethernet, что скорее всего говорит о специфике Hyper-V R2 в этом вопросе.

Лимит по производительности системы хранения FAS3160A для такой конфигурации не был достигнут.

Подробности и полный документ по результатам –тут:
http://www.netapp.com/us/library/technical-reports/tr-3846.html

Один комментарий

  1. Korj:

    Максимальная нагрузка с 4 серверов была 2.7Гбит/с, т.е. не выше 675Мбит/с. Следовательно, даже 1ГБит/с карат не была даже близка к перегрузке. Соответственно не имели особого значения и JF, поскольку хватало пропускной и для неоптимальных 1.5-киловых пакетов, да и нагрузка была столь плотной, что карта всё что надо на 1 уровне собирала в большие фреймы.
    Что меряли? Latency ограничена хранилкой, минимум шёл 4ms, что для аппаратной коммутации в неперегруженной сети - долго. IOPS-ы, опять же выдаваемые хранилкой? Ну выдавала она нормальные свои IOPS-ы, которые на этой нагрузке и должна была выдавать - при чём тут метод подключения?
    Был бы другой паттерн - не 100% random 8k, возможно хранилка выдала бы больше, и тогда б что-то упёрлось уже в сеть. Пока упёрлось всё в хранилку, точнее в конечную latency жестких дисков. Хранилка не перегружена - да, но latency имеет ту, что имеет, что и ограничивает результат.
    Хотели показать, что на 100% random 4-8k не нужно ничего, кроме 1G iSCSI? А почему именно такой паттерн? Со стороны сервера может и не нужно, а хранилка как подключалась? Небось же не одним портом 1G Ethernet - вот об этом и речь, когда говорят о 10G том же.

    Вы пишете:
    “в том числе и на 512 outstanding IOs (очень высокая загрузка)”
    На самом деле это на все 32 машины - каждая машина нагружалась до 16 OIO.
    Вы же писалиЖ
    “Значение Outstanding IOs от 1 до 8 относится к очень “легким” программам, 128 и 256 - очень “тяжелым”.”
    Следовательно нагрузка была легкой, по вашей же терминологии.

Оставить комментарий

20/0.130

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.