Содержание к диссертации
Введение
Глава 1. Обзор современных систем пакетной обработки заданий в многопроцессорных вычислительных системах 11
1.1. Обзор многопроцессорных вычислительных систем 11
1.2. Обзор средств программирования многопроцессорных вычислительных систем 16
1.2.1. Коммуникационная библиотека MPI 18
1.2.2. Среда выполнения параллельных программ PVM 19
1.3. Системы управления пакетной обработкой заданий 21
1.3.1. Кластерная система Condor 22
1.3.2. Система DQS - Distributed Queuing System 25
1.3.3. Система управления заданиями Codine 28
1.3.4. Переносимая планирующая система PBS - Portable Batch System 31
1.3.5. Архитектура систем управления заданиями 35
1.4. GRID-технологии 37
1.5. Выводы по главе 1 41
Глава 2. Методы планирования очередности выполнения заданий на многопроцессорных системах гетерогенной вычислительной сети 43
2.1. Основные принципы построения системы управления заданиями TMS .43
2.2. Ресурсы в системе управления заданиями TMS 45
2.3. Задания в системе управления TMS 47
2.3.1. Эффективность параллельных программ , 47
2.3.2. Расчет времени выполнения задания 49
2.4. Постановка задачи планирования и ее сложность 54
2.4.1. Классификация алгоритмов планирования 58
2.4.2. Критерии оценки расписаний 60
2.4.3. Известные дисциплины планирования 62
2.5. Планирование заданий в системе управления TMS 67
2.5.1. Приоритеты заданий 68
2.5.2. Локальное планирование заданий 71
2.5.3. Балансировка загрузки локальных очередей классов 75
2.6. Теорема об эффективности локального планирования. 76
2.7. Выводы по главе 2 80
Глава 3. Разработка системы управления выполнением потока программ на высокопроизводительной вычислительной сети 82
3.1. Назначение и требования к системе управления потоком заданий 82
3.2. Общая организация системы TMS 84
3.3. Сервер планирования и учета 86
3.3.1. Структура сервера планирования и учета 86
3.3.2. Основной конфигурационный файл сервера планирования 89
3.3.3. Ограничения и учет использования ресурсов 92
3.3.4. Организация сетевых взаимодействий 95
3.3.5. Безопасность системы управления заданиями TMS 97
3.3.6. Описание заданий... ...99
3.3.7. Цикл обработки задания 101
3.4. Модуль-агент узла 103
3.5. Программные интерфейсы системы управления заданиями TMS 107
3.5.1. Программный интерфейс планировщика SchedAPI 108
3.5.2. Библиотека CommandAPI 110
3.5.3. Программный интерфейс агента вычислительного узла AgentAPI.. 115
3.6. Утилиты системы управления заданиями TMS 117
3.6.1. Утилита tsub , 117
3.6.2. Утилита tslat 117
3.6.3. Утилита tdel 119
3.6.4. Утилита tget 119
3.6.5. Утилита tconf 120
3.7. Выводы по главе 3 123
Глава 4. Исследование эффективности разработанных методов планирования заданий 125
4.1. Эмуляция внешней среды сервера планирования и учета 125
4.2. Используемые при оценке разработанных методов планирования характеристики расписаний 129
4.3. Генератор заданий 131
4.4. Конвертер журналов 133
4.5. Результаты исследований 134
4.6. Выводы по главе 4 142
Заключение 143
Литература 145
- Обзор средств программирования многопроцессорных вычислительных систем
- Известные дисциплины планирования
- Безопасность системы управления заданиями TMS
- Используемые при оценке разработанных методов планирования характеристики расписаний
Введение к работе
Актуальность темы. Численные методы широко применяются в современных научных исследованиях во многих отраслях науки для решения фундаментальных и прикладных задач. К таким задачам можно отнести задачи численного моделирования природных процессов, анализа экспериментальных данных в реальном времени, распознавание речи и изображений. В частности, на вычислительных ресурсах Центра высокопроизводительных вычислений (ЦВВ) РГУ решаются задачи квантовой механики, квантовой химии, астрофизики (задачи динамики галактик), радиофизики (моделирование газовых разрядов), задачи гидродинамики водоемов и фильтрации грунтовых вод.
В то же время, мощности современных однопроцессорных компьютеров явно недостаточно для оперативного решения подобных задач. Это обстоятельство побуждает исследователей использовать для объемных расчетов многопроцессорные вычислительные системы (МВС), выполняя на них параллельные версии программ.
Специализированные МВС достаточно дороги, хотя по мере развития сетевых технологий появилась возможность создания высокопроизводительных кластеров из серийно выпускаемых рабочих станций. Тем не менее, настройка, обслуживание и эксплуатация высокопроизводительных систем требует определенных усилий со стороны администратора. Это неизбежно приводит к созданию в рамках научной организации вычислительного центра коллективного доступа, обладающего мощными вычислительными ресурсами и предоставляющего эти ресурсы для выполнения пользовательских задач. При этом сразу возникает проблема разделения ресурсов между задачами различных пользователей. Необходимо обеспечить эффективное использование имеющихся вычислительных ресурсов, надежную изоляцию заданий, а также соблюдение определенной справедливости при распределении ресурсов между программами нескольких пользователей.
Для решения перечисленных проблем применяются системы пакетной обработки заданий (СПОЗ), расширяющие базовые возможности ОС, и позволяющие объединить несколько МВС в единый вычислительный комплекс. СПОЗ обеспечивает организацию выполнения потока заданий пользователей,
единый пользовательский интерфейс для доступа Н<^п<ЧМ>^ВЫ'нюдитеяьным
РОСАЛЦНОНЛЛЬНЛЯ I БИБЛИОТЕКА |
!йоа
О» КО і
ресурсам, єдиную политику управления ресурсами и т.д. Проблемам создания и организации таких систем посвящены работы Вл.В. Воеводина и его учеников, В.И.Золотарева, В.Н.Коваленко, Д.Фейтелсона, Е. Смирни и других ученых. Существующие СПОЗ можно условно разделить на 2 класса:
Специализированные СПОЗ - применяются для поддержки конкретных супер-ЭВМ, обычно поставляются вместе с этими супер-ЭВМ.
СПОЗ общего назначения - могут применяться для достаточно широкого класса многопроцессорных систем.
Однако существующие СПОЗ обладают рядом недостатков:
1. Некоторые системы рассчитаны на управление однородными
вычислительными сетями. В то же время, в состав вычислительных центров
обычно входят разнородные системы, образуя гетерогенные вычислительные
сети. Примеры таких систем, рассчитанных на планирование однородных
систем - DJM, Task Broker, EASY.
2. Даже если система управления ориентирована на работу в гетерогенной
вычислительной среде, от пользователя обычно требуется заранее (на этапе
передачи задания в систему) определить количество процессоров, которые
должны быть выделены заданию и их тип (тип вычислительной системы).
Примеры таких систем - OpenPBS, Condor, LSF и т.д. Это не всегда удобно,
если задание является переносимым (может выполняться на различных MB С) и
масштабируемым (может выполняться на различном числе процессоров).
Масштабируемость является одним из важных свойств параллельных программ. При этом от количества выделенных процессоров зависит потребность программы в других ресурсах вычислительной системы -например, время выполнения параллельной программы в зависимости от числа процессоров определяется законом Амдала.
Кроме того, использование стандартных средств и интерфейсов для организации межпроцессорных взаимодействий позволяет создавать переносимые параллельные программы, которые могут выполняться на МВС разных типов с различной архитектурой. Например, реализации библиотеки MPI существуют для подавляющего большинства многопроцессорных систем (включая кластеры рабочих станций), а библиотеки POSIX thread доступны для большинства SMP-систем.
Таким образом, является актуальным создание системы управления пакетной обработкой параллельных заданий в гетерогенной вычислительной
сети с поддержкой организации выполнения масштабируемых и переносимых заданий. Такая система должна обеспечивать эффективное распределение и использование имеющихся вычислительных ресурсов, безопасность, удобство администрирования системы и управления заданиями, предоставлять АРІ для реализации новых дисциплин планирования заданий, а также создания дополнительных пользовательских утилит.
Целью диссертационной работы является разработка открытой системы управления заданиями в гетерогенных сетях, состоящих из однородных подсетей, реализация гибкого механизма планирования заданий, а также исследование эффективности разработанных методов. Поставленные цели достигаются решением следующих задач:
1.Провести сравнительный анализ современных систем управления заданиями для МВС, выявить их преимущества и недостатки.
2.Провести анализ теоретических и используемых на практике подходов к планированию заданий и распределению ресурсов многопроцессорных вычислительных систем.
3.Разработать методы и алгоритмы распределения ресурсов и планирования заданий в неоднородной вычислительной сети, состоящей из однородных подсетей.
4.Разработать архитектуру системы управления заданиями,
обеспечивающей поддержку различных типов МВС, а также организацию выполнения масштабируемых и переносимых параллельных программ.
5.Разработать открытые программные интерфейсы для создания специализированных дисциплин планирования заданий, а также для создания новых утилит, образующих интерфейс между системой управления и пользователями системы.
6.Выполнить прототипную реализацию открытой системы управления заданиями, обеспечивающей выполнение масштабируемых и переносимых заданий в гетерогенной вычислительной сети.
7.Разработать инструментарий и методы анализа производительности различных алгоритмов планирования.
8.Провести исследование характеристик разработанных алгоритмов планирования.
Научная новизна работы. Научную новизну работы определяют следующие основные результаты:
1.Архитектура системы управления заданиями по выполнению масштабируемых и переносимых параллельных программ в неоднородной вычислительной сети, состоящей из однородных подсетей, объединяющих однотипные МВС.
2.Методы и алгоритмы распределения заданий по вычислительным ресурсам, определения количества процессоров, выделяемых для выполнения заданий и времени их запуска.
З.Теорема об оценке эффективности предложенных методов планирования для случая полностью масштабируемых заданий.
4.Результаты исследования эффективности алгоритмов планирования, подтвердившие преимущества разработанных средств по сравнению с другими известными СПОЗ.
Практическая значимость
Практическую значимость работы представляет созданная на базе разработанной архитектуры система управления заданиями TMS (Task Management System). Система позволяет объединить МВС с различной архитектурой и производительностью и использовать их как единый вычислительный комплекс. Система управления предоставляет единообразный интерфейс для пользователей, эффективно распределяет задания по имеющимся вычислительным ресурсам, облегчает администрирование вычислительной сети в целом.
Публикации. По теме диссертации опубликовано 13 печатных работ, в том числе 2 статьи и 11 тезисов докладов на конференциях.
Апробация результатов работы. Результаты работы докладывались и обсуждались на научно-практических конференциях: Международная научно-методическая конференция. "Телематика'2001", Санкт-Петербург, 2001 г.; Всероссийская научная конференция "Научный сервис в сети Интернет", Новороссийск, 2002 г.; XXIX Международная конференция "Информационные технологии в науке, образовании, телекоммуникации, бизнесе", 2002 г.; IX конференция представителей региональных сетей "Relarn-2002", Нижний Новгород, 2002 г.; Международная научно-техническая конференция "СуперЭВМ и многопроцессорные вычислительные системы", Таганрог, 2002 г.; IX Всероссийская научно-методическая конференция "Телематика'2002", Санкт-Петербург, 2002 г.; X Всероссийская научно-методическая конференция
"Телематика'2003", Санкт-Петербург, 2003 г.; Научно-методическая
конференция "Современные информационные технологии в образовании:
Южный Федеральный округ", Ростов-на-Дону, 2003 г.; Всероссийская научная
конференция "Научный сервис в сети Интернет", Новороссийск, 2003 г.;
Международная научная конференция "Интеллектуальные и
многопроцессорные системы", Таганрог, 2003 г.; I Всероссийская научная конференция "Методы и средства обработки информации", Москва, 2003 г.
Реализация работы и внедрение результатов. Результаты работы использовались при выполнении и составили существенную часть результатов следующих НИР: проект В.0011 ФЦП «Интеграция» «Развитие центра высокопроизводительных вычислений для нужд вузовской и академической науки», № гос. регистрации 01.200.118684; проект № 341 «Исследование и разработка программных средств организации удаленного выполнения программ на гетерогенной вычислительной сети суперкомпьютерного центра Ростовского государственного университета» НТП Минобразования РФ «Государственная поддержка региональной научно-технической политики высшей школы и развитие ее научного потенциала», № гос. регистрации 01.200.118685; проект 1.7.43 «Разработка методов, технологии и специальных программных средств удаленного использования вычислительных ресурсов регионального центра высокопроизводительных вычислений в учебном процессе и научных исследованиях» НОП Минобразования РФ «Научное, научно-методическое, материально-техническое обеспечение развития технологий информационного общества и индустрии образования». Результаты работы внедрены в опытную эксплуатацию в центре высокопроизводительных вычислений РГУ.
Структура и объем. Диссертация состоит из введения, четырех глав, заключения и двух приложений. Основной текст диссертации содержит 158 страниц, 53 рисунка, 1 таблицу. Список литературы насчитывает 119 наименований.
Обзор средств программирования многопроцессорных вычислительных систем
В связи с развитием высокоскоростного сетевого оборудования, широкое распространение получили кластерные системы [8-10]. Такие системы являются более дешевым вариантом МРР-систем. При этом роль вычислительного узла играет серийный компьютер, а роль коммуникационной среды - локальная сеть. Одним из наиболее привлекательных свойств кластерных технологий является возможность объединения компьютеров самых различных типов - это могут быть как обычные персональные компьютеры, так и мощные рабочие станции с SMP-архитектурой. Топология полученной МВС в данном случае определяется используемым сетевым оборудованием - например, если используется соединение через коммутаторы Ethernet, то обеспечивается полнодоступная схема - любые два компьютера могут обмениваться данными, независимо от других пар, скорость передачи данных одинакова для любой пары узлов. Кроме того, достаточно эффективно реализуется широковещательная рассылка данных. Очевидно, что реальная производительность кластерной установки в основном определяется используемыми средствами коммуникации. Для высокопроизводительных вычислений характерным является частый обмен относительно небольшими порциями данных. Таким образом, большое значение приобретает не столько пропускная способность сети, сколько латентность. Латентность можно определить, как время, требуемое для передачи сообщения нулевой длины. Другими словами, латентность - это время, которое необходимо затрать на подготовку сообщения, формирование пакета, таймаут передачи и т.д. В частности, разновидности наиболее дешевой технологии Ethernet - Fast Ethernet и Gigabit Ethernet — имеют очень высокую латентность - порядка 60-180 мсек., что значительно ограничивает применение данной технологии для построения высокопроизводительных кластеров. Чаще всего в подобных установках используются технологии Myrinet, SCI, и т.д. [11].
Последние несколько лет получила распространение идея построения распределенных вычислительных сетей - GRID-технологии [12-19]. Данная идея является развитием кластерных технологий и заключается в объединении территориально удаленных вычислительных узлов в единую МВС посредством глобальных сетей. В результате была бы получена МВС, превосходящая любую существующую МВС в тысячи раз по большинству параметров - количеству процессоров, суммарному объему памяти, объему дискового пространства и вычислительной мощности. Более детально технология GRID обсуждается в параграфе 1.4 настоящей главы.
Для того, чтобы воспользоваться преимуществами параллельном обработки данных, необходимо иметь инструменты для реализации параллельных алгоритмов [20-22]. Средства разработки можно разбить на следующие классы: - Коммуникационные библиотеки для стандартных последовательных языков программирования. - Высокоуровневые библиотеки заранее распараллеленных процедур. - Специальные параллельные языки программирования. Некоторые их них получаются из стандартных языков путем добавлением распараллеливающих конструкций. - Использование распараллеливающих компиляторов с обычных языков программирования. Выбор подходящей парадигмы параллельного программирования, а, следовательно, и конкретных средств разработки, зависит как от свойств реализуемого параллельного алгоритма, так и от архитектуры компьютера. В реализации алгоритма различают функциональный параллелизм - когда различные процессы выполняют различные действия над данными (пример -конвейерная обработка данных) и параллелизм по данным - когда различные процессы параллельной программы выполняют одни и те же действия над различными подмножествами данными. Важнейшим свойством архитектуры компьютера является наличие общей или распределенной памяти. Для SMP-систем естественным способом обмена данными является использование общей памяти, и, следовательно, многопоточная организация программы. В этом случае программа состоит из одного основного процесса, который порождает необходимое количество легковесных процессов (нитей). Каждая нить может выполняться на отдельном процессоре, при этом операционная система автоматически осуществляет балансировку загрузки различных процессоров в системе. В то же время, все нити разделяют общее адресное пространство, и обмен данными между ними может осуществляться через глобальные переменные программы. Отдельные нити выполняются асинхронно, и для синхронизации могут применяться семафоры, блокировки, критические секции и т.д. Практически все операционные системы поддерживают стандарт POSIX thread [23], который определяет библиотечные вызовы для порождения и завершения нитей, а также средства синхронизации.
Механизм передачи сообщений является более общим, а для систем с массовым параллелизмом - единственным практически возможным способом обмена информацией. В рамках данной парадигмы, программа состоит из отдельных процессов, которые выполняются на разных процессорах. Процессы в рамках одной параллельной задачи получают уникальные идентификаторы, кроме того, определены процедуры отправки и приема сообщений между процессами. Сообщение содержит идентификатор процесса-отправителя, процесса-приемника, данные и, возможно, некоторую дополнительную информацию.
При этом операция чтения является блокирующей - т.е. данная операция завершается только после получения данных от источника. Таким образом, может выполняться неявная синхронизация процессов. Специализированные коммуникационные библиотеки реализуют расширенный набор операций, которые могут включать коллективные распределенные операции, блокирующие и неблокирующие процедуры обмена, средства для задания топологии коммуникаций и т.п.
Для систем типа NUMA могут использоваться обе технологии, например, в суперкомпьютере Cray XI реализован принцип DSM (Distributed Shared Memory), что позволяет использовать как MPI (библиотека передача сообщений), так и ОрепМР (потоковый параллелизм).
Известные дисциплины планирования
Кроме вышеперечисленных критериев, задача планирования определяется также выбором функционала f(S) для оценки полученных расписаний. Рассмотрим несколько наиболее часто применяемых на практике случаев. Пусть в момент времени t = 0 в систему поступило п заданий, и S -некоторое расписание. Обозначим через С(Т) время завершения обработки задания Т. Иногда его также называют временем прохождения, поскольку С(Т) определяет общее время пребывания задания в системе.
Через W(T) обозначим время ожидания момента запуска, т.е. сколько времени задание провело в очереди, а через R(T) - время выполнения задания, R(T) - С(Т) — W(T). Заметим, что если алгоритм планирования допускает вытеснение, то R(T) может превышать величину, определяемую функцией rt(). Тогда в качестве оценки f(S) могут быть выбраны:
Длина расписания. Длиной L(S) расписания S называют величину тах(С(Т)). Тогда Sopi - оптимальное расписание, если L(Sopl) = min {L(S)} [76].
Средневзвешенное время завершения заданий (СВЗ). В этом случае каждому заданию назначается положительная величина w(t) - вес. СВЗ - это величина AW(S)=2 w(T) C(T), и Sopl - оптимальное расписание, если AW(S0pt) = min(AW(S)). Частный случай — минимизация среднего времени прохождения задания (w(t) = 1/п, где п - число заданий) [71,77-79]. 3. Среднее замедление заданий. Является частным случаем (2), но широко применяется на практике. [71,78,80,81] Через замедление (slowdown) задания Т обозначим величину SD(T) = C(T)/mm(d(m)). Замедление показывает, во сколько раз увеличивается время прохождения задания по сравнению с минимально возможным временем выполнения, если бы МВС обрабатывала только данное задание в выделенном режиме. Тогда величину ASD(S) = 2 SD(T)/n называют средним замедлением для расписания S и Sopi -оптимально, если ASD(Sop()=minCASD(S)). Сводится к случаю (2) при w(t) = l/min(d(m))/n. Широкое использование замедления в качестве оценки качества планирования обусловлено тем, что это характеристика "выравнивает" задания -для длинных заданий допускается большее время ожидания. Три вышеперечисленных способа определяют целевой функционал через параметры заданий. Существует еще 2 способа, позволяющих оценить расписание с точки зрения использования ресурсов системы [78]: 4.Средняя загрузка системы. Номинальной загрузкой системы в момент времени t называют отношение числа занятых процессоров (выделенных заданиям) к общему количеству ПЭ в системе. Средняя загрузка — это номинальная загрузка, усредненная по времени. Для невытесняющего планирования существует более простой способ вычисления средней загрузки -[2(D(T) R(T))] / L(S) / Р, где L(S) - длина расписания S, Р - общее количество процессоров в МВС, D(T) — число выделенных заданию Т процессоров, R(T) - время выполнения задания. З.Средний коэффициент использования системы (utilization). Для выполняемого на D(T) процессорах задания определена эффективность -отношение полученного ускорения к D(T). Коэффициент использования системы в момент времени t - это средняя эффективность использования ПЭ системы, т.е. 2 Е(р) / Р. Обе определенные выше величины принимают значения в интервале от О до 1, и должны по возможности максимизироваться. Рассмотрим простейшие дисциплины задания. Они ориентированы в основном на немасштабируемые задания, т.е. такие, для которых указана только одна размерность [82,83]. 1 .FCFS (First Come - First Served) - обслуживание заданий производится в порядке их поступления в систему. Все поступающие задания помещаются в конец очереди ожидания и запускаются строго в порядке, определяемом очередью. Если очередному заданию невозможно выделить требуемое количество процессоров, то распределение заданий по ПЭ приостанавливается до тех пор, пока не освободится достаточно ПЭ для запуска задания из головы очереди. Достоинствами данной дисциплины является простота реализации, определенная справедливость (исключается возможность бесконечного ожидания) и высокая степень предсказуемости — вновь поступающие задания не оказывают никакого влияния на поступившие ранее. Основной недостаток — часто неэффективное использование ресурсов МВС, эффективность результирующего расписания сильно зависит от порядка прибытия заданий. Для повышения эффективности работы данного алгоритма может применяться стратегии обратного заполнения (backfilling) [80,81,84], которые позволяют планировщику оптимизировать расписание и более полно использовать ресурсы вычислительной системы: la) FCFS/FF (FCFS First Fit) - задания обслуживаются в порядке FCFS, но если очередное задание не может быть запущено из-за недостатка свободных процессоров, то планировщик выбирает задание, находящееся ближе всего к голове очереди и для запуска которого в данный момент достаточно ПЭ. 16) FCFS/BF (FCFS Best Fit) - аналогично предыдущему случаю, но из очереди выбирается задание с максимальной размерностью (не превышающей количество свободных процессоров). В обоих случаях может определяться длина окна F — в этом случае для поиска задания для заполнения планировщик просматривает не всю очередь, а только первые F заданий. Обе описанные модификации дисциплины FCFS увеличивают среднюю загрузку системы, однако обладают серьезным недостатком - задания с большой размерностью имеют тенденцию к неограниченному увеличению времени ожидания — их выполнение может постоянно откладываться в пользу вновь поступающих заданий с малой размерностью (эффект устаревания заданий). 2.Планирование на основе приоритетов является обобщением дисциплины FCFS: каждому заданию приписывается некоторое значение -приоритет, который определяет порядок заданий в очереди. Затем задания обслуживаются одной из модификаций FCFS. Следующие дисциплины являются частным случаем приоритетного планирования: 2а) SPT, SJF (Shortest Processing Time, Shortest Job First) - данная дисциплина в качестве очередного задания для запуска выбирает задание с минимальным требованием времени выполнения, т.е. приоритет задания обратно пропорционален времени его обработки (предпочтение отдается коротким заданиям). Для случая однопроцессорной системы доказано [85], что дисциплина SPT строит расписание с минимальным средним временем прохождения заданий. Недостаток — задания с большим временем обработки имеют тенденцию к устареванию.
Безопасность системы управления заданиями TMS
Каждое ограничение описывается в виде элемента, имя которого является одним из вышеперечисленных видов ограничений. Имена атрибутов совпадают с именами классов, для которых устанавливается данное ограничение. Имеется два зарезервированных имени атрибута - all - определяемое им значение применяется ко всем классам, для которых значение не указано, и _total -данное значение является ограничением для всех классов в целом. Ограничения max_queue_cnt, max_queue_compl и min_job__period могут иметь только атрибут _total, поскольку до запуска задания невозможно точно сказать, к какому именно классу оно относится. Элементы ограничений объединяются с помощью элементов user_constr , group_constr или system_constr , которые определяют область действия ограничения. Например, запись вида означает, что на каждом классе узлов одновременно не может выполняться более трех заданий пользователей, принадлежащих некоторой группе, а общее число одновременно выполняемых заданий (на различных классах), принадлежащих пользователям этой группы не может превышать 5. Приведенный набор параметров обеспечивает достаточно широкие возможности по настройке требуемого уровня доступа конкретного пользователя к ресурсам системы. Диспетчер планирования использует ограничения на этапе предварительной проверки задания, а планировщик - при определении времени и узлов для запуска задания на выполнение.
За реализацию сетевых взаимодействий сервера планирования с остальными компонентами системы управления отвечает сетевой модуль (рис. 3.2). Взаимодействие компонентов основано на передаче сообщений.
Сообщения могут быть двух типов — запрос (request) и ответ (response). Запрос и ответ образуют элементарный сеанс. Сетевой модуль обеспечивает базовый набор функций, необходимых для передачи сообщений между компонентами и обеспечивает асинхронный режим работы сервера на уровне элементарных сеансов. Это означает, что между отправкой запроса и получением ответа сервер может выполнять другую работу. Такая организация позволяет уменьшить время отклика сервера и снизить вероятность сбоя в его работе при отказе вычислительных узлов. Кроме того, сетевой модуль инкапсулирует особенности реализации сетевого взаимодействия и, вообще говоря, может быть модифицирован для работы в сетях, не поддерживающих семейство протоколов TCP/IP. Для доставки сообщений используются протоколы UDP и TCP. Поскольку система управления предназначена для работы в локальных сетях, использование протокола UDP допустимо и позволяет избежать накладных расходов на установление и поддержку виртуального соединения. По этому протоколу передаются короткие сообщения, размер которых не превышает максимального размера для UDP-пакета. Для передачи длинных сообщений, а также сообщений, которые могут повлиять на безопасность системы, используется протокол TCP.
Обращение к модулю происходит путем вызова функции send_message оператором следующего формата: send_message(CMessage msg, CObject obj, CSavedData save, int timeout, int tcp_only); Функция имеет следующие параметры - сообщение msg, которое необходимо отправить. Адрес получателя инкапсулирован в сообщении. Остальные параметры используются только в том случае, когда сообщение является запросом. Параметр obj — ссылка на объект-отправитель сообщения. При получении ответа на данный запрос он будет передан объекту obj, кроме того, при истечении таймаута объект получит сигнал о невозможности доставки сообщения. Параметр save - позволяет объекту-отправителю сохранить некоторую информацию, которая потребуется ему при обработке ответа на посылаемый запрос; timeout - устанавливает предельное время, в течение которого сетевой модуль будет пытаться доставить сообщение. По истечении указанного периода отправителю obj будет возвращено сообщение об ошибке. Флаг tcp_on!y позволяет указать сетевому модулю, что для доставки сообщения необходимо всегда использовать протокол TCP, независимо от длины сообщения. Поскольку система управления TMS предназначена для работы в сети коллективного доступа к вычислительным ресурсам, важным аспектом разработки является обеспечение информационной безопасности системы. Необходимо обеспечить защиту вычислительных узлов и управляющей машины от несанкционированного доступа, а также обеспечить разграничение прав пользователей системы TMS. Основными источниками угрозы безопасности системы TMS можно считать следующие: 1. Попытка запуска на вычислительном узле задания с измененными правами или от имени другого пользователя. 2. Попытки несанкционированного доступа к агенту узла и передачи ему команд по управлению заданиями. 3. Попытки «подменить» некоторые файлы на вычислительном узле при копировании файлов. Безопасность системы управления базируется на следующих положениях: 1. Задания на вычислительных узлах никогда не запускаются с правами суперпользователя. Запуск новых процессов, а также операции чтения/записи в файлы осуществляется от имени владельца задания. 2. Все компоненты системы запускаются от имени суперпользователя, и поэтому могут использовать сетевые порты с номерами меньше 1024. Использование таких портов уменьшает вероятность подмены процессов на управляющей машине. 3. Сетевой модуль при получении сообщения-ответа всегда сравнивает адрес отправителя ответа и адрес, куда ранее был отправлен запрос. В случае несовпадения сообщение отбрасывается и производится запись в журнал событий. 4. При выполнении операции копирования файлов порождается отдельный поток управления, а уровень привилегий надежно сбрасывается до уровня пользователя-владельца задания. 5. При поступлении заданий, имя владельца имеет вид username@hostname. По умолчанию, задание запускается на вычислительных узлах от имени пользователя username, кроме суперпользователя root. Это вполне логичное допущение, поскольку очень часто в локальных сетях используется единая доменная служба имен (например, NIS). Однако имеется возможность переопределить такое поведение с помощью файла usermap.cfg. С его помощью можно задать правила трансляции сетевого имени пользователя во внутреннее имя системы, а также преобразование внутренних имен пользователей в имена реальных пользователей для вычислительных узлов.
Используемые при оценке разработанных методов планирования характеристики расписаний
Каждый информационный объект имеет идентификатор (OID), который является уникальным для данного типа объектов в течение всего жизненного цикла системы управления. Например, для класса вычислительных узлов это имя класса, для узла - его сетевое имя, для задания - TID, для пользователя -имя пользователя или UID. Процедура создания информационного объекта заключается в отправке серверу планирования запроса, в котором указывается OID целевого объекта. Сервер планирования возвращает набор атрибутов, описывающих объект и их значения.
Объекты классов TMSXXXColl представляют собой коллекции (наборы) информационных объектов одного типа. Например, функция TMSUser::getJobs() возвращает список заданий пользователя в виде коллекции TMSJobColl. Коллекция представляет собой список идентификаторов объектов (OID), включенных в коллекцию. Коллекции имеют методы для навигации по объектам (get__first(), get_next()) и для поиска объектов по идентификатору (OID). При этом информационные объекты, перечисленные в коллекции, создаются на стороне клиента только в момент непосредственного обращения к объекту. Таким образом, для того чтобы узнать, например, количество объектов в коллекции, нет необходимости получать детальную информацию о каждом объекте.
Информационные объекты кэшируются на стороне клиента, при этом каждому реальному объекту сервера планирования соответствует не более одного информационного объекта. Такая реализация, во-первых, позволяет уменьшить сетевой трафик между клиентской и управляющей машинами, а во-вторых, гарантирует согласованность данных - если один и тот же информационный объект входит в несколько коллекций, то во всех коллекциях значения свойств объекта будут одни и те же.
Получение данных от сервера планирования, создание информационных объектов и их коллекций, кэширование и обновление объектов осуществляется управляющим объектом класса TMS Conn Server. Информационные объекты имеют метод refresh(), который позволяет явно обновить состояние информационного объекта данными по запросу сервера планирования. По умолчанию, состояние объектов обновляется автоматически через определенные интервалы времени. Период обновления можно изменить с помощью метода TMSConnServer::set_update_to(int timeout). Коллекции информационных объектов автоматически не обновляются, поэтому для получения нового списка объектов необходимо повторить запрос.
Каждый информационный объект состоит из набора атрибутов. Атрибут имеет имя и значение, при этом каждый тип информационных объектов характеризуется собственным набором атрибутов. Список свойств информационных объектов приведен в Приложении 2.
Атрибуты информационных объектов являются экземплярами класса TMSProp и могут быть получены с помощью метода TMSObj::get_prop( nMfl_aTpn6yra ). Метод TMSObj :;еІ_іуре( имя_атрибута ) позволяет определить тип значения атрибута. Значение атрибута может являться строкой, целым числом, вещественным числом или ресурсным требованием. Значения последнего типа являются сложными объектами и состоят из пар вида res_name=res_val, где res_name - имя ресурса, определенное в сервере планирования, res_val — значение ресурса. Например, такой тип имеет атрибут задания cons_res, который определяет, какое количество ресурсов было использовано заданием при выполнении.
Доступ к значениям атрибутов осуществляется с помощью методов класса TMSProp - get_str_valQ, get_int_val(), get_float_va]() и get_res_val() соответственно. Метод get_res_yal() возвращает объект TMSResProp, который позволяет работать с каждым значением ресурса по отдельности. Типизация значений атрибутов не является строгой, поэтому при вызове вышеперечисленных функций могут выполняться неявные преобразования -например, при вызове get_int_va1() для строкового атрибута, будет предпринята попытка конвертировать строковое значение в число. Если преобразование типов недопустимо, возбуждается исключение типа TMSTypeError. Вызов метода get_str_val() является корректным для атрибутов любого типа и возвращает строковое представление значения атрибута. Для атрибутов, имеющих тип «ресурсное требование» строка будет иметь вид res_namel=res_vall, res_name2 = res_val2, ... . Класс TMSObj также имеет реализацию методов get_ type _val, поэтому запись вида TMSObj ::get_prop( HMfl_aTpH6yTa )- get_ type __val () эквивалентна более компактной форме TMSObj : еі_ іуре _уа1( имя_атрибута ). Если имена атрибутов неизвестны, может быть организован перебор атрибутов с помощью методов TMSObj::get_first_propO и TMSObj ::get_next_prop().
Конкретные классы информационных объектов предоставляют специальные методы для доступа к различным свойствам объекта. Например, получить идентификатор задания можно с помощью метода TMSJob::get_tid(), который равносилен вызову TMSObj::get_int_vaI("TID")
Для того, чтобы изменить состояние некоторого объекта сервера планирования достаточно изменить значения атрибутов соответствующего информационного объекта с помощью методов set_ type _val(). Эти методы транслируют изменение атрибута в запрос, который передается серверу планирования. Кроме того, можно воспользоваться специальными методами, определенными для конкретных классов. Очевидно, что не все свойства объекта могут быть изменены. В первую очередь это относится к свойствам, которые образуют идентификатор объекта (OID) — например, не может быть изменен TID задания. Кроме того, на присваиваемые значения могут накладываться различные ограничения. Все проверки производятся на стороне сервера, а клиенту возвращается результат выполнения операции. Все set-методы возвращают целочисленный код ошибки (0 - нет ошибки).
Некоторые информационные объекты имеют также методы, которые позволяют выполнять действия, не связанные с изменением состояния объектов сервера. Например, метод TMSJob::kiIl(int sig) позволяет послать UNIX-сигнал sig выполняющемуся заданию.
