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

Узнайте, как устроен проект распределенных вычислений, основанный на платформе BOINC

Развертывание и запуск собственного полноценного сервера распределенных вычислений на платформе BOINC

Евгений Ивашко, Сотрудник Института РАН, Институт прикладных математических исследований Карельского научного центра РАН.

Сотрудник Института прикладных математических исследований Карельского научного центра РАН. Имеет степень магистра математики.



17.11.2011

Введение

POSIX-время

UNIX-время или POSIX-время (англ. Unix time) – система описания моментов во времени, принятая в UNIX и других POSIX-совместимых операционных системах.

Моментом начала отсчета считается полночь (по UTC) с 31 декабря 1969 года на 1 января 1970 года, время с этого момента называют «эрой UNIX» (англ. Unix Epoch).

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

Чтобы узнать текущее UNIX-время в большинстве UNIX-подобных систем, можно использовать команду date +%s.

http://ru.wikipedia.org/wiki/Время_UNIX

Новая статья продолжает серию, посвященную распределенным вычислениям на основе платформы BOINC. В первой статье (см. раздел "Ссылки", п. 1) рассказывалось о том, что такое распределенные вычисления и как выглядит проект BOINC с точки зрения пользователя. Следующая статья (см. раздел "Ссылки", п. 2) описывает принципы работы сервера BOINC и его архитектуру. Наконец, в третьей статье (см. раздел "Ссылки", п. 3) представлены инструкции и дополнительная информация, касающаяся установки собственного сервера проектов распределенных вычислений на базе платформы BOINC.

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

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

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

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

Таблица 1. Назначение файлов и каталогов BOINC-проекта
Имя каталога/файлаНазначение
apps/В этом каталоге размещаются исполняемые файлы (для различных платформ) и файлы ресурсов, которые передаются на клиентские компьютеры для выполнения расчетов.
config.xmlБазовые настройки проекта.
download/В этом каталоге должны находиться исходные файлы, необходимые для выполнения расчетов.
local.revision, db_revisionФайлы содержат номера ревизий и служат для проверки необходимости установки обновлений.
py/В подкаталоге Boinc содержатся модули на языке Python (например, такие как configxml.py, предназначенный для чтения и обработки файла настроек config.xml).
bin/В каталоге содержатся служебные утилиты проекта, такие как, например, упоминавшиеся в прошлой статье xadd, create_work и start.
db_dump_spec.xmlФайл настроек, определяющий формат вывода утилиты db_dump (находится в подкаталоге bin каталога проекта). В свою очередь утилита db_dump формирует XML-файлы со статистикой по кредитам проекта (подробнее о кредитах говорится в первой статье серии – см. раздел "Ссылки", п. 1).
html/Web-сайт проекта, включающий в себя информацию о самом проекте и зарегистрированных в нем приложениях, Web-интерфейс системы управления проектом, статистику участников и команд и многое другое.
log_boincserver/Каталог содержит лог-файлы служб проекта (подробнее о службах рассказано в третьей статье серии – см. раздел "Ссылки", п. 3).
templates/В этом каталоге обычно хранятся шаблоны рабочих заданий и результатов, необходимые для утилиты create_work.
cgi-bin/Содержит служебные cgi-скрипты проекта.
keys/Криптографические ключи, которые используются для подписывания исполняемых файлов, передаваемых пользователям проекта. Необходимы в целях обеспечения безопасности.
upload/В этот каталог (точнее, в его подкаталог со случайным именем) помещаются файлы с результатами расчетов, присланные клиентскими компьютерами.
myapp.cronjob, myapp.httpd.confВспомогательные файлы, которые содержат настройки служб cron и httpd соответственно.
myapp.readmeКраткая инструкция по установке и запуску BOINC-проекта.

Как видите, файлы и каталоги, необходимые для функционирования проекта, перемешаны с используемыми для административных задач. Однако это не составляет большой проблемы, так как управление проектом обычно не требует прямого обращения к каким-либо файлам, а вынесено в Web-интерфейс.

Из всего проекта в отдельный каталог выделены файлы, относящиеся к Web-сайту проекта – о нем мы поговорим подробнее в следующей статье.


База данных

Нечеткая логика и теория нечетких множеств

Нечеткая логика и теория нечетких множеств – раздел математики, являющийся обобщением классической логики и теории множеств. Понятие нечеткой логики было впервые введено профессором Лютфи Заде в 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○С может оказаться горячим, для другого – не слишком горячим. Именно в этом и проявляется нечеткость задания соответствующего множества.

Для нечетких множеств, как и для обычных, определены основные логические операции. Самыми основными, необходимыми для расчетов, являются пересечение и объединение.

http://www.basegroup.ru/library/analysis/fuzzylogic/math/

База данных – это основа всего проекта 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_logging, forum_preferences и др.) и т.д.

Однако для администратора проекта наиболее интересны будут те таблицы базы данных, которые относятся непосредственно к работе проекта и проводимым вычислениям. Далее будет подробно рассказано об этих таблицах.

Таблица app

Первая из таблиц (которую мы рассмотрим наиболее подробно), необходимых непосредственно для работы приложения, – это таблица app, в ней хранится информация о приложениях, используемых в рамках проекта.

mysql> SELECT * FROM app;
idcreate_timenamemin_versiondeprecateduser_friendly_namehomogeneous_redundancy weightbetatarget_nresults
11261137518uppercase00upperCASE0100

Поле create_time встречается и во многих других таблицах – это дата создания записи (по времени POSIX – см. врезку). Поле deprecated также будет не раз появляться – оно говорит о том, является ли значение неиспользуемым (соответственно, 0 указывается для активной записи, а ненулевое значение – для неактивной). Значение min_version задает минимально необходимую версию клиента BOINC для участия в вычислениях.

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

Для решения этой проблемы платформа BOINC предоставляет возможность использования однородных вычислителей (homogeneous redundancy – HR). HR разделяет все компьютеры, участвующие в вычислениях в рамках проекта, на «классы эквивалентности»: два хоста принадлежат одному классу, если возвращают одинаковые результаты для одного и того же рабочего задания. Если включены однородные вычисления, то планировщик BOINC отсылает одинаковые рабочие задания хостам из одного и того же класса.

Однородные вычисления включаются для проекта строкой

<homogeneous_redundancy>N</homogeneous_redundancy>

в файле config.xml. Тип HR (значение N) задается значением из таблицы 2.

Таблица 2. Классы однородных вычислителей
Тип HR (значение N)Классы однородных вычислителей
0Однородные вычисления отключены (все хосты эквивалентны).
1Сильное разбиение хостов на классы (создается 80 различных классов хостов на основе четырех типов операционных систем и 20 типов процессоров).
2Слабое разбиение хостов на классы (используются только четыре класса по операционным системам: Windows, Linux, Mac-PPC и Mac-Intel).

Однородные вычисления можно также включить для отдельного приложения, а не для всего проекта – для этого необходимо внести изменения в поле 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;
idcreate_timenameuser_friendly_name
11261137518windows_intelx86Microsoft Windows (98 or later) running on an Intel x86-compatible CPU
21261137518windows_x86_64Microsoft Windows running on an AMD x86_64 or Intel EM64T CPU
31261137518i686-pc-linux-gnuLinux running on an Intel x86-compatible CPU

Заключение

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

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • Библиотека документов

    Более трех тысяч статей, обзоров, руководств и других полезных материалов.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=775507
ArticleTitle=Распределенные вычисления: Часть 4. Проект BOINC изнутри
publish-date=11172011