Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

Кемеровский государственный университет

Математический факультет

Кафедра ЮНЕСКО по Новым информационным технологиям

Специальность 010503 - «Математическое обеспечение и администрирование информационных систем»

ДИПЛОМНАЯ РАБОТА

Тема:

Разработка компонентов системы удаленного доступа и управления распределенными вычислительными ресурсами

Выполнил студент 5 курса

Окулов Николай Николаевич

Руководитель: К.Е. Афанасьев

д-р физ.-мат. наук, профессор

Кемерово 2014



СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• Обзор систем управления вычислительными ресурсами
• Требования к системе УД и УРВР
• Архитектура системы УД и УРВР
• Структура пользовательских данных
• Система УД к ВР
• Принцип работы пакета KemsuWeb
• ER-модель базы данных системы УД и УРВР
• ГЛАВА 1. РАЗРАБОТКА КОМПОНЕНТА «ИНТЕРФЕЙС АДМИНИСТРАТОРА» СИСТЕМЫ УДАЛЕННОГО ДОСТУПА К ВЫЧИСЛИТЕЛЬНЫМ РЕСУРСАМ
• 1.1 Определение функций администратора
• 1.2 Моделирование администраторской части системы УД к ВР
• 1.3 Требования к компоненту «Интерфейс администратора»
• 1.4 Описание web-форм и их реализация
• 1.5 Описание пакета p_admin
• ГЛАВА 2. РАЗРАБОТКА КОМПОНЕНТА «ИНТЕРФЕЙС КЛИЕНТА» СИСТЕМЫ УДАЛЕННОГО ДОСТУПА К ВЫЧИСЛИТЕЛЬНЫМ РЕСУРСАМ
• 2.1 Определение функций клиента
• 2.2 Моделирование клиентской части системы УД к ВР
• 2.3 Требования к компоненту «Интерфейс клиента»
• 2.4 Описание web-форм и их реализация
• 2.6 Описание пакета p_client
• ГЛАВА 3. РАЗРАБОТКА КОМПОНЕНТА «ВИРТУАЛЬНАЯ ЛАБОРАТОРИЯ» СИСТЕМЫ УДАЛЕННОГО ДОСТУПА К ВЫЧИСЛИТЕЛЬНЫМ РЕСУРСАМ
• 3.2 Определение функций
• 3.3 Моделирование
• 3.4 Требования к компоненту «Виртуальная лаборатория»
• 3.5 Описание web-форм и их реализация
• 3.6 Описание пакета p_virtlab
• ЗАКЛЮЧЕНИЕ
• СПИСОК ЛИТЕРАТУРЫ
• СПИСОК СОКРАЩЕНИЙ
• ПРИЛОЖЕНИЯ

• ВВЕДЕНИЕ
• В настоящее время вычислительные системы кластерного типа получают все большее распространение. Это обусловлено различными факторами, главным из которых является насущная потребность в решении актуальных задач фундаментальной и прикладной науки, для анализа и исследования которых производительности существующих средств вычислительной техники оказывается недостаточно. [18]
• Grand challenges - это фундаментальные научные или инженерные задачи с широкой областью применения, эффективное решение которых возможно только с использованием мощных (суперкомпьютерных) вычислительных ресурсов.

Вот лишь некоторые области, где возникают задачи подобного рода: предсказания погоды, климата и глобальных изменений в атмосфере, гидро- и газодинамика, науки о материалах, разведка нефти и газа, управляемый термоядерный синтез, генетика человека и многие другие области. [20]

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

Рост популярности кластерных решений в научной и академической среде привел к появлению практически в каждом ВУЗе страны набора кластеров, как высокопроизводительных для научных расчетов, так и относительно низкопроизводительных для обучения студентов и отладки программ. [21]

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

Многие организации, а особенно университеты, имеют несколько компьютерных классов, на базе каждого из которых легко может быть организован однородный кластер. Так, например, в ЦНИТ КемГУ организован распределенный вычислительный ресурс на базе уже существующих учебных компьютерных классов, включенных в единую университетскую сеть. [21]

При поддержке аналитической ведомственной целевой программы «Развитие научного потенциала высшей школы (2006-2014 годы)» в КемГУ был создан информационно-вычислительный портал для организации учебной и научной деятельности ВУЗа, одной из подсистем которого является система УД и УРВР.

Обзор систем управления вычислительными ресурсами

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

В настоящее время наиболее развиты и представляют интерес несколько систем управления прохождением заданиями. Сделаем их краткий обзор. [11]

Load Leveler

Данная система разработана и поддерживается компанией IBM. Это стандартная система управления прохождением заданиями для мейнфреймов под управлением ОС AIX. В данной системе поддерживается детальное описание ресурсов, необходимых для задачи. По этому описанию система пытается найти наилучший из доступных компьютеров для запуска.

Единицей измерения вычислительных ресурсов в Load Leveler является компьютер. Это не обязательно должен быть физически один компьютер, это может быть очередь NQS (Network Queue System), обслуживающая вычислительный кластер.

Load Leveler изначально ориентирована на однопроцессорные задачи, но в настоящее время поддерживает и параллельные среды. Однако набор их весьма невелик и ограничивается IBM Parallel Environment Library (POE/MPI/LAPI) 2.4.0, Parallel Virtual Machine (PVM) 3.3 (на архитектуре RS6K architecture) и Parallel Virtual Machine (PVM) 3.3.11+ (на архитектуре SP2MPI).

Важной особенностью Load Leveler является поддержка контрольных точек, как для последовательных, так и для параллельных приложений. Система активно используется во всём мире. Например, под её управлением работает комплекс Regatta, установленный на факультете ВМиК МГУ им. М.В. Ломоносова в Москве.

Condor

Изначальное предназначение системы Condor - использование времени простоя компьютеров для счёта задач. В обычном режиме компьютер может использоваться как рабочая станция, а когда пользователь не работает за компьютером, Condor запускает на нём задачи. Эта система была разработана в 1988 году и продолжает активно развиваться.

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

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

OpenPBS (TorquePBS)

OpenPBS - одна из самых популярных систем на сегодняшний день. К сожалению, сейчас проект OpenPBS заморожен и не развивается, хотя есть его коммерческая версия OpenPBS Pro, которая развивается и поддерживается. Существует новый проект, основанный на OpenPBS - TorquePBS, который унаследовал от предшественника все достоинства, но и большинство недостатков.

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

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

Queue

Интерфейс к системе представляет собой расширенную замену стандартного сервиса rsh. Задачи, запущенные через Queue, запускаются на том вычислительном узле, который наименее загружен в данный момент. Загруженность узла определяется по количеству запущенных на нём задач. Таким образом, Queue осуществляет балансировку загрузки вычислительных узлов кластера. Запуск параллельных задач возможен при условии, что запуск процессов задачи осуществляется с помощью rsh (как сделано в реализации mpich_p4).

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

Система управления прохождением задач в системе МВС-1000/М

Эта система разработана в Институте прикладной математики им. М.В. Келдыша РАН специально для суперкомпьютера МВС-1000/М коллективом в составе: Баранов А.В., Лацис А.О., Храмцов М.Ю., Шарф С.В. Данная система сразу была ориентирована на запуск параллельных задач на больших кластерных установках и гарантированное освобождение вычислительных узлов по окончании работы задач. Постановка задачи в очередь осуществляется с помощью написания своего командного файла, в котором описываются необходимые ресурсы. Планировщик, поддерживаемый этой системой, принимает во внимание не только заказанные для задачи ресурсы, но и время, которое пользователь уже потратил на счёт. Если пользователь превысил заданный порог отведённого ему времени, то приоритет его задач понижается. Таких порогов может быть задано несколько. Алгоритм планирования не может быть изменён без внесения правок в код системы.

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

NQS/NQE

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

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

В NQS не предусмотрена поддержка параллельных задач. Проект не развивается с 1992 года.

Для работы с несколькими очередями NQS применяется система NQE (Network Queue Envinronment), которая может выбирать, в какую очередь посылать запрос. Проект NQE поддерживался компанией Silicon Graphics, но с 1993 года не развивается.



DQS

Система DQS во многом аналогична NQS, но имеет возможность учитывать ограничения, указанные в скрипте при добавлении задачи в очередь. Параллельные задачи не поддерживаются. Проект не развивается с 1996 года. Существовала коммерческая реализация DQS - Codine. Однако последний проект в данный момент закрыт и не поддерживается.

LSF

Наверное, самая развитая в рассматриваемой области система. К сожалению, полной документации по ней нет в открытом доступе, т.к. эта система является коммерческой. LSF разработана в компании Platform. Поддерживаются как обычные, так и параллельные приложения. Система может управлять несколькими кластерами одновременно.

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

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

Требования к системе УД и УРВР

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

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

— обеспечить пользователю удобный графический интерфейс для работы с системой в удаленном режиме;

— следить за состоянием доступных вычислительных ресурсов;

— принимать от пользователей файлы с расчетными программами и начальными данными, компилировать их на кластере, ставить в очередь на запуск;

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

— сообщать пользователю информацию о состоянии его расчетов (в очереди, выполняется, выполнен);

— передавать пользователю файлы с результатами работы его программ;

— ограничивать доступ пользователей к расчетам других пользователей.

На основе этих требований были определены задачи, которые и должна решать создаваемая система:

— хранение файлов расчетных программ пользователей ИС (далее «программ») в виде исходного и/или бинарного кода, файлов начальных данных, результатов и другой информации, необходимой для проведения научных расчетов;

— хранение и сопровождение информации (метаданных) о файлах и других объектах пользователей;

— передача файлов с кодами программ, начальными данными или результатами между пользовательским приложением и хранилищем данных;

— создание, удаление и управление пользователем своими объектами (файлами, расчетами);

— хранение информации о доступных вычислительных ресурсах;

— отслеживание состояния доступных удаленных вычислительных ресурсов;

— отслеживание состояния расчетных программ на удаленных вычислительных ресурсах;

— передача файлов между хранилищем и удаленными вычислительными ресурсами;

— передача команд на удаленные вычислительные ресурсы;

— определение очередности запуска программ в случае существования конкуренции за вычислительные ресурсы. [21]

Архитектура системы УД и УРВР

Система УД и УРВР построена по трехзвенной архитектуре «клиент - сервер - удаленный агент». В состав серверной части входят: сервер приложений, сервер баз данных и сервер управления кластерами (менеджер вычислительных ресурсов). Общая структура системы приведена на рисунке 1.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 1 - Структура системы УД и УРВР

Так как система является частью информационно-вычислительного портала КемГУ, то пользователь взаимодействует с системой посредством web-браузера. В качестве хранилища данных выступает СУБД Oracle, а связующим звеном браузера пользователя и хранилища является web-сервер приложений Tomcat, который осуществляет динамическую генерацию страниц с использованием пакета KemsuWeb. Такая архитектура позволяет работать с системой из любой точки, имеющей выход в Интернет, а также обеспечивает независимость от платформы и минимальные системные требования к аппаратному обеспечению пользователя. Менеджер вычислительных ресурсов обеспечивает передачу агентам, размещенным на вычислительных кластерах, файлов из хранилища и запросов на генерацию исполняемого кода и выполнение расчетов, а также осуществляет прием результатов расчетов и размещение их в хранилище данных. [21]

Взаимодействие менеджера вычислительных ресурсов с базой данных осуществляется через прикладной интерфейс OCCI (Oracle C++ Call Interface) - низкоуровневый интерфейс, предназначенный для выполнения операций с базой данных Oracle (например, для входа в систему, разбора и исполнения SQL-предложений, получения записей и т.д.). [24]

Структура пользовательских данных

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

Основными объектами, которые обрабатываются системой, являются:

— расчет - совокупность выполняемого кода программы и начальных данных;

— задание - совокупность расчета и параметров его запуска: выбранный кластер, количество процессоров, время старта.

Основной семантической единицей, с которой работает сервер, является задание. Для пользователя же задание является лишь малой частью проекта, который имеет следующую структуру:



Проект:

— файл исходного кода (1 .. *);

— make-файл (0 .. 1);

— параметры:

— архитектура вычислительной системы (1);

— операционная система (1);

— параллельная библиотека (1);

— компилятор (1);

— исполняемый файл (0 .. 1) или файл ошибки компиляции (0 .. 1);

— серия (1 .. *):

- подсерия (0 .. *):

— расчет (0 .. *):

- файл начальных данных (0 .. *);

- задание (0 .. *):

— файл промежуточного результата (0 .. *);

— файл ошибки (0 .. 1) или файл результата (0 .. 1);

- расчет (0 .. *):

- файл начальных данных (0 .. *);

- задание (0 .. *):

— файл промежуточного результата (0 .. *);

— файл ошибки (0 .. 1) или файл результата (0 .. 1).

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2 - Структура пользовательских данных в хранилище

Состояния задания на запуск разделяются на 4 основные группы:

— Начальные состояния, связанные с ожиданием на сервере (New, Scheduled, Wait, NewBlocked, ScheduledBlocked, WaitBlocked);

— Состояния, связанные с обработкой на кластере (например, WaitOnCluster, ProcessingOnCluster);

— Состояния, связанные с созданием результата (например, DoneOnCluster, ResultCreated, DoneWithErrorOnCluster, RunErrorCreated);

— Терминальные («тупиковые») состояния (DeleteOnServerError, GetResultErrorOnCluster и др.).

Рисунок 3 - Диаграмма состояний проекта

Сначала задание обрабатывается на сервере, далее передается для обработки на кластер, а затем происходит получение результата работы программы с кластера и процесс формирования результата в базе данных. Расчетная программа может завершиться либо успешно (в этом случае в БД генерируется объект типа «результат»), либо завершиться с ошибкой (текстовый файл с ошибкой также размещается в БД). В случае ошибки при создании результата в БД, задание может попасть в одно из терминальных состояний. Такие состояния обрабатываются вручную администратором. Из ряда состояний задача может быть удалена.

Основные этапы жизненного цикла задания на компиляцию аналогичны заданию на запуск.

Диаграммы состояний заданий на запуск и на компиляцию представлены на рисунках 4 и 5 соответственно.

Система УД к ВР

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 6 - Структура системы УД к ВР

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

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

Рисунок 4 - Диаграмма состояний задания на запуск

Рисунок 5 - Диаграмма состояний задания на компиляцию

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

Принцип работы пакета KemsuWeb

Логика приложения реализуется на сервере приложений и сервере баз данных. В качестве сервера приложений используется Apache Tomcat, предназначенный для реализации технологии Java Servlets и выполняющий функции web-сервера. В качестве системы управления базой данных был использован Oracle 10 DataBase Server. В качестве клиента к системе используется стандартный web-браузер, обмен данными проходит по стандартным сетевым протоколам в среде Intranet/Internet.

Рисунок 7 - Архитектура системы на физическом уровне

Логика приложения на стороне сервера базы данных реализована в виде набора пакетов: для функциональных блоков создаются пакеты для осуществления операций с данными, обеспечивающие манипуляцию необходимыми данными путем вызова хранимых процедур. Для реализации пакетов используется язык PL/SQL. Для реализации web-интерфейса используются технологии J2EE и XML.

На сервере приложений Apache Tomcat использована библиотека KemsuWeb, которая обеспечивает единую среду для создания приложений, основанных на трехуровневой архитектуре в среде Internet за счет адаптеров, которые удовлетворяют различные потребности разработчика: в операциях с Oracle, в защите информации, в управлении ходом приложения. Пакет разработан в ЦНИТ КемГУ. [9]



Рисунок 8 - Архитектура реализации

Разработчик создает XSLT-шаблоны оформления интерфейса пользователя и XML-файлы, в которых описывается вызов хранимых процедур и обработка полученных результатов с использованием специальных "команд", которые описываются элементами из пространства имен "res=http://www.kemsu.ru/xml-response" и "req=http://www.kemsu.ru/xml-request".

Web-клиент посылает HTTP-запрос сервлету RequestController. Сервлет извлекает параметры из HTTP-запроса, включая URL, т.е. адрес XML-файла, который в дальнейшем преобразуется в абсолютный путь к файлу. Сервлет создает экземпляр класса XMLTraslator, передавая ему HTTP-запрос и путь к запрошенному файлу. Если в XML-файле встречаются элементы из специального пространства имен, создается адаптер и ему делегируется обработка таких элементов. Из XML-файла извлекается путь к шаблону трансформации XSLT main.xsl. Этот шаблон в свою очередь импортирует шаблон default.xsl, который обеспечивает механизм простого оформления результатов запросов в ответ на "команды", описываемых в XML-файле и tree.xsl, который содержит структуру WEB-приложения и шаблоны-функции для различных действий с этой структурой. В завершение main.xsl динамически оформляет XHTML-файл, который возвращается web-клиенту при помощи сервлета (рисунок 9).

Рисунок 9 - Архитектура web-интерфейса

ER-модель базы данных системы УД и УРВР

ER-модель базы данных системы УД и УРВР содержит 37 сущностей с общим количеством атрибутов свыше 200. Полная ER-модель базы данных приведена на рисунке 10. Далее приведено краткое описание основных сущностей ER-модели:

T_PROJECT - содержит информацию о пользовательских проектах.

T_SERIES - содержит информацию о сериях расчетов.

T_CALCULATION - содержит информацию о расчетах.

T_TASK - содержит информацию о заданиях на запуск.

T_COMPILATION_TASK - содержит информацию о заданиях на компиляцию.

T_CALCULATOR - содержит информацию о вычислительных ресурсах (кластерах).

T_RESULT - содержит информацию о файлах результатов заданий.

T_RUN_ERROR - содержит информацию о файлах ошибок.

T_SOURCE_CODE - содержит информацию о файлах исходных кодов программ.

T_INPUT_DATA - содержит информацию о файлах начальных данных расчетов.

T_USER - содержит информацию о пользователях системы.

T_USERS_GROUP - содержит информацию о группах пользователей.

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

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

T_LOG - содержит информацию о всех событиях в системе.

T_FILE - содержит пользовательские файлы всех типов и информацию о них.

Целью данной работы является разработка и реализация компонентов «Интерфейс администратора», «Интерфейс клиента» и «Виртуальная лаборатория» системы УД и УРВР. В соответствии с целью работы были поставлены следующие задачи:

- изучить пакет KemsuWeb и освоить необходимые программные средства и языки (HTML, XML, PL/SQL, JavaScript);

- изучить архитектуру и принципы функционирования системы УД и УРВР; определить требования к разрабатываемым компонентам;

