МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
имени М.В.ЛОМОНОСОВА

НАУЧНО-ИССЛЕДОВАТЕЛЬСКИЙ ИНСТИТУТ ЯДЕРНОЙ ФИЗИКИ
имени Д.В.СКОБЕЛЬЦЫНА

УДК 004.75

№ госрегистрации 0120.0 801882-

Инв.№ 105835/08

УТВЕРЖДАЮ

Директор НИИЯФ МГУ

______________ М.И.Панасюк
«___»_________ 2008 г.

ОТЧЕТ
О НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ

Исследование и разработка технологического задела по запуску в грид-инфраструктуру заданий, подготовленных для различных сред исполнения

3 этап

(промежуточный)

по теме:

Экспериментальные исследования поставленных перед НИР задач.

Руководитель работ

________ подпись, дата

В.А.Ильин

Москва 2008 г.

СПИСОК ИСПОЛНИТЕЛЕЙ

Руководитель работ, д-р физико-математических наук	_________________ подпись, дата	В.А.Ильин (Введение, Заключение)
Исполнители	_________________ подпись, дата	А.П.Крюков (раздел 2)
	_________________ подпись, дата	А.П.Демичев (разделы 3)
	_________________ подпись, дата	Е.Г.Боос (разделы 4)

Реферат

отчета по теме:

Экспериментальные исследования поставленных перед НИР задач.

Отчет: 43 с., 12 рис., 1 таблица, 13 источников, 2 приложения

Ключевые слова: распределенные вычисления, грид, среда исполнения, виртуализация ресурсов.

Объектом исследования являются распределенные вычислительные ресурсы грид-инфраструктур в условиях их применения для решения задач, подготовленных для различных сред исполнения.

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

В процессе работы на третьем этапе исследований проводились экспериментальные исследования поставленных перед НИР задач, в том числе

• Программная реализация разработанных алгоритмов.
• Разработка макета системы.
• Разработка программы и методики экспериментальных исследований.
• Сопоставление результатов тестирования с параметрами, определенными в Техническом задании.

Кроме того, в соответствии с календарным планом работ по контракту проводилась:

• Разработка документации в соответствии с требованиями п. п. 4.4, 4.5 ТЗ.
• Технико-экономические исследования эффективности внедрения исследования в народное хозяйство.
• Проведение патентных исследований по ГОСТ 15.011-96.
• Реализация мероприятий по достижению технико-экономических показателей (п. 6 Технического задания).
• Составление промежуточного отчета и его рассмотрение.

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

В рамках реализации мероприятий по достижению технико-экономических показателей, зафиксированных в Техническом задании, опубликованы тезисы доклада по теме работы на Международной конференции "XXI International Symposium on Nuclear Electronics & Computing NEC'2007" (Болгария, Варна, 10-17 сентября, 2007 г.): A.Kryukov and I.Gorbunov "First experience of submission to the EGEE/RDIG Grid of jobs prepared for non standard OS's by means virtualization" ("Первый опыт запуска заданий, подготовленных для исполнения в нестандартных ОС, в грид EGEE/РДИГ на основе виртуализации"). По материалам работы и доклада в печать направлена статья, которая будет опубликована в Трудах конференции.

Содержание

Определения……………………………………........................………………..…………………6

Обозначения и сокращения……........................……………………………………………..……9

1 Введение 11

2 Разработка макета системы 13

2.1 Уточненная архитектура СЗЗ-РСИ 13

2.2 Уточненный алгоритм работы СЗЗ-РСИ 15

3 Программная реализация разработанных алгоритмов и создание макета системы запуска заданий для различных сред исполнения 18

3.1 Программная реализация компонент СЗЗ-РСИ 18

3.1.1 Cлужба предоставления сред исполнения (СПСИ) 18

3.1.2 Модуль разворачивания ВМ на рабочем узле 19

3.1.3 Монитор виртуальных машин (МВМ) 21

3.1.4 Модуль передачи данных в виртуальную среду 23

3.1.5 Модуль безопасности 26

3.1.6 Репозиторий сред исполнения 28

3.2 Аппаратная реализация макета 29

3.3 Техническая документация на компоненты СЗЗ-РСИ и макет системы 31

4 Проведение экспериментальных исследований 32

5 Сопоставление результатов тестирования с параметрами, определенными в Техническом задании. 35

6 Технико-экономические исследования эффективности внедрения результатов НИР в народное хозяйство 35

7 Заключение 41

8 Список использованных источников 43

Определения

В настоящем отчете о НИР применяют следующие термины с соответствующими определениями:

Аппаратная технология виртуализации - набор инструкций процессора Intel VT-x или AMD-V для упрощения и ускорения переключения контекста между гостевой и хостовой операционными системами.

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

Виртуальная машина - программная или аппаратная среда, в той или иной степени имитирующая работу реального компьютера. На виртуальную машину, так же как и на реальный компьютер можно инсталлировать операционную систему, у виртуальной машины так же есть BIOS, оперативная память, жёсткий диск (выделенное место на жёстком диске реального компьютера), могут эмулироваться периферийные устройства. На одном компьютере может функционировать несколько виртуальных машин.

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

Гостевая операционная система - операционная система, работающая внутри виртуальной машины.

Инфраструктура безопасности грида - компонента промежуточного программного обеспечения грида; основывается на понятии открытого ключа, входит в инструментальный пакет Globus.

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

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

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

Приложение – любая компьютерная программа, предназначенная для решения конкретной задачи пользователя из некоторой прикладной области. В данном контексте рассматриваются грид-приложения, т.е. приложения, использующие грид-инфраструктуру для получения результата.

Промежуточное программное обеспечение/ППО - слой программного обеспечения, состоящий из агентов, являющихся посредниками между различными компонентами крупного приложения. Зачастую ППО используется в распределённых приложениях, причём агентов, составляющих этот слой, может быть несколько.

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

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

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

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

Хостовая операционная система - операционная система, в которой работает платформа виртуализации, исполняющаяся непосредственно на хосте

Хостовая система (хост) - компьютер, на котором работает платформа виртуализации.

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

Обозначения и сокращения

ВМ виртуальная машина

МВМ монитор виртуальных машин (гипервизор)

ОС операционная система

ПО программное обеспечение

ППО промежуточное программное обеспечение

РДИГ Российский грид для интенсивных операций с данными

РЦ ресурсный центр

СЗЗ-РСИ система запуска заданий, подготовленных для различных сред исполнения, в грид-среду

СПСИ служба предоставления сред исполнения

CE вычислительный элемент (Computing Element)

EGEE развертывание грид-систем для e-науки (The Enabling Grids for E-sciencE)

GT4 набор инструментальных средств Globus версии 4 (Globus Toolkit 4)

CLI интерфейс командной строки (Command Line Interface)

gLite промежуточное программное обеспечение проекта EGEE (Lightweight Middleware for Grid Computing)

GSI система безопасности (Grid Security Infrastructure)

JDL язык описания задания (Job Description Language)

KVM Linux Kernel Virtual Machine

OGSA открытая архитектура ГРИД-сервисов (Open Grid Service Architecture)

PBS портируемая система пакетной обработки (Portable Batch System)

RB сервис распределения ресурсов (Resource Broker)

SE элемент хранения; ресурс хранения данных (Storage Element)

UI интерфейс пользователя (User Interface)

UML User-mode Linux

VMM монитор виртуальных машин (Virtual Machines Monitor)

VW виртуальное рабочее пространство (Virtual Workspace)

VWS служба виртуального рабочего пространства (Virtual Workspace Service)

WM менеджер загрузки (Workload Manager)

WMS подсистема управления загрузкой (Workspace Management Service)

WN рабочий узел (Working Node)

1. Введение

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

Основными целями работы являются:

• существенное расширение класса прикладных задач, решаемых в глобальных грид-инфраструктурах, на основе технологии запуска и обработки заданий, подготовленных для различных сред исполнения, и, тем самым, повышение эффективности и обеспечение возможности широкого коммерческого использования грида;
• выполнение международных обязательств, зафиксированных в контракте No. 031688 c Европейской Комиссией по Европейскому проекту EGEE (“Enabling Grids for E-sciencE”).

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

На втором этапе выполнения работ по контракту разработаны алгоритмы работы системы запуска заданий с различными средами исполнения в грид, выяснены взаимосвязи разрабатываемой системы с другими компонентами грид-инфраструктуры, выявлены направления экспериментальных проверок для подтверждения достижимости параметров работы системы, определенных в Техническом задании, проведены патентные исследования. В рамках реализации мероприятий по достижению технико-экономических показателей, зафиксированных в Техническом задании, опубликованы тезисы и подготовлена статья для Трудов Международной конференции "XXI International Symposium on Nuclear Electronics & Computing NEC'2007" (Болгария, Варна, 10-17 сентября, 2007 г.): A.Kryukov and I.Gorbunov "First experience of submission to the EGEE/RDIG Grid of jobs prepared for non standard OS's by means virtualization" ("Первый опыт запуска заданий, подготовленных для исполнения в нестандартных ОС, в грид EGEE/РДИГ на основе виртуализации").

В соответствии с Календарным планом проведены патентные исследования, в результате которых не обнаружено каких-либо материалов, которые бы препятствовали использованию результатов работ в Российской Федерации.

Проведенный анализ научно-технической литературы и нормативно-технической документации, а также результаты патентных исследований (как на первом этапе работы, так и на втором показывает), что разрабатываемая система запуска заданий в грид-систему для различных сред исполнения в настоящее время не имеет прямых аналогов. Исследования в области виртуализации грид-ресурсов, близкие к целям настоящего контракта, проводятся рамках проектов Globus, CoreGRID и Amazon Elastic Compute Cloud (EC2). Однако, эти исследования не отвечают полностью целям и задачам настоящего проекта, а соответствующие разработки не могут быть непосредственно интегрированы в грид-инфраструктуры EGEE и РДИГ, что определено Техническим заданием настоящего контракта.

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

В связи с тем, что по условиям Технического задания должна быть обеспечена совместимость системы запуска заданий, подготовленных для различных сред исполнения, в грид-среду с промежуточным программным обеспечением (ППО) gLite [1], названия компонент грид-инфраструктуры приводятся как на русском, так и на английском языках (ППО gLite разрабатывается в рамках международного проекта Enabling Grids for EsciencE (EGEE) [2]); также для согласованности используется англоязычная аббревиатура для компонент грид-инфраструктуры.

2. Разработка макета системы

Система запуска заданий, подготовленных для различных сред исполнения (СЗЗ-РСИ) является частью общей грид-инфраструктуры. В данном разделе анализируются компоненты базовых грид-сервисов и грид-ресурсов, которые должны взаимодействовать с СЗЗ-РСИ.

1. Уточненная архитектура СЗЗ-РСИ

Общая архитектура и состав модулей системы, а именно:

• служба предоставления сред исполнения (СПСИ),
• модуль разворачивания ВМ на рабочем узле,
• монитор виртуальных машин (МВМ),
• модуль передачи данных в виртуальную среду,
• модули безопасности,
• репозиторий сред исполнения

остались неизменными и подробно описаны в Отчете о научно-исследовательской работе за второй этап выполнения проекта.

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

• передача исполняемых файлов и данных в гостевую ОС перед началом выполнения задания, а также получение результатов выполнения заданий осуществляется посредством механизма монтирования-размонтирования файла образа гостевой ОС к локальной файловой системе рабочего узла;
• при необходимости передачи данных с ЭХД в процессе выполнения заданий используется клиент GridFTP [??] (исследования показали, что клиентские программы для GridFTP существуют практически для любой ОС, в частности - для всех ОС, указанных в ТЗ);
• использование механизмов, указанных в предыдущих пунктах позволяет обойтись без развертывания на рабочих узлах серверов FTP, что существенно экономит ресурсы рабочих узлов и улучшает характеристики, зафиксированные в пп. 4.2.5 и 4.2.6 Технического задания.

В результате этих уточнений общая архитектура ресурсного грид-центра с модулями СЗЗ-РСИ приобретает следующий вид, приведенный на рис. ?? (сравни с рис. 9 Отчета о данной НИР за второй этап "Теоретические исследования поставленных перед НИР задач").

Рис. ?? Уточненная архитектура вычислительных грид-ресурсов (CE и WN) с модулями СЗЗ-РСИ

На этом рисунке сплошные линии со стрелками обозначают управляющие связи, а штрих-пунктирные - передачу файлов образов и входных/выходных данных для заданий.

2. Уточненный алгоритм работы СЗЗ-РСИ

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

Рис.??. Уточненный алгоритм выполнения задания в среде по запросу пользователя с помощью службы предоставления сред исполнения.

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

• Пользователь в описании задания на языке JDL указывает ПО-тег, соответствующий необходимости развертывания ВМ с необходимой средой исполнения ;
• WMS с помощью информационной системы находит ресурсный центр с CE, имеющим такой ПО-тег, а также со свободными рабочими узлами и направляет туда задание;
• на CE задание обрабатывается с участием службы предоставления сред исполнения (СПСИ) и "обертывается" специальным скриптом;
• при запуске на рабочем узле с установленным монитором виртуальных машин (МВМ) обертывающий скрипт:

• монтирует копию образа требуемой среды к файловой системе рабочего узла (рабочие узлы ППО gLite функционируют под управлением ОС Scientific Linux);
• записывает входную "песочницу" (sandbox) задания в файл образа;
• обеспечивает запуск задания после разворачивания ВМ (например, для гостевой ОС Windows соответствующим образом дополняет файл autoexec.bat);
• размонтирует файл образа;
• запускает ВМ и разворачивает файл образ требуемой среды исполнения;
• после окончания выполнения задания останавливает ВМ;
• вновь монтирует файл образа и копирует результаты в выходную песочницу на рабочем узле;
• уничтожает использованную копию образа на локальном диске.

• результаты задания (выходная песочница) доставляются пользователю стандартными средствами gLite.

Кроме того, обертывающий скрипт следит за тем, чтобы развернутая ВМ корректно уничтожалась, если время выполнения задания превысило время, выделенное системой управления пакетными заданиями кластера рабочих узлов.

3. Программная реализация разработанных алгоритмов и создание макета системы запуска заданий для различных сред исполнения
1. Программная реализация компонент СЗЗ-РСИ

В соответствии с разработанными архитектурой и алгоритмами работы была осуществлена программная реализация компонентов СЗЗ-РСИ, а именно, были реализованы:

• Cлужба предоставления сред исполнения (СПСИ)
• Модуль разворачивания ВМ на рабочем узле
• Монитор виртуальных машин (МВМ)
• Модуль передачи данных в виртуальную среду
• Модули безопасности
• Репозиторий сред исполнения

Часть компонент разработанной системы являются оригинальным программным продуктом. В качестве основы других модулей были взяты готовые свободно распространяемые продукты с открытым исходным кодом. Для их интеграции в систему запуска заданий для различных сред исполнения была проведена работа по их инсталляции и соответствующей конфигурации.

В следующих подразделах данной части отчета приведена краткая характеристика программной реализации каждого из компонентов. Более подробное описание приведено в технической документации (см. разд. 3.3).

1. Cлужба предоставления сред исполнения (СПСИ)
1. Функциональное назначение

будет дополнено

2. Описание логической структуры

будет дополнено

3. Программное обеспечение, необходимое для функционирования программы

будет дополнено

4. Языки программирования, на которых написана программа

будет дополнено

5. Используемые технические средства

будет дополнено

6. Вызов и загрузка

будет дополнено

7. Входные и выходные данные

будет дополнено

2. Модуль разворачивания ВМ на рабочем узле
1. Функциональное назначение

Назначением программы является монтирование/размонтирование файла образа требуемой среды исполнения к локальной файловой системе рабочего узла, запись входной "песочницы" (sandbox) задания в файл образа и результатов задания в файловую систему, запуск ВМ и разворачивание требуемой среды исполнения, после окончания выполнения задания - прекращение работы ВМ.

Программа работает на рабочем узле грид-системы и взаимодействует с соответствующей компонентой ППО.

2. Логическая структура

Программа состоит из следующих частей:

• блок разворачивания ВМ;
• блок монтирования/размонтирования файла образа среды исполнения;
• блок аварийной остановки и уничтожения ВМ.

Модуль запускается службой предоставления сред исполнения (СПСИ) и обращается к монитору виртуальных машин (МВМ). Требуемая среда исполнения указывается в файле описания задания на языке JDL с помощью атрибута " Requirements".

3. Программное обеспечение, необходимое для функционирования программы

Программа предназначена для работы в операционной среде Scientific Linux 4 (SL4).

4. Языки программирования, на которых написана программа

При написании модуля использовались языки программирования:

• perl,

• bash.

5. Используемые технические средства

Модуль устанавливается на рабочие узлы ресурсного центра на базе персонального компьютера (ПК) со следующими минимальными параметрами:

• ЦПУ - Pentium III 1GHz
• ОП - 256MB
• диск - 40GB
• сеть ethernet 10Mb с доступом в интернет
• внешний канал выхода в интернет - 10Mb/сек

6. Вызов и загрузка

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

#root> xenrun -i input_dir -o output_dir -e exec_file test.jdl

При правильной работе задание input_dir/exec_file должно быть выполнено в среде, специфицированной в файле test.jdl и результаты записаны в директорию output_dir.

7. Входные и выходные данные

Входными данными программы являются:

• входная директория (ключ -i);
• выходная директория (ключ -o);
• исполняемый файл (ключ -e);
• файл описания задания (JDL-файл).

Выходными данными являются подходящим (в соответствии с JDL-файлом) сгенерированные команды развертывания виртуальной машины с требуемой средой исполнения.

3. Монитор виртуальных машин (МВМ)
1. Функциональное назначение

Назначением монитора виртуальных машин (МВМ) является организация безопасного исполнения виртуальной машины с требуемой средой исполнения на физической системе с производительностью близкой к хостовой системе. В качестве МВМ в СЗЗ-РСИ используется Xen (http://www.xen.org), распространяющийся с открытым исходным кодом (opensource).

2. Описание логической структуры

В системе Xen есть множество уровней, нижним и наиболее привилегированным из которых является сам Xen.

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

Первый домен, домен 0, создаётся автоматически при загрузке системы. Этот домен обладает особыми управляющими привилегиями. Домен 0 запускает остальные домены и предоставляет им виртуальные устройства. Еще он занимается выполнением административных задач, таких как остановка (suspending), возобновление (resuming) работы виртуальных машин и их миграция.

В домене 0 работает процесс xend, который и занимается управлением Xen. Xend отвечает за управление виртуальными машинами и обеспечение доступа к их консолям. Команды Xend даются из командной строки и передаются ему через HTTP-интерфейс.

Дистрибутив Xen включает три главных компонента: собственно Xen, порт Linux и NetBSD для работы в Xen и утилиты для управления Xen-системой.

3. Программное обеспечение, необходимое для функционирования программы

Программа предназначена для работы в операционной среде Scientific Linux 4 (SL4).

4. Языки программирования, на которых написана программа

При написании МВМ использовались языки программирования:

• С,
• bash
• perl.

5. Используемые технические средства

Модуль устанавливается на рабочие узлы ресурсного центра на базе персонального компьютера (ПК) со следующими минимальными параметрами:

• ЦПУ - Pentium III 1GHz
• ОП - 256MB
• диск - 40GB
• сеть ethernet 10Mb с доступом в интернет
• внешний канал выхода в интернет - 10Mb/сек

6. Вызов и загрузка

Для запуска управляющего демона Xen, необходимо дать команду:

# xend start

Когда демон запустится, с помощью программы xm можно выполнять управление и наблюдать за доменами, работающими в вашей системе. Утилита xm предоставляет множество команд по управлению доменами. Запуск домена выполняется с помощью команды create. Предположим, что вы создали конфигурационный файл myvmconf, базирующийся на файле /etc/xen/xmexample2. Для старта домена с ID виртуальной машины 1 нужно ввести команду:

# xm create -c myvmconf vmid=1

Ключ -c обозначает, что после того как домен будет создан, xm должна превратиться в его консоль. Параметр vmid=1 устанавливает переменную vmid, использующуюся в конфигурационном файле myvmconf, равной 1.

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

Если надо запустить домен в режиме полной виртуализации (с конфигурационным файлом /etc/xen/xmdefconfig, см. Приложение В), выполняется команда

xm create -c /etc/xen/xmdefconfig

Далее устанавливается гостевая ОС, следуя стандартной для данной операционной системы процедуре установки. После окончания установки выполняется команда

xm destroy 1

и редактируется строка boot="d" конфигурационного файла: она должна быть заменена на boot="c".

Далее выполняется команда:

xm create -c /etc/xen/xmdefconfig

Система должна начать загружаться.

7. Входные и выходные данные

Входными данными программы являются файлы образов сред исполнения.

Выходными данными сообщения о развернутой виртуальной машине.

4. Модуль передачи данных в виртуальную среду
1. Функциональное назначение

Назначением модуля передачи данных является передача данных, которые требуются в процессе выполнения задания, из хранилища в виртуальную машину, где выполняется это задание. В качестве такого модуля используется клиетская часть GridFTP.

Программное обеспечение GridFTP является компонентом грид-инструментария Globus (http://www.globus.org) и состоит из следующих частей:

• сервер (globus-gridftp-server),

• клиентской части (globus-url-copy),
• библиотеки для разработки модифицированных клиентских частей

Для того, чтобы данные были доступны с помощью GridFTP, необходимо на хосте, который может обратиться к требуемым данным, установить GridFTP-сервер и обеспечить соответствующий интерфейс к хранилищу данных (Data Storage Interface, DSI). Чаще всего это означает стандартную (POSIX) файловую систему, но DSI также существуют для Брокера ресурсов хранения (Storage Resource Broker, SRB) и высокопроизводительной системы хранения данных (High Performance Storage System, HPSS)

Если нужно просто обратиться к данным, которые доступны по GridFTP, достаточно установить клиенте GridFTP - globus-url-copy. Этот клиент способен обращаться к данным посредством целого ряда протоколов: http, https, ftp, gsiftp и file. Важным является то, что это не интерактивный клиент, а интерфейс командной строки, подходящий для использования внутри скриптов.

2. Описание логической структуры

Программное обеспечение GridFTP является компонентом грид-инструментария Globus (http://www.globus.org) и состоит из следующих частей:

• сервер (globus-gridftp-server),

• клиентской части (globus-url-copy),
• библиотеки для разработки модифицированных клиентских частей

Для того, чтобы данные были доступны с помощью GridFTP, необходимо на хосте, который может обратиться к требуемым данным, установить GridFTP-сервер и обеспечить соответствующий интерфейс к хранилищу данных (Data Storage Interface, DSI). Чаще всего это означает стандартную (POSIX) файловую систему, но DSI также существуют для Брокера ресурсов хранения (Storage Resource Broker, SRB) и высокопроизводительной системы хранения данных (High Performance Storage System, HPSS)

Если нужно просто обратиться к данным, которые доступны по GridFTP, достаточно установить клиенте GridFTP - globus-url-copy. Этот клиент способен обращаться к данным посредством целого ряда протоколов: http, https, ftp, gsiftp и file. Важным является то, что это не интерактивный клиент, а интерфейс командной строки, подходящий для использования внутри скриптов.

3. Программное обеспечение, необходимое для функционирования программы

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

4. Языки программирования, на которых написана программа

При написании МВМ использовались языки программирования:

• С,
• Java.

5. Используемые технические средства

Модуль устанавливается в среду исполнения и формируется файл образа диска с этим модулем для последующего развертывания в виртуальной машине на рабочем узле.

6. Вызов и загрузка

Следующая команда позволяет передать файл из удаленного хранилища на локальный диск или файл-сервер, определенный во втором URL:

globus-url-copy [optional command line switches] Source_URL Destination_URL

Здесь Source_URL - адрес источника данных, Destination_URL - адрес приемника данных. Возможными префиксами адресов могут быть:

• file://
• ftp://
• gsiftp://
• http://
• https://

Возможные форматы URL:

• gsiftp://myhost.mydomain.com:2812/data/foo.dat
• http://myhost.mydomain.com/mywebpage/default.html
• file:///foo.dat

7. Входные и выходные данные

Входными данными программы являются файлы, которые необходимо скопировать.

Выходными данными программы являются копии требуемых файлов.

5. Модуль безопасности
1. Функциональное назначение

Назначением этой программы является делегирование тех или иных привилегированных ресурсов пользователям с ведением протокола работы. В рамках СЗЗ-РСИ основное назначение этого модуля безопасности - запуск монитора виртуальных машин со строго ограниченными правами.

2. Описание логической структуры

Команда sudo предоставляет возможность пользователям выполнять команды от имени привилегированного пользователя (root) либо от имени других пользователей:

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

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

Правила, используемые sudo для принятия решения о предоставлении доступа, находятся в файле /etc/sudoers; язык их написания и примеры использования подробно изложены в sudoers(5). Кроме того, пример правил, предоставляющих пользователям, являющимся членами группы rpm, возможность устанавливать, обновлять и удалять пакеты в системе, приведен в файле /usr/share/doc/sudo-<версия>/rpm.sudoers.

Для редактирования файла /etc/sudoers следует использовать программу visudo, которая проверяет синтаксис и тем самым позволяет избежать ошибок в правилах.

3. Программное обеспечение, необходимое для функционирования программы

Программа предназначена для работы в ОС Scientific Linux. В качестве модуля безопасности используется программа sudo (англ. superuser/substitute user do, дословно «выполнить от суперпользователя»). Назначением этой программы является делегирование тех или иных привилегированных ресурсов пользователям с ведением протокола работы. В рамках СЗЗ-РСИ основное назначение этого модуля безопасности - запуск монитора виртуальных машин со строго ограниченными правами.

4. Языки программирования, на которых написана программа

При написании МВМ использовались язык программирования С.

5. Используемые технические средства

Модуль устанавливается на рабочий узел ресурсного центра грид-инфраструктуры.

6. Вызов и загрузка

Общий формат обращения к программе является следующим:

sudo [необязательные опции] команда

Если пользователь не перечисленный в списке, в файле sudoers, попытается выполнить команду посредством sudo, должно быть отправлено письмо, как определено в установленное время или как определено в файле sudoers (по умолчанию root). Однако, это письмо не будет отправлено, если неавторизованный пользователь попытается запустить sudo, с флагами -l или -v. Эта возможность позволяет пользователям узнать, могут они использовать sudo или нет.

Если sudo запущен пользователем root и переменная SUDO_USER установлена, sudo будет использовать это значение, для определения того, кто является настоящим пользователем. Данная возможность может быть использована пользователем для протоколирования команд через sudo, даже когда вызван root shell. Утилита так же поддерживает -e флаг, который будет полезен, даже если будет запущен через sudo-скрипт или программу.

7. Входные и выходные данные

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

Выходными данными являются результаты выполнения запущенных команд.

6. Репозиторий сред исполнения
1. Функциональное назначение

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

2. Описание логической структуры

Файлы с образами дисков могут быть размещены в локальной файловой системе рабочих узлов ресурсных центров. В этом случае модуль разворачивания виртуальных машин на рабочем узле обращается к ним по протоколу NFS.

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

3. Программное обеспечение, необходимое для функционирования программы

К файлам репозитория необходим доступ по протоколу NFS, GridFTP или каким-либо другим стандартным протоколам.

4. Используемые технические средства

Репозиторий располагается на локальных дисках рабочих узлов или на файловых серверах, к которым есть доступ с рабочих узлов протоколу NFS, GridFTP или каким-либо другим стандартным протоколам.

5. Вызов и загрузка

Репозитарий должен быть доступен модулю разворачивания ВМ по протоколу NFS или каким-либо другим стандартным протоколам. Файлы с образами в репозитории должны иметь стандартизованные наименования: названиеОС-типФайловойСистемы-номерВерсииСреды.

6. Входные и выходные данные

Входными данными являются файлы образы дисков с различными средами исполнения.

Выходными данными являются развернутая виртуальная машина с соответствующей средой исполнения.

2. Аппаратная реализация макета

Компоненты макета установлены на специально выделенные для этой цели компьютеры со следующими характеристиками: HP ProLiant DL140G3, 2x Dual-Core Xeon 5150, 2.66GHz, 8GB Memory, 1x160GB SATA HDD. Важно отметить, что эти компьютеры обеспечивают аппаратную поддержку виртуализации, что является необходимым условием для развертывания среды операционной системы WindowsXP с помощью монитора виртуальных машин Xen.

Компьютеры установлены в стойки 42U с распределенным электропитанием 32А на 32 розетки и фронтальным непринудительным охлаждением. Общий вид стоек с компьютерами, на которые установлены компоненты СЗЗ-РСИ показан на рис. ???.

В качестве компонент ППО gLite, необходимых для запуска заданий на грид-ресурсы, а также получения информации о ходе их выполнения и результатов использовались грид-сервисы, установленные в Центре базовых грид-сервисов НИИЯФ МГУ (http://grid.sinp.msu.ru/???).

(а) (б)

Рис.???. Вид компьютерной стойки в которой установлены компоненты системы запуска заданий для различных сред исполнения(СЗЗ-РСИ);
(а) вид спереди; (б) вид сзади.

Сетевая структура, обеспечивающая работу макета, представлена на рис. ???.

Рис.???. Упрощенная схема сетевой структуры, обеспечивающей работу макета СЗЗ-РСИ

3. Техническая документация на компоненты СЗЗ-РСИ и макет системы

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

• на каждый компонент системы запуска
• текст программы (или ссылка на источник открытого кода свободно распространяемого продукта, использующегося в качестве модуля СЗЗ-РСИ) - по ГОСТ 19.401-78;
• описание программы - по ГОСТ 19.402-78;
• спецификация программы - по ГОСТ 19.202-78;
• руководство системного программиста - по ГОСТ 19.503-79;
• руководство программиста - по ГОСТ 19.504-79;
• на разработанный в рамках НИР макет сегмента грида EGEE/РДИГ - эскизная документация в составе:
• конструкторская документации (выполняется в соответствии с ГОСТ 2.125-88) в составе:
• схема структурная (в соответствии с РД 50-34.698-90);
• схема функциональная (в соответствии с РД 50-34.698-90);
• Программная документация в составе:
• описание программы - по ГОСТ 19.402-78;
• описание применения - по ГОСТ 19.502-78;
• текст программы - по ГОСТ 19.401-78.

4. Проведение экспериментальных исследований

В рамках работ на третьем этапе проекта были проведены экспериментальные исследования на макете системы запуска заданий для различных сред исполнения (СЗЗ-РСИ). Целью этих испытаний являлась проверка выполнения требований Технического задания (далее - ТЗ) к СЗЗ-РСИ и, на основании этого, определение возможности проведения на следующем этапе работ комплексных испытаний системы в составе Российского грида для интенсивных операций с данными (РДИГ).

Испытания проводились в соответствии с разработанной на данном этапе Программой и методикой предварительных испытаний (прилагается к данному Отчету) в соответствии с ГОСТ 19.301-79 и требованиями Технического задания и Календарного плана исследований. Программа испытаний предусматривает проведение испытаний отдельных компонент СЗЗ-РСИ, и всей системы в целом. Для этого производилась проверка соответствия характеристик разработанного комплекса функциональным и отдельным иным видам требований, изложенных в ТЗ.

Испытания проводились в три этапа:

1. Приемка документации и проверка комплектности программных и технических средств
2. Испытания качественных характеристик (функциональных возможностей) СЗЗ-РСИ
3. Испытания количественных характеристик работы СЗЗ-РСИ

На первом этапе проводилась проверка комплектности (соответствия ТЗ) и качества программной документации, проверка комплектности состава технических и программных средств и проверка совместимости с операционной системой Linux.

На втором этапе испытаний наряду с контрольной проверкой возможности выполнения на рабочих узлах грида заданий в хостовой операционной системе (ОС) Scientific Linux, осуществлялась проверка возможности выполнения на рабочих узлах грида заданий в гостевых операционных системах Linux/Fedora, Linux/Ubuntu и WindowsXP (п. 4.2.4 ТЗ).

На третьем этапе испытаний оценивались количественные показатели, а именно проводилась проверка выполнения требований п. 4.2.5 ТЗ о том, что дополнительные (накладные) расходы рабочих узлов грид-системы на развертывание "гостевой" среды исполнения для типичных задач не должны превышать

• для ЦПУ - 15%,
• для оперативной памяти - 30%,

а также проверка выполнения требований п. 4.2.6 ТЗ о том, что время выполнения задания на рабочем узле с "гостевой" средой исполнения не должны превышать для типичных вычислительных задач времени исполнения того же задания на аналогичном компьютере, где указанная среда является основной на 15%.

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

П. 4.2.4 ТЗ: Созданная система должна обеспечивать возможность запуска на рабочие узлы, работающие под управлением операционной системы (ОС) Scientific Linux (стандартная ОС для ППО gLite), заданий в среде следующих ОС:

• WindowsXP;
• Fedora Core;
• Ubuntu.

П. 4.2.5 ТЗ: Дополнительные (накладные) расходы рабочих узлов грид-системы на развертывание "гостевой" среды исполнения для типичных задач не должны превышать:

• для ЦПУ - 15%;
• для оперативной памяти - 30%.

П. 4.2.6 ТЗ: Время выполнения задания на рабочем узле с "гостевой" средой исполнения не должны превышать для типичных вычислительных задач времени исполнения того же задания на аналогичном компьютере, где указанная среда является основной на 15%.

Изучение существующей научно-технической литературы, проведенное на первом этапе работы показывает, что по отдельности каждый из перечисленных параметров является достижимым. В частности, как указано в Научно-техническом отчете за первый этап выполнения работ, используя эмуляцию оборудования или полную виртуализацию, можно обеспечить развертывание любых операционных систем, включая указанные в п. 4.2.4 Технического задания. Однако эмуляция оборудования и полная виртуализация являются слишком громоздкими решениями и потребляют значительные ресурсы. Это обстоятельство практически не позволяет удовлетворить требованиям пп. 4.2.5 и 4.2.6 ТЗ.

Таким образом, наиболее предпочтительным типом виртуализации для достижения параметров, определенных Техническим заданием, является паравиртуализация. Благодаря тому, что значительную часть работы по взаимодействию с хостовой платформой в этом подходе берет на себя гостевая ОС, производительность ВМ незначительно отличается от хостовой ОС. Однако при этом остается вопрос о том насколько хорошо этот тип виртуализации и, в частности, конкретная реализация - Xen, поддерживают операционные системы, указанные в п. 4.2.4 ТЗ.

ОС Windows можно запускать как гостевую систему на Xen, но только если он запущен на процессорах типа Intel VT (IVT, Intel Vanderpool) или AMD virtualization (AMD-V, AMD Pacifica). Такая технология процессорной поддержки виртуализации является новой, находится в процессе развития и поэтому в процессе работы по данному контракту необходимо будет экспериментально исследовать удобство развертывания и полноту функциональных свойств операционных систем, указанных в п. 4.2.4 ТЗ, в среде Xen.

Другие экспериментальные исследования необходимы для подтверждения достижимости параметров в пп. 4.2.5 и 4.2.6 ТЗ, связанных с производительность виртуализированных рабочих узлов. Эти экспериментальные исследования необходимы также для оптимизации параметров настройки виртуальных машин и достижения наилучших показателей производительности.

Указанные в данном разделе экспериментальные исследования будут проведены на третьем этапе работ по проекту.

5. Сопоставление результатов тестирования с параметрами, определенными в Техническом задании.

будет дополнено

6. Технико-экономические исследования эффективности внедрения результатов НИР в народное хозяйство

Эффективность научных исследований устанавливается с учетом различных видов проявления полезного эффекта, который может быть получен при использовании результатов НИР. Такими видами эффекта могут быть:

1. научно-технический эффект - характеризуется как накопление новых знаний в области свойств и явлений материального мира, проявляется в виде научных публикаций, докладов, открытий, защищенных диссертаций, изобретений;
2. социальный эффект - проявляется в повышении безопасности дня жизни и здоровья человека, безопасности труда, в улучшении условий труда, снижении вероятности профессиональных заболеваний, повышении экологической безопасности и в получении других социально значимых результатов;
3. экономический эффект - характеризует стоимостную оценку результативности научных исследований, проявляется в снижении себестоимости продукции, работ, услуг, росте прибыли.

В первом случае принято использовать [нтэ1,нтэ2] коэффициент научно-технического эффекта HT - оценку по 10-балльной шкале, рассчитываемую по формуле:

HT = im ribi  ,

где m - количество признаков научно-технического эффекта; ri - балльная оценка i-го признака научно-технического эффекта; bi - уровень значимости i-го признака научно-технического эффекта.

В таблице ??? приведены типовые признаки научно-технического эффекта и значения ri.

Таблица ???. Типовые признаки научно-технического эффекта и значения ri.

Номер приз-нака, i	Признаки научно-технического эффекта		Значения ri
1	Ожидаемый уровень новизны результатов НИР	принципиально новый	10
		относительно новый	4
		не обладающий новизной	0
2	Теоретический уровень, перспективность	установление нового закона, теории	10
		глубокая проработка проблемы	8
		разработка способа, метода, программы	6
3	Возможность практического использования результатов	в течение 1 - 2 лет	10
		в течение 3-5 лет	5
		в течение 5 и более лет	2
		неопределенная	0

В таблице ??? приведены типовые значения bi.

Таблица ???. Типовые признаки научно-технического эффекта и значения bi.

Номер приз-нака, i	Признаки научно-технического эффекта	Значения bi
1	Ожидаемый уровень новизны результатов НИР	0,3
2	Теоретический уровень, перспективность	0,4
3	Возможность практического использования	0,3

Анализ отчетной научно-исследовательской работы показывает, что для нее факторы ri имеют следующие значения: r1 = 10, r2 = 6, r3 = 10. Поэтому оценка HT научно-технического эффекта от данной работы по 10-балльной шкале является следующей:

HT = 10 0,3 + 6 0,4 + 10 0,3 = 8,4

Весовые коэффициенты bi определяются критериями для оценки установленным в Конкурсной документации по проведению открытых конкурсов на право заключения государственных контрактов на выполнение научно-исследовательских работ для государственных нужд в рамках федеральной целевой программы «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2012 годы» (мероприятия 1.2 – VI очередь, 1.3 – VIII очередь, 1.4 – IV очередь, 1.5 – VII очередь 1.6 – VIII очередь). Сравнение относительных величин максимальных баллов, начисляемых заявленным работам за функциональные характеристики (потребительские свойства) и/или качественные характеристики создаваемой научно-технической продукции, приводит к значениям bi (округленным), указанным в Таблице ???.

Таблица ???. Типовые признаки научно-технического эффекта и значения bi.

Номер приз-нака, i	Признаки научно-технического эффекта	Значения bi
1	Ожидаемый уровень новизны результатов НИР	0,25
2	Теоретический уровень, перспективность	0,25
3	Возможность практического использования	0,5

Анализ отчетной научно-исследовательской работы показывает, что для нее факторы ri имеют следующие значения: r1 = 10, r2 = 6, r3 = 10. Поэтому оценка HT научно-технического эффекта от данной работы по 10-балльной шкале является следующей:

HT = 10 0,25 + 6 0,25 + 10 0,5 = 9

Сравнивая полученное значение научно-технического эффекта НИР с максимальным значением научно-технического эффекта, принимаемого равным 10 баллам, можно сделать вывод, что работа существенно превосходит средний уровень.

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

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

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

Экономический эффект Ээф рассчитывается следующим образом:

Ээф = Э – ЕнК,

где Э - суммарная годовая величина экономии средств, полученных в результате внедрения НИР;

Ен — нормативный коэффициент эффективности капиталовложений (норма рентабельности);

К — капиталовложения, в данном случае – сумма сметы затрат на НИР и капиталовложений на внедрение результатов НИР.

Рекомендованные [нтэ3] ориентировочные значения нормы рентабельности (нормативного коэффициента эффективности капиталовложений Ен) в зависимости от видов капиталовложений представлены в Таблице ???.

Таблица ???. Нормы рентабельности в зависимости от видов инвестиций

Вид инвестиций	Цель инвестиций	Норма рентабельности Ен(%)
1	Сохранение позиций на рынке	5—6
2	Повышение качества продукции, обновление основных фондов	min 12
3	Внедрение новых технологий	min 15
4	Увеличение прибыли, накопление финансовых резервов для инновационных проектов	min 18—20
5	Рисковые инновационные проекты, исход которых неясен	min 25

В нашем случае осуществляется внедрение новых технологий. Поэтому Ен  0,15.

В соответствии с контрактом, затраты на НИР (бюджетные и внебюджетные средства) равны 3 млн. руб. (в течение полутора лет осуществления проекта). Программные компоненты СЗЗ-РСИ устанавливаются на тот же аппаратный комплекс, что и другие компоненты промежуточного программного обеспечения (ППО) в ресурсных центрах грид-инфраструктуры, причем предполагается, что инсталляция и сопровождение системы осуществляется тем же штатным составом администраторов ресурсных центров, что и в случае ППО без СЗЗ-РСИ. Поэтому затраты на внедрение результатов НИР связаны только с незначительным увеличением служебных обязанностей администраторов и являются пренебрежимо малыми. Таким образом, К  3 млн. руб.

Наиболее сложно определить суммарную годовую величину экономии средств Э. Представляется возможным дать только нижнюю оценку для этого показателя (и, соответственно, для экономического эффекта Ээф) в расчете на одну организацию, использующую грид-инфраструктуру и нуждающуюся в программах, которые есть на рынке, но для среды исполнения, отличной от хостовой среды рабочих узлов грид-системы. Типичная стоимость лицензий на использование достаточно мощных коммерческих программ (например, для моделирования различных процессов) составляет от 30 до 300 тыс. руб. В то же время минимальная стоимость создания собственного варианта аналогичной программы (для среды исполнения грид-узлов) вряд ли может быть меньше 1 млн. руб. (минимальная годовая зарплата двух квалифицированных программистов). Таким образом, минимальная экономия за счет использования готового продукта (что можно сделать благодаря внедрению СЗЗ-РСИ) составляет 700 тыс. руб. Подставляя это значение в выше приведенную формулу для экономического эффекта Ээф, получаем

Ээф = 700 - 0,15  3000 = 250 тыс.руб.

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

T = K/ Эобщ.эф.

Видно, однако, что если произведение числа организаций на число используемых программ будет порядка 10, выполняемый НИР окупится за срок порядка года. Учитывая широко разворачивающиеся работы в области нанотехнологий и наноиндустрии, для которой задачи компьютерного моделирования с использованием распределенных вычислений являются чрезвычайно актуальными, указанная оценка срока окупаемости НИР представляется вполне реальной.

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

7. Заключение

Таким образом, на третьем этапе выполнения работ по контракту были разработаны алгоритмы работы системы запуска заданий с различными средами исполнения в грид, выяснены взаимосвязи разрабатываемой системы с другими компонентами грид-инфраструктуры, выявлены направления экспериментальных проверок для подтверждения достижимости параметров работы системы, определенных в Техническом задании, проведены патентные исследования. В рамках реализации мероприятий по достижению технико-экономических показателей, зафиксированных в Техническом задании, опубликованы тезисы доклада по теме работы на Международной конференции "XXI International Symposium on Nuclear Electronics & Computing NEC'2007" (Болгария, Варна, 10-17 сентября, 2007 г.): A.Kryukov and I.Gorbunov "First experience of submission to the EGEE/RDIG Grid of jobs prepared for non standard OS's by means virtualization" ("Первый опыт запуска заданий, подготовленных для исполнения в нестандартных ОС, в грид EGEE/РДИГ на основе виртуализации"). По материалам работы и доклада в печать направлена статья, которая будет опубликована в Трудах конференции.

В соответствии с Календарным планом проведены патентные исследования, в результате которых не обнаружено каких-либо материалов, которые бы препятствовали использованию результатов работ в Российской Федерации.

В результате проделанной работы получены следующие основные выводы:

• в рамках грид-инфраструктуры система запуска заданий для различных сред исполнения (СЗЗ-РСИ) должна непосредственно взаимодействовать с подсистемами управления загрузкой и информационного обслуживания и мониторинга грида, а также вычислительными элементами в ресурсных центрах;
• формат запросов на запуск заданий в требуемой среде исполнения должен соответствовать общепринятой схеме GLUE, что обеспечивает совместимость создаваемой системы с подсистемами информационного обслуживания и мониторинга большинства существующих грид-инфраструктур, в том числе EGEE/РДИГ (совместимость с EGEE/РДИГ требуется Техническим заданием);
• требуемая среда исполнения должна указываться в файле описания задания на языке JDL с помощью атрибута " Requirements";
• система запуска заданий для различных сред исполнения должна быть реализована в соответствии с архитектурой и алгоритмами, описанными в разд. 3.2 настоящего Научно-технического отчета;
• для обеспечения общей безопасности грид-инфраструктуры с СЗЗ-РСИ должна использоваться инфраструктуры безопасности грида Globus GSI и программа "sudo";
• для подтверждения достижимости параметров работы системы, определенных в Техническом задании, необходимы экспериментальные исследования, указанные в разд. 4 настоящего Научно-технического отчета.

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

Задачи третьего этапа осуществления проекта выполнены полностью.

8. Список использованных источников

1. Промежуточное программное обеспечение gLite: http://glite.web.cern.ch/glite
2. Проект EGEE: http://www.eu-egee.org
3. Проект RDIG: http://egee-rdig.ru
4. Foster и др. "Open Grid Services Architecture (OGSA) v1.0", http://www.gridforum.org/documents/GFD.30.pdf
5. Менеджер ресурсов хранения данных (SRM): http://sdm.lbl.gov/srm-wg
6. Схема GLUE: http://glueschema.forge.cnaf.infn.it, http://forge.ogf.org/sf/projects/glue-wg
7. Язык описания заданий (JDL): Job Description Language HowTo, DataGrid-01-TEN-0102-0_2, http://server11.infn.it/workload-grid/docs/DataGrid-01-TEN-0102-0_2-Document.doc
8. GT 4.0 Pre WS GRAM: Developer Guide, http://www.globus.org/toolkit/docs/4.0/developer-index.html
9. Проект Globus: http://www.globus.org
10. Программа sudo: http://www.sudo.ws/sudo
11. Язык UML: http://www.uml.org
12. Протокол FTP: http://rfc.net/rfc959.html; http://rfc.net/rfc1579.html
13. FTP-сервер Pure-FTPd: http://www.pureftpd.org
14. Методика определения экономической эффективности использования в народом хозяйстве новой техники, изобретений и рационализаторских предложений, - М.: ВНИИПИ, 1986. - 52 с.
15. Макконел, К.Р. Брю С.Л. Экономикс – принципы, проблемы и политика пер. с англ., М.: ИНФРА-М, 2003, 785с.
16. Е.Г. Непомнящий "Экономика и управление предприятием: Конспект лекций" Таганрог: Изд-во ТРТУ, 1997