Распределенные вычисления: Часть 4. Проект BOINC изнутри
Введение
Новая статья продолжает серию, посвященную распределенным вычислениям на основе платформы BOINC. В первой статье рассказывалось о том, что такое распределенные вычисления и как выглядит проект BOINC с точки зрения пользователя. Следующая статья описывает принципы работы сервера BOINC и его архитектуру. Наконец, в третьей статье представлены инструкции и дополнительная информация, касающаяся установки собственного сервера проектов распределенных вычислений на базе платформы BOINC.
В этой статье мы более подробно обсудим результаты, полученные в предыдущей статье, и рассмотрим созданный BOINC-проект «изнутри».
Статья рассчитана на администратора проекта BOINC – для управления большим и сложным проектом необходимо хорошо понимать его внутреннюю структуру и механизмы работы. Это позволит и оперативнее, и с лучшим результатом справляться с неизбежно возникающими неожиданными сложностями.
Структура каталогов
Прежде всего начнем с файлов и каталогов, которые были автоматически созданы скриптом make_project. В таблице 1 вы увидите список файлов и каталогов (первого уровня), появившихся при инициализации проекта. Столбец «назначение» поможет понять, для чего служит тот или иной файл/каталог.
Таблица 1. Назначение файлов и каталогов BOINC-проекта
Как видите, файлы и каталоги, необходимые для функционирования проекта, перемешаны с используемыми для административных задач. Однако это не составляет большой проблемы, так как управление проектом обычно не требует прямого обращения к каким-либо файлам, а вынесено в Web-интерфейс.
Из всего проекта в отдельный каталог выделены файлы, относящиеся к Web-сайту проекта – о нем мы поговорим подробнее в следующей статье.
База данных
База данных – это основа всего проекта BOINC. В базе данных хранится вся используемая в проекте информация, включая сведения о зарегистрированных командах, пользователях и связанных с ними компьютерах, об имеющихся приложениях и их версиях, об используемых пользователями клиентах BOINC и, самое важное, – информация о текущих подзадачах и результатах вычислений.
Рассмотрим подробнее структуру базы данных. Для этого соединимся с mysql от имени пользователя root:
boincadm@boincserver:~/projects/myapp> mysql -u root -p
После ввода пароля нужно выбрать базу данных, соответствующую нашему проекту:
mysql> use myapp;
Список таблиц выбранной базы данных можно просмотреть командой
mysql> show tables;
Вы получите следующий результат:
Tables_in_myapp +-------------------+ app app_version assignment banishment_vote banishment_votes category credit_multiplier credited_job donation_items donation_paypal forum forum_logging forum_preferences friend host msg_from_host msg_to_host notify platform post post_ratings private_messages profile result sent_email state_counts subscriptions team team_admin team_delta thread user workunit
Всего база данных содержит 33 таблицы. Из них большая часть – это вспомогательные таблицы, не требующиеся непосредственно для функционирования проекта: информация о пользователях и командах (user, team, team_admin и др.), начисленных очках (credited_job), пожертвованиях проекту (donation_paypal, donation_items), таблицы, необходимые для работы форума (forum, forum_loggin, forum_preferences и др.) и т.д.
Однако для администратора проекта наиболее интересны будут те таблицы базы данных, которые относятся непосредственно к работе проекта и проводимым вычислениям. Далее будет подробно рассказано об этих таблицах.
Таблица app
Первая из таблиц (которую мы рассмотрим наиболее подробно), необходимых непосредственно для работы приложения, – это таблица app, в ней хранится информация о приложениях, используемых в рамках проекта.
mysql> SELECT * FROM app;
Поле create_time встречается и во многих других таблицах – это дата создания записи (по времени POSIX – см. врезку). Поле deprecated также будет не раз появляться – оно говорит о том, является ли значение неиспользуемым (соответственно, 0 указывается для активной записи, а ненулевое значение – для неактивной). Значение min_version задает минимально необходимую версию клиента BOINC для участия в вычислениях.
*UNIX-время или POSIX-время (англ. Unix time) – система описания моментов во времени, принятая в UNIX и других POSIX-совместимых операционных системах.
Моментом начала отсчета считается полночь (по UTC) с 31 декабря 1969 года на 1 января 1970 года, время с этого момента называют «эрой UNIX» (англ. Unix Epoch).
Способ хранения времени в виде количества секунд очень удобно использовать при сравнении дат (с точностью до секунды), а также для хранения дат: при необходимости их можно преобразовать в любой удобочитаемый формат. Дата и время в этом формате также занимают очень мало места (4 или 8 байтов, в зависимости от размера машинного слова), поэтому его разумно использовать для хранения больших объемов дат. Недостатки в производительности могут проявиться при очень частом обращении к элементам даты, вроде номера месяца и т. п. Но в большинстве случаев эффективнее хранить время в виде одной величины, а не набора полей.
Чтобы узнать текущее UNIX-время в большинстве UNIX-подобных систем, можно использовать команду date +%s.
Особого внимания заслуживает поле homogeneous_redundancy, отражающее специфику высокопроизводительных приложений. Дело в том, что большинство приложений, активно использующих вычисления, выдают различные результаты для одного и того же задания в зависимости от архитектуры компьютера, используемой операционной системы, флагов компилятора и самого компилятора. Для одних приложений эта разница незначительна, и полученные результаты могут сравниваться с помощью функций нечеткой логики (см. врезку) или просто с учетом погрешности. Однако в некоторых случаях небольшие различия в исходных вычислениях могут привести к значительно отличающимся результатам.
*Нечеткая логика и теория нечетких множеств – раздел математики, являющийся обобщением классической логики и теории множеств. Понятие нечеткой логики было впервые введено профессором Лютфи Заде в 1965 г.
Характеристикой нечеткого множества выступает функция принадлежности. Обозначим через MFc(x) степень принадлежности к нечеткому множеству C. Тогда нечетким множеством С называется множество упорядоченных пар вида C={MFc(x)/x}, MFc(x) [0,1]. Значение MFc(x)=0 означает отсутствие принадлежности к множеству, 1 – полную принадлежность.
Проиллюстрируем это на простом примере. Формализуем неточное определение «горячий чай». В качестве x (область рассуждений) будет выступать шкала температуры в градусах Цельсия. Очевидно, что она изменяется от 0 до 100 градусов. Нечеткое множество для понятия «горячий чай» может выглядеть следующим образом:
C={0/0; 0/10; 0/20; 0,15/30; 0,30/40; 0,60/50; 0,80/60; 0,90/70; 1/80; 1/90; 1/100}.
Так, чай с температурой 60○С принадлежит к множеству «Горячий» со степенью принадлежности 0,80. Для одного человека чай при температуре 60○С может оказаться горячим, для другого – не слишком горячим. Именно в этом и проявляется нечеткость задания соответствующего множества.
Для нечетких множеств, как и для обычных, определены основные логические операции. Самыми основными, необходимыми для расчетов, являются пересечение и объединение.
Для решения этой проблемы платформа BOINC предоставляет возможность использования однородных вычислителей (homogeneous redundancy – HR). HR разделяет все компьютеры, участвующие в вычислениях в рамках проекта, на «классы эквивалентности»: два хоста принадлежат одному классу, если возвращают одинаковые результаты для одного и того же рабочего задания. Если включены однородные вычисления, то планировщик BOINC отсылает одинаковые рабочие задания хостам из одного и того же класса.
Однородные вычисления включаются для проекта строкой
<homogeneous_redundancy>N</homogeneous_redundancy>
в файле config.xml. Тип HR (значение N) задается значением из таблицы 2.
Таблица 2. Классы однородных вычислителей
Однородные вычисления можно также включить для отдельного приложения, а не для всего проекта – для этого необходимо внести изменения в поле homogeneous_redundancy таблицы app.
Поле weight таблицы app указывает на то, какое количество рабочих заданий этого приложения передается на обработку; имеет смысл лишь при работе нескольких приложений в рамках одного проекта.
Поле beta указывает, является ли приложение бета-версией.
Наряду с homogeneous_redundancy, особый интерес – как отражающее внутреннюю специфику платформы BOINC – представляет поле target_nresults. По умолчанию BOINC дублирует рабочие задания и сверяет результаты, полученные от разных хостов. Это делается, во-первых, для гарантирования достоверности результатов, а во-вторых, для того, чтобы задание не «пропало», если пользователь хоста вышел из проекта (или хост по каким-то другим причинам стал недоступен или не может продолжать вычисления). Однако такая политика приводит к большим потерям в производительности, так как не менее 50% всего машинного времени тратится на дублирование работы. Эти потери могут быть существенными для проектов с небольшим числом участников или для проектов с огромными объемами требуемых вычислений.
Для решения этой проблемы создателями платформы BOINC разработан механизм адаптивной дублируемости заданий. Заключается он в следующем.
В рамках проекта BOINC ведется список доверительных хостов – хостов, имеющих хорошую «репутацию». Каждому компьютеру, участвующему в вычислениях, назначается рейтинг (являющийся обратно пропорциональным степени доверия этому компьютеру). Изначально рейтинг равен 0.1. Каждый присланный хостом верный результат (подтвердившийся другими хостами) умножает рейтинг на 0.95. Каждый неверный результат сбрасывает рейтинг на 0.1. Если рейтинг хоста меньше заданного числа А, то рабочее задание, отправляемое этому хосту, не дублируется, а полученный затем результат будет считаться верным без проведения процедуры голосования (о процедуре голосования рассказывалось в первой статье серии – см. раздел «Ссылки», п. 1). Значение числа А задается в исходном коде сервера BOINC и равняется 0.05 (если это значение потребуется поменять – ищите его в файле sched_send.cpp под именем ER_MAX). Таким образом, хост может стать доверенным, прислав не менее 14 верных результатов подряд.
Для включения механизма адаптивной дублируемости заданий необходимо изменить значение поля target_nresults на ненулевое и указать в шаблоне рабочего задания следующие значения:
<target_nresults>1</target_nresults> <min_quorum>1</min_quorum>
Таблица app_version
Эта таблица содержит описания версий приложений. Каждая запись содержит адрес URL и хеш MD5 исполняемого файла. Практически вся необходимая информация о приложении содержится в поле xml_doc таблицы в виде xml-документа:
<file_info>
<name>uppercase_1.0_i686-pc-linux-gnu</name>
<url>http://boinc.domain.ru/myapp/download/uppercase_1.0_i686-pc-linux-gnu</url>
<executable/>
<file_signature>...</file_signature>
<nbytes>508022.000000</nbytes>
</file_info>
<app_version>
<app_name>uppercase</app_name>
<version_num>100</version_num>
<api_version>6.11.0</api_version>
<file_ref>
<file_name>uppercase_1.0_i686-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
</app_version>
Таблица workunit
В этой таблице – как несложно догадаться – хранится информация, относящаяся к рабочим заданиям. Описание входного файла хранится в XML-документе:
<name>in</name>
<url>http://boinc.domain.ru/myapp/download/3e9/in</url>
<md5_cksum>...</md5_cksum>
<nbytes>14</nbytes>
</file_info>
<workunit>
<file_ref>
<file_name>in</file_name>
<open_name>in</open_name>
</file_ref>
</workunit>
Таблица содержит довольно много полей, но самые важные из них содержат данные о результатах, связанных с конкретным рабочим заданием: шаблон, число полученных результатов, число результатов, прошедших проверку удачно и неудачно.
Ряд полей таблицы описывают ресурсы, необходимые для выполнения рабочего задания: rsc_fpops_est – это оценка количества операций, необходимых для получения результата; если число операций превысило значение rsc_fpops_bound, то приложение принудительно завершается; для выполнения рабочего задания хост должен иметь достаточные ресурсы по оперативной памяти (rsc_memory_bound), свободному дисковому пространству (rsc_disk_bound) и скорости доступа в Интернет (rsc_bandwidth_bound).
Таблица result
Аналогично таблице workunit, существует и таблица result, описывающая результаты вычислений по конкретным рабочим заданиям (третье поле таблицы – workunitid – связывает результат и рабочее задание). Кроме всего прочего, хранятся и значения, необходимые для начисления кредитов (запрашиваемое и начисленное число кредитов: claimed_credit, granted_credit, cpu_time), необходимые для определения статуса завершения задания (server_state, client_state, exit_status, file_delete_state, validate_state) и временные метки (report_deadline, sent_time, received_time).
Таблица platform
Наконец, последняя рассматриваемая нами таблица – это таблица platform. В ней указываются программно-аппаратные платформы, «известные» проекту. Таблица заполняется утилитой xadd (подкаталога bin каталога проекта) на основе файла project.xml (в прошлой статье мы говорили об этом файле и рассматривали его содержимое).
Если вы не изменяли файл project.xml, то в таблице platform увидите следующее:
mysql> SELECT * FROM platform;
Заключение
Руководство проектом распределенных вычислений – это ответственная и непростая работа, требующая глубокого понимания процессов, происходящих во время штатной работы сервера. Цель этой статьи – дать направление и основные «вехи» для всестороннего и подробного исследования платформы BOINC. В статье были рассмотрены основные внутренние объекты проекта BOINC, составляющие структуру каталогов и базу данных каждого проекта.
В следующей статье мы продолжим исследование платформы BOINC, перейдя от «внутреннего администрирования» к «внешнему»: объектом изучения послужит Web-интерфейс администрирования проекта.
Статья взята с http://www.ibm.com