- построить модели разрабатываемых компонентов системы;

- реализовать компоненты.

Рисунок 10 - ER-модель БД системы УД и УРВР

В главе 1 описаны основные этапы процесса разработки компонента «Интерфейс администратора» системы УД и УРВР, приведены модели, поясняющие механизм работы компонента, а также даны описания web-форм и пакета p_admin, содержащего процедуры и функции, необходимые для реализации компонента.

В главе 2 описаны основные этапы процесса разработки компонента «Интерфейс клиента» системы УД и УРВР, приведены модели, поясняющие механизм работы компонента, а также даны описания web-форм и пакета p_client, содержащего процедуры и функции, необходимые для реализации компонента.

В главе 3 описаны основные этапы процесса разработки компонента «Виртуальная лаборатория» системы УД и УРВР, приведены модели, поясняющие механизм работы компонента, а также даны описания web-форм и пакета p_virtlab, содержащего процедуры и функции, необходимые для реализации компонента.



ГЛАВА 1. РАЗРАБОТКА КОМПОНЕНТА «ИНТЕРФЕЙС АДМИНИСТРАТОРА» СИСТЕМЫ УДАЛЕННОГО ДОСТУПА К ВЫЧИСЛИТЕЛЬНЫМ РЕСУРСАМ

1.1 Определение функций администратора

Любая сложная информационная система нуждается в администрировании. Для осуществления функций по администрированию системы УД и УРВР понадобилась реализация отдельного компонента «Интерфейс администратора». Администратор отвечает за работоспособность системы в целом. Для этого он наделен соответствующими возможностями по управлению объектами БД системы УД и УРВР.

Были определены следующие функции администратора системы УД и УРВР:

- Управление кластерами:

- Просмотреть список вычислительных ресурсов (кластеров), подключенных к системе;

- Добавить кластер в систему (добавить информацию о новом кластере);

- Удалить кластер из системы;

- Заблокировать кластер (в случае временной неисправности);

- Изменить атрибуты кластера;

- Перезагрузить кластер;

- Управление очередью заданий:

- Просмотреть очередь заданий;

- Заблокировать задание;

- Удалить задание (с отправкой клиенту промежуточных результатов или без);

- Изменить приоритет задания;

- Просмотр и анализ статистики использования системы:

- Просмотреть журнал событий;

- Просмотреть общую статистику использования системы;

- Просмотреть статистику по определенному кластеру;

- Просмотреть статистику по определенному пользователю;

- Управление пользователями и группами:

- Просмотреть списки пользователей и групп;

- Назначить (изменить) права на доступ пользователей к кластерам;

- Назначить (изменить) права на доступ групп пользователей к кластерам;

- Назначить (изменить) атрибуты пользователей, (в том числе, принадлежность группам и приоритеты).

1.2 Моделирование администраторской части системы УД к ВР

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

— Диаграмма вариантов использования;

— Диаграмма связей между web-формами.

Диаграмма вариантов использования для администратора системы УД и УРВР представлена на рисунке 11.

Управлять кластерами. Администратор должен иметь возможность просматривать список кластеров в системе, добавлять в систему новые кластеры, блокировать/разблокировать (при неисправностях или профилактических работах на кластере), перезагружать и удалять кластеры, а также изменять их атрибуты.

Управлять очередью заданий. Администратор должен иметь возможность просматривать очередь заданий, блокировать и разблокировать задания, изменять приоритет заданий, а также удалять задания (например, при подозрении на «зависание»). Доступность этих операций определяется статусом задания. В зависимости от статуса удаляемого задания в некоторых случаях клиенту могут прийти промежуточные результаты.

Рисунок 11 - Диаграмма вариантов использования (администратор)

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

Управлять пользователями. Администратор должен иметь возможность просматривать списки пользователей и групп, назначать пользователям и группам права на доступ к кластерам, а также изменять атрибуты пользователей (например, добавлять пользователя в группу или исключать из нее, назначать (изменять) приоритеты).

На рисунке 12 представлена диаграмма связей между web-формами интерфейса администратора.



Рисунок 12 - Диаграмма связей между web-формами интерфейса администратора

1.3 Требования к компоненту «Интерфейс администратора»

Функциональные требования:

— Реализация основных функций администратора в соответствии с пунктом 1.1.

Требования к прикладному ПО:

— Доступ к системе должен осуществляться в удаленном режиме посредством web-браузера.

Системные требования:

— Для обеспечения интеграции с системой УД и УРВР, компонент должен строиться на основе СУБД Oracle, сервера приложений Tomcat и пакета KemsuWeb.

Требования к web-интерфейсу:

— Наличие кнопок навигации по формам (перехода на родительские формы);

