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

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

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

Grid, Грид

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

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

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

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

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

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

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

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

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

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

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

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

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

Мост (Bridge)

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

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

Приложения BOINC

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

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

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

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

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

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

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

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

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

В начало

Заключение

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