Суперкомпьютер по запросу

Высокопроизводительные вычисления (High-Performance Computing, HPC) играют все более важную роль в изучении сложных процессов различных предметных областей, включая проектирование аэрокосмической техники и автомобилей; бизнес-аналитику; развлечения; финансы; производство; разведку, добычу, очистку и переработку нефти и газа; а также разработку лекарственных средств. Моделирование и симуляция сложнейших природных, инженерных и социальных систем не просто помогают исследователям лучше разобраться в них, но в значительной мере способствуют снижению рисков принятия решений.

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

Сегодня преобладающей парадигмой вычислений становятся облака, дающие немало преимуществ, в том числе и для HPC. Однако существующим реализациям облачных HPC недостает быстродействия и масштаба, необходимых многим научным приложениям. Подход HPC в виде сервиса (HPCaaS) подразумевает предоставление с помощью облачной абстракции простого интерфейса для доступа к ресурсам высокопроизводительных систем.

Облака и научные приложения

Облака обеспечивают удобный доступ по требованию к пулу конфигурируемых ресурсов, которые можно быстро выделять и освобождать с минимальными затратами сил на администрирование и взаимодействие с провайдером сервиса. Облачные сервисы основаны на трехуровневой абстракции *aaS, позволяющей платить за доступ к ресурсам в зависимости от действительно используемого объема. Самый нижний уровень — инфраструктура как сервис (Infrastructure as a Service, IaaS) — предоставляет пользователю доступ к мощностям физической или виртуализованной конфигурации в объеме, масштабируемом по необходимости. Следующий уровень абстракции — платформа как сервис (Platform as a Service, PaaS) — предоставляет облачные стеки платформного ПО для разработки и развертывания произвольных облачных сервисов. Самый высокий уровень — программа как сервис (Software as a Service, SaaS) — предоставляет полноценные программные решения, размещаемые в облаке.

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

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

Затем исследователи начали экспериментировать с гибридной инфраструктурой, объединявшей HPC-ресурсы с публичными облаками, — этот принцип называют «HPC плюс облака». Такой подход давал HPC-приложениям некоторые преимущества: ускорение и отказоустойчивость —поддерживая гибридные потоки работ, например HPC плюс анализ данных. При этом сложности с выделением и использованием ресурсов оставались.

Учитывая ограничения облаков, построенных на стандартном оборудовании, при обслуживании HPC-приложений очевидна потребность в облачных решениях, специально созданных для таких приложений, что особенно актуально для оборудования с быстрыми процессорами и межсоединениями. Этот подход, называемый «HPC в виде облака», подразумевает соединение друг с другом небольших виртуализованных или невиртуализованных кластеров для создания общего крупномасштабного облака. Такие системы дают более высокое быстродействие, чем HPC в облаке, но все еще заметно уступают локальным HPC-кластерам.

Рис. 1. Высокопроизводительные вычисления в виде сервиса. Фреймворк HPCaaS трансформирует суперкомпьютер IBM Blue Gene/P в эластичное облако, состоящее из нескольких облаков. Объединенное облако обеспечивает динамическое распределение, эффективное использование и максимальную доступность HPC-ресурсов

HPC в виде сервиса

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

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

Предлагаемая среда HPCaaS трансформирует суперкомпьютер, в данном случае IBM Blue Gene/P, в эластичное облако, составленное из нескольких облаков и обеспечивающее динамическое распределение, эффективное использование и максимальную доступность HPC-ресурсов с помощью абстракций IaaS, PaaS и SaaS. Как показано на рис. 1, два основных системных компонента HPCaaS — это инфраструктура как сервис (Deep Cloud) и платформа в виде сервиса (CometCloud).

Инфраструктура как сервис

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

Реализация IaaS на суперкомпьютере связана с двумя серьезными трудностями. Во-первых, современные планировщики не способны управлять интерактивными рабочими нагрузками для удовлетворения запросов задач в ресурсах, требующего эластичного масштабирования. Хотя некоторые планировщики предоставляют мгновенный доступ к HPC-ресурсам, поддержка этой возможности обычно добавлялась постфактум, а не реализовывалась изначально. Во-вторых, типовая задача для суперкомпьютера должна не только указать объем требуемых ей ресурсов, но и «знать» ресурсные ограничения HPC-системы. Между тем, у пользователей облака должна быть иллюзия безграничных возможностей.

В диспетчере ресурсов суперкомпьютера IBM Deep Cloud эти проблемы решаются за счет предоставления пользователям абстракции неограниченных ресурсов, позволяющей им программно менять свои запросы в период исполнения. Тем самым спрос формируется динамически, что позволяет свести к минимуму время ожидания в очереди. Диспетчер состоит из двух основных компонентов: планировщика, обеспечивающего пространственно-временную эластичность ресурсов, и механизма динамической тарификации.

