Фгбу «пияф» удк 001. 89: 004. 31

Скачать 1.44 Mb.

Название	Фгбу «пияф» удк 001. 89: 004. 31
страница	8/14
Дата публикации	01.04.2015
Размер	1.44 Mb.
Тип	Отчет

100-bal.ru > Информатика > Отчет

1 ... 4 5 6 7 8 9 10 11 ... 14

2.2Разработка рекомендаций по использованию результатов проведенных НИР в реальном секторе экономики, а также в дальнейших исследованиях и разработках

2.2.1Рекомендации по системе учёта заявок на эксперименты

Существуют различные подходы к организации систем подачи заявок на проведение экспериментов в удалённом режиме через Интернет. Как правило, большинство систем требуют обязательной предварительной регистрации пользователя, получения имени и пароля, и только после этого пользователь получает доступ к функциональности системы. При этом при регистрации требуется указать сведения, обосновывающие право на проведение экспериментов на экспериментальных установках (быть сотрудником организации, участвовать в совместных исследованиях, коммерческое использование экспериментальных установок). Полученные (или введённые) имя/пароль в дальнейшем являются аутентификационными данными пользователя, которые в дальнейшем используются при взаимодействии с другими удалёнными сервисами. Фактически система подачи заявок является одним из сервисов общей информационной структуры, доступ к которой определяется единой системой регистрации пользователей. При этом в качестве аутентификационных данных могут использоваться регистрационные данные из глобальных систем однократной регистрации (например OpenID или ей подобных).

Другой подход заключается в приёме заявок от всех пользователей без предварительной регистрации, только с указанием идентификационных и контактных данных основного пользователя (Principal User) эксперимента и затем, после принятия решения о проведения эксперимента, рассылка через e-mail информации об аутентификационных данных, которые и будут использоваться для доступа к информационным ресурсам. Тем самым доступ к системе подачи заявок и связанных с ней сервисам может быть ограничен и локализован, обеспечивая более строгий контроль по доступу к данным.

Для разработанной модели способ организации системы подачи заявок и механизм взаимодействия с ней важен, поскольку создание корневого объекта базы метаданных “Исследование” фактически определяется принятием заявки на эксперимент и содержит метаданные, характерные для описания заявки. Конечно, схема базы метаданных содержит достаточно ограниченное подмножество данных, обычно заполняемых при подаче заявки.

Поэтому рекомендуемый порядок подачи заявок для системы подачи заявок и взаимодействия с ней системы хранения метаданных при создании корневых объектов базы метаданных может быть сформулирован следующим образом:

а) Регистрация заявки на проведение эксперимент через Веб-сайт системы подачи заявок с указанием идентификационных и контактных данных основного пользователя. Если пользователь уже имеет цифровой сертификат, указание DN сертификата.

б) После рассмотрения и принятия заявки рассылка сообщения по электронной почте с указанием точки входа и инструкциями для получения аутентификационных данных основного пользователя. При наличии других информационных ресурсов, доступ к которым требует ввода аутентификационных данных, это может быть пара имя/пароль или другой уникальный идентификатор, однако для организации доступа к системе хранения данных пользователь должен получить цифровой сертификат, выданный доверенным центром сертификации. Способ получения зависит от организации работы центра сертификации.

в) Для нового пользователя регистрация в виртуальной организации (группе), через Веб-интерфейс системы управления виртуальными организациями (VOMS). После этого новый пользователь становится авторизованным пользователем системы хранения данных.

г) Административным персоналом или программным образом в базе метаданных создаётся корневой объект “Исследование” с информацией об эксперименте из заявки и роль “Владелец” (“Owner”) для этого объекта назначается основному пользователю.

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

2.2.2Рекомендации по сопряжению с системой хранения данных

При сопряжении внешних сервисов с системой хранения данных рекомендуется использование двух основных подходов: сопряжение через программную библиотеку и сопряжение через клиента командной строки.

Сопряжение через программную библиотеку рекомендуется для сервисов, специально разрабатываемых для взаимодействия с системой, например, сервисов на рабочих станциях экспериментов. Данный метод обеспечивает максимальную производительность, но требует изменения исходного кода сервисов для внесения каких-либо корректив в алгоритм взаимодействия. Взаимодействие может осуществляться по устойчивому защищённому сетевому соединению, причём взаимная аутентификация может выполняться лишь единожды при установлении такого соединения. Программная библиотека обеспечивает доступ ко всей функциональности СХД.

Сопряжение через клиента командной строки рекомендуется для пакетов прикладных программ, специально не рассчитанных на работу с системой хранения данных. При этом чтение и запись данных в СХД осуществляется клиентом командной строки непосредственно перед или после запуска пакета. Данный метод обеспечивает максимальную гибкость, так как не требует внесения никаких изменений в программный код прикладных программ, однако может иметь меньшую производительность из-за необходимости запуска клиента командной строки для выполнения любого действия с СХД.

2.2.3Рекомендации по организации потоков данных (файлы, размеры)

Разработанная модель рассчитана на хранение данных в виде отдельных файлов. Каждый файл является атомарной единицей хранения данных. Такая организация является оптимальной с точки зрения доступа пользователей системы к данным, а также при необходимости внешней обработки данных прикладными программными пакетами.

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

Поскольку передача файла атомарна, при возникновении каких-либо нештатных ситуаций файл либо полностью передаётся, либо полностью не передаётся с возвращением кода ошибки. При необходимости доступа лишь к части данных, находящихся в файле, файл необходимо прочитать (или записать) целиком.

Таким образом, при непрерывном потоке данных с рабочей станции или из программы симуляции представляется разумной следующая организация этих данных в виде файлов:

а) Для служебных файлов (конфигурация ПО, другие данные небольшого объёма) – текстовый формат, объём до нескольких сотен килобайт;

б) Для файлов экспериментальных данных или данных симуляции – бинарный, текстовый или смешанный формат (NeXus), объём до нескольких сотен мегабайт. При необходимости хранить данные большего объёма их целесообразно разбить на несколько файлов. Файлы размером более двух гигабайт могут быть несовместимы с некоторыми операционными или файловыми системами;

в) Для файлов публикаций – бинарный или гипертекстовый формат (Portable Document Format, Open Document Format), размер до нескольких десятков мегабайт.

2.2.4Рекомендации по использованию метаданных для описания сбора и обработки данных конкретных экспериментов

Централизованная система хранения экспериментальных данных обеспечивает поддержку полного жизненного цикла этих данных от их создания, сохранения и обработки. Ключевым фактором в этом являются метаданные, которые являются средством описания различных фаз жизненного цикла экспериментальных данных, их трансформации и связанных с ними объектов, а также обеспечивают возможность поиска информации по различным критериям. Важность детального описания посредством метаданных процесса исследования и данных, порождаемых при этом, обуславливается следующими основными факторами:

а) Централизованное хранение метаданных и доступ к ним через веб-интерфейс существенно упрощает работу с данными научным коллаборациям, когда такая информация как кто, когда, в каких условиях, посредством чего и т.п. создал конкретный набор данных необходима всем членам такого научного коллектива.

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

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

г) Использование метаданных обеспечивает возможность поиска информации по различным критериям.

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

а) Объекты “Исследование” (Investigation), “Установка” (Instrument), “Образец” (Sample). Эти объекты представляет собой наборы метаданных, которые в основном заполняются значениями из заявки на эксперимент. Объект “Исследование” определяет общее описание проводимого исследования: название, тип (симуляция, эксперимент, калибровка и т.п.), описание, время начала и конца исследования. Объект “Установка” определяет такие параметры как имя, тип и общее описание установки, на которой будет проводится исследование. Объект “Образец” описывает образец, на котором проводятся исследования, и который позволяет определить такие параметры как имя и его описание, химическая формула, физическое состояние, масса. Однако помимо этих метаданных для каждого из объектов в случае необходимости исследователь может добавить произвольное количество параметров в форме “описание параметра” – “его значение” как произвольные текстовые строки. Особенно важным здесь является дополнительное описание исследуемого образца, поскольку заранее предопределенные метаданные не могут охватить все многообразие этих объектов. Кроме того, учитывая, что все объекты, определенные в базе метаданных, связаны с тем или иным объектом “Исследование” и поиск различной информации чаще всего происходит через определение параметров этого объекта, крайне важно сформировать список ключевых слов, связанных с конкретным исследованием. Для этой цели в базе метаданных существует объект “Keywords”, позволяющий определить группу ключевых слов, связанных с конкретным объектом “Исследование”.

