Планирование задач в распределённых

Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«Санкт-Петербургский государственный электротехнический
университет «ЛЭТИ» им. В.И. Ульянова (Ленина)»
На правах рукописи
Голубев Иван Алексеевич
Планирование задач в распределённых
вычислительных системах на основе метаданных
05.13.11 – Математическое и программное обеспечение вычислительных
машин, комплексов и компьютерных сетей
ДИССЕРТАЦИЯ
на соискание ученой степени
кандидата технических наук
Научный руководитель
доктор технических наук, профессор
Куприянов Михаил Степанович
Санкт-Петербург – 2014
Содержание
Введение
Глава 1.
4
Особенности построения современных систем плани­
рования задач в распределённых системах
8
1.1. Анализ предметной области и обзор научных публикаций . . . . .
8
1.1.1. Основные типы распределённых систем обработки . . . . .
8
1.1.2. Системы управления ресурсами и планировщики заданий .
14
1.1.3. Свойства задач и ресурсов в распределённых системах . .
20
1.1.4. Методы планирования использования ресурсов и выполне­
ния задач . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.2. Анализ распространённых промышленных планировщиков зада­
ний и систем управления ресурсами . . . . . . . . . . . . . . . . .
27
1.2.1. Система HTCondor . . . . . . . . . . . . . . . . . . . . . . .
27
1.2.2. Система DIET . . . . . . . . . . . . . . . . . . . . . . . . .
30
1.2.3. Программный стек ProActive . . . . . . . . . . . . . . . . .
32
1.2.4. Системы управления ресурсами Slurm и Torque . . . . . .
34
1.2.5. Планировщик Moab . . . . . . . . . . . . . . . . . . . . . .
35
1.2.6. Планировщик Maui . . . . . . . . . . . . . . . . . . . . . . .
38
1.3. Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Глава 2.
Использование метаданных для планирования в РСОД 42
2.1. Классификация метаданных . . . . . . . . . . . . . . . . . . . . .
42
2.2. Создание и хранение мультимедийных метаданных . . . . . . . .
44
2.3. Связь между метаданными и ресурсными требованиями . . . . .
48
2.4. Поиск близких задач . . . . . . . . . . . . . . . . . . . . . . . . . .
52
2.5. Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Глава 3.
Разработка теоретических основ планирования задач
в РСОД
59
3.1. Математическая модель планирования задач в РСОД . . . . . . .
60
2
3.2. Метод планирования задач в РСОД на основе метаданных и ре­
сурсных метрик . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
3.2.1. Вычисление ресурсных затрат выполнения на основе ре­
сурсных метрик . . . . . . . . . . . . . . . . . . . . . . . . .
67
3.2.2. Оценка ресурсных затрат на выполнение на основе мета­
данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
3.2.3. Вычисление матрицы назначения . . . . . . . . . . . . . . .
71
3.3. Модификация алгоритма поиска ближайших соседей на основе
метода локализованного хэширования . . . . . . . . . . . . . . . .
72
3.4. Методика планирования задач на основе метаданных и ресурсных
метрик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
3.5. Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
Глава 4.
Экспериментальная оценка эффективности предложен­
ного метода
81
4.1. Архитектура программной системы . . . . . . . . . . . . . . . . .
81
4.2. Задача декодирования видео данных . . . . . . . . . . . . . . . . .
87
4.2.1. Описание задачи . . . . . . . . . . . . . . . . . . . . . . . .
87
4.2.2. Инфраструктура и метаданные . . . . . . . . . . . . . . . .
88
4.2.3. Жизненный цикл метаданных . . . . . . . . . . . . . . . .
93
4.2.4. Оценка вычислительных затрат . . . . . . . . . . . . . . .
96
4.2.5. Обработка результатов эксперимента . . . . . . . . . . . .
99
4.3. Задача обработки гидрографических данных . . . . . . . . . . . . 114
4.3.1. Задача построения карт высот . . . . . . . . . . . . . . . . 114
4.3.2. Планирование задач обработки гидрографических данных 116
4.4. Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Заключение
125
Литература
127
3
Введение
Актуальность темы исследования
Cистемы планирования задач служат для решения проблемы эффективно­
го и гибкого назначения поступивших задач обработки данных на доступные
вычислительные ресурсы распределенных систем обработки данных (РСОД).
При развертывании и сопровождении РСОД основной проблемой яв­
ляется трудоёмкость настройки программного обеспечения, выполняющего
назначение задач на вычислительные ресурсы которая, как правило, связана
со следующими свойствами РСОД:
1. Разнородность задач по ресурсным требованиям, аппаратная гетероген­
ность вычислительных узлов и различная загрузка узлов РСОД требуют
специального учёта, что ведёт к созданию сложных политик планирова­
ния.
2. Отсутствие полной информации о ресурсных требованиях задач усложня­
ет принятие интеллектуальных решений по их планированию.
Широкое распространение кластерных систем, грид-систем и облачных си­
стем связано с увеличением числа решаемых прикладных задач и значитель­
ным возрастанием нагрузок на вычислительные системы. Поставщики сетевых
сервисов, опираясь на крупные консолидированные центры обмена данных, осо­
бое внимание стали уделять совершенствованию методов планирования задач
обработки данных.
Требования сокращения временных издержек на решение прикладных за­
дач, упрощения процедуры сопровождения распределенных систем обработки
данных в существующих условиях обосновывают актуальность разработки
новых методов планирования задач в РСОД.
Объектом исследования являются системы планирования задач в РСОД.
Предметом исследования выступают методы планирования задач, ко­
торые используются в системах планирования для РСОД.
4
Целью диссертационной работы является сокращение временных за­
трат на выполнение задач в РСОД в условиях неполноты информации о ресурс­
ных требованиях.
Для достижения поставленной цели были сформулированы и решены сле­
дующие задачи:
1. Анализ существующих методов планирования задач обработки данных в
РСОД.
2. Разработка математической модели планирования задач в РСОД.
3. Разработка метода планирования задач в РСОД.
4. Решение проблемы поиска ближайших задач с учётом разнородности ат­
рибутов и их значимости для ресурсопотребления.
5. Разработка методики планирования задач в РСОД.
6. Проведение экспериментов по распределению задач обработки данных по
ресурсам РСОД на основе предложенного метода.
Методология и методы исследования
Использовались методы машинного обучения, теории алгоритмов, матема­
тической статистики и теории множеств.
Научная новизна
1. Предложена математическая модель планирования задач в РСОД, отли­
чающаяся от существующих совместным учётом метаданных и метрик
загрузки ресурсов при отображении задач на вычислительные ресурсы.
2. Предложен метод планирования задач в РСОД, отличающийся от суще­
ствующих учетом метаданных из предыстории выполнения, которые удо­
влетворяют критерию близости.
3. Предложена модификация алгоритма поиска ближайших соседей на ос­
нове метода локализованного хэширования, отличительной особенностью
которого является учёт типов атрибутов и их значимости для ресурсопо­
требления.
Практическая значимость
5
1. Предложена методика планирования задач в РСОД, которая позволяет
сократить временные затраты на выполнение задач в условиях неполноты
информации о ресурсных требованиях.
2. Разработана архитектура программной системы планирования задач в
РСОД, которая реализует предложенный метод планирования.
Положения, выносимые на защиту:
1. Математическая модель планирования задач в РСОД.
2. Метод планирования задач в РСОД.
3. Модификация алгоритма поиска ближайших соседей.
Степень достоверности и апробация результатов
Достоверность результатов диссертационной работы подтверждается кор­
ректным применением математического аппарата, результатами машинного экс­
перимента на гетерогенном кластере и практической апробацией.
Основные положения и результаты диссертационной работы докладыва­
лись и обсуждались на 5 международных научно-технических конференциях.
Внедрение результатов:
Полученные научные и практические результаты использовались при вы­
полнении следующих работ:
1. НИP «Разработка теоретических основ проектирования сервисно-ориенти­
рованной информационно-аналитической системы анализа данных на ба­
зе технологии облачных вычислений». СПб ГЭТУ. Проект №2.1.2/12448.
Сроки: 2011.
2. НИР «Создание высокопроизводительных вычислительных технологий
для интеллектуальных систем оперативной обработки и визуализации гид­
роакустической информации». СПб ГЭТУ. Сроки: 2012-2013.
3. НИР «Разработка математического аппарата априорной оценки работы
алгоритмов интеллектуального анализа в гетерогенной распределенной
среде». СПб ГЭТУ. Проект №01201155585. Сроки: 2011-2013.
4. НИР «Организация производства систем гидроакустического мониторин­
6
га акватории на базе покровных антенн в местах размещения нефте- и
газодобывающих платформ в районе Арктического шельфа». СПб ГЭТУ.
Проект №13.G25.31.0054. Сроки: 2010-2012.
Публикации
Основные теоретические и практические результаты диссертации опубли­
кованы в 20 печатных работах, среди которых 4 статьи в ведущих рецензи­
руемых изданиях, рекомендуемых в действующем перечне ВАК, 2 раздела в
2-х монографиях, 5 работ – в материалах международных научно-технических
конференций, 9 свидетельств о регистрации программ для ЭВМ1 .
Структура и объем диссертации
Диссертация состоит из введения, 4 глав, заключения и библиографии.
Общий объем диссертации 135 страниц, из них 126 страниц текста, включая 30
рисунков и 8 таблиц. Библиография включает 82 наименования на 9 страницах.
1
Часть программных свидетельств получена до смены фамилии. Свидетельство о перемене имени с
Громов И.А. на Голубев И.А. I-AK № 539834.
7
Глава 1
Особенности построения современных систем
планирования задач в распределённых системах
В настоящей главе рассматриваются типы распределённых систем обра­
ботки данных и основная терминология. Анализируются основные компонен­
ты современных систем планирования ресурсов и заданий и основные методы
планирования, которые изложены в литературе или реализованы программно
в планировщиках вычислительных ресурсов и заданий распространённых на
практике.
1.1. Анализ предметной области и обзор научных
публикаций
1.1.1. Основные типы распределённых систем обработки
Потребность в сетевых вычислительных ресурсах существенно возросла в
последнее десятилетие во многих прикладных областях. Сетевые приложения
порождают постоянно возрастающую нагрузку на сервера и кластеры, предо­
ставляющие услуги, с ростом числа задач решаемых в сети. Такие задачи связа­
ны с электронной коммерцией, финансовыми расчетами, социальными сетями,
услугами приобретения и распространения мультимедийных данных (фото, ви­
део, аудио).
Существующие поставщики облачных сервисов в основном опираются на
крупные консолидированные ЦОД для предоставления своих услуг. В связи
с этим широкое распространение получили системы параллельной и распреде­
лённой обработки данных: вычислительные кластеры, грид системы и облачные
системы. Ниже будут кратко приведены определения каждой из них.
8
Применение данных типов систем для научных вычислений и для решения
прикладных задач привело к возрастанию нагрузки на конечные аппаратные
ресурсы в связи с необходимостью анализа и решения всё более вычислитель­
но и пространственно трудоёмких задач. Такие задачи зачастую имеют весьма
неравномерные требования в отношении потребляемых вычислительных ресур­
сов.
Всё вышеописанное накладывает особые требования при проектировании
распределённых систем обработки данных (РСОД), чтобы позволить предоста­
вить указанные услуги в разумное время для всевозрастающего числа пользо­
вателей.
Приведём определения указанных систем обработки данных.
Под кластером подразумевают группу компьютеров, объединённых высо­
коскоростными каналами связи и представляющих с точки зрения пользователя
единый аппаратный ресурс [1].
Как правило узлы кластерных систем не распределены географически и их
управление осуществляется с помощью промежуточного программного обеспе­
чения (ПО) централизованным способом: существует единый узел, отвечающий
за управление ресурсами и распределение задач по узлам.
Данные системы применяются для научных вычислений и для решения
коммерческих прикладных задач, поскольку являются экономичнее и надежнее
(за счёт избыточности) специализированных централизованных мейнфреймов.
Кластеры могут быть однородными по составу аппаратного обеспечения или со­
стоять из набора разных по конфигурации (гетерогенных) узлов-обработчиков.
Схематично кластерная система изображена на Рисунке 1.1.
На вход системы поступают прикладные задачи обработки, которые могут
иметь существенно различающиеся ресурсные требования. Непосредственной
обработкой данных занимаются распределённые узлы кластера. Планировщик
задач отвечает за сопоставление задач имеющимся в доступе вычислительным
ресурсам. Более подробно данная система будет рассмотрена в следующем раз­
9
Рисунок 1.1. Высокоуровневое представление кластерной РСОД
деле.
Под грид системой (от англ. grid - сетка) или метакомпьютером понимают
сеть гетерогенных вычислительных ресурсов, географически распределённых,
используемых для параллельной обработки вычислительных задач [1]. Грид
представляет собой программно-аппаратную инфраструктуру для разделяемо­
го использования вычислительных узлов, сетей, баз данных и других ресурсов,
которые находятся в юрисдикции различных географически распределённых
организаций [2]. Для управления ресурсами используется промежуточное ПО,
причём управление как правило - децентрализованное.
Отличительными свойствами грид систем являются [3]:
1. Распределённость компонентов - узлы системы могут находиться в геогра­
фически удалённых друг от друга регионах, что сказывается на оператив­
ности взаимодействия;
2. Метакомпьютер может динамически менять конфигурацию - система под­
держки прозрачно для пользователя производит распределение задач по
компонентам системы с учётом динамического подключения/отключения
удалённых ресурсов;
10
3. Неоднородность системы - в состав грид системы могут входить узлы с
различным составом программно-аппаратных ресурсов;
4. Метакомпьютер объединяет ресурсы различных организаций, каждая из
которых может иметь собственную политику доступа к ресурсам.
С точки зрения пользователя отличительной чертой таких систем явля­
ется отсутствие контроля над множеством задач обрабатываемых на каждом
конкретном узле. Кроме того заранее неизвестно, какими ресурсами будет рас­
полагать система в определённый момент. Также важной отличительной чертой
является нацеленность грид систем на решение вычислительно трудоёмких на­
учных задач.
Облачные вычисления - общий термин для целого ряда сетевых сервисов,
предоставляемых по требованию, для которых наиболее характерными являют­
ся следующие свойства [4]:
1. Самообслуживание по-требованию - клиент имеет возможность получить
доступ к вычислительным ресурсам в любой момент без необходимости
человеческого вмешательства со стороны провайдера.
2. Сервисы предоставляются по сети стандартными механизмами и нацеле­
ны на использование на гетерогенных клиентских платформах (ноутбу­
ках, мобильных устройствах, рабочих станциях).
3. Объединение физических ресурсов (серверов, устройств хранения дан­
ных, сетей и пр.) на стороне поставщика сервисов в единый пул, что поз­
воляет их динамически перераспределять в условиях постоянно изменяю­
щегося спроса.
4. Эластичность - услуги (или динамическая расширяемость) могут быть
предоставлены, расширены или сужены по требованию в любой момент
времени, зачастую в автоматическом режиме. Для конечных клиентов
данное свойство позволяет получать сервисы с высоким уровнем доступ­
ности.
5. Оплата услуг выполняется исходя из учёта затраченных ресурсов.
11
Облачные сервисы могут предоставляться в соответствии со следующими
моделями обслуживания [5]:
1. Программное обеспечение как услуга (SaaS, англ. Software-as-a-Service) модель в которой пользователь абстрагируется от всех деталей поддержки
приложения: аппаратного обеспечения, распределённости данных, исполь­
зуемых программных средств и др., - и получает в качестве услуги гото­
вое к использованию программное обеспечение, предоставляемое по сети.
Наиболее характерным примером таких услуг могут выступать сервисы
предоставления или обработки данных, которые доступны как SOAP или
REST веб-сервисы, и могут использоваться программным способом.
2. Платформа как услуга (PaaS, англ. Platform-as-a-Service) - модель, в ко­
торой пользователь абстрагируется от аппаратной части поддержки при­
ложения и получает возможность управлять заранее подготовленным на­
бором информационно-технологических платформ: операционными систе­
мами, базами данных, средствами разработки и тестирования и др., - и
имеет возможность устанавливать и использовать собственное приклад­
ное программное обеспечение.
3. Инфраструктура как услуга (IaaS, англ. IaaS or Infrastructure-as-a-Service)
- модель, в которой клиент предоставляется возможность управлять вир­
туальными ресурсами - виртуальными машинами, виртуальными сетями,
а также балансировкой нагрузки, межсетевыми экранами и пр. Постав­
щик услуги предоставляет гибкие механизмы доступа к пулу ресурсов, а
также хранения и перенастройки заранее сконфигурированных виртуаль­
ных машин.
Облачные системы предоставляют дополнительный уровень абстракции,
который позволяет отделить задачи обслуживания аппаратного и программно­
го обеспечения от прикладных задач использования предоставляемых ресурсов.
В результате конфигурированием и системным администрированием занимают­
ся специально подготовленная группы специалистов, а конечные клиенты лишь
12
получают по требованию, а затем высвобождают заданные количества аппарат­
ных ресурсов и заранее сконфигурированного ПО.
Данный подход позволяет экономить финансовые средства на стороне про­
вайдера облачных услуг благодаря масштабам производства, а также на стороне
клиентов в соответствии с принципом использования ресурсов по требованию.
На стороне провайдера решаются во многом схожие с кластерными системами
технические задачи.
В настоящей работе исследуются методы планирования задач, которые мо­
гут быть применены для всех указанных типов распределённых систем, бла­
годаря использованию дополнительного уровня абстракции - системы управ­
ления ресурсами, которая скрывает низкоуровневые различия и предоставляет
ресурсы для выполнения задач. В терминологии облачных вычислений система
управления ресурсами соответствует модели обслуживания Инфраструктура
как услуга (IaaS).
Объектом исследования в данной работе выступают распределённые
системы, которые находятся под управлением систем управления ресурсами:
вычислительные кластеры, грид системы, облачные системы. Данная работа
посвящена анализу и повышению производительности РСОД, выполняющих об­
работку разнородных по ресурсным требованиям задач. Иными словами пред­
метом исследования являются методы планирования назначением ресурсов
на задачи обработки данных.
Значительное число исследований [6] показало, что современные вычисли­
тельные нагрузки высокоизменчивы, и характеризуются особым распределени­
ем: множество небольших задач (или запросов) с малыми ресурсными требо­
ваниями и сравнительно небольшое множество крупных задач с непропорцио­
нально высокими требованиями к потребляемым ресурсам. Интеллектуальное
планирование распределением задач по узлам обработки, обеспечивающее эф­
фективное использование ресурсов становится чрезвычайно актуальным при
таких характеристиках задач.
13
С учётом данных особенностей в настоящей работе основное внимание уде­
ляется анализу, математическому моделированию и улучшению методов плани­
рования задач в условиях и с учётом:
1. Разнородности задач;
2. Гетерогенности узлов РСОД;
3. Метаданных задач;
4. Истории выполнения задач.
В следующем разделе проведён анализ существующих наработок по дан­
ным проблемам как в кластерных системах, грид системах, так и в так называ­
емых облачных средах.
1.1.2. Системы управления ресурсами и планировщики заданий
Задание представляет собой сущность, которая поступает на вход системы
планирования и состоит из набора задач (см. Рисунок 1.2). Поток задач поступа­
ет во входную очередь. Задачи являются атомарной единицей планирования и
в рамках одного задания могут быть независимыми или организованы в дерево
зависимостей.
Соответственно такие задачи или выполняются параллельно если они неза­
висимы, или последовательно при наличии зависимостей. Зависимости опреде­
ляют порядок выполнения работ и потоки данных между задачами.
Поскольку в дальнейшем будут рассматриваться только независимые зада­
чи, которые могут планироваться отдельно, между терминами задание и задача
в данной работе не будет поставлено различий.
Проблема планирования задач обработки состоит из выделения ресурсов
(узлов обработки) для задач и установления порядка в котором задачи из вход­
ной очереди будут выполняться на этих ресурсах [7].
Класс систем, в которых осуществляется централизованное управление ре­
сурсами получил название системы управления ресурсами [8], который, как
правило тесно интегрируется с системой планирования задач или планировщи­
14
Рисунок 1.2. Состав потока входных данных для систем планирования
ком задач [9].
Система управления ресурсами и планировщик задач вместе представляют
собой промежуточное программное обеспечение: с одной стороны оно должно
управлять ресурсами (на низком уровне), а с другой - учитывать требования
прикладных задач (описанных на высоком уровне). Для этого на этапе функци­
онирования система выполняет мониторинг текущего состояния загруженности
ресурсов и затем производит назначение свободных ресурсов на поступившую
задачу [8].
Система управления ресурсами обычно включает в себя информационный
сервис, отвечающий за сбор информации о состоянии выполнения задач и о
состоянии ресурсов. Иногда данные функции на себя берёт сторонняя система
мониторинга.
Для управления ресурсами и задачами планировщик, опираясь на данные,
предоставляемые информационным сервисом, использует методы управления
15
(планирования) задачами и ресурсами.
Метод или политика планирования задач (task scheduling policy) представ­
ляет собой набор правил, которые используются для определения когда и как
выбирать новую задачу (процесс) на обработку [10]. В основе выбора задачи на
исполнение лежит процедура сортировки задач в соответствии с их приорите­
тами.
Для планирования задач, как правило, используется та или иная дисципли­
на обслуживания. Выделяют дисциплины обслуживания, которые опираются
на знания о ресурсных требованиях задачи и без априорных знаний, когда все
задачи обрабатывают универсальным способом.
Дисциплины обслуживания без априорных знаний [6]:
1. First in First Out, FIFO, - задачи обрабатываются в порядке поступления.
2. Last in First Out, LIFO, - задачи обрабатываются в обратном порядке.
3. Random Selection for Service (RSS), - задача выбирается случайным обра­
зом.
4. Time Sharing, с разделением времени - квант времени выделяется каждой
задаче поочерёдно.
5. Least Attained Service - выбирается задача, получившая наименьшее время
обслуживания.
К недостаткам приведённых дисциплин обслуживания можно отнести сле­
дующее:
1. Они не стремятся подобрать узел соответствующий ресурсным требовани­
ям;
2. Решают другую задачу: какую задачу из очереди выбрать первой для
обработки в соответствии с приоритетом или другими критериями;
3. Предполагают однотипность задач в плане ресурсных требований (вычис­
лительной и пространственной трудоёмкости);
4. Предполагают использование однотипных узлов-обработчиков (количество
ресурсов на каждом узле одинаково).
16
При использовании данных подходов ресурсы используются неэффективно
в случаях, когда:
1. Узлы РСОД различаются по мощности (гетерогенность РСОД);
2. Задачи разнородны по вычислительной и пространственной (по памяти)
сложности, и, следовательно имеют сильно отличающиеся ресурсные тре­
бования;
3. Узлы РСОД могут исполнять параллельно несколько задач.
Если ресурсные требования заданы заранее, то могут применяться следу­
ющие дисциплины обслуживания [6]:
1. Shortest Job First (SJF), - выбирается задача с наименьшими ресурсными
требованиями.
2. Shortest Remaining processing time, - выбирается задача, для которой оце­
нённое время обслуживания минимально.
Данные дисциплины обслуживания учитывают разнородность задач, но
требуют априорных знаний о ресурсных требованиях, которые не всегда до­
ступны.
Другой аспект приведённых методов планирования задач – поддержка со­
хранения состояния выполнения задач, что позволяет прерывать выполнение
текущей задачи и переключаться на выполнение другой (например более при­
оритетной). Такие методы как Time Sharing, Least Attained Service, Shortest
Remaining Processing Time относятся к данному классу методов планирования
задач, за счёт чего на каждом вычислительном узле могут находиться несколь­
ко задач на разных стадиях выполнения.
Реализация сохранения состояния задач широко применяется для плани­
рования процессов в операционных системах, когда нескольким процессам вы­
деляется последовательно квант процессорного времени для создания псевдо­
параллелизма. Вместе с тем такая стратегия привносит дополнительные на­
кладные расходы и может быть неприемлема для прерывания вычислительно
трудоёмких задач. В связи с этим данный класс методов лежит за пределами
17
исследования настоящей диссертации.
Следующий этап планирования - для каждой выбранной задачи применяет­
ся метод выбора узла (node allocation policy), который определяет оптимальный
набор ресурсов для выделения на задачу обработки данных. Методы управле­
ния ресурсами строятся с учётом состояния каждого узла/ресурса распреде­
лённой среды, а также в соответствии с заранее установленными требованиями
приложений [8].
Подходы к назначению узлов (ресурсов) на задачи также разняться в за­
висимости от доступной априорной информации:
1. Наименее использованный узел (Least Recently Used Node/Server) , - вы­
брать наименее загруженный или неиспользуемый узел.
2. Случайный выбор (Random Selection), - узел-обработчик выбирается слу­
чайным образом.
3. На основе теории массового обслуживания (Queue metrics based), - вы­
брать узел с наименьшей длиной очереди или средним временем ожида­
ния обработки.
4. Оценка оставшегося времени выполнения (Elapsed-time prediction), - вы­
брать узел с наименьшим прогнозируемым временем выполнения.
5. Прогнозирование ресурсопотребления (Resource consumption prediction), выбрать узел, наиболее соответствующий прогнозу потребления ресурсов.
Основным недостатком используемых методов планирования является рас­
смотрение процесса выбора задачи и процесса выбора узла как независимых
этапов планирования. Сначала выбирается наиболее приоритетная задача, а
затем для неё выбирается наиболее подходящий узел.
Несмотря на то, что на каждом отдельном этапе принимается локально
оптимальное решение, глобальный процесс отображения множества задач на
множество узлов зачастую не оптимален. Для поиска оптимального назначения
группы задач на группу узлов требуется рассматривать указанные процедуры
планирования в рамках одного этапа.
18
Исходя из проделанного обзора можно сделать вывод о необходимости раз­
работки новых методов планирования задач в РСОД в условиях неполноты
информации о ресурсных требованиях, позволяющих сократить временные за­
траты на выполнение прикладных задач обработки данных.
Для этого в настоящей работе предлагается проанализировать связь между
атрибутами задач (метаданными) и метрическими характеристиками использо­
вания вычислительных ресурсов.
Рисунок 1.3. Область исследования
Схематично область место исследований настоящей диссертационной рабо­
ты обозначено красным цветом на Рисунке 1.3, где в качестве подписей приве­
дены названия распространённых методов планирования.
Иными словами в работе проводится исследование методов планирования
независимых задач без поддержки сохранения состояния выполнения и в усло­
виях неполноты информации о ресурсных требованиях задач.
19
1.1.3. Свойства задач и ресурсов в распределённых системах
В общем случае запускаемые в вычислительной системе приложения имеют
разные требования к вычислительным узлам. К примеру, в случае виртуализа­
ции сетей, запрос на создание виртуальной сети может быть описан с учётом
ограничений, накладываемых на узлы сети (напр. процессор и физическое рас­
положение) и на связи (напр. задержка, пропускная способность и джиттер).
Традиционные требования, которые предъявляются со стороны приложе­
ний:
1. Сетевые требования (пропускная способность и задержка);
2. Конфигурационные требования (процессор и память);
3. Права доступа к определённым программным ресурсам.
Информационный сервис, который предоставляет данные о состоянии ре­
сурсов, опирается на модель ресурсов, о которой будет сказано ниже.
Таким образом, на вход метода выделения ресурсов подаются следующие
данные:
1. Физические и виртуальные ресурсы;
2. Требования приложений;
3. Модели ресурсов.
Рассмотрим вопрос моделирования ресурсов РСОД. Под моделированием
ресурсов понимается разбитие доступных аппаратных ресурсов (памяти, про­
цессора, пропускной способности сети и т.п.) на виртуальные части. К приме­
ру память может делиться на части в 32 Mb или 512 Mb, пропускная способ­
ность сети делиться по 0.25 Mb/s, а процессора можно предоставлять как цели­
ком, так и разделяя ядра одного процессора между прикладными приложени­
ями. При этом чрезмерно детализированное описание ресурсов может излишне
усложнить работу на стадии планирования ресурсов и оптимизации [8] .
Кластерные ресурсы, зачастую характеризуются гетерогенностью: различ­
ные архитектуры, программное и аппаратное обеспечение. В связи с этим, раз­
20
работка адекватной ресурсной модели является первой задачей, которую необ­
ходимо решить при разработке системы выделения ресурсов [8].
Важно учитывать, что моделирование ресурсов не обязано привязываться
к тому, каким образом они предоставляются конечным пользователям. К приме­
ру, провайдер может моделировать каждый ресурс индивидуально по мелкогра­
нулированной шкале (количество гигагерц процессора или гигабайт памяти), но
предоставлять их в определённой комплектации в качестве классов виртуаль­
ных машин (типы с большим объёмом памяти или высокопроизводительные с мощным процессором).
В работе [8] отмечается что на этапе создания системы необходимо строить
модели ресурсов исходя из типов предоставляемых сервисов.
К примеру в решении Elastic Computing Cloud от Amazon выделяются клас­
сы арендуемых машин (instance families): общего назначения, оптимизирован­
ные по производительности процессора, с большим объёмом основной памяти
(RAM), c большим объёмом внешней памяти и оптимизированные под графи­
ческую обработку1 . Кроме того, в каждом классе машин идёт разделение по
мощности (instance types): малые, средние, большие, сверхбольшие и т.п.
1.1.4. Методы планирования использования ресурсов и выполнения
задач
Авторы статьи [8] также делят стратегии выбора ресурсов на апостериор­
ные и априорные.
Для апостериорных стратегий, после того, как было выполнено изначаль­
ное назначение ресурсов (которое может и не быть оптимальным), управление
назначением ресурсов продолжается с целью улучшения первичного решения.
При необходимости принимаются такие меры, как добавление или переназначе­
ние ресурсов с целью оптимизации использования системных ресурсов или для
того чтобы удовлетворить требованиям конечных пользователей.
1
Amazon EC2 instance types.
21
К примеру в статье [8] отмечается существование т.н. правил масштаби­
рования, которые задают каким образом и в каких ситуациях приложение по­
требляет больше вычислительных ресурсов и требует масштабирования. Поль­
зователи облачной среды имеют возможность задать правила, определяющие
те действия, которые необходимо произвести (например запуск новой виртуаль­
ной машины) при превышении допустимых пороговых значений собираемых
метрик.
Априорные же стратегии находят единственное решение о выделении ре­
сурсов, которое считается оптимальным. Для достижения этого стратегия долж­
на учитывать все переменные, которые могут влиять на способ выделения. К
примеру, при выделении виртуальных машин, стратегия оптимизации должна
предоставить решение (или множество возможных решений), которое удовле­
творяет всем ограничениям и требованиям (минимизации времени или ресурс­
ных затрат на выполнение) оптимальным способом.
Большинство существующих алгоритмов планирования задач исходит из
предположения, что время выполнения приложения (задачи) известно заранее,
ещё до выполнения [9]. Данное предположение существенно упрощает сопостав­
ление задач и ресурсов, хотя и показало свою несостоятельность для многих
реальных приложений. С другой стороны, существует целая группа приклад­
ных приложений, для которых есть возможность мониторинга исполнения. За­
частую, когда существует корреляция между состоянием выполнения задачи
и общим временем её выполнения, информация о текущем состоянии может
выступать основой для прогнозирования оставшегося времени выполнения.
Многие из предложенных алгоритмов, которые выполняют оценку времени
выполнения и прогнозирование загрузки ресурсов, основаны на статистических
моделях [11].
Использование истории предыдущих запусков для построения моделей про­
гнозирования для кластерных и облачных платформ не является новой идеей
[11]. Помимо автоматического масштабирования ресурсов, данные модели при­
22
меняются совместно с генерацией синтезированной нагрузки для тестирования
различных политик масштабирования.
Решения о масштабировании на практике безусловно не основываются лишь
только на истории предыдущих запусков, т.к. необходимо принимать во внима­
ние ресурсные затраты на выделение новых ресурсов, накладные расходы на
миграцию задач и многие другие факторы.
Помимо методов управления ресурсами выделяют два различных типа пла­
нирования задач: статический и динамический. Статические стратегии опреде­
ляют план на стадии планирования или выполняют запуск на основе инфор­
мации о доступных узлах обработки и задач для запуска. В качестве цели ста­
тического планирования выступает минимизация ожидаемой длительности вы­
полнения задач.
Динамические стратегии, с другой стороны, применяются в тех случаях,
когда время прибытия неизвестно априори и потому система вынуждена назна­
чать ресурсы по прибытию задач. В качестве цели динамического планирова­
ния может выступать как минимизация длительности обработки пакета за­
дач, так и минимизация некоторой метрики производительности, отражающей
качество предоставляемого сервиса (QoS).
Динамический подход к планированию означает, что планировщик спосо­
бен менять стратегию планирования при появлении новых задач и освобожде­
нии узлов обработки.
При статическом планированиии, которое, как правило, выполняется на
этапе подготовки запуска, характеристики параллельной программы (время об­
работки задач, зависимости данных, требования синхронизации и пр.) извест­
ны заранее. При динамическом планировании, решения о планировании прини­
маются на этапе выполнения на основании информации о состоянии системы
(метрик), в связи с чем дополнительно появляется проблема минимизации на­
кладных расходов на планирование [12].
Методы динамического планирования состоят из стратегии планирования
23
и алгоритма планирования [13, 14]. Стратегия планирования описывает ситу­
ации в которых вызывается алгоритм планирования. Алгоритм планирования
составляет план на основе информации о состоянии машин, и информации об
очереди задач в очереди ожидания на момент вызова.
Как указано в [15] стратегии динамического планирования делятся на две
категории: немедленной обработки и пакетной обработки. В первом случае толь­
ко вновь прибывшая задача рассматривается планировщиком, в то время как в
пакетном режиме планировщик управляет как вновь прибывшей задачей, так
и задачами из очереди ожидания обработки.
Используемые алгоритмы планирования основаны на различных допуще­
ниях, различаются по функциональности и, в следствие этого имеют различаю­
щиеся сценарии применения. В работе [12] проведена попытка систематизации
27 существующих алгоритмов. В целом к задаче планирования выполнения па­
кетов заданий для параллельной обработки выделяют два основных подхода:
1. Планирование независимых задач;
2. Планирование задач с зависимостями (описанных в виде направленного
ацикличного графа).
В работе [7] отмечается, что существующие наработки в области динамиче­
ского планирования в гетерогенных кластерах рассматривают исключительно
независимые задачи и назначают единственную задачу на каждый узел обра­
ботки. В связи с этим авторы отмечают актуальность исследования методов,
которые учитывают зависимости между задачами в виде направленных ацик­
личных графов.
Например, в статье [9] производится оценка производительности и оптими­
зация для существующего алгоритма адаптивного планирования в грид-систе­
мах. Алгоритм обрабатывает задачи, имеющие перекресные зависимости, кото­
рые можно описать направленным ацикличным графом, для которых отсут­
ствует информация об общем времени выполнения.
Авторы в статье [12] также исследуют вопрос планирования задач с зави­
24
симостями.
В настоящей же работе основной акцент сделан на упрощение процедуры
инсталляции промежуточного ПО для РСОД, в связи с чем рассматривается
только проблема планирования независимых задач.
Как уже отмечалось, все указанные методы планирования как правило ре­
ализуются на уровне промежуточного программного обеспечения между при­
кладным и системным программным обеспечением. В статье [16] предлагает­
ся эвристика для повышения эффективности (минимизации времени решения
задач и оптимизации использования ресурсов) промежуточного программного
обеспечения на основе стандарта GridRPC, который служит для планирования
клиентских запросов. Предложенная модель позволяет выполнить оценку дли­
тельности всех задач системы. Помимо клиентов и серверов авторы выделяют
компонент называемый реестром, что соответствует планировщику в других
статьях. Реестр отвечает за отображение пользовательских запросов на серве­
ра в соответствии с определёнными критериями.
Авторы отмечают, что популярный алгоритм планирования Minimum Completion Time разработан с целью минимизации длительности выполнения прило­
жения, но не способен оптимизировать какой-либо иной критерий, как напри­
мер время отклика отдельного запроса. Кроме того, алгоритм требует знаний
о состоянии сети и серверов обработки, что несёт дополнительные накладные
расходы и допускает возможность принятия решении о планировании на основе
устаревшей информации о состоянии.
В указанной работе предлагается подход на основе модели разделения вре­
мени (time sharing), который позволяет прогнозировать длительность выполне­
ния отдельно выбранной задачи на выбранном сервере и влияние на длитель­
ность задач уже запущенных на данном узле обработки. В настоящей работе
также производится прогнозирование метрик для выбранной задачи на выбран­
ном узле, но вместо модели разделения времени используется независимая об­
работка задач на узлах распределённой системы (задача занимает выделенный
25
ей ресурс целиком).
Различают также методы, учитывающие выход из строя компонентов систе­
мы и не учитывающие. Для предлагаемых в настоящей работе решений выход
из строя компонентов системы не является ограничивающим, поскольку данная
проблема может быть решена независимо на других уровнях за счёт наличия
дополнительных резервных компонентов.
Некоторые методы основаны на предположении, что нагрузка на каждый
ресурс остаётся неизменной на время выполнения прикладной задачи [9]. В дан­
ной работе такое предположение не делается: используются средние величины
загрузки ресурсов.
В статье [9] подчеркивается, что планирование и выделение ресурсов для
задач является актуальной задачей, поскольку некорректное планирование за­
дач может привести к неэффективному использованию аппаратных ресурсов.
В качестве цели планирования авторы отмечают корректное назначение задач
на узлы обработки.
Авторы в статье [17] отмечают, что установление соответствия между при­
ложениями и вычислительными ресурсами в грид системах является трудоём­
кой задачей ввиду гетерогенности ресурсов и динамичности изменения состо­
яния загрузки ресурсов в системе. В связи с этим предлагается использовать
искусственную нейронную сеть для прогнозирования состояния узлов обработ­
ки. В работе сравниваются два алгоритма прогнозирования на основе нейрон­
ных сетей. Авторы используют статический подход к планированию: делается
допущение о том, что время выполнения задач может быть оценено на стадии
планирования до реального запуска задач.
Идея, что для повышения качества планирования длительные по прогнози­
руемому времени задачи [9] назначаются на более производительные ресурсы,
чем короткие по времени задачи, для которых достаточно низкопроизводитель­
ных ресурсов, может быть обобщена следующим образом: чем более точно вы­
деленные для задачи ресурсы соответствуют её ресурсным требованиям тем
26
выше эффективность использования ресурсов и ниже среднее время обработки
заявок.
Описанный в работе метод призван повысить рациональность использова­
ния аппаратных ресурсов РСОД (resource utilization) и сократить суммарное
время выполнения пакета задач при условии гетерогенности узлов обработки:
в данном случае обработчики отличаются лишь количеством процессоров.
В последующих разделах проведён анализ основных систем управления
ресурсами и планировщиков заданий, используемых на практике.
1.2. Анализ распространённых промышленных
планировщиков заданий и систем управления
ресурсами
1.2.1. Система HTCondor
Несмотря на то, что персональное владение вычислительными ресурсами
предоставляет известные удобства для конечных пользователей, загрузка вы­
числительных мощностей в таких случаях, как правило, остаётся крайне низ­
кой и неэффективной: большинство персональных компьютеров простаивает в
течение длительных интервалов времени.
Программное обеспечение HTCondor создавалось с целью решить суще­
ствующую задачу загрузки всех доступных ресурсов, путём создания среды об­
работки данных с высокой пропускной способностью (High-Throughput Computing)
из индивидуальных рабочих станций и вычислительных кластеров. В целом,
HTCondor является специализированной пакетной системой для управления вы­
числительно ёмкими задачами. Как большинство пакетных систем, HTCondor
предоставляет механизм очередей, политики планирования, схему приоритетов
и классификацию ресурсов.
HTCondor может планировать выполнение задач на выделенных рабочих
27
станциях, как и большинство пакетных систем, но в отличие от традиционных
пакетных систем, также способен выполнять эффективную загрузку разделяе­
мых машин для выполнения задач [18].
HTCondor обладает следующими возможностями:
1. Находить доступные машины для поступивших задач;
2. Поддерживать хранение промежуточного состояния выполнения задач;
3. Поддерживать миграцию исполняемых задач между машинами;
4. Осуществлять управление доступными ресурсами путём отображения по­
требителей ресурсов на источники, предоставляющие ресурсы, с помощью
системы извещений;
5. Поддерживать упорядоченное выполнение группы взаимозависимых за­
дач, описанной направленным ацикличным графом.
В рамках данной диссертации особый интерес представляет именно ме­
тод отображения ресурсов на задачи обработки, который в HTCondor получил
название ClassAds. Все рабочие станции, которые находятся в пуле ресурсов
HTCondor, публикуют (advertise) информацию о статических и динамических
свойствах ресурсов, таких как количество памяти, тип процессора, тактовая
частота процессора, объём виртуальной памяти, физическое расположение ма­
шины, а также средняя текущая загрузка [18]. Кроме того, указывается при
каких условиях принимаются задачи на выполнение и какие задачи для данной
рабочей станции являются предпочтительными (например, выполнять задачи
только в ночное время, когда устройства ввода не используются).
Пользователь, со своей стороны, задаёт запрос на ресурсы при отправке за­
дачи обработки данных. В запросе определяются как необходимые, так и пред­
почтительные свойства ресурсов для выполнения данной задачи.
HTCondor выступает в качестве посредника, который подбирает и упорядо­
чивает в порядке значимости пары запрос на ресурсы - предложение ресурсов
(resource Ads).
Для сортировки используются несколько уровней приоритетов:
28
1. Приоритет, который пользователь назначил задаче обработки данных;
2. Приоритет самого пользователя;
3. Предпочтения определённым типам задач, которые заданы в описании
вычислительных машин с помощью бизнес-правил (политик назначения
задач).
При отображении задач обработки данных на вычислительные узлы ис­
пользуются специальные ранговые выражения (rank expressions), которые поз­
воляют выбрать для задачи вычислительный узел среди всех машин, удовлетво­
ряющих требованиям задачи и доступных пользователю. Ранговое выражение
позволяет получить число, отражающее степень соответствия данной машины
требованиям задачи: чем выше число, тем больше машина подходит для вы­
бранной задачи.
При составлении ранговых выражений могут также использоваться атри­
буты из описаний как вычислительных узлов, так и самих задач.
Таким образом, в системе HTCondor требуется вручную задать следующие
метаданные для назначения ресурсов на задачи обработки данных:
1. Для каждой задачи создать файл запроса, в котором указываются мини­
мальные и предпочтительные требования к ресурсам, а также приоритет
самой задачи;
2. Для каждого вычислительного узла задать его статические свойства, а
также указать какие динамические свойства должны определяться во вре­
мя функционирования распределённой системы;
3. Задать набор ранговых выражений, отражающих предпочтения по выпол­
нению задач на тех или иных ресурсах.
HTCondor совмещает в себе функции системы управления ресурсами и си­
стемы планирования заданий, обладая гибкой системой настройки бизнес-пра­
вил планирования. Единственным минусом такого решения стоит считать повы­
шенные требования к квалификации администратора: требуется вручную опи­
сывать стратегии планирования на всех уровнях функционирования системы,
29
поскольку нет адаптивности системы к изменяющимся условиям.
1.2.2. Система DIET
DIET является промежуточным программным обеспечением, которое пред­
ставляет собой уровень между операционной системой и прикладными прило­
жениями, и предназначен для организации грид-вычислений на основе различ­
ных типов распределённых ресурсов (рабочих станций, кластеров, грид-систем,
облачных систем).
Иерархия компонентов системы DIET представлена на Рисунке 1.4.
Рисунок 1.4. Иерархия компонентов системы DIET
Программная архитектура DIET состоит из следующих типов компонентов
[19]:
1. Клиент (client) - приложение, которое использует DIET для решения за­
дач.
2. Управляющий агент (master agent, MA) - получает вычислительный за­
прос от клиента, затем собирает информацию о доступных ресурсах с
30
серверов, выбирает наиболее подходящий сервер и отправляет ссылку на
выбранный сервер клиенту.
3. Местный агент (local agent, LA) - передаёт запросы и информацию между
управляющими агентами и серверами, выполняя частичное планирование
в рамках поддерева серверов.
4. Серверная служба (server daemon, SeD) - служба, которая выполняется на
конечных вычислительных узлах и служит для предоставления информа­
ции о возможных типах решаемых задач, локально доступных данных и
статической и динамической информации о количестве и загрузке ресур­
сов.
Подсистема планирования в DIET определяет план исполнения задач рас­
пределённым способом: для каждой поступившей на обработку задачи сервер­
ные службы предоставляют оценку производительности - набор данных, отра­
жающих свойства ресурсов каждого сервера на момент запроса.
Примеры собираемых характеристик:
1. Время с момента выполнения последней задачи (сек.);
2. Коэффициент загруженности процессора (в интервале [0,1]);
3. Объём свободной памяти (Мб);
4. Число доступных процессоров;
5. Тактовая частота процессоров (МГц);
6. Общий объём памяти (Мб);
7. Размер процессорного кэша (Кб);
8. Объём раздела диска (Мб);
9. Средняя скорость чтения/записи на диск (Мб/сек.).
Такие оценки с каждого конечного сервера передаются на родительский
(местный или управляющий) агент, где они сортируются в соответствии с неко­
торым оптимизационным критерием.
По умолчанию, сервера упорядочиваются в порядке времени последнего ис­
пользования (least recently used scheduling, см. стр. 18), если серверные службы
31
сохраняют временные отметки. Если же возможности хранения временных от­
меток нет - планировщик выбирает сервер для выполнения задачи случайным
образом (random scheduling, см. стр. 18) [19].
Таким образом, система DIET предоставляет простую схему автоматиче­
ского выбора ресурсов на основе мониторинга состояния ресурсов (узлов систе­
мы) и не требует задания информации о ресурсных требованиях задач. Это
является несомненным достоинством системы DIET.
Кроме того, система DIET позволяет расширять подсистему планирова­
ния посредством плагинов. Данная функциональность даёт возможность рас­
ширить множество метрик, которые используются для оценки производитель­
ности, метриками прикладной области и задать критерий, в соответствии с ко­
торым эти данные используются на этапе сортировки вычислительных узлов­
кандидатов на выполнение поступившей задачи. В результате, при разработке
плагина, проблема планирования перекладывается на разработчиков конечных
прикладных приложений.
Из недостатков данного решения стоит отметить необходимость программ­
ной реализации модуля планирования для каждой прикладной задачи, что свя­
зано с существенными временными затратами и требованиям к высокой квали­
фикации персонала поддержки.
1.2.3. Программный стек ProActive
Программный стэк ProActive включает в себя систему управления ресурса­
ми ProActive Grids and Clouds, распределённый планировщик задач ProActive
Orchestration and Scheduling, промежуточное ПО для грид-систем ProActive
Programming и набор графических интерфейсов для взаимодействия с поль­
зователем.
По умолчанию планировщик ProActive извлекает задачи обработки из вход­
ной очереди в соответствии с политикой FIFO (First-in First-out). Кроме того
предоставляются интерфейсы и рекомендации по программной реализации соб­
32
ственных методов планирования [20].
Планировщик в системе ProActive не решает задачу выбора узла для испол­
нения задачи, а лишь предоставляет механизм поиска ресурсов: клиент форми­
рует запрос, в котором указывает критерии отбора узлов, после чего система
управления ресурсами предоставляет список доступных узлов, соответствую­
щих указанным критериям. Далее клиент принимает решение об исполнении
кода непосредственно самой задачи, если ресурсов достаточно или ждёт осво­
бождения требуемого количества ресурсов. Как только ресурсы выделены кли­
енту, он обладает исключительным прямым доступом к узлу-обработчику до
момента завершения своих операций.
Достоинством системы ProActive является её кроссплатформенность, - стек
реализован на языке Java, модули системы (ProActive агенты) исполняются на
Java Virtual Machine. Это позволяет использовать единый подход к управлению
ресурсами в самых разнородных инфраструктурах [20]:
1. Сетях рабочих станций;
2. Облачных ресурсов Amazon Elastic Compute Cloud (EC2);
3. Ресурсах, предоставляемых системами виртуализации поверх аппаратно­
го обеспечения (поддерживаются гипервизоры XenServer, Hyper-V, xVM
Server, VMWare ESX/ESXi, Xen OSS);
4. Ресурсах, предоставляемых гостевыми системами виртуализации (поддер­
живаются контейнеры виртуальных машин VirtualBox, VMware Server,
KVM);
5. Ресурсах, предоставляемых кластерными системами на базе Windows HPC
Server.
Недостатком программного стека ProActive можно считать как необходи­
мость программной реализации метода выбора узла-обработки данных даже в
простейших случаях, так и отсутствие гибких механизмов по настройке поли­
тики выбора задач из входной очереди.
33
1.2.4. Системы управления ресурсами Slurm и Torque
Slurm является открытой системой управления нагрузкой, предназначенн­
ной для кластеров рабочих станции на базе ОС Linux. Предоставляет механиз­
мы экслюзивного и совместного доступа к ресурсам, а также механизмы запуска
и мониторинга задач.
Стандартная конфигурация системы Slurm подразумевает обработку задач
в соответствии с приоритетом FIFO, но есть возможность добавления собствен­
ного метода планирования через механизм программных расширений (плаги­
нов).
В стандартной конфигурации, Slurm выделяет узлы для задач в эксклюзив­
ном режиме. Это означает, что несмотря на то, что выполняемая задача может
не использовать все доступные ресурсы (процессор, память, область подкачки,
локальный диск), другие задачи не имеют возможности получить к ним доступ.
Используемая по умолчанию политика эксклюзивного доступа может при­
вести в неэффективному использованию кластера и ресурсов узлов-обработчи­
ков. В связи с этим SLURM также поддерживает разделяемое использование
ресурсов для минимизации простоя ресурсов.
Аналогично системе Slurm, система Torque используется исключительно
для управления ресурсами, обрабатывая запросы от планировщика и ведая
низкоуровневыми аспектами запуска, остановки и мониторинга задач. Стан­
дартный планировщик pbs_sched, который распространяется вместе с системой
Torque, обладает лишь базовыми возможностями и обеспечивает неэффектив­
ное использование ресурсов кластера [21].
Поскольку выбор планировщика в кластерных системах оказывает суще­
ственное влияние на доступность ресурсов, их загрузку и эффективное исполь­
зование, разработчики системы Torque рекомендуют использовать сторонние
системы планирования Moab и Maui. В следующих подразделах они будут рас­
смотрены подробно.
34
1.2.5. Планировщик Moab
Планировщик Moab преследует цели равноправного и эффективного ис­
пользования распределённых ресурсов кластера, определяя где и при каких
условиях исполнять задачи.
Планировщик Moab поддерживает интеграцию с системами управления
ресурсами SLURM и TORQUE [22].
Узел-обработчик в большинстве случаев представляет собой стандартную
рабочую станцию, но поддерживается также и возможность работы с виртуаль­
ными машинами, предоставляемыми гипервизором.
Для Moab ресурсом в конечном счёте могут выступать:
1. Процессоры (количество);
2. Оперативная память (Мб);
3. Область подкачки (Мб);
4. Дисковая внешняя память (Мб).
Планировщик Moab функционирует как в режиме опроса системы управле­
ния ресурсами, так и в событийном режиме. В качестве событий, активирующих
следующий цикл планирования могут выступать:
1. Поступление новой задачи обработки данных;
2. Завершение выполнения ранее запущенной задачи;
3. Добавление нового узла-обработчика;
4. Внесение изменений в политики (настройки) системы управления ресур­
сами.
На каждой итерации планирования планировщик запрашивает у системы
управления ресурсами актуальную информацию о состоянии ресурсов, рабочей
нагрузки и конфигурации политик планирования.
Затем Moab выполняет следующие действия:
1. Получает список задач, для которых условия выполнения удовлетворены.
2. Упорядочивает задачи в соответствии с их относительным приоритетом в
35
списке. Для каждой задачи приоритет определяется в соответствии с та­
кими атрибутами, как владелец задачи, её размер, длительность простоя
данной задачи в очереди и пр. Как правило, для приоритезации имеет
значение группа разнородных и независимых целей, таких как максими­
зация загрузки ресурсов, особый приоритет пользователей в отдельных
проектах, исключение чрезмерного простоя задач. Подход, используемый
в Moab подразумевает назначение весов для множества независимых це­
лей и получение суммарного значения приоритета для каждой задачи.
3. Определяет доступные ресурсы. Для каждой задачи Moab пытается най­
ти узел-обработчик, соответствующий требованиям к ресурсами, указан­
ным в описании задачи. Важно отметить, что узел-обработчик считается
подходящим лишь в том случае, если удовлетворены ВСЕ ресурсные тре­
бования, указанные в описании задачи.
4. Выделяет ресурсы для выполнения задачи. Если подходящие ресурсы
есть в пуле ресурсов, планировщик применяет метод выбора узла (node
allocation policy) для выбора наиболее подходящего множества ресурсов.
5. Запускает задачу. После того как узел-обработчик выбран, планировщик
связывается с системой управления ресурсами и указывает где и как за­
пускать задачу обработки данных.
Рассмотрим подробнее шаг, на котором Moab выделяет ресурсы для вы­
полнения задачи.
Процесс выделения ресурсов (узла-обработчика) для выполнения задачи,
как выбор наиболее подходящих ресурсов из списка доступных, особенно актуа­
лен в средах, характеризующихся следующими свойствами [22]:
1. Гетерогенность ресурсов (качественные и количественные различия меж­
ду узлами);
2. Наличие разделяемых узлов (такой узел может быть использован для од­
новременного выполнения более чем для одной задачи);
3. При использовании резервирования ресурсов для предоставления гаран­
36
тий качества QoS;
4. Неоднородной топологии сети (скорость передачи данных между различ­
ными сегментами может существенно отличаться).
Основная целями метода выбора узла является повышение производитель­
ности при выполнении данной задачи (локальная оптимизация) и предоставле­
ние максимальной свободы для планировщика при планировании последующих
задач (глобальная оптимизация).
Метод выбора узла позволяет задавать критерии выбора: скорость узла,
тип резервирования (разделяемый или экслюзивный доступ) и количество из­
быточных ресурсов и пр. Кроме того, возможно настроить политики выбора
узлов как на глобальном (общесистемном) уровне, так и применительно к от­
дельным задачам.
Таким образом, в планировщике Moab проводится четкое разделение меж­
ду методами планирования применительно к задачам и ресурсам:
1. Метод выбора задачи (job selection policy), на основе схемы приоритетов
и информации о выполнении предварительных условий задачи, последо­
вательно извлекает из очереди задачи на обработку.
2. Метод выбора узла-обработчика (node allocation policy), на основе ресурс­
ных требований задачи и информации о загрузке узлов, для каждой от­
дельной задачи подбирает наиболее подходящий узел. Приоритет каждо­
го узла применительно к поступившей задаче оценивается по различным
взвешенным параметрам.
Достоинством используемого в планировщике Moab подхода можно счи­
тать гибкость настройки процесса планирования за счёт использования модуль­
ного подхода к решению проблем планирования. Необходимость ручного зада­
ния ресурсных требований для каждой задачи стоит отнести к недостаткам
системы.
Стоит также отметить, что планирование осуществляет последовательно
для наиболее приоритетных задач, что позволяет получить локальный опти­
37
мум, но может привести к неэффективному планированию в целом.
В противовес такому подходу существуют методы, которые осуществляют
планирование для группы задач, что позволяет оценивать совместную эффек­
тивность запуска и находить глобальный оптимум.
Однако, стоит отметить, что планирование для групп задач стоит приме­
нять только тогда, когда существует соответствующая равномерная нагрузка.
Для интерактивных проблем целесообразно выполнять планирование примени­
тельно к отдельным задачам.
1.2.6. Планировщик Maui
Разработчики системы планирования Maui выделяют три основные обла­
сти, для которых осуществляется принятие решений с использованием политик
[23]:
1. Управление трафиком. Необходимо исключать ситуации соревнования за­
дач за одни и те же ресурсы, поскольку это, как правило, снижает общую
производительность кластера, увеличивает время выполнения таких за­
дач, и может приводить к отказам.
2. Политики целевого использования. Кластеры и иные высокопроизводи­
тельные платформы создаются для выполнения определённых приклад­
ных задач. В целях эффективности планирования планировщик должен
позволять учитывать бизнес-правила по использованию системы в процес­
се планирования.
3. Любые оптимизации, которые можно применить в процессе планирования
для повышения производительности в обработке задач.
Информация о задачах обработки поступает из таких систем управления
ресурсами как Loadleveler, PBS, Wiki, или LSF, и содержит:
1. Атрибуты: владелец задачи, состояние задачи и пр.
2. Ресурсные требования: количество и временной интервал на который тре­
буется тот или иной ресурс.
38
Каждое требование на ресурс включает в себя также список условий, ко­
торые ВСЕ должны быть удовлетворены, чтобы узел-обработчик был выбран.
Под узлом-обработчиков в системе Maui подразумевается набор ресурсов,
каждый с множеством связанных атрибутов. Как правило, узел-обработчик это один или несколько процессоров, память, и, возможно, множество дополни­
тельных ресурсов, таких как дисковое пространство, область подкачки, сетевые
интерфейсы, программные лицензии и т.д. Дополнительно узел описывается та­
кими атрибутами как тип архитектуры или операционная система.
Информацию об узлах, включая количество доступных ресурсов и состоя­
ние узлов, поступает к планировщику исключительно от системы управления
ресурсами.
Под ресурсами в системе Maui понимается тот же список что и в системе
Moab (см. 1.2.5).
Для применения политик планирования к задачам обработки используется
понятие класса. Класс задачи задаётся с помощью системы выделения ресурсов
и может быть ассоциирован с одним или несколькими атрибутами или ограни­
чениями:
1. Атрибуты задачи (длительность задачи, её размер, ресурсные требова­
ния);
2. Ограничения на множество рабочих станций - класс задач может обраба­
тываться только на заранее заданном множестве узлов-обработчиков;
3. Ограничения на свойства поступающей задачи - минимальное количество
процессоров, время поступления задачи и т.п.
4. Список доступа - в соответствующую очередь поступает лишь класс за­
дач, для которых выполняются требования контроля доступа (поступают
только задачи от определённых пользователей или групп).
Соответственно для каждого класса выделяется отдельная очередь обра­
ботки.
39
Maui отслеживает использование классов как потребляемого ресурса, что
даёт возможность проектировщикам системы создавать политики использова­
ния в зависимости от типов задач.
Пример политики выполнения задач: - не более 8 задач любого типа мож­
но запускать одновременно, - не более 4 задач от группы административных
пользователей могут одновременно выполняться в системе.
Шаги, которые планировщик Maui выполняет на каждой итерации плани­
рования полностью эквивалентны тем, которые используются в планировщике
Moab (см. 1.2.5).
Одним из достоинств системы для конечного пользователя является под­
держка резервирования ресурсов с указанием интервалов времени и списка до­
ступа, что особенно важно для предоставления гарантий качества обслужива­
ния QoS.
Главные недостатки используемого в планировщике Maui подхода к плани­
рованию:
1. Необходимо знать ресурсные требования задачи априори, что не всегда
возможно;
2. Как правило, требуется задать условия выбора узла-обработчика;
3. Задачи необходимо заранее разбить на классы в зависимости от значений
их атрибутов, параметров контроля доступа и пр.
4. На основе заданных классов необходимо заранее определить политики
выбора очереди запуска.
Такая избыточность ручного конфигурирования приводит к существенным
временным затратам на стадии проектирования системы.
40
1.3. Выводы
Анализ основных систем планирования (систем управления ресур­
сами Slurm, Torque, планировщиков заданий Moab, Maui и комбинированных
систем HTCondor и DIET) и распространённых в литературе методов планиро­
вания задач показал следующее:
1. Методы, используемые в существующих системах планирования, зачастую
опираются на наличие информации о ресурсных требованиях задач обра­
ботки данных, перекладывая проблему настройки на конечного пользова­
теля.
2. Методы планирования, не требующие информации о ресурсных требова­
ниях, обладают следующим основным недостатком – отсутствие учёта
совместных требований для групп задач, приводит к неэффективному ис­
пользованию вычислительных ресурсов.
В связи с эти требуется разработка новых методов планирования задач в
РСОД в условиях неполноты информации о ресурсных требованиях, позволяю­
щих сократить временные затраты на выполнение прикладных задач обработки
данных.
Для этого в настоящей работе предлагается проанализировать связь между
атрибутами задач (метаданными) и метрическими характеристиками использо­
вания вычислительных ресурсов.
41
Глава 2
Использование метаданных для планирования в
РСОД
В главе рассматриваются основные типы метаданных и этапы их жизненно­
го цикла: извлечения, хранения и использования. Проводится классификация
задач обработки данных исходя из их ресурсных требований. Наличие связи
между метаданными и ресурсными метриками иллюстрируется на примере за­
дачи декодирования видео данных. Для сравнения задач на основе метаданных
предлагается использовать методы машинного обучения на основе прецедентов.
2.1. Классификация метаданных
В соответствии со стандартом ISO/IEC 11179 [24] термин метаданные опре­
деляется как данные определяющие или описывающие другие данные.
Метаданные, как набор характеристик, описывающих некое множество(а)
данных могут относится к одному из следующих классов:
1. Описательные метаданные, которые описывают отдельные экземпляры
прикладных данных, - приводят характеристики содержимого данных.
Описательные метаданные - это, как правило информация, которая ис­
пользуется для поиска: заголовок, издательство, автор, ключевые слова и
др;
2. Структурные метаданные, которые описывают способ организации хра­
нения информации с помощью структур данных (данные о контейнерах
данных);
3. Административные метаданные, которые включают в себя технические
атрибуты цифровых данных, такие как время и место создания файла,
автор, последняя дата изменения, размер и расширение файла;
42
В целях принятия решений по планированию ресурсов для задач в РСОД
представляет наибольший интерес тип описательных метаданных, поскольку
именно в зависимости от характеристик конкретных экземпляров данных, а не
обобщённой структуры хранения, находятся ресурсные требования задач обра­
ботки данных. В связи с этим далее под термином метаданные будут понимать­
ся именно описательные метаданные.
Метаданные могут хранится в одном в файле с данными, либо в отдельном
файле или в базе данных. Метаданные, вложенные в сам файл данных, называ­
ются встроенными (embedded). Для хранения метаданных раздельно от самих
данных используются специальные репозитарии данных.
Наличие полных метаданных позволяет решать задачи поиска, идентифи­
кации и описания в самых различных областях: при распространении цифро­
вого видео и аудио, здравоохранения, семантического поиска в интернете, для
сервисов геолокации и пр. К сожалению решение многих прикладных задач
затруднено ввиду неполноты, некорректности или полного отсутствия метадан­
ных. В некоторых случаях существуют способы относительно нетрудоёмкого
получения и исправления отсутствующих или некорректных метаданных.
Метаданные могут быть получены с помощью ручного ввода или посред­
ством автоматизированной обработки. В то время, как ручной ввод позволяет
получать качественно лучшие метаданные, такой метод обладает высокой тру­
доёмкостью и подвержен ошибкам ввода. Автоматизированная же обработка
даёт возможность избегать случайных ошибок, но позволяет получить лишь
ограниченный набор метаданных.
В целях данного исследования представляют интерес те характеристики
данных, которые имеют корреляцию с ресурсными требованиями для обработки
этих данных.
Многие из таких характеристик, хранятся в самих данных, то есть явля­
ются встроенными, или уже доступны как атрибуты файлов, хранимых в фай­
ловой системе (внешние метаданные).
43
В следующем разделе приведены основные характеристики мультимедий­
ных метаданных и проведён анализ их пригодности для принятия решений о
планировании в РСОД.
2.2. Создание и хранение мультимедийных метаданных
Исследование методов распределённой обработки мультимедийных данных,
таких как цифровой звук, видео файлы и изображения получило особую значи­
мость благодаря широкой распространённости переносных цифровых устройств
и сетевых сервисов. Всё чаще для хранения и обработки таких данных исполь­
зуются облачные среды, а пользователям предоставляются высокоуровневые
сервисы SaaS. На уровне поставщика услуг мультимедийные метаданные иг­
рают особую роль, поскольку они являются основой для принятия решения
планирования.
Ниже приведены основные характеристики для каждого типа мультиме­
дийных данных, которые могут выступать в качестве атрибутов классификации
в процедуре поиска ближайших задач, который выполняется при реализации
предложенного метода планирования задач.
Атрибуты цифровых изображений:
1. Размер файла в памяти (в Кб);
2. Формат файла: сжатие без потерь (PNG, TIFF) / сжатие с потерями
(JPEG, GIF);
3. Глубина цвета, color depth (байт на пиксель);
4. Размер изображения (в дюймах/см);
5. Разрешение (точек на дюйм/см);
6. Время и дата;
7. Настройки камеры: фокусное расстояние, величина выдержки, значение
ISO и пр.
Большинство цифровых камер, сохраняет базовую информацию о снимке:
44
высота, ширина, формат файла и время съёмки. Более современные камеры
(включая камеры смартфонов), сканеры и другие устройства поддерживают
сохранение расширенного набора метаданных на основе открытого стандарта
Extensible Metadata Platform (XMP)1 , построенного на основе разметки XML,
- таким образом создание метаданных производится автоматически и одновре­
менно с созданием самих данных. Метаданные могут быть сохранены как в сам
файл данных (встроенные метаданные), так и внешне - в отдельный файл XMP
метаданных (.xmp sidecar файл). Встраивание блока XMP данных поддержива­
ется в основных форматах изображений: TIFF, JPEG, JPEG2000, PNG, GIF,
PDF, Photoshop (PSD) и Digital Negatives (DNG).
Помимо XMP, существуют стандарты хранения метаданных цифровых изоб­
ражений, такие как EXIF, IPTC (IIM), поддержка которых уже не ведётся2 .
Поскольку огромное количество данных и метаданных было сохранено с ис­
пользованием указанных стандартов, особенно ценной оказывается поддержка
конвертации таких метаданных в формат XMP.
Как правило, для основных задач обработки изображений наиболее важ­
ными в плане определения трудоёмкости обработки являются разрешение изоб­
ражения (точек на см.) и физический размер изображения (ширина и высота в
см.), которые хранятся в Exiff блоке XMP метаданных.
Атрибуты цифровых аудиофайлов:
1. Размер файла в памяти (в Кб);
2. Кодек: сжатие без потерь (FLAC, APE) / сжатие с потерями (MP3, Ogg
Vorbis, WMA);
3. Глубина дискретизации, bits per sample (8-bit, 32-bit);
4. Частота дискретизации, sampling rate or quantization (kHz);
5. Длительность (в секундах/ минутах);
1
Extensible Metadata Platform: http://www.adobe.com/products/xmp/overview.html.
2
До появления открытых стандартов каждая система обработки изображений использовала собственные
закрытые методы работы с метаданными, что не позволяло их передавать вместе с изображением.
45
6. Количество каналов (моно, стерео, 3-канальный звук, n-канальный звук).
Форматы хранения аудио данных MP3, WAV и AIFF (Audio Interchange
File Format) поддерживают хранение встроенных метаданных в соответствии
со стандартом XMP. Кроме того, широкое распространение получил стандарт
iXML3 , который определяет формат хранения встроенных метаданных в аудио
файлах формата Broadcast Wave file и ввиду отсутствия фиксированной XML
схемы позволяет записывать любые метаданные.
Атрибуты цифровых видео данных:
1. Размер файла в памяти (в Кб);
2. Кодек: сжатие без потерь (Huffyuv) / сжатие с потерями (MPEG1, MPEG2,
MPEG4);
3. Глубина цвета, color depth (байт на пиксель);
4. Размер кадра или разрешение, frame size / resolution (WxH in pixels);
5. Кадровая частота, frame rate (кадров в секунду, frames per second);
6. Длительность (в секундах/ минутах);
7. Битрейт = бит на кадр * кадровая частота, bit rate = bits per frame *
frame rate.
Файлы цифровых видео данных состоят из нескольких потоков: поток ви­
део данных, поток(и) аудио данных, поток(и) субтитров. Атрибуты, отражаю­
щие трудоёмкость для распространённых задач обработки видео: битрейт, раз­
мер файла.
Перечисленные примеры атрибутов мультимедийных данных, за исключе­
нием размера файла, хранятся в самих файлах, то есть являются встроенными.
Формат хранения встроенных метаданных соответствует мультимедийным
стандартам, к примеру:
1. Видео файлы MPEG хранятся в соответствии с семейством стандартов
ISO/IEC 13818;
2. Файлы изображений JPEG хранятся в соответствии со стандартом ISO/IEC
3
iXML Standard 1.61 (2010): http://www.ixml.info/
46
10918-5.
Кроме того, некоторые форматы хранения видео данных - MP4 (MPEG 4
part 14) и AVI (Audio Video Interleaved) - поддерживают хранение встроенных
метаданных в соответствии со стандартом XMP.
Поскольку формат хранения бинарных мультимедийных данных стандар­
тизован, получение метаданных может быть полностью автоматизировано - про­
цедура извлечения метаданных производит их получение перед запуском про­
цесса планирования ресурсов.
Применение в зависимости от конкретной прикладной проблемы тех или
иных атрибутов позволит классифицировать задачи обработки по трудоёмкости
и выполнить эффективное распределение задач по узлам-обработчикам.
Выводы по проведённому анализу характеристик данных:
1. Среди существующих типов мультимедийных метаданных - описатель­
ных, структурных и административных - для принятия решений по пла­
нированию задач наибольшую ценность представляют описательные ме­
таданные, которые отражают ресурсные требования для задач обработки
данных.
2. Источниками получения метаданных могут выступать устройства запи­
си данных, процедуры автоматической предъобработки данных и ручной
ввод. Во многих случаях, таких как съёмка видео, фотосъёмка, запись
звука, сканирование изображений, современные устройства уже сохраня­
ют расширенный набор метаданных в стандартизованном формате XML.
3. Для работы со встроенными и внешними метаданными для изображений,
видео и аудио данных существует ряд стандартов, наибольший интерес
из которых представляет, начиная с 2005 года, (версия стандарта XMP
1.04 ) как расширяемый открытый формат хранения метаданных XMP от
Adobe. XMP поддерживает наиболее распространённые форматы изоб­
ражений (TIFF, JPEG, JPEG2000, PNG, GIF, PDF, Photoshop (PSD) и
4
Стандарт XMP 1.0: http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf
47
Digital Negatives (DNG)) и предоставляет обратную совместимость с су­
ществовавшими ранее стандартами хранения метаданных EXIF и IPTC.
Помимо изображений встраивание блока XMP метаданных поддержива­
ется музыкальными форматами MP3, WAV и AIFF, и видео форматами
MP4 и AVI.
Редактирование и чтение метаданных XMP поддерживается в большин­
стве существующих пакетов обработки изображений, кроме того, посколь­
ку атрибуты хранятся в XML, доступен программный способ их обработ­
ки.
2.3. Связь между метаданными и ресурсными
требованиями
Как указывалось в главе 1, ресурсные требования задачи обработки дан­
ных могут быть заданы вручную аналитиком, на основе знаний прикладной
области, или получены автоматически в результате эксперимента на обучаю­
щей выборке данных. В настоящей работе предложенный метод планирования
предполагает использование последнего подхода.
Апостериорные ресурсные требования задачи характеризуются множеством
метрик загрузки ресурсов, полученных в результате эксперимента. В данном
разделе рассматривается вопрос для каких задач обработки данных, предло­
женный подход имеет практическую целесообразность.
Метаданные могут выступать основой принятия решений по планирова­
нию ресурсов в том случае, когда их изменение приводит к повышению или
понижению ресурсных требований.
Основными ресурсами в любой вычислительной системе, в том числе рас­
пределённой, выступают память и процессоры [2]. В соответствии с этими ре­
сурсами выделяют типы задач ресурсоёмких по памяти и ресурсоёмких по про­
цессорному времени. Примерами задач, требовательных к памяти выступают
48
анализ данных (in-memory analytics), сборка и анализ геномных последователь­
ностей. Примеры задач, требовательных к производительности процессора: па­
кетная обработка данных, кодирование видео, задачи физики элементарных
частиц и вычислительной гидродинамики.
Наряду с процессором и памятью, другими важными классами задач яв­
ляются задачи с большим объёмом операций ввода/вывода и задачи по работе
с графикой.
Высокими требованиями к производительности ввода/вывода обладают кла­
стерные файловые системы, нереляционные (NoSQL) базы данных, задачи рас­
пределённой обработки данных Map/Reduce (Hadoop). В более общем виде это класс задач, периодически генерирующий cнимок (snapshot) всего состоя­
ния системы [25].
Высокими требованиями к производительности графики обладают задачи
вычислительной химии, рендеринга (визуализации) и инженерного проектиро­
вания.
Наконец, пропускная способность сети играет огромную роль для ряда рас­
пределённых приложений.
В зависимости от выбранной прикладной задачи обработки данных и свя­
занных с ней данных формируются различные зависимости между метаданны­
ми и метриками загрузки ресурсов. В то время как для одних задач характерно
влияние одного подмножества метаданных на потребление памяти, для других
задач характерна связь между другими атрибутами и загрузкой процессоров.
Пример зависимости между свойствами задачи и метриками загрузки при­
ведён в Таблице 2.1.
В таблице для каждой записи приведены метаданные задачи декодирова­
ния видео данных5 – свойства выходного видеопотока (исходный файл один
для всех записей), конфигурация узла-обработчика и полученные в результа­
те метрики исполнения. Как можно видеть из полученных метрик, свойства
5
Подробное описание задачи декодирования см. раздел 4.2
49
Таблица 2.1. Зависимости между ресурсами и метаданными для видеоприложений
задачи оказывают влияние на потребление памяти (ram load), использование
процессоров (avg CPU load) и затраченное время.
Знание зависимости между метаданными и метриками загрузки ресурсов,
то есть ресурсными требованиями, для определённого класса задач позволяет
принимать политики планирования, повышающие эффективность использова­
ния ресурсов. Для выбранной задачи, на основе её метаданных подбирается
наиболее подходящий узел, обладающий требуемыми ресурсами.
К примеру облачный провайдер Amazon, наряду с машинами общего на­
значения, предоставляет возможность аренды машин оптимизированных под
высокое потребление памяти (high memory instances), под большой объём опе­
раций ввода/вывода (high I/O instances), под вычислительно ёмкие задачи (high
CPU Instances) и под задачи работы с графикой (GPU Instances)6 . Кроме то­
го, узлы различаются по скорости передачи данных по сети в зависимости от
используемого сетевого интерфейса.
Рассмотрим зависимости между метаданными и ресурсными метриками на
примере задачи декодирования видео.
Процесс от подачи задачи на вход системы до получения результата вы­
глядит следующим образом. Пользователь указывает источник видео данных и
требуемые параметры конвертации видео. Затем система планирования загру­
6
Amazon Web Services instance types: http://aws.amazon.com/ec2/instance-types/
50
жает данные, анализирует метаданные и подбирает наиболее подходящие для
данной задачи ресурсы. Задача поступает на выполнение на автоматически по­
добранный узел-обработчик, а затем результат обработки передаётся пользова­
телю (ссылка, откуда можно загрузить результат).
Указанную задачу решает с помощью собственных закрытых методов пла­
нирования бета версия сервиса Amazon Elastic Transcoder7 . Сервис позволяет
выбрать тип устройства под которое необходимо конвертировать видео (план­
шет, смартфон, ноутбук), конкретное устройство (Amazon Kindle Fire HD или
Apple iPhone 4S), или вручную задать параметры выходного видео файла. Вход­
ные и выходные данные хранятся в облачном хранилище Amazon S38 .
В соответствии с классом ресурсных требований выделяют следующие ти­
пы задач:
1. Вычислительно ёмкие задачи, требовательные к производительности про­
цессора(ов);
2. Задачи, требовательные к потребляемой памяти;
3. Задачи, требовательные к производительности операций ввода/вывода;
4. Задачи, требовательные к производительности графической подсистемы.
Под каждый из существующих классов задач основные поставщики об­
лачных инфраструктур (IaaS) выделяют свой тип узлов: оптимизированных
по памяти (memory optimized), по производительности процессора (compute
optimized), по производительности ввода/вывода (storage optimized) и произ­
водительности графики (GPU instances).
Методы динамической балансировки нагрузки позволяют повысить общую
производительность распределённой системы, такой как сеть рабочих станций,
за счёт назначения работ на машины с простаивающими или слабо загружен­
ными ресурсами. Методы балансировки нагрузки в распределённых системах,
представленные в литературе, нацелены на повышение эффективности исполь­
7
Amazon Elastic Transcoder: http://aws.amazon.com/elastictranscoder/
8
Amazon Simple Storage Service: http://aws.amazon.com/s3/
51
зования процессора [26, 27], памяти [28, 29], процессора и памяти [30], подсисте­
мы ввода-вывода [25].
Основным недостатком данных методов является необходимость указания
ресурсных требований для подсистемы ввода-вывода, процессора и памяти для
каждой задачи обработки данных. В следующем разделе рассмотрены методы
поиска похожих (близких) задач, которые позволяют обойти данное ограниче­
ние.
2.4. Поиск близких задач
Оценка ресурсных требований задачи по ресурсным требованиям наиболее
близких задач в широком смысле представляет собой обучение на основе пре­
цедентов (Instance-Based Learning). Прецедентное обучение основано на предпо­
ложении что схожие объекты (точки) относятся к схожим классам [31].
Прецедентное, или иначе, ленивое обучение (lazy learning) характеризуется
следующими свойствами [32]:
1. отложенность - данные обучения сохраняются, а вычисления отклады­
ваются до момента, когда поступают запросы, требующие ответа;
2. локальность - ответы на запросы получаются в результате объединения
подмножества записей из обучающей выборки; при этом используется т.н.
локальное обучение, когда для прогнозирования используется часть про­
странства обучающей выборки [33, 34].
Применительно к данной работе интерес представляют собой способы ре­
шения задачи регрессии методом поиска ближайших соседей (𝑘-𝑁 𝑁 регрессия).
Прогнозирование методом ближайшего соседа заключается в поиске 𝑘 наи­
менее удалённых (другими словами, наиболее близких) точек и получении клас­
са (или численного значения в случае регрессии) голосованием простым боль­
шинством. Качество прогнозирования методом 𝑘-𝑁 𝑁 зависит от того, какие
точки считаются менее удалёнными, то есть метод чувствителен к способу за­
52
дания метрики расстояния.
Выходом алгоритма 𝑘-𝑁 𝑁 регрессии является прогнозируемый вектор ре­
сурсных затрат, который оценивается как среднее значение векторов ресурсных
затрат 𝑘 ближайших соседей, где параметр 𝑘 задаётся аналитиком.
Применительно к задаче прогнозирования ресурсов, обучающая выборка
представляет собой множество кортежей:
{(𝑋, 𝑌 )}
где:
𝑋 = 𝑥1 , 𝑥2 , · · · 𝑥𝑛 - вектор метаданных в многомерном пространстве;
𝑌 = 𝑦1 , 𝑦2 , · · · 𝑦𝑘 - значения ресурсных затрат.
Пусть 𝐴 и 𝐵 – два вектора метаданных в многомерном пространстве. Срав­
нение объектов производится на основе меры схожести (Similarity measure) [35]:
𝑆(𝐴, 𝐵) =
𝑑
∑︁
𝑤𝑘 · 𝑆𝑘 (𝑎𝑘 , 𝑏𝑘 )
(2.1)
𝑘=1
где:
𝑤𝑘 - вес отдельного атрибута;
𝑆𝑘 - по-атрибутная мера схожести;
𝑎𝑘 , 𝑏𝑘 - значения отдельных атрибутов.
Вес каждого атрибута отражает его значимость для определения прогно­
зируемых ресурсных требований: если один из атрибутов важнее других для
классификации, то назначение ему большего веса позволяет повысить точность
прогнозирования.
Схемы взвешивания по-атрибутных метрик схожести необходимы, посколь­
ку в противном случае избыточные, незначимые или зашумлённые атрибуты
будут оказывать тот же эффект на вычисление расстояния что и другие атри­
буты [36]. В частности, для алгоритма поиска ближайшего соседа размер выбор­
ки, требуемый для получения классификатора с заданным уровнем точности
53
прогнозирования, растёт экспоненциально с ростом количества избыточных ат­
рибутов [31, 37].
Ряд исследований показал [38–40], что разновидности алгоритма 𝑘-𝑁 𝑁 ,
осуществляющие взвешивание атрибутов позволили повысить точность прогно­
зирования в ряде прикладных областей.
Техники выбора атрибутов (feature selection) являются частным случаем
назначения весов, когда для отсечения множества избыточных атрибутов им
задаются нулевые веса 𝑤 = 0.
Ранжирование и отсечение атрибутов потенциально позволяют получить
целый ряд преимуществ:
1. Упростить визуализацию и понимание данных;
2. Уменьшить объём хранимых данных;
3. Сократить время обучения (построения модели);
4. Сократить эффект проклятия размерности;
5. Повысить точность прогнозирования.
Стандартными способами получения вектора весов являются линейная ре­
грессия, вычисление коэффициентов корреляции и ковариации. Среди мето­
дов выбора атрибутов, широкое распространение получили методы фильтра­
ции (filter) [41], которые выполняются на стадии предъобработки данных вне
зависимости от выбора классификатора.
Вместе с тем, на данный момент не существует универсального метода
получения атрибутных весов, оптимальных для всех прикладных областей, по­
скольку каждая задача требует предвзятости (bias) в выборе атрибутов [42].
Смещением оценок (bias), считается любая основа для предпочтения одних
обобщений другим, в отличие от строгого соответствия оценкам полученным
из обучающей выборки. Наличие знаний прикладной области, знание об источ­
никах получения данных обучения, предпочтение простых обобщений приводят
к смещению оценок, но при этом позволяют повысить точность прогнозирова­
ния [42].
54
В работе [32] в качестве одного из оснований классификации алгоритмов
обучения выступает как раз наличие знаний прикладной области для коррек­
ции весов. В методике выбора атрибутов, предложенной в работе [43], также
предлагается составлять список выбранных атрибутов вручную ("ad hoc"feature
selection method) при наличии знаний из прикладной области.
Что касается способа вычисления по-атрибутной меры схожести (расстоя­
ния), то он зависит, в первую очередь, от типа атрибута: численный или катего­
риальный (т.е. дискретный и возможно неупорядоченный). Если для численных
атрибутов наибольшее распространение носит мера Минковского, в частности
при значении порядка 𝑝 = 2 - евклидово расстояние, 𝑝 = 1 - манхеттенское
расстояние:
𝐷(𝐴, 𝐵) = (
𝑑
∑︁
|𝑎𝑘 − 𝑏𝑘 |𝑝 )1/𝑝 ,
(2.2)
𝑘=1
то для категориальных атрибутов базовой является мера Шимкевича-Симп­
сона (overlap coefficient, коэффициент перекрытия):
𝑆(𝐴, 𝐵) = 𝑜𝑣𝑒𝑟𝑙𝑎𝑝(𝐴, 𝐵) =
𝐴∩𝐵
.
𝑚𝑖𝑛(|𝐴| , |𝐵|)
(2.3)
На практике объекты сравнения редко характеризуются одним типом атри­
бутов. Наличие одновременно как номинальных, так и численных атрибутов не
позволяет использовать ни одну из приведённых метрик напрямую. Преобразо­
вание атрибутов, – дискретизация численных или отображение категориальных
атрибутов на численные, - это один из способов, который применяется в дан­
ных случаях. Вместе с тем, преобразование типов атрибутов сопровождается
выбрасыванием части значимой информации, что может привести к снижению
точности построенной модели [44].
Другой подход, учитывающий разнородность типов атрибутов, подразуме­
вает использование гетерогенных функций расстояния (Heterogeneous Distance
Functions), - для различных типов атрибутов применяются различные функции
55
расстояния.
Функция, которая использует метрику перекрытия для номинальных ат­
рибутов и нормализованное Евклидово расстояние для численных атрибутов,
получила название Heterogeneous Euclidean-Overlap Metric [45].
Для двух векторов 𝑋 и 𝑌 она определяется как:
⎯
⎸ 𝑚
⎸∑︁
𝐻𝐸𝑂𝑀 (𝑋, 𝑌 ) = ⎷
𝑑𝑎 (𝑥𝑎 , 𝑦𝑎 )2 .
(2.4)
𝑎=1
Эта функция определяет расстояние между двумя значениями 𝑥 и 𝑦 вы­
бранного атрибута 𝑎 как:
⎧
⎪
⎪
⎪
1
если 𝑥 или 𝑦 неизвестны
⎪
⎪
⎨
𝑑𝑎 (𝑥, 𝑦) = 𝑜𝑣𝑒𝑟𝑙𝑎𝑝𝑎 (𝑥, 𝑦) если 𝑎 номинален, иначе
⎪
⎪
⎪
⎪
⎪
⎩𝑟𝑛_𝑑𝑖𝑓 𝑓𝑎 (𝑥, 𝑦)
(2.5)
При наличии пропущенных значений атрибутов, расстояние между двумя
атрибутами определяется как максимальное, то есть 1. Учёт возможности про­
пущенных значений в данных крайне важен на практике, поскольку неполнота
и зашумлённость исходных данных зачастую ограничивают применение алго­
ритмов машинного обучения [46].
Функция перекрытия для отдельного категориального атрибута задаётся
следующим образом:
𝑜𝑣𝑒𝑟𝑙𝑎𝑝𝑎 (𝑥, 𝑦) =
⎧
⎪
⎨0 если 𝑥 = 𝑦,
(2.6)
⎪
⎩1 иначе
Нормализованное расстояние 𝑟𝑛_𝑑𝑖𝑓 𝑓𝑎 задаётся как:
𝑟𝑛_𝑑𝑖𝑓 𝑓𝑎 (𝑥, 𝑦) =
|𝑥 − 𝑦|
.
𝑟𝑎𝑛𝑔𝑒𝑎
(2.7)
Здесь значение 𝑟𝑎𝑛𝑔𝑒𝑎 , которое используется для нормализации определя­
ется как:
𝑟𝑎𝑛𝑔𝑒𝑎 = 𝑚𝑎𝑥𝑎 − 𝑚𝑖𝑛𝑎 .
56
(2.8)
Необходимо отметить, что деление на размах (range) позволяет выбросам
(outliers, экстремальным значениям) оказывать существенное влияние на вклад
атрибута в суммарное значение расстояния. К примеру, если переменная имеет
значения в диапазоне [0, 10], но одно, скорее всего ошибочное значение 50, то­
гда нормализация делением на размах, практически всегда будет приводить к
результату меньше чем 0.2.
Альтернативный способ нормализации заключается в использовании сред­
неквадратичного отклонения (СКО, standard deviation) для уменьшения эффек­
та от выбросов. Поскольку 95% значений в нормальном распределении попада­
ют в диапазон в два СКО от среднего значения, в работе [45] предлагается
выполнять нормализацию следующим образом:
𝑟𝑛_𝑑𝑖𝑓 𝑓𝑎 (𝑥, 𝑦) =
|𝑥 − 𝑦|
,
4𝜎𝑎
(2.9)
где:
𝜎𝑎 - среднеквадратичное отклонение численного атрибута 𝑎.
Помимо указанных способов нормализации, на практике также часто осу­
ществляют масштабирование значений численных атрибутов (re-scaling) в один
из диапазонов [0, 1] или [−1, 1]. При этом применяются следующие функции:
𝑥′ =
𝑥 − min 𝑥
max 𝑥 − min 𝑥
(2.10)
𝑥−𝑥
.
𝜎
(2.11)
или
𝑥′ =
57
2.5. Выводы
1. Проведённый анализ показал, что каждое из заданий обработки данных
характеризуется одновременно:
∙ Множеством характеристик данных;
∙ Множеством ресурсных требований;
∙ Классом ресурсных требований (наиболее значимый для производи­
тельности ресурс);
∙ Метриками загрузки вычислительных ресурсов.
2. Наличие корреляции между характеристиками данных и метри­
ческой информацией позволяет строить прогностические моде­
ли используя предысторию выполнения задач.
3. Оценка ресурсных требований новых задач может быть выполнена посред­
ством поиска близких по метаданным задач с помощью методов машин­
ного обучения на основе прецедентов.
58
Глава 3
Разработка теоретических основ планирования
задач в РСОД
В настоящей главе рассмотрены основные множества данных, их атрибу­
ты и зависимости между ними, которые используются в процессе планирова­
ния задач обработки данных планировщиком заданий для запуска на множе­
стве вычислительных ресурсов, предоставляемых аппаратным обеспечением,
под управлением системы управления ресурсами.
Предлагается математическая модель планирования задач в РСОД, для
которой описываются все используемые элементы и множества данных. Рас­
сматриваются примеры значений данных, которые скрываются за указанными
множествами на практике.
Предлагается метод планирования задач в РСОД и подробно рассматрива­
ются его основные этапы.
Отдельно рассматривается проблема поиска ближайших соседей, которая
является вычислительно трудоёмкой и возникает при планировании на основе
предыстории использования ресурсов, и предлагается алгоритм для её решения.
59
3.1. Математическая модель планирования задач в РСОД
Определение 2.1 Модель задачи планирования для РСОД представляет со­
бой кортеж
𝑃 = (𝑇, 𝐴, 𝐾, 𝑅, 𝑀, 𝑓, 𝐶, 𝑊 )
(3.1)
где:
𝑇 - множество задач;
𝐴 - множество атрибутов данных (метаданных), связанных с задачами;
𝐾 - множество узлов-обработчиков;
𝑅 - множество характеристик узлов;
𝑀 - множество метрик загрузки ресурсов вычислительных узлов;
𝑓 - отображение множества 𝑇 на множество 𝐾;
𝐶 - оценки вычислительных затрат выполнения задач из множества 𝑇 на
узлах-обработчиках из множества 𝐾;
𝑊 - коэффициенты назначения задач из множества 𝑇 на узлы-обработчики
из множества 𝐾.
Рассмотрим каждую составляющую предложенной модели более подробно.
Основной единицей планирования для планировщика заданий является за­
дача обработки данных.
Иными словами, задано множество заданий 𝑇 = {𝑡1 , 𝑡2 , . . . , 𝑡𝑛 }, 𝑛 ∈ 𝑁 , для
каждого из которых известны некоторые метаданные: 𝐴 = {𝑎1 , 𝑎2 , . . . , 𝑎𝑠 }, 𝑠 ∈ 𝑁
- множество атрибутов. Здесь и далее 𝑁 - множество натуральных чисел.
Каждый атрибут 𝑎𝑖 принимает дискретные значения из некоторого множе­
ства: 𝑎𝑖 ∈ 𝑉𝑖 = {𝑣1 , 𝑣2 , . . . , 𝑣𝑟 }, 𝑟 ∈ 𝑁 .
Множество атрибутов и их значений варьируется в зависимости от при­
кладной области и от конкретного класса задач обработки данных. К примеру,
для задач обработки изображений используются такие атрибуты, как разреше­
ние изображения (целочисленный тип), тип сжатия (категориальный тип: jpeg,
png, и др.), сжатие с потерями или без потерь (булевый тип - true/false), глубина
60
цвета (байт/пиксель) и пр.
Задано множество узлов обработки 𝐾, для каждого из которых известен
набор ресурсных характеристик (множество 𝑅):
𝑘 = 𝑅 = (𝑟1 , 𝑟2 , . . . , 𝑟𝑖 ), 𝑖 ∈ 𝑁.
(3.2)
К примеру вычислительный узел 𝑘 может характеризоваться количеством
процессоров и объёмом доступной памяти:
𝑘 = (𝑝, 𝑟),
где 𝑝 - количество процессоров узла 𝑘,
𝑟 - объём оперативной памяти узла 𝑘.
𝑝 и 𝑟 - дискретные величины, которые, к примеру, могут принимать следу­
ющие значения:
𝑝 ∈ {1, 2, 4, 8}, 𝑟 ∈ {128, 256, 512, 1024}
Как правило под ресурсами в системах управления ресурсами подразуме­
ваются:
1. Процессоры (количество);
2. Оперативная память (Мб);
3. Область подкачки (Мб);
4. Дисковая внешняя память (Гб);
5. Внешняя память на твердотельном носителе SSD (Гб);
6. Скорость сетевого соединения (Мбит/с);
7. Видеокарта (объём в Мб и др. характеристики).
Множество метрик 𝑀 характеризует степень загруженности того или ино­
го ресурса вычислительного узла в процессе обработки задания. В качестве
примера1 метрик выступают:
1. Средняя (максимальная) загрузка процессора(ов) – cpu utilization;
1
См. также метрики, используемые Amazon:
http://docs.aws.amazon.com/AmazonCloudWatch/lanew/DeveloperGuide/ec2-metricscollected.html
61
2. Объём потребляемой оперативной памяти;
3. Время обработки задания;
4. Количество байт записанных на диск;
5. Количество байт переданных или полученных по сети.
В процессе обработки данных в РСОД происходит назначение поступивших
задач 𝑇 на узлы обработки 𝐾 в соответствии с некоторым методом планирова­
ния 𝑓 :
𝑓 : (𝑡, 𝑘) ↦→ 𝑤,
(3.3)
где:
𝑡 ∈ 𝑇 – задача из очереди ожидания,
𝑘 ∈ 𝐾 – вычислительный узел-обработчик,
𝑤 - элемент матрицы назначения, которая является результатом работы
системы планирования задач.
С каждым единичным назначением (𝑡, 𝑘) связана некоторая оценка ресурс­
ных затрат 𝑐. Все возможные отображения множества заданий 𝑇 на множество
узлов 𝐾 характеризуются матрицей
⎛
𝑐
⎜ 11
⎜
⎜ 𝑐21
𝐶=⎜
⎜ ..
⎜ .
⎝
𝑐𝑛1
ресурсных затрат:
⎞
𝑐12 · · · 𝑐1𝑛
⎟
⎟
𝑐22 · · · 𝑐2𝑛 ⎟
⎟
.. . . . .. ⎟
.
. ⎟
⎠
𝑐𝑛2 · · · 𝑐𝑛𝑚
(3.4)
где 𝑖 ∈ [1, 𝑛]; 𝑗 ∈ [1, 𝑚]; 𝑛 = |𝑇 |; 𝑚 = |𝐾|.
Ресурсные требования заданий обработки данных зависят от многих усло­
вий и параметров:
1. Самих данных, в частности - свойств данных;
2. Классов задач обработки данных (какие операции выполнять с данными),
для которых вычислительная сложность может быть различна;
3. Доступных ресурсов узла-обработчика (памяти, скорости сетевого интер­
фейса и пр.);
62
4. Характеристик сети (пропускная способность, загрузка каналов передачи
данных и пр.);
5. Локальности данных (каковы временные затраты на загрузку данных на
узел-обработчик);
6. Характеристик из Теории Массового Обслуживания (средняя длина оче­
реди, среднее время обработки запроса и т.д.).
Предлагаемый метод учитывает характеристики обрабатываемых данных
и ресурсные характеристики узлов-обработчиков при принятии решений о пла­
нировании.
Приведённая выше матрица оценок ресурсных затрат имеет значение для
самого алгоритма планирования, но результатом планирования должны высту­
пать пары (задание, узел-обработчик), которые характеризуют назначение.
Поскольку в РСОД одно задание выполняется только на одном из выбран­
ных узлов и при параллельной обработке в РСОД задание полностью занимает
выбранный узел, отображение 𝑓 , задаваемое планировщиком полностью описы­
вается матрицей назначения:
⎛
𝑤 𝑤
⎜ 11 12
⎜
⎜ 𝑤21 𝑤22
𝑊 =⎜
⎜ ..
..
⎜ .
.
⎝
𝑤𝑛1 𝑤𝑛2
𝑤𝑖𝑗 =
· · · 𝑤1𝑛
⎞
⎟
⎟
· · · 𝑤2𝑛 ⎟
⎟
.. ⎟ ,
...
. ⎟
⎠
· · · 𝑤𝑛𝑚
(3.5)
⎧
⎪
⎨0 если задание 𝑖 не назначено на узел 𝑗
⎪
⎩1 если задание 𝑖 назначено на узел 𝑗
Таким образом выполняется условие:
𝑛
∑︁
𝑤𝑖𝑗 = 1, 𝑖, 𝑗 ∈ 𝑁.
(3.6)
𝑖=1
- то есть каждое задание назначается на выполнение только на одном вычисли­
тельном узле.
63
Если количество узлов и количество задач совпадает, то выполняется до­
полнительное условие:
𝑛
∑︁
𝑤𝑖𝑗 = 1,
𝑖=1
𝑚
∑︁
𝑤𝑖𝑗 = 1, 𝑖, 𝑗 ∈ 𝑁.
(3.7)
𝑗=1
- то есть устанавливается взаимно-однозначное соответствие между заданиями
и узлами обработки данных.
При обработке заданий, цель метода планирования состоит в том, чтобы
подобрать коэффициенты 𝑤𝑖𝑗 ∈ {0, 1}, с целью сокращения суммарных ресурс­
ных затрат:
𝑛 ∑︁
𝑚
∑︁
𝑐𝑖𝑗 𝑤𝑖𝑗 = 𝑠𝑢𝑚 −→ 𝑚𝑖𝑛.
(3.8)
𝑖=1 𝑗=1
Данная проблема в общем виде получила название задачи о назначениях
и рассмотрена в разделе 3.2.3. Для применения алгоритмов решения задачи
о назначениях (например, Венгерского алгоритма) необходимо задать способ
получения неизвестных оценок 𝑐𝑖𝑗 , который рассмотрен в предложенном методе
планирования в следующем разделе.
Стоит ещё раз отметить, что в рассмотренных в главе 1 планировщиках
отделены процессы выбора задачи из очереди и выбора узла-обработчика для
выполнения задачи, в связи с чем проблема не рассматривается как задача о
назначениях. В качестве конкретного примера реализации РСОД может высту­
пать кластер рабочих станций под управлением системы управления ресурсами
Torque (см. стр. 34) и планировщика заданий Moab (см. стр. 35).
64
3.2. Метод планирования задач в РСОД на основе
метаданных и ресурсных метрик
Определение 2.2 Метод планирования задач на основе метаданных и ресурс­
ных метрик представляет собой последовательность применения функций на
этапе сбора предыстории выполнения:
𝑓ℎ𝑖𝑠𝑡 = 𝑓ℎ𝑖𝑠𝑡.2 ∘ 𝑓ℎ𝑖𝑠𝑡.1 ,
и на этапе прогнозирования:
𝑓 = 𝑓𝑎𝑠𝑠𝑖𝑔𝑛 ∘ 𝑓𝑐𝑜𝑠𝑡.𝑒𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑜𝑛 ∘ 𝑓𝑛𝑒𝑎𝑟𝑒𝑠𝑡 ,
(3.9)
(3.10)
который позволяет получить коэффициент назначения 𝑤 для каждой пары
(задача, вычислительный узел):
𝑓 : (𝑡, 𝑘) ↦→ 𝑤
где:
(3.11)
𝑡 ∈ 𝑇 – задача из очереди ожидания,
𝑘 ∈ 𝐾 – незагруженный узел-обработчик,
𝑤 - элемент матрицы назначения, которая является результатом рабо­
ты системы планирования задач.
Описание используемых функций
I. На этапе сбора данных предыстории применяются следующие функции:
I.1. Функция 𝑓ℎ𝑖𝑠𝑡.1 : (𝑡, 𝑘) ↦→ (𝑚1 , 𝑚2 , · · · 𝑚𝑟 ) ∈ 𝑀ℎ𝑖𝑠𝑡 , 𝑟 ∈ 𝑁
– задаёт способ получения метрик загрузки вычислительных ресур­
сов, где:
𝑡 ∈ 𝑇ℎ𝑖𝑠𝑡 - задача обработки данных, 𝑘 ∈ 𝐾ℎ𝑖𝑠𝑡 - узел-обработчик,
𝑀ℎ𝑖𝑠𝑡 - множество кортежей метрик загрузки ресурсов, полученных
в результате выполнения.
I.2. Функция 𝑓ℎ𝑖𝑠𝑡.2 : (𝑚1 , 𝑚2 , · · · 𝑚𝑟 ) ↦→ 𝑐
– задаёт способ получения оценок вычислительных затрат 𝑐 ∈ 𝐶ℎ𝑖𝑠𝑡
для задач предыстории.
65
В результате использования указанных функций на этапе сбора данных
предыстории строится множество троек (𝑡, 𝑘, 𝑐) ∈ 𝐺ℎ𝑖𝑠𝑡 , которое в дальней­
шем используется для прогнозирования затрат выполнения новых задач,
где:
𝑡 – задача обработки данных,
𝑘 – вычислительный узел, на котором выполнялась обработка данных,
𝑐 – оценка вычислительных затрат, полученная в результате выполнения.
II. На этапе прогнозирования применяются следующие функции:
II.1. Функция 𝑓𝑛𝑒𝑎𝑟𝑒𝑠𝑡 : 𝑇 × 𝐾 ↦→ 𝐺ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡
– задаёт способ получения ближайших к новой паре (𝑡, 𝑘)
троек (𝑡ℎ𝑖𝑠𝑡 , 𝑘ℎ𝑖𝑠𝑡 , 𝑐) ∈ 𝐺ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 ⊂ 𝐺ℎ𝑖𝑠𝑡 из предыстории, для кото­
рых известны оценки вычислительных затрат 𝑐.
II.2. Функция 𝑓𝑐𝑜𝑠𝑡.𝑒𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑜𝑛 : 𝑇 × 𝐾 × 𝐶ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 ↦→ 𝐶 – задаёт способ по­
лучения оценок вычислительных затрат на выполнение новых задач
на доступных вычислительных узлах, где:
𝐶ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 = {𝑐1 , 𝑐2 , · · · 𝑐𝑛 }, для некоторого 𝑛 ∈ 𝑁 - оценки вычисли­
тельных затрат из полученного множества 𝐺ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 .
II.3. Функция 𝑓𝑎𝑠𝑠𝑖𝑔𝑛 : 𝑐 ↦→ 𝑤
– задаёт способ получения коэффициентов назначения на основе по­
лученных оценок, где:
𝑐 ∈ 𝐶 - коэффициент оценки вычислительных затрат выполнения
задач из очереди ожидания;
𝑤 - элемент матрицы назначения, которая является результатом ра­
боты системы планирования задач.
Рассмотрим составляющие метода планирования более подробно.
В данной работе предлагается решать существующую проблему отсутствия
информации о ресурсных требованиях с помощью оценки ресурсных затрат 𝑐
на основе предыстории выполнения задач. Данный шаг предложенного метода
рассмотрен в разделе 3.2.1.
66
Для вновь поступивших на вход системы планирования задач оценки мо­
гут быть получены путём поиска близких задач с использованием метода бли­
жайшего соседа. При этом предлагается выполнять сравнение новой задачи с
задачами из предыстории экспериментов на основе атрибутов (метаданных),
а затем оценки вычислительных затрат наиболее близких задач использовать
для получения значения ресурсных затрат для новой задачи. Данный шаг пред­
ложенного метода рассмотрен в разделе 3.2.2.
В процессе функционирования системы планирования РСОД становятся
доступными также фактические значения метрик загрузки вычислительных
ресурсов в результате выполнения новых задач, которые в дальнейшем могут
служить для повышения точности сравнения и повышения качества планиро­
вания.
После получения оценок вычислительных затрат выполнения задач на мно­
жестве узлов-обработчиков, то есть построения матрицы вычислительных за­
трат, проблема планирования сводится к решению задачи о назначениях. Дан­
ный шаг рассмотрен в разделе 3.2.3.
3.2.1. Вычисление ресурсных затрат выполнения на основе
ресурсных метрик
В данном разделе рассматривается вопрос, что подразумевается под ре­
сурсными затратами выполнения 𝑐𝑖𝑗 выбранной задачи 𝑖 на узле обработки 𝑗,
а также каким образом может оцениваться данная величина.
В результате фактического запуска задач на оборудовании РСОД становят­
ся доступны определённые метрики загрузки вычислительных ресурсов 𝑀 =
{𝑚1 , 𝑚2 , . . . , 𝑚𝑘 }, для некоторого 𝑘 ∈ 𝑁 .
Таким образом функция 𝑓ℎ𝑖𝑠𝑡.1 - не задаётся аналитически, а является про­
цедурой экспериментального запуска задач обработки данных на узлах-обра­
ботчиках РСОД, которая позволяет в результате получить множество метрик
𝑀ℎ𝑖𝑠𝑡 загрузки ресурсов.
67
В качестве примера собранных метрик могут выступать следующие харак­
теристики:
- Средняя загрузка процессора;
- Средняя величина объёма потребляемой оперативной памяти;
- Время выполнения задачи.
Такие метрики характеризуют временные и ресурсные затраты на выпол­
нение задачи, то есть косвенно отражают её ресурсные требования и могут быть
использованы для прогнозирования ресурсных затрат на выполнение новых за­
дач.
Таким образом, на этапе сбора данных предыстории, затраты ресурсов на
выполнение можно рассматривать как значение функции, которая зависит от
значений ресурсных метрик и, отображает их на некоторый вещественный ин­
тервал [0, 𝑑]:
𝑐 = 𝑓ℎ𝑖𝑠𝑡.2 (𝑀 ) = 𝑓ℎ𝑖𝑠𝑡.2 (𝑚1 , 𝑚2 , . . . , 𝑚𝑘 ) −→ [0, 𝑑], 𝑑 ∈ 𝑅
(3.12)
В качестве 𝑓ℎ𝑖𝑠𝑡.2 можно использовать различные функции, устанавливаю­
щие зависимость ресурсных затрат от метрик. К примеру можно использовать
следующую функцию:
𝑓ℎ𝑖𝑠𝑡.2 (𝑚1 , 𝑚2 , . . . , 𝑚𝑘 ) = 𝑎1 · 𝑚1 + 𝑎2 · 𝑚2 + · · · + 𝑎𝑘 · 𝑚𝑘 =
𝑘
∑︁
𝑎𝑖 · 𝑚𝑖 ,
(3.13)
𝑖=0
где 𝑎𝑖 ∈ [0, 1] - коэффициент значимости, оценивающий вклад данной метрики
в итоговую оценку затрат.
Функция 𝑓ℎ𝑖𝑠𝑡.2 отражает вклад каждой метрики в итоговое значение ре­
∑︀
сурсных затрат выполнения. В простейшем случае 𝑓ℎ𝑖𝑠𝑡.2 = 𝑘𝑖=0 𝑚𝑖 - все мет­
рики считаются равноправными.
Поскольку для планирования задач имеет значение не абсолютное значе­
ние стоимости запуска выбранной задачи 𝑖 на узле обработки 𝑗, а стоимость
68
относительно других задач, имеет смысл после получения всех значений 𝑐𝑖𝑗
провести нормализацию используя формулы, рассмотренные в разделе 2.4.
В результате применения функций 𝑓ℎ𝑖𝑠𝑡.1 и 𝑓ℎ𝑖𝑠𝑡.2 на данном этапе получены
фактические метрики загрузки ресурсов, и выведенные из них оценки ресурс­
ных затрат выполнения задач обработки данных. Полученные оценки затрат
призваны заменить отсутствие априорных знаний о ресурсных требованиях за­
дач.
3.2.2. Оценка ресурсных затрат на выполнение на основе
метаданных
В предыдущем разделе рассматривался вопрос, как получить значения ре­
сурсных затрат на выполнение выбранной задачи на выбранном узле обработки
на основе метрик, полученных в ходе экспериментов.
Найденные таким способом апостериорные оценки необходимо применить
в процессе планирования новых задач. Иными словами, необходимо найти от­
вет на вопрос: каким образом произвести оценку ресурсных затрат для вновь
поступивших задач используя предысторию выполнения задач?
Для этой цели, необходимо установить связь между новой парой (задача,
узел-обработчик) (𝑡, 𝑘) и парой (𝑡ℎ𝑖𝑠𝑡 , 𝑘ℎ𝑖𝑠𝑡 ) из предыстории выполнения 𝐺ℎ𝑖𝑠𝑡 ,
для которой имеется оценка затрат 𝑐ℎ𝑖𝑠𝑡 . Иными словами, необходимо найти
наиболее похожую задачу(и) и использовать имеющиеся значения затрат для
оценки значения 𝑐 новой задачи.
Сравнение задач предлагается осуществить на основе метаданных, - тех
атрибутов, которыми обладают задачи, как было указано в разделе 3.1 на стра­
нице 60: 𝐴 = {𝑎1 , 𝑎2 , . . . , 𝑎𝑠 }, 𝑠 ∈ 𝑁 . Используя атрибуты и некоторую метрику
расстояния можно определить наиболее близкую задачу (к примеру расстояние
по Хеммингу):
𝐷(𝑡𝑎 , 𝑡𝑏 ) =
𝑠
∑︁
𝑖=1
69
(|𝑎𝑖 | − |𝑏𝑖 |) ,
(3.14)
где 𝑎𝑖 и 𝑏𝑖 - атрибуты задач 𝑡𝑎 и 𝑡𝑏 соответственно.
Помимо метрики расстояния допустимо использовать обратную величину
- меру сходства. Для сравнения объектов с категориальными атрибутами суще­
ствуют различные способы нахождения величины меры схожести, как показано
в работе [35].
Для перехода от меры расстояния к мере сходства 𝑆𝑖𝑚 используется сле­
дующая формула:
𝑆𝑖𝑚 =
1
.
1+𝐷
(3.15)
Если вычислить расстояние до всех имеющихся задач, можно выделить
подмножество 𝐺ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 ⊂ 𝐺ℎ𝑖𝑠𝑡 наиболее близких задач. В простейшем случае
выбирается одна задача, для которой метрика расстояния минимальна.
Затем можно оценить ресурсные затраты для новой задачи 𝑡 как среднее
значение затрат выполнения для задач из полученного множества 𝑇ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 :
∑︀𝑛
𝑐𝑖
𝑐 = 𝑓𝑐𝑜𝑠𝑡.𝑒𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑜𝑛 = 𝑖=1 , 𝑐𝑖 ∈ 𝑇
(3.16)
𝑛
В результате, после выполнения указанных выше вычислений для каждой
пары (задача, узел) строится матрица ресурсных затрат 𝐶 3.4.
В работе [48] предложен схожий метод оценки затрат, который использу­
ется для прогнозирования временных затрат на выполнение заданий в Грид
системах. На основе предыдущих экспериментов, рекомендательная система
(Case-Based Reasoning) ищет наиболее похожие по описанию задания (вычис­
ляя расстояние) и затем оценивает временные затраты для нового задания. В
данной работе предложен более общий подход, когда помимо описания зада­
ния для сравнения используются также и метаданные прикладной области, а
прогнозирование направлено на ресурсные затраты а не на оценку времени вы­
полнения.
70
3.2.3. Вычисление матрицы назначения
После получения матрицы ресурсных затрат, необходимо составить матри­
цу назначения таким образом, чтобы минимизировать суммарные затраты в
соответствии с формулой 3.8.
В более общем виде задача о назначениях формулируется следующим об­
разом. Дана матрица 𝐴 размером 𝑛 × 𝑛. Требуется в каждой её строке выбрать
по одному числу так, чтобы в любом столбце также было выбрано ровно по
одному числу, и при этом сумма выбранных чисел была бы минимальной.
Альтернативная формулировка. Дан полный двудольный граф с верши­
нами; каждому ребру приписан некоторый вес. Требуется найти совершенное
паросочетание минимального веса [49].
Для решения данной задачи традиционно применяются методы комбина­
торной оптимизации такие как Венгерский алгоритм [50], алгоритм Хопкрофта­
Карпа [51] и алгоритм Джеймса Манкреса [52].
Поскольку перечисленные алгоритмы подробно изложены в указанных ис­
точниках, в целях сокращения изложения детали получения матрицы назначе­
ния 𝑊 на основе матрицы стоимости 𝐶 представляется целесообразным опу­
стить:
𝑓𝑎𝑠𝑠𝑖𝑔𝑛 : 𝐶 ↦→ 𝑊.
71
(3.17)
3.3. Модификация алгоритма поиска ближайших соседей
на основе метода локализованного хэширования
Описанный выше метод планирования задач на основе метаданных и ре­
сурсных метрик на шаге II.1 предполагает осуществление поиска ближайших
соседей для обрабатываемых объектов данных.
Существующие объекты данных характеризуются как категориальными
так и численными атрибутами, что не позволяет применять метрики расстояния
рассчитанные на отдельные типы атрибутов (например евклидово расстояние
или расстояние хэмминга).
Для сравнения таких объектов данных, как было показано в разделе 2.4
применимы гетерогенные функции расстояния. При этом отдельно вычисляют­
ся по-атрибутные расстояния как для категориальных, так и для численных
атрибутов. Полученные величины нормализуются и взвешиваются, чтобы со­
кратить влияние зашумлённых значений и разность шкал.
Основной проблемой такого рода поиска выступает его высокая размер­
ность. Для каждого объекта данных (задания) необходимо вычислить расстоя­
ние до всех 𝑛 объектов из предыстории выполнения, что приводит к линейной
асимптотической сложности единичного запроса 𝑂(𝑛).
При планировании группы заданий необходимо произвести оценку ресурс­
ных затрат для всех сочетаний (узел-обработчик, задание), что ведёт к общей
асимптотической сложности:
𝑂(ℎ · 𝑣 · 𝑛) = ℎ · 𝑣 · 𝑂(𝑛) = 𝑂(𝑛)
(3.18)
где:
ℎ - количество доступных для планировщика узлов-обработчиков,
𝑣 - количество заданий ожидающих обработки.
Несмотря на теоретически линейную сложность, на практике константы ℎ
и 𝑣 также оказывают существенный вклад на вычислительную трудоёмкость
72
процесса планирования. К примеру при доступности 33 узлов обработчиков и
наличии по крайней мере 33 заданий в очереди ожидания, требуется выполнить
1089 запросов, каждый из которых имеет линейную сложность, зависящую от
объёма данных предыстории.
Существуют различные подходы, позволяющие сократить размерность опе­
рации поиска ближайших соседей. Среди них особо стоит отметить следующие
методы:
1. Cжатие множества данных [53], на котором осуществляется поиск ближай­
ших соседей. Выполняется удаление дубликатов, зашумлённых и нерепре­
зентативных данных. Кроме того объекты данных, для которых метрика
расстояния ниже определённого заданного порога, также подвергаются
сокращению.
2. Использование индексных иерархичных структур данных: kd-деревьев [54],
VP-деревьев [55], R-деревьев [56] и других. Многомерные деревья позволя­
ют свести поиск в среднем к логарифмическому времени 𝑂(log (𝑛)). Одна­
ко такие структуры данных дают линейную трудоёмкость при размерно­
сти поиска (количество координат точки) больше 20 ввиду т.н. проклятия
размерности [57, 58].
3. Использование метода локализованного хэширования Local Sensitivity Hashing
[59–61], в соответствии с которым для каждого объекта данных вычисля­
ется хэш значение и благодаря использованию локальных хэш функций
близкие объекты попадают в одну корзину в хэш таблице. При этом коли­
чество корзин (𝑏𝑢𝑐𝑘𝑒𝑡𝑠) много меньше количества объектов 𝑏𝑢𝑐𝑘𝑒𝑡𝑠 << 𝑛.
Метод позволяет за константное время 𝑂(1) перейти к подмножеству
𝑁𝑠𝑢𝑏 ∈ 𝑁 объектов, мощность которого много меньше мощности исход­
ного множества |𝑁𝑠𝑢𝑏 | << |𝑁 |. Для получения ближаших 𝑘 соседей вы­
числяется расстояние до всех объектов множества 𝑁𝑠𝑢𝑏 и выбираются 𝑘
объектов с наименьшим расстоянием.
Для сокращения размерности поиска 𝑘 ближайших соседей для объектов
73
с разнородными атрибутами в настоящей работе предлагается алгоритм на ос­
нове метода локализованного хэширования поскольку данный метод обладает
достаточной масштабируемостью: часть поиска осуществляется за время 𝑂(1).
При осуществлении поиска ближайших соседей на основе метода локально­
го хэширования крайне важно корректно выбрать атрибуты данных, на основе
которых будет вычисляться хэш значение. Данный выбор определяет какая
часть поиска будет выполняться за константное время, а какая за линейное.
Это должны быть атрибуты, отражающие похожесть (близость) объектов дан­
ных. При этом выбор атрибутов должен производиться исходя из специфики
прикладной области.
Применительно к задаче планирования задач в РСОД необходимо задать
хэш функции исходя из следующих требований:
1. Необходимо выбрать в качестве значимых те атрибуты данных, которые
оказывают наибольший вклад в ресурсопотребление задания.
2. Необходимо учесть гетерогенность атрибутов, поскольку прикладные за­
дания характеризуются как категориальными, так и численными метадан­
ными.
Исходя из сформулированных требований в настоящей работе предлагает­
ся модификация алгоритма поиска на основе метода локализованного хэширо­
вания, которая позволяет выполнить часть поиска за константное время 𝑂(1),
а часть – за сублинейное 𝑂(𝑟), 𝑟 << 𝑛. Отличия от стандартного алгоритма
выделены жирным шрифтом.
Алгоритм 3.1 (Модификация алгоритма поиска ближайших соседей на основе
метода локализованного хэширования). Алгоритм описывается в виде после­
довательности шагов:
I. Выбор атрибутов для хэширования:
I.1. Разделить множество атрибутов на категориальные и численные.
I.2. Для каждого из полученных множеств вычислить коэффи­
74
циенты значимости используя обучающую выборку.
I.3. Выбрать 𝑛 наиболее значимых для ресурсопотребления ка­
тегориальных атрибутов и 𝑛 наиболее значимых численных
атрибутов.
II. Построение хэш-таблицы на основе обучающей выборки: для каждого
объекта данных:
II.1. Вычислить хэш значение отдельно для категориальных и
отдельно для численных типов из множества выбранных на
шаге 1.3 атрибутов.
II.2. Использовать полученный суммарный хэш в качестве индекса в
хэш таблице для выбора корзины.
II.3. Сохранить идентификатор объекта по полученному адресу в хэш
таблицу.
III. Поиск 𝑘 ближайших соседей для нового объекта:
III.1. Вычислить хэш значение отдельно для категориальных и
отдельно для численных типов из множества выбранных на
шаге 1.3 атрибутов.
III.2. Использовать полученный суммарный хэш в качестве индекса в
хэш таблице для выбора корзины.
III.3. Вычислить расстояние до каждого из объектов, идентификаторы
которых хранятся в корзине, полученной на предыдущем шаге.
III.4. Отсортировать полученный вектор расстояний.
III.5. Выбрать 𝑘 объектов с наименьшим расстоянием.
Схематично последний этап работы алгоритма, то есть процесс поиска бли­
жайших соседей на основе выбранных атрибутов представлен на Рисунке 3.1.
75
Рисунок 3.1. Процесс поиска ближайших соседей
3.4. Методика планирования задач на основе метаданных
и ресурсных метрик
Для применения описанного метода планирования задач в РСОД на прак­
тике, была сформулирована методика планирования задач на основе метадан­
ных и ресурсных метрик (Рисунок 3.2):
I. Этап одноразовой настройки РСОД:
I.1. Задать процедуры извлечения и сохранения метаданных.
I.2. Задать процедуры получения и сохранения метрик загрузки ресур­
сов.
II. Этап работы системы в режиме накопления истории экспериментов - сбор
экспериментальных данных:
II.1–2. Запустить задания поочерёдно на всех узлах распределённой систе­
мы. Потребуется провести цикл запусков одних и тех же заданий,
но на разных узлах. Различные задания в рамках одной итерации
76
запуска могут обрабатываться параллельно.
II.3–4. Произвести сбор метрик загрузки ресурсов для каждой пары (зада­
ние, узел-обработчик). При этом под заданием подразумевается мно­
жество атрибутов данных (метаданных). Узел-обработчик описыва­
ется множеством ресурсных характеристик узла, а метрики характе­
ризуют загрузку отдельных ресурсов вычислительного узла.
II.5. Вычислить апостериорные оценки ресурсных затрат выполнения за­
даний на основе собранных метрик. Сохранить множество кортежей,
где элементом выступает тройка объектов (задание, узел-обработ­
чик, оценка затрат). Для этого имеет смысл использовать любую
ассоциативную структуру данных.
III. Этап прогнозирования - применения истории экспериментов для оценки
ресурсных затрат новых заданий:
III.1–3. Для каждого задания - найти множество наиболее близких заданий,
сравнив их атрибуты данных. Для сравнения заданий используется
функция расстояния, с учётом степени значимости отдельных аттри­
бутов.
III.4. Для каждого множества близких заданий из предыстории экспери­
ментов - загрузить вектора оценок выполнения на узлах распреде­
лённой системы.
III.5. Для каждого задания - получить вектор априорных оценок затрат
выполнения на каждом узле, на основе векторов стоимости выполне­
ния заданий из предыстории. Для получения новой оценки использу­
ется функция агрегации существующих оценок. В простейшем случае
считается, что вклад каждой отдельной оценки в результирующую
оценку равнозначен. Более трудоёмкий, но зачастую более обосно­
ванный подход предполагает взвешивание отдельных оценок в зави­
симости от их актуальности применительно к данной прикладной
области.
77
III.6. Получив матрицу затрат выполнения группы заданий на множестве
узлов распределённой системы в результате выполнения предыду­
щих шагов, необходимо получить оптимальный способ назначения
заданий на узлы одним из существующих алгоритмов решения зада­
чи о назначениях - Хопкрофта-Карпа, Джеймса Манкреса и др. Ре­
зультатом выполнения данного шага является матрица назначения.
III.7. На данном шаге выполняется непосредственное выполнение заданий
на узлах распределённой системы в соответствии с полученной мат­
рицей назначения.
IV. Этап дообучения:
IV.1. Аналогично п.II.3–4 выполнить сбор метрик для выполненных зада­
ний.
IV.2. Аналогично п.II.5. вычислить апостериорные оценки ресурсных за­
трат выполнения заданий на основе собранных метрик.
78
Рисунок 3.2. Методика планирования задач на основе метаданных и ресурсных метрик
3.5. Выводы
1. Предложена математическая модель планирования задач в РСОД,
в структуре которой явно выделены атрибуты данных (метаданные) и
метрики загрузки ресурсов. Последние апостериорно характеризуют ре­
сурсные требования задач, и выступают основой для выполнения про­
гнозирования ресурсных затрат.
2. Основываясь на предложенной модели, предложен метод планирования
задач в РСОД, который базируется на учёте корреляции между метадан­
ными и метриками загрузки ресурсов и не требует априорных знаний о
ресурсных требованиях поскольку основан на предыстории обработки за­
дач.
3. Для сокращения размерности процесса поиска ближайших соседей пред­
ложен алгоритм поиска 𝑘 ближайших соседей на основе локализован­
ного хэширования, который учитывает тип атрибутов и значимость атри­
бутов для потребления вычислительных ресурсов.
4. Для использования предложенного метода в системах управления ресур­
сами РСОД на практике предложена методика планирования задач в
РСОД.
80
Глава 4
Экспериментальная оценка эффективности
предложенного метода
В настоящей главе приведена обобщённая архитектура РСОД, реализую­
щая предложенный метод планирования.
Кроме того, рассматривается применение предложенного метода планиро­
вания к задачам декодирования видео данных и обработки гидрографических
данных. Приводится подробное описание используемых атрибутов данных, мет­
рик загрузки вычислительных ресурсов, и процедуры прогнозирования ресурс­
ных затрат на основе предыстории экспериментов.
4.1. Архитектура программной системы
Предложенный метод определяет компоненты программной системы, изоб­
ражённые на диаграмме компонентов на Рисунке 4.1.
Планировщик заданий и ресурсов реализует функции планирования зада­
ний обработки данных и назначения вычислительных ресурсов, и включает в
себя модули оценки ресурсных затрат и назначения ресурсов.
Модуль оценки ресурсных затрат служит для обработки данных предыс­
тории экспериментов и реализует функцию 𝑓ℎ𝑖𝑠𝑡.2 предложенного метода пла­
нирования: на основе экспериментально полученных метрик 𝑀ℎ𝑖𝑠𝑡 вычисляют­
ся коэффициенты ресурсных затрат 𝑐 и строится множество кортежей вида
(𝑡, 𝑘, 𝑐) ∈ 𝐺ℎ𝑖𝑠𝑡 .
Также данный модуль используется для выполнения оценки ресурсных за­
трат для вновь поступивших заданий: построенная ранее модель используется
для нахождения близких заданий 𝑇ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 и их оценки усредняются для полу­
чения оценки ресурсных затрат для нового задания. В результате для выбран­
81
Рисунок 4.1. Диаграмма компонентов системы планирования заданий и ресурсов РСОД
ной группы заданий модуль строит матрицу ресурсных затрат 𝐶.
Модуль назначения ресурсов получает матрицу ресурных затрат 𝐶 от мо­
дуля оценки и решает задачу о назначениях, то есть ищет оптимальный способ
назначения поступивших заданий на имеющиеся ресурсы (узлы-обработчики).
В результате строится матрица назначения 𝑊 .
В качестве сторонних компонентов выступают система управления ресур­
сами и модуль сбора ресурсных метрик.
Система управления ресурсами получает матрицу назначения 𝑊 от моду­
ля планирования, затем передаёт команды по запуску соответствующих зада­
ний на каждом вычислительном узле. Помимо этого поддерживаются функции
уведомления о завершении обработки ранее запущенных заданий и месте сохра­
нения результатов обработки данных.
Модуль сбора метрик предоставляет метрические данные о загрузке си­
стемных ресурсов (памяти, процессора, графического процессора, подсистемы
82
ввода-вывода и др.) на узлах-обработчиках, предоставляет информацию о вре­
мени выполнения отдельных задач, а также позволяет узнать конфигурацию
(объём доступной памяти, количество свободных процессоров и пр.) каждого
из вычислительных узлов системы. Соответствует информационному сервису в
терминологии существующих систем управления ресурсами.
Модуль обработки метаданных отвечает за операции по извлечению, пре­
образованию и сохранению метаданных.
Рассмотрим логику работы программного кода, реализующего предложен­
ный метод. Диаграмма состояний изображена на Рисунке 4.2.
Рисунок 4.2. Диаграмма состояний
Логика работы отличается в зависимости от этапа работы: на Рисунке 4.2
изображены диаграммы состояний для этапа сбора данных предыстории (слева)
и для этапа прогнозирования (справа).
Для сбора данных предыстории выполнения выполняется запуск заданий
83
на узлах-обработчиках. По результатам выполнения заданий собираются мет­
рики загрузки ресурсов, на основе которых вычисляются нормализованные ко­
эффициенты затрат выполнения для каждой пары (задание, узел). Собранные
в результате такого процесса данные используются на этапе прогнозирования.
Диаграмма классов изображена на Рисунке 4.3. Основными классами, ре­
ализующими систему планирования заданий в РСОД являются:
1. Планировщик заданий (Task Scheduler);
2. Класс агента-обработчика данных (Processing Agent);
3. Класс для осуществления доступа к хранилищу данных (Data Storage);
4. Класс для осуществления доступа к хранилищу метаданных (Metadata
Storage);
5. Класс для извлечения метаданных (Metadata Extractor);
6. Класс для сохранения метрик загрузки ресурсов (Metrics Saver).
Планировщик заданий включает в себя объект класса Metadata Mapper,
который выполняет функции по преобразованию метаданных к формату при­
годному для выполнения поиска ближайших соседей в соответствии с предло­
женным алгоритмом, а также объект класса Model Builder, на котором лежат
функции по построению модели прогнозирования.
84
85
Рисунок 4.3. Диаграмма классов
Для тестирования методов планирования задач в диаграмму классов добав­
лен класс генератора заданий (Task Generator), который позволяет порождать
группы заданий generateTasks() с заданным периодом времени в зависимости
от выбранного режима интенсивности загрузки (mode) - слабый (до 6 задач в
минуту), средний (от 6 до 19 з/мин) или режим высокой загрузки (86 з/мин и
выше).
Помимо интенсивности загрузки генератор позволяет настраивать трудо­
емкости заданий (слабая, средняя и высокая) и их распределение:
1. Constant - константное распределение трудоемкости. Генерируются зада­
ния средней трудоемкости.
2. Uniform – равномерное дискретное распределение трудоемкости. Выбор
каждого из типов трудоёмкости заданий равновероятен.
3. Random – случайное распределение трудоемкости. Для выбора трудоём­
кости задания используется программный генератор случайных чисел.
4. Weighted Discrete – взвешенное дискретное распределение трудоемкости.
Приближение гауссова распределения по трудоемкости заданий, при ко­
тором 72% заданий имеют среднюю трудоемкость, а задания с высокой и
низкой трудоёмкостью получают по 14% соответственно.
86
4.2. Задача декодирования видео данных
4.2.1. Описание задачи
В качестве прикладной задачи для проверки предложенного метода плани­
рования в данной работе рассматривается задача декодирования видео данных.
Данная задача возникает на практике всё чаще в связи с распространением пе­
реносных мобильных цифровых устройств.
Широко известные сервисы видео хостинга YouTube, Vimeo, DailyMotion,
а также платные сервисы распространения видео по подписке Netflix, Amazon
Prime, Cloudload и другие, предоставляют несколько уровней качеста видео по­
тока. При этом, преобразование данных производится заранее исходя из за­
данного набора профилей, а результат сохраняется для последующего доступа.
Различные профили декодирования необходимы по ряду причин:
1. Устройства воспроизведения обладают различными аппаратными ресур­
сами исходя из своего ценового сегмента;
2. Скорость сетевого соединения до конечного клиента зачастую накладыва­
ет ограничения на передачу видео высокого разрешения;
3. Высокая нагрузка на сервера контент-провайдера также способна ограни­
чить скорость передачи данных.
В отличие от перечисленных сервисов, где задачи декодирования решаются
заранее, Amazon Elastic Transcoder является примером сервиса, позволяющего
арендовать вычислительные ресурсы по требованию для тех же целей. Данная
возможность предоставляет определённую гибкость разработчикам приложе­
ний с одной стороны и администраторам центров обработки данных с другой
стороны.
В данной диссертационной работе предлагается реализовать подобный сер­
вис для тестирования методов планирования задач.
Основная задача сервиса такого типа - назначить поступившие задачи об­
работки данных на доступные вычислительные ресурсы (узлы-обработчики)
87
сохранив баланс между:
1. временными затратами на обработку заявок, что актуально для пользова­
теля - и
2. оптимальностью использования вычислительных ресурсов, что актуально
для хостинг провайдера.
Такая постановка проблемы приводит к необходимости планирования и
решении задачи о назначениях, для чего применим предложенный метод пла­
нирования на основе метаданных и метрик загрузки ресурсов.
4.2.2. Инфраструктура и метаданные
Рассмотрим подробнее конфигурацию распределённой среды обработки дан­
ных и особенности решаемой задачи. Диаграмма развертывания, описывающая
основные программные компоненты и вычислительные узлы распределённой
системы приведена на Рисунке 4.4.
В качестве основы распределённой среды исполнения выступают 33 вычис­
лительных узла с конфигурацией представленной в Таблице 4.1.
Таблица 4.1. Конфигурация РСОД
Кроме узлов обработчиков используются:
1. Узел хранения данных и сервер наименования объектов;
2. Узел хранения метаданных и моделей;
3. Узел генерации заданий и планирования;
88
89
Рисунок 4.4. Диаграмма развёртывания
Для связи компонентов системы используется промежуточное ПО Pyro,
которое предоставляет серсис наименования и доступа к распределённым объ­
ектам. В качестве распределённых объектов в системе выступают:
1. Сервер наименования объектов;
2. Множество объектов-обработчиков, которые запускают процедуры обра­
ботки данных;
3. Cервис извлечения метаданных, который извлекает свойства видеопотока
при поступлении новых файлов и сохраняет их в базу данных;
4. Сервис синхронизации времени - используется для получения временных
штампов, необходимых для метрического анализа;
5. Сервис планирования заданий, выполняющий назначение ресурсов;
6. Сервис генерации заданий.
В качестве метаданных задач обработки выступают:
1. Cвойства видео потока;
2. Cвойства устройств воспроизведения;
3. Cвойства сетевого соединения - классы пропускной способности среды.
Для каждой группы метаданных сущестует свой жизненный цикл, соглас­
но которому задаются процедуры извлечения метаданных, их преобразования,
сохранения и использования. В то время как свойства видео потока извлекают­
ся заранее при подгрузке новых исходных видео файлов, свойства устройства
с которого пользователь формирует заявку и сетевого соединения становятся
известны лишь при поступлении задач на вход системы планирования.
На Рисунке 4.5 приведён пример метаданных видео потока, которые были
получены с помощью консольной утилиты MediaInfo1 .
С точки зрения инфраструктуры распределённой среды обработки, дан­
ные хранятся на центральном узле и доступны для узлов-обработчиков через
Network File System. Те из метаданных, которые извлекаются заранее, хранятся
в базе данных на отдельном вычислительном узле.
1
Утилита MediaInfo: http://sourceforge.net/projects/mediainfo
90
Рисунок 4.5. Пример метаданных
Несмотря на то, что информация о свойствах устройств и сетевых соеди­
нений неизвестна до момента получения заданий, при проектировании системы
задаются их классы с общими свойствами.
Для типовых, наиболее распространённых устройств задаются профили
декодирования, которые представлены в Таблице 4.2. В качестве основы для
составления профилей использовались классы предустановок утилиты декоди­
рования HandBrake2 .
В зависимости от класса устройства формируются такие свойства как ви­
део битрейт (bit rate), разрешение (width * height, высота выбирается пропор­
2
Профили декодирования HandBrake: https://trac.handbrake.fr/wiki/BuiltInPresets
91
Таблица 4.2. Профили декодирования
ционально), количество аудио каналов (channels), частота дискретизации звука
(sampling rate) и аудио битрейт.
Свойства ffmpeg preset, h264 profile, h264 level определяют настройки де­
кодирования видео в выходной формат H.2643 , который на данный момент яв­
ляется стандартом де-факто для компрессии видео. Исходя из этих свойств
определяется баланс между скоростью и качеством декодирования. Кроме того,
мультимедийные устройства специфицируют поддержку того или иного уровня
сжатия (h264_profile, h264_level) исходя из своих аппаратных возможностей.
Для конвертации видео и аудио данных применяется инструментарий ffmpeg4 ,
который широко используется, в том числе и сервисом YouTube.
В Таблице 4.3 перечислены ограничения на свойства декодирования, на­
кладываемые исходя из класса используемого соединения.
Как можно видеть в приведённой таблице, свойства декодирования подо­
3
Формат сжатия видео H.264: http://en.wikipedia.org/wiki/H.264
4
Набор библиотек ffmpeg: http://www.ffmpeg.org/
92
Таблица 4.3. Классы сетевых соединений
браны таким образом, чтобы адаптировать битрейт под пропускную способ­
ность сети.
Рассмотрим как все указанные выше метаданные извлекаются, после чего
составляется набор описательных метаданных для каждого поступившего на
вход системы задания.
4.2.3. Жизненный цикл метаданных
В целях эксперимента, задачи обработки данных порождаются программ­
ным способом посредством генератора и поступают на узел-планировщик (ге­
нератор и узел-планировщик находятся на одной физической машине), где про­
исходит назначение поступивших задач на узлы-обработчики.
Генератор заданий, выдаёт с заданным временным интервалом 𝑇 множе­
ство кортежей вида
(𝑑𝑒𝑣𝑖𝑐𝑒_𝑡𝑦𝑝𝑒, 𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛_𝑡𝑦𝑝𝑒, 𝑣𝑖𝑑𝑒𝑜_𝑖𝑑),
(4.1)
где:
𝑑𝑒𝑣𝑖𝑐𝑒_𝑡𝑦𝑝𝑒 - тип устройства воспроизведения,
𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛_𝑡𝑦𝑝𝑒 - тип сетевого соединения,
𝑣𝑖𝑑𝑒𝑜_𝑖𝑑 - идентификатор видео файла.
При поступлении таких кортежей в систему, выполняется получение мета­
данных, их преобразование и непосредственно обработка данных. Последова­
93
тельность этапов обработки каждого задания представлена на диаграмме по­
следовательности 4.6.
Запрос инициируется пользователем (User), когда происходит выбор видео
файла для обработки: show_video(id). Затем программный клиент (Software
Client) дополняет метаданные запроса информацией о типе устройства и клас­
се сетевого соединения: add_metadata(). В результате, сервис декодирования
видео (Service) получает на вход задание, которое представляет собой кортеж
вида 4.1.
Получив задание, сервис выполняет отображение входных данных на мно­
жество метаданных, определяющих задание декодирования: map_metadata().
Преобразование входного запроса производится в несколько этапов. Ис­
пользуя полученные данные по идентификатору видео файла подгружаются
из базы данных метаданные исходного видео потока. Также по идентификато­
ру типа устройства подгружается профиль декодирования, который определяет
свойства выходного видео потока.
По идентификатору типа соединения подгружается профиль декодирова­
ния, определяющий ограничения на качество выходного видео потока исходя
из возможностей сетевого соединения.
Значение каждого свойства декодирования (к примеру видео битрейт) опре­
деляется следующим образом:
𝑝 = 𝑚𝑖𝑛(𝑝𝑠𝑟𝑐 , 𝑝𝑑𝑒𝑣𝑖𝑐𝑒 , 𝑝𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛 ),
(4.2)
где:
𝑝𝑠𝑟𝑐 - значение свойства в исходном видео файле,
𝑝𝑑𝑒𝑣𝑖𝑐𝑒 - значение свойства, определённое для класса устройств,
𝑝𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛 - верхняя граница, определённая исходя из скорости сетевого соедине­
ния.
94
95
Рисунок 4.6. Диаграмма последовательности обработки заявки
Таким образом, метаданные, которые задают трудоёмкость операции де­
кодирования, формируются исходя из свойств исходного видео файла, класса
устройства воспроизведения (иными словами - его аппаратных возможностей)
и пропускной способности сетевого соединения. К примеру, даже если устрой­
ство способно воспроизводить видео высокого разрешения, нет смысла предо­
ставлять такой видео поток при низкой пропускной способности сети, поскольку
это может привести к появлению джиттера (jitter).
После преобразования метаданных сервис добавляет новое задание в оче­
редь планировщика: add_task( data ). Планировщик (Scheduler) выполняет на­
значение заданий на узлы-обработчики (Cluster node): assign_task(task_data).
Узел-обработчик выполняет декодирование видео данных, а на клиентское устрой­
ство передаётся URL, по которому можно получить доступ к выходному видео
потоку.
Далее рассмотрим подробнее процесс назначения вычислительных ресур­
сов на поступившие задачи обработки данных.
4.2.4. Оценка вычислительных затрат
Анализ литературы в главе 1 показал, что наиболее распространённый ме­
тод распределения заданий по узлам-обработчикам заключается в использо­
вании приоритетной очереди FIFO (First In First Out) и выделения наименее
нагруженного узла под новые задания LLF (Least Loaded First).
Данный метод (FIFO_LLF) будет использован в качестве основы для срав­
нения, поскольку так же как и метод планирования на основе метаданных (ме­
тод Meta_Sched) он не требует априорных знаний о ресурсных требованиях.
Кроме того, данный метод используется для накопления предыстории экспери­
ментов для метода Meta_Sched.
Метод Meta_Sched требует построения модели, позволяющей прогнозиро­
вать оценку вычислительных затрат для новых заданий, на основе собранной
статистики запуска.
96
В результате выполнения заданий, помимо получения результатов декоди­
рования, производится сбор метрик загрузки вычислительных ресурсов и их
сохранение в базу данных. На Рисунке 4.7 приведён пример метрик (metrics),
полученных в результате выполнения задания. Каждая запись также хранит
метаданные задачи и свойства узла-обработчика.
Рисунок 4.7. Пример метрик
Используемые метрики и свойства узлов-обработчиков:
1. avg_cpu_load_percent - средняя загрузка процессоров узла-обработчика
во время выполнения операции декодирования;
2. ram_load_kb - объём потребляемой памяти (Kb) процессом, выполняю­
щим декодирование;
97
3. submit_timestamp - временной штамп поступления задания в систему;
4. start_processing_timestamp - временной штамп начала декодирования;
5. elapsed_seconds - время, затраченное на обработку данных (декодирова­
ние);
6. node_free_ram - объём доступной оперативной памяти (Mb);
7. node_free_processors - количество незагруженных процессоров.
Данные метрики позволяют оценить временные и ресурсные затраты на
обработку данных, а также временные затраты на планирование заданий, такие
как время ожидания и время обработки.
Для каждой записи вычисляется нормализованная величина затрат по фор­
муле:
𝑐𝑜𝑠𝑡 = 𝑤1 * 𝑐𝑝𝑢_𝑐𝑜𝑠𝑡(𝑎𝑣𝑔_𝑟𝑎𝑚_𝑙𝑜𝑎𝑑_𝑘𝑏, 𝑛𝑜𝑑𝑒_𝑓 𝑟𝑒𝑒_𝑟𝑎𝑚)
(4.3)
+𝑤2 * 𝑟𝑎𝑚_𝑐𝑜𝑠𝑡(𝑎𝑣𝑔_𝑐𝑝𝑢_𝑙𝑜𝑎𝑑, 𝑛𝑜𝑑𝑒_𝑓 𝑟𝑒𝑒_𝑝𝑟𝑜𝑐𝑒𝑠𝑠𝑜𝑟𝑠)
где:
𝑐𝑝𝑢_𝑐𝑜𝑠𝑡 - функция оценки процессорных затрат,
𝑟𝑎𝑚_𝑐𝑜𝑠𝑡 - функция оценки затрат памяти,
𝑤𝑖 - весовые коэффициенты значимости вычислительного ресурса.
В формуле 4.3 весовые коэффициенты подбираются таким образом, чтобы
отдать приоритет наиболее востребованным ресурсам в зависимости от класса
задачи:
1. Процессору - для вычислительно ёмких задач;
2. Памяти - для задач, требовательных к памяти;
3. Подсистеме ввода-вывода;
4. Графической подсистеме;
5. Сети.
Решаемая задача декодирования видео относится к вычислительно ёмким,
то есть требовательна к процессору 𝑤1 = 1, в то время как потребление памяти
остаётся незначительным 𝑤2 = 0.3.
98
Функции 𝑐𝑝𝑢_𝑐𝑜𝑠𝑡 и 𝑟𝑎𝑚_𝑐𝑜𝑠𝑡 оценивают затраты для отдельных ресур­
сов, при этом учитывается является ли ресурс не до конца загруженным или
перегруженным.
Оценка ресурсных затрат для новых пар задач и вычислительных узлов
(𝑡, 𝑘) осуществляется следующим образом. Наличие метаданных позволяет най­
ти в предыстории 𝐺ℎ𝑖𝑠𝑡 близкие пары 𝐺ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡 и оценить ресурсные затраты.
Для этого используется алгоритм поиска предложенный в разделе 3.3.
При этом выбор корзины в хэш таблице основан на значениях значимых ка­
тегориальных аттрибутов. Для задачи декодирования видео данных значимыми
являются атрибуты ffmpeg preset, h264 profile, h264 level, которые определяют
качество выходного видео потока.
При вычислении расстояния до всех объектов-кандидатов из полученной
корзины по-атрибутные расстояния взвешиваются исходя из значимости каж­
дого численного атрибута.
В результате оценки ресурсных затрат для всех заданий и узлов обработ­
чиков строится матрица ресурсных затрат. Полученная матрица ресурсных за­
трат позволяет решить задачу о назначениях и получить матрицу назначения,
в соответствии с которой задачи обработки данных будут разосланы по узлам­
обработчикам.
4.2.5. Обработка результатов эксперимента
Для сравнения методов планирования задач распределённая система обра­
ботки данных тестируется в различных условиях. Сценарии, на которых прове­
ряется производительность методов планирования отличаются распределением
трудоёмкости входного потока заданий и степенью нагрузки на систему.
Построенная распределённая система обработки данных выполняет плани­
рование и обработку задач декодирования видео в течение 10 минут для каж­
дого сценария. Затем, по результатам собранной статистики качество работы
методов планирования FIFO_LLF и Meta_Sched оценивается по следующим
99
показателям:
1. Коэффициент использования процессорных ресурсов вычислительного уз­
ла.
2. Среднее время (сек.) ожидания обработки задания.
3. Среднее время (сек.) нахождения задания в системе (время ожидания +
время обработки).
4. Средняя задержка (сек.) обработки задания (время ожидания / время
обработки).
5. Изменение суммарного времени выполнения задач для каждого сценария.
6. Изменение среднего времени ожидания обработки задания для каждого
сценария.
При этом, коэффициент использования процессорных ресурсов вычисли­
тельного узла вычисляется по формуле:
𝑈=
𝑢
,
100 · 𝑝
где:
𝑢 - процент процессорного времени, которое многопоточное задание получило,
𝑝 - количество доступных процессоров.
Экспериментально полученные распределения коэффициента использова­
ния процессорных ресурсов для различных тестовых сценариев приведены на
Рисунках 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17, 4.18, 4.19, где по оси
абсцисс отсчитывается величина коэффициента использования процессоров, а
по оси ординат отсчитывается количество экспериментов, попавших в каждый
из диапазонов.
Для того, чтобы понять как интерпретировать полученные результаты
необходимо выделить основные критерии, характеризующие пригодность ана­
лизируемого метода планирования для его применения на практике. Основные
критерии следующие:
1. Сравнение временных характеристик обработки задач, полученных при
100
использовании указанных методов планирования: среднее время нахож­
дения заявки в системе, средняя задержка и среднее время обработки
заявки.
2. Сравнение эффективности использования ресурсов. С точки зрения пла­
нирования, оптимальной считается загрузка ресурса в диапазоне [0.8, 1],
в то время как значения из диапазона [0, 0.8) показывают что ресурс ис­
пользован не до конца, а значения > 1 говорят о перегрузке (нехватке)
ресурса.
Рассмотрим последовательно каждый из них.
Рисунок 4.8. Распределение коэффициента использования процессорных ресурсов для сцена­
рия: (постоянное распределение трудоёмкости, лёгкая нагрузка)
101
Рисунок 4.9. Распределение коэффициента использования процессорных ресурсов для сцена­
рия: (постоянное распределение трудоёмкости, средняя нагрузка)
Рисунок 4.10. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (постоянное распределение трудоёмкости, высокая нагрузка)
102
Рисунок 4.11. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (равномерное дискретное распределение трудоёмкости, лёгкая нагрузка)
Рисунок 4.12. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (равномерное дискретное распределение трудоёмкости, средняя нагрузка)
103
Рисунок 4.13. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (равномерное дискретное распределение трудоёмкости, высокая нагрузка)
Рисунок 4.14. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (взвешенное дискретное распределение трудоёмкости, лёгкая нагрузка)
104
Рисунок 4.15. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (взвешенное дискретное распределение трудоёмкости, средняя нагрузка)
Рисунок 4.16. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (взвешенное дискретное распределение трудоёмкости, высокая нагрузка)
105
Рисунок 4.17. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (случайное распределение трудоёмкости, лёгкая нагрузка)
Рисунок 4.18. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (случайное распределение трудоёмкости, средняя нагрузка)
106
Рисунок 4.19. Распределение коэффициента использования процессорных ресурсов для сце­
нария: (случайное распределение трудоёмкости, высокая нагрузка)
Рисунок 4.20. Относительная эффективность планирования метода Meta_Sched по сравне­
нию с методом FIFO_LLF
107
Рисунок 4.21. Изменение временных затрат выполнения задач для метода Meta_Sched по
сравнению с методом FIFO_LLF
Рисунок 4.22. Изменение среднего времени ожидания в очереди для метода Meta_Sched по
сравнению с методом FIFO_LLF
108
Таблица 4.4. Результаты экспериментов по планированию заданий
109
Описательная статистика результатов экспериментов приведена в сводной
Таблице 4.4. Как видно из полученных результатов, временные характеристики,
- среднее время нахождения заявки в системе, средняя задержка и среднее
время ожидания обработки заявки, - являются величинами одного порядка для
обоих методов планирования.
Проанализируем эффективность использования вычислительных ресурсов
для каждого экспериментального сценария.
На гистограммах 4.8, 4.9, 4.10 приведена характеристика эффективности
загрузки процессорных ресурсов для постоянного распределения трудоёмкости,
которое характеризуется тем, что на вход системы подаются задания средней
трудоёмкости.
Как можно видеть из Рисунка 4.8, при слабой загрузке, метод FIFO_LLF
имеет больше точек в диапазоне [0, 0.8), который говорит о недоиспользовании
ресурсов, а также отличается наличием заданий, для которых было выделено
недостаточно ресурсов (processor utilization > 2). В диапазоне [0.8, 1] оба метода
показали схожие результаты.
При средней загрузке (Рисунок 4.9) метод FIFO_LLF немного превосходит
метод Meta_Sched, поскольку последний ошибочно назначил часть заданий та­
ким образом, что ресурсы оказались перегружены. Кроме того, в оптимальном
диапазоне [0.8, 1] метод Meta_Sched немного уступает (70 против 90) методу
FIFO_LLF по количеству точек.
При высокой загрузке (Рисунок 4.10) видно значительное преимущество ме­
тода планирования на основе метаданных и ресурсных метрик (Meta_Sched),
поскольку множество точек, попавших в диапазон [2, 6] было перенесено в диа­
пазон [0, 2]. Иными словами была снижена перегрузка системы.
На гистограммах 4.11, 4.12, 4.13 приведена характеристика эффективности
загрузки процессоров для равномерного дискретного распределения трудоёмко­
сти, которое характеризуется тем, что на вход системы равновероятно подаются
задания легкой, средней и высокой трудоёмкости.
110
На Рисунке 4.11 видно, что метод планирования Meta_Sched, при слабой
загрузке, имеет больше точек в оптимальном диапазоне [0.8, 1] и также меньше
точек с недоиспользованными ресурсами. Однако метод Meta_Sched немного
уступает методу FIFO_LLF, поскольку часть заданий получило недостаточно
вычислительных ресурсов: точки попали в диапазон [1, 1.6].
При средней загрузке (Рисунок 4.12) метод планирования Meta_Sched по­
казывает лучшие результаты на диапазоне [0, 0.8) (недоиспользованные ресур­
сы) и сравнимые результаты в диапазоне [0.8, 1] (оптимальная загрузка), однако
проигрывает в диапазоне [1, 4], поскольку имеет больше заданий, для которых
вычислительных ресурсов оказалось недостаточно. Впрочем в диапазоне [4, 5]
оба метода ведут себя одинаково неэффективно.
При высокой загрузке (Рисунок 4.13) метод планирования Meta_Sched поз­
воляет сократить количество случаев перегрузки ресурсов.
Также в работе приведены графики для взвешенного дискретного и случай­
ного распределения трудоёмкости заданий. Взвешенное дискретное распределе­
ние является приближением гауссова распределения, при котором 72% заданий
имеют среднюю трудоемкость, а задания с высокой и низкой трудоёмкостью
получают по 14% соответственно. Случайное (псевдослучайное) распределение
трудоёмкости определяется программным генератором случайных чисел.
Аналогично анализируя гистограммы для взвешенного дискретного и слу­
чайного распределения трудоёмкости можно сделать вывод о том, что при сред­
ней и слабой загрузке оба метода планирования (FIFO_LLF и Meta_Sched)
сравнимы по эффективности, в то время как при высокой загрузке метод пла­
нирования на основе метаданных и ресурсных метрик (Meta_Sched) позволяет
более эффективно использовать вычислительные ресурсы.
Для того чтобы сравнить два метода планирования в целом, целесообраз­
но также вычислить процент задач для которых вычислительных ресурсов ока­
залось достаточно в каждом тестовом сценарии. Данная величина отражает
эффективность работы планировщика.
111
Если принять за 𝑛 количество задач, для которых 𝑈 ≤ 1, а за 𝑛𝑎𝑙𝑙 – число
всех задач, обработанных для данного сценария, то эффективность планирова­
ния вычисляется по следующей формуле:
𝐸=
𝑛
,
𝑛𝑎𝑙𝑙
Далее относительная эффективности планирования метода Meta_Sched по
сравнению с методом FIFO_LLF вычисляется как:
𝑑𝐸 = 𝐸𝑚𝑒𝑡𝑎_𝑠𝑐ℎ𝑒𝑑 − 𝐸𝑓 𝑖𝑓 𝑜_𝑙𝑙𝑓 ,
где:
𝐸𝑚𝑒𝑡𝑎_𝑠𝑐ℎ𝑒𝑑 - эффективность метода планирования Meta_Sched,
𝐸𝑓 𝑖𝑓 𝑜_𝑙𝑙𝑓 - эффективность метода планирования FIFO_LLF.
Значение величины относительной эффективности планирования для всех
экспериментальных сценариев приведено на Рисунке 4.20. Как показывает рас­
пределение, метод планирования на основе метаданных проигрывает методу
FIFO_LLF при слабой и средней загрузке, но показывает свою эффективность
при высокой интенсивности поступления заявок (86/мин.).
Такой результат объясняется тем, что при слабой интенсивности поступле­
ния заявок значительная часть вычислительных ресурсов простаивает. Метод
планирования FIFO_LLF отдаёт предпочтение наименее загруженным вычис­
лительным узлам, в результате чего ресурсные требования задач оказываются
удовлетворёнными.
Планирование на основе метаданных и ресурсных метрик опирается на ис­
торию выполнения задач обработки данных. Как показывают результаты на
Рисунке 4.20 в условиях высокой интенсивности поступления заявок такой под­
ход позволяет повысить эффективность планирования за счёт более точного
установления соответствия задач вычислительным узлам на основе собранной
ранее статистики.
Проанализируем также временные затраты на выполнение задач. Для это­
го посчитаем суммарное время нахождения всех заявок в системе отдельно для
112
каждого сценария выполнения, а затем посчитаем на сколько процентов оно
изменилось при использовании метода планирования на основе метаданных по
сравнению с методом планирования FIFO_LLF. Как показывают результаты на
Рисунке 4.21 суммарное время нахождения заявок в системе (время ожидания
+ время выполнения) сокращается при высокой интенсивности поступления за­
явок в среднем на 20%, что говорит также о необходимости сбора определённого
объёма предыстории для получения выигрыша от применения метода.
При проведении эксперимента для лёгкой интенсивности поступления за­
дач в среднем было собрано 60 задач предыстории, для средней интенсивности
– 160 задач, для высокой интенсивности – 400 задач. При этом для метода пла­
нирования на основе метаданных, среднее время нахождения заявок в системе
изменилось на 10.7% (увеличилось), на 4.5% (увеличилось) и на −20.3% (умень­
шилось) соответственно по сравнению с методом планирования FIFO_LLF.
Проанализируем также изменение среднего времени ожидания обработки
заявок метода Meta_Sched по сравнению с методом FIFO_LLF для каждого
сценария. Как видно на Рисунке 4.22, при слабой интенсивности загрузки на­
кладные расходы планирования на основе метаданных в среднем на 70.6% выше
чем для метода FIFO_LLF. Для средней загрузки накладные расходы выше на
10.55%, а для высокой загрузки накладные расходы уменьшаются на 7.58%.
Это позволяет сделать вывод о непригодности предложенного метода пла­
нирования в условиях слабой и средней интенсивности поступления заявок,
значения которых в настоящем исследовании составили 6 и 19 задач в минуту
соответственно.
С другой стороны, в режиме высокой интенсивности загрузки – 86 задач в
минуту, – предложенный метод планирования на основе метаданных позволяет
сократить суммарное время нахождения заявок в системе в среднем на 20%, а
среднее время ожидания обработки заявок на 11%.
113
4.3. Задача обработки гидрографических данных
Для эскпериментальной проверки метода предложенного в разделе 3.1, рас­
сматриваются задачи обработки гидрографических данных.
В разделе 4.3.1 даётся высокоуровневое описание задачи, а в разделе 4.3.2
рассмотрены метаданные и метрики загрузки ресурсов, которые использова­
лись в процессе планирования, а также проводится анализ временных характе­
ристик выполнения задач.
4.3.1. Задача построения карт высот
В данном разделе рассмотрено применение предложенного метода к за­
дачам обработки гидрографических данных. Практическая работа была про­
ведена в рамках НИР «Организация производства систем гидроакустического
мониторинга акватории на базе покровных антенн в местах размещения нефтеи газодобывающих платформ в районе Арктического шельфа».
Для наглядного отображения относительного положения надводных кораб­
лей, подводных лодок, буёв, нефтяных платформ и прочих морских объектов
широко применяется трёхмерное представление данных. В связи с тем, что для
передачи гидрографических данных между производителями морских карт, на­
вигационных систем, гидрографическими агентствами и службами широко ис­
пользуются векторные электронные карты стандарта S-57 (Рисунок 4.23), ак­
туальной является задача использования существующих баз файлов в качестве
основы для генерации трёхмерных карт.
Согласно стандарту, координаты суши и водной поверхности хранятся в
виде набора слоев: отдельные слои представляют контуры глубин, контуры вы­
сот, береговые линии, искусственные сооружения и прочие объекты. К примеру,
отмеченные на Рисунке 4.23 уровни имеют следующий смысл:
1. LANDARE - границы суши,
2. DEPCNT - контуры глубины,
114
3. RIVERS - реки.
Особенностью существующих файлов карт S-57 является недостаточность
информации о глубинах, в связи с чем входная матрица точек получается раз­
реженной.
Рисунок 4.23. Двумерное отображение карты s57
В статье [62] излагается предложенный метод построения трёхмерных карт
на основе разреженных матриц глубин. Также отмечается вычислительная тру­
доемкость вычисления трёхмерной сетки для разрешений 106 точек и выше.
Дополнительно ускорить процесс построения карт высот позволяет парал­
лельная обработка данных в несколько потоков, т.к. области карты могут стро­
иться независимо друг от друга. Значение глубины (высоты) каждой из точек
на карте высот зависит только от входных данных.
Поскольку в данной диссертационной работе рассматриваются методы па­
раллельной обработки независимых задач, для построения трёхмерной карты
региона Земли имеет смысл разделить его на части, что будет соответствовать
задачам обработки в принятой в настоящей работе терминологии. Поскольку
существующие карты имеют различные характеристики (количество исходных
точек глубин, размер файла), трудоёмкость каждой из задач будет различной.
115
Кроме того трудоёмкость может отличаться если ставиться задача обсчёта реги­
она для различных выходных разрешений. Такая задача имеет смысл на практи­
ке для осуществления предварительного просмотра в интерфейсе пользователя.
Наличие различных по трудоёмкости задач обосновывает актуальность
применения предложенного в данной работе метода.
4.3.2. Планирование задач обработки гидрографических данных
Для получения равномерной сетки точек, на основе которых выполняется
построение трёхмерной поверхности, выполняется интерполяция разреженной,
неравномерно распределённой сетки точек из входной навигационной карты
стандарта S-57. Реализация алгоритма на C++, решающего данную задачу, поз­
воляет независимо обрабатывать участки на параллельно запущенных потоках.
При этом программный код написан таким образом, что данные разделяются
на равные части между доступными аппаратными потоками. Задача является
ресурсоёмкой, требуя значительных временных затрат, - до 4 часов на одну кар­
ту, при расчёте в 4 параллельных потока, - при выполнении интерполяции для
получения карт с высоким разрешением (106 ) точек.
В качестве источника входных данных рассматривается архив навигацион­
ных карт NOAA Electronic Navigational Charts (NOAA ENC) 5 . В архиве хра­
нятся 670 карт S-57 (по состоянию на 2008 год): покрыты основные морские
порты США. Общий объём архива – 1,6 Гб.
Пусть каждая независимая задача обработки данных характеризуется сле­
дующим множеством атрибутов 𝐴:
1. Размер файла (в Кб);
2. Имя файла карты;
3. Количество опорных точек интерполяции;
4. Разрешение выходной карты высот.
5
NOAA Electronic Navigational Charts: http://www.nauticalcharts.noaa.gov/mcd/enc/.
116
Задачи, которые поступают на вход системы планирования, имеют различ­
ные выходные разрешения из диапазона [104 , 105 ] точек. Пусть пакет задач 𝑇 ,
для которого необходимо выполнить назначение на ресурсы обработки, состоит
из 𝑛 = 8 задач, в каждой из которых выбрано разрешение случайным образом
из заданного диапазона.
Обучающая выборка 𝐺ℎ𝑖𝑠𝑡 также состоит из 8 задач, но разрешение зада­
ётся с равномерным шагом
105 −104
𝑛
в том же диапазоне [104 , 105 ].
Непосредственно данные загружены на RAID массив типа 5 и соответству­
ющий раздел примонтирован к каждому узлу обработчику, с целью исключения
накладных расходов на передачу данных по сети.
В качестве узлов обработки 𝐾 выделим 8 машин, каждая из которых харак­
теризуется количеством аппаратно поддерживаемых потоков (threads) и объё­
мом оперативной памяти (ram). Поскольку рассматриваемая задача является
вычислительно сложной (но не требовательной по потреблению памяти), прак­
тический смысл имеет лишь количество потоков, а объём памяти может быть
произвольным. Таким образом, имеется 8 узлов, для которых количество пото­
ков равняется соответственно {1, 1, 2, 2, 4, 4, 4, 6} и на каждый узел выделяется
по 1024 Мб оперативной памяти, из которых для прикладных приложений будет
доступно меньше количество памяти.
В качестве планировщика, реализующего предложенный метод выступа­
ет программа на языке Python, запущенная на отдельном узле. Для передачи
команд и прочей информации между узлом-планировщиком и узлами-обработ­
чиками, используется промежуточное программное обеспечение Pyro46 . Pyro4
предоставляет сервис наименования для удалённого доступа к распределённым
объектам и возможность вызова удалённых процедур на кажом из узлов.
Рассмотрим величины, на основе которых можно будет оценивать эффек­
тивность различных методов планирования задач и ресурсов.
Выделим метрики загрузки ресурсов 𝑀 , которые будут использоваться для
6
distributed object middleware for Python (RPC): https://pypi.python.org/pypi/Pyro4.
117
построения модели:
1. Средняя загрузка процессора;
2. Средний объём потребляемой процессом памяти;
3. Затраченное время.
Каждая из указанных метрик рассчитывается отдельно для каждой кон­
кретной задачи 𝑡. Значения данных метрик можно получить с помощью ути­
литы time (версия GNU 1.7), доступной для операционных систем семейства
Unix7 .
Для построения модели необходимо запустить каждую из задач обучаю­
щей выборки на всех 𝑛 = 8 доступных узлах. В результате запуска получена
статистика, которая частично приведена в таблице 4.5.
Таблица 4.5. Метрики загрузки ресурсов
Далее необходимо определить, относительно какой из метрик 𝑚 ∈ 𝑀 вы­
полнять оценку ресурсных затрат 𝑐.
Поскольку средняя загрузка процессора близка к 100%, в данном случае её
величина лишь зависит от количества выделенных на данный узел процессоров:
в подтверждение этого значение коэффициента корреляции Пирсона между ко­
личеством процессоров и средней загрузкой процессора равняется 0.97.
7
unix time utility v.GNU 1.7: http://man7.org/linux/man-pages/man1/time.1.html.
118
Значение величины потребления памяти для процесса, исполняющего об­
работку данных на удалённом узле находится в интервале [30, 40] Мб, то есть
практически не меняется от задачи к задаче.
Для получения нормализованной стоимости в данном эксперименте предла­
гается использовать оставшуюся метрику - затраченное время, которая являет­
ся универсальной для всех типов задач. Посчитав нормализованную стоимость
по формуле 2.10 получим модель, которая будет сохранена в формате JSON8 и
для наглядности частично приведена в таблице 4.6.
Таблица 4.6. Модель для оценки стоимости
Имея сохранённую модель можно перейти к оценке стоимости для вновь по­
ступивших задач: имея пакет из 𝑛 = 8 поступивших задач необходимо оценить
стоимость выполнения каждой из них на каждом из 𝑛 доступных узлов-обра­
ботчиков для получения матрицы стоимости (см. 3.4).
Для этого первым делом необходимо определить на основе каких атрибутов
будет производиться сравнение задач. Иными словами: для выбранной задачи
из тестовой выборки находятся наиболее близкие из обучающей выборки в соот­
ветствии с заданной метрикой расстояния (в данном случае - евклидово рассто­
яние) и используются их оценки стоимости. Напомним, что задачи обучающей
8
JavaScript Object Notation: http://www.json.org/.
119
выборки и связанные с ними оценки сохранены в качестве модели, полученной
заранее.
Для выбора атрибутов найдём коэффициенты корреляции между зависи­
мыми переменными {𝑡ℎ𝑟𝑒𝑎𝑑𝑠, 𝑟𝑎𝑚, 𝑜𝑢𝑡𝑝𝑢𝑡_𝑟𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛} и независимыми целевы­
ми переменными {𝑒𝑙𝑎𝑝𝑠𝑒𝑑_𝑡𝑖𝑚𝑒, 𝑎𝑣𝑔_𝑐𝑝𝑢_𝑙𝑜𝑎𝑑_𝑝𝑒𝑟𝑐𝑒𝑛𝑡, 𝑟𝑎𝑚_𝑙𝑜𝑎𝑑_𝑘𝑏}: Таб­
лица 4.7.
Таблица 4.7. Корреляция между характеристиками задач и узлов и метриками
Поскольку для оценки стоимости использовалась только метрика, отража­
ющая затраченное время (𝑒𝑙𝑎𝑝𝑠𝑒𝑑_𝑠𝑒𝑐𝑜𝑛𝑑𝑠), в приведенной таблице ценность
представляют лишь строки с этой независимой переменной. Как можно видеть
повышение количества потоков обработки (𝑡ℎ𝑟𝑒𝑎𝑑𝑠) сопровождается понижени­
ем времени обработки (коэффициент корреляции -0.58), а увеличение разреше­
ния (𝑜𝑢𝑡𝑝𝑢𝑡_𝑟𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛) выходной карты высот сопровождается повышением
времени обработки (коэффициент корреляции 0.68). Хотя значения коэффици­
ентов корреляции не могут служить для установления причинно-следственной
связи между явлениями, наличие высокой положительной или отрицательной
корреляции является необходимым (но недостаточным) условием такой связи.
Таким образом, для сравнения задач выбраны следующие атрибуты:
1. количество процессоров узла (𝑡ℎ𝑟𝑒𝑎𝑑𝑠)
2. разрешение выходных карт высот (𝑜𝑢𝑡𝑝𝑢𝑡_𝑟𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛).
120
После того как выбраны атрибуты, необходимо определить способ поиска
ближайших пар (𝑡ℎ𝑖𝑠𝑡 , 𝑘ℎ𝑖𝑠𝑡 ) из предыстории выполнения 𝐺ℎ𝑖𝑠𝑡 к новой паре (𝑡, 𝑘).
Для эффективного поиска предлагается использовать структуру данных kd-tree
[63], которая позволяет осуществлять поиск ближайших соседей в среднем за
𝑂(𝑙𝑜𝑔(𝑛)) время. При этом, для вычисления расстояния 𝐷(𝑡𝑎 , 𝑡𝑏 ) между двумя
точками структура данных kd-tree использует евклидово расстояние.
После того как для каждой задачи 𝑡 найдены ближайшие соседи 𝐺ℎ𝑖𝑠𝑡.𝑛𝑒𝑎𝑟𝑒𝑠𝑡
(в данной реализации ищутся 3 ближайших соседа), ресурсные затраты выпол­
нения задачи на заданном узле 𝑐 находится как среднее значение ресурсных
затрат ближайших пара (задача, вычислительный узел).
Повторив данную процедуру для всех новых задач получена матрица сто­
имости 𝐶, которая используется для решения задачи о назначениях одним из
существующих алгоритмов комбинаторной оптимизации. В данной реализации
используется алгоритм Джеймса Манкреса [52] решения задачи о назначениях.
В результате работы алгоритма строится матрица назначения 𝑊 , на основе
которой выполняется непосредственно сам запуск задач на выполнение на узлах
обработчиках.
Для сравнения по производительности был проведён ряд экспериментов
как при использовании предлагаемого метода планирования, который учиты­
вает зависимость между атрибутами прикладных задач и загрузкой ресурсов,
так и при использовании метода без учёта такой зависимости. Иными словами
альтернативный метод в плане учёта атрибутов прикладных задач выполняет
случайное назначение ресурсов на задачи обработки.
Результаты проведения экспериментов можно видеть на Рисунке 4.24.
По оси 𝑥 отображается номер эксперимента, а по оси 𝑦 время выполне­
ния для обоих методов планирования в минутах: зеленым цветом обозначено
затраченное время при использовании предложенного метода планирования,
красным - при использовании метода без учета атрибутов задач. Кроме того
на графике для каждого отдельного эксперимента приведён полученный при­
121
Рисунок 4.24. Сравнение производительности методов
рост производительности при использовании предлагаемого метода. Как можно
видеть, в среднем для каждого пакета задач предложенный метод позволяет
выиграть 8 − 10% времени, что в среднем составляет 15 минут.
122
4.4. Выводы
1. Предложена программная архитектура системы планирования за­
дач в РСОД, реализующая предложенный метод планирования на основе
метаданных и ресурсных метрик.
2. На основе предложенной программной архитектуры реализована про­
граммная система планирования в РСОД для задач декодирования ви­
део данных и задач обработки гидрографических данных.
3. Проведён цикл экспериментов по планированию заданий декодиро­
вания видео данных при различных условиях распределения трудоёмко­
сти заданий и интенсивности вычислительной нагрузки с использованием
предлагаемого метода планирования и метода FIFO/Least Loaded First
(FIFO_LLF).
Анализ результатов эксперимента показывает следующее:
. Суммарное время нахождения заявок в системе при использовании
метода планирования на основе метаданных сокращается на 20% по
сравнению с методом FIFO_LLF при высокой интенсивности поступ­
ления задач в систему, но возрастает на 4.5% при средней интенсив­
ности и на 10.7% при слабой интенсивности.
. Среднее время ожидания обработки заявок при использовании ме­
тода планирования на основе метаданных сокращается на 7.58% по
сравнению с методом FIFO_LLF при высокой интенсивности поступ­
ления задач в систему, но возрастает на 10.55% при средней интен­
сивности и на 70.6% при слабой интенсивности.
Такие результаты объясняются следующими причинами:
. Увеличение интенсивности поступления заявок также увеличивает
объём данных предыстории, что оказывает влияние на качество про­
гнозирования.
. При невысокой интенсивности поступления заявок значительная часть
123
вычислительных ресурсов простаивает. Метод планирования FIFO_LLF
отдаёт предпочтение наименее загруженным вычислительным узлам,
в результате чего ресурсные требования задач оказываются удовле­
творёнными.
4. Метод планирования на основе метаданных был применён к задаче обра­
ботки гидрографических данных и позволил сократить время выполнения
задач в среднем на 10%.
124
Заключение
В процессе проведенных в диссертационной работе исследований получены
следующие основные результаты:
1. Проведён анализ систем управления ресурсами Slurm, Torque, Moab, Maui
HTCondor, DIET и распространённых в литературе методов планирова­
ния задач в распределённых системах обработки данных (РСОД), кото­
рый показал актуальность разработки новых методов планирования в
условиях неполноты информации о ресурсных требованиях.
2. Выявлены характеристики данных (метаданные) и метрики использова­
ния ресурсов, корреляция между которыми позволяет строить прогно­
стические модели машинного обучения на основе прецедентов для оцен­
ки ресурсных требований новых заданий используя историю выполнения
предыдущих заданий.
3. Предложена математическая модель планирования задач в РСОД, в струк­
туре которой явно выделены атрибуты данных (метаданные) и метрики
загрузки ресурсов.
4. Основываясь на предложенной модели, предложен метод планирования
задач в РСОД, который базируется на учёте корреляции между метадан­
ными и метриками загрузки ресурсов и не требует априорных знаний о
ресурсных требованиях поскольку основан на предыстории обработки за­
дач.
5. Для сокращения размерности процесса поиска ближайших задач предло­
жена модификация алгоритма поиска ближайших соседей на основе ло­
кализованного хэширования, с учётом типов атрибутов и их значимости
для ресурсопотребления.
6. Для использования предложенного метода в системах управления ресур­
сами РСОД на практике предложена методика планирования задач.
7. Предложена программная архитектура системы планирования задач в
125
РСОД, на основе которой реализована программная система планирова­
ния для задач декодирования видео данных и задач обработки гидрогра­
фических данных.
8. Проведён цикл экспериментов по планированию задач декодирования ви­
део, который показал в среднем 20% сокращение временных затрат вы­
полнения задач при высокой интенсивности поступления заявок.
9. Сочетание предложенного метода с известными, например FIFO_LLF,
позволяет обеспечить сокращение временных затрат при различных ин­
тенсивностях поступления заявок.
10. Метод планирования на основе метаданных был апробирован на задаче
обработки гидрографических данных и позволил сократить время выпол­
нения задач в среднем на 10%.
11. По результатам выполненной работы опубликованы 11 печатных работ
[62, 64–73] и зарегистрированы 9 программных свидетельств [74–82].
Основные положения и результаты диссертационной работы докладыва­
лись и обсуждались на 5 международных научно-технических конферен­
циях:
∙ XIII-XVI Международные конференции по мягким вычислениям и
измерениям (SCM’2010-2013), Санкт-Петербург.
∙ 9th International Conference on Computer Science and Information Technologies (CSIT 2013), Yerevan, Armenia.
12. Дальнейшее развитие работы может быть направлено на расширение пред­
ложенных решений применительно к заданиям, представленным в виде
графов задач с зависимостями.
126
Литература
1. Tanenbaum A. S., Steen M. v. Distributed Systems: Principles and Paradigms
(2nd Edition). Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 2006. IS­
BN: 0132392275.
2. Prahbu C. Grid and Cluster Computing. PHI Learning Private Limited, 2013.
P. 253.
3. Воеводин В.В., Воеводин Вл.В. Паралельные вычисления. СПб: БХВ-Петер­
бург, 2002. С. 608.
4. The NIST Definition of Cloud Computing. No. Special Publication 800-145.
National Institute of Standards and Technology, 2011. P. 7.
5. Casal D. Cloud Computing for Programmers. Amazon Digital Services, Inc.,
2013. P. 59.
6. Broberg J. A. Effective task assignment strategies for distributed systems un­
der highly variable workloads: Ph. D. thesis / School of Computer Science and
Information Technology, Science, Engineering, and Technology Portfolio, RMIT
University, Melbourne, Victoria, Australia. 2006.
7. Barbosa J. M. G., Moreira B. D. R. Dynamic Job Scheduling on Heterogeneous
Clusters // Proceedings of the 2009 Eighth International Symposium on Parallel
and Distributed Computing. ISPDC ’09. Washington, DC, USA: IEEE Comput­
er Society, 2009. P. 3–10. URL: http://dx.doi.org/10.1109/ISPDC.2009.19.
8. Endo P., Palhares A. D. A., Pereira N. et al. Resource allocation for distributed
cloud: concepts and research challenges // Ieee Network. 2011. Vol. 25, no. 4.
P. 42–46.
9. Chtepen M., Claeys F., Dhoedt B. etal. Performance evaluation and optimiza­
tion of an adaptive scheduling approach for dependent grid jobs with unknown
execution time // 18th World IMACS Congress and MODSIM09 International
Congress on Modelling and Simulation, Proceedings / edited byR. Anderssen,
R. Braddock, L. Newham. Modelling and Simulation Society of Australia and
127
New Zealand ; International Association for Mathematics and Computers in Sim­
ulation, 2009. P. 1003–1009. URL: http://www.mssanz.org.au/modsim09/
C5/chtepen.pdf.
10. Bovet D., Cesati M. Understanding The Linux Kernel. Oreilly & Associates Inc,
2005. ISBN: 0596005652.
11. Imam M. T., Miskhat S. F., Rahman R. M., Amin M. A. Neural Network and
Regression Based Processor Load Prediction for Efficient Scaling of Grid and
Cloud Resources // 14th International Conference on Computer and Informa­
tion Technology (ICCIT). IEEE, 2011.
12. Kwok Y.-K., Ahmad I. Static scheduling algorithms for allocating directed
task graphs to multiprocessors // ACM Comput. Surv. 1999. Vol. 31, no. 4.
P. 406–471. URL: http://doi.acm.org/10.1145/344588.344618.
13. Kim J.-K., Shivle S., Siegel H. J. et al. Dynamically mapping tasks with priorities
and multiple deadlines in a heterogeneous environment // J. Parallel Distrib.
Comput. 2007. Vol. 67, no. 2. P. 154–169. URL: http://dx.doi.org/10.
1016/j.jpdc.2006.06.005.
14. Sun W., Zhang Y., Inoguchi Y. Dynamic Task Flow Scheduling for Heteroge­
neous Distributed Computing: Algorithm and Strategy // IEICE - Trans. Inf.
Syst. 2007. Vol. E90-D, no. 4. P. 736–744. URL: http://dx.doi.org/10.
1093/ietisy/e90-d.4.736.
15. Maheswaran M., Ali S., Siegel H. J. et al. Dynamic mapping of a class of in­
dependent tasks onto heterogeneous computing systems // J. Parallel Distrib.
Comput. 1999. Vol. 59, no. 2. P. 107–131. URL: http://dx.doi.org/10.
1006/jpdc.1999.1581.
16. Caniou Y., Jeannot E. Experimental Study of Multi-criteria Scheduling Heuris­
tics for GridRPC Systems // Euro-Par. 2004. P. 1048–1055.
17. Xue S., Chen L., Liu G. Resource state prediction in the grid based on neural
network // Proceedings of the 5th international conference on Natural compu­
tation. ICNC’09. Piscataway, NJ, USA: IEEE Press, 2009. P. 294–298. URL:
128
http://dl.acm.org/citation.cfm?id=1797096.1797156.
18. HTCondor Version 8.0.0 Manual. University of Wisconsin–Madison: Center for
High Throughput Computing, 2013. P. 1053.
19. Abdelkader A., Caniou Y., Caron E. et al. DIET 2.8 user’s manual. Inria,
ENS-Lyon, UCBL, SysFera, 2011.
20. Amedro B., Bodnartchouk V., Baduel L. et al. ProActive Scheduling v.3.3.2
user’s manual. INRIA, University of Nice-Sophia Antipolis, ActiveEon, 2013.
P. 152.
21. Torque v.4.2.4 Administrator Guide. Adaptive Computing Enterprises, 2013.
P. 314.
22. Moab Workload Manager v.7.2.4 Administrator Guide. Adaptive Computing
Enterprises, 2013. P. 1136.
23. Maui v.3.2 Administrator’s Guide. Adaptive Computing Enterprises, 2011.
P. 287.
24. Metadata registries. ISO/IEC 11179-1 International Standard. ISO/IEC, 2004.
P. 32.
25. Qin X., Jiang H., Manzanares A. et al. Dynamic Load Balancing for
I/O-intensive Applications on Clusters // Trans. Storage. 2009. Vol. 5, no. 3.
P. 9:1–9:38. URL: http://doi.acm.org/10.1145/1629075.1629078.
26. Harchol-Balter M., Downey A. B. Exploiting Process Lifetime Distributions for
Dynamic Load Balancing // SIGOPS Oper. Syst. Rev. 1995. Vol. 29, no. 5.
P. 236–. URL: http://doi.acm.org/10.1145/224057.225838.
27. Hui C.-C., Chanson S. T. Improved Strategies for Dynamic Load Balancing //
IEEE Concurrency. 1999. Vol. 7, no. 3. P. 58–67. URL: http://dx.doi.org/
10.1109/4434.788780.
28. Acharya A., Setia S. Availability and Utility of Idle Memory in Workstation
Clusters // SIGMETRICS Perform. Eval. Rev. 1999. Vol. 27, no. 1. P. 35–46.
URL: http://doi.acm.org/10.1145/301464.301478.
29. Voelker G. M., Jamrozik H. A., Vernon M. K. et al. Managing Server Load in
129
Global Memory Systems // SIGMETRICS Perform. Eval. Rev. 1997. Vol. 25,
no. 1. P. 127–138. URL: http://doi.acm.org/10.1145/258623.258682.
30. Zhang X., Qu Y., Xiao L. Improving Distributed Workload Performance by
Sharing both CPU and Memory Resources // ICDCS. IEEE Computer Society,
2000. P. 233–241.
31. Aha D. W., Kibler D., Albert M. K. Instance-based learning algorithms //
Machine Learning. 1991. P. 37–66.
32. Wettschereck D., Aha D. W., Mohri T. A Review and Empirical Evaluation of
Feature Weighting Methods for aClass of Lazy Learning Algorithms // Artif.
Intell. Rev. 1997. Vol. 11, no. 1-5. P. 273–314. URL: http://dx.doi.org/10.
1023/A:1006593614256.
33. Wu M., Schölkopf B. A local learning approach for clustering // In Avances
Neural Information Processing Systems. 2006.
34. Bottou E., Vapnik V. Local Learning Algorithms // Neural Computation. 1992.
Vol. 4. P. 888–900.
35. Varun C., Shyam B., Vipin K. Similarity Measures for Categorical Data - A
Comparative Study // Technical Report TR 07-022. 2007. URL: http://www.
cs.umn.edu/tech_reports_upload/tr2007/07-022.pdf.
36. Hall M. A. Correlation-based feature selection for machine learning: Ph. D. the­
sis / The University of Waikato, Hamilton, NewZealand. 1999.
37. Langley P., Sage S. Oblivious Decision Trees and Abstract Cases. 1994.
38. Kelly J. D., Davis L. A Hybrid Genetic Algorithm for Classification // Proceed­
ings of the 12th International Joint Conference on Artificial Intelligence - Volume
2. IJCAI’91. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1991.
P. 645–650. URL: http://dl.acm.org/citation.cfm?id=1631552.1631558.
39. Aha D. W. Tolerating Noisy, Irrelevant and Novel Attributes in Instance-based
Learning Algorithms // Int. J. Man-Mach. Stud. 1992. Vol. 36, no. 2. P. 267–287.
URL: http://dx.doi.org/10.1016/0020-7373(92)90018-G.
40. Wettschereck D. A Study of Distance-based Machine Learning Algorithms:
130
Ph. D. thesis. Corvallis, OR, USA: Oregon State University, 1994. AAI9507711.
41. Kohavi R., John G. H. Wrappers for Feature Subset Selection // Artif. In­
tell. 1997. Vol. 97, no. 1-2. P. 273–324. URL: http://dx.doi.org/10.1016/
S0004-3702(97)00043-X.
42. Mitchell T. M. The Need for Biases in Learning Generalizations // Readings in
Machine Learning / Ed. by J. W. Shavlik, T. G. Dietterich. Morgan Kauffman,
1980. P. 184–191. Book published in 1990. URL: http://www.cs.nott.ac.
uk/~bsl/G52HPA/articles/Mitchell:80a.pdf.
43. Guyon I., Elisseeff A. An Introduction to Variable and Feature Selection // J.
Mach. Learn. Res. 2003. Vol. 3. P. 1157–1182. URL: http://dl.acm.org/
citation.cfm?id=944919.944968.
44. Ventura D., Martinez T. R. An Empirical Comparison of Discretization Mod­
els // Proceedings of the 10th International Symposium on Computer and In­
formation Sciences. 1995. P. 443–450.
45. Wilson D. R., Martinez T. R. Improved Heterogeneous Distance Functions //
J. Artif. Int. Res. 1997. Vol. 6, no. 1. P. 1–34. URL: http://dl.acm.org/
citation.cfm?id=1622767.1622768.
46. Quinlan J. R. Unknown Attribute Values in Induction // Proceedings of the
Sixth International Workshop on Machine Learning. San Francisco, CA, USA:
Morgan Kaufmann Publishers Inc., 1989. P. 164–168. URL: http://dl.acm.
org/citation.cfm?id=102118.102173.
47. Janert P. K. Data Analysis with Open Source Tools - a Hands-on Guide for
Programmers and Data Scientists. O Reilly, 2011. ISBN: 978-0-596-80235-6.
48. Nassif L. N., Nogueira J. M., Ahmed M. et al. Job Completion Prediction in
Grid Using Distributed Case-based Reasoning // 2012 IEEE 21st International
Workshop on Enabling Technologies: Infrastructure for Collaborative Enterpris­
es. 2005. P. 249–254.
49. Burkard R., Dell’Amico M., Martello S. Assignment Problems. Philadelphia, PA,
USA: Society for Industrial and Applied Mathematics, 2009. ISBN: 0898716632,
131
9780898716634.
50. Kuhn H. W. The Hungarian method for the assignment problem // Naval Re­
search Logistics Quarterly. 1955. Vol. 2. P. 83–97.
51. Hopcroft J., Karp R. An n. 5/2 algorithm for maximum matchings in bipartite
graphs // SIAM Journal on Computing. 1973. Vol. 2. P. 225–231.
52. Munkres J. Algorithms for the assignment and transportation problems // Jour­
nal of the Society for Industrial and Applied Mathematics. 1957. Vol. 5, no. 1.
P. 32–38.
53. Mary-Huard T., Robin S. Tailored Aggregation for Classification // IEEE Trans.
Pattern Anal. Mach. Intell. 2009. Vol. 31, no. 11. P. 2098–2105. URL: http:
//dx.doi.org/10.1109/TPAMI.2009.55.
54. Yuan Z.-W., Wang Y.-H. Research on K Nearest Neighbor Non-parametric Re­
gression Algorithm Based on KD-Tree and Clustering Analysis // Proceedings
of the 2012 Fourth International Conference on Computational and Information
Sciences. ICCIS ’12. Washington, DC, USA: IEEE Computer Society, 2012.
P. 298–301. URL: http://dx.doi.org/10.1109/ICCIS.2012.246.
55. Fu A. W.-c., Chan P. M.-s., Cheung Y.-L., Moon Y. S. Dynamic Vp-tree In­
dexing for N-nearest Neighbor Search Given Pair-wise Distances // The VLDB
Journal. 2000. Vol. 9, no. 2. P. 154–173. URL: http://dx.doi.org/10.1007/
PL00010672.
56. Lu J., Lu Y., Cong G. Reverse Spatial and Textual K Nearest Neighbor Search //
Proceedings of the 2011 ACM SIGMOD International Conference on Manage­
ment of Data. SIGMOD ’11. New York, NY, USA: ACM, 2011. P. 349–360.
URL: http://doi.acm.org/10.1145/1989323.1989361.
57. Gionis A., Indyk P., Motwani R. Similarity Search in High Dimensions via Hash­
ing // Proceedings of the 25th International Conference on Very Large Data
Bases. VLDB ’99. San Francisco, CA, USA: Morgan Kaufmann Publishers
Inc., 1999. P. 518–529. URL: http://dl.acm.org/citation.cfm?id=645925.
671516.
132
58. Datar M., Immorlica N., Indyk P., Mirrokni V. S. Locality-sensitive Hashing
Scheme Based on P-stable Distributions // Proceedings of the Twentieth Annual
Symposium on Computational Geometry. SCG ’04. New York, NY, USA: ACM,
2004. P. 253–262. URL: http://doi.acm.org/10.1145/997817.997857.
59. Wang H., Cao J., Shu L., Rafiei D. Locality Sensitive Hashing Revisited: Filling
the Gap Between Theory and Algorithm Analysis // Proceedings of the 22Nd
ACM International Conference on Conference on Information Knowledge Man­
agement. CIKM ’13. New York, NY, USA: ACM, 2013. P. 1969–1978. URL:
http://doi.acm.org/10.1145/2505515.2505765.
60. Dasgupta A., Kumar R., Sarlos T. Fast Locality-sensitive Hashing // Proceed­
ings of the 17th ACM SIGKDD International Conference on Knowledge Discov­
ery and Data Mining. KDD ’11. New York, NY, USA: ACM, 2011. P. 1073–1081.
URL: http://doi.acm.org/10.1145/2020408.2020578.
61. Yang Z., Ooi W. T., Sun Q. Hierarchical, non-uniform locality sensitive hashing
and its application to video identification. 2004. P. 743–746.
62. Голубев И. А., Губарев Н. В. Генерация трёхмерных карт на основе гид­
рографических данных стандарта S-57 // Известия ЛЭТИ. 2013. № 5.
С. 61–64.
63. Cormen T. H., Stein C., Rivest R. L., Leiserson C. E. Introduction to Algo­
rithms. 2nd edition. McGraw-Hill Higher Education, 2001. ISBN: 0070131511.
64. Холод И. И., Куприянов М. С., Голубев И. А. и др. Интеллектуальный
анализ распределенных данных на базе облачных вычислений. СПб: Изд-во
СПбГЭТУ ЛЭТИ, 2011. С. 148. ISBN: 978-5-7629-1176-4.
65. Холод И. И., Куприянов М. С., Голубев И. А. и др. Интеллектуальный
анализ данных в распределенных системах. СПб: Изд-во СПбГЭТУ ЛЭТИ,
2012. С. 101. ISBN: 978-5-7629-1228-0.
66. Каршиев З. А., Голубев И. А., Прохоренко K. A. Оценка ускорения и эффек­
тивности параллельного выполнения алгоритмов интеллектуального анали­
за данных // Известия ЛЭТИ. 2012. № 10. С. 46–52.
133
67. Голубев И. А. Развертывание распределенной системы интеллектуального
анализа данных в облачной среде // Известия ЛЭТИ. 2011. № 9. С. 36–43.
68. Куприянов М. С., Голубев И. А. Система восстановления моделей инфор­
мационных бизнес-процессов в унаследованных ИТ-системах // Известия
ЛЭТИ. 2011. № 10. С. 31–38.
69. Golubev I. A., Smirnov A. N. Clustering and Classification Tasks Adaptation
to Cloud Environment // IEEE RNW Section Proceedings. Vol. 2. IEEE, 2011.
70. Golubev I. A., Kupryianov M. S. Metadata-driven task scheduling in computer
clusters // Proceedings of 9th International Conference on Computer Science
and Information Technologies (CSIT 2013), Yerevan, Armenia. 2013. P. 249–252.
71. Golubev I. A., Kupryianov M. S. Cloud-based distributed data mining sys­
tems // Proceedings of 9th International Conference on Computer Science and
Information Technologies (CSIT 2011), Yerevan, Armenia. 2011. P. 183–186.
72. Голубев И. А. Уровни оптимизации загрузки арендуемых виртуальных ре­
сурсов // Proceedings of XV International Conference on Soft Computing and
Measurements (SCM’2012). 2012. С. 241–244.
73. Голубев И. А. Распределение задач обработки в вычислительных кластерах
на основе метаданных // Proceedings of XVI International Conference on Soft
Computing and Measurements (SCM’2013). Т. 1. 2013. С. 162–164.
74. Холод И. И., Куприянов М. С., Громов И. А. и др. Программа кластериза­
ции текстов на основе лексической информации, Свидетельство о гос. реги­
страции программы для ЭВМ №2010615374, 20.08.2010.
75. Холод И. И., Куприянов М. С., Громов И. А. и др. Программа автомати­
ческого сравнения слабоструктурированных текстовых документов, Свиде­
тельство о гос. регистрации программы для ЭВМ №2010615389, 20.08.2010.
76. Холод И. И., Куприянов М. С., Громов И. А. и др. Программа автоматиче­
ского построения модели бизнес процесса на основе последовательности кад­
ров мейнфреймов, Свидетельство о гос. регистрации программы для ЭВМ
№2010615373, 20.08.2010.
134
77. Холод И. И., Куприянов М. С., Громов И. А. и др. Программа автоматиче­
ского анализа структурированной текстовой информации, Свидетельство о
гос. регистрации программы для ЭВМ №20106111456, 19.02.2010.
78. Холод И. И., Серебрянский Д. А., Голубев И. А. Программа генерации гра­
фовых моделей на основе подграфов, Свидетельство о гос. регистрации про­
граммы для ЭВМ №2012610928, 20.01.2012.
79. Голубев И. А. Программа для распределённого анализа данных, Свидетель­
ство о гос. регистрации программы для ЭВМ №2012610984, 23.01.2012.
80. Афанасьев А. Н., Голубев И. А., Губарев Н. В. и др. Модуль построения
карт высот в системе гидроакустического мониторинга акватории для карт
стандарта S-57, Свидетельство о гос. регистрации программы для ЭВМ №
2013611677, 30.01.2013.
81. Афанасьев А. Н., Голубев И. А., Губарев Н. В. и др. Модуль визуализации
карт высот для систем гидроакустического мониторинга акватории, Свиде­
тельство о гос. регистрации программы для ЭВМ № 2013611630, 30.01.2013.
82. Афанасьев А. Н., Голубев И. А., Губарев Н. В. и др. Модуль визуализации
тактической подводной обстановки для систем гидроакустического монито­
ринга акватории, Свидетельство о гос. регистрации программы для ЭВМ
№ 2013611675, 30.01.2013.
135