Pull to refresh

Comments 22

На текущий момент в HPC можно выделить два основных вкуса Storage: очень быстрый локальный (но небольшого объема) и основной (более медленный, зато большой). Первый принято называть Burst Buffer.

Система хранения в HPC — это отдельная большая интересная тема. Я в нее не лез, но от коллег всякого нахватался.
Если коротко, то очень быстрый локальный Storage — редко используется по одной простой причине. Локальный, даже пусть он будет SSD, по скорости сравним со скоростью центрального хранилища, подключенного по Infiniband. Т.е. не такой он и быстрый.
А дальше можно пропустить семь томов рассказа о том, какие задачи и как распараллеливаются и, в связи с этим, как и какое хранение оптимальнее использовать. Например, фермы рендеринга, часто используют локальное хранение в связи с тем, что задача хорошо параллелится просто раздачей вида «кадр на узел». Все данные для рендера кадра можно сразу загрузить локально, а потом три дня считать (утрирую). Но в результате — на рендер фермах обходятся минималистичным Ethernet'ом и обычными NAS/SAN, никаких инфинибэндов, никаких люстр.
А если что-нибудь на тему CFD… То упирается все в латентность интерконнекта и скорость файловой системы — итерации короткие, обмена данными между узлами и узлов с СХД — много.
Основная засада Storage в HPC, это частое почти полное отсутствие «случайного доступа» к системе хранения. Итерация отсчиталась… и _все_ узлы практически идеально одновременно лезут в одну и ту же папку положить промежуточный результат, а потом все узлы дружно, одновременно, лезут в одну и ту же папку за следующей порцией данных. И тут вдруг выясняется, что энтерпрайзная СХД со 100500 миллионов миллиардов IOPS… Зависает минут на десять и неспеша разгребает очередь запросов из-за того, что эти IOPSы рассчитаны на ситуацию, когда случайные процессы в случайные моменты времени лезут к случайным файлам.
Именно по этому чаще всего в HPC видна ситуация вида — локальные диски на 10-30% вычислительных узлов, СХД включенная в ту же высокопроизводительную фабрику и, третий уровень — «обычная» СХД на медленных больших дисках, подключенная через Ethernet, или, иногда, через FC к «голове».
Как бы есть уже qpi, встроенный в процы. Заменить физический слой, и в теории можно использовать вместо IB.
Без внимания остался, на мой взгляд, такой важный сегмент как ускорители на FPGA, которые должны потеснить GPU.
По ускорителям: для интела — это будет их семейство Intel Xeon Phi.
А также напрямую для FPGA — покупка Intel'ом Altera.
Верно, этот вопрос я не рассмотрел.
Пока я не вижу широкого использования FPGA или ASIC в HPC. И у меня, к сожалению, нет пока интуиции в этом вопросе.
Хотя, вроде бы, для некоторых направлений HPC FPGA могут быть полезны. Например, в геномике. Вот, например, контора, которая пошла дальше FPGA и предлагает ASIC'и для стандартных геномных алгоритмов: http://www.edicogenome.com/dragen_bioit_platform/
Однако мне неизвестно, насколько хорошо у них идут дела.
Как думаете, какой будет стратегия Интела (и других игроков) в отношении FPGA? И как вся тема будет развиваться?
В России эксплуатируется несколько HPC систем на FPGA. У нас было окошко на одну такую машину, но информации про нее никакой не было.
Ну и всякого почитать можно для начала на http://fpga.parallel.ru/
Intel Parallel Studio

Тольк для HPС есть Intel Cluster Studio (включающая в себя MPI библиотеки, рантайм и анализатор производительности на кластерах).
К сожалению, иногда нужно изобретать велосипед: у нас кластер содержит ноды от amd и intel одновременно.
Эт конечно чуть сложнее, но для большинства софта в Parallel Studio достаточно x86 совместимости (хотя конечно, в тех же библиотеках типа MKL производительность будет не интеловская)
Можете что-то платформонезависимое посоветовать?
Я знаю, что
premature optimization is the root of all evil
Из библиотек производительности, рантаймов, или анализаторов? Просто уточнить, о чем именно мы говорим.
Из библиотек, с остальным можно подождать.
Из неинтеловских лучше Atlas, наверное, нет.
Cluster Studio сейчас называется «Parallel Studio XE Cluster Edition»
Из упущенного: DAOS, http://storageconference.us/2015/Presentations/Gorda.pdf.
По-моему, это мертвая тема.
Хотя, несомненно, заслуженная :)
DAOS использовался в самой первой реализации Burst Buffer'ов совместно с EMC и HDF Group в 2012 году. Эту работу проспонсировал американский Department of Energy.

Насколько мне известно, до продуктизации DAOS дело никогда не доходило. Только экспериментальные наработки…

Спасибо, что вспомнили о нем!
Кстати, откуда знаете про DAOS?
Вы занимаетесь системами хранения?
Я занимался Люстрой в 2004-2009, потом другой системой, для exascale.
Если не секрет, что делали для Люстры? И что за система для exascale?
Первое, что я сделал для Люстры был OSX клиент, но он так и не был выпущен, потому что Apple поменял VFS интерфейс в следующей версии Дарвина. Потом было много чего: новый сервер мета-данных (http://wiki.lustre.org/images/b/b8/LUG08-head-mds-danilov.pdf), новый клиентский IO стек (http://wiki.lustre.org/images/6/66/CLIO-TOI.pdf) и пр. Про новую систему (Mero) есть обзор: http://www.pdsw.org/pdsw-discs16/wips/danilov-wip-pdsw-discs16.pdf.
О! Кажется, у меня наступило просветление. Мы с вами ужинали в SLC вместе с нашим общим другом Джоном Бентом
Only those users with full accounts are able to leave comments. Log in, please.