Кооперация: Согласование множества ресурсов

В то время, как уровень Ресурсов нацелен на взаимодействие с одним ресурсом, расположенный выше уровень содержит протоколы и службы, которые не ассоциированы с каким - либо одним заданным ресурсом, а скорее являются глобальными по природе и охвату взаимодействий на всём множестве ресурсов. По этой причине следующий слой архитектуры называется уровнем Кооперации(Collectivelayer). Компоненты уровня Кооперации могут реализовать широкое разнообразие режимов, не предъявляя новых требований к разделяемым ресурсам. Например:

• Службы каталогов (directoryservices) позволяют членам ВО обнаруживать зарегистрированные обобществлённые и/или частные ресурсы. Служба каталогов даёт возможность её пользователям запрашивать ресурсы, указывая их имена и/или атрибуты такие как тип, доступность или загруженность.

• Службы совместного одновременного распределения, планирования и заказа ресурсов (co-allocation, schedulingandbrokeringservices) позволяют участникам ВО запрашивать один или больше ресурсов для конкретной цели и планировать решение задач на соответствующих ресурсах.

• Службы мониторинга и диагностики (monitoringanddiagnosticsservices) осуществляют мониторинг ресурсов ВОдля выявления отказов, вторжения (“intrusiondetection”), перегрузки и т.д.

• Службы репликации данных (datareplicationservices) поддерживают управление ресурсами хранения ВО (также возможно, сетевыми и вычислительными) для достижения максимальной производительности при доступе к данным с учётом, например, таких показателей, как время ответа, надёжность и стоимость.

• Системы программирования для грид (grid-enabledprogrammingsystems) дают возможность использовать в грид-среде известные модели программирования. При этом для решения вопросов, касающихся обнаружения и распределения ресурсов, безопасности и других используются различные грид-службы.

• Системы управления заданиями (workloadmanagementsystems) и инфраструктура взаимодействия (collaborationframeworks) – также известные, как среды решения задач (problemsolvingenvironments – “PSEs”) - предназначены для описания, использования и управления многоэтапными, асинхронными и многокомпонентными потоками работ.

• Службы обнаружения программного обеспечения (softwarediscoveryservices), используя параметры решаемой задачи находят и выбирают наилучшие для этой задачи реализацию программного обеспечения и исполнительную платформу.

• Серверы групповой авторизации (communityauthorizationservers) проводят в жизнь политики группового доступа к ресурсам, выдавая мандаты, которые члены группы могут использовать для доступа к групповым ресурсам. Используя информацию о ресурсах и протоколы управления ресурсами (на уровне Ресурсов) и безопасности, эти серверы обеспечивают глобальную, жёсткую политику обслуживания.

• Службы учёта использования и оплаты ресурсов (communityaccountingandpaymentservices) собирают вместе информацию о ресурсах для учёта их использования, платежах за ресурсы и/или ограничения на использование ресурсов членами группы.

• Службы взаимодействия (collaborationservices) поддерживают согласованный синхронный или асинхронный обмен информацией внутри потенциально больших групп пользователей.

Эти примеры иллюстрируют широкое разнообразие протоколов уровня Кооперации и служб, применяемых на практике. Заметим, что в то время, как протоколы уровня Ресурсов по своей природе должны быть общими и широко распространёнными, протоколы уровня Кооперации охватывают спектр от решений общего характера до исключительно специальных или зависящих от конкретной предметной области, причём последние, возможно, интересны только внутри конкретных ВО.

Прикладной уровень

Последний уровень обсуждаемой грид-архитектуры – уровень Приложений(Applicationslayer) - содержит пользовательские программные приложения, которые применяются в среде ВО. Приложения конструируются в терминах обращений к службам, определённым на любом уровне архитектуры. На каждом уровне чётко определены протоколы, которые обеспечивают доступ к нескольким полезным службам: управлению ресурсами, доступа к данным, обнаружения ресурсов и так далее. Также на каждом уровне для интерфейсов API’s может быть установлено, какая реализация протокола обмена информацией посылает соответствующим службам сообщения для выполнения желаемых действий.

4. Понятие о виртуальной организации

Инфраструктура Грид основана на предоставлении ресурсов в общее пользование, с одной стороны, и на использовании публично доступных ресурсов, с другой. В этом плане ключевое понятие инфраструктуры Грид – виртуальная организация, в которой кооперируются как потребители, так и владельцы ресурсов. Мотивы кооперации могут быть разными. В существующих Грид-системах виртуальная организация представляет собой объединение (коллаборацию) специалистов из некоторой прикладной области, которые объединяются для достижения общей цели.

Любая ВО располагает определенным количеством ресурсов, которые предоставлены зарегистрированными в ней владельцами (некоторые ресурсы могут одновременно принадлежать нескольким ВО). Каждая ВОсамостоятельно устанавливает правила работы для своих участников, исходя из соблюдения баланса между потребностями пользователей и наличным объемом ресурсов, поэтому пользователь должен обосновать свое желание работать с Грид-системой и получить согласие управляющих органов ВО.

Грид-система является средой коллективного компьютинга, в которой каждый ресурс имеет владельца, а доступ к ресурсам открыт в разделяемом по времени и по пространству режиме множеству входящих в ВО пользователей. Виртуальная организация может образовываться динамически и иметь ограниченное время существования.

К настоящему времени существует множество ВО, входящих в различныеГрид-системы. Примерами ВО, действующих в рамках проекта LCG-2 (Грид для обработки данных с ускорителя LHC), являются ВО экспериментов, которые планируется проводить на этом ускорителе: ATLAS, CMS, Alice, LHCb.

5. Распределение ресурсов в Грид

Эффективное распределение ресурсов и их координация являются основными задачами системы Грид, и для их решения используется планировщик (брокер ресурсов). Пользуясь информацией о состоянии Грид-системы, планировщик определяет наиболее подходящие ресурсы для каждой конкретной задачи и резервирует их для ее выполнения. Во время выполнения задача может запросить у планировщика дополнительные ресурсы или освободить избыточные. После завершения задачи все отведенные для нее вычислительные ресурсы освобождаются, а ресурсы памяти могут быть использованы для хранения результатов работы.

Важным свойством систем Грид является то, что пользователю не нужно знать о физическом расположении ресурсов, отведенных его задаче. Вся работа по управлению, перераспределению и оптимизации использования ресурсов ложится на планировщик и выполняется незаметно для пользователя. Для пользователя создается иллюзия работы в едином информационном пространстве, обладающем огромными вычислительными мощностями и объемом памяти.

Грид является наиболее сложной информационной средой, когда-либо создаваемой человеком. Для системы такой сложности очень важна проблема обеспечения надежного функционирования и восстановления при сбоях. Человек не способен уследить за состоянием тысяч различных ресурсов, входящих в Грид-систему, и по этой причине задача контроля над ошибками возлагается на систему мониторинга, которая следит за состоянием отдельных ресурсов. Данные о состоянии заносятся в информационные ресурсы, откуда они могут быть прочитаны планировщиком и другими сервисами, что позволяет иметь постоянно обновляющуюся достоверную информацию о состоянии ресурсов.

В Грид-системах используется сложная система обнаружения и классификации ошибок. Если ошибка произошла по вине задачи, то задача будет остановлена, а соответствующая диагностика направлена ее владельцу (пользователю). Если причиной сбоя послужил ресурс, то планировщик произведет перераспределение ресурсов для данной задачи и перезапустит ее.

Сбои ресурсов являются не единственной причиной отказов в Грид-системах. Из-за огромного количества задач и постоянно меняющейся сложной конфигурации системы важно своевременно определять перегруженные и свободные ресурсы, производя перераспределение нагрузки между ними. Перегруженный сетевой ресурс может стать причиной отказа значительного количества других ресурсов. Планировщик, используя систему мониторинга, постоянно следит за состоянием ресурсов и автоматически принимает необходимые меры для предотвращения перегрузок и простоя ресурсов.

В распределенной среде, какой является Грид-система, жизненно важным свойством является отсутствие так называемой единственной точки сбоя. Это означает, что отказ любого ресурса не должен приводить к сбою в работе всей системы. Именно поэтому планировщик, система мониторинга и другие сервисы Грид-системы распределены и продублированы. Несмотря на всю сложность, архитектура Грид разрабатывалась с целью обеспечить максимальное качество сервиса для пользователей. В Грид-системах используются современные технологии передачи данных, обеспечения безопасности и отказоустойчивости.

