Pull to refresh
7
Karma
0
Rating
Vilgelm Bitner @HPCHub

HPC in the Cloud

  • Followers 6
  • Following

Производительность сети малой латентности InfiniBand на виртуальном кластере HPC HUB

Для задач HPC важна сеть малой латентности. Есть несколько таких сетей. Infiniband традиционно используется в HPC, когда используется оборудование разных вендоров. Infiniband поддерживает SR-IOV и есть открытые драйвера для Linux. Опять же есть некоторый опыт в мире по виртуализации Infiniband.

Производительность сети малой латентности InfiniBand на виртуальном кластере HPC HUB

но 2 нода на 40 коров это не показатель
С чего-то надо начинать. Сейчас подобные тесты пока не выходят за пределы 4-8 узлов.

да и MPI ведёт себя довольно не предсказуемо в разных версиях и сборках
В статье есть подробная информация о версиях использованного софта. Опять же можно попробовать самому.

не было так же упомянуто про роль производительного shared storage( e.g lustre) что не маловажно, ну когда нодов более 2х во многооо раз конечно)
Мы не используем Lustre, мы используем gfs2 и ранее об этом писали в своих статьях. К тому же у нас неблокирующий свитч, и вроде как роутинг с round-robin. Поэтому есть основания ожидать, что IB будет вести себя прилично при масштабировании.

виртуализация в любом её виде плохо влияет на производительность подобныих вычислений
Вопрос на сколько плохо. В конце концов и сеть малой латентности «плохо влияет» по сравнению с большой SMP машиной. А еще лучше вообще однопроцессорная одноядерная машина с очень быстрой памятью и периферией, вообще без ОС, а только с кодом расчета и минимально-необходимой поддержкой I/O. Но почему-то так никто не делает.

Производительность сети малой латентности InfiniBand на виртуальном кластере HPC HUB

спасибо за Ваше замечание.
да, Вы правы. Infiniband разрабатывался IBTA. То, что в Интел были разработаны и реализованы первые чипы Infiniband, а также устройства на их основе, безусловно не дает права цеплять приставку Intel к бренду Infiniband.

Создание разделяемого хранилища на базе CEPH RBD и GFS2

Основная проблема, как нам видится в том, что пространство пользовательских ID для независимых кластеров пересекаются. В результате сложно разграничить доступ. Плюс также проблемы с кооперативными квотами для разных кластеров.

Создание разделяемого хранилища на базе CEPH RBD и GFS2

Неудобно, медленно. К тому же пространство пользовательских ID для независимых кластеров пересекаются, сложно доступ разграничить. Плюс кооперативные квоты.

Виртуальный суперкомпьютер по требованию

У нас есть узлы с Intel Xeon Phi 7120P, но они пока предоставляются как bare-metal инфраструктура.

В зависимости от спроса на такие узлы готовы рассмотреть вариант интеграции их в общую облачную инфраструктуру со всеми фичами (on-demand, pay-per-use, snapshotting, etc.).

Касательно проприетарного софта. Мы стараемся это делегировать клиенту. Он сам устанавливает и заботится о лицензиях. Мы можем сохранить настроенное клиентское окружение, чтобы в следующий раз клиент не тратил на это время.

Мы ведём переговоры с рядом вендоров коммерческого кластерного ПО и планируем предоставлять шаблоны vSC заранее + гибкую аренду лицензий.

Виртуальный суперкомпьютер по требованию

Скорее всего есть небольшое недопонимание.
Наша цель — предоставлять как можно гибко суперкомпьютерные мощности. Желательно столь же гибко как оно бывает с VPS/VDS.

На данный момент мы нащупываем ту модель коммерциализации, которая была бы интересна нашим потенциальным клиентам.

На данный момент оно работает так.
Клиент:
  • регистрируется в контрольной панели и закидывает на лицевой счет деньги
  • заказывает подписку (сторадж, vSC). во время заказа подписки указывает нужное количество выч. мощностей
  • подписка активируется и начинает щелкать время (минимальный квант пока — 1 сутки). округление идет до минимального кванта
  • списание денег с лицевого счета происходит каждый день пока активны подписки на выч. мощности

Правильно ли я понял вопрос?
Такой подход на Ваш взгляд удобный?

Виртуальный суперкомпьютер по требованию

Да. Планируем.
В будущем будет Tesla K80.
Cейчас в частном порядке можем дать 1-2 Tesla K5000.

Виртуальный суперкомпьютер по требованию

Нет, NFS мы не используем, т.к. сторажд на счетном кластере на NFS работает медленно и может привести к непредсказуемым проблемам. Мы отдаем Ceph rbd кластеру как shared диск. Почему был выбран такой вариант конфигурации мы расскажем в будущей статье.

Виртуальный суперкомпьютер по требованию

Чтобы приложение параллельно считалось на нескольких узлах, его надо распараллелить (переписать приложение). Но можно на кластере одновременно запустить несколько независимых задач на разных узлах “в параллель”, хотя для этого Infiniband не особо нужен. Таким образом можно посчитать, скажем, восемь задач за одну неделю, а не за восемь.

Виртуальный суперкомпьютер по требованию

про джаву — надо параллелить, но можно на кластере одновременно пускать несколько задач на разных узлах “в параллель”, хотя для этого Infiniband не особо нужен.

Виртуальный суперкомпьютер по требованию

спотовый тариф — это если у нас есть свободные мощности, то клиент их получает по бросовой цене, но с условием, что мы можем их забрать в любой момент без предупреждения и гарантий сохранения счета и настроенного окружения.

но в нашем случае мы конечно же скажем заранее, что планируем забрать.

Виртуальный суперкомпьютер по требованию

При определённом объеме и длительности цена будет такой.

Если же речь идет, чтобы взять только на 1 сутки, то цена будет выше примерно в два раза.

Либо это будет спотовый тариф как на амазоне.

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity