Pull to refresh

Comments 80

Вообще-то, коннектором для QDR и FDR является QSFP (и для оптики и для меди). CX4 для SDR и DDR.
Согласен, уточню в тексте
А продается ли подобное оборудование в России, и если да, то сколько оно стоит? Прошлым летом на Ipv6 day о нем крайне интригующе рассказывали, обещали через год будет.
Intel сама не занимается продажами, так что точной информацией не владею :( Когда искал материалы к посту, натыкался в гугле на нескольких интеграторов, занимающихся поставками оборудования Infiniband, так что купить у нас точно можно. Сколько оно стоит — наверное, тоже у них надо спрашивать.
Понял, спасибо, буду искать.
IPv6 мапится прямо в кадры InfiniBand, так что он там присутствовал изначально.

Продукты и Qlogic, и Mellanox продают все ведущие вендоры серверного оборудования — HP, IBM, Dell. Напрямую, вроде, не продаются, только через OEM-партнёров.
Свободно продается, ищите представителей Mellanox и Qlogic
Наконец-то Интел заговорил об Инфинибенде. Хочется узнать о судьбе наследия Кулоджика — будет ли развиваться это подразделение, какие продукты можно ожидать?
Скажите пожалуйста, а возможно-ли связывать по InfiniBand разнесенные на большие расстояния площадки и будут ли у IB какие-либо преимущества в этом случае по сравнению, например, с 10/40 GE?
И есть ли вообще примеры(опыт) внедрения InfiniBand-сетей между датацентрами?
На данный момент это больная тема InfiniBand. Есть несколько разрозненных решений для «дальнобойного» ИБ:
1) у Мелланокс для передачи на дальние расстояния трафик ИБ заворачивается в 10GigE, для чего в директор ставится модуль-бридж.
2) у ADVA есть оптическое решение xWDM, которое позволяет пробрасывать нативный 1x QDR InfiniBand на метро-расстояния (до 100 км).

Возможно, появилось ещё что-то.
У одного американского поставщика видел достаточно дешёвые карточки — они без набортной памяти, зато 125 баксов всего. Там же и коммутаторы были — не такое уж и дорогое это удовольстви, что-то около 250 баксов на порт, всё жду, когда появится возможность организовать маленький такой кластер на таких железках… Не рекламы ради — погуглите ColFax Direct — там вполне себе можно собрать кластер на коленке.
10G IB карточки (SDR 4x) я покупал на ebay по $23 :)
Меня больше всего задавила жаба при виде цены на кабель для них на том сайте :)
А кабели я купил у китайцев по каким-то разумным ценам, типа баксов по 30 за трехметровый.
На ebay, естественно.

Не с первого раза, но рабочий комплект набрался (1 или 2 кабеля работали на 10G ether, но не работали с IB, так и работают с ether теперь)
В какой-то степени жалко, что подобные весьма перспективные технологии все время бьются с очень бородатым, хромым от рождения и перекачанным стероидами езернетом, и чаще всего проигрывают — как FC, который в большинстве современных внедрений транспортируется поверх ethernet либо не используется вовсе, так потихоньку и IB.

Иерархическая приоритизация трафика? DCB. Приоритезация, годная для пускания FCoE трафика, который исключительно чувствителен к потерям, и да, есть иерархия.
Низкая латентность? Нексусы линейки 3000 дают задержку L2/L3 коммутации пакета менее 200 наносекунд (на 10G/40G интерфейсах). Примерно на том же уровне работает и Infiniband.
Масштабируемость? Либо TRILL, либо древняя, но оттого не менее эффективная clos фабрика с агрегацией линков.
Возможность резервирования? Для ethernet это никогда не было проблемой.
В драйверной части IB сделано очень много такого, чтобы не ходить по уровням модели OSI, заворачивая-разворачивая пакеты, а избавиться лишнего (и задержек-оверхеда). RDMA, GPUDirect, SRP и так далее.

Из перечисленного, поверх ether есть, вроде бы, только RDMA.
А потом выясняется, что оверхеды-то эти несущественны. Современному сетевому оборудованию что L2, что L4 — одинаково по ресурсам и задержкам, ибо все давно реализовано хардварно. Современные ЦП тратят абсолютно мизерные ресурсы на сворачивание-разворачивание пакетов (особенно по сравнению с тем, каким обработкам подвергнутся данные L7, ради которых все и затевалось). Да еще и современные сетевухи, особенно интеловские, offload'ят львиную долю обработки пакета.