б) Набор данных» (Dataset). Это объект объединяет файлы, соответствующие определённому действию в рамках исследования. Это могут быть данные симуляции или других операций, предваряющих эксперимент, например калибровка, данные экспериментальных измерений или данные после обработки и анализа. Этот тип набора данных пользователь должен определить на этапе его создания из заранее определенного набора метаданных. Типичным примером объединения экспериментальных данных является группа файлов, состоящая из собственно данных измерения на образце и файлов калибровки, фона и т.п. Имена наборов данных должны быть уникальными, поэтому для удобства пользования необходимо принять некоторые соглашения об образовании имен. В настоящей модели имена наборов данных предлагается формировать по следующей схеме: “/pik/<краткое имя исследования>/<краткое имя установки>/<собственно имя набора данных>”. Для более детальной идентификации набора данных пользователям рекомендуется использовать параметр “Description”, который в дальнейшем можно использовать при поиске, а также использовать дополнительные метаданные через объект “Dataset_parameter”.

в) Объект “Файл данных” (Datafile). Эти объекты появляются в системе сохранения данных при передаче с экспериментальных рабочих станций, как результат обработки данных и в результате загрузки сторонних файлов через веб-интерфейс. Каждый из таких объектов определяется набором метаданных, которые (кроме имени файла) автоматически заполняются такими значениями, как времена создания файла и появления его в системе, размер и тип, контрольная сумма и месторасположение в системе хранения. Однако ключевыми здесь являются дополнительные метаданные, которые пользователь может определить через объект “Datafile_parameter”. Для экспериментальных данных прежде всего рекомендуется определить параметр, позволяющие различить в дальнейшем один файл от другого в наборе данных. Например, определить параметр, значения которого и будут описывать происхождение данного файла, т.е. определять тип файла в наборе данных. Важное значение для идентификации экспериментальных данных имеют условия и параметры установки , при которых файл данных был получен. Как правило, набор таких параметров является достаточно большим. Например, для детектора малоуглового рассеяния нейтронов (МУРН) необходимо сохранить такую информацию, как позиция и параметры коллиматора, позиция детектора, температурные условия и т.п. Как правило, эта информация сохраняется в файле вместе с данными, например в формате NeXus, однако наиболее существенные параметры из общего набора рекомендуется сохранить в виде метаданных, что позволит в будущем упростить поиск и навигацию в системе хранения.

г) Объекты фазы обработки данных. Описание посредством метаданных конкретной фазы обработки данных имеет исключительно важное значение, поскольку это позволяет в будущем оценить и проверить полученные в результате обработки данные. Любой этап обработки данных требует описания трех основных объектов: входные данные, программа и выходные данные. Поскольку предполагается, что входные файлы уже являются документированными на предыдущих этапах, то единственным моментом, требующим метаданных, здесь является необходимость указания связи выходного набора данных с входными файлами, что позволит в дальнейшем возможность навигации по всей цепочке этапов научного исследования. Для этого пользователю предоставляется возможность через объект Dataset_meta связать конкретный выходной набор данных с множеством входных файлов, указав их имена в системе хранения. Для описания самой программы обработки рекомендуется использовать такие параметры как имя программы, ее версия и краткое описание, а также при необходимости авторы программы. Эти параметры предоставляются пользователю через объекты Software и Software_run. Кроме того, важной информацией, которую рекомендуется сохранять на этом этапе, являются условия выполнения программы, а именно разрядность вычислительного узла и версия операционной системы. Эти параметры можно определить через объект Software_run_parameter.

д) Объект “Публикация”. Одной из основных целей научного исследования является публикация результатов. Система хранения метаданных позволяет описать конкретную публикацию и связать ее с данными, на которых она основана. Для этой цели рекомендуется использовать такие метаданные, как полное название с авторами, аннотация, репозиторий и URL (если имеется). Эти параметры в системе определяются объектом “Publication”. Для связи публикации с данными, на которых она основана, используется объект “Publication_meta”, атрибуты которого позволяют определить набор файлов данных.

2.2.5Рекомендации по организации обработки данных

Основной метод запуска заданий на вычислительном кластере, являющемся сегментом Грид – это формирование на специальном языке JDL файла описания задания и передача этого файла на менеджер кластера с помощью соответствующей команды. От пользователя не требуется знание деталей языка JDL, поскольку они скрыты веб-интерфейсом, предоставляющим все основные функции по запуску и управлению заданиями на вычислительном Грид-сегменте. Для пакетов прикладных программ, установленных на вычислительном кластере, веб-интефейс предоставляет возможность интерактивного редактирования запускающего скрипта, который будет выполняться на рабочем узле кластера. Здесь пользователю необходимо модифицировать строки, обеспечивающие следующие действия:

а) Загрузка входных файлов. Для этого необходимо в параметрах команды modus, выполняемой перед запуском программы, указать требуемых имена наборов данных и, если загружаются не все файлы из набора данных, то также и имена файлов.

б) Запуск программы. Здесь можно добавить требуемые параметры обработки.

в) Сохранение результатов. Для этого необходимо в параметрах команды modus, выполняемой после завершения программы, указать требуемых имена наборов данных и имена файлов.

После завершения программы рекомендуется проверить файл stderr.txt, который будет появляться в рабочем каталоге пользователя и содержать все сообщения об ошибках и предупреждения, которые выдавались в процессе выполнения как запускающего скрипта так и самой программы обработки.

Сценарий обработки данных, рассмотренный выше, не является единственным. Прежде всего, это касается случая, когда для обработки данных требуется программа, которая не установлена на вычислительном кластере, но пакет для ее сборки находится в распоряжении пользователя. Здесь следует отметить, что если даже исполняемый файл программы имеется, то тем не менее рекомендуется сборка программы непосредственно на вычислительном узле, что позволит избежать ошибок из-за возможного несоответствия среды сборки и выполнения. Рекомендуемый сценарий для рассматриваемого случая следующий:

а) Загрузить в рабочий каталог пользователя все файлы, требуемые для сборки программы.

б) Создать в рабочем каталоге запускающий скрипт, аналогичный используемом в предыдущем сценарии. В этом скрипте перед запуском программы написать все команды, обеспечивающие сборку программы.

в) Используя возможности веб-интерфейса по низкоуровневому созданию файла описания задания на языке JDL, в секции выполняемое задание (Executable) указать имя запускающего скрипта, а в секции входные файлы (Input files)- имена всех файлов из рабочего каталога, которые будут переданы на рабочий узел (в том числе и имя запускающего скрипта).

г) Дальнейшие действия аналогичны описанным в предыдущем сценарии.

Использование рабочего каталога пользователя не ограничивается рассмотренным случаем. Зачастую сценарий обработки данных предполагает использование файла параметров, который может быть достаточно большим и требующим своего редактирования при нескольких предварительных прогонах программы обработки. При этом сохранение файла параметров, а также выходных данных, в системе хранения не является удобным для пользователя. В этом случае рекомендуется разместить файл параметров в рабочем каталоге, а выходные данные промежуточных запусков программы также направлять в этот каталог, для чего в секции Output files указать имена выходных файлов. После выполнения отладочных прогонов программы обработки рекомендуется в набор данных с выходными файлами программы обработки поместить файл параметров, что позволит в будущем иметь полную информацию об условиях запуска этой программы.

2.2.6Требования по сетевой совместимости и использования стандартных протоколов и форматов данных

Активное сетевое оборудование, которое будет использоваться при создании сетевой вычислительной инфраструктуры, обеспечивающей поддержку проведения экспериментов на установках реактора ПИК, должно обеспечивать выполнение следующих функций:

а) коммутация на 2-ом и 3-ем уровнях модели OSI;

б) одновременная маршрутизация IP v4 и IP v6, качество обслуживания (QoS) и безопасность, поддержанная на аппаратном уровне;

в) статическая маршрутизация между виртуальными локальными сетями (VLAN);

г) динамическая маршрутизация между сегментами;

д) технология агрегирования каналов должна выполняться по технологии IEEE 802. 3ad;

е) виртуальные локальные сети должны реализовываться по стандартному протоколу IEEE 802.1q;

ж) поддержка следующих стандартов IEEE: 802.1D MAC Bridges; 802.1s Multiple Spanning Tree Protocol; 802.1w Rapid Spanning Tree Protocol;802. 3ab 1000BASE-T (10/100/1000 Ethernet over copper); 802. 3z Gigabit Ethernet; 802. 3ae 10 Gigabit Ethernet; 802.1p Class-of-Service (CoS) Tagging for Ethernet frames; 802.1x Port-based network access control;

и) поддержка следующих стандартов RFC: RFC 1591; RFC 768; RFC 783; RFC 792; RFC 793; RFC 826; RFC 854; RFC 951; RFC 1058; RFC 1519; RFC 1542; RFC 2030; RFC 2131; RFC 2453; RFC 3046; RFC 3768; RFC 2362; RFC 3376; RFC 3973; RFC 2784; RFC 1213; RFC 1493; RFC 1724; RFC 1850; RFC 2021; RFC 2096; RFC 2618; RFC 2620; RFC 2674; RFC 2737; RFC 2281; RFC 1195; RFC 2787; RFC 2863; RFC 2925; RFC 2328; RFC 3101; RFC 4271; RFC 2474; RFC 2597; RFC 2598; RFC 1492; RFC 2138; RFC 2866.

