Разработка модели среды распределенных вычислений Evergrid для сравнения алгоритмов управления потоками задач и данных (1187422), страница 5
Текст из файла (страница 5)
Если взять во внимание тот факт, что подобных приложений на go найдено небыло, то преимущества таковы:∙ возможность использовать один код планировщика как для симуляции, так идля реального окружения - это дает дополнительные гарантии корректностиего реализации∙ удобная возможность записи реальных сценариев работы и последующей симуляции их с различными вариантами планировщиков∙ go - простой в использовании язык и имеет встроенную модель параллелизмаCSP, это облегчает разработку и модификацию кода симуляции∙ go - быстрый язык, скорость его работы сравнима с C/C++∙ в go встроен автоматический детектор состояний гонки∙ go популярен для микросервисов, но на данный момент нет ни одного симулятора для goСледует понимать, что использование или модификация готового решения должны предоставлять преимущества, перевешивающие этот список.4.1.
NetLogoNetLogo[2] - очень известное решение для моделирования и исследования работы многоагентных систем. Его преимущество состоит в развитых инструментахвизуализации.Но для решения конкретной задачи NetLogo подходит плохо, т. к.:∙ NetLogo использует свой язык программирования. Это язык узкого назначенияи писать на нем менее удобно, чем на популярных языках общего назначения27∙ мы симулируем не только scheduler, но и прочие компоненты системы. Намважно, чтобы модель общения между ними была приближена к реальной. Этодает возможности для поиска состояний гонки в рамках архитектуры в целом.Реализация честного общения всех компонентов довольно сложна на NetLogoи потенциально сложнее написания своей реализации на go.∙ у него низкая скорость работы4.2.
Узкоспециализированные симуляторы: SimGrid, GridSim,ALEA 2Среди более узкоспециализированных решений было найдено три кандидата:SimGrid[3], GridSim[4] и ALEA 2[5].Эти продукты реализованы на Java (GridSim, ALEA 2) и C (SimGrid). У всехтрех есть один критический недостаток: без модификации исходного кода невозможно реализовать поставленную задачу - архитектура проекта слишком специфична.А сама задача их модификации получается сложнее, чем написание своего решения.Также усложняется и сопровождение получившегося симулятора - вносить правкитяжелее по двум причинами: Java и C менее удобны чем go, больший шанс неожиданных ошибок в виду возможных конфликтов с изначальной архитектурой симулятора.Еще одна особенность всех трех симуляторов - они сверхсконцентрированы наанализе планировщика, в то время как одной из наших задач является и анализархитектуры в целом.Также есть проблемы специфичные для каждого из решений:4.2.1. GridSimДата последнего обновления - 2010й год.
Видимо, проект более не поддерживается, и при возникновении незадокументированных проблем трудно будет связатьсяс его разработчиком.Также при использовании GridSim будет проблематично симулировать "динамическое"окружение - разрывы сети, меняющийся список воркеров и прочее.Итого: суммарная сложность модификации и поддержки решения на GridSimпотенциально выше сложности написания и поддержки своей реализации на go.
Приэтом мы еще жертвуем вышеописанными преимуществами своей реализации.284.2.2. ALEA 2ALEA 2 является модификацией GridSim, и ее использование сопряжено с темиже проблемами. В отличие от GridSim, она еще поддерживается разработчиками.4.2.3. SimGridНаиболее активно поддерживаемый продукт, но более узкоспециализирован, чемдва других. Количество модификаций, которые необходимо будет внести, существенно больше - что усложняет его адаптацию.К тому же, из соображений скорости он написан на С, а модифицировать кодна С обычно сложнее, чем модифицировать код на Java.29Глава 5Реализованная в симуляторе модельВ этой главе описана реализованная в симуляторе модель. Это даст представление о том, как проходит процесс симуляции и какова степень подробности и точностисимулятора.5.1.
Многоагентное окружение с дискретным временемОснову симулятора представляет из себя многоагентая среда. Она состоит изагентов и ядра, которые общаются друг с другом посредством сообщений.Ядро системы обеспечивает синхронизацию работы агентов и управляет временем. Симуляция не является непрерывной и разбита на дискретные единицы времени(ticks). Каждый tick соответствует одной минуте. Подобный выбор масштаба обуславливается тем, что предполагается достаточная скорость работы планировщика,чтобы успеть обработать запросы пришедшие в рамках одного tick’а за минуту.
А исходя из того, что предполагаются довольно большие объемы датасетов, погрешностьвремени порядка минуты на передачу данных является допустимой.В процессе каждого тика агент меняет свое состояние. Данный процесс цикличен. Возможные состояния агента и переходы между ними показаны на рисунке 5.1.Прямоугольники - это состояния. Второй тип элементов - это синхронизации.
Синхронизация означает, что невозможно пройти по данному ребру, пока все агенты небудут готовы.Описание состояний:Done Означает, что предыдущий тик завершен успешно. Является исходным состоянием агента.Ready Означает, что агент готов начать работу в рамках нового тика.Working Означает, что агент в данный момент совершает работу.Idle Означает, что агент в данный момент бездействует и выполнил всю делегированную ему на данный момент работу.Описание синхронизаций:30Рис. 5.1.
Цикл работы агентаStart Work Дает гарантию, что перед началом работы все агенты достигли состояния ReadyFinish Work Дает гарантию, что перед завершением тика все агенты находятся всостоянии Idle.Важным аспектом является то, что признак завершения тика - это статус Idleу всех агентов системы. Это нужно помнить и не позволять системе попадать в этосостояние, когда не вся работа сделана.В состоянии Idle агент ждет одного из двух событий: новое сообщение от другогоагента либо сигнал Finish Work.
В последнем случае состояние меняется на Done. Этасмена состояния единственная не контролируется агентом напрямую.Помимо основного статуса каждый агент имеет булев маркер stopFlag. Если онравен true, значит агент не запланировал никакой работы на будущие тики, и, еслисимуляция завершится сейчас, то это будет корректный исход.Соответственно, симуляция завершается, когда у всех агентов stopFlag маркерравен true.5.2. Сетевое окружениеВ терминах описанной многоагентной среды симуляция сетевого окружения является заботой самих агентов.
Причем это несложно реализуется: если агент знает31свое место и места прочих агентов внутри сети, то он сам может накладывать ограничения на общения с этими агентами. То есть симуляция сети сводится к предоставлению конкретным агентам информации о конфигурации сети.Структура сети в текущей версии симулятора представляет из себя набор изсегментов.
Каждый сегмент содержит несколько машин. К одной машине могут бытьпривязаны один и более агентов.Скорость передачи данных внутри сегмента и между сегментами может бытьразличной и является частью его описания.5.3. Параллелизм и коммуникацияАгенты должны исполняться параллельно друг другу и ядру. Конечно, они могут блокировать друг друга - это соответствует ситуации, когда сервис не можетответить на новый запрос, пока не завершена обработка предыдущего.
Но в рамкахнезависимых участков кода мы получаем прирост производительности симуляцииблагодаря параллелизму. А в виду недетерминированного порядка выполнения этихучастков - можем заметить состояния гонки вызванные недостаточно качественнойпроработкой архитектуры.5.4. Изоляция агентовВ большинстве случаев агенты должны быть изолированы друг от друга. Этоозначает, что весь обмен информацией между ними должен происходить посредствомсообщений.В порядке исключения, конечно, можно использовать разделяемую память имьютексы. Например, это годится для тех случаев, когда мы симулируем распределенное хранилище, а его конкретная реализация и возможность сбоев выходят зарамки эксперимента.5.5.
Генерация сценариевГенерация сценариев, которые воспроизводятся в симуляции, должна происходить отдельно. Это позволит сравнивать поведение планировщиков и архитектурыв максимально приближенных условиях. Следовательно, симулятор должен предоставлять два инструмента: для генерации сценариев и для запуска симуляции.32Сценарий состоит из трех частей: конфигурация сети, описание датасетов иконтейнеров, последовательность запросов в систему.Сгенерированный сценарий представляет из себя набор YAML-файлов (вышеуказанные части лежат каждая в своем файле).
При желании вместо генерацииможно составить сценарий вручную или вносить правки в уже сгенерированный.5.6. Сбор статистикиНужно предоставить максимальную свободу в обработке данных. Это приводит к тому, что правильно сделать результатом работы симулятора логи, причем вудобном формате. В логи надо писать, что и когда произошло, а с помощью любоговнешнего инструмента можно на основе логов выстроить произвольные метрики.В данной работе в качестве формата логов был выбран JSON в виду хорошегобаланса простоты и гибкости.5.7.
Детали реализации компонентов системыТеперь подробнее рассмотрим принципы реализации конкретных компонентовархитектуры. Всего есть три типа агентов: Core, Control Unit, Worker5.7.1. CoreДанный агент при инициализации получает список запросов. Каждому запросу из списка соответсвует порядковый номер тика, когда он должен быть послан всистему. Каждый отдельный запрос посылается случайному Control Unit’у.5.7.2. Control UnitК каждому Control Unit’у привязана группа Worker’ов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