Что до SRP — уж простите за ламерство (с IB никогда не работал), но разве это не примерно то же самое, что и iSCSI для классического EoIP? Я уж не говорю о том, что сейчас намечается тенденция к уходу от блочных хранилищ в сторону NFS, который, вообще говоря, по скоростям сравним, а по оверхедам лишь незначительно хуже основных конкурентов, зато проще и приятнее в работе. А реализовать единую 40G/10G фабрику на ethernet с приоритезацией любого рода трафика SAN куда проще и дешевле, чем содержать две отдельные физические сети как это принято сейчас.

GPUDirect? Забавно, но уж слишком специфично и ОЧЕНЬ мало кому нужно. А к тому времени, когда возникнет всеобщая потребность в сетевом доступе к ресурсам видеокарт — и Infiniband запросто может отбросить коньки, и поверх IP over Ethernet наверняка это дело реализуют, как всегда. Ведь, как я писал выше, RTT — главное преимущество IB перед ethernet — уже примерно сравнялся у обоих.
Инфинибенд задумывался как замена и эзернету, и файбер ченнелу. Тот же Мелланокс позиционирует свои сети как конвергентные. Приводят в презентациях фотографии, где от сервера отходит только два IB-провода (для повышения доступности больше, нежели для производительности).

Есть прямой маппинг NFSoIB. SRP — это маппинг SCSIoIB. По богатству upper-level protocols Инфинибенд превосходит даже начальные стандарты Fibre Channel. Так что говорить о том «зачем ИБ, когда есть конвергентный эзернет» оправданно, когда у вас уже есть эзернет. А когда вы строите новое решение, то почему бы его не построить на ИБ?
Инфинибенд задумывался как замена и эзернету, и файбер ченнелу.

Движение есть, прогресса нет.
А когда вы строите новое решение, то почему бы его не построить на ИБ?

Есть уверенность в том, что ethernet завтра не умрет (сейчас он бешеными темпами обрастает дополнительными костылями). Нет уверенности в том, что Infiniband завтра не умрет — появление технологий вроде RoCE традиционно является дурной приметой. Да и по цене — наверняка ethernet дешевле при сравнимых характеристиках.
Все это справедливо для классического ЦОДа, которому, если быть честным, сверхвысокая производительность всех компонент не критична.

InfiniBand — это больше область HPC и если смотреть на современные тенденции, то сейчас даже 10GE сети в этой области являются максимум вспомогательными или I/O сетями. Основные данные, где критична latency, критична надежность и предсказуемость доставки, критичны все специфические функции от атомарных операций до GPUDirect в основном ходят либо поверх InfiniBand, либо поверх проприетарных решений.
InfiniBand — это не только умная пересылалка пакетов, но и большое количество необходимой дополнительной функциональности, которую Ethernet просто не умеет.

От NFS уходят, а некоторые уже ушли к распределенным хранилищам, например, построенным при помощи GPFS, Lustre и т.д., так как пропускная способность хранилища данных суперкомпьютера — это достаточно больная тема и у классических хранилищ тут есть некоторые проблемы.

P.S. Из Enterprise решений с IB на ум приходит Oracle Exadata, так что даже в бизнес-сегменте не все так гладко с Ethernet.
Ещё можно отметить, что практически все более-менее крупные производители материнских плат для серверов имеют в своей линейке минимум одну такую плату с IB. А у некоторых IB — это штатная опция по умолчанию :)
И, по-моему, 10G Ethernet дороговат по сравнению с тем же IB начального уровня.
HP ProLiant линейки SL начиная с G7 имеют чип на материнской плате от Мелланокса, к которому подключено два порта. Их можно сконфигурировать либо оба как IB, либо оба как 10GigE, либо один так, другой сяк. Так что в данном случае цена 10G vs IB практически идентична.
IB много где используется в Enterprise решениях. У EMC — в линейке Isilon и в будущем у XtremIO (у обоих в бэкэнде); есть опытные образцы фронтэнд портов IB для VMAX и VNX. Есть сторадж DDN с ИБ-фронтэндом. Есть ИБ-фронтэнд у стораджей от Texas Memory Systems. С появлением драйверов под VMware стало возможным использовать и в фермах vSphere для передачи IP-трафика (быстрый vMotion, быстрый доступ к NFS).
InfiniBand — это больше область HPC и если смотреть на современные тенденции, то сейчас даже 10GE сети в этой области являются максимум вспомогательными или I/O сетями.

