[SETI_home_v8]

Организация распределённых вычислений в виде BOINC-проекта естественным образом делится на два крупных блока:
• Настройка BOINC-сервера;
• Создание приложения - либо как полноценного BOINC-приложения, взаимодействующего с клиентом через API, либо как просто "какого-то приложения", взаимодействующего через wrapper.
После получения некоторого опыта работы с перечисленными выше компонентами сначала в SAT@home, затем - у себя в виртуалках, а потом - и в RakeSearch, у меня сложилось следующее мнение:
1. В развёртывании серверной части - вроде бы ничего страшного нет. Да, крайне желателен опыт работы с Linux, но ничего особо хитрого там нет. Вопрос скорее в наличии (или нахождении) небольшого описания, которое говорило бы как развернуть базу, файлы проекта, запустить его сервисы, зарегистрировать приложение и дробавлять задания. Для начала - этого вполне хватит;
2. Причём всё вышеописанное и в замечательном виде есть как минимум у коллег из Петрозаводска и, думаю, у коллег из ИППИ РАН. И, что ещё важнее - личный опыт!
3. Вне зависимости от типа сервера проекта (Gerasim от SerVal-а или BOINC от Андерсона), развёрнутый сервер надо как-то сопровождать, архивировать данные, выкладывать новости, общаться с участниками, делать бэйджики, строить графики, решать какие-то проблемы с заданиями и workunit-ами и т.д. и т.п. Очень большая (если не бОльшая) часть этой работы - связана с базой данных проекта, а всевозможные дополнительные, "инфраструктурные" задачи могу потребовать написания дополнительных скриптов или даже небольших программулин. Например, если у вас число workunit-ов и результатов будет исчисляться сотнями тысяч или миллионами, то вам точно придётся задуматься о том, как это лучше хранить, и как раскладывать и генерируемые workunit-ы и результаты к ним, получаемые не в совсем упорядоченном виде. Или что делать с данными о завершённых workunit-ах и result-ах в базе? Учёный (или исследовательская группа), которому (или которой) в первую очередь и нужны результаты вычислений - могут это всё сделать. Но никакого смысла ему (или им) тратить на это всё время - нет, ибо всё тоже самое, только и быстрее и оптимальнее... сделает энтузиаст или группа энтузиастов в свободное от работы время - просто потому что на своей работе они занимаются чем-то подобным, только намного интенсивнее и в гораздо больших объёмах. У них просто на этом уже набита не только рука, но и куча шишек;
4. Из перечисленных выше пунктов следует один очень простой вывод - "Как минимум для начала, нет никакого смысла самостоятельно поднимать свой сервер проекта. Лучше воспользоваться либо опытом, либо и опытом, и инфраструктурой коллег, которые это уже знают и умеют. А свои силы - направить на написание приложения, которое и должно добывать научно значимые результаты". Тут можно вспомнить, что когда-то Олег Заикин сам запустил SAT@home (за что ему большой почёт), но: 1) на то он и один из первопроходцев в этой части в России; 2) Это было в 2012 году, а сейчас - 2019, а я говорю именно о том, что лучше делать сейчас; 3) лично я исхожу из того, что время - это очень важный ресурс и действовать надо в зависимости от предполагаемых его затрат. Если человек сходу может развернуть серверную часть - отлично. Если же нет, то лучше сначала потратить время на приложение, а с инфраструктурными вещами - помогут. А дальше - видно будет;
5. А теперь - самое интересное, с чего можно было бы и начать, но тогда не было бы понятно почему с него начали. �� Приложение, расчётный модуль для проекта! Лично я, сейчас, думаю, что его создание должно проходить по следующим стадиям:
1. Формирование математической модели: формулы, операции преобразования, алгоритмы изменения данных в формализованном, математическом виде.
2. Преобразование построенной математической модели в структуры данных и алгоритм их обработки, записанные либо в псевдокоде, либо в виде, близком к языкам программирования, либо уже на каком-то языке программирования, с чётким, жёстким раздением на две части - ядро из данных, полностью описывающих состояние расчёта и обособленное так, чтобы в процедурах обработки не было и не возникало каких-то дополнительных переменных или структур, от которых зависело бы состояние расчёта, но которые бы не входили в это ядро. Поясню - речь не о том, чтобы это ядро было как-то хитро так написано, а наоборот - чтобы в конце написания программы, она должна быть такой, чтобы в ней это ядро и сформировалось. Это очень важно, потому что...
3. ... на следующем этапе, именно это ядро, полностью описывающее состояние расчёта и становится содержимым файла контрольной точки, а с другой, функционал формирование контрольных точек, скорее всего, будет задействован в генераторе workunit-тов! Просто потому что workunit - это и есть контрольная точка, только пришедшая с сервера и которую, на всякий случай, нельзя затирать до окончания расчёта! На этом этапе расчётный модуль уже окончательно формируется в виде программы, делающей почти всё необходимое: запуск с некоего нулевого состояния; запуск с промежуточного состояния; запись данных в файл результата; корректное завершение расчёта;
4. А когда уже есть расчётный модуль, который умеет запускаться и с контрольной точки, и без неё (начиная расчёт с начала), в него нужно добавить вызов нескольких функций, связанных с BOINC API, после чего он станет полноценным BOINC-приложением. Если у вас под руками будет либо хороший пример, либо вы будете сотрудничать с человеком, который это уже делал, скорее всего - это будет самая простая часть от всей работы.
6. Реальность, конечно, может задавать задачки, далеко выходящие за рамки озвученных пунктов. Ну, например, если в нашем расчёте используются сторонние библиотеки, которые надо исполнять в каком-то хитром окружении, или использовать виртуальную машину, docker или что-то ещё. Или, например, если у расчёта может быть несколько выходных файлов, которые надо отправлять время от времени, как это ранее было в ClimatePrediction.net (а может есть и сейчас). В этом случае взаимодействие с BOINC-клиентом может усложняться, но и в этом случае - всё равно сначала надо разобраться с checkpoint-ами!
Итого: Чтобы запустить расчёты в виде BOINC-проекта, в первую очередь нужно иметь интерес к решению некоторой проблемы; во-вторую очередь - алгоритм вычислений, разбивающий задачу на независимые, меньшие по размеру подзадачи; в-третью очередь - реализацию этого алгоритма в виде программы с выделенной структурой данных, полностью описывающих состояние расчёта (и вот тут, возможно, человеку придётся удалить из своей памяти "накодированное непосильным трудом" и просто-напросто написать расчётный модуль заново!) и уже только после этого могут начаться какие-то сложности, связанные с настройкой инфраструктуры проекта, которые, как уже выше было сказано, вполне могут быть решены либо прямо на инфраструктуре тех, кто это уже умеет делать, либо с их помощью. Особо отмечу, что на мой взгляд, возможность формирования контрольной точки и перезапуска расчёта с неё, является не каким-то специфичным требованием, выдвигаемым распределёнными вычислениями, а наоборот - одно из базовых требований, которому должно соответствовать, в идеале, любое расчётное приложение, запускаемое что в BOINC-проекте, что на суперкомпьютере, что на отдельно взятом компьютере или сервере. Это просто признак хорошо написанного расчётного модуля. Ну, если конечно, сами задания не являются очень короткими, из-за чего контрольные точки, действительно, могут быть просто не нужны.
И, как мне кажется, регулярное появление всё новых и новых проектов распределённых вычислений - озвученные выше предположения - подтверждает. А вот если, конкретно у нас, в России, проектов распределённых вычислений почему-то не появляется, то, скорее, тут дело не в сложностях с BOINC, а в том, что-либо потенциальные потребители мощностей не знают о том, что "а так можно было", либо самих исследований настолько мало, что они умещаются в существующих суперкомпьютерах, а то и кафедральных компьютерах, серверах и т.п.