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

Демон

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

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

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

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

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

Grid, Грид

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

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

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

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