Cистема BOINC

В качетсве примера системы с вертикальной интеграции расмотрим програмную платформу BOINC для организации добровольных вычислений.

BOINC (англ. Berkeley Open Infrastructure for Network Computing) – открытая программная платформа (университета) Беркли для GRID вычислений) — некоммерческое межплатформенное ПО для организации распределённых вычислений. Используется для организации добровольных вычислений.Состоит из серверной и клиентской частей. Первоначально разрабатывался для крупнейшего проекта добровольных вычислений — SETI@home, но впоследствии разработчики из Калифорнийского университета в Беркли сделали платформу доступной для сторонних проектов. На сегодняшний день BOINC является универсальной платформой для проектов в области математики, молекулярной биологии, медицины, астрофизики и климатологии. BOINC даёт исследователям возможность задействовать огромные вычислительные мощности персональных компьютеров со всего мира. BOINC разработан командой во главе с Дэвидом Андерсоном (David Pope Anderson), возглавляющим также SETI@home, из Space Sciences Laboratory Калифорнийского университета в Беркли. На 2 февраля 2011 BOINC являет собой распределённую сеть из более чем 490’000 активных компьютеров (хостов) со средней производительностью, равной 5’000 TeraFLOPS. Платформа работает на различных операционных системах, включая Microsoft Windows и варианты юниксоподобных GNU/Linux, FreeBSD, NetBSD, OpenBSD, Solaris и Mac OS X. BOINC распространяется под лицензией GNU Lesser General Public License, как свободное программное обеспечение с открытым исходным кодом.[википедия ололо]

Архитектура системы BOINC

Особенность «volunteer computing» заключается в том, что для успешного решения отдельные небольшие подзадачи должны быть очень слабо связаны между собой и практически не зависеть от результатов параллельно выполняемых заданий. В противном случае очень большие издержки производительности будут приходиться на ожидание других результатов и на их синхронизацию. Идеальной задачей является, например, подбор пароля методом «грубой силы» – для каждого варианта (десятка, сотни – в зависимости от сложности вычисления) пароля отдельный компьютер вычисляет хэш и сравнивает его с заданным. Первое совпадение – задача решена, но никакой другой результат не может приблизить к правильному ответу, а подзадачи абсолютно независимы (в силу свойств парольных хэш-функций). Под такие задачи, состоящие из независимых подзадач, и разработана архитектура системы BOINC(рис.4).

Рис.4 Архитектура системы BOINC

Основа архитектуры BOINC – сервер состоящий из набора отдельных подсистем, каждая из которых отвечает за свою вполне определенную задачу, например, выполнение вычислений, передачу файлов и т.д. Каждая из подсистем проверяет состояние подзадачи, производит какие-то действия и изменяет состояние подзадачи – так они работают в бесконечном цикле. В корне системы лежит принцип конечного автомата.

Конечный автомат (в теории алгоритмов) – это математическая абстракция, позволяющая описывать пути изменения состояния объекта в зависимости от его текущего состояния и входных данных при условии, что общее возможное число состояний конечно. Конечный автомат является частным случаем абстрактного автомата. Конечный автомат может быть детерминированным или недетерминированным в зависимости от того, имеется ли один или несколько вариантов его поведения на каком-то шаге.

Формально конечный автомат определяется следующей пятеркой объектов:

M=(Σ,Q,F,s,π), где

Σ – допустимый входной алфавит (конечное множество допустимых входных символов);

Q – конечное множество состояний автомата;

F – множество заключительных состояний автомата, являющееся подмножеством множества Q;

s – начальное состояние автомата;

π – отображение множества Σ на множество Q (функция перехода).

Автомат начинает работу в состоянии s, считывая по одному символы входной строки. Считанный символ переводит автомат в новое состояние из F, в соответствии с функцией переходов π. Процесс продолжается до тех пор, пока не будет достигнуто одно из состояний F. Если по завершении считывания входного слова (цепочки символов) автомат оказывается в одном из допускающих состояний, то слово "принимается" автоматом. В этом случае говорят, что оно принадлежит языку данного автомата. В противном случае слово "отвергается".

Конечные автоматы широко используются на практике, например в синтаксических и лексических анализаторах, а также в других случаях, когда число состояний объекта и переходов между ними сравнительно невелико.

В целом, система состоит из сервера BOINC (при необходимости, распределенного на несколько физических серверов в целях повышения производительности, отказоустойчивости и безопасности), множества клиентов, выполняющих задания сервера и, возможно, дополнительных компонент в виде присоединенных GRID-сетей (например, на основе широко распространенного инструментария Globus Toolkit )

Globus Toolkit – это открытый (Open Source) инструментарий для создания вычислительных Grid. Включает в себя набор программных сервисов и библиотек для проведения мониторинга ресурсов, обнаружения и управления вычислительными узлами, обеспечения безопасности и управления файлами. Разрабатывается и поддерживается организацией Globus Alliance.

Сервер BOINC состоит из:

• как минимум одного Web-сервера, который обрабатывает входящие и исходящие сообщения;
• сервера баз данных, который отслеживает состояние подзадач и соответствующие им результаты, а также хранит информацию о клиентах и набранных ими баллах;
• пяти различных демонов, которые периодически проверяют состояние базы данных и выполняют необходимые работы по обслуживанию системы и распределению подзадач.

Как уже говорилось, все эти программы могут быть запущены как на одном физическом сервере, так и на нескольких. Решение, создавать ли распределенный сервер BOINC, безусловно, зависит от нагрузки и требований по отказоустойчивости.

Далее подробно о компонентах, составляющих сервер BOINC.

Web-сервер

Строго говоря, Web-сервер не является необходимой частью инфраструктуры сервера BOINC. Однако его наличие обусловлено самой сущностью «volunteer computing» – для того, чтобы привлечь участников к своему проекту, вы должны хоть чем-то заинтересовать их. Именно для этого нужен сайт, рассказывающий о том, насколько важное дело для всего человечества вы – а, значит, и присоединившиеся к вам добровольцы – выполняете: ищете внеземные цивилизации (как давно люди мечтают увидеть пришельцев! – SETI@HOME), разрабатываете новые лекарственные препараты (на благое дело не жалко отдать простаивающий процессор – Docking@Home) или предсказываете погоду (ну когда же прогнозы, наконец, будут совпадать с реальностью? – ClimatePrediction.net)... Расскажите о своем проекте – этим вы сможете привлечь единомышленников! Каждый проект распределенных вычислений на базе BOINC предоставляет своим участникам возможность объединиться в команды (например, в команду Linux-пользователей, чтобы насладиться более высокой строчкой рейтинга, чем у команды Windows-пользователей) и следить за увеличением числа набранных баллов... Учитывая, что роль сайта в работе BOINC-проекта все-таки является второстепенной, Web-сервер является первым кандидатом на «отселение» на соседний физический сервер. Однако необходимо помнить, что для демонстрации актуальных цифр статистики Web-сервер должен иметь связь с базой данных сервера BOINC.

База данных

Демон

Демон – это компьютерная программа, работающая в фоновом режиме без взаимодействия с пользователем. Наиболее широко этот термин употребляется в UNIX-подобных системах. Как правило, в виде демонов реализуются серверные программы, например, Web-сервер, ftp-сервер и т.д.

База данных – это основа всего проекта BOINC, в ней хранится вся информация, относящаяся к серверу BOINC, включая сведения о зарегистрированных пользователях и связанных с ними хостами, о приложениях и версиях приложений, о клиентах BOINC и их версиях, а также о подзадачах и результатах вычислений. К этой информации обращаются (как для чтения, так и для внесения изменений) специальные служебные программы сервера. Система BOINC изначально ориентирована на работу с СУБД MySQL, которая в будущем подойдет и для нашего тестового проекта распределенных вычислений. Учитывая, что вся нагрузка, связанная с активным обменом информацией в рамках проекта BOINC, возложена на базу данных, именно она, как правило, и является тем самым «бутылочным горлышком» производительности сервера.