— Отображение всей необходимой информации об объектах;

— Генерация предупреждений при удалении объектов;

— Наличие возможностей сортировки и фильтрации отображаемой информации.

1.4 Описание web-форм и их реализация

В соответствии пунктом 1.3, были определены необходимые для компонента «Интерфейс администратора» web-формы и их содержание. Реализация web-форм показана на рисунках.

Функции управления кластерами

1. Форма «Рабочий стол администратора» (рисунок 13). На данной форме расположены ссылки на группы функций (разделы) с описанием доступных действий в данном разделе. При нажатии на ссылку, осуществляется переход на соответствующую форму.

Рисунок 13 - Рабочий стол администратора (all_view.htm)

2. Форма просмотра состояния кластеров (рисунок 14). На данной форме отображается список кластеров в системе, а также некоторые их атрибуты, такие как: идентификатор кластера, название, описание, архитектура, операционная система, количество процессоров (общее и доступное), максимальное количество задач, количество запущенных задач, статус, состояние, объем памяти (общий и доступный). Доступны операции изменения параметров кластера, блокирования/разблокирования, удаления, перезагрузки кластера, добавления нового кластера, а также просмотра статистики по кластеру. При выборе определенной операции, осуществляется переход на соответствующую ей web-форму.

Рисунок 14 - Просмотр состояния кластеров (cluster_view.htm)

3. Форма добавления кластера (рисунок 15). На данной форме можно задать основные атрибуты нового кластера, такие как: название, описание, архитектура, операционная система, количество процессоров, максимальное количество задач, статус, объем памяти. Значения атрибутов «Архитектура» и «ОС» задаются с помощью выпадающих списков, содержимое которых формируется запросом к БД. При нажатии на кнопку «Добавить», информация о новом кластере заносится в базу данных, и осуществляется переход на форму просмотра состояния кластеров.

Рисунок 15 - Добавление кластера (cluster_add.htm)

4. Форма изменения параметров кластера (рисунок 16). Данная форма позволяет изменить основные атрибуты выбранного кластера, такие как: название, описание, архитектура, операционная система, количество процессоров, максимальное количество задач, статус, объем памяти. Значения атрибутов «Архитектура» и «ОС» задаются с помощью выпадающих списков, содержимое которых формируется запросом к БД. При нажатии на кнопку «Применить изменения», обновленная информация заносится в базу данных, и осуществляется переход на форму просмотра состояния кластеров. Доступны операции блокирования/разблокирования, удаления, перезагрузки кластера, а также просмотра статистики по кластеру. При выборе определенной операции, осуществляется переход на соответствующую ей web-форму. Для удобства работы, на этой форме отображается список заданий, выполняемых на изменяемом кластере, и доступных операций с ними, а также полная информация о заданиях. Имеются возможности сортировки и фильтрации заданий по любому атрибуту.

Рисунок 16 - Изменение параметров кластера (cluster_set.htm)

5. Форма блокирования кластера (рисунок 17). На данной форме можно заблокировать/разблокировать кластер. Отображаются основные атрибуты выбранного кластера и список выполняемых на нем заданий. Для удобства работы, на этой форме отображается список заданий, выполняемых на блокируемом кластере, и доступных операций с ними, а также полная информация о заданиях. Имеются возможности сортировки и фильтрации заданий по любому атрибуту. При нажатии кнопки «Заблокировать» или кнопки «Разблокировать», изменяется статус выбранного кластера, и осуществляется переход на форму просмотра состояния кластеров. Доступна операция просмотра статистики по кластеру.

6. Форма удаления кластера (рисунок 18). Данная форма позволяет удалить кластер. Отображаются основные атрибуты выбранного кластера и список выполняемых на нем заданий. Для удобства работы, на этой форме отображается список заданий, выполняемых на удаляемом кластере, и доступных операций с ними, а также полная информация о заданиях. Имеются возможности сортировки и фильтрации заданий по любому атрибуту. При нажатии на кнопку «Удалить», информация о данном кластере удаляется из базы данных, и осуществляется переход на форму просмотра состояния кластеров. Доступна операция просмотра статистики по кластеру.

Рисунок 17 - Блокирование кластера (cluster_block.htm)



Рисунок 18 - Удаление кластера (cluster_del.htm)

7. Форма перезагрузки кластера (рисунок 19). На данной форме можно перезагрузить кластер. Отображаются основные атрибуты выбранного кластера и список выполняемых на нем заданий. Для удобства работы, на этой форме отображается список заданий, выполняемых на перезагружаемом кластере, и доступных операций с ними, а также полная информация о заданиях. Имеются возможности сортировки и фильтрации заданий по любому атрибуту. При нажатии на кнопку «Перезагрузить», в БД происходит изменение статуса кластера, вследствие чего, на кластер должна отправляться команда на перезагрузку. В настоящее время данная функция не поддерживается системой УД и УРВР. Доступна операция просмотра статистики по кластеру.

Рисунок 19 - Перезагрузка кластера (cluster_reload.htm)



Функции управления очередью заданий

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

Рисунок 20 - Просмотр очереди заданий (queue_view.htm)

9. Форма изменения приоритета задания (рисунок 21). На данной форме можно изменить приоритет задания. Отображаются основные атрибуты выбранного задания. При нажатии на кнопку «Применить изменения», обновленная информация заносится в базу данных, и осуществляется переход на форму просмотра очереди заданий. Данная операция доступна, если задание находится либо в состоянии «Поставлено в очередь», либо в состоянии «Ожидает».



Рисунок 21 - Изменение приоритета задания (queue_set.htm)

10. Форма блокирования задания (рисунок 22). Данная форма позволяет заблокировать/разблокировать задание. Отображаются его основные атрибуты. При нажатии кнопки «Заблокировать» или кнопки «Разблокировать», соответственным образом изменяется статус выбранного задания, и осуществляется переход на форму просмотра очереди заданий. Данная операция доступна, если задание находится в одном из следующих состояний: «Новое», «Поставлено в очередь», «Ожидает» или «Заблокировано» (т.е. до того, как задание было запущено на кластере).

Рисунок 22 - Блокирование задания (queue_block.htm)

11. Форма удаления задания (рисунок 23). На данной форме можно удалить задание. Отображаются основные атрибуты выбранного задания. При нажатии на кнопку «Удалить», задание помечается на удаление, и осуществляется переход на форму просмотра очереди заданий. В связи с использованием информации о заданиях для сбора статистики и расчета приоритетов пользователей, задания физически не удаляются из базы данных. Данная операция доступна, если задание находится в одном из состояний, связанных с ожиданием на сервере или обработкой на кластере.

Функции просмотра статистики использования системы

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

Рисунок 23 - Удаление задания (queue_del.htm)

Рисунок 24 - Просмотр журнала событий (log_view.htm)

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

14. Форма просмотра статистики по кластеру. Данная форма предоставляет подробную информацию об использовании конкретных кластеров системы. Здесь отображаются основные характеристики использования ВР. Форма находится в разработке.

15. Форма просмотра статистики по пользователю. Данная форма предоставляет подробную информацию об активности конкретных пользователей системы. Здесь отображаются основные характеристики использования системы. Форма находится в разработке.

Функции управления пользователями

16. Форма управления пользователями. На данной форме будут доступны функции: просмотра списков пользователей и групп, назначения пользователям и группам прав на доступ к кластерам и изменения атрибутов пользователей, в частности, принадлежности группам. При реализации этих функций, будут производиться манипуляции с данными в таблицах T_ACCESS, T_GROUP_ACCESS, T_USER и T_USER_GROUP. Форма находится в разработке.

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

Для обеспечения работы функций интерфейса администратора, также был реализован ряд web-форм служебного назначения, посредством которых происходит вызов хранимых в БД процедур и функций из пакета p_admin.

Список служебных форм:

- cluster_add2.htm - вызывает функцию добавления нового кластера;

- cluster_block2.htm - вызывает функции блокирования/разблокирования кластера;

- cluster_del2.htm - вызывает функцию удаления кластера;

- cluster_reload2.htm - вызывает функцию перезагрузки кластера;

- cluster_set2.htm - вызывает функцию изменения параметров кластера;

- queue_block2.htm - вызывает функцию блокирования задания;

- queue_set2.htm - вызывает функцию изменения приоритета задания;

- queue_del2.htm - вызывает функцию физического удаления задания;

- task_res.htm - вызывает функции удаления задания и получения промежуточных результатов.

1.5 Описание пакета p_admin

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

Состав пакета p_admin:

cluster_add - процедура добавления кластера;

Входные параметры:

- in_name (VARCHAR2) - имя кластера,

- in_description (VARCHAR2) - описание кластера,

- in_arch_id (NUMBER) - идентификатор архитектуры кластера,

- in_os_id (NUMBER) - идентификатор операционной системы кластера,

- in_proc_num (NUMBER) - число процессоров в кластере,

- in_max_task (NUMBER) - максимальное число заданий, обрабатываемых кластером одновременно,

- in_status (VARCHAR2) - статус кластера,

- in_mem (NUMBER) - объем памяти кластера;

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

cluster_block - процедура для блокирования или разблокирования кластера;

Входные параметры:

- in_id (NUMBER) - идентификатор кластера;

- in_action (NUMBER) - код операции (блокировать или разблокировать);

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

cluster_del - процедура удаления кластера;

Входной параметр:

