Вестник РАН, 2022, T. 92, № 1, стр. 46-56

СТРУКТУРА MC2E

Перечислим основные принципы организации среды MC2E:

• инфраструктура представляет собой объединение локаций, оснащённых вычислителями, хранилищами и сетевыми ресурсами, называемых федератами;

• федерация управляет всеми ресурсами (центральный процессор, память, сеть передачи данных, программное обеспечение), предоставляемыми федератами;

• ресурсы одного федерата могут одновременно использовать разные проекты;

• ресурсы федерата могут быть виртуализированными;

• ресурсы на уровне пользователя имеют высокий уровень абстракции и их использование не должно подразумевать высокую квалификацию пользователя;

• результаты экспериментов всегда должны сохраняться и могут использоваться другими для воспроизведения или продолжения эксперимента;

• федерация предоставляет сервисы по обработке данных, другими словами, федерация – это компьютер.

На рисунке 1 показана организация среды MC2E с распределением ответственности между международными участниками проекта.

Примером вычислительного ресурса федерата может быть высокопроизводительный вычислитель либо ЦОД. У каждого федерата есть своя собственная политика, которая регулирует распределение ресурсов между участниками проектов. Идея построения информационно-вычислительной инфраструктуры как федерации разнородных вычислительных установок уже использовалась во многих действующих проектах. Некоторые из них предназначались для проведения экспериментов в области компьютерных сетей. Например, проект GENI – Global Environment for Network Innovation [4], инициированный Национальным научным фондом США (NSF), представляет собой виртуальную лабораторию для сетевых экспериментов в международном масштабе. Сегодня более 200 университетов США подключены к среде GENI. Другой поддержанный NSF проект – FABRIC [5] – предлагает адаптивную программируемую инфраструктуру для исследований в области компьютерных наук. К аналогичным, но менее известным проектам относятся Ophelia [6] и Fed4Fire [7]. Первый реализован при поддержке ЕС, второй поддержан 17 компаниями из 8 европейских стран. Есть и другие, которые обеспечивают среду для вычислительных экспериментов независимо от прикладной области [8–10]. Однако у всех этих проектов есть несколько существенных недостатков:

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

• невозможность строить цепочки сервисов для проведения экспериментов;

• нельзя автоматически переносить уже существующее программное обеспечение в новую среду;

• при планировании ресурсов не учитывается масштабирование производительности сервисов;

• отсутствие служб контроля и управления DCN, таких как мониторинг и службы BoD.

Базовыми технологиями для проекта MC2E при разработке виртуальной инфраструктуры для междисциплинарных исследований служили программно-конфигурируемые сети (SDN) и виртуализация сетевых функций (NFV) [11]. Эти технологии позволяют повысить уровень абстракции ресурсов, обеспечить их согласованную оптимизацию и автоматизацию управления инфраструктурой. Вместо отдельных ресурсов пользователи получают виртуальные инфраструктуры, полностью укомплектованные необходимыми ресурсами – вычислительными мощностями, каналами связи и системами хранения – с гарантированной производительностью и качеством обслуживания (QoS) на основе соглашения об уровне сервиса (SLA).

Фактически, в проекте MC2E использовались две облачные среды: Docklet [12] и Cloud Conductor (C2) [13]. Предназначение Docklet – предоставить индивидуально настроенное рабочее пространство в облачной среде [14]. Основа Docklet – LXC виртуальный кластер [15]. Пользователи Docklet взаимодействуют непосредственно в своей рабочей области, используя браузер для разработки, отладки, тестирования своего программного обеспечения с помощью инструментов, которые предоставляет эта среда. Docklet позволяет строить индивидуальные небольшие виртуальные центры обработки данных, создавая виртуализированные кластеры, а затем предоставляя экспериментаторам настроенное рабочее пространство в облаке. Пользователям нужен только современный браузер для доступа в свою рабочую область, расположенную в сети федерата, из любого места в Интернете и в любое время.

Архитектура платформы C2 основана на эталонной реализации модели ETSI NFV MANO [13]. C2 обеспечивает полную поддержку жизненного цикла виртуализированных сервисов (ВС) – инициализацию, конфигурацию, выполнение и деинициализацию, которая осуществляется с помощью так называемых шаблонов на языке TOSCA [13]. Всё, что нужно для установки и запуска ВС, – шаблон TOSCA, включающий описание структуры облачного приложения, политики управления приложениями, образа операционной системы и сценариев запуска, остановки и настройки приложения, реализующего ВС. TOSCA формирует администратор сервиса в виде архива zip или tar.

Такая среда, построенная на основе федерации, имеет следующие преимущества:

• простота и скорость выделения, настройки и масштабирования ресурсов;

• разработка приложения как цепочки из сервисов на основе технологии NFV;

• объединение инфраструктур разных исследовательских групп на основе единой политики доступа;

• автоматизированное планирование ресурсов для выполнения запросов пользователей на основе политики доступа и требований SLA;

• язык шаблонов для описания приложений, позволяющий абстрагироваться от низкоуровневых системных деталей;

• децентрализованная система учёта ресурсов для взаиморасчётов между участниками проекта;

• широкие возможности для отслеживания и мониторинга экспериментов;

• повышенная эффективность виртуализации сети благодаря технологии программно-конфигурируемых сетей (ПКС), что позволяет настраивать виртуализированные сетевые каналы для каждого конкретного эксперимента;

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

Перечислим основные компоненты или подсистемы среды MC2E:

• мета-облако – оркестровка пользовательских приложений, распределение и планирование их между федератами;

• интерфейс – предоставляет пользователям унифицированный API для отправки своих приложений и федеративного администратора с целью управления и контроля ресурсов федерации;

• сеть – регулирует использование сетевых ресурсов и предоставляет услугу BoD;

• монитор – выполняет мониторинг и учёт потребления ресурсов всех федератов в MC2E;

• качество обслуживания, административный контроль и управление – обеспечивают соблюдение политики использования ресурсов на основе требований пользователя (SLA) и гарантируют доступность ресурсов.

Эти компоненты подробно описаны в работе [16]. Общий процесс выполнения запроса пользователя в среде MC2E выглядит следующим образом:

1. С помощью единого интерфейса MC2E пользователь отправляет своё приложение и данные на интерфейсный сервер.

2. Интерфейсный сервер вызывает планировщик и монитор мета-облака, чтобы выбрать федерата для выполнения приложения.

3. Мета-облако анализирует очередь и прогнозирует время выполнения приложения и время передачи данных для всех доступных федератов.

4. Основываясь на прогнозе, мета-облако выбирает федерата, который минимизирует общее время пребывания приложения в системе (критерий PTS – время ожидания в очереди + время выполнения).

5. Мета-облако обращается к контуру управления сетью для прокладки канала к выбранному на шаге 4 федерату и отправляет туда приложение и его данные.

6. Федерат запускает приложение и возвращает результаты пользователю.

7. В случае сбоя подсистема мониторинга и управления качеством обслуживания перенаправляет приложение средствами мета-облака в другой федерат.

ОБЛАКО КАК СРЕДА ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ ВЫЧИСЛЕНИЙ

Несмотря на то, что скорость вычисления в облачных средах ниже, чем в специализированных серверных кластерах или суперкомпьютерах [17], такая технология становится всё более популярной и выбирается в качестве платформы для высокопроизводительных вычислений из-за низкой стоимости и простоты доступа. В нескольких статьях [18, 19] показано, что одно из основных узких мест производительности HPC-С связано с задержками в сети передачи данных (СПД) в ЦОД. Суперкомпьютеры используют быстрые СПД-сети на основе специализированных средств [20, 21]. HPC-С в основном полагаются на обычный Ethernet. Задержки в СПД могут привести к недозагрузке процессоров (ЦП) приложениями с высокой интенсивностью обмена данными, поскольку в них могут возникать длительные “паузы” в вычислениях из-за ожидания передачи данных по сети между ветвями приложения.

Один из важных результатов проекта MC2E – экспериментальное обоснование гипотезы о том, что производительность HPC-приложений может незначительно деградировать при совместном использовании ядер ЦП. Эта гипотеза была проверена в рамках проекта МС2Е с помощью теста HPC – NAS Parallel Benchmarks (NPB) [22] в облачной среде мини-ЦОД с гипервизором QEMU/KVM с 64 виртуальными машинами (ВМ) (Ubuntu 16.04, 1 vCPU, 1024 Мб ОЗУ), MPI версия 3.2. На головном сервере было 16 МВ, на остальных – по 8 МВ на каждом. Средняя задержка между разными виртуальными машинами – около 400 мкс. Пропускная способность составляла на одном сервере 18.2 Гб/с, на разных серверах – 5.86 Гб/с.

Для изучения влияния пропускной способности сети на загрузку ЦП была проведена серия экспериментов. Последовательно 5 NPB MPI-программ с 2, 4, 8, 16, 32, 64 процессами на каждой виртуальной машине запускались в сети с тремя пропускными способностями каналов: 100 Мб/с, 1 и 10 Гб/с соответственно. Эксперименты показали почти линейную зависимость деградации загрузки ЦП от роста числа MPI-процессов. Это происходило потому, что разные MPI-процессы выполнялись на разных ВМ, а данные передавались между разными серверами. Загрузка ЦП также снижалась, когда программа выполнялась на одном физическом сервере (2, 4 и 8 ЦП). Сокращение загрузки ЦП как раз и позволяет использовать ядра одного и того же ЦП между разными программами. Подробно эта серия экспериментов с графиками представлена в работе [16].

В другой серии экспериментов изучалась способность различных HPC-приложений совместно использовать ядра одного и того же ЦП. Методология эксперимента заключалась в следующем: последовательно запускались 5 пар идентичных NPB MPI-программ с одинаковым числом (2, 4, 8, 16, 32, 64) процессов в каждой. Для оценки способности программы совместно использовать ресурсы ЦП применялась метрика:

где $T_{{pure}}^{i}$ (i = 1.2) – время выполнения без разделения ресурсов; $T_{{sharing}}^{i}$ (i = 1.2) – время выполнения, когда две программы использовали одни и те же ядра одного и того же ЦП.

Нетрудно увидеть, что если значение метрики больше 1, то выполнение двух программ, запускаемых одновременно, займёт меньше времени, чем при их последовательном запуске. Эксперименты показали, что даже в среде с медленной сетью (100 Мб/с) можно получить до 20% ускорения выполнения. Однако не все программы могут эффективно разделять физические ресурсы. Подробно эта серия экспериментов описана в работе [16].

ПРОГНОЗИРОВАНИЕ ВРЕМЕНИ ВЫПОЛНЕНИЯ ПРОГРАММ

Напомним, что один из основных критериев эффективности среды облачных вычислений для HPC-приложений – время, проведённое программой в этой среде (критерий PTS). Данная величина зависит от алгоритмов распределения ресурсов в облачной среде (отображение виртуальных вычислителей на физические) и дисциплины обслуживания очереди программ с учётом неоднородности физических вычислителей.

Из анализа процесса выполнения запроса пользователя, представленного в конце раздела “Структура MC2E”, видно, что этапы 3 (метапланирование) и 4 (локальное планирование) – точки оптимизации по критерию PTS. Важной частью проекта MC2E стали исследование и разработка алгоритма, выбор наиболее эффективного вычислителя в федерации для определённой программы на основе критерия минимального времени выполнения – важного компонента критерия PTS. Для этого специалисты изучили и разработали несколько алгоритмов прогнозирования времени выполнения программы на определённом наборе вычислителей с учётом истории выполнения программы на разных вычислителях (подробное описание алгоритмов см. [23]).

Задача прогнозирования времени выполнения программы на определённом вычислителе хорошо известна и относится к классическим. Например, время выполнения программы на конкретном вычислителе, а также время ожидания в очереди можно спрогнозировать, имея историю её запусков на этом вычислителе [24–27], для чего могут быть использованы многие алгоритмы экстраполяции, например [28, 29] или регрессии [30], или более сложные алгоритмы, в частности, ансамбль деревьев принятия решений (рандомный лес) [31]. Основной недостаток этих алгоритмов заключается в том, что их можно применять только к одному и тому же вычислителю. Но суть этой задачи в MC2E заключалась в прогнозировании времени выполнения программы на определённом наборе вычислителей. Конечно, упомянутые алгоритмы можно использовать для оценки времени выполнения программ на нескольких вычислителях. Однако для этого нужна история запуска каждой программы на каждом вычислителе из набора. Эта информация недоступна.

Выбор вычислителя осуществляется следующим образом. Одним из хорошо известных алгоритмов [24–27] оценивается время выполнения программы по историям её проведения на каждом вычислителе из определённого набора. Примером такой истории может быть трасса выполнения программы [32]. Основываясь на полученных данных, можно либо построить расписание для группы программ, либо, следуя жадной стратегии, отправлять каждую программу на вычислитель, где у неё минимальное время выполнения. Однако необходимы все истории выполнения всех программ на каждом из вычислителей в рассматриваемом наборе. Такой информации, как правило, нет.

Один из важных и новых результатов проекта MC2E – разработка метода прогнозирования времени выполнения программы, который позволяет ослабить требование данных обо всех историях выполнения всех программ на каждом из вычислителей в рассматриваемом наборе: для прогнозирования времени выполнения программы на вычислителях из определённого набора достаточно только историй выполнения этой программы на некоторых из них (подробное описание метода см. [23]). Другими словами, нет необходимости запускать каждую программу на каждом вычислителе.

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

У РС есть рейтинговая матрица, в которой строки (или столбцы) соответствуют фильмам, книгам или товарам, а столбцы (или строки) соответствуют пользователям. Эта матрица часто бывает разреженной, поскольку в списке присутствует множество пользователей и элементов, поскольку пользователи не могут физически оценить все рассматриваемые элементы. Система пытается предсказать предпочтения каждого пользователя для каждого элемента на основе индивидуальных оценок пользователей для некоторых элементов. Другими словами, РС должна заполнить пустые ячейки в рейтинговой матрице. В этих терминах рассмотрим следующую аналогию: пользователи – это вычислители, элементы – это программы, а оценки пользователей – времена выполнения программ. Таким образом, вычислители “оценивают” программы, при этом чем меньше рейтинг (время выполнения), тем лучше.

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

Должно быть ясно, что точность прогноза зависит от количества известных историй выполнения программ на вычислителе из определённого набора. Нами было исследовано два подхода к этой задаче. Первый базировался на группировке вычислителей на основе корреляции Пирсона [35] и показал [23], что данный подход целесообразно применять в случае плотно заполненной (не менее 95% ячеек) матрицы “Программы–Вычислители”.

Второй подход, разработанный для разреженной матрицы “Программы–Вычислители”, подразумевал её разложение на векторные представления вычислителей и программ – так называемые embedding’и. Embedding – это элементы относительно малоразмерного пространства, в которое можно преобразовывать векторы бо́льшей размерности. Техника еmbedding упрощает машинное обучение для случая больших данных, таких как разреженные векторы, представляющие слова. В идеале она частично отражает семантику данных, помещая семантически похожие объекты близко друг к другу в пространстве embedding’ов [36]. В статье [23] подробно показано, как использовать embedding программ и embedding вычислителей для прогнозирования времени выполнения программы на конкретном вычислителе. Техника декомпозиции матрицы “Программы–Вычислители” для расчёта embedding дана в работе [37].

Предложенный подход к прогнозированию времени выполнения программы требует минимальных знаний о программе, которые обычно собирают на всех современных вычислителях. Другое важное преимущество подхода – возможность декомпозиции матрицы “Программы–Вычислители” на embedding и для программ, и для вычислителей размерности 1. Этот факт позволяет тотально упорядочить как вычислители, так и программы, что существенно упрощает подбор вычислителя с эффективным временем выполнения. Подробнее о тестировании методов прогнозирования см. [23].

СЕРВИС “КАНАЛ ПО ТРЕБОВАНИЮ” (BoD)

Как было отмечено в начале статьи, одной из исследованных в проекте MC2E была проблема динамического создания канала между ЦОДами по требованию с заданным качеством связи. Среда, предназначенная для междисциплинарных научных исследований, должна иметь гибкие и мощные механизмы распределения, планирования и администрирования сетевых ресурсов. В противном случае накладные расходы на сетевые ресурсы в сети ЦОДов будут очень высокими, так как нагрузка на этот ресурс носит спорадический характер. Естественно, возникал вопрос о возможности создания сервиса BoD, способного формировать между ЦОДами канал надлежащего качества по требованию, то есть передавать определённое количество данных за определённый интервал времени через транспортную сеть TCP/IP. Следует подчеркнуть, что такой сервис не предполагает выделенного канала между взаимодействующими сторонами. Более того, он должен создаваться динамически путём агрегирования существующих сетевых ресурсов.

В статье [38] подробно рассмотрены протоколы агрегации сетевых ресурсов и алгоритмы для создания сервиса BoD. Здесь представлена лишь логическая схема подхода, предложенного в цитируемой статье. Создание сервиса BoD можно разделить на две основные части: идентификация и агрегация маршрутов в сети ЦОДов и распределение потоков данных между ними согласно требованиям качества сервиса BoD для каждого потока.

Слова “построение и агрегация маршрутов” означают, что для передачи потока данных между ЦОДами одновременно используют разные маршруты и агрегируют несколько физических линий в одну логическую. Есть много протоколов и технологий, которые позволяют сделать это [38]. Однако все они оставляют открытой проблему качества обслуживания.

Для построения маршрутов необходимо решить несколько задач.

Первая: сколько и какие маршруты необходимы, чтобы удовлетворить требования качества сервиса BoD? Маршруты должны иметь минимальные пересечения по линиям связи и коммутаторам/маршрутизаторам. Это ограничение проистекает из особенностей работы алгоритмов управления перегрузкой на транспортном уровне в сети. Количество рёберно-непересекающихся путей между двумя вершинами в графе определяется теоремой Менгера [39], которая утверждает, что наибольшее количество непересекающихся по рёбрам маршрутов от вершины u к вершине v в графе равно наименьшему количеству рёбер в разрезе <u, v> этого графа.

Отсутствие пересечения маршрутов не всегда относится к критическим моментам. Например, если физическая линия на пересечении имеет достаточную пропускную способность, чтобы удовлетворить требованиям качества сервиса для всех проходящих через неё потоков, то эта линия, будучи пересечением маршрутов, критическим местом не является. Возможно, что в топологии сети нет альтернативных непересекающихся маршрутов между источником и пунктом назначения. Однако при наличии физических каналов с высокой пропускной способностью можно преобразовать граф топологии сети так, чтобы ребро, соответствующее такой линии, было заменено несколькими рёбрами с меньшей пропускной способностью. Альтернативным решением может быть поиск маршрутов с наименьшим количеством пересечений, как это делает алгоритм Min Cost Max Flow – MCMF [40].

После нахождения значения k – количества непересекающихся маршрутов, граф топологии сети обрабатывают специальным алгоритмом для определения k-маршрутов между источником и пунктом назначения. Оказалось, что для этого подходит далеко не каждый алгоритм. Например, жадный алгоритм [41] не решит эту проблему. Правильным выбором оказался алгоритм MCMF [42]. Он сводит исходную задачу к поиску максимального потока в сети. В результате набор маршрутов с ресурсами, достаточными для предоставления сервиса BoD, будет идентифицирован.

Вторая задача: как распределить ресурсы этих маршрутов при передаче прикладного потока, то есть как решить проблему AFLD (Applicaton Flow Load Distribution)? Она была разделена на три части: оценка ресурсов, распределение ресурсов и реализация рассчитанного распределения между найденными маршрутами. Решение первой даёт ответ на вопрос, достаточно ли доступной пропускной способности идентифицированных маршрутов для обеспечения нужного качества сервиса BоD? Если это так, то решение второй части проблемы даёт ответ на вопрос, как распределить нагрузку потока данных приложения между этими маршрутами. При решении третьей части приходится иметь дело с многопоточными протоколами, то есть использующими несколько маршрутов одновременно. Эти протоколы разделяют прикладной поток на несколько транспортных подпотоков, каждый из которых использует свой маршрут.

Существуют два основных подхода к многопоточной маршрутизации на транспортном уровне: статический и динамический. MPTCP – это статический подход [42], предполагающий априорное выделение определённого количества транспортных подпотоков (то есть маршрутов), между которыми распределяются сегменты прикладного потока. Динамический подход, например FDMP [43], использует динамическое выделение маршрута для подпотока по запросу транспортного агента в зависимости от соответствия общей пропускной способности текущего множества подпотоков требованию качества сервиса.

Для решения AFLD-проблемы была разработана математическая модель многопоточной передачи данных по требованию между ЦОДами при следующих предположениях:

• чтобы воспользоваться сервисом BoD, пара ЦОДов должна заключить контракт с оператором сети передачи данных, к которой подключены ЦОДы, где оговариваются максимально допустимые объёмы передаваемых данных и максимально допустимое для этого время, качество связи и т.д.;

• по одному и тому же контракту невозможно одновременное появление двух и более запросов на сервис BoD;

• вероятность распределения потоков запросов на сервис по каждому контракту известна.

На основе этой модели проблема AFLD была сформулирована как задача целочисленного линейного программирования (ЦЛП) с дискретным временем [16]. Её решение в форме ЦЛП дало ответы на следующие вопросы: достаточно ли имеющейся пропускной способности на выявленных маршрутах для удовлетворения всех потоков запросов при заданном наборе контрактов на определённом интервале времени? Как должна быть распределена пропускная способность на каждом маршруте между потоками, возникающими по требованию?

На базе маршрутизаторов Juniper VMX был построен прототип предложенных выше подходов к реализации сервиса BoD на основе технологии VPN, апробированный между ЦОДами на факультете вычислительной математики и кибернетики МГУ имени М.В. Ломоносова и ЦОДами Пекинского университета [3]. В апреле 2021 г. успешно завершился пилотный проект реализации сервиса BоD между ЦОДами в Москве и Новосибирске [44].

* * *

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

• высокий уровень управления ресурсами и гибкие возможности для определения виртуальных сред;

• возможность использовать имеющееся программное обеспечение исследователей;

• высокое качество планирования и эффективность использования ресурсов по критерию PST;

• освобождение пользователя от рутинных задач системного администрирования, а также определение единого способа описания жизненного цикла виртуализированного сервиса в ЦОД (или в HPC-кластере).

В ходе проекта экспериментально обоснована гипотеза о том, что можно получить сокращение среднего времени выполнения программ в облаке. Эксперименты продемонстрировали, что на определённых классах приложений можно получить до 20% сокращения времени.

Разработано новое решение проблемы выбора подходящего вычислителя MPI-программы в гетерогенной среде на основе критерия PST. Для этого был предложен новый подход к прогнозированию времени выполнения программы MPI на вычислителе, даже если она на нём никогда не выполнялась. Построены и проанализированы два алгоритма: базирующийся на группировке вычислителей с использованием корреляции Пирсона (для плотной матрицы “Программа–Вычислитель”) и основанный на технике разложения такой матрицы, позволяющий получать векторные представления (embedding) программы и вычислителя (для разреженной матрицы “Программа–Вычислитель”).

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

Кроме того, в ходе проекта МС2Е предложено и исследовано решение для построения сервиса BоD. Этот подход разделён на проблемы агрегации маршрутов и распределения прикладных потоков. Изучены разные варианты решения задачи агрегации маршрутов в зависимости от топологии сети и возможностей сетевого оборудования. Вопрос о распределении прикладных потоков между агрегированными маршрутами сформулирован и решён в виде задач ЦЛП.

Было бы наивно полагать, что представленные результаты полностью охватывают все проблемы, возникающие при создании информационно-вычислительных сред для междисциплинарных исследований. Перечислим лишь несколько из оставшихся за рамками проекта МС2Е: автоматизация запуска программ на различных вычислителях в среде, где есть ресурсы HPC-C и HPC-S; скоординированное управление данными и сетевыми ресурсами в реальном времени; мониторинг и аналитика, администрирование и безопасность в таких средах [45]; учёт потребляемых ресурсов; взаиморасчёты между участниками федерации; использование технологий периферийных вычислителей [46].