Планировщик ресурсов создан на базе гибкого механизма резервирования, и подобно традиционным планировщикам он может обеспечить высокий коэффициент загруженности системы. Однако, в отличие от обычных, он обеспечивает эластичность задач в период исполнения, предоставляя им простой API для запроса новых ресурсов и используя ряд стратегий максимизации вероятности выполнения такого запроса. Эластичность ресурсов может быть достигнута либо за счет ограничения уровня загруженности системы, либо путем принудительного завершения или приостановки работающих задач в целях высвобождения мощностей по запросам от других заданий. В Deep Cloud используются оба этих механизма. Поступающие задачи делятся на два типа: с выделенным объемом ресурсов (dedicated) и «лучшее из возможного» (best effort). В каждый момент времени может работать только ограниченное количество dedicated-задач, а задачи категории best effort запускаются по мере возможности. Система сама решает, какие задачи завершить или приостановить для оптимального обеспечения эластичности ресурсов.

Чтобы управлять спросом на физически ограниченный объем ресурсов, механизм динамической тарификации следует принципу, похожему на схемы расценок в гостиничной и транспортной отраслях. Пользователи получают сведения о доступности ресурсов в зависимости от тарифов и могут выбрать, когда лучше запустить свои задачи. Динамически корректируя расценки на разные конфигурации, система «распрямляет» кривую спроса: самые высокие тарифы выставляются тогда, когда спрос самый высокий. Соответственно, пользователи с ограниченным бюджетом и гибким графиком исполнения будут запускать свои задачи в периоды малой нагрузки на систему, а более платежеспособные пользователи с высокими требованиями смогут укладываться в сроки.

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

Платформа в виде сервиса

Уровень PaaS экранирует для пользователя низкоуровневое оборудование и таким образом обеспечивает простоту и автономную эластичность. На этом уровне также можно объединять в федерацию несколько облаков, работающих на нескольких суперкомпьютерных системах, не беспокоясь об их физической инфраструктуре. В описываемой реализации HPCaaS уровень PaaS создается с помощью программного каркаса CometCloud, который разрабатывается в университете Ратгерса.

CometCloud обеспечивает множество функций, в том числе исполнение потока работ, балансировку нагрузки, отказоустойчивость, связи между кодом, автоматическое вертикальное и горизонтальное масштабирование по требованию и объединение группы облаков. Система также выполняет планирование и распределение заданий, выдачу ресурсов и контроль сбоев на уровне приложений и ОС.

Рис. 2. iPad-интерфейс для запуска моделирования на HPCaaS. С помощью простого в программировании интерфейса ученые могут готовить эксперименты, задавать параметры бюджета и время выполнения, следить за потоком работ и направлять его, а также получать результаты в интерактивном режиме

Система CometCloud состоит из четырех основных компонентов: сервер, мастер, «рабочие» и Comet-пространство. Сервер отправляет пользовательские запросы к мастеру, который передает задачи в Comet-пространство. Обычно задание — это экземпляр традиционного HPC-приложения с различными параметрами: входные данные, число процессоров, режим работы и т. д. После отправки набора задач в Comet-пространство «рабочие» соединяются с ним, «вытягивают» себе задание и исполняют в заданном разделе. Такая схема с вытягиванием гарантирует балансировку нагрузки, поскольку задания распределяются по разным средам исполнения. Если задание завершается аварийно из-за системного сбоя, то мастер вновь помещает его в Comet-пространство для повторной обработки, тем самым обеспечивая определенный уровень отказоустойчивости. Мастер также меняет выделенный объем ресурсов в соответствии с общей рабочей нагрузкой Comet-пространства, что обеспечивает программируемую эластичность.

Для связи между CometCloud и Deep Cloud служит специальная программа — агент Blue Gene. Comet-мастер, общаясь через агент, оптимизирует запросы на ресурсы Blue Gene/P. Агент принимает заданные пользователем параметры, такие как бюджет и сроки выполнения, и меняет запросы ресурсов. С помощью интерфейса программирования Deep Cloud программно выделяет или высвобождает ресурсы и получает сведения о тарифах и готовности. Таким образом, агент Blue Gene решает задачу обеспечения эластичности ресурсов как с точки зрения пользователя, так и с точки зрения программирования.

Comet-пространство можно разделить между несколькими узлами переднего плана Blue Gene/P для создания объединенного облака суперкомпьютерных ресурсов. «Рабочие» на каждой системе изолированно выполняют свои задания и затем возвращают результаты на соответствующие внешние узлы. Работу систем можно синхронизировать, чтобы текущий набор заданий завершался прежде, чем будет обработан следующий.

Программное обеспечение в виде сервиса

Предложенный фреймворк HPCaaS обеспечивает простоту внедрения новых приложений и предоставление доступа пользователей к ним в виде сервиса через тонкие клиенты. С помощью простого в программировании интерфейса, как например вариант для Apple iPad (рис. 2), ученые могут готовить эксперименты, задавать бюджет и время выполнения, следить за потоком работ и направлять его, а также получать результаты в интерактивном режиме. Фреймворк маскирует сложность суперкомпьютера, благодаря чему пользователи могут сосредоточиться на решаемых задачах и тратить меньше времени на системное администрирование.

Тестирование

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

IPARS

