Comments 49
мс — это миллисекунды, а речь идет о микросекундах, верно?
Меланокс и Ethernet умеет ускорять: показывали мне тесты с «пингами», 9.5 мкс на 40G карточках, кажется без свитча. После подмены стандартных сокетов на «волшебные» через LD_PRELOAD получается 1.5 мкс, при этом всем tcp/ip стеком стала заниматься сетевушка. То есть на каждой машине убрали по 4 мкс накладных расходов.
6-7 миллисекунд latency – это лучшие результаты, которые они достигли путем апгрейда серверов и максимальной софтверной доработкой
К черту сервера. Назовите конкретные модели задействованных коммутаторов (если есть опции вроде DFC и тому подобного, то и их назовите) и трансиверов.
Современные low-latency ethernet свитчи дают задержку аж до 200мкс. Без всяких особенностей конфигурирования, тоже «воткнул и поехали».
Пока же я вижу статью про «взяли дешевый store-and-forward ширпотреб и ВНЕЗАПНО не смогли получить latency как на IB железке».
На момент тестирования у заказчика использовались коммутаторы ядра Cisco серии 6500 с агрегированными 10G линками. Настройка оборудования была проведена с учетом всех рекомендаций вендора с целью снижения возможных задержек.
О том и речь. Cat6500 дает около 8мкс задержки даже с DFC. Он не ориентирован на низкую задержку. Это вообще сильно устаревшая платформа, даже с Sup2T и его PFC4.
Как я уже писал выше (с ошибкой конечно, 200нс вместо 200мкс), есть и специализированное железо. Например, Cisco Nexus 3000. Есть что-то от Arista. От других тоже есть. Но вы выбрали худших из всех вариантов — модульный коммутатор, не предназначенный для работы в таких условиях. Разумеется, он будет работать медленнее всех.
Вы сейчас сравниваете, условно, какой-нибудь бодрый седан от Audi с хачбеком автоВАЗа и на этом основании говорите, что седаны — самые быстрые автомобили. Мне такое сравнение кажется диким. Выберите нормального конкурента и уже с ним гоняйтесь. Увидите, что разница будет где-то в районе статистической погрешности, ну может чуть выше.
Как я уже писал выше (с ошибкой конечно, 200нс вместо 200мкс), есть и специализированное железо. Например, Cisco Nexus 3000. Есть что-то от Arista. От других тоже есть. Но вы выбрали худших из всех вариантов — модульный коммутатор, не предназначенный для работы в таких условиях. Разумеется, он будет работать медленнее всех.
Вы сейчас сравниваете, условно, какой-нибудь бодрый седан от Audi с хачбеком автоВАЗа и на этом основании говорите, что седаны — самые быстрые автомобили. Мне такое сравнение кажется диким. Выберите нормального конкурента и уже с ним гоняйтесь. Увидите, что разница будет где-то в районе статистической погрешности, ну может чуть выше.
Во-первых: мы ничего не выбирали для сравнения. У заказчика была определенная существующая инфраструктура. Во-вторых: IB может делать то, что может решаться и с помощью Ethernet, но экономичнее и быстрее. По большей степени получилось про то как «быстрее».
Но можно посчитать и экономику. Например посчитать разницу в стоимости установки новых Nexus вместо 6500, и стоимость Mellanox sx6025 без замены 6500. Поймите, дело не в сравнении двух железок. Говориться о подборе оптимального решения. В это и есть главная роль системного интегратора — подобрать оптимальное.
Теперь если совсем абстрагироваться от железа и говорить о том «кто же самый быстрый» — то IB превосходит Ethernet по скорости передачи данных как технология. Только в описанном случае этот параметр совершенно не интересовал заказчика, так как по этому критерию у него не было проблем.
Но можно посчитать и экономику. Например посчитать разницу в стоимости установки новых Nexus вместо 6500, и стоимость Mellanox sx6025 без замены 6500. Поймите, дело не в сравнении двух железок. Говориться о подборе оптимального решения. В это и есть главная роль системного интегратора — подобрать оптимальное.
Теперь если совсем абстрагироваться от железа и говорить о том «кто же самый быстрый» — то IB превосходит Ethernet по скорости передачи данных как технология. Только в описанном случае этот параметр совершенно не интересовал заказчика, так как по этому критерию у него не было проблем.
IB может делать то, что может решаться и с помощью Ethernet, но экономичнее и быстрее
Что может быть быстрее, чем распаковать новый свитч, смонтировать его и переключить уже имеющиеся сервера в него, не меняя никакой конфигурации и обходясь без лишних глючных драйверов, а также без переучивания сетевиков, серверных админов и прочих под новую технологию?
Про стоимости не знаю. Надо сравнивать. Но нексусы 3к недорогие.
Например посчитать разницу в стоимости установки новых Nexus вместо 6500
Вы уж определитесь: то ли вы заменяете имеющуюся инфраструктуру, то ли дополняете. Нексусы можно точно так же поставить рядом с шеститонниками, как и IB свитчи. Пусть между собой сервера общаются через быстрые нексусы/аристы/что угодно, а с внешним миром — через старые добрые каталисты. Кстати, несмотря на все QoSы, отделить один трафик от другого в любом случае неплохая идея.
Есть огромные 7k, заменяющие собой cat6500. А нексусы 3k — обычные мелкие немодульные железки на фиксированное количество портов, пара юнитов в высоту.
В это и есть главная роль системного интегратора — подобрать оптимальное.
Где-то я уже видел такой подход. «Начал притормаживать компьютер => покупаем новый компьютер» или хотя бы «переустанавливаем ОС», когда достаточно почистить автозагрузку и максимум накинуть плашку памяти. Прыжок с IPoE на IPoIB довольно радикален. А читая описанные в статье причины для этого действия, на ум приходит только одно объяснение: некомпетентность инженеров Крока, не понимающих, что и ethernet свитчи бывают устроены по-разному, и не надо брать трактор для участия в гонке суперкаров.
Про «быстрее». Скорость — это то, какую коробку можно более быстро распаковать, а с какой технологией приложение будет в итоге работать быстрее. Предполагаю, что вы недооцениваете трудозатраты и сложность процесса по замене коммутаторов уровня ядра, обслуживающих более 1000 рабочих мест и более 20 серверов оказывающих непрерывные сервисы. По обучению персонала. Тема в целом правильная, но в случае с IB абсолютно безболезненная, так как сетевик уровня CCNA «поднимет» IB сеть за несколько часов просто следуя технической документации, а для серверных админов — это вообще не новая технология и с точки зрения управления сервером ничего концептуально нового или сложного с внедрением IB вообще не происходит.
Про замену или дополнение. Мы то как раз сразу определились что заменять работающую и в целом удовлетворяющую систему не нужно, а нужно ее дополнить. Можно ли было дополнить Nexusами — да можно, но сложнее, более затратнее, еще более усложнит IP cеть и как следствии удорожит и усложнит дальнейшую эксплуатацию и снизит надежность.
Про «Начал притормаживать компьютер => покупаем новый компьютер» — в данном случае наши специалисты вместо того чтобы «продать новый компьютер» (новый Nexus), рекомендовали рассмотреть IB как бюджетную альтернативу решающую конкретно взятую задачу. Здесь уместно следующее сравнение: представим что у человека есть кухонный комбайн, но вот мясорубка в нем его не устраивает (например, не хватает мощности вращения шкива). По-вашему выходит, что правильнее всего было продать новый комбайн последнего поколения с большей мощностью двигателя. А мы сознательно, т. е. зная весь ассортимент бытовой техники от всех ведущих производителей, предложили купить отдельно новую мясорубку. С точки зрения прибыли, я полностью согласен с вами — надо было продавать новый комбайн (Nexus). Но у нас другой подход к нашим заказчикам.
Про замену или дополнение. Мы то как раз сразу определились что заменять работающую и в целом удовлетворяющую систему не нужно, а нужно ее дополнить. Можно ли было дополнить Nexusами — да можно, но сложнее, более затратнее, еще более усложнит IP cеть и как следствии удорожит и усложнит дальнейшую эксплуатацию и снизит надежность.
Про «Начал притормаживать компьютер => покупаем новый компьютер» — в данном случае наши специалисты вместо того чтобы «продать новый компьютер» (новый Nexus), рекомендовали рассмотреть IB как бюджетную альтернативу решающую конкретно взятую задачу. Здесь уместно следующее сравнение: представим что у человека есть кухонный комбайн, но вот мясорубка в нем его не устраивает (например, не хватает мощности вращения шкива). По-вашему выходит, что правильнее всего было продать новый комбайн последнего поколения с большей мощностью двигателя. А мы сознательно, т. е. зная весь ассортимент бытовой техники от всех ведущих производителей, предложили купить отдельно новую мясорубку. С точки зрения прибыли, я полностью согласен с вами — надо было продавать новый комбайн (Nexus). Но у нас другой подход к нашим заказчикам.
А при чём здесь 1000 рабочих мест и более 20 серверов? Вы к ним всем протянули InfiniBand?
Из статьи выходит что только между несколькими серверами, а остальное осталось по старому.
Из статьи выходит что только между несколькими серверами, а остальное осталось по старому.
При данных масштабах трогать работающее ядро – крайне нежелательно. И с помощью IB был проработан вариант допсегмента сети без какого-либо изменения действующей сети.
«1000 рабочих мест и более 20 серверов» и «при тех масштабах» как-то плохо сочетаются. Обычная средних размеров сеть. Если клиенты доверили все одному центральному шеститоннику даже с двумя супами — сами дураки, ни о какой надежности и речи не идет.
Так все-таки в чем проблема устроить допсегмент сети на базе ethernet, без связанной с IB головной боли, без изменения конфигурации mission critical систем (а именно таковыми и являются те сервера)?
Так все-таки в чем проблема устроить допсегмент сети на базе ethernet, без связанной с IB головной боли, без изменения конфигурации mission critical систем (а именно таковыми и являются те сервера)?
сложность процесса по замене коммутаторов уровня ядра
Никто не предлагает заменять это:
, если в остальном они устраивают.
Но можно подключить все сервера, требующие экстремально низкого latency, к чему-нибудь из этого:
Неужели это настолько сложная мысль? :)
сетевик уровня CCNA «поднимет» IB сеть за несколько часов просто следуя технической документации
Поднять проще всего. А вот когда рано или поздно что-то сломается — что он будет делать? И внезапно авария, которая в случае традиционного IPoE чинится за 2-3 минуты, затянется на те самые упомянутые вами «максимум 4 часа» — пока тот CCNA будет судорожно копаться в доках и выяснять, что пошло не так.
а для серверных админов — это вообще не новая технология и с точки зрения управления сервером ничего концептуально нового или сложного с внедрением IB вообще не происходит.
А вот к примеру ниже пишут, что дрова глючные… Причем пишут в основном те самые серверные админы.
более затратнее
Скажите, сколько стоили IB свитчи, а также трансиверы и прочее.
Кроме того: контора, поднимающая 10G на 6500, является достаточно богатой, чтобы влегкую купить любое сетевое оборудование за 5-значные цифры, выбирая не по цене, а по качеству и потребностям. Ибо у 6500 абсолютно безумная и неоправданная стоимость 10G порта.
А ведь есть и такие железки, которые обходятся уже гораздо дешевле, чем ваше IB оборудование. И с точки зрения задач заказчика они тоже однозначно лучше.
еще более усложнит IP cеть
Чем конкретно установка отдельного L2 свитча (то есть, разумеется, двух свитчей) усложнит IP сеть?
и как следствии удорожит и усложнит дальнейшую эксплуатацию и снизит надежность.
Напоминаю: речь идет про дешевый, всем с пеленок знакомый IPoE. Теперь он очень дорогой в обслуживании и сложный. А IB, от которого чуть ниже писали, вообще бесплатен, знания по его поддержке автоматически загружаются в мозг каждого homo sapiens при рождении, и он никогда не глючит.
Нда…
в данном случае наши специалисты вместо того чтобы «продать новый компьютер» (новый Nexus), рекомендовали рассмотреть IB как бюджетную альтернативу решающую конкретно взятую задачу.
Ну то есть как писали ниже — «побыстрее продать, а дальше пусть клиент сам разбирается».
Так почему же не было тестирования не менее бюджетных low-latency ethernet свитчей на целевых задачах? А вдруг они справятся лучше, чем IB, и вдобавок под них не придется производить крайне трудоемкие и рискованные изменения на критических серверах? Стоимость и упомянутого шеститонника — ничто по сравнению с ущербом подобной организации от 30-минутного простоя посреди дня.
Это и есть некомпетентность интегратора. Полное игнорирование задач клиента, отключение мозга, бездумное следование алгоритму «нужна низкая задержка => не глядя впариваем IB, ничто иное нас не волнует». То, что в итоге IB обойдется клиенту намного дороже и в закупке, и в сопровождении — не ваша проблема, да :)
Для протокола.
24-портовый свитч с 500нс задержкой: тут.
Упомянутый вами Mellanox sx6025 тут.
Оба новые, не refurbished, не б/у.
Докидываем стоимость сетевых карт IB (ethernet уже есть), трансиверов (ethernet уже есть) и получаем, что поставить ethernet свитч, полностью решающий задачу заказчика, не требующий дополнительного обучения и не грозящий компании сильными потрясениями в ближайшем будущем в связи с радикальным изменением задействованного L2 протокола, стоит дешевле.
24-портовый свитч с 500нс задержкой: тут.
Упомянутый вами Mellanox sx6025 тут.
Оба новые, не refurbished, не б/у.
Докидываем стоимость сетевых карт IB (ethernet уже есть), трансиверов (ethernet уже есть) и получаем, что поставить ethernet свитч, полностью решающий задачу заказчика, не требующий дополнительного обучения и не грозящий компании сильными потрясениями в ближайшем будущем в связи с радикальным изменением задействованного L2 протокола, стоит дешевле.
Но если возможности есть необходимость оставить текущую инфраструктуру (причин на это может быть миллион) и необходимо построить параллельную low-latency сеть, то IB от Mellanox + IB кабели + IB карточки на круг может выйти раза в 2 дешевле, чем Arista + трансиверы + карточки. Это я так, совсем приблизительно считаю, КРОКу виднее на счёт цен. При этом 56G IB против 10G ethernet.
«Arista + трансиверы + карточки» выйдет дешевле, потому что карточки и трансиверы уже есть, и даже оптика уже проложена. Достаточно поставить новые свитчи, провести за пару минут базовую конфигурацию вида «два порта транк, остальные аксесс» и переткнуть в них сервера. Как я уже говорил, затраты на поддержку такого решения тоже радикально ниже, чем затраты на поддержку двух совершенно разных сетей. Не верите — спросите тех, кто работает с FC и ethernet сетями, которые тоже традиционно изолированы друг от друга (хотя в последнее время есть мода на инкапсуляцию FC в ethernet).
Тут писали, что про «56G» пи**еж и провокация, реально оно даже медленнее, чем 10G езернет. И кстати — почему в топике не было результата прожига iperf'ом? Вот уж где самый маркетинг: показать, что можно на практике выжать много десятков гигабит за копейки!
Тут писали, что про «56G» пи**еж и провокация, реально оно даже медленнее, чем 10G езернет. И кстати — почему в топике не было результата прожига iperf'ом? Вот уж где самый маркетинг: показать, что можно на практике выжать много десятков гигабит за копейки!
Я же говорю, возможен случай, когда надо строить параллельную сеть. Или когда есть только 1G и надо что-то с низкими задержками.
Мы пока в продакшене ничего меланоксовского не используем, только пробуем щупать, и пока о парнях из меланокса положительное мнение. + у них есть интересные ethernet карточки.
Контрдовод к тому, что меланокс фигня: windows azure построен на их карточках. Кажется, фейсбук тоже закупает их ящиками.
Мы пока в продакшене ничего меланоксовского не используем, только пробуем щупать, и пока о парнях из меланокса положительное мнение. + у них есть интересные ethernet карточки.
Контрдовод к тому, что меланокс фигня: windows azure построен на их карточках. Кажется, фейсбук тоже закупает их ящиками.
Или когда есть только 1G и надо что-то с низкими задержками.
На этот случай есть свои low-latency свитчи. Правда, тут уже время пакетизации может быть нехорошим.
у них есть интересные ethernet карточки
Что-то мне подсказывает, что комбинированные ethernet/IB карты будут либо говном, либо гораздо дороже, чем просто ethernet карты на ту же скорость.
Контрдовод к тому, что меланокс фигня
Это не контрдовод. Может, они драйвера и даже прошивки сетевых карт сами пишут? Мы-то не знаем. Разумеется, у таких компаний имеется собственный штат очень сильных разработчиков.
Вон гугл вообще сам проектирует себе ЦОДовые свитчи, беря лишь broadcom'овскую универсальную логику, сам пишет под них софт и оркестраторы. Это говорит о том, что те железки очень хорошо работают в условиях, специфичных для гугла. Про другие условия речи нет.
Впрочем, я не говорю, что меланокс фигня. Это говорят другие — те, кто с ними работал. Я не работал. Я лишь говорю, что в посте какая-то чушь написана, а инженеры крока, не знавшие о существовании специализированного ethernet железа, некомпетентны. Ведь рынок low-latency свитчей, где счет идет на сотни наносекунд, процветает, многие финансовые учреждения их ставят вместо того же IB. По той же причине, по которой многие предпочитают FCoE вместо раздельных FC и ethernet: две инфраструктуры зельмо дорого сопровождать.
А сходу предлагать клиенту IB, даже когда современного не-low latency свитча клиенту хватило бы (да, 6500-й очень устарел в этом плане, более новые железки дают минимум в два раза меньшую задержку), даже не вникнув в его потребности… Ладно бы счет шел на десятки наносекунд, но тут смело разбрасываются целыми микросекундами. Теряется малейший смысл ставить IB — дорого и глупо.
>Тут писали, что про «56G» пи**еж и провокация, реально оно даже медленнее, чем 10G езернет.
Уточню, что упомянутое ограничение касается только IPoIB. Если использовать IB по назначению, т.е. с RDMA, то все с производительностью нормально.
Уточню, что упомянутое ограничение касается только IPoIB. Если использовать IB по назначению, т.е. с RDMA, то все с производительностью нормально.
Да, примерно так, но были ещё факторы. Обновил топик, там более точное описание ситуации, чтобы было конкретно понятно, что именно за кейс был.
При этом технические специалисты заказчика решили сравнить IB со своим вариантом.
С каким именно вариантом? Как производилось сравнение? Почему у меня остается ощущение, что и заказчики, и ваши инженеры по причине собственной некомпетентности просто не знали про существование быстрых cut-through свитчей?
Мы провели тесты на площадке заказчика, а его специалисты подтвердили следующее
Какой-то болезненный бред по всем четырем пунктам. Особенно меня восторгает катастрофическая сложность обслуживания пары мелких свитчей с фиксированной конфигурацией. Вы серьезно?
Все-таки не позорьте собственный департамент, уберите эту глупость из топика: «Отстроить Ethernet-сеть с параметрами как у IB займёт в 3-4 раза больше времени в среднем. Скорость решения задач по восстановлению IB-сети – максимум 4 часа в любое время суток.»
Я читаю это, понимаю, что если перевести мою сеть ЦОДов на IB, то сетевые аварии будут устраняться по 4 часа, и меня прошибает холодный пот. А между тем, кто-то умудряется менее чем за час поднять отъехавший в полном составе периметр сети по десяткам ЦОДов.
А тут мы говорим про один-два мелких свитча. И меня очень раздражает подобная ахинея в топике системного интегратора, которому полагается быть компетентным, но который откровенно выставляет себя на посмешище.
Идеально было бы если написали полные модели и сразу же настройку оборудования (получилось бы информативно, может дополните?). Почему использовали SX6005 а не соединяли напрямую?
Специально для таких людей в новых ядрах реализованы TCP Small Queries, уменьшающие на порядки латенси сетевого стека. С учётом 500нс задержек в соответствующих ethernet-коммутаторах, думаю, можно было бы сравнить производительность (и итоговую стоимость).
А меланоксовские карточки на меня особого впечатления не произвели — сыроватые драйвера, практически не поддерживают стандартные возможности ethtools.
А меланоксовские карточки на меня особого впечатления не произвели — сыроватые драйвера, практически не поддерживают стандартные возможности ethtools.
Они не просто кривые, они еще и глючные.
Столкнулись с падением SRPT при подключении первого же клиента. При том не просто он сам падал, а всю систему вешал. Вердикт разработчиков был — кривые дрова мелланокса. Купили дешевые карточки от cisco (ака Topspin) на ebay и все заработало с пол-пинка. Мелланоксы до сих пор на полке пылятся.
Столкнулись с падением SRPT при подключении первого же клиента. При том не просто он сам падал, а всю систему вешал. Вердикт разработчиков был — кривые дрова мелланокса. Купили дешевые карточки от cisco (ака Topspin) на ebay и все заработало с пол-пинка. Мелланоксы до сих пор на полке пылятся.
Спасибо за информацию. Меня ихнее Catastrophic buffer error в dmesg'е при включенном debug'е давно веселило.
Лично у нас есть другое мнение, основанное на нашем собственном опыте эксплуатации IB в ЦОДе, который в частности обеспечивает работу «облака» в котором оказываются услуги нашим заказчиками.
У нас полностью позитивное отношение к данной технологии и производителю. Оборудование легко запустилось, и уже довольно долго полет нормальный. Если наша команда может кому-то помочь с настройкой/эксплуатацией имеющегося оборудования Mellanox — пишите в личку. У нас также есть возможность привлекать к решению серьёзных кейсов непосредственно специалистов вендора.
У нас полностью позитивное отношение к данной технологии и производителю. Оборудование легко запустилось, и уже довольно долго полет нормальный. Если наша команда может кому-то помочь с настройкой/эксплуатацией имеющегося оборудования Mellanox — пишите в личку. У нас также есть возможность привлекать к решению серьёзных кейсов непосредственно специалистов вендора.
Ну, давайте я задам простой вопрос: как управлять карточкой посредством стандартных интерфейсов в ethtool? У интела это всё вылизано до невозможности — и они постили десятки и сотни коммитов в соответствующие утилиты. Почему этого же нет у меланокса?
Ок. Тогда домашнее задание. Берем две машины, в обе ставим IB-карты Mellanox (точнее говоря достаточно только на target). Ставим с одной стороны OFED+SCST, с другой используем стандартный SRP initiator из OFED. Запускаем target, все работает, запускаем initiator, target падает в кору. Можете еще для разнообразия разные дистрибутивы попробовать и разные версии OFED. Начнете копать дамп — увидите, что валится драйвер Mellanox.
Я конечно не исключаю, что все уже починили, но года полтора или два назад, она еще была.
Это странно… Большая часть TOP500 суперкомпьютеров крутятся на Linux'е. По идее эти дрова должны вылизаны и блестеть как…
Это как сравнивать легковой автомобиль с танком: один удобный и быстрый, а на втором можно съездить в Европу.
Это вы 45 лет пражской весны так отмечаете?
Это вы 45 лет пражской весны так отмечаете?
Надеюсь, старшие товарищи поправят если я вру.
Главный плюс infiniband достигается не так. IPoIB позволяет пускать знакомый всем IP, но это дополнительная опция а не основной метод использования. IB позволяет приложениям обмениваться сообщениями не взаимодействуя со сторонними приложениями и ОС. Если переписать суперважное приложение заказчиков для работы с IB на прямую, то задержки могут снизиться еще сильнее
Главный плюс infiniband достигается не так. IPoIB позволяет пускать знакомый всем IP, но это дополнительная опция а не основной метод использования. IB позволяет приложениям обмениваться сообщениями не взаимодействуя со сторонними приложениями и ОС. Если переписать суперважное приложение заказчиков для работы с IB на прямую, то задержки могут снизиться еще сильнее
Большинство интеграторов такой «фигней» не занимаются. Их основная задача — впарить как можно быстрее программно-аппаратный комплекс, настроить что-бы все вместе хоть как-то работало (обычно через одно место) и бежать следующих окучивать.
Может у нас и не все такие, но всех российских интеграторов, что я видел, работают именно так.
Может у нас и не все такие, но всех российских интеграторов, что я видел, работают именно так.
Более того, у IPoIB существует довольно низкое ограничение на пропускную способность (по сравнению с полной полезной пропускной способностью интерфейса). Для года 2-3 назад с 40G интерфейсами и современными на тот момент ЦП, насколько я помню, это были ~2G в datagram mode и ~9G в connected mode (и то, это при достаточно большом MTU).
А не сравнивали производительность IPoIB против IB RDMA? Сильно ли растет задержка с ростом числа хопов между хостами?
Многие считают, что InfiniBand — это «космос».
Не правда. InfiniBand используется даже в бюджетных гос. учреждениях. Например для доступа к дисковому хранилищу для виртуалок. Как было написано в статье можно и на ethernet но уже дороже и сложнее.
Не правда. InfiniBand используется даже в бюджетных гос. учреждениях. Например для доступа к дисковому хранилищу для виртуалок. Как было написано в статье можно и на ethernet но уже дороже и сложнее.
Ну, это не «космос» давно уже. Но как и космос — к реальной жизни прикладывается довольно мало и редко :-}
Используем как раз в бюджетном и как раз для доступа к системе хранения одного из пула виртуалок. Лучше бы не использовали. Пусть уж лучше чуть более дорогой, но старый, добрый, надежный и проверенный годами FC.
У IB все что связано с SRP/iSER выглядит написанным «на коленке» в стадии вечной беты :(
У IB все что связано с SRP/iSER выглядит написанным «на коленке» в стадии вечной беты :(
А ценник на Mellanox sx6025 вполне доступный — около $7000. Коммутатор cut-through близкой производительности будет стоит гораздо больше. Сетевые карты как я понимаю уже были в наличии, то предложенный интегральном вариант имеет право на жизнь.
А есть какие-то соображения, почему IBM отказался от поддержки Infiniband? В новые сервера линейки POWER, насколько я знаю, IB-карты заказать нельзя. И даже Netezza и PureScale (которые PureData) собраны на 10G Ethernet.
Это что, ревность к Ораклу? :)
Это что, ревность к Ораклу? :)
Если я правильно понял, то оба приложения построены на базе СУБД Oracle :-)?
Only those users with full accounts are able to leave comments. Log in, please.
Про InfiniBand: как мы уменьшали пинг с 7 мкс до 2,4 мкс (и результаты тестов)