Разработка модели среды распределенных вычислений Evergrid для сравнения алгоритмов управления потоками задач и данных (1187422), страница 3
Текст из файла (страница 3)
Тогда злоумышленник будетзнать минимум о текущем состоянии системы. Прочие методы борьбы с этой угрозойуже выходят за рамки этой работы.Следующее ограничение происходит из того, как мы будем выполнять задачи.Очевидно, что нам нужна виртуализация - иначе наш кластер быстро превратят вботнет. Нам нужна универсальность - хочется покрыть как можно больше сценариевиспользования. Также нам нужна скорость - следовательно, нам нужна легковеснаявиртуализация.
Третий критерий - технология должна быть простой в использовании. В идеале - проведение эксперимента на своей локальной машине не должно отличаться от выполнения его на наших мощностях. Сложив все эти требования воедино,мы получим ответ - Docker. И это решение имеет много преимуществ: Docker отлично отвечает требованиям к изоляции, удобству воспроизводимости и модификации.А его инструментарий органично вписывается в архитектуру. От предоставляемыхмощностей нам в итоге требуется:∙ свободное место на диске∙ доступ по ssh∙ корректно работающий docker∙ возможность мониторинга нагрузки (чтобы регистрировать не относящуюся кнашему сервису нагрузку)Даже неограниченный доступ в Интернет не является жестким требованием мы можем собрать контейнер на наших машинах и готовый образ передать по ssh.Возникает вопрос о том, как пользователь должен предоставлять контейнер сосвоим алгоритмом.
Если следовать идеям доступности и простоты модификации, тонаиболее очевидное решение - Github. Наиболее органично будет работать с специально оформленными github-репозиториями, которые содержат все необходимое длясборки контейнера.Использование Docker на первый взгляд накладывает ограничение вида „одназадача = одна машина”, но это можно обойти - ведь мы можем активизироватьнесколько машин и разрешить контейнерам общаться между собой.
Тем не менее,15в рамках данной работы акцент сделан именно на подходе "одна задача = одна машина". Несмотря на это, архитектура должна быть пригодна для обоих вариантов.Если уж рассмотрели то, как загружать реализации алгоритмов (далее будемназывать их контейнерами, раз имеем в виду Docker) - то стоит сказать пару слов озагрузке датасетов. Никаких особых ограничений здесь незаметно. Все, что нужно- это иметь системе возможность закачать собранный контейнер на свои машины.Путей достижения этого много, и в данной работе они не будут рассматриваться (заисключением перемещения датасетов внутри самой системы).И последнее ограничение, о котором я хочу сказать, - это CAP-теорема. Мыимеем дело с распределенной в глобальной сети системой, а в таком случае нельзязабывать о CAP-теореме.
Нарушение связи между элементами системы не должноприводить к ее некорректной работе.16Рис. 3.1. Диаграмма архитектуры3.2. Предлагаемая архитектураТеперь можно рассмотреть конкретную реализацию, удовлетворяющую описанным выше принципам. Диаграмма предлагаемой архитектуры показана на рисунке3.1. Далее мы рассмотрим в отдельности каждый из ее слоев и компонентов.Для начала объясню общую структуру.
Здесь видно разделение на три слояплюс пользователи системы. User 1 – User X - это пользователи. Каждый слой состоитиз компонентов. Распределение компонентов по машинам специфично для каждогослоя. Для слоя Interface оно явно не ограничивается предложенной архитектурой. Взависимости от нагрузки и прочих факторов все эти компоненты могут быть как наодной машине, так и разнесены по нескольким. Для слоя Control истинно правило"одна машина - один Control Unit". Для слоя Execution все просто - один Workerравен одной машине, предоставленной для вычислений.Направление стрелок - это направление запросов между компонентами.
В случаедолговременного соединения - стрелка направлена от инициатора.Первые два слоя - это “наши” машины, которым мы доверяем, и только у нас17есть к ним доступ.Третий слой - машины, предоставленные извне, мы им “не доверяем”.Слева показаны приоритеты в терминах CAP-теоремы для каждого слоя.Справа показано, что первые два слоя используют Hashicorp Consul для servicediscovery и leader election.3.2.1.
Слой ExecutionНа этом слое находятся машины, предоставленные пользователями системы.Они частично конфигурируются нами и не содержат никакого кода, который быуправлял слоями выше (из соображений безопасности). Про специфику работы сэтими ресурсами и требования к ним было написано выше.Все запросы приходят со слоя Control. То есть машинам даже необязательнознать IP других компонентов системы. Отдельный случай - если машины не имеют”белого” IP: в этом случае в их обязанность входит самостоятельно поддерживатьсоединение со слоем Control, и нам все же придется ставить на Worker’ы какое-нибудьприложение, которое будет обеспечивать соединение со слоем Core.3.2.2.
Слой ControlСостоит только из Control Unit’ов. Каждый Control Unit - это отдельная машина. Каждый Worker из слоя ниже принадлежит только одному Сontrol Unit’y.Control Unit состоит из нескольких логических компонент и представляет изсебя монолитную программу.Все Control Unit с этого слоя представляют из себя распределенную систему. Тоесть запросы с верхнего слоя Interface по своей сути направлены не к конкретномуControl Unit’у, а ко всей системе целиком.Смысл подобного разбиения - это большая стабильность системы. Т.
е. эффективным подходом будет, например, расположить по одному Control Unit на географическую зону.Смысл всей этой системы в следующем:∙ Получать задания со слоя выше (от Сore)∙ Раскидывать датасеты по Worker’ам∙ Запускать вычисления на Worker’ах18∙ Отправлять результаты вычислений на Worker’ах на слой выше (в Core).Теперь конкретные примеры запросов, которые могут приходить в эту систему:∙ Загрузи датасет∙ Загрузи и собери этот docker-контейнер∙ Обнови этот докер контейнер∙ Обнови этот датасет∙ Запусти этот контейнер с этим датасетомИз подобных задач формируются локальные очереди (Local Queue). В какуюлокальную очередь и на какой Worker отправить задачу, определяет “распределенный” Scheduler.
Также состояние, корректность и доступность Worker’ов, прочие глобальные характеристики системы отслеживаются Monitor’ом. Monitor может даватьинформацию о всех доступных Worker’ах системы. Monitor - основной инструментScheduler’а для получения текущего состояния системы. Executor отвечает за "опустошение"очереди и выполнение задач на Worker’ах.Результат выполнения работы отправляется в Core, который, в свою очередь,решает, где хранить этот результат.3.2.3. Слой InterfaceРаспределение по машинам в этом слое диктуется лишь нагрузкой. При маломколичестве пользователей - можно все три компонента держать на одной машине.Теперь отдельно про каждый компонент.WEB Веб-приложение, написанное на любом адекватном web-фреймворке.
Именночерез него происходит постановка задач, просмотр результатов и прочее. Является единой точкой управления системой как для рядовых пользователей, таки для администраторов. Важно понимать, что здесь используются не толькоHTML + JS, но и реализована вся бизнес-логика интерфейса.DB Основная база данных. В ней хранится все относящееся к бизнес-логике приложения. По своему содержанию должна быть независима от нижестоящихслоев. Т. е. если конфигурация всего того, что есть ниже, станет иной - данныене должны стать некорректными.19Core WEB не общается напрямую со слоем Сontrol. Он работает с Core через API,а оно в свою очередь контролирует слой ниже. Т.
е. Core - это микросервисвзаимодействия со слоем Control. Это важное разделение, поэтому подчеркну:WEB - это бизнес логика, Core - микросервис, который контролирует общениес распределенной вычислительной системой. Core не проверяет никаких параметров, связанных с бизнес-логикой: кто поставил задачу, сколько у него денегна счету и прочее.3.3. Выбор технологий для реализаций компонентовТеперь, когда есть представление о структуре, надо понять, какие есть эффективные способы реализации. Если не оговорено иного, предложенные способы несутрекомендательный характер.3.3.1. WEBПосколько Evergrid является по своей сути стартапом, то важным аспектом является скорость разработки.
То есть надо уметь быстро создать прототип и иметьвозможно быстро вносить изменения. На Java и ASP.NET подобное получается плохо, особенно у небольших команд. Наиболее успешно используемые технологии - этоRuby on Rails1 , Node.js2 фреймворки3 , Django4 и прочие python-фреймворки, PHP5 .Есть также менее распространенные решения, но тоже заслуживающие внимания: Play Framework6 , Phoenix Framework7 .Веб-фреймворки можно разделить на два класса:С "синхронной"архитектурой – когда запускается ровно N обработчиков запросов (в отдельных процессах или тредах). То есть система может одновременнообрабатывать не более чем N запросов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
