Содержание к диссертации
Введение
Глава 1. Обзор методов и средств управления заданиями 9
1.1. Средства удаленного ввода заданий 9
1.2. Средства распределенной обработки заданий 15
1.3. Концептуальные модели СУЗ 19
1.3.1. Модель удаленного вызова процедур 19
1.3.2. Модель DCNA 23
1.3.3. Модель службы JTM ISO 24
1.4. Анализ методов и средств управления заданиями 35
1.5. Анализ области применения 39
1.6. Постановка задачи ... 42
Глава 2. Разработка модели управления заданиями 46
2.1. Исследование и выбор принципов управления заданиями. 46
2.1.1. Запуск работ 47
2.1.2. Параллельное выполнение работ 59
2.1.3. Синхронизация выполнения работ 64
2.1.4. Мониторинг работ 64
2.2. Состав и функциональные возможности примитивов 76
2.3. Структура информационных компонент 80
2.4. Структура функциональных компонент 82
2.5. Протокол обмена 83
2.6. Протокол обработки спецификаций 84
2.7. Управление транспортными пересылками спецификаций 86
2.8. Выводы 87
Глава 3. Разработка службы управления заданиями 90
3.1. Функциональная структура 90
3.2. Информационная структура 93
3.3. Модульная структура исполнительной системы 101
3.4. Исполнительные средства СУЗ 103
3.5. Функциональные средства СУЗ 104
3.7.Выводы 107
Глава 4. Реализация и использование СУЗ в АС СН 108
4.1. Отказоустойчивая обработка заданий 108
4.2. Автоматизированная подсистема решения задач суточного планирования 112
4.3. Управление регламентными процессами 116
4.4. Выводы 121
Заключение 123
Список литературы 127
- Средства распределенной обработки заданий
- Состав и функциональные возможности примитивов
- Модульная структура исполнительной системы
- Автоматизированная подсистема решения задач суточного планирования
Введение к работе
Актуальность проблемы. Современный этап научно-технического прогресса характеризуется интенсивной информатизацией общества, которая невозможна без передовой компьютерной техники и информационных вычислительных сетей.
Разработка и реализация сетей ЭВМ требует решения множества проблем, вызванных различием типов объединяемых компьютеров, их архитектур и конфигураций, операционных систем и коммутационного оборудования, физических принципов и алгоритмов передачи данных. Решение этих задач предусматривает разработку системного программного обеспечения, предоставляющего пользователям набор различных сетевых услуг.
Существует класс задач, который предполагает выполнение множества заданий, не требующих интерактивного взаимодействия с пользователями. Задания выполняются на различных ЭВМ в неоднородной вычислительной сети. Такие ЭВМ в данной работе названы исполнительными. При этом необходимо обеспечить пересылку исходных данных в исполнительную ЭВМ, а также пересылку результатов выполнения задания в исходную или другую ЭВМ. Завершение выполнения определенных заданий может служить сигналом для активизации выполнения других заданий. Кроме того, необходимо осуществлять контроль и управление ходом выполнения распределенной обработки заданий. Совокупность заданий, обработка которых объединена одним замыслом, названа сетевым заданием. Пример графического представления выполнения сетевого задания приведен на рис. 1.
Описанный класс задач характерен для предметных областей, которые имеют отработанный производственный цикл, состоящий из совокупности отлаженных технологических процессов, не требующих вмешательства человека.
Этот класс задач характерен для предприятий и ведомств, чья деятельность четко формализована и жестко регламентирована нормативными и рас-
5 порядительными документами. К таким организациям и ведомствам относятся Вооруженные Силы РФ, а также различные конструкторские организации, например, создающие авиационную технику.
Автоматизированные системы специального назначения (АС СН), рассматриваемые в данной работе, - это АС, предназначенные для автоматизации вычислительного процесса в организациях приведенного выше типа. АС СН предъявляют к используемым системным и прикладным программным продуктам требования технологической независимости, информационной безопасности и сертификации. Сертификация предполагает наличие исходных текстов программ, комплектов конструкторской документации и предприятий, сопровождающих жизненный цикл используемых программных продуктов.
Для повышения эффективности функционирования таких АС СН, сокращения сроков их разработки, улучшения управления распределенными процес-
сами необходимо создание службы управления заданиями. Как показал
обзор, существующие средства не обладают необходимыми функциональными возможностями и неприемлемы по условиям сертификации. Важность и сложность управления распределенной обработкой заданий в АС СН выдвигают в число актуальных задач исследование и разработку службы управления заданиями.
Дополнительным подтверждением актуальности данной работы являются материалы по стандартизации JTM (Job Transfer and Manipulation) ISO [1,2].
Целью диссертационной работы является исследование и разработка службы управления заданиями для автоматизированных систем специального назначения, которая позволила бы выполнить в неоднородной вычислительной сети распределенную синхронизированную обработку заданий, не требующих интерактивного взаимодействия с пользователем.
Методы исследования. В диссертационной работе используются методы теории сложных систем, теории массового обслуживания, теории вероятностей, математической статистики, теории моделирования.
Научная новизна. Разработана модель службы управления заданиями (СУЗ), выбраны средства описания сетевых заданий и определена их функциональность. Предложены состав и структура исполнительной службы, определен протокол взаимодействия элементов службы. Созданы информационные и управляющие структуры. Разработана имитационная модель для качественной оценки эффективности распределения выполнения заданий для различных алгоритмов. Показана потенциальная эффективность распределения заданий при наличии накладных расходов.
Основными положениями работы, выносимыми на защиту, являются:
Модель управления заданиями.
Протокол взаимодействия элементов СУЗ.
Исследование модели и протокола СУЗ.
4. Исследование эффективности алгоритмов распределения заданий.
5. Прикладные аспекты (модульная структура и состав СУЗ, информационные структуры СУЗ).
Практическая значимость работы. Разработанные средства СУЗ могут быть использованы в автоматизированных системах предприятий и ведомств, чья деятельность четко формализована и жестко регламентирована нормативными и распорядительными документами: в АС ВС РФ, а также в АС различных конструкторских бюро, создающих сложную технику.
Степень обоснованности и достоверность научных положений, выводов и рекомендаций, сформулированных в диссертационной работе, подтверждена корректностью анализа возможных вариантов построения СУЗ и экспериментальной проверкой принятых решений.
Реализация результатов исследования. Служба управления заданиями использовалась при создании системы управления регламентными процессами и программного комплекса обеспечения отказоустойчивой обработки заданий, разрабатываемых в интересах Военно-воздушных сил, Управления Начальника вооружения ВС РФ и Управления Начальника связи ГШ ВС РФ.
С помощью СУЗ удалось уменьшить время разработки прикладных систем, повысить оперативность решения задач, сократить сроки принятия решений, повысить надежность выполнения ответственных заданий при минимизации накладных расходов, что подтверждено соответствующими актами о внедрении.
Апробация. Отдельные результаты диссертационной работы излагались на следующих научных конференциях:
VIII Всесоюзном семинаре «Персональные ЭВМ и локальные сети» (г. Новый Афон), на IV Всесоюзном межвузовском семинаре «Диалоговые средства распределенной обработки данных в комплексах и сетях ЭВМ» (г. Москва), на Московской научно-технической конференции «Информатика, телеобработка и персональные компьютеры» (г. Москва), на Всероссийской научно-технической конференции "Перспективы развития оборонных информацион-
8 ных технологий" (г. Воронеж). Также некоторые положения работы обсуждались на научных семинарах, проводимых на кафедре "Компьютерные системы и технологии" МИФИ.
Научные публикации. По теме диссертации автор имеет 7 печатных работ, список которых приведен в конце диссертации.
Средства распределенной обработки заданий
Одной из определяющих тенденций сетевых операционных систем является обеспечение реальной многозадачности, которая, в свою очередь, была вызвана развитием архитектуры аппаратных средств серверов по поддержке многопроцессорности. В связи с этим актуальной становится проблема управления многозадачностью, в том числе и распределением задач по процессорам. Естественным развитием данного подхода стала разработка средств по распределению задач или потоков по различным процессорам не только одного сервера, но и ряда серверов сети [51-61].
В операционных системах на уровне инструментальных средств допускается назначение компьютера для выполнения порождаемых процессов. Подобную возможность закладывают некоторые производители программного обеспечения в свои продукты. Фирма Lotus объявила о стремлении выпустить Lotus Notes, который будет поддерживать многосерверную параллельную обработку документов. Ярким представителем данного класса продуктов является 3D-Studio.
Пакет анимационной графики 3D-Studio не является ни сетевой операционной системой, ни прикладной оболочкой общего назначения. Данный продукт предоставил возможность распределения своих заданий для формирования клипов/фликов на разных серверах.
Так как формирование сложных анимационных роликов требует большого количества машинного времени, фирма предложила механизм организации запуска и управления своими заданиями. Как только один из серверов завершил обработку определенного задания, он сообщает об этом на другие серверы. На эти серверы направляются необходимые задания. Пользователь описывает лишь количество и сетевые имена серверов, на которых можно производить соответствующую обработку.
Переход от совместно используемых обрабатывающих систем к системам распределенной обработки требует создания более гибких вычислительных систем, способных удовлетворить потребности организаций. Механизм централизованного управления традиционных систем, предназначенных для совместного использования информации, на базе аппаратных и программных средств одного поставщика уже не отвечает запросам пользователей [51-67].
Эти тенденции ведут к исчерпанию резервов вычислительных систем на основе рабочих групп. По мере того, как специалисты по информационным системам приступают к реализации общекорпоративных систем, ограничения среды рабочих групп становятся все более очевидными. Появляется необходимость организации такой связи между ПЭВМ и ЭВМ, имеющих мощные ресурсы, которая позволяла бы пользователям осуществлять доступ к главным вычислительным ресурсам предприятия. При расположении ресурсов на сервере пользователям необходимо знать, где находится каждый ресурс, к которому они хотят осуществить доступ. Функции управления, "привязанные к серверу", также ограничивают свободу супервизора, осуществляющего управление общекорпоративной системой.
Для обеспечения распределенной обработки информации в неоднородной среде консорциум Open Software Foundation (OSF) представил спецификацию поддержки распределенной среды DCE (Distributed Computing Environment). DCE - это сложный набор прикладных и сетевых служб, основными из которых являются: средства машинно-независимого представления данных, позволяющие различным компьютерам преобразовывать данные; протокол, определяющий действия клиента и сервера при удаленном вызове процедур; потоки, которые позволяют приложению одновременно выполнять несколько задач; протокольный компилятор, который имеет определение удаленной процедуры, включая типы аргументов и ответов, и генерирует интерфейсы RPC; протокольный компилятор освобождает приложение от программирования на более низком уровне; служба аутентификации, которая отвечает за безопасность любого удаленного доступа; служба сетевых имен, которая позволяет приложениям размещать обозначенные сетевые объекты (такие как пользователи, хосты, или почтовые ящики) и устанавливает связь со службами, которые регистрируются в сети; служба сетевого времени для синхронизации хост-машин по установке единого сетевого времени; распределенная файловая система для исключения файловой избыточности. Она обеспечивает быстрое, надежное и полномочное разделение файлов. Для сетевого взаимодействия неоднородных машин с эффективным разделением больших объемов данных распределенной файловой системе требуется механизм блокирования файлов.
Структурное взаимодействие компонентов модели DCE в соответствии с эталонной моделью OSI ISO представлено на рис. 1.1.
Хотя основной компонентой DCE является удаленный вызов процедур, другие утилиты являются также существенными для создания распределенных приложений.
Модель DCE ориентированна на работу в среде нескольких операционных систем с использованием многих сетевых протоколов, предлагая для доступа к различным службам согласованный набор прикладных программных интерфейсов.
Состав и функциональные возможности примитивов
Описание сетевого задания реализуется с помощью примитивов. Примитивы обеспечивают выполнение элементарных действий по управлению заданиями. Эти элементарные действия называют работами. В качестве работ в данном случае имеются в виду такие действия, как проверка наличия и пересылка файлов, активизация заданий в рамках операционной системы (ОС) исполнительной ЭВМ, опрос статуса задания, принудительное завершение задания и т. п. Работы одного сетевого задания могут выполняться на различных ЭВМ. В отличие от сетевых традиционные задания, выполняемые в рамках отдельных ОС, называют локальными.
Основные различия подходов описания сетевых заданий состоят в степени централизации механизма управления, унификации исполнительных механизмов, а также требований контроля и синхронизации выполнения работ. В результате анализа и с учетом требований документов по стандартизации ISO [1,2] определен следующий набор примитивов службы управления заданиями: SUBMIT - объявление сетевого задания; INQUIRE - запрос информации о наличии требуемых файлов; GIVE - пересылка файлов к исполнителю работы; DISPOSE - пересылка файлов от исполнителя работы; INITLJOB - инициализация обработки локального задания (прикладного процесса) в указанной ЭВМ; STATUS - запрос информации о состоянии локального задания или работы; HOLD - приостанов выполнения локального задания или работы; RELEASE - продолжение выполнения приостановленного локального задания или работы; STOP - прекращение выполнения локального задания или работы; WAITEND - ожидание завершения выполнения локального задания или работы; PROFORMA - объявление проформы; SPAWN - активизация проформы; KILL - завершение сетевого задания и удаление всей информации о нем. Данный набор обеспечивает возможности централизованного и децентрализованного управления обработкой сетевого задания. При организации распределенной обработки заданий используют средства активизации и контроля завершения как отдельных работ, так и ряда работ, объединенных в специальные группы, называемые проформами. Проформа рассматривается как самостоятельная работа и, в свою очередь, может быть включена в другие проформы. При этом порождаемые работы обладают автономностью от "родительских" заданий. Необходимо рассмотреть наиболее существенные отличия примитивов СУЗ и JTM. С точки зрения JTM примитивы разбиты на четыре группы. Обращение к каждой из них инициируется примитивами J_INITIATE_WORK, MAN. Примитивы инициации определяют место обработки работы, а также авторизацию и санкционирование полномочий пользователя. Функциональные примитивы, примитивы контроля и управления включаются в соответствующие примитивы инициации. Основной чертой примитивов JTM является формирование всей последовательности выполнения работ, связанных одним примитивом инициации.
Механизмом передачи управления выполнением работ из одной ЭВМ в другую служит проформа. Разные примитивы инициации определяют формирование различных заданий-OSI. Другими словами, взаимодействие между работами, задаваемыми различными примитивами инициации, затруднено. Иллюстрацией данного подхода является наличие четырех видов конвертов (примитивов инициации), в которые вкладываются наборы письменных инструкций (примитивов). Конверты отправляются по адресу назначения. Получатель на конверте считывает информацию об отправителе и принимает решение: распечатывать конверт, отправить его обратно, уничтожить или передать в другую инстанцию. Распечатав конверт, получатель последовательно выполняет все вложенные инструкции (работы). Среди инструкций могут оказаться другие конверты (проформы), которые отсылают по своим адресатам (spawn). Однако после того, как письмо опущено в почтовый ящик, связь с ним теряется. О выполнении той или иной инструкции отправитель узнает лишь тогда, когда исполнителем инструкции будет отправлено ответное письмо. Воздействовать же на последовательность выполнения инструкций, в зависимости от результатов исполнения предыдущих, отправитель письма, практически, лишен, или должен быть настолько дальновидным, чтобы предусмотреть возможные последствия.
Модульная структура исполнительной системы
Модуль JTMIN принимает спецификации работ (INDICATION), проверяет их правильность и, в зависимости от типа, ставит в очередь к одному из диспетчеров. Спецификации работ (W ) направляются к диспетчеру DISPF, спецификации завершения и управления работами (N , С ) к диспетчеру DISPC, который работает с более высоким приоритетом, чем первый. Если спецификация относится к запросу асихронного типа или обнаружены ошибки, то модуль JTMIN формирует и отправляет соответствующий ответ (RESPONSE) источнику запроса. Источником запроса может быть как процесс пользователя, так и средства СУЗ другой ЭВМ.
Диспетчер выбирает спецификацию из своей очереди и определяет ЭВМ, на которой необходимо выполнить работу. Затем спецификация либо пересылается в другую ЭВМ (REQUEST), либо передается одному из серверов на обработку. Серверы выполняют работу в соответствии с параметрами спецификации и формируют спецификацию завершения работы. Модули WAITENDC и WAITENDF фиксируют завершение работы и при необходимости передают спецификацию завершения работы (R ) процессу пользователя или средствам СУЗ другой ЭВМ. Исполнительные средства СУЗ разработаны для операционных систем ОС MVT, TKS, SVS, VM, VAX VMS, MS Windows NT. Под локальным заданием в ОС MVT, SVS, TKS понимается задание в контексте SNA. Для инициализации выполнения локального задания в этом случае требуется указать файл, расположеннный на исполнительной ЭВМ, который содержит описания задания на языке JCL. В случае ОС VM служба управления заданиями представляет собой виртуальную машину с правами администратора. При необходимости СУЗ активизирует виртуальную машину пользователя в фоновом режиме с его правами и полномочиями. Обработка всех запросов пользователя осуществляется в этой виртуальной машине. Локальное задание в VAX, работающей под управлением операционной системы VMS, описывается в виде командного файла. При пересылке файлов и запуске локального задания средствами операционной системы обеспечиваются соответствующие полномочия и права пользователя. Для этого исполнительная служба запускается как системный процесс с необходимыми квотами и привилегиями. Локальное задание в IBM PC описывается в виде исполняемых файлов и процедур.
В операционной системе Windows NT исполнительная система СУЗ реализована в виде системного сервиса. Функциональные средства СУЗ предоставляют пользователю, работающему за терминалом, следующие возможности: - переслать файл с ЭВМ пользователя на другую сетевую ЭВМ; - переслать файл из удаленной ЭВМ на ЭВМ пользователя; - получить справочную информацию о файле, расположенном на удаленной сетевой ЭВМ; - инициировать выполнение локального задания на удаленной исполнительной ЭВМ; - опросить состояние задания; - приостановить выполнение задания; - продолжить выполнение приостановленного задания; - прекратить выполнение задания; - получить список доступных сетевых ЭВМ. Функциональные средства предоставляют интерфейс пользователю к службе управления заданиями. Они позволяют выполнять в режиме диалога функции по запуску задания, управлению состоянием задания, возврату результатов счета и пересылке файлов. При разработке функциональных средств учитывались, с одной стороны, основные приемы работы с диалоговыми средствами на различных ЭВМ, а с другой - возможности конкретных ЭВМ. Было предложено реализовать интерфейс в режиме меню. Для ПЭВМ требования к интерфейсу были ориентированы на регламентные процедуры управления АСУ.
Автоматизированная подсистема решения задач суточного планирования
Данная подсистема входит в состав уже рассмотренной выше (раздел 4.1) АССН. При составлении плана от различных источников в течение суток принимают информацию, содержащую предложения в план. Источниками являются взаимодействующие объекты автоматизации. При наступлении новых суток выполняют информационно-расчетные задачи подготовки фрагментов плана на следующие сутки и программу сверки планов.
К моменту начала разработки программного комплекса автоматизации имелись информационно-расчетные задачи планирования и сверки планов. Подготовку исходных файлов предложений, обмен результатами расчетов, запуск задач, а также их перезапуск в случае аварийного завершения или сбоя компьютера осуществлял пользователь в интерактивном режиме. Работа включала большое количество ручных операций по запуску программ, проводилась в ночное время, нередко сопровождалась ошибками, требующими повторения отдельных этапов, и нарушением временных нормативов. Она выполнялась в течение нескольких часов и требовала большого напряжения исполнителей. Поэтому была поставлена задача автоматизации процесса подготовки суточного плана.
Было рассмотрено два подхода к осуществлению автоматизации процесса суточного планирования.
При первом подходе предполагалось провести разработку нового программного комплекса формирования суточного плана, автоматизирующего все технологические циклы планирования: обмен данными, выполнение расчетных задач, управление вычислительным процессом с использованием RPC-вызовов. Разработка нового программного комплекса потребовала бы значительных трудозатрат, связанных с написанием и отладкой большого объема программного кода на языке C++, принятого в качестве базового в рассматриваемой АС СН.
Другой подход связан с использованием существующих информационно-расчетных задач и автоматизацией их запуска средствами СУЗ. Данный подход учитывает, что расчетные задачи тщательно отлажены, точно отражают специфику взаимодействующих объектов и успешно применяются в существующем виде. Кроме того, приняты во внимание распределенный характер выполнения задач, отсутствие исходных текстов для ряда расчетных программ, важность решения задачи планирования в определенном временном интервале, а также функциональные возможности СУЗ по управлению локальными заданиями и организации единого вычислительного процесса.
Исполнительные системы СУЗ были установлены на сервере функциональной группы, на серверах группы обслуживания и на серверах обмена данными.
Процесс выполнения задач планирования был описан в виде сетевого задания. Упрощенный вариант блок-схемы сетевого задания суточного планирования приведен на рис.4.2.
Примитив SUBMIT объявляет сетевое задание, определяет уникальный служебный идентификатор этого задания. Примитив GIVE осуществляет сбор файлов предложений в суточный план с АРМ пользователей и с сервера обмена данными.
Основным сервером для проводимых расчетов назначается сервер функциональной группы планирования. Примитивом INITLJOB на указанном сервере активизируется локальное задание по расчету суточного плана в виде фонового процесса.
Примитив WAITEND ожидает завершение локального задания расчета плана. В случае аварийного завершения локального задания (код возврата гс не равен 1) менеджер кластера (раздел 4.1.) назначает альтернативный сервер и повторяет расчет суточного плана.
В случае успешного завершения локального задания (код возврата гс равен 1) работа DISPOSE осуществляет пересылку результатов планирования на сервер обмена данными для передачи в АС взаимодействующих объектов. Примитив GIVE производит сбор планов от взаимодействующих объектов. Примитив INITLJOB активизирует локальное задание сверки планов взаимодействующих объектов.
Сетевое задание автоматически осуществляет процесс сверки, производя необходимое число раз пересылку результатов планирования между сервером приложений и сервером обмена данными и активизируя локальные задания.