Приложения для расчета статистического ансамбля имитируют многомасштабные, многоступенчатые модели путем параллельного исполнения сотен или тысяч экземпляров приложения и интеграции результатов с помощью ансамблевого фильтра Калмана (ensemble Kalman filter, EnKF). При появлении новых данных они вносятся во все модели, чтобы обновить экземпляры для следующего этапа потока работ. Ансамблевые приложения требуют переменного числа процессоров для каждого экземпляра, быстрой межпроцессорной связи, а также большого и динамичного пула HPC-ресурсов для достижения приемлемой точности. Им также нужен простой в использовании механизм управления потоками работ, гарантирующий выполнение задания. Код HPC-приложения и фильтра обычно пишется разными группами разработчиков, поэтому желателен простой механизм связывания кода.

Само приложение — это Integrated Parallel Accurate Reservoir Simulator, система, прогнозирующая потоки нефти в резервуаре с использованием различных жидкостных моделей. Используемый EnKF действует по методу Монте-Карло, реализуя этапы прогнозирования и ассимиляции (обновления) данных. В проведенном тестировании первый этап заключался в параллельном исполнении множества экземпляров IPARS в целях прогнозирования течения нефти на основе заданного набора параметров модели (проницаемости, пористости и т. д.). На этапе ассимиляции, руководствуясь разницей между прогнозируемыми и наблюдаемыми данными, EnKF обновляет параметры и переменные модели. Этот процесс непрерывно повторяется по мере поступления новых данных.

Рис. 3. Поток работ IPARS. CometCloud исполняет экземпляры IPARS и интегрирует результаты их работы с помощью ансамблевого фильтра Калмана, а Deep Cloud выделяет физические ресурсы, необходимые для исполнения всех экземпляров

Поток работ приложения

Как показано на рис. 3, поток работ приложения состоит из многих этапов, на каждом из которых, в свою очередь, одновременно исполняется множество экземпляров IPARS. Фильтр EnKF интегрирует результаты на каждом этапе. Число экземпляров на каждом этапе и количество самих этапов динамически меняются в зависимости от конкретной задачи и желаемого уровня точности.

Предложенная реализация состоит из двух систем Blue Gene/P, находящихся на разных континентах: Watson в исследовательском центре IBM в Йорктаун-Хайтс (шт. Нью-Йорк) и Shaheen в Университете науки и техники короля Абдуллы в Саудовской Аравии.

CometCloud обеспечивает общую оркестровку исполнения потока работ: система исполняет экземпляры IPARS и интегрирует результаты их работы с помощью EnKF. По завершении исполнения набора экземпляров каждого этапа CometCloud запускает EnKF для обработки результатов, генерируя набор экземпляров для следующего этапа. Агент Blue Gene затем динамически масштабирует ресурсы вертикально или горизонтально в соответствии с требованиями обновленного набора задач.

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

***

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

Предлагаемый фреймворк HPCaaS действует по второму принципу, трансформируя суперкомпьютеры Blue Gene/P в объединенное эластичное облако. В ходе тестирования удавалось по запросу типового HPC-приложения динамически выделять от 640 до 22 016 процессоров двух систем Blue Gene/P, находящихся на разных континентах. Примечательно, что сам фреймворк не влиял на быстродействие и коэффициент загруженности HPC-ресурсов. Таким образом, он реализует новую, потенциально более простую и мощную абстракцию для доступа к таким ресурсам.

Предоставив возможность исполнять HPC-приложения в облаке, HPCaaS поможет ученым и инженерам глубоко исследовать сложные процессы. Стандартизованные интерфейсы доступа к совместно используемой инфраструктуре обеспечат повышение эффективности командной работы независимо от географического местонахождения участников. Исчезнут барьеры, мешающие доступу к дорогостоящим суперкомпьютерам, — HPCaaS «демократизирует» эти машины, позволив использовать их не только в научных и инженерных исследованиях, но и, например, в образовании. Однако пока сделаны лишь первые шаги, и необходима дальнейшая работа над повышением надежности каркаса, обеспечением возможности подключения других HPC-систем к объединенному облаку, созданием более эффективных механизмов связи и переноса данных между различными облаками, а также над обобщением подхода HPCaaS с охватом других платформ и видов приложений.

Мустафа Абделбакы (moustafa.a@rutgers.edu) — аспирант, Маниш Парашар (parashar@rutgers.edu) — профессор университета Ратгерса. Хенджо Ким (hyunjoo.kim@xerox.com) — научный сотрудник Исследовательского центра Xerox в Вебстере (шт. Нью-Йорк). Випин Сачдева (vsachde@us.ibm.com) — научный сотрудник, Керк Джордан (kjordan@us.ibm.com) — директор по передовым решениям, Джеймс Секстон (sextonjc@us.ibm.com) — директор программ, Хани Джамджум (jamjoom@us.ibm.com) — менеджер по исследованиям, Зун Инь Ше (zshae@us.ibm.com) — научный сотрудник Исследовательского центра IBM имени Томаса Ватсона. Реза Таваколи (tavakoli@ices.utexas.edu) — научный сотрудник, Мэри Уилер (mfwices.utexas.edu) — профессор,  Гергина Пенчева (gergina@ices.utexas) – аспирант Института инженерных и компьютерных наук Техасского университета в Остине.