Skip to main content

Microsoft iSCSI Initiator и аггрегация сетевых линков

UPDATE1: VAL внес важную поправку во всю писанину – “ни черта не понятно”. Завтра запишу видео, с комментариями 😉

Много букв, основной тезис – “аггрегация и iSCSI не работает быстро”. Чуть разверну 😉

Почему-то не в первый раз сталкиваюсь с ситуацией, когда разнообразные товарищи пытаются что-то “пофиксить”, добиваясь максимальной производительности от связки Microsoft iSCSI Initiator и Oracle Unified Storage/Solaris 11/OSol/OI COMSTAR. В результате беглого анализа обнаруживается любопытная связка – сервер Windows 200x + NIC Teaming (Link Aggregation, или объединение линков, это по-нашему) на нем (благо многие брендовые сервера содержат в себе отличные сетевые наборы от Intel c соотв. обвязкой) + Oracle iSCSI Software Target (COMSTAR/Unified). И коронный вопрос “и где тут ваши сотни мегабайт в секунду?!”.

Ну так вот, для желающих сделать аггрегацию, дабы ускорить процессы ввода/вывода на системах – такая схема НЕ поддерживается, о чем прямо говорится в документации Microsoft iSCSI Software Initiator 2.x Users Guide на страничке 15 (зацитирую): Microsoft does not support the use of NIC teaming on iSCSI interfaces. тчк. Ну не поддерживает MS такой конфигурации (что логично в силу особенностей траффика iSCSI). Работать, тем не менее, такая схема будет, но никаких фантастических результатов на ней достигнуть, увы, не получится – как показало беглое исследование (некий свитч Cisco, как бы не 2950, x86 машина с 4-мя ethernet, uss7000 + tcpdump + наблюдение за свитчом), балансирока, применяемая для аггрегированных линков, не обеспечивает эффективное “разведение” траффика по конкретным линкам внутри аггрегации. По сути – это пустая трата ресурсов.

Дальше сколько-то слов про “что делать?” и “как быть?”

Как быть? Что делать?! Да очень просто – создать нормальный SAN – с полностью изолированными и разведенными по свитчам линками (это наш failover), в отдельных VLAN (это наша изоляция и производительность). iSCSI траффик – это, например, Ваши файлы БД, которые, может так статься, исключительно чуйствительны к задержкам (asvc_t на Solaris iostat). Не будучи изолированным от общего сетевого траффика (а он может быть очень существенным, если предположить использование некоего специфичного ПО – например, NetBackup), можно получить деградацию производительности, которая окажет очень большое влияние на продуктив – что немаловажно – такое влияние будет слабо поддаваться быстрому анализу…

Microsoft iSCSI Initiator поддерживает MPIO. Это плюс. Sun Unified Storage поддерживает много порталов – еще один плюс. В итоге – создаем нужное количество (по количеству доступных сетевых портов, в общем случае) порталов iSCSI на системе хранения, по вкусу – изолируем их в отдельные VLAN и на раздельных свитчах. На инициаторе прописываем нужные порталы. И все! Проблема – решена.