Должны использоваться следующие протоколы, широко используемые в сети Интернет:

а) HTTP (Hyper Text Transfer Protocol) — протокол передачи гипертекста. Протокол HTTP используется при пересылке Веб-страниц;

б) HTTPS (Hypertext Transfer Protocol Secure) — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных

в) FTP (File Transfer Protocol) — это протокол передачи файлов со специального файлового сервера на компьютер пользователя. FTP дает возможность абоненту обмениваться двоичными и текстовыми файлами с любым компьютером сети. Установив связь с удаленным компьютером, пользователь может скопировать файл с удаленного компьютера на свой или скопировать файл со своего компьютера на удаленный.

г) SSH (Secure SHell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений, шифрующий весь трафик, включая и передаваемые пароли.

Данные, полученные в результате работы систем сбора экспериментальных данных и систем off-line обработки и анализа должны представляться пользователям в следующих форматах:

а) NeXus — универсальный формат данных для нейтронных, рентгеновских и мюоных исследований, созданный в качестве международного стандарта коллаборацией ученых и программистов, представляющих основные научные объекты в Европе, Азии, Австралии и Северной Америке в целях содействия расширению сотрудничества в области анализа и визуализации нейтронных, рентгеновских, мюонных данных;

б) JSON (JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком;

в) XML (eXtensible Markup Language) — расширяемый язык разметки, рекомендованный Консорциумом Веб, представляющий собой свод общих синтаксических правил текстового формата, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между подсистемами.

2.2.7Рекомендации по инфраструктуре безопасности на основе цифровых идентификаторов

С целью обеспечения максимальной совместимости как с системами Грид, так и с прикладным ПО целесообразно использовать инфраструктуру PKI для аутентификации и авторизации пользователей и сервисов.

Данная инфраструктура широко поддерживается различными операционными системами и является стандартом для аутентификации в Грид и Интернет. При использовании PKI каждому пользователю или сервису выдаётся персональный уникальный цифровой сертификат, однозначно его идентифицирующий.

Цифровые сертификаты централизованно выдаются национальным или региональным удостоверяющим центром, который гарантирует достоверность информации, указанной в сертификате. Использование инфраструктуры PKI позволяет максимально унифицировать процедуры взаимной аутентификации пользователей и сервисов, автоматически обеспечивая совместимость с другими существующими или разрабатываемыми системами, также построенными на основе PKI. Типичным примером могут служить веб-браузеры, подавляющее большинство из которых поддерживает PKI для аутентификации пользователей и веб-сервисов.

Для управления регистрацией и реестром известных пользователей и сервисов может быть использована одна из систем управления виртуальными организациями, например, VOMS, предоставляющая стандартный веб-ориентированный интерфейс для управления пользователями и группами пользователей.

2.2.8Разработка проекта ТЗ для проведения ОКР по теме: «Разработка программно-аппаратного комплекса хранения и обработки экспериментальных данных для нейтронных установок реактора ПИК».

При разработке проекта технического задания на ОКР на программно-аппаратный комплекс хранения и обработки экспериментальных данных для нейтронных установок реактора ПИК необходимо использовать результаты работы, полученные при разработке модели интегральной системы off-line обработки, хранения и распределенного анализа данных экспериментов на нейтронных установках реактора ПИК по реализации функциональных задач, а именно:

а) построение системы хранения данных;

б) передача данных от рабочих станций в систему хранения данных;

в) распределённая off-line обработка данных с использованием Грид технологий;

г) взаимодействие пользователей с системой с использованием Веб- ориентированного пользовательского интерфейса;

д) безопасность системы.

Разработанная информационно-коммуникационная модель интегральной системы off-line обработки, хранения и распределенного анализа данных, включающая в себя программное обеспечение экспериментальной реализации в виде программного комплекса «МОДУС» с программной документацией, а также испытательный стенд с эскизной конструкторской документацией являются базой для создания реальной системы off-line хранения, обработки и распределённого анализа информации для экспериментов, планируемых к проведению на высокоточном реакторе ПИК. Наличие этих разработок позволит сократить сроки создания системы на стадии ОКР за счет проработки на стадии НИР логической структуры системы и выбора оптимальных вариантов технических решений реализации модели системы. Практически это означает, что выполнение ОКР может начинаться с этапа разработки технического проекта, пропустив этапы разработки технического предложения и эскизного проекта. Проект технического задания на ОКР представлен в приложении А.