Результаты тестирования 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
Максимальная нагрузка с 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 - очень “тяжелым”.”
Следовательно нагрузка была легкой, по вашей же терминологии.