1) А если обмены проходят по принципу все со всеми? Или четные с нечетными? А задача запущена на сотнях(тысячах) ядер, которые в один свич могут не влезть.
2) Вы описали типичнейший случай расчетной задачи, например, когда нужно получить рассчитанные данные о цифрах в соседних узлах сетки.
Ну это-же не решение поставленной существующей задачи? Это вообще общие слова.
При наличии переподписки, как все вышесказанное позволит мне обеспечить гарантию доставки и отсутствие перегрузки на уровне ethernet, если сервера о переподписке ничего не знают и захотят передавать на скорости порта?
Технически, ничто не мешает организовать ethernet сеть вообще без переподписки.
В идеале конечно да, но существующую то задачу это как решит, если инфраструктура уже есть?
ECMP можно как-нибудь прикрутить, когда источники трафика (сервера) по умолчанию ничего не знают друг о друге(и о топологии сети) и упираются в более узкий участок не ранее чем через один коммутатор? При этом если источник и приемник в одном коммутаторе, то они могут общаться на скорости порта не мешая другим.
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, но я говорю о предполагаемом будущем.
Кому не хватает агрегированных 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 и проприетарных решений.
Все это справедливо для классического ЦОДа, которому, если быть честным, сверхвысокая производительность всех компонент не критична.
InfiniBand — это больше область HPC и если смотреть на современные тенденции, то сейчас даже 10GE сети в этой области являются максимум вспомогательными или I/O сетями. Основные данные, где критична latency, критична надежность и предсказуемость доставки, критичны все специфические функции от атомарных операций до GPUDirect в основном ходят либо поверх InfiniBand, либо поверх проприетарных решений.
InfiniBand — это не только умная пересылалка пакетов, но и большое количество необходимой дополнительной функциональности, которую Ethernet просто не умеет.
От NFS уходят, а некоторые уже ушли к распределенным хранилищам, например, построенным при помощи GPFS, Lustre и т.д., так как пропускная способность хранилища данных суперкомпьютера — это достаточно больная тема и у классических хранилищ тут есть некоторые проблемы.
P.S. Из Enterprise решений с IB на ум приходит Oracle Exadata, так что даже в бизнес-сегменте не все так гладко с Ethernet.
Скажите пожалуйста, а возможно-ли связывать по InfiniBand разнесенные на большие расстояния площадки и будут ли у IB какие-либо преимущества в этом случае по сравнению, например, с 10/40 GE?
И есть ли вообще примеры(опыт) внедрения InfiniBand-сетей между датацентрами?
Вынужден внести важное уточнение.
В эту сумму входят и наши сервисы. Мы не разделяем интернет и «внутренние» сервисы, когда считаем потребление трафика пользователями.
У нас правда есть свои линии связи, что несколько упрощает задачу по передаче данных.
С точки зрения безопасности да, согласен.
В случае большинства сотрудников это не имеет отношения к действительности.
Ну я же говорил, что мыслить нужно шире и обязательно в контексте интересов работодателя! Мы не банк. Мы Research и R&D и у нас это имеет отношение к большинству сотрудников…
20 человек на 2Мбита — это примерно 0,1Мбит/с на человека. У нас при полностью открытом интернете в среднем получается 0,15Мбит/с на человека (пиками иногда бывает до 0.3Мбит/с на человека). И выборка у нас на порядок больше для расчета среднего потребления трафика.
Так что да, можем и не такое представить при полностью открытом интернете.
Может, кому-то это покажется странным, но, вообще говоря, рабочее время сотрудника принадлежит работодателю, а свободное рабочее время стоит тратить на что-то потенциально полезное работодателю… Не?
Золотые слова! Только мыслить нужно шире, так как даже ютуб может оказаться полезным работодателю. Например, видео с многих зарубежных конференций и публичных лекций часто размещается именно на нем.
Энергопотребление растет. Ни одного прецедента существенного падения энергопотребления нашей цивилизацией на текущий момент не было. Это позволяет предположить, что для развития цивилизации и для ее экспансии хотя-бы в ближний космос потребуется все больше энергии. Никто же не говорит, что вся аккумулируемая энергия должна передаваться на одну планету.
ГЭС кстати не самые мощные электростанции да и на климат и экосистему они влияют гораздо сильнее, чем модное нынче глобальное потепление.
Энергия ветра и воды — это тоже последствия попадания на Землю солнечной энергии. И собирая «первичную» энергию, возможно, можно собрать ее больше, чем получая энергию из «вторичных» источников.
Если в доме штатная электроплита, то как минимум с 80-х годов заземление должно быть в щитке и должно быть проложено до электроплиты в штатной проводке.
Естественные языки допускают многозначность, но все-же отсутствие словосочетания «хотя-бы раз» меняет задачу коренным образом.
По этому за резкость я извиняюсь, действительно перегнул палку, Но претензия к некорректной постановке задачи с некорректными выводами все равно остается.
Тем не менее если бросить 100 раз монетку, шансы получить орла выше, чем после одного раза
Шансы получить орла НИКАК не зависят от числа бросков. Шансы хотя-бы раз получить орла от числа бросков зависят. Я считаю, что нужно точнее формулировать примеры.
Сейчас согласен.
Если Вы изначально имели ввиду, вероятность, что выстрелит хотя-бы 1 из 100, то да. Эта вероятность с ростом числа попыток растет как 1-(вероятность провала одного)^N.
Чуть выше maxshopen подробно расписал, как понял Вас я, и что Вы на самом деле хотели сказать, но сказали очень расплывчато.
Ок.
1-й раз P_орел = 0.5
2-й раз P_орел = 0.5
…
100-й раз P_орел = 0.5
Каким образом число бросков влияет на вероятность выпадения орла в последующем броске?
Какова вероятность выпадения орла в 100 испытаниях?
А это уже совсем другая история(задача). Если имеется ввиду, какова вероятность, что все 100 раз выпадет орел, то 0.5^100 или где-то примерно 10^-31 степени, что очень и очень мало.
Тем не менее если бросить 100 раз монетку, шансы получить орла выше, чем после одного раза. Если в каждом из стартапов вероятность успеха 10%, ты конечно можешь и с первого раза сделать успешный бизнес\стартапов, а можешь и с 100ого провалиться, но чем больше ты стараешься, работаешь, тем выше твои шансы.
Какой феерический бред необразованного человека!
Гуглите про зависимые и независимые события.
Бросания монетки классический пример независимых событий, где вероятность исхода в следующем эксперименте не зависит от предыдущих.
В случае бизнесов я возможно даже частично соглашусь, что опыт будет помогать, но вот вопрос о том, на какие деньги компенсировать убытки провалившихся бизнесов остается открытым.
P.S. Есть конечно способ «обмануть» теор.вер. для тех, кто его не знает, но в реальной жизни он мошенничеством зовется, с соответствующими моральными и юридическими последствиями
Раньше я думал не так, но сейчас пожалуй тоже поддержу мысль о собственной психологии.
Иномарку содержать может практически каждый, а найти и содержать в исправном и рабочем состоянии 20-и летний автомобиль уже нет.
Интересное наблюдение, но моя 20-и летняя волга в отличном состоянии вызывает гораздо больший интерес у уважаемых людей при встрече, чем 3,5летний среднеразмерный кроссовер (при этом по удельным эксплуатационным затратам Волга дороже кроссовера).
P.S. У меня правда бизнеса своего нет, может в этом все дело :)
2) Вы описали типичнейший случай расчетной задачи, например, когда нужно получить рассчитанные данные о цифрах в соседних узлах сетки.
Так бывает чуть менее чем всегда.
При наличии переподписки, как все вышесказанное позволит мне обеспечить гарантию доставки и отсутствие перегрузки на уровне ethernet, если сервера о переподписке ничего не знают и захотят передавать на скорости порта?
В идеале конечно да, но существующую то задачу это как решит, если инфраструктура уже есть?
А если его нет? Весь трафик критичен и лучше равномерно распределить пропускную способность, чем кого-либо двигать.
Это был не я. Но каюсь, грешен — увел разговор в свою область из области обычных ЦОДов.
Однако IB — это не только умная передача пакетов. А ничего из оставшегося ethernet на текущий момент не умеет (разве что кроме RDMA).
Мы говорим о том, что было или о том, что будет? Если о том что было, то логично, что в основной массе использовался менее функциональный Ethernet, когда IB не было или был дорог или использовался проприетарный интерконнект. Если говорить о том, что будет, то похоже, что в вершине top500 ethernet'у в ближайшей перспективе уготована роль вспомогательных сетей.
В СКС согласен потери как динозавры, но как универсально с вершины приложения и ОС гарантировано не перегрузить интерфейсы, включая промежуточные(например, если если вдруг все лезвия одной корзины ломануться к лезвиям соседней, а между корзинами линьков в 2 раза меньше)?
end-to-end — это от приложения к приложению через NIC и возможно коммутатор.
Чуть выше написано про «QDR switch chips have a latency of 100 nanoseconds.».
Если сравнивать end-to-end, то нужно к латенси коммутатора прибавить задержки в двух сетевых картах и в драйверах.
Не совсем. Если у абстрактного Иванова И.И. скорость доступа к ютубу упала раз в 100, то это скажется на остальных, абстрактных Петровых И Сидоровых? Нет, не скажется, по этому задача гугла в том, чтобы у основной массы грузились «мгновенно». Им не критично, если будут отстающие, так как задачи отдачи котиков с ютуба пользователям независимы.
Ну мы-же здесь про top-level задачи рассуждаем?
По причине сильной связности решаемых задач. Требуется постоянно учитывать, что насчитали соседние узлы и в этом случае неравномерность отклика сильно портит всю картину.
В прошлом да по массовости IB относительно недавно уступал Eth, но я говорю о предполагаемом будущем.
А 40 и 100 G порт уже можно поставить в один сервер? Я таких решений пока не видел, а IB есть уже здесь и сейчас.
Ставлю на InfiniBand и проприетарные решения. По крайней мере мне не известно о том, чтобы кто-нибудь пытался создавать основную коммуникационную сеть на базе Ethernet.
Беглый взгляд в вики, говорит, что IB дает раза в 2 меньшее латенси. Под надежностью я имел ввиду такие сервисы как Reliable Connection, Reliable Datagram. 1 или 2 хопа — для задачи могут отличаться Очень сильно…
Есть RFC по передаче IP пакетов методом голубиной почты ;)
А у гугла нет адских требований к инфраструктуре. Гугл и ко берут масштабом, а не требованиями. Посмотрите, например, на суть предложенного гуглом MapReduce. Им не критична скорость отклика системы, не нужно постоянно быстро обмениваться данными между всеми компонентами системы одновременно. Если посмотреть внимательно на архитектуру, то можно увидеть что она достаточно слабо связана, так как задачи гугла можно разбивать на много маленьких, практически не зависимых подзадач.
В этом случае проблему масштабности можно решать софтварно.
Но есть и другой полюс, где задачи сильно связаны, требуется постоянный обмен данными и огромные вычислительные мощности. Тут уже возникают действительно адские требования к коммуникационной инфраструктуре. Один или два хопа, могут быть узким местом в производительности всей системы, а не некоторого локального участка. — Это мир HPC, где сейчас не видно конкурентов для IB и проприетарных решений.
InfiniBand — это больше область HPC и если смотреть на современные тенденции, то сейчас даже 10GE сети в этой области являются максимум вспомогательными или I/O сетями. Основные данные, где критична latency, критична надежность и предсказуемость доставки, критичны все специфические функции от атомарных операций до GPUDirect в основном ходят либо поверх InfiniBand, либо поверх проприетарных решений.
InfiniBand — это не только умная пересылалка пакетов, но и большое количество необходимой дополнительной функциональности, которую Ethernet просто не умеет.
От NFS уходят, а некоторые уже ушли к распределенным хранилищам, например, построенным при помощи GPFS, Lustre и т.д., так как пропускная способность хранилища данных суперкомпьютера — это достаточно больная тема и у классических хранилищ тут есть некоторые проблемы.
P.S. Из Enterprise решений с IB на ум приходит Oracle Exadata, так что даже в бизнес-сегменте не все так гладко с Ethernet.
И есть ли вообще примеры(опыт) внедрения InfiniBand-сетей между датацентрами?
Вынужден внести важное уточнение.
В эту сумму входят и наши сервисы. Мы не разделяем интернет и «внутренние» сервисы, когда считаем потребление трафика пользователями.
У нас правда есть свои линии связи, что несколько упрощает задачу по передаче данных.
С точки зрения безопасности да, согласен.
Ну я же говорил, что мыслить нужно шире и обязательно в контексте интересов работодателя! Мы не банк. Мы Research и R&D и у нас это имеет отношение к большинству сотрудников…
Так что да, можем и не такое представить при полностью открытом интернете.
Золотые слова! Только мыслить нужно шире, так как даже ютуб может оказаться полезным работодателю. Например, видео с многих зарубежных конференций и публичных лекций часто размещается именно на нем.
ГЭС кстати не самые мощные электростанции да и на климат и экосистему они влияют гораздо сильнее, чем модное нынче глобальное потепление.
По этому за резкость я извиняюсь, действительно перегнул палку, Но претензия к некорректной постановке задачи с некорректными выводами все равно остается.
Шансы получить орла НИКАК не зависят от числа бросков. Шансы хотя-бы раз получить орла от числа бросков зависят. Я считаю, что нужно точнее формулировать примеры.
Если Вы изначально имели ввиду, вероятность, что выстрелит хотя-бы 1 из 100, то да. Эта вероятность с ростом числа попыток растет как 1-(вероятность провала одного)^N.
Чуть выше maxshopen подробно расписал, как понял Вас я, и что Вы на самом деле хотели сказать, но сказали очень расплывчато.
1-й раз P_орел = 0.5
2-й раз P_орел = 0.5
…
100-й раз P_орел = 0.5
Каким образом число бросков влияет на вероятность выпадения орла в последующем броске?
А это уже совсем другая история(задача). Если имеется ввиду, какова вероятность, что все 100 раз выпадет орел, то 0.5^100 или где-то примерно 10^-31 степени, что очень и очень мало.
Какой феерический бред необразованного человека!
Гуглите про зависимые и независимые события.
Бросания монетки классический пример независимых событий, где вероятность исхода в следующем эксперименте не зависит от предыдущих.
В случае бизнесов я возможно даже частично соглашусь, что опыт будет помогать, но вот вопрос о том, на какие деньги компенсировать убытки провалившихся бизнесов остается открытым.
P.S. Есть конечно способ «обмануть» теор.вер. для тех, кто его не знает, но в реальной жизни он мошенничеством зовется, с соответствующими моральными и юридическими последствиями
Иномарку содержать может практически каждый, а найти и содержать в исправном и рабочем состоянии 20-и летний автомобиль уже нет.
Интересное наблюдение, но моя 20-и летняя волга в отличном состоянии вызывает гораздо больший интерес у уважаемых людей при встрече, чем 3,5летний среднеразмерный кроссовер (при этом по удельным эксплуатационным затратам Волга дороже кроссовера).
P.S. У меня правда бизнеса своего нет, может в этом все дело :)