Кому не хватает агрегированных 10G — есть 40G и 100G. Хотя да, буквально на днях IB наконец-то перегнал ethernet на этом поприще — но оборудование с 40G и 100G интерфейсами (а также с минимизированными задержками) появилось относительно недавно (по меркам суперкомпьютеров, которые строятся по несколько лет), так что запасаемся попкорном и смотрим, кто — кого.
Основные данные, где критична latency, критична надежность и предсказуемость доставки

Про latency говорил. Надежность? Само существование FCoE говорит о многом. Потери => переход сторы в RO. Предсказуемость? Clos фабрика — и вам нет дела до предсказуемости.
InfiniBand — это не только умная пересылалка пакетов, но и большое количество необходимой дополнительной функциональности, которую Ethernet просто не умеет.

Сейчас даже TDM поверх ethernet гоняют (кто-то, где-то, наверное). Уж на что, мягко говоря, диаметрально противоположные подходы.
Не проблема реализовать все фичи Infiniband поверх любого другого транспорта с минимальным оверхедом. Само собой оно будет работать немного хуже, но зато проще и дешевле. Грубо говоря, на сэкономленные деньги можно еще нод в кластер докупить.
От NFS уходят, а некоторые уже ушли к распределенным хранилищам, например, построенным при помощи GPFS, Lustre и т.д.

Тут имеет смысл взглянуть на тех, у кого действительно адские требования к инфраструктуре. Например, насколько мне известно, сеть Google вполне себе работает на IPoE, разве что они сами разрабатывают себе оборудование и софт для него. Надо ли говорить, что гугл — из тех, кто на несколько лет опережает рынок по технологичности своей инфраструктуры? Да и Amazon, и FB, и Twitter, и прочие гиганты тоже не замечены в пользовании IB.
Кому не хватает агрегированных 10G — есть 40G и 100G.

А 40 и 100 G порт уже можно поставить в один сервер? Я таких решений пока не видел, а IB есть уже здесь и сейчас.

так что запасаемся попкорном и смотрим, кто — кого.

Ставлю на InfiniBand и проприетарные решения. По крайней мере мне не известно о том, чтобы кто-нибудь пытался создавать основную коммуникационную сеть на базе Ethernet.

Про latency говорил. Надежность? Само существование FCoE говорит о многом. Потери => переход сторы в RO. Предсказуемость? Clos фабрика — и вам нет дела до предсказуемости.

Беглый взгляд в вики, говорит, что IB дает раза в 2 меньшее латенси. Под надежностью я имел ввиду такие сервисы как Reliable Connection, Reliable Datagram. 1 или 2 хопа — для задачи могут отличаться Очень сильно…

Сейчас даже TDM поверх ethernet гоняют (кто-то, где-то, наверное). Уж на что, мягко говоря, диаметрально противоположные подходы.

Есть RFC по передаче IP пакетов методом голубиной почты ;)

Тут имеет смысл взглянуть на тех, у кого действительно адские требования к инфраструктуре. Например, насколько мне известно, сеть Google...

А у гугла нет адских требований к инфраструктуре. Гугл и ко берут масштабом, а не требованиями. Посмотрите, например, на суть предложенного гуглом MapReduce. Им не критична скорость отклика системы, не нужно постоянно быстро обмениваться данными между всеми компонентами системы одновременно. Если посмотреть внимательно на архитектуру, то можно увидеть что она достаточно слабо связана, так как задачи гугла можно разбивать на много маленьких, практически не зависимых подзадач.
В этом случае проблему масштабности можно решать софтварно.

Но есть и другой полюс, где задачи сильно связаны, требуется постоянный обмен данными и огромные вычислительные мощности. Тут уже возникают действительно адские требования к коммуникационной инфраструктуре. Один или два хопа, могут быть узким местом в производительности всей системы, а не некоторого локального участка. — Это мир HPC, где сейчас не видно конкурентов для IB и проприетарных решений.
А 40 и 100 G порт уже можно поставить в один сервер?

www.google.ru/search?q=ethernet+adapter+40g
Да.
мне не известно о том, чтобы кто-нибудь пытался создавать основную коммуникационную сеть на базе Ethernet.

blog.infinibandta.org/2012/06/21/infiniband-most-used-interconnect-on-the-top-500/
Причем ethernet там обычно 1G…
Беглый взгляд в вики, говорит, что IB дает раза в 2 меньшее латенси.

