Разработка модели среды распределенных вычислений Evergrid для сравнения алгоритмов управления потоками задач и данных (1187422), страница 6
Текст из файла (страница 6)
С данными Worker’амиможет общаться только этот Control Unit.В каждый момент времени ровно один Control Unit является лидером.Control Unit содержит в себе следующий подкомпоненты:scheduler - сам планировщик. Критически важна возможность использования одной и той же реализации планировщика как для симуляции, так и для реальныхусловий.
Может либо пополнять очереди выполнения произвольных воркеров,либо делегировать запрос лидеру.33monitor - компонент, который используется планировщиком, чтобы узнать глобальное состояние системыlocal queue - содержит очередь задач для подконтрольных воркеров. КомпонентExecutor из описания архитектуры в виду простоты своего устройства встроенв этот подкомпонент модели Control Unit.Подкомпоненты работают в отдельных потоках выполнения.Control Unit может принимать два типа запросов:Запросы на загрузку датасета или запуск контейнера c указанным датасетом- данные запросы могут приходить от Core или быть делегированы другимControl Unit’ом.
Обрабатываются scheduler’ом.Запросы на добавление задачи в очередь подконтрольного Worker’а - данные запросы приходят от других Control Unit’ов. Причина их появления в том,что при своей работе планировщик рассматривает все Worker’ы системы, а нетолько принадлежащие его Control Unit’у.5.7.3. WorkerВ один момент времени Worker может исполнять только один запрос.
Запросык нему могут приходить только от связанного с ним Control Unit’а.Worker может принимать три вида запросов:Загрузка датасета Время, необходимое на это, вычисляется на основе скоростипередачи данных, полученной из описания сети.Сборка контейнера - в данный момент считается, что контейнер собирается заодин тик. При желании этот параметр можно изменить.Выполнение контейнера с заданным датасетом - датасет и контейнер должны быть уже загружены на Worker. Время, необходимое на данную задачу,вычисляется по упрощенной модели: воркер имеет параметр производительности во флопсах, а контейнер имеет параметр, сколько флопс нужно на каждыймегабайт данных.
Разделив одно на другое, получаем искомое время.34Глава 6РезультатыРезультатами работы является описание архитектуры (приведенное в тексте диплома) и реализация симулятора доступная на github: https://github.com/ffloyd/evergrid-go.Код симулятора продокументирован для облегчения его последующей разработки и модификации. Технические тонкости реализации и более подробное рассмотрение принципов работы отдельных компонентов вынесены за рамки текста дипломаи являются частью документации.Удобная он-лайн версия документации доступна по адресу: https://godoc.org/github.com/ffloyd/evergrid-go.Помимо описания работы компонентов, в документации даны рекомендации попутям эффективной модификации и расширения системы.При реализации описанной в предыдущей главе модели go показал себя с сильной стороны.
Модель параллелизма CSP оказалась крайне удобной для реализациимногоагентной системы как с точки зрения внутренней архитектуры, так и с точкизрения получившегося API.Реализованная как часть симулятора многоагентная среда получилась независимой от остального кода и может быть использована как база для написания другихсимуляторов.При реализации для симулятора компонентов CoreUnit, Core и Worker быловыявлено множество небольших технических аспектов, касающихся синхронизацииработы компонентов.
Причем эти аспекты будут актуальны и при написании реализаций этих компонентов для реальных условий. Этот факт подтверждает оправданность идеи, что необходимо тестировать не только сам планировщик, но и принципывзаимодействия остальных частей системы.Эти тонкие моменты выражены в документации, которой сопровожден код исамом коде. В качестве примера приведу один из таких моментов: "если два последовательных запроса в систему оперируют одним датасетом или контейнером, то второй запрос должен быть послан в систему строго после окончания обработки первогоControl Unit’ами".
Конкретно этот пример связан с тем, что глобальное состояниесистемы должно полностью отражать изменения, привнесенные обработкой первого35запроса. Иначе может оказаться, что мы, например, дважды запланируем загрузкуодного и того же датасета на один Worker.6.1. Установка и использование evergrid-goРеализованный программный продукт называется evergrid-go и представляет изсебя CLI-приложение (Command Line Interface).Ниже описан наиболее простой сценарий для установки разработанного симулятора и примеры его использования.Для начала нам надо установить go и настроить его окружение.
Инструкцииесть на сайте языка программирования go: https://golang.org/doc/install. Упрощенный способ для установки на Ubuntu: https://github.com/golang/go/wiki/UbuntuКогда окружение настроено скачиваем и устанавлваем актуальную версию evergridgo следующей командой:go get github . com / ffloyd / evergid - goПосле этого генерируем сценарий работы (со стандартными настройками) в папке simdata:$GOPATH / bin / evergrid - go gendata test simdataПоменять параметры генерации можно через опции, список которых можно увидеть с помощью команды:$GOPATH / bin / evergrid - go gendata -hДалее можно запустить симуляции для различных типов планировщика:$GOPATH / bin / evergrid - go simulator simdata / test .
yaml -s random$GOPATH / bin / evergrid - go simulator simdata / test . yaml -s naivefast$GOPATH / bin / evergrid - go simulator simdata / test . yaml -s naivecheap6.2. Пример работыНиже приведены примеры результатов работы симуляции на одинаковом сценарии для всех трех тривиальных реализаций планировщика.Показаны только последние строчки логов, которые содержат статистику использования воркеров.36Как будет видно, планировщики дают результаты соответсвующие их целям.Naive Fast имеет наименьшее значение ”total calculating ticks”, Naive Cheap имеетнаименьшее значение ”total money spent”, а все три запуска random scheduler оказались существенно хуже по этим параметрам.Данные результаты представлены в ознакомительных целях, а сами планировщики представляют из себя довольно наивные реализации, которые не предназначены для работы в реальных условиях.6.2.1.
Random SchedulerПри запросе на загрузку датасета выбирается один случайный воркер и датасетзагружается на него.При запросе на выполнение эксперимента - эксперимент запускается на воркерес уже загруженным датасетом.Так как работа планировщика рандомизирована приведены результаты трех запусков. Остальные два планировщика выдают одинаковый результат при условииодинакового сценария.Листинг 6.1. Random Scheduler: запуск 1Total uploading tickssimulation = big value =269Total building tickssimulation = big value =82Total calculating tickssimulation = big value =5336Total money spentsimulation = big value =4158.3458Листинг 6.2. Random Scheduler: запуск 2Total uploading tickssimulation = big value =269Total building tickssimulation = big value =83Total calculating tickssimulation = big value =4450Total money spentsimulation = big value =2670.4092Листинг 6.3.
Random Scheduler: запуск 3Total uploading tickssimulation = big value =269Total building tickssimulation = big value =85Total calculating tickssimulation = big value =5353Total money spentsimulation = big value =3992.3984376.2.2. Naive Fast SchedulerПри запросе на загрузку датасета выбираются три наиболее производительныхворкера с размером очереди меньше пяти, либо просто три наиболее производительных воркера.При запросе на выполнение эксперимента - среди воркеров с загруженным (илис запланированным для загрузки) датасетом выбирается наиболее быстрый с размером очереди меньше 5-и, либо просто наиболее быстрый из воркеров с минимальнойочередью, если это невозможно.Листинг 6.4.
Naive Fast SchedulerTotal uploading tickssimulation = big value =807Total building tickssimulation = big value =55Total calculating tickssimulation = big value =1611Total money spentsimulation = big value =1361.84396.2.3. Naive Cheap SchedulerПри запросе на загрузку датасета выбираются три наиболее дешевых воркера сразмером очереди меньше пяти, либо просто три наиболее дешевых воркера.Сравнивается цена за одну минуту работы.При запросе на выполнение эксперимента - среди воркеров с загруженным (илис запланированным для загрузки) датасетом выбирается наиболее дешевый с размером очереди меньше 5-и, либо просто наиболее дешевый из воркеров с минимальнойочередью, если это невозможно.Листинг 6.5. Naive Cheap SchedulerTotal uploading tickssimulation = big value =807Total building tickssimulation = big value =63Total calculating tickssimulation = big value =2574Total money spentsimulation = big value =497.475938ЗаключениеВ данной работе на основе общего описания системы Evergrid была сформулирована ее архитектура.
На основе этой архитектуры была реализована среда ее моделирования на языке программирования go. Соответсвенно, результатами работыявляются:∙ описание архитектуры∙ рекомендации по ее реализации∙ симулятор этой архитектуры для анализа работы планировщиков∙ подробная техническая документация этого симулятора, посвященная его использованию и модификацииАрхитектура приведена в тексте диплома, а продокументированный исходныйкод симулятора доступен на github: https://github.com/ffloyd/evergrid-go.Сформулированная архитектура призвана облегчить разработку системы в будущем, а написание своего симулятора в противовес использованию готовых решенийобосновано совокупностью следующих факторов:∙ ни одно из популярных решений в своем исходном виде не поддерживает необходимую архитектуру, а их модификация оказывается не менее сложной задачейчем написание своей реализации∙ малоизвестные решения рискованно использовать∙ не требуется столь сложный механизм симуляции, который используется в популярных решениях∙ go удобнее для написания и поддержки подобных систем, чем C/С++ или Java∙ отсутствие подобных симуляторов реализованных на go∙ возможность интероперабельности с реальной системой увеличивает качествосимуляции и самого продукта∙ важность проверки работоспособности принципов работы предложенной архитектуры39При написании симулятора учитывалось, что его будут расширять и модифицировать, поэтому особое внимание уделялось изолированности и заменяемости егокомпонентов.40Список литературы1.
Sakaki T., Okazaki M., Matsuo Y. Earthquake Shakes Twitter Users: Real-time EventDetection by Social Sensors // Proceedings of the 19th International Conference onWorld Wide Web. WWW ’10. New York, NY, USA: ACM, 2010. P. 851–860. URL:http://doi.acm.org/10.1145/1772690.1772777.2. Tisue S., Wilensky U. Netlogo: A simple environment for modeling complexity //International conference on complex systems / Boston, MA. Vol. 21. 2004.3. Casanova H. Simgrid: A toolkit for the simulation of application scheduling // Clustercomputing and the grid, 2001.
proceedings. first ieee/acm international symposiumon / IEEE. 2001. P. 430–437.4. Buyya R., Murshed M. GridSim: a toolkit for the modeling and simulation of distributed resource management and scheduling for Grid computing // Concurrencyand Computation: Practice and Experience. 2002.
Vol. 14, no. 13-15. P. 1175–1220.URL: http://dx.doi.org/10.1002/cpe.710.5. Klusáček D., Rudová H. Alea 2: Job Scheduling Simulator // Proceedings of the3rd International ICST Conference on Simulation Tools and Techniques. SIMUTools’10. ICST, Brussels, Belgium, Belgium: ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2010. P.
61:1–61:10. URL:http://dx.doi.org/10.4108/ICST.SIMUTOOLS2010.8722..
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
