Меня смущает термин "не спасти" - не очень понятно, о чём это.Stranger03 писал(а):Оно конечно может и так, но, выражу сомнение:Umlyaut писал(а):Вот только в этом контексте эти Ваши "транки" суть есть L2-агрегация по LA(CP) - тогда как мультипас по L3 кроет L2-агрегацию как бык овцу и без всякой поддержки со стороны коммутаторов
1. мультипас требует поддержки со стороны хоста, на уровне драйверов ОСи. В случае одного, двух хостов ок, а в
2. мультипас может и не спасти, если хостов будет десяток, другой. Как себя поведет СХД в этом случае, вопрос.
Впрочем, пойдём по порядку:
1. Да, МР должен быть на хосте (инициаторе iscsi). В случае Сферы с этим всё более чем в порядке;
2. "Десяток-другой хостов" ничего не меняют принципиально - каждый хост-инициатор общается с таргетом как если бы он был один, "ничего не зная" о наличии "десятка-другого" конкурентов.
Подчеркну - речь не идёт о разделе полной пропускной способности дисков и/или сети у СХД - просто именно механизму МР хоста (как балансировщику I/O) до звезды, с каким к-во инициаторов ещё общается в данные момент таргет;
Сразу хочу мягко заметить, что это не самый лучший вариант с т.з. редундантности - лучше бы взять два свитча 1G и раскидать линки по ним поровну.Stranger03 писал(а):Вот кстати и вопрос. Рассмотрим пример. Есть у нас iSCSI Infortrend. Подключили мы его в неуправляемому коммутатору типа Dlink по 10G. Ну скажем воткнули 4-е соска.
Да, стекабельность (классическая, через бэкбон, а не плюшевый псевдостек а-ля "что-же-ты-Паккард" через порты) свитчей при этом абсолютно не требуется - можно их даже не соединять между собой, для IP МР это не нужно.
Почему нет? Естественно, если все ваши 10-20 серверов ломанутся одновременно, чтобы сгенерить суммарно трафик на интерфейсах Инфотренда, то да, в сумме он будет отдавать столько, сколько одновременно смогут утилизоровать все активные на тот момент хосты.Stranger03 писал(а): Есть у нас ферма серверов, ну скажем 10-ть (20-ть) штук. Все завели на iSCSI. Как себя поведет Infortrend? Сможет ли он выдать наружу 40G? На дисках не зацикливаемся, считаем, что у нас их достаточно.
Не в обиду вашим парням будь сказано, но они, возможно, просто "не умеют его (10G) готовить(тм)"Stranger03 писал(а): Подумал, спустя минут 10-ть. Что-то мне подсказывает, что даже в случае с мультипасом на стороне хостов бОльше 10G мы выжать не сможем. Наши парни говорят, что агрегации в случае с iSCSI нет, ну или мы об этом пока не знаем.
Я поначалу тоже думал, что это фигня и недалеко ушла от L2-aggregation, но потом научился делать правильно (это заняло некоторое время на раздумья, RTFM и тесты, но оно того стОило).
Там весь "секрет" в настройке IP: если все интерфейсы, участвующие в МР, привычно сделать в одной (подсети) - скажем, в стандартной 192.168.1.х/24 или ещё какой, то "кина не будет".
А вот коли разнести их на (под)сети разные:
------------
Host1 nic1(10G) 192.168.26.53/24 -> physSwitch -> SAN1 nic1(10G) 192.168.26.231
Host1 nic2(10G) 192.168.27.53/24 -> physSwitch -> SAN1 nic2(10G) 192.168.27.231
Host1 nic3(10G) 192.168.28.53/24 -> physSwitch -> SAN1 nic3(10G) 192.168.28.231
Host1 nic4(10G) 192.168.29.53/24 -> physSwitch -> SAN1 nic4(10G) 192.168.29.231
Хосты2, 3, 4, etc. - точно по той же схеме.
-----------------
то картина меняется радикальнейше - когда каждый путь находится в своей (под)сети, то в этом случае RR-балансировка на хосте отрабатывает близко к идеалу (могу даже скрин выложить, где видно счётчики трафика на паре 10G-интерфейсов во время svMotion - по 270MB/s на каждом из двух интерфейсов с разбросом 10-100KB/s).
Советую попробовать протестировать по моей методике - уверяю, мнение о "неработающей" iscsi-балансировке поменяется.
А вот это уже вопрос не балансировки, а насыщения "аплинка" от СХД.Stranger03 писал(а): Итого, у нас есть 4-е линка по 10G. Если 10-ть хостов начнут молотить с СХД, то в среднем по больнице на каждый хост мы получим где-то в районе 4G. И вероятно вы правы, L2 здесь будет как мертвому припарки.
Моя личная практика показывает, что при правильной настройке масшабирование будет практически линейное и, что важно, "на все деньги" (конечно, с условием, что диски хранилки смогут отдать/взять всё это богатство, а дури процов хранилки хватит на обработку пакетов - кстати, это и для хостов справедливо
).Отсюда вывод - если каждый хост действительно "впитывает" полные 10G от хранилки, то для уменьшения "перекоса" ставьте на хранилку не 4, а больше 10G-интерфейсов (сколько потянут другие подсистемы).
).