- in_id (NUMBER) - идентификатор кластера;

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

cluster_set - процедура изменения параметров кластера;

Входные параметры:

- in_id (NUMBER) - идентификатор кластера,

- in_name (VARCHAR2) - имя кластера,

- in_description (VARCHAR2) - описание кластера,

- in_arch_id (NUMBER) - идентификатор архитектуры кластера,

- in_os_id (NUMBER) - идентификатор операционной системы кластера,

- in_proc_num (NUMBER) - число процессоров в кластере,

- in_max_task (NUMBER) - максимальное число заданий, обрабатываемых кластером одновременно,

- in_status (VARCHAR2) - статус кластера,

- in_mem (NUMBER) - объем памяти кластера;

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

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

Входные параметры:

- in_sort (VARCHAR2) - имя атрибута, по которому будет выполняться сортировка,

- in_prdk (VARCHAR2) - показатель направления сортировки (asc/desc),

- in_fltr_id (VARCHAR2) - показатель применения фильтрации событий по идентификатору,

- in_fltr_class (VARCHAR2) - показатель применения фильтрации событий по категории,

- in_fltr_date (VARCHAR2) - показатель применения фильтрации событий по времени происхождения,

- in_op_id (VARCHAR2) - название операции сравнения при фильтрации событий по идентификатору,

- in_op_class (VARCHAR2) - название операции сравнения при фильтрации событий по категории,

- in_op_date (VARCHAR2) - название операции сравнения при фильтрации событий по времени происхождения,

- in_value_id (VARCHAR2) - сравниваемое значение при фильтрации событий по идентификатору,

- in_value_class (VARCHAR2) - сравниваемое значение при фильтрации событий по категории,

- in_value_date (VARCHAR2) - сравниваемое значение при фильтрации событий по времени происхождения;

Выходной параметр:

- out_queue (REF CURSOR) - курсор, содержащий список событий и сопутствующую информацию.

queue_block - процедура для блокирования или разблокирования задания;

Входные параметры:

- in_id (NUMBER) - идентификатор задания;

- in_action (NUMBER) - код операции (блокировать или разблокировать);

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

queue_del - процедура физического удаления задания;

Входной параметр:

- in_id (NUMBER) - идентификатор задания;

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

queue_set - процедура изменения приоритета задания;

Входные параметры:

- in_id (NUMBER) - идентификатор задания,

- in_rank (NUMBER) - значение приоритета задания;

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

queue_op_SetRank (NUMBER) - функция, определяющая доступность операции изменения приоритета задания;

Входные параметры:

- in_id (NUMBER) - идентификатор задания.

queue_op_Block (NUMBER) - функция, определяющая доступность операции блокирования задания;

Входные параметры:

- in_id (NUMBER) - идентификатор задания.

queue_op_UnBlock (NUMBER) - функция, определяющая доступность операции разблокирования задания;

Входные параметры:

- in_id (NUMBER) - идентификатор задания.

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

Входные параметры:

- in_id (NUMBER) - идентификатор задания.

queue_op_Del (NUMBER) - функция, определяющая доступность операции удаления задания;

Входные параметры:

- in_id (NUMBER) - идентификатор задания.

queue_sort - процедура для просмотра очереди заданий с возможностями сортировки и фильтрации по нескольким атрибутам.

Входные параметры:

- in_sort (VARCHAR2) - имя атрибута, по которому будет выполняться сортировка,

- in_prdk (VARCHAR2) - показатель направления сортировки (asc/desc),

- in_filter (VARCHAR2) - имя поля, по которому будет выполняться фильтрация заданий,

- in_op (VARCHAR2) - название операции сравнения при фильтрации заданий,

- in_value (VARCHAR2) - сравниваемое значение при фильтрации заданий;

Выходной параметр:

- out_queue (REF CURSOR) - курсор, содержащий список заданий и сопутствующую информацию.

task_res - процедура для удаления задания с получением промежуточных результатов или без;

Входные параметры:

- in_id (NUMBER) - идентификатор кластера;

- in_action (NUMBER) - код операции (забирать промежуточные результаты или нет);

Выходной параметр:

- out_res (NUMBER) - показатель успешности выполнения процедуры.

cluster_access (NUMBER) - функция проверки прав доступа пользователя к кластеру;

Входные параметры:

- in_user_id - идентификатор пользователя,

- in_cluster_id - идентификатор кластера.

Следующие функции находятся в разработке:

cluster_reload - процедура перезагрузки кластера;

Входной параметр:

- in_id (NUMBER) - идентификатор кластера;

Выходной параметр:

- out_res (VARCHAR2) - показатель успешности выполнения процедуры.

analyze_general - процедура для вывода общей статистики использования системы за указанный период времени.