**Распределенные вычисления: Часть 4. Проект BOINC изнутри**

**Введение**

Новая статья продолжает серию, посвященную распределенным вычислениям на основе платформы BOINC. В [[ru:chast_1|первой статье]] рассказывалось о том, что такое распределенные вычисления и как выглядит проект BOINC с точки зрения пользователя. [[ru:chast_2|Следующая статья]]  описывает принципы работы сервера BOINC и его архитектуру. Наконец, в [[ru:chast_3|третьей статье]] представлены инструкции и дополнительная информация, касающаяся установки собственного сервера проектов распределенных вычислений на базе платформы BOINC.

В этой статье мы более подробно обсудим результаты, полученные в предыдущей статье, и рассмотрим созданный BOINC-проект «изнутри».

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

**Структура каталогов**

Прежде всего начнем с файлов и каталогов, которые были автоматически созданы скриптом //make_project//. В таблице 1 вы увидите список файлов и каталогов (первого уровня), появившихся при инициализации проекта. Столбец «назначение» поможет понять, для чего служит тот или иной файл/каталог.

''**Таблица 1. Назначение файлов и каталогов BOINC-проекта**''

{{:ru:chast_4_folder_structure.png|}}

Как видите, файлы и каталоги, необходимые для функционирования проекта, перемешаны с используемыми для административных задач. Однако это не составляет большой проблемы, так как управление проектом обычно не требует прямого обращения к каким-либо файлам, а вынесено в 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;**

{{:ru:chast_4_mysql_apps.png|}}

Поле //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. Классы однородных вычислителей**

{{:ru:chast_4_homogenous_redundancy_classes.png|}}

Однородные вычисления можно также включить для отдельного приложения, а не для всего проекта – для этого необходимо внести изменения в поле 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;**

{{:ru:chast_4_mysql_platforms.png|}}

**Заключение**

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

В следующей статье мы продолжим исследование платформы BOINC, перейдя от «внутреннего администрирования» к «внешнему»: объектом изучения послужит Web-интерфейс администрирования проекта.

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