Распределенные вычисления: Часть 2. Архитектура высокопроизводительных вычислений на базе BOINC

1. Введение

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

Материал следующей статьи будет широко опираться на информацию, представленную здесь – теоретические знания по архитектуре и организации работы серверной части системы BOINC понадобятся для развертывания полноценного сервера «volunteer computing» и решения первой задачи с помощью технологии распределенных вычислений.

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

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

На рисунке 1 представлена архитектура системы BOINC.

Рисунок 1. Архитектура системы BOINC

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

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

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

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

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

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

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

2.1. Web-сервер

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

2.2. База данных

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

2.3. Служба обработки состояния подзадач (Transitioner)

Эта служба (вообще-то демон согласно терминологии UNIX, но мы будем называть эти выполняющиеся в фоновом режиме не интерактивные служебные программы службами, чтобы статья не попала в раздел «фэнтези») предназначена для обработки состояния вычислительных подзадач и результатов их решения. Она не зависит от приложения и является одинаковой для всех проектов – будь то предсказание погоды или поиск внеземных цивилизаций. Служба обработки проверяет текущее состояние подзадачи в базе данных и обновляет соответствующие поля, когда подзадача готова перейти в новое состояние. Сложность заключается в том, что подзадачи имеют не состояния как таковые, а наборы «подсостояний». Эти подсостояния включают в себя также состояния соответствующих результатов вычислений. Например, если результаты готовы к проверке и к этому моменту достаточно данных для организации проверки кворумом (о кворуме проверки результатов говорилось в прошлой статье – см. п. 1 раздела «Ссылки»), то состояние подзадачи меняется на «готова к проверке». Служба обработки является одной из наиболее ресурсоемких с точки зрения нагрузки на процессор, поэтому она может быть разделена на несколько процессов, каждый из которых отвечает за определенный набор подзадач. Соответственно, эти процессы могут работать на различных физических серверах.

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

2.4. Служба проверки результатов (Validator)

Назначение службы – организация проверки полученных результатов. Как говорилось в прошлой статье, в целях обеспечения достоверности каждая из подзадач рассчитывается на нескольких различных клиентах. Поэтому полученные в итоге результаты необходимо проверить, сверив между собой и определив «каноническое» решение – результат, полученный кворумом клиентов. При этом алгоритм проверки результатов целиком зависит от решаемой задачи – где-то достаточно удостовериться в равенстве двух чисел (с точностью до третьего знака), а где-то необходимо поэлементно сравнить с десяток матриц… Вот за реализацию этого алгоритма проверки результата и отвечает служба. Кроме того, программа проверки может следить за правдоподобностью результатов. Например, если моделируется падение тела под воздействием силы тяжести, можно проверить, не является ли конечная точка выше над землей, чем начальная. Такое никогда не может случиться, а значит, свидетельствует об ошибке в результате. Следовательно, такие результаты являются заведомо неправильными и не должны приниматься во внимание.

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

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

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

2.5. Служба освоения (Assimilator)

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

2.6. Служба удаления файлов (File deleter)

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

2.7. Служба подачи (Feeder)

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

2.8. Планировщик (Scheduler)

Планировщик – это CGI-программа, которая запускается, когда к серверу проекта подсоединяется клиент и запрашивает порцию заданий. Вместо запроса к БД планировщик получает задания из сегмента разделяемой памяти, в который задания загружает служба подачи. Планировщик имеет возможности по самостоятельному назначению подзадач клиентам, так как не все клиенты имеют одинаковые настройки и компьютеры. Например, один пользователь может иметь Linux-версию клиента и выделить 100 MБ дискового пространства и 200 MБ оперативной памяти, а другой клиент может запустить только Windows-версию и разрешить использование не более 10 MБ дискового пространства и 10 MБ оперативной памяти. В этом случае планировщик принимает решение о назначении более вычислительно-емкого задания Linux-клиенту, оставляя наиболее простые подзадачи «слабому» Windows-клиенту.

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

2.9. Мост (Bridge)

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

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

2.10. Приложения BOINC

Теперь остановимся немного подробнее на особенностях приложений, реализуемых в рамках проекта BOINC. Естественно, что для отсылки заданий клиентам должно быть разработано и запущено как минимум одно приложение BOINC. После создания проекта в форме исполняемого файла, он должен быть зарегистрирован на сервере BOINC, и администратор может начать создавать подзадачи для этого приложения. Это значит, что подзадачи изначально являются не более чем описанием входящих файлов. Если проект должен быть запущен для вычисления на различных платформах, то должна быть реализована и зарегистрирована версия для каждой из этих платформ.

Для того чтобы какая-то программа была приложением BOINC, она должна вызывать специальные функции BOINC API, которые реализованы на языке C. В частности, каждое приложение BOINC должно вызывать специальные функции в начале и конце программы: функцию инициализации и функцию завершения. Между этими двумя функциями приложение BOINC должно также вызывать функции, говорящие клиенту о стадии выполнения подзадания (в процентах), чтобы пользователь мог видеть прогресс вычислений. Некоторые пользователи также ожидают, что приложение BOINC будет демонстрировать какие-то картинки, поэтому необходимо вызывать функции рисования, если клиентское приложение запрашивает отображение графики.

Если приложение использует входные или не являющиеся временными выходные файлы, то их имена должны быть преобразованы перед открытием с помощью специальной функции BOINC API. Это необходимо для тех приложений, которые запускаются с большим количеством различных входных файлов и генерируют большое количество различных выходных файлов. Если все файлы при каждом запуске имеют одно и то же имя, то при новом запуске потребуется создать отдельные каталоги на сервере и на клиенте для предотвращения конфликтов имен. Так как приложение остается тем же при разных запусках, невозможно сменить имена внутри приложения и совсем непрактично каждый раз перекомпилировать приложение. Все это приводит к тому, что приложение работает с логическими именами файлов и эти имена файлов транслируются клиентом в физические имена при запуске. Физические имена файлов определяются только при создании подзадачи.

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

2.11. Жизненный цикл задания

Жизненный цикл задания и связанных с ним подзаданий выглядит следующим образом (рисунок 2):

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

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

Рисунок 2. Жизненный цикл задания

Заключение

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

Статья взята с http://www.ibm.com