=Paper=
{{Paper
|id=Vol-1482/706
|storemode=property
|title=Комбинированное использование высокопроизводительных ресурсов и грид-инфраструктур в рамках облачной платформы Everest
(Combined use of HPC resources and grid infrastructures with Everest cloud platform)
|pdfUrl=https://ceur-ws.org/Vol-1482/706.pdf
|volume=Vol-1482
}}
==Комбинированное использование высокопроизводительных ресурсов и грид-инфраструктур в рамках облачной платформы Everest
(Combined use of HPC resources and grid infrastructures with Everest cloud platform)==
https://ceur-ws.org/Vol-1482/706.pdf
Суперкомпьютерные дни в России 2015 // Russian Supercomputing Days 2015 // RussianSCDays.org
Комбинированное использование высокопроизводительных
ресурсов и грид-инфраструктур в рамках облачной
платформы Everest*
О.В. Сухорослов
Институт проблем передачи информации Российской академии наук
Everest — облачная платформа, поддерживающая публикацию, выполнение и компо-
зицию вычислительных приложений в распределенной среде. Одной из отличитель-
ных черт платформы является возможность запуска приложений на произвольных
комбинациях внешних вычислительных ресурсов, подключенных пользователями. В
работе описывается интеграция платформы Everest с одиночными вычислительными
ресурсами и грид-инфраструктурой EGI, а также рассматриваются проблемы, связан-
ные с комбинированным использованием данных ресурсов для выполнения разме-
щенных в Everest приложений.
1. Введение
В настоящее время остро стоит проблема объединения вычислительного потенциала дос-
тупных исследователям ресурсов в гетерогенные распределенные вычислительные среды
(ГРВС) для решения сложных научных задач. Решение данной проблемы позволило бы много-
кратно повысить производительность исследований и эффективность использования отдельных
ресурсов. Существующие методы и технологии не в полной мере решают указанную проблему,
поскольку в большинстве своём ориентированы только на определенные типы ресурсов и при-
ложений.
Грид-технологии (Globus Toolkit, gLite, Unicore) позволяют организовать разделяемый дос-
туп к множеству вычислительных ресурсов с возможностью автоматического распределения
заданий между ресурсами. Однако данные технологии ориентированы только на определенный
класс вычислительных ресурсов (кластеры и суперкомпьютеры), при этом далеко не все ресур-
сы доступны через грид-системы. Грид-технологии сложны в установке, использовании и со-
провождении, что затрудняет их применение в рамках небольших научных проектов или для
создания персональных ГРВС.
В свою очередь, технологии добровольных вычислений (BOINC, XtremWeb, OurGrid) ори-
ентированы на интеграцию простаивающих ресурсов персональных компьютеров, что затруд-
няет их использование с другими типами ресурсов. Например, использование технологии
BOINC на суперкомпьютере требует разработки дополнительных программных средств, таких
как CluBORun. Исключением является система HTCondor, разработчики которой одними из
первых предложили механизм интеграции с ресурсами суперкомпьютеров и грид-
инфраструктур путем запуска заданий-агентов.
Другим подходом к построению ГРВС является применение метапланировщиков и других
программных средств (HTCondor-G, Nimrod-G, GridWay, Ganga, DIRAC, PanDA), реализующих
распределение и запуск заданий на заданном пуле вычислительных ресурсов. Данные средства
позволяют сформировать ГРВС из произвольного набора ресурсов различных типов. При этом,
как правило, не требуется установка дополнительного программного обеспечения (далее – ПО)
на ресурсах, что значительно облегчает создание ГРВС. Вместе с тем, данные программные
средства также обладают рядом недостатков. Остается необходимость установки и настройки
данного ПО, как правило, на постоянно доступном сервере с внешним IP-адресом. Ряд средств
не реализуют многопользовательский режим, то есть ориентированы только на персональное
использование. Другие средства поддерживают работу с ГРВС нескольких пользователей, но
только в рамках общего набора ресурсов, заданного администратором.
*
Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта № 14-07-00309.
706
Суперкомпьютерные дни в России 2015 // Russian Supercomputing Days 2015 // RussianSCDays.org
Платформа Everest [1-3] реализует новый подход к решению проблем публикации, выпол-
нения и композиции вычислительных приложений в распределенной среде. В отличие от суще-
ствующих решений, Everest является облачной платформой, реализующей модель облачных
вычислений Platform as a Service (PaaS). Это означает, что вся функциональность платформы
доступна через удаленные интерфейсы: пользовательский веб-интерфейс и программный ин-
терфейс (REST API). Один экземпляр платформы может обслуживать много пользователей,
позволяя им размещать свои приложения, запускать их и делиться ими с другими пользовате-
лями без необходимости установки дополнительного ПО на компьютеры пользователей. Раз-
мещенные в Everest приложения автоматически становятся доступными через веб-интерфейс и
REST API. Последний позволяет автоматизировать работу с приложениями, осуществлять их
композицию в рамках расчетных схем (workflow) и работать с приложениями из внешних сис-
тем.
Отличительной чертой Everest является поддержка запуска приложений на произвольных
комбинациях внешних вычислительных ресурсов. Пользователи платформы могут подключать
к ней имеющиеся в их распоряжении вычислительные ресурсы и создавать персональные
ГРВС. В отличие от существующих средств организации вычислений в ГРВС, все действия по
конфигурации ресурсов и запуску вычислительных заданий осуществляются через веб-браузер.
При этом платформа поддерживает одновременное функционирование множества ГРВС, соз-
данных пользователями. В работе описывается интеграция платформы Everest с одиночными
вычислительными ресурсами и грид-инфраструктурой EGI, а также рассматриваются пробле-
мы, связанные с комбинированным использованием данных ресурсов для выполнения разме-
щенных в Everest приложений.
2. Архитектура платформы Everest
Рассмотрим кратко общую архитектуру платформы Everest (Рис. 1). Серверная часть плат-
формы состоит из трех уровней: программный интерфейс (REST API), приложения и вычисли-
тельное ядро. Клиентская часть платформы включает пользовательский веб-интерфейс (Web
UI) и клиентские библиотеки.
Рис. 1. Архитектура платформы Everest
707
Суперкомпьютерные дни в России 2015 // Russian Supercomputing Days 2015 // RussianSCDays.org
REST API — программный интерфейс платформы, реализованный в виде веб-сервиса на
основе стиля REST. Данный интерфейс включает операции для работы со всеми основными
объектами платформы, такими как приложения, задания, ресурсы. Это единая точка входа для
всех клиентов платформы, включая веб-интерфейс и клиентские библиотеки.
Уровень приложений соответствует среде размещения приложений, созданных пользовате-
лями платформы. Приложения является главными объектами платформы, представляющими
собой вычислительные блоки с четко описанными интерфейсами. Каждое размещенное в
Everest приложение автоматически публикуется как веб-сервис через REST API. Владелец при-
ложения может настраивать список пользователей, которым доступен запуск приложения.
Платформа Everest не предоставляет собственных ресурсов для выполнения приложений и
не связана жестко с какой-либо одной инфраструктурой. Вместо этого она позволяет пользова-
телям подключать к себе внешние ресурсы и запускать приложения на любых сочетаниях дан-
ных ресурсов.
Вычислительное ядро управляет выполнением приложений на удаленных ресурсах. При
вызове приложения через интерфейс платформы формируется задание (job), состоящее из од-
ной или нескольких вычислительных задач (tasks). Ядро реализует все действия связанные с
передачей данных, запуском и мониторингом задач на удаленных ресурсах. Также ядро осуще-
ствляет мониторинг состояния самих ресурсов и использует данную информацию при плани-
ровании задач.
Веб-интерфейс (Web UI) представляет собой графический интерфейс для работы пользова-
телей с платформой. Данный интерфейс реализован в виде приложения на языке JavaScript, ко-
торое может выполняться в веб-браузере без необходимости установки дополнительного ПО.
Веб-интерфейс взаимодействует с платформой через REST API, то есть использует тот же ин-
терфейс, что и остальные клиенты платформы.
Клиентские библиотеки предназначены для упрощения программного доступа к платформе
через REST API. Они позволяют пользователями легко писать программы, которые вызывают
приложения и комбинируют их в произвольные сценарии. В настоящий момент реализована
одна такая библиотека для языка Python.
3. Интеграция с одиночными вычислительными ресурсами
Традиционно для интеграции программных систем с удаленными вычислительными ресур-
сами применяются два подхода.
Первый основан на использовании общих протоколов удаленного доступа, поддерживае-
мых ресурсами, таких как SSH. Данный подход часто используется для интеграции с высоко-
производительными ресурсами. Основным его преимуществом является легкость подключения
ресурса, поскольку для этого требуется только передать системе реквизиты доступа к ресурсу
(например, SSH-ключ). Однако, в случае использования облачной платформы, не контролируе-
мой непосредственно пользователем, передача реквизитов доступа системе может быть неже-
лательна из соображений безопасности. Более того, многие суперкомпьютерные центры запре-
щают их пользователям передачу своих реквизитов третьим лицам. Наконец, данный подход не
применим в случае отсутствия как такового удаленного доступа к ресурсу, что имеет место для
ресурсов, находящихся за межсетевым экраном, а также персональных компьютеров.
Второй подход основан на запуске на стороне ресурса специальной программы-агента, иг-
рающей роль посредника между ресурсом и системой. Данный подход распространен сред сис-
тем, ориентированных изначально на использование ресурсов персональных компьютеров, та-
ких как Condor и BOINC. Преимуществами данного подхода являются поддержка интеграции с
любыми ресурсами, вне зависимости от наличия доступа к ним извне, а также возможность
реализации на уровне агента гибкого механизма безопасности. Данный подход также позволяет
оптимизировать сетевой трафик и лучше масштабируется на большое число ресурсов. Основ-
ным недостатком второго подхода является необходимость установки и запуска специального
ПО на стороне ресурса, что снижает удобство подключения ресурса.
На основе проведенного анализа в качестве основного метода интеграции платформы
Everest с внешними вычислительными ресурсами был выбран второй подход, поскольку он об-
708
Суперкомпьютерные дни в России 2015 // Russian Supercomputing Days 2015 // RussianSCDays.org
ладает большей универсальностью и позволяет обеспечить защиту ресурса. При этом были
сформулированы следующие основные требования к агенту:
простота установки и использования (минимальные системные требования, запуск без
прав суперпользователя),
поддержка доступа к ресурсу, находящемуся за межсетевым экраном, с минимальными
требованиями к открытым «наружу» портам,
защита ресурса от несанкционированного использования и запуска вредоносного ПО,
открытый исходный код и открытый протокол взаимодействия с клиентами.
Исходя из данных требований, была выполнена разработка вычислительного агента для
платформы Everest (Рис. 2). Агент реализован на языке Python, что позволило обеспечить пере-
носимость агента на основные современные ОС. Кроме того, среда выполнения Python 2 при-
сутствует сейчас практически на всех вычислительных ресурсах. Агент имеет минимум зави-
симостей и может быть быстро развернут на ресурсе пользователем без специальной подготов-
ки и прав суперпользователя. С целью повышения уровня доверия пользователей, исходный
код агента открыто доступен [4].
Рис. 2. Архитектура агента Everest
Взаимодействие между агентом и платформой реализовано на базе протоколов WebSocket
и HTTP. Протокол WebSocket, позволяющий создать двусторонний канал связи между клиен-
том и веб-сервером, используется для передачи агенту команд (например, запуск нового зада-
ния) и приема от него различных уведомлений (например, изменение состояния задания). Про-
токол HTTP используется для передачи данных вычислительных задач между агентом и плат-
формой. Данный подход обеспечивает связь агента с платформой с минимальными требова-
ниями к открытым «наружу» портам и разрешенным протоколам на стороне ресурса. Подобные
ограничения часто имеют место в суперкомпьютерных центрах и корпоративных сетях.
Для того чтобы подключить ресурс к платформе, пользователь должен зарегистрировать
его через веб-интерфейс и получить секретный код ресурса. После этого необходимо развер-
нуть агента на ресурсе, указав в конфигурации агента полученный секретный код. После ус-
пешного подключения агента к платформе он начинает передавать в Everest информацию о со-
стоянии ресурса, которая отображается в веб-интерфейсе.
Поддержка взаимодействия агента с различными типами ресурсов реализована через меха-
низм подключаемых адаптеров. Адаптер транслирует поступающие к нему со стороны агента
вызовы (запрос состояния ресурса, запуск задачи, запрос состояния задачи, отмена задачи) в
вызовы команд, специфических для данного типа ресурса. В настоящий момент реализованы и
используются адаптеры для запуска задач на локальной машине в отдельных процессах или
внутри одноразовых Linux-контейнеров, а также на вычислительных кластерах под управлени-
ем менеджеров ресурсов TORQUE, SLURM и Sun Grid Engine. В случае кластера агент выпол-
няется на запускающей машине.
Для защиты ресурса от несанкционированного использования и атак реализованы следую-
щие механизмы. При установлении соединения агент и платформа производят взаимную аутен-
709
Суперкомпьютерные дни в России 2015 // Russian Supercomputing Days 2015 // RussianSCDays.org
тификацию. Пользователь может ограничить запускаемые агентом приложения, указав в кон-
фигурации список разрешенных команд в виде регулярных выражений. Кроме того, реализация
агента устойчива к атакам типа shell injection. Однако это не обеспечивает полной защиты в
случае наличия уязвимых мест в самих приложениях или при запуске непроверенных про-
грамм. Одним из реализованных подходов к решению этой проблемы является запуск вычисли-
тельных задач в одноразовых Linux-контейнерах на основе технологии Docker.
В 2015 году функциональность агента была существенно развита. В частности, была реали-
зована возможность взаимодействия с произвольными клиентами через открытый протокол
(ранее агент мог подключаться и взаимодействовать только с Everest), а также реализовано
управление агентом через графический интерфейс. Новая версия агента является самостоятель-
ным программным решением, которое может использоваться для запуска вычислений на уда-
ленных ресурсах в рамках произвольных систем.
4. Интеграция с грид-инфраструктурой EGI
European Grid Infrastructure (EGI) - крупнейшая грид-инфраструктура, объединяющая ре-
сурсы сотен вычислительных центров по всему миру и ориентированная на поддержку иссле-
дований в различных областях науки. Внушительный объем агрегированных вычислительных
ресурсов (около полумиллиона процессорных ядер в случае EGI) делает важным поддержку
работы с подобными инфраструктурами в рамках платформы Everest.
Интеграция с EGI заметно отличается от интеграции с одиночным ресурсом. Во-первых,
для запуска заданий в EGI необходимо иметь доступ к машине с пользовательским интерфей-
сом (т. н. User Interface). Однако у многих пользователей отсутствует доступ к такой машине.
Таким образом, вариант с размещением агента Everest на запускающей машине грида, по ана-
логии с вычислительным кластером, отпадает. Во-вторых, для грида характерны высокие за-
держки при запуске заданий, часто имеющие непредсказуемый характер. В частности, некото-
рые задания могут «зависать» надолго в очередях отдельных ресурсов. Поэтому широкое рас-
пространение получила стратегия так называемых «пилотных заданий» (pilot jobs), когда в грид
запускается универсальное задание-агент, связывающееся с центральным сервером и выпол-
няющее назначаемые ему сервером задачи.
Исходя из описанных особенностей, для интеграции с EGI был реализован подход, заклю-
чающийся в запуске по требованию в грид разработанных ранее агентов (Рис. 3). Запуск аген-
тов реализован через пользовательский интерфейс (EMI User Interface), развернутый на стороне
платформы. Для всех пользователей используется один экземпляр UI, взаимодействие с кото-
рым осуществляется по протоколу SSH.
Рис. 3. Схема интеграции Everest с грид-инфраструктурой EGI
710
Суперкомпьютерные дни в России 2015 // Russian Supercomputing Days 2015 // RussianSCDays.org
Everest контролирует число выполняющихся в грид агентов, запуская новых агентов по ме-
ре необходимости, но не больше установленного пользователем лимита. Будучи запущенным
на ресурсе грида агент связывается с Everest и приступает к выполнению поступающих задач.
Взаимодействие агента и платформы здесь ничем не отличается от случая одиночного ресурса.
Однако агентов теперь запускает не пользователь, и с одним ресурсом в терминах Everest те-
перь может быть связано сразу несколько агентов. Кроме того, в случае отсутствия новых за-
дач, агент автоматически завершает свое выполнение, чтобы освободить занимаемый ресурс.
Поскольку доступ к ресурсам в EGI регламентируется на основе участия пользователей в
виртуальных организациях (ВО), то подключение ресурсов EGI к Everest также реализовано на
уровне отдельных ВО. Пользователь Everest может подключить к платформе в качестве ресурса
определенную ВО, передав платформе действующий прокси-сертификат. По истечении срока
действия прокси-сертификата ресурс становится недоступным до тех пор, пока пользователь не
обновит сертификат. В будущем планируется реализовать поддержку генерации и автоматиче-
ского обновления прокси-сертификатов.
5. Заключение
В настоящее время платформа Everest позволяет относительно легко подключать к ней
внешние вычислительные ресурсы различного типа, что открывает возможности для комбини-
рованного использования нескольких ресурсов и создания ГРВС. Например, при проведении
расчетов можно сочетать использование локальных вычислительных ресурсов организации
пользователя с ресурсами грид-инфраструктуры.
Данная функциональность уже предусмотрена в платформе - при конфигурации или запус-
ке приложения пользователь может указать сразу несколько ресурсов. Для простых приложе-
ний, состоящих из одной задачи, из нескольких альтернатив необходимо выбрать один ресурс.
Для сложносоставных приложений, таких как многовариантный расчет, необходимо распреде-
лить задачи приложения между имеющимися в распоряжении пользователя ресурсами. В обоих
случаях необходимо учитывать характеристики и текущую загрузку ресурсов.
Предварительные вычислительные эксперименты с использованием ГРВС из трех серверов
и трех вычислительных кластеров, подключенных к Everest, показали, что платформа способна
полностью загрузить используемые ресурсы. Тем не менее, эффективное решение данной зада-
чи, оптимизирующее время выполнения приложений, требует доработки планировщика
Everest. Также в будущем планируется провести аналогичные эксперименты с использованием
ресурсов грид-инфраструктуры.
Другой проблемой, связанной с использованием нескольких ресурсов, является обеспече-
ние переносимости приложений. Многие вычислительные приложения изначально создавались
и использовались в рамках определенных ресурсов. При попытке запуска приложения на новом
ресурсе могут возникать проблемы, связанные с отсутствием требуемых зависимостей и сис-
темных библиотек. Для решения данной проблемы предлагается использовать существующие
подходы, основанные на виртуализации приложений.
Литература
1. Sukhoroslov O., Afanasiev A. Everest: A Cloud Platform for Computational Web Services. In
Proceedings of the 4th International Conference on Cloud Computing and Services Science
(CLOSER 2014). SCITEPRESS - Science and and Technology Publications, 2014, pp. 411-416.
2. О. В. Сухорослов. Интеграция вычислительных приложений и распределенных ресурсов на
базе облачной программной платформы // Программные системы: теория и приложения:
электрон. научн. журн. 2014. T. 5, No 4(22), c. 171–182.
3. Everest. http://everest.distcomp.org/
4. Everest Agent. https://gitlab.com/everest/agent/
711
Суперкомпьютерные дни в России 2015 // Russian Supercomputing Days 2015 // RussianSCDays.org
Combined use of HPC resources and grid infrastructures with
Everest cloud platform
Oleg Sukhoroslov
Keywords: distributed computing, heterogeneous computing environments, grid middleware,
job scheduling, cloud platform
Everest is a cloud platform supporting publication, execution and composition of computing
applications in a distributed environment. One of distinguishing features of the platform is the
ability to run applications across arbitrary combinations of external computing resources
attached by a user. This work presents integration of Everest with HPC clusters and EGI grid
infrastructure, and also considers problems related to combined use of these resources for
running Everest applications.