По сравнению с чем?
www.cisco.com/en/US/products/ps12581/index.html
Algo Boost technology allows the Cisco Nexus 3548 to achieve exceptionally low latencies of 250 nanoseconds (ns) or less for all workloads — unicast and multicast, and Layer 2 and 3 — regardless of the features applied.
Warp mode can further reduce latency to 190 ns for small-to-midsize Layer 2/3 deployments
Warp SPAN enables stock market data delivery to trading servers in as little as 50 ns


en.wikipedia.org/wiki/InfiniBand#Latency
The end-to-end latency range spans from 1.07 microseconds MPI latency (Mellanox ConnectX QDR HCAs) to 1.29 microseconds MPI latency (Qlogic InfiniPath HCAs) to 2.6 microseconds (Mellanox InfiniHost DDR III HCAs)

IB где-то в десяток раз медленнее :)
Под надежностью я имел ввиду такие сервисы как Reliable Connection, Reliable Datagram.

На ethernet транспорте потери — следствие перегрузки интерфейсов. DCB решает. На современном железе с правильной СКС шанс увидеть битый пакет примерно равен шансу увидеть живого динозавра…
Есть RFC по передаче IP пакетов методом голубиной почты ;)

Есть и мое любимое RFC про передачу электричества поверх IP. Кстати, вдохновением автору данного шедевра служил другой RFC, про SONET over MPLS :)
Им не критична скорость отклика системы

Это как раз главная их задача — чтобы странички у пользователей грузились мгновенно. А еще чтобы ютуб не тупил (сколько там терабит трафика уходило из ЦОДов гугла во время вчерашнего стратосферного прыжка?).
И задачи гугла куда ближе к потребностям подавляющего большинства, чем задачи, связанные с HPC. К примеру — у дисковых массивов самих по себе такой latency, что задержки на сетевом оборудовании никого не интересуют.
Один или два хопа, могут быть узким местом в производительности всей системы

Узким местом по какой причине?
Это мир HPC, где сейчас не видно конкурентов для IB и проприетарных решений.

Ссылка выше. IB только-только обогнал устаревшую версию ethernet.
О, есть цифры end to end. 1.07 микросекунды для Mellanox 40G (которые универсальные, ethernet/IB)

Mellanox, когда 56G IB презентовал, клялся что end-to-end latency — в пределах 700нс через один свитч.

Полтора раза для суперкомпьютерных задач — заметная разница.
Mellanox, когда 56G IB презентовал, клялся что end-to-end latency — в пределах 700нс через один свитч.

Полтора раза для суперкомпьютерных задач — заметная разница.

То есть выигрыш Nexus 3548 в три раза по сравнению с самой быстрой ревизией IB, или аристы 7150 в два раза — это хорошо? :)
Не, nexus — это же только свитч. А я про end-to-end, из юзерлевел в юзерлевел.

Интел для своих 10G-карт похвалялся 2 микросекундами, кажется, но непонятно с каким свитчом

В свитче — пишут что 100-165 наносекунд port-to-port у мелланоксовских свитчей.
«2 микросекундами» — это end-to-end
я про end-to-end, из юзерлевел в юзерлевел.

А где было такое написано?
Интел для своих 10G-карт похвалялся 2 микросекундами

Микросекундный рубеж вроде побит. www.accelize.com/about-us/news/55-accelize-announces-xp7v690lp-40g-low-profile-pci-express-ultra-low-latency-xilinx-virtex-7-based-fpga-network-adapter-card.html
У Мелланокса есть 1,3мкс.
Как где: 'O, есть цифры end to end'.

А вы в том сообщении сравнивали свитчевый delay с end-to-end, что удивительно мне

Хм… Значит уже есть.

blog.infinibandta.org/2012/06/21/infiniband-most-used-interconnect-on-the-top-500/
Причем ethernet там обычно 1G…

Мы говорим о том, что было или о том, что будет? Если о том что было, то логично, что в основной массе использовался менее функциональный Ethernet, когда IB не было или был дорог или использовался проприетарный интерконнект. Если говорить о том, что будет, то похоже, что в вершине top500 ethernet'у в ближайшей перспективе уготована роль вспомогательных сетей.

На ethernet транспорте потери — следствие перегрузки интерфейсов. DCB решает. На современном железе с правильной СКС шанс увидеть битый пакет примерно равен шансу увидеть живого динозавра…

В СКС согласен потери как динозавры, но как универсально с вершины приложения и ОС гарантировано не перегрузить интерфейсы, включая промежуточные(например, если если вдруг все лезвия одной корзины ломануться к лезвиям соседней, а между корзинами линьков в 2 раза меньше)?

IB где-то в десяток раз медленнее :)

end-to-end — это от приложения к приложению через NIC и возможно коммутатор.
Чуть выше написано про «QDR switch chips have a latency of 100 nanoseconds.».
Если сравнивать end-to-end, то нужно к латенси коммутатора прибавить задержки в двух сетевых картах и в драйверах.

Это как раз главная их задача — чтобы странички у пользователей грузились мгновенно.

Не совсем. Если у абстрактного Иванова И.И. скорость доступа к ютубу упала раз в 100, то это скажется на остальных, абстрактных Петровых И Сидоровых? Нет, не скажется, по этому задача гугла в том, чтобы у основной массы грузились «мгновенно». Им не критично, если будут отстающие, так как задачи отдачи котиков с ютуба пользователям независимы.

И задачи гугла куда ближе к потребностям подавляющего большинства, чем задачи, связанные с HPC.

Ну мы-же здесь про top-level задачи рассуждаем?

Узким местом по какой причине?

По причине сильной связности решаемых задач. Требуется постоянно учитывать, что насчитали соседние узлы и в этом случае неравномерность отклика сильно портит всю картину.

Ссылка выше. IB только-только обогнал устаревшую версию ethernet.

В прошлом да по массовости IB относительно недавно уступал Eth, но я говорю о предполагаемом будущем.
не перегрузить интерфейсы, включая промежуточные

supportforums.cisco.com/docs/DOC-16176
Все давно продумано. Вы ведь понимаете, что для обеспечения беспотерьной передачи FCoE трафика никак не обойтись без сигнализирования отправителю о перегрузках?
Впрочем, практически полностью утилизированные линки — это на самом деле здорово. Гугл как-то хвастался, что у них процент утилизации в среднем составляет 90%. Да и в 100% загрузке сетевых интерфейсов нет ничего совсем уж страшного — до тех пор, пока работает какая-либо приоритезация и есть некритичный трафик, который можно подвинуть.
end-to-end — это от приложения к приложению

Ок, теперь верю. Ну что же, подождем, посмотрим. Ведь low-latency ethernet свитчи только недавно появились, как и сама задача снижения задержки.
Ну мы-же здесь про top-level задачи рассуждаем?

Помнится, выше кто-то предлагал отказаться от ethernet в пользу IB в современных ЦОДах — и речь шла не про интерконнекты суперкомпьютера…
но я говорю о предполагаемом будущем.

Вот я и говорю, что совсем недавно ethernet резко рванул вперед, так что тренд, изображенный на том графике, запросто может прекратиться.
Introduction to Priority based Flow Control

и есть некритичный трафик, который можно подвинуть

А если его нет? Весь трафик критичен и лучше равномерно распределить пропускную способность, чем кого-либо двигать.

Помнится, выше кто-то предлагал отказаться от ethernet в пользу IB в современных ЦОДах — и речь шла не про интерконнекты суперкомпьютера…

Это был не я. Но каюсь, грешен — увел разговор в свою область из области обычных ЦОДов.

Вот я и говорю, что совсем недавно ethernet резко рванул вперед,

Однако IB — это не только умная передача пакетов. А ничего из оставшегося ethernet на текущий момент не умеет (разве что кроме RDMA).
А если его нет? Весь трафик критичен и лучше равномерно распределить пропускную способность

Ethernet прекрасно поддерживает ECMP (то бишь равномерную балансировку по множеству линков). Можно по старинке, агрегацией, а можно новомодным TRILL, который по сути есть воплощение протокола маршрутизации IS-IS на L2, что позволяет строить достаточно сложные L2 топологии с избыточностью и при этом без блокировки лишних линков.
А ничего из оставшегося ethernet на текущий момент не умеет

Дык научить-то не проблема, был бы драйвер. Научат, никуда не денутся.
ECMP можно как-нибудь прикрутить, когда источники трафика (сервера) по умолчанию ничего не знают друг о друге(и о топологии сети) и упираются в более узкий участок не ранее чем через один коммутатор? При этом если источник и приемник в одном коммутаторе, то они могут общаться на скорости порта не мешая другим.
В ethernet сервера и так ничего не знают о топологии сети. Им известны лишь идентификаторы друг друга (mac адреса). Разруливание потоков по линкам — задача коммутаторов.

Ну и как бы само собой разумеется, что при общении в пределах одного коммутатора трафик не выходит за пределы этого коммутатора. Времена хабов давно прошли.

Технически, ничто не мешает организовать ethernet сеть вообще без переподписки. Например, 4х40G на аплинки и 16x10G до серверов, коммутатор в ядре имеет много 40G интерфейсов. Но это примерно всегда нецелесообразно.
blog.ioshints.info/2012/09/building-large-l3-fabrics-with-brocade.html — один из примеров крупномасштабной сети на ethernet. 4500x10G портов и переподписка 1:3 (прекрасный показатель для ЦОДа, в большинстве случаев даже избыточный).
Ну это-же не решение поставленной существующей задачи? Это вообще общие слова.
При наличии переподписки, как все вышесказанное позволит мне обеспечить гарантию доставки и отсутствие перегрузки на уровне ethernet, если сервера о переподписке ничего не знают и захотят передавать на скорости порта?

Технически, ничто не мешает организовать ethernet сеть вообще без переподписки.

В идеале конечно да, но существующую то задачу это как решит, если инфраструктура уже есть?
При наличии переподписки, как все вышесказанное позволит мне обеспечить гарантию доставки и отсутствие перегрузки на уровне ethernet, если сервера о переподписке ничего не знают и захотят передавать на скорости порта?

Еще раз: эта задача давно решена. Смотрите на реализации FCoE трафика, конкретнее — технологии DCB и PFC. Это тот случай, когда потерь быть не должно вообще.

Вы всерьез считаете, что сценарий «все блейды на полной скорости обмениваются данными» имеет хотя бы малейшее отношение к действительности? Но это же абсолютно невозможно.
Сценарий когда «блейды на полной скорости обмениваются данными» и упираются в bandwidth/latency интерконнекта — это типичный такой случай для высокопроизводительных вычислений.
Неважно, про какие случаи мы говорим. Даже если умышленно добиваться этого — перед вредителем стоит сложная комбинаторная задача.
1) Два обменивающихся данными сервера ни в коем случае не должны оказаться на одном свитче.
2) Обмен данными должен быть организован так, чтобы все блейды были разбиты на пары, с полной загрузкой 10G линков двухсторонним обменом. Если же на пары разбить не удастся и трафик ходит между тремя или большим числом блейдов — задача еще сильнее усложняется.

Так не бывает.
1) А если обмены проходят по принципу все со всеми? Или четные с нечетными? А задача запущена на сотнях(тысячах) ядер, которые в один свич могут не влезть.
2) Вы описали типичнейший случай расчетной задачи, например, когда нужно получить рассчитанные данные о цифрах в соседних узлах сетки.

Так бывает чуть менее чем всегда.
А если обмены проходят по принципу все со всеми?

Если есть три сервера с 10G интерфейсами, и два из них захотят херачить по 10G на третий, то суммарная загрузка аплинков составит не 20G, а 10G.
Потому я и говорю, что это — сложная комбинаторная задача, в которой много факторов.
Так бывает чуть менее чем всегда.

То есть 100% нод разбиты на пары и качают между собой данные, причем каждая пара разнесена по разным свитчам? Это — бред, такого не бывает. Вы, видимо, что-то недопонимаете из того, что я говорю.
Ну вот принципиальное отличие IB и заключается в том, что юзерское приложение (сервер) может узнать о топологии сети и затем это знание разумно использовать.

Например, для правильного броадкаста данных в кластере.
Например, для правильного броадкаста данных в кластере.

У езернета давно есть мультикаст. Куда уж правильнее? Есть разного рода оверлеи поверх L3.

Мне вот кажется нецелесообразным, что задача распределения потоков должна возлагаться на сетевое оборудование, а для клиента сеть должна быть совершенно прозрачным облаком.
Вот представьте, что у нас есть кластер с более чем одним свитчем (задержки на свитче — допустим 200нс) и нам надо спланировать некую расчетную задачу.
Разумно распределить ее так, чтобы те ноды, которым нужно более тесное общение между собой — сидели бы на одном свитче.

Без знаний о топологии сети этого сделать нельзя. Понятно, знание можно принести в программу вручную (как-то вбив туда топологию), но автоматически оно как-то надежнее.
Разумно распределить ее так, чтобы те ноды, которым нужно более тесное общение между собой — сидели бы на одном свитче.

И это давно решено. Вы забыли про существование такой штуки, как «виртуализация», особенно в контексте нагруженных облачных сервисов? Ведь у каждого хоста есть свой виртуальный (или у UCS — физический) свитч, и надо бы группировать тесно общающиеся виртуалки на одном хосте. Для этого есть оркестраторы, которые в курсе, что и где расположено. И еще они в курсе топологии транспортной сети. В отдельных случаях они способны управлять сетевым железом.
А ведь есть еще и постепенно появляющийся SDN, который лет через 5-10 уже может в нормальном виде выйти на рынок. Тот же ethernet, но в теории — с безграничной гибкостью управления потоками данных, и опять же не требующий предоставления серверам лишней информации.

Изучайте инфраструктуру облачных сервисов. Если интересно — могу накидать ссылок.
Изучайте инфраструктуру облачных сервисов. Если интересно — могу накидать ссылок.

Напишите пожалуйста, какой вендор поставляет готовые облачные решения для высокопроизводительных вычислений, а не для бизнес-приложений?

После этого можно будет рассуждать о виртуализации, потери от которой перекроют все «преимущества» в разы.
Давайте почитаем вторую ссылку:
«We expect the VM overhead is unacceptable for MPI jobs over interconnects»
«Technology is ready for implementation of private HPC cloud without VM.»
«A full HPC cloud solution running on VM is very application dependent.»

Те в частных случаях возможно, но в общем HPC-случае все не так радужно. Но исследования в этой области действительно ведутся.
И на самом деле речь не про саму по себе виртуализацию, а про то, что в контексте виртуализации возникает схожая задача, и она вполне решается.
Ну реально — в чем проблема сторонним оркестратором собирать с коммутаторов данные о подключенных нодах (хоть по LLDP) и сведения о потоках данных (хоть netflow), обработать эту информацию и выдать рекомендации по оптимальному расположению нод? Вы видите тут хотя бы малейшие трудности?
Вы видите тут хотя бы малейшие трудности?

А через пару часов одни задачи досчитаются, другие запустятся и профиль трафика изменится.
А каким образом в случае IB рассчитывается распределение задач с учетом минимизации хопов между системами? Вот берете этот метод и банально применяете его к ethernet.
Никто не спорит с тем, что информацию о топологии собрать можно. Равно, как никто не спорит с тем, что на Ethernet можно сделать low latency решение, благо хостовое оборудование вообще идентично во многих случаях (карты 40G/IB), а ether-свитчи медленнее IB-шных (port to port) всего-то раза в два.
И никто не спорит с тем, что можно сделать bypass мимо layering, получив низкие задержки в драйвере (см. выше про одинаковость оборудования).

Разница в том, что на ethernet это *можно* сделать, а на IB — *уже* сделано. Поэтому если выбирать решение для HPC сегодня, то выбор — очевиден.

Когда сделают (не «можно сделать», а реально сделают) — тогда и посмотрим.
Разница в том, что на ethernet это *можно* сделать, а на IB — *уже* сделано.

И тут мы возвращаемся к тому, что всегда появляется костыль, работающий поверх ethernet и позволяющий с вполне приемлемым качеством засунуть круглое в квадратное. Даже FC и TDM поверх езернета транспортируют, хотя их идеологии вроде бы с точки зрения здравого смысла несовместимы с ethernet (нельзя пускать протокол, не переносящий потерь, поверх протокола, которому нет дела до потерь; нельзя пускать требующий точной временной синхронизации протокол поверх транспорта, которому нет дела до задержек и у которого они by design будут варьироваться).
А все потому, что ethernet чертовски универсальный. И если где-то он работает не очень хорошо, то появляется новый протокол для ethernet, устраняющий проблему.
И где же костыль для SRP?
Ну и где iSER initiator для windows, ну к примеру?
Мы вроде говорили про HPC, да? А откуда Windows взялся? Если мне память не изменяет, его доля в этом сегменте стремится к нулю.
Я говорил про SRP, а это — сторадж-протокол.
А еще iSCSI — сторадж-протокол. Да и NFS-CIFS туда же (пусть они и несколько более высокоуровневые). И?
Вы еще скажите «на Android нету iSER инициатора».

Надо ли говорить, что процент HPC кластеров с ethernet интерконнектами несравнимо выше процента HPC кластеров с виндой?
Если смотреть на первые 100 из supercomputers top500, то внезапно выяснится что
1) на 10GbE интерконнекте там только один №72
2) а на винде — полтора, один Linux/Windows, второй — Windows.

MS на этот рынок очень хочет, даже Win2008 Server HPC Edition выпустила.

Но быстрый сторадж — это другая история, не обязательно HPC
на 10GbE интерконнекте там только один №72

И почти половина — на 1GbE? И ведь хватает же…
MS на этот рынок очень хочет, даже Win2008 Server HPC Edition выпустила.

Она им когда-то владела.
Но быстрый сторадж

Обычно в случае стораджа никто не гонится даже за микросекундами, потому что латентность стор измеряется в миллисекундах…
Латентность стораджа определяется латентностью кэша.
И почти половина — на 1GbE? И ведь хватает же…

В первой сотне top500 только одна машина с номером 61 обладает 1GE интерконнектом. Не считая номера 72 у всех остальных либо IB либо проприетарные интерконнекты.

Если же взять весь топ500, то машины с гигабитным интерконнектом дают всего 13% от суммарной производительности, те это уже старые и низкопроизводительные машины.
Номер 61, кстати, выделяется на общем фоне крайне отвратительным отношением Rmax/Rpeak

С нормальным интерконнектом была бы в первых 25.
Вот пишут трудящиеся, кстати:

Q: Can iWARP be faster than InfiniBand?

No. iWARP is a very complex solution for bringing RDMA capability to Ethernet. iWARP is really RDMAP over DDP over MPA over TCP, and this complexity is the reason for the higher CPU overhead and higher latency (6-10usec) when compared to InfiniBand.
Есть сетевухи, оффлоадящие это дело с CPU.
И какая получается латентность в результате?
Без понятия. Но:

Measurements have shown that the SCST SRP target has a lower latency and a higher bandwidth than the STGT iSER target. This is probably because the RDMA communication overhead is lower for a component implemented in the Linux kernel than for a user space Linux process, and not because of protocol differences.

То есть дело все-таки не в оверхедах самих протоколов?
Дело именно в оверхедах, о которых я говорил с самого начала — на упаковку-распаковку layered-данных. На гигабайтных скоростях они внезапно оказываются заметными.

И, собственно, в IB protocol stack уже вложили кучу усилий по удалению этих оверхедов, а в etherned — еще нет. Это не считая того смешного факта, что тот же iWARP/iSER реализован для линукса в рамках инфинибендовского стека OpenFabrics (возможно, есть и другие реализации, конечно)
Дело именно в оверхедах, о которых я говорил с самого начала — на упаковку-распаковку layered-данных.

А я говорю, что дело именно в том, что драйвер работает в юзерспейсе, а оверхедов никаких нет.
На гигабайтных скоростях они внезапно оказываются заметными.

Современный сервер способен прокачать через себя более 20гб/с, осуществляя DPI анализ каждого пакета.
А гигабитные скорости — это ничто.
Реальность получается простая. На сегодня Ethernet банально «хуже и дороже», даже в тех случаях, когда с серверной стороны одинаковые карты IB/Eth40G.
Латентность больше, полоса меньше, low latency свитчи — дороже чем IB-шные и не обеспечивают всей функциональности (вроде получения топологии стандартным путем прямо из драйвера).

При этом, конечно, IB — ad hoc решение и при прочих равных лично я бы предпочел бы ethernet, но прочих равных — в приложениях чувствительных и к BW и к latency просто нет.

Понятно, когда-нибудь сделают (хотя даже 10% в latency — может быть серьезной разницей), вот тогда и приходите.

P.S. Читайте на что отвечаете — внимательнее. Я писал про гигабайтные скорости, а вы мне ответили про гигабитные.

На одном и том же железе SRP работает значительно быстрее на коротких транзакциях, чем iSCSI поверх IPoIB.
Лично тестировал: blog.lexa.ru/2012/09/02/domashnii_storadzhboks_proizvoditelnost_iscsisrp_freebsdlinux.html

Бенчмарка под мои нужды, возможно что при другом паттерне разница в скорости не такая большая.
Это на старом 10G IB, по 23 бакса за карту. И это железо сегодня никому нахрен не нужно, оттого оно дешевле 10G ether чуть не на порядок :)
Результаты там действительно крайне странные, и я бы сказал — не вполне достоверные. Особенно учитывая IPoIB — надо бы сравнивать с нативным езернетом.

Недавно писали, как правильно тестировать диски/сторы: habrahabr.ru/post/154235/
Они достоверные, в том смысле что воспроизводятся.
Другой вопрос, что там метрика — интересная лично мне т.к. я делал сторадж для рабочей станции, а это — один поток I/O в интерактивной программе. К энтерпрайз-стораджу она не имеет отношения.

Претензии же ваши к IPoIB непонятны — вы же сами писали выше:
«Современные ЦП тратят абсолютно мизерные ресурсы на сворачивание-разворачивание пакетов „
Only those users with full accounts are able to leave comments. Log in, please.