Моделирование вычислений в облачной системе - umotnas.ru o_O
Моделирование вычислений в облачной системе - umotnas.ru o_O
|
страница 1
|
|||||||||||||||||||||||||||||||||||||||||||
|
Похожие работы
|
Моделирование вычислений в облачной системе - страница №1/1
МОДЕЛИРОВАНИЕ ВЫЧИСЛЕНИЙ В ОБЛАЧНОЙ СИСТЕМЕ Полежаев П.Н. Оренбургский государственный университет, г. Оренбург Для организации HPC поверх облачных центров был выбран подход, заключающийся в создании неавтономной грид-системы, функционирующей поверх вычислительного облака. Опишем основные преимущества и особенности реализации данного подхода. Грид-система представляет собой совокупность вычислительных кластеров, каждый из которых развернут внутри группы экземпляров виртуальных машин в отдельном сегменте центра обработки данных (ЦОД), а также экземпляра виртуальной машины грид-диспетчера, который поддерживает единую очередь параллельных вычислительных задач. Грид-система и облачная система не изолированы полностью друг от друга, как это характерно для обычных подходов к реализации HPC поверх облаков. Облачная система предоставляет планировщику грид-системы актуальную информацию о состоянии сети облака (оценку задержек при передаче пакетов между виртуальными вычислительными узлами), а грид-система передает информацию подсистеме маршрутизации облака о выполненных назначениях процессов параллельных задач и их коммуникационные схемы. Такой осознанный подход к снижению уровня абстракции и универсализации облачной системы позволяет, с одной стороны, планировщику грида, обладающему актуальной информацией о высокопроизводительной сети, эффективно и локализовано назначать процессы параллельных задач. А с другой, подсистема маршрутизации облачной системы может использовать проактивную схему маршрутизации. Данная схема заключается в том, что, когда известны шаблоны коммуникации (например, виртуальные топологии MPI-2 для параллельных задач) между сетевыми устройствами, то маршруты передачи данных между ними можно проложить заранее, до начала коммуникаций. Это позволяет избежать задержки обработки первого пакета, которая характерна для реактивной схемы, в которой при получении первого пакета каждого нового потока маршрут прокладывает контроллер и устанавливает соответствующие правила во все OpenFlow-коммутаторы [1, 2]. При использовании обеих схем имеет место проблема ограниченности размера таблицы записей о потоках OpenFlow-коммутаторов. В случае реактивной схемы она решается путем установки каждого правила коммутации на некоторый интервал времени, после оно автоматически удаляется из таблицы. В случая проактивной схемы предложен вариант, в котором агрегируются потоки между процессами параллельных задач, при условии, что процессы запущены в одних и тех же виртуальных машинах. Все описанное выше позволяет снизить среднее время выполнения коммуникационно-интенсивных задач, а также увеличить среднюю загрузку, как грид-системы, так и всей облачной системы. В разрабатываемой облачной системе планируется использовать смешенную схему маршрутизации: проактивную – для передачи данных между процессами параллельных программ и реактивную – для управления инфраструктурными потоками в облаке. Современные алгоритмы планирования задач в облачных вычислительных системах недостаточно эффективны. Возможно их улучшение за счет учета: топологии вычислительной системы, сетевой конкуренции, задержек при передачи данных, многопроцессорности вычислительных узлов, виртуализации узлов, сетевых устройств и программно-конфигурируемой сети. Для разработки подобных алгоритмов необходимо создание адекватной модели групп виртуальных машин, а также модели вычислительной задачи грид-системы, функционирующей поверх вычислительного облака. Далее опишем их более подробно. где – набор экземпляров виртуальных машин, входящих в группу, и соединенных друг с другом полносвязным образом; – пользователь облачной системы, являющийся владельцем группы; – заданное пользователем желаемое значение минимальной гарантированной пропускной способности по каждой связи между виртуальными машинами внутри группы; – указанное пользователем желаемое значение максимальной гарантированной задержки по каждой связи между виртуальными машинами внутри группы. Любой экземпляр виртуальной машины имеет тип в вычислительном облаке и входит в его сегмент , он является виртуальным вычислительным узлом облака и, подобно физическому узлу, имеет следующие параметры и динамические характеристики: Формула Здесь и – соответственно размеры выделенной виртуальной оперативной и дисковой памяти в Мб, – количество выделенных виртуальных вычислительных ядер, – их относительная производительность, – множество виртуальных портов, – образ виртуальной машины. К числу динамических характеристик относятся: и – соответственно удельные доли загруженности оперативной и дисковой памяти вычислительного узла в момент времени , – вектор загруженностей каждого из виртуальных вычислительных ядер узла в момент времени , причем , – состояние виртуальной вычислительной машины в момент времени Разработанная модель параллельной вычислительной задачи детально описывает группу экземпляров виртуальных машин облачной системы, позволяет пользователю указывать желаемые значения минимальной гарантированной пропускной способности и максимальной гарантированной задержки. Модель вычислительной задачи грид-системы, функционирующей поверх вычислительного облака. Каждая вычислительная задача , отправляемая на исполнение в грид-систему, может быть представлена в виде совокупности подзадач , связанных бинарным отношением предшествования , которое задается следующим образом: подзадача использует результаты выполнения задачи , и поэтому она может быть запущена только по окончанию задачи . Произвольная вычислительная задача , поступающая в очередь грид-диспетчера, может быть формально описана в виде взвешенного ориентированного ациклического графа: где – множество вершин-подзадач, – множество дуг, определяющих зависимости по данным, – отображение, определяющее оценку объема передаваемых данных в байтах по соответствующей дуге (между подзадачами), размер входных данных для вершин-источников и оценку размера выходных данных для вершин-стоков . Входные данные вершин-источников подготавливаются владельцем задачи заранее, до запуска задачи, и передаются грид-диспетчеру в момент отправки задачи на исполнение. Эти данные могут быть оформлены в виде файлов или записей в базе данных. По окончанию вычислений выходные данные вершин-стоков возвращаются пользователю. Каждая подзадача представляет собой параллельную неинтерактивную программу, способную работать в пакетном режиме. Будем считать, что каждая подзадача целиком выполняется в рамках выделенного ей виртуального кластера вычислительного облака (группы виртуальных машин), т.е. недопустимо, чтобы одна часть ее процессов выполнялось на одном кластере, а другая – на другом. Это ограничение связано с допущением об интенсивном информационном обмене между процессами подзадачи, происходящем во время вычислений, и предположением о том, что стоимость межкластерных комммуникаций (через сеть Интернет) непомерно высока. Процессы подзадачи запускаются локальным планировщиком кластера одновременно на всех выделенных вычислительных ядрах, во время работы они обмениваются сообщениями между собой. Ресурсы, выделенные подзадаче, освобождаются при завершении всех ее процессов. Подзадача характеризуется следующим набором параметров: где – количество необходимых вычислительных ядер (количество создаваемых процеесов); и – соответственно объемы оперативной и дисковой памяти в килобайтах, запрашиваемые для исполнения каждого процесса подзадачи; задает оценку пользователя в секундах времени выполнения подзадачи на узлах с единичной относительной производительностью; описывает набор коммуникационных шаблонов подзадачи для каждого вычислительного шага, например, отдельные группы пересылок, сопровождающие вычисления, при решении задачи вычисления разложения Фурье, задачи параллельного умножения матриц. Следующая формула позволяет вычислить – оценку времени выполнения подзадачи с учетом производительности выделенных ей планировщиком вычислительных узлов: где – множество пар номеров «сегмент-виртуальный узел», назначенных диспетчером подзадаче . Множество включает набор коммуникационных шаблонов подзадачи, каждый из которых может быть описан в виде взвешенного ориентированного графа следующего вида: где – множество процессов подзадачи; – функция, определяющая вес каждой дуги, равный ее коммуникационной интенсивности ( обозначает интенсивность передачи пакетов от процесса к процессу ); – оценка продолжительности времени, в течение которого действует коммуникационный шаблон . Можно условно выделить два класса вычислительных задач:
Оба класса вычислительных задач должны эффективно планироваться диспетчером грид-системы. Построенная математическая модель вычислительной задачи грид-системы позволяет формализовать внешнюю (требования к числу ядер, к памяти, оценка времени выполнения) и внутренюю (коммуникационные шаблоны и ограничения предшествования) структуру высокопроизводительной задачи, характерной для современных грид-систем. Разработанные модели параллельной вычислительной программы для облачной системы и вычислительной задачи для грид-системы полностью отражают специфику сорвеменных облачных систем, включая OpenStack [3], а также современных диспетчеров грид-систем и их алгоритмов планирования. В будущем планируется разработка эффективных алгоритмов планирования задач и их исследование с помощью автоматизированного программного симулятора облачной и грид-системы. Работа поддержана федеральной целевой программой «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007–2013 годы» (госконтракт №07.514.11.4153) и РФФИ (проект №12-07-31089). Список литературы
|
|
|