Если бы все было так просто с пузомерками суперкомпьютеров…
Есть Top500, где тест LINPACK и ФЛОПСы, а есть Graph500, где меряют производительность обработки больших массивов данных.
Образно говоря, если в тесте LINPACK на процессорах можно обед готовить, а остальные подсистемы относительно разгружены, то в случае Graph500 процессор чуть ли не простаивает в то время как обед можно готовить на памяти и интерконнекте…
Внутричерепная говорите? А Вы в курсе, что внутричерепная гематома — это инсульт?
И несколько дней комы уже говорят о том, что после непосредственного повреждения головного мозга он нормальным практически гарантированно не будет? Нормальным в смысле без психических отклонений.
Все еще сомневаетесь в том, что не правы? Когда столкнетесь на практике, как выглядит небольшая внутричерепная гематома и к чему она может очень быстро привести совсем по другому запоете… Я бы даже сказал волком завоете…
Скажу честно, не знаю. Но для дома нужно смотреть ультразвуковые отпугиватели, так как вибрационные будут довольно бесполезны.
Мы в дачном доме отпугиватели ни разу не ставили, но благодаря конструкции мыши внутрь дома ни разу не проникали, судя по показаниям мышиного индикатора (хлеб оставленный на пленке на полу перед длительным отсутствием людей). Однако мы и зимой на выходные на дачу ездим.
Айтишник без оптоволокна в квартиру, пинга до яндекса в <30 мс
Да, качать какой-нибудь линукс на оптике в квартиру гораздо удобнее, чем по GPRS, но интернет на работе все-равно быстрее.
и двух/троекратного резервирования электропитания
Вот с этим то проще в на даче(в деревне). Во первых внешнее питание, которое идет по столбам. Во вторых 5кВт дизель-генератор, которого в случае дачи хватает (на жилой деревенский дом нужно ставить больше и капитальный, а не переносной с подходящем месте). И третий совсем резервный контур — это инвертор 12-220В, который дает возможность запитать ноутбуки-телефоны от машины, а в ней аккумулятор и минимум 20 литров солярки(меньший остаток топлива я допускаю только в городе, где на моих 10км до работы 5 заправок. На даче, где до ближайшей 20км минимум 20л в баке, а зимой минимум половина бака).
А вообще я работаю в лесу. И знаете, внешняя тишина благотворно сказывается на рабочий процесс, в отличие от постоянного шума центра города, где я живу.
а также без опции доставки жратвы на дом
А желудок после такой жратвы лечить долго придется?
Забыл добавить, что есть еще такая хорошая штука, как вибрационный отпугиватель грызунов и кротов — вытянутый цилиндр на батарейках, который закапывается в предварительно увлажненную землю для лучшей передачи вибрации и ультразвука. Батареек нормально хватает на сезон где-то с конца апреля по начало октября, на зиму девайс выкапывается для хранения.
Как показывает практика 10 соток дачи одной такой штуки хватает почти на всю площадь, но есть и ограничение — фундаменты гасят вибрации, по этому за фундаментами мышки иногда пробегают, но в прямой видимости устройства мыши не ходят и не гнездятся.
Проблему мышей в минвате можно минимизировать правильной конструкцией утепления. Большая проблема — это пчелы в оной. Последние очень легко прогрызают деревянную обшивку и щели и добираются до утеплителя, устраивая в нем соты. Выгонять проще всего зимой вырезая кусок утеплителя и проливая все щели монтажной пеной. Правда эти насекомые могут прогрызть доски и оболочку в другом месте.
Против мышей хорошо помогает полностью закрыть пространство с утеплителем, например упаковав утеплитель в оболочку из рубероида в стенах. Помимо этого в случае деревянного дома нижние венцы и нижний слой пола можно пропитать маслом, его мыши не любят.
В случае подвала опаснее крысы, а не мыши. Мыши в отличие от крыс не грызут бетон, по этому сквозь фундамент мышь не пойдет, а крыса может.
Если подвала нет, а фундамент не сильно заглублен, то мыши могут прокопаться под фундаментом, но тогда их должен остановить нижний пол.
Владельцы тойот, у которых электронная педаль газа приводила к неконтролируемому разгону, владельцы калин у которых электроусилитель выкручивал и заклинивал руль, а так-же все те люди, которые уже погибли или пострадали из-за подобных причин думаю будут с Вами не согласны…
P.S. Пьяные водители конечно зло, с которым обязательно нужно бороться, но Вы посмотрите ради интереса полную статистику ДТП. Вы очень сильно удивитесь, когда узнаете, как на самом деле распределяются виновники ДТП…
Так как сайт ГИБДД у меня не грузится, то я приведу ссылку на Автокадабру ( autokadabra.ru/shouts/39479 ), где детально, с цифрами правда показаны только 3 причины, но уж больно они неожиданные в количественном плане и полностью противоречат создаваемому сейчас информационному фону.
В первой сотне top500 только одна машина с номером 61 обладает 1GE интерконнектом. Не считая номера 72 у всех остальных либо IB либо проприетарные интерконнекты.
Если же взять весь топ500, то машины с гигабитным интерконнектом дают всего 13% от суммарной производительности, те это уже старые и низкопроизводительные машины.
Давайте почитаем вторую ссылку:
«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-случае все не так радужно. Но исследования в этой области действительно ведутся.
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 и у нас это имеет отношение к большинству сотрудников…
Есть Top500, где тест LINPACK и ФЛОПСы, а есть Graph500, где меряют производительность обработки больших массивов данных.
Образно говоря, если в тесте LINPACK на процессорах можно обед готовить, а остальные подсистемы относительно разгружены, то в случае Graph500 процессор чуть ли не простаивает в то время как обед можно готовить на памяти и интерконнекте…
А есть еще реальные задачи :)…
Внутричерепная говорите? А Вы в курсе, что внутричерепная гематома — это инсульт?
И несколько дней комы уже говорят о том, что после непосредственного повреждения головного мозга он нормальным практически гарантированно не будет? Нормальным в смысле без психических отклонений.
Все еще сомневаетесь в том, что не правы? Когда столкнетесь на практике, как выглядит небольшая внутричерепная гематома и к чему она может очень быстро привести совсем по другому запоете… Я бы даже сказал волком завоете…
Мы в дачном доме отпугиватели ни разу не ставили, но благодаря конструкции мыши внутрь дома ни разу не проникали, судя по показаниям мышиного индикатора (хлеб оставленный на пленке на полу перед длительным отсутствием людей). Однако мы и зимой на выходные на дачу ездим.
Да, качать какой-нибудь линукс на оптике в квартиру гораздо удобнее, чем по GPRS, но интернет на работе все-равно быстрее.
Вот с этим то проще в на даче(в деревне). Во первых внешнее питание, которое идет по столбам. Во вторых 5кВт дизель-генератор, которого в случае дачи хватает (на жилой деревенский дом нужно ставить больше и капитальный, а не переносной с подходящем месте). И третий совсем резервный контур — это инвертор 12-220В, который дает возможность запитать ноутбуки-телефоны от машины, а в ней аккумулятор и минимум 20 литров солярки(меньший остаток топлива я допускаю только в городе, где на моих 10км до работы 5 заправок. На даче, где до ближайшей 20км минимум 20л в баке, а зимой минимум половина бака).
А вообще я работаю в лесу. И знаете, внешняя тишина благотворно сказывается на рабочий процесс, в отличие от постоянного шума центра города, где я живу.
А желудок после такой жратвы лечить долго придется?
Как показывает практика 10 соток дачи одной такой штуки хватает почти на всю площадь, но есть и ограничение — фундаменты гасят вибрации, по этому за фундаментами мышки иногда пробегают, но в прямой видимости устройства мыши не ходят и не гнездятся.
Против мышей хорошо помогает полностью закрыть пространство с утеплителем, например упаковав утеплитель в оболочку из рубероида в стенах. Помимо этого в случае деревянного дома нижние венцы и нижний слой пола можно пропитать маслом, его мыши не любят.
В случае подвала опаснее крысы, а не мыши. Мыши в отличие от крыс не грызут бетон, по этому сквозь фундамент мышь не пойдет, а крыса может.
Если подвала нет, а фундамент не сильно заглублен, то мыши могут прокопаться под фундаментом, но тогда их должен остановить нижний пол.
P.S. Пьяные водители конечно зло, с которым обязательно нужно бороться, но Вы посмотрите ради интереса полную статистику ДТП. Вы очень сильно удивитесь, когда узнаете, как на самом деле распределяются виновники ДТП…
Так как сайт ГИБДД у меня не грузится, то я приведу ссылку на Автокадабру ( autokadabra.ru/shouts/39479 ), где детально, с цифрами правда показаны только 3 причины, но уж больно они неожиданные в количественном плане и полностью противоречат создаваемому сейчас информационному фону.
В первой сотне top500 только одна машина с номером 61 обладает 1GE интерконнектом. Не считая номера 72 у всех остальных либо IB либо проприетарные интерконнекты.
Если же взять весь топ500, то машины с гигабитным интерконнектом дают всего 13% от суммарной производительности, те это уже старые и низкопроизводительные машины.
А через пару часов одни задачи досчитаются, другие запустятся и профиль трафика изменится.
«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-случае все не так радужно. Но исследования в этой области действительно ведутся.
Напишите пожалуйста, какой вендор поставляет готовые облачные решения для высокопроизводительных вычислений, а не для бизнес-приложений?
После этого можно будет рассуждать о виртуализации, потери от которой перекроют все «преимущества» в разы.
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 и у нас это имеет отношение к большинству сотрудников…