Содержание к диссертации
Введение
Глава 1 Исследование структуры и принципов функционирования сервисов передачи файлов в глобальных распределенных инфраструктурах 13
1.1 Исследование архитектуры сервисов передачи файлов 13
1.1.1 Общие сведения о сервисе передачи файлов (FTS) 13
1.1.2 FTS-каналы 18
1.1.3 Схемы взаимодействия FTS с элементами сервиса управления данными 21
1.2 Исследование методов и средств мониторинга информационных систем 23
1.2.1 Вычислительные машины и мониторинг их состояния 24
1.2.2. Становление информационных систем и новые задачи мониторинга 26
1.2.3. Мониторинг баз данных и новые формы представления результатов 28
1.2.4. Мониторинг распределенных систем 29
1.2.5. Мониторинг компьютерных сетей 33
1.2.6. Мониторинге человеческим лицом 36
1.2.7. Новое тысячелетие и технологии мониторинга :.37
1.2.8. Мониторинг грид 39
Глава 2 Методы и средства обработки и хранения информации о сбоях, возникающих при передаче данных в глобальных распределенных инфраструктурах 42
2.1 Хранение данных об ошибках 42
2.2 Прототип системы мониторинга 43
2.2.1 Извлечения данных в прототипе системы мониторинга 44
2.2.2 Хранение данных в прототипе системы мониторинга 44
2.2.3 Представление данных в прототипе системы мониторинга 45
2.3 Исследование сбоев, возникающих на каналах передачи данных 50
2.3.1 Исследование сбоев в FTS версии 1.5 51
2.3.2 Исследование сбоев в FTS версии 2.0 55
2.3.3 Основные результаты исследования сбоев на каналах передачи данных 58
Глава 3. Разработка и реализация подхода к проектированию систем мониторинга сервисов передачи файлов 61
3.1 Классификация ошибок, возникающих в распределенных системах передачи данных 61
3.2 Подход к проектированию систем мониторинга сервисов передачи файлов в крупных распределенных грид-инфраструктурах 62
3.3 Система мониторинга сервиса передачи файлов 64
3.4 Отчеты в системе мониторинга 71
3.5 Панель администратора в системе мониторинга 78
3.6 Механизм оповещений в системе мониторинга 79
Глава 4 Автоматизация грид 83
4.1 Автономные грид 83
4.1.1 Архитектура грид 84
4.1.2 Автономный компьютинг 86
4.1.3 Автоматизация и адаптивность грид 91
4.1.4 Сервис управления грид 95
4.3 Применение ЭС для автоматизации сервиса передачи файлов 100
Заключение 105
Приложение А: Различные интерфейсы системы мониторинга FTS 108
Литература 110
- Общие сведения о сервисе передачи файлов (FTS)
- Представление данных в прототипе системы мониторинга
- Подход к проектированию систем мониторинга сервисов передачи файлов в крупных распределенных грид-инфраструктурах
- Автоматизация и адаптивность грид
Введение к работе
Актуальность темы
Уже более 20 лет распределенные компьютерные инфраструктуры используются для решения широкого класса задач. Одним из наиболее интересных направлений в данной области является грид - технология создания географически распределенных программно-аппаратных компьютерных инфраструктур, предназначенных для объединения разнородных ресурсов с целью повышения эффективности их использования и экономии затрат. Физика, химия, астрономия, медицина, науки о земле - это далеко не полный список областей, в которых используются грид-инфраструктуры. Одной из важнейших функций грид является распределение, хранение и обработка огромных массивов данных, за что отвечают специализированные сервисы.
В своей работе сервисы передачи данных взаимодействуют с множеством компонентов. Грид-инфраструктуры могут состоять из сотен сайтов (региональных компьютерных центров), на которых установлены различные системы хранения файлов. Для взаимодействия с системами хранения используются различные сервисы, а за передачу данных отвечают различные протоколы. Сервисы передачи данных организуют работу всех элементов и сервисов управления данными, а также обрабатывают информацию об ошибках на любом этапе передачи данных. Ежедневно подобными сервисами выполняются тысячи транспортных задач, пересылаются десятки тысяч файлов, общие объемы передаваемой информации составляют десятки терабайт в день! От надежности и корректности работы подобных сервисов напрямую зависит успех использующих их проектов.
Программная составляющая грид - middleware, промежуточное программное обеспечение (ППО). Среди наиболее известных ППО можно выделить gLite и Globus. Сервис передачи файлов в gLite называется FTS (File Transfer Service), его аналог в Globus - RFT (Reliable File Transfer Service). К концу 2006-го года FTS и RFT находились на этапе становления и набор средств их мониторинга был весьма ограничен. В основном он состоял из скриптов, визуализирующих информацию, предоставляемую самими сервисами посредством интерфейса командной строки, или комплексов мониторинга широкого профиля, отражающими общую информацию по передачам данных. Ни одна из систем не предоставляла полную информацию о состоянии сервисов, истории их функционирования, а главное об ошибках, возникающих в распределенных системах передачи данных. Подобная ситуация неблагоприятно сказывалась на надежности функционирования сервисов и требовала оперативного решения.
Актуальной задачей является и решение проблемы адаптивности грид. Из-за сложности и разнородности грид-инфраструктур существует множество трудностей в их поддержании и управлении. Для их установки, конфигурирования и контроля требуется множество опытных специалистов, которых зачастую очень сложно найти, а тем более обучить. Современные грид-инфраструктуры не способны автоматически подстраиваться под изменения программно-аппаратной среды (отсутствует адаптивность), вследствие чего реакция на сбои и изменения в инфраструктуре происходит с большим запозданием. Автоматизация работы как отдельных, так и групп сервисов способно самым положительным образом сказаться на адаптивности, а значит и на эффективности работы грид-инфраструктур.
Цель работы:
Разработка новых и совершенствование существующих методов и средств анализа и обработки информации о функционировании сервисов передачи файлов в глобальных распределенных инфраструктурах.
Для достижения поставленной цели необходимо решить следующие задачи:
Исследование структуры и принципов функционирования сервисов передачи файлов в распределенных инфраструктурах;
Разработка классификации ошибок передачи данных, возникающих в грид-инфраструктур ах.
Разработка подходов к проектированию систем мониторинга сервисов передачи файлов в грид;
Разработка системы мониторинга сервиса передачи данных и исследование полученной информации о сбоях.
Исследование возможностей адаптивности и автоматизации сервисов передачи файлов.
Методы исследования
Для решения поставленных задач использовались понятия и методы системного анализа, математической статистики и проектирования программных средств.
Научная новизна
Предложена классификация ошибок, возникающих в распределенных системах передачи данных, основанная на четкой иерархии описания сбоев и использовании механизма паттернов.
Предложен и реализован подход к проектированию систем мониторинга сервисов передачи файлов в крупных распределенных инфраструктурах.
Предложен новый сервис - сервис управления грид (Grid Management Service, GMS), способный решить проблему адаптивности глобальных распределенных систем.
Практическая ценность работы
Создана система мониторинга сервиса передачи файлов, предоставляющая широкие возможности для анализа и обработки информации о его функционировании.
Проведено исследование ошибок, возникающих при передаче файлов в крупных распределенных грид-инфраструктурах. Исследование позволило определить самые распространенные ошибки, причины их возникновения, основные области возникновения ошибок, выявить программные и логические ошибки в приложениях.
С целью автоматизации работы сервиса передачи файлов и апробации идей GMS создан прототип модуля экспертной системы, способный значительно облегчить работу администраторов систем передачи данных.
Основные положения, выносимые на защиту
Архитектурные особенности сервиса передачи файлов таковы, что для решения задач мониторинга сервиса требуется использовать модифицированные методы мониторинга из различных областей.
Предложенная классификация ошибок позволяет решить вопросы разделения, объединения и детализации сбоев, возникающих в распределенных системах передачи данных.
Разработанный подход к проектированию систем мониторинга сервисов передачи данных в глобальных распределенных инфраструктурах стандартизирует разработку приложений мониторинга.
Разработанная система мониторинга предоставляет широкие возможности для анализа и обработки информации о функционировании сервиса передачи файлов.
Предложенный сервис управления грид (Grid Management Service, GMS) способен решить проблему адаптивности глобальных распределенных систем.
Апробация работы
Результаты работы неоднократно докладывались на семинарах ЛИТ ОИЯИ, Дубна, рабочих совещаниях и семинарах ITGS, ЦЕРН, WLCG Service Reliability Workshop, ЦЕРН (26.11.2007), а так же на конференциях «Distributed computing and Grid technologies in science and education», GRID-2008, Дубна (30.5-4.06.3008) , CHEP (Computing in High Energy and nuclear Physics) 2009, Прага (20-27.03.2009) и «Молодежь и XXI век», Курск (26.5-29.5.2009). Работа была награждена первой премией молодых ученых и специалистов в номинации - «научно-технические прикладные работы», на 13-ой зимней конференции ОМУС-2009 (Объединение молодых учёных и специалистов ОИЯИ) (16.02-21.02.2009) и признана лучшей на 16-й научной конференции студентов, аспирантов и молодых специалистов
университета «Дубна» (23.3-3.4.2009), а так же конференции «Информационные системы и технологии 2009», Обнинск (15.05.2009).
Публикации и личный вклад автора
По результатам диссертации опубликовано 7 работ из них три в списке изданий, рекомендуемых ВАК для опубликования основных научных результатов диссертации [1, 2, 4].
Автор принимал непосредственное участие в создании классификации ошибок и подхода к проектированию средств мониторинга сервисов передачи данных. Разработка систем мониторинга сервисов передачи данных и определение основных принципов функционирования, архитектурных особенностей и задач сервиса управления грид проводилась лично автором.
Объем и структура работы
Общие сведения о сервисе передачи файлов (FTS)
Исследование архитектуры сервисов передачи файлов В разделе рассматриваются концептуальное устройство и архитектурные особенности сервиса передачи данных FTS, как типового сервиса передачи данных. FTS создавался на основе RFT, но на 2007 год являлся более развитым - предоставлял большие функциональные возможности, в связи с чем было решено исследовать именно его. Описываются возможности сервиса, основные структурные элементы, принципы функционирования, а так же схемы взаимодействия с другими элементами сервиса управления данными (Data Management Services).
В gLite (промежуточное программное обеспечение в EGEE/WLCG) существует , шесть сервисов высокого уровня, решающих различные задачи: Helper Services - сервис отвечающий за информационную поддержку пользователей. Он включает в себя Configuration & Instrumentation Service, Agreement Service, Bandwith Allocation & Reservation Service. Grid Access — набор инструментов для взаимодействия с сервисами: CLI (Command Line Interface) и API (программный интерфейс приложений) Security Services — сервис отвечающий за вес аспекты безопасности. Он включает в себя Authorization, Authentication, Auditing, Dynamic Connectivity. Information & Monitoring Services - сервис предоставляющий различную информацию о функционировании систем. Он включает в себя Information & Monitoring, Job Monitoring, Network Monitoring, Service Discovery. Data Management Services - сервис управления данными. Он включает в себя Meta Catalog, File & Replica Catalog, Storage Element, Data Movement. Job Management Services — сервис управления заданиями. Он включает в себя Accounting, Job Provenance, Package Manager, Computer Element, Workload Management. В проекте EGEE/WLCG используются три системы хранения данных — Castor (59), dCache (60) и DPM (61). Для взаимодействия с системами хранения (предоставления унифицированного интерфейса) был разработан специальный сервис -SRM (Storage Resource Manager) (62). За перемещение данных на физическом уровне отвечает GridFTP (63) - протокол, разработанный в рамках проекта Globus (9). Таблицы соответствия между первоначальными названиями файлов (Logical File Name, LFN), уникальными идентификационными номерами (Glbally Unique. Identifier, GUID) re названиями файлов на конкретных сайтах (Site URL, SURL) хранятся в LFC (LCG File Catalog) (64). LFC объединяет в себе функции файлового каталога и каталога реплик. Для обеспечения необходимой надежности, производительности и организации взаимодействия между остальными сервисами управления данными был создан сервис передачи файлов - FTS (File Transfer Service). В задачи FTS так же входит и обработка ошибок от систем, сервисов и протоколов, участвующих в передаче данных в глобальных распределенных инфраструктурах. Это является весьма не тривиальной задачей, поскольку сообщения о сбоях изменяют структуру и содержания не только в различных компонентах но и в различных версиях и модификациях одного и того же компонента. FTS используют приложения, разрабатываемые для конкретных экспериментов. Типичная задача FTS выглядит как регулирование интенсивных потоков данных для набора пар «файл на сайте источнике - файл на сайте назначения». FTS позволяет: задавать правила использования ресурсов сайта, в соответствии с политиками сайтов и виртуальных организаций; предотвращать перегрузку сетей и перегрузку хранилищ данных; отслеживать общую ситуацию и получать комплексную информацию об ошибках, возникающих во время работы сервиса. Данный сервис должен обеспечить надежный механизм передачи файлов типа точка-точка, предоставить удобный способ распределения ресурсов между экспериментами, а также различные возможности мониторинга и контроля для администраторов сайтов; дать возможность контролировать запросы, поступающие со стороны пользователей, устанавливать последовательность их исполнения, а так же ранжировать их по приоритетности ,для менеджеров виртуальных организаций. г. : FTS состоит из ряда отдельных компонентов рис. 1, взаимодействующих только с центральной базой данных на платформе Oracle. Единственный компонент, с которым взаимодействуют пользователи - Web-сервис. Посредством командной строки, либо через собственный скрипт, использующий стандартные интерфейсы, пользователь имеет возможность запускать задачи и отслеживать их состояние. Множество пользователей подключаются к Web-сервису по безопасному соединению через протокол SOAP. Web-сервис реализован на основе Tomcat, а использование WSDL (Web Service Definition Language) позволяет пользователям написать собственное приложение для взаимодействия с сервисом на удобном для них языке программирования.
Представление данных в прототипе системы мониторинга
FTS отвечает за взаимодействие различных элементов хранения и передачи данных, их различных версий и модификаций, поэтому спектр возникающих ошибок, приводящих к неудачному завершению передачи, довольно велик, кроме того в тексте ошибок, зачастую, содержится уникальная персонифицированная информация - время, дата, название файла или атрибуты пользователя:
В приведенном примере [id] - уникальный идентификатор запроса, [srm] -название SRM, к которому происходит запрос, и {SRMJNVALID REQUEST] -внутренний идентификатор запроса SRM, могут быть различными, однако, тип ошибки при этом не меняется.
Необходимо было разработать удобный механизм хранения, добавления и изменения информации об ошибках. В результате было предложено использовать механизм паттернов — устойчивых составных частей однозначно характеризующих тип ошибки. Так в приведенном примере части «Failed to complete PrepareToPut request» и «on remote SRM» не меняются и могут быть использованы для определения типа сбоя. Это позволит объединять данные о подобных ошибках и работать с ними на более высоком уровне. При использовании подобного механизма следует определить минимальное достаточное число составных частей, описывающих сбой. Проанализировав все имеющиеся сообщения об ошибках, было решено, что для однозначного определения типа сбоя достаточно хранить гри его составные части. Таким образом, ошибка в общем случае описывается тремя ее составными частями, уникальным идентификатором и полным примером. Получив механизм хранения информации о типах сбоев можно было приступать к реализации прототипа системы мониторинга.
Прототип системы мониторинга Сервис FTS, на конец 2006-го года был устроен таким образом, что информация о передачах данных хранилась на серверах, где были установлены "агенты передач" в виде log-файлов (файлов отчетов). Они являлись единственным доступным источником информации. Для получения информации о проблемах на каналах, требовалось обрабатывать log-файлы, .сохранять полученные данные, а так же предоставлять доступный интерфейс для работы с ними. Соответственно, для системы мониторинга. была выбрана трехзвенная архитектура: извлечение данных — набор скриптов, ответственных за перемещение и обработку лог-файлов (реализация - Perl, shell), хранение данных - MySQL, представление данных - web-интерфейс (реализация - РНР, XHTML). Схема работы системы представлена на рис 5.
Первым шагом работы скриптов уровня извлечения данных является перемещение log-файлов с серверов, на которых установлены агенты передач, к узлу, на котором установленная система мониторинга. Можно было бы обойтись и без лишних манипуляций, т.к. обработка log-файлов может производиться непосредственно "на месте", но для уменьшения нагрузки на сервера было решено производить все работы на сторонних машинах. За временной интервал фиксации показаний системы был выбран один час, т.к. это позволяло своевременно реагировать на возникновение внештатных ситуаций и, в тоже время, не создавало чрезмерной нагрузки на ресурсы.
Следующим шагом является определение количества разнообразных ошибок возникших на канале с 12 часов ночи. Упрошенный алгоритм работы, скрипта выглядит I примерно так: просматривая все ошибки из базы, скрипт ищет в тексте очередного-log-файла полное вхождения всех ее составных частей, если в результате работы ошибка не была опознана, то она трактуется, как ранее неизвестная и ее текст направляется для рассмотрения администратору, в противном случае, увеличивается количество ошибок подобного типа на канале. Результатом работы программы является количество ошибок каждого типа на определенном канале, и остается только записать эту информацию в БД.
В базе данных (MySQL) храниться информация об известных ошибках -примеры, паттерны, типы и т.д. Отдельная таблица отведена для хранения информации об отслеживаемых каналах. Существует "историческая таблица", в которой записываются случаи появления ошибок на каналах с описанием вызвавших их причин. В основной таблице, в виде временных срезов, хранится информация о количестве разнообразных ошибок, возникающих на каналах передачи данных.
Рис. 6. Общий вид интерфейса системы. Основной блок программы "Monitoring tools" имеет следующие настройки -канал, временной период (может быть предоставлена самая последняя информация, информация за последние 24 часа, либо за временной период более суток) и форма вывода результата. Информация может быть представлена в виде таблиц, графиков, диаграмм, а также агрегирована по типу ошибок. Примеры отчетов в системе приведены на рис.
Кроме приложения, вызвавшего ошибку: Castor, SRM, GridFTP и т.д., зачастую можно установить где именно произошла ошибка - на сайте источнике, сайте назначения или в процессе передачи, кроме того, на данном этапе стало очевидно, что количество ошибок настолько велико (было выделено более 350 паттернов), что без введения классификации, объединяющей сходные сбои, работать с ними довольно сложно. Проанализировав имеющиеся паттерны, было выделено 16 различных классов ошибок. Ниже дается название класса ошибки и ее краткое описание, "fts" - ошибки, возникающие из-за неисправности самого FTS, "globus" - ошибки с gridftp, "user" -ошибки, возникающие по вине пользователей, "tcp" - ошибки подключения к сети, "t_dcache", "s_dcache", "dcache" - ошибки dCache ("t_" и "s_" обозначают, на чьей стороне произошла ошибка, на сайте источнике или сайте назначения: t- target, s-source), "t_castor", "s_castor", "castor" - ошибки Castor, "t_dpm", "s_dpm", "dpm" -ошибки DPM, и "t_srm", "s_srm", "srm" - кроме ошибок непосредственно самого SRM, в данный класс входят и ошибки, у которых не удалось выяснить приложение, повлекшее их возникновение. Практические испытания показали, что намного удобнее сначала определить класс проблем, возникающих на канале, а затем переходить к более детальным исследованиям. Тип представления результата, при котором ошибки на канале агрегированы по классам, в разработанной системе называется аналитический отчет. Пример аналитического отчета представлен на рис. 8, где в первой строке после даты и времени перечисляются классы ошибок, а в следующей строке приводится число соответствующих ошибок.
Подход к проектированию систем мониторинга сервисов передачи файлов в крупных распределенных грид-инфраструктурах
Классификация ошибок, возникающих в распределенных системах передачи данных Использование паттернов позволило стандартизировать представление информации об ошибках, достичь взаимопонимания между разработчиками программных приложений и пользователями FTS, а также установить связи между различными ошибками. За время работы автором было выделено более 400 паттернов ошибок. Для облегчения работы с ними было определено 16 различных объединяющих классов. На тот момент в FTS использовалось только одно поле для описания ошибки, и обработка данных о них требовала много ресурсов, т.к. необходимо было, производить поиск в строке.і: Изучение выделенных паттернов и классов позволило; совместно с коллективом разработчиков FTS разработать и применить в FTS версии 2.0 новую классификацию ошибок, в соответствии с которой сообщение о сбое состоит из четырех частей:
Scope - источник ошибки (может принимать значения: SOURCE - сайт-источник, DESTINATION - сайт-назначения, TRANSFER - транспортные протоколы, проблемы связи и т.д.). Category — класс ошибки. Определено более 30 неизменных классов ошибок. (FILE_EXIST, NO_SPACE_LEFT, TRANSFERJTIMEOUT и т.д.) Phase - этап в жизненном цикле передачи, на котором произошла ошибка (ALLOCATION, TRANSFER_PREPARATION, TRANSFER и т.д.) Message — детальное описание ошибки (400 паттернов). Четкая иерархия описания сбоев позволяет достаточно легко решать вопросы разделения, объединения и детализации. Существует возможность группировать сбои по источникам их возникновения и определить их класс для получения общего представления о ситуации, а при необходимости получить детальное описание ошибок с целью их исправления. Кроме того использование различных полей для хранения составных частей ошибок значительно уменьшает время обработки данных. Из вышеизложенного положение о том. что предложенная классификация ошибок, представляет стандартизированное решение вопросов разделения, объединения и детализации сбоев, возникающих в распределенных системах передачи данных. 3.2 Подход к проектированию систем мониторинга сервисов передачи файлов в крупных распределенных грид-инфраструктурах . Следующим шагом работы стала разработка общего подхода к проектированию средств мониторинга для сервисов передачи файлов. Подход ориентирован на удовлетворение общих требований к функциональности системы, сформулированным в первой главе, направленности на минимизацию времени вычислений, использование единых стандартов и автоматизированных механизмов обработки информации. Основные положения подхода следующие: 1. Все компоненты систем мониторинга должны разрабатываться в соответствии с единой классификацией ошибок. Данное правило позволит избежать недопонимания между пользователями и администраторами, упростить процесс разработки приложений и снизить нагрузку на БД при выполнении большинства запросов по обработке исходных данных. 2. Агрегация и визуализация информаг ии должны предоставлять возможность точного определения причин и мест возникновения проблем. У пользователей должна существовать возможность получения как общих отчетов - количество удачных/неудачных передач для всего сервиса или канала, так и максимально детализированных, вплоть до количества определенных ошибок на конкретном хосте (элементе хранения) для любой из организаций. Должна существовать возможность работы с различными уровнями детализации и получения отчетов в наиболее удобных для пользователей формах. 3. Большинство вычислений долэ/сны производиться в базе данных. Кроме удобного -механизма добавления изменений, это позволит не зависеть от дополнительных программных и аппаратных ресурсов, и значительно снизить время при доработке процедур. 4. Агрегированная для различных отчетов информация должна храниться в БД. Большинство нужных пользователям отчетов, это различные «срезы» одних и тех же исходных данных. Поэтому, следует еще на этапе проектирования определить основные объекты, информация о которых может заинтересовать пользователей, и разработать механизмы объединения исходных данных для большинства типов отчетов. Кроме того, необходимо определить временные интервалы, по истечению которых данные могут быть «безболезненно» суммированы. 5. Все средства мониторинга должны быть оснащены механизмами оповещений. Объемы информации об ошибках настолько велики, что анализ требует очень много времени. Механизмы оповещений позволяют администраторам задавать наборы правил, при срабатывании которых им будут отправлены сообщения, что позволит работать с системой только в случае если случилось что-нибудь действительно серьезное. 6. В системах мониторинга должна существовать возможность анализа взаимозависимостей между ошибками. Определение причин возникнования ошибок - очень сложная задача. Изучение взаимозависимостей межу новыми и хорошо изученными ошибками способно значительно сократить время на определение причин возникновения последних.
Данный подход детально осуждался и уточнялся на рабочих совещания группы IT GS, и был принят как основа для работы в 2008-ом году. Он призван упростить и стандартизировать разработку приложений, предназначенных для мониторинга, и может быть распространен на широкий спектр различных грид-сервисов. Практическим результатом этих исследований, методов и подходов явилась разработка полнофункциональной системы мониторинга сервиса передачи данных FTS, представленная ниже.
Автоматизация и адаптивность грид
На четвертом уровне рис. 25 находится «главный автономный менеджер» обеспечивающий управленческие функции в масштабах всей системы. Существуют два типа подобных менеджеров: «с разделением по дисциплинам» - менеджер организует работу автономных менеджеров точек доступа только определенного типа (самонастройки, самолечения, самооптимизации или самозащиты); «без разделения» -менеджер организует работы менеджеров точек доступа различного типа.
На пятом уровне находятся интерфейсы для IT специалистов. Как говорилось ранее, автономные функции выполняют задачи, которые IT специалисты хотели бы делегировать, однако в отдельных случаях может понадобиться привлечь к решению некоторых задач специалистов. Для подобных нужд используется стандартные консольные интерфейсы, основанные на промышленных стандартах. Подобная организация позволяет решать как локальные, так и задачи глобального масштаба из единого центра.
В автономных системах должна существовать база знаний (Knowledge source) к которой должен быть обеспечен стандартизированный интерфейс. В подобной базе может храниться информация о «симптомах», политиках, запросах на изменения состояния и планах изменений. Автономные менеджеры могут получать знания из одного или нескольких источников, а менеджеры автономных менеджеров могут активировать знания, позволяя автономным менеджерам выполнять такие операции как распознавание конкретных симптомов либо применение конкретных политик. Естественно, создание автономных систем непростая задача. На первого этапе автоматизированные функции будут лишь собирать и объединять информацию необходимую администраторам для принятия решений. Затем они смогут выступать в качестве советников, предлагая администратору различные курсы действий С развитием автономных технологий и увеличением доверия к ним, им будут Доверены действия на самом нижнем уровне. С течением времени, администраторы будут принимать только управленческие решения наивысшего уровня за счег автоматизации все большего количества процессов на нижнем уровне.
Автономный компьютинг очень мощная технология. В последнее годы возможности ее применение в различных областях породили множество исследований Например, интересные работы в данном направлении можно найти в применении к .компьютерным сетям (72; 73), веб-сервисам (74), файловым системам (75; 76), Установке и конфигурационному анализу (77) и т.д. Естественно, что применение основных концепций автономного копыотинга к любой области, например к грид, способно принести значительную пользу. В следующем разделе будет рассмотрена сцхуация с автоматизацией грид.
Автоматизация и адаптивность грид В настоящее время существует два направления автоматизации грид. ;в первом разработчики пытаются внести некоторые функции автоматизации в уже существующие системы мониторинга, а во втором - разработать в соответствии с правилами автономного копыотинга отдельный автономный компонент, приложение или даже грид. В первой работе (78), которую хотелось бы упомянуть, авторы представляют Acord - автономную сервисную архитектуру для самоорганизующихся приложений. Прототип реализованной системы является расширением Apache Axis Toolkit (79) интегрированным с НПО Globus. Работа проводится в рамках проекта AutoMate (80), основная задача которого определение ключевых технологий для решения проблем создания адаптивных грид-приложений. Ключевым элементом адаптивной части проекта является Автономный сервис потоков данных (Autonomic Data Streaming Service), который используется для передачи больших объемов данных с суперкомпьютеров NERSC (Nansen Environmental and Remote Sensing Centre) и ORNL (Oak Ridge National Laboratory) для обработки и анализа на кластеры PPPL (Princeton Plasma Physics Laboratory). Сервис- обладает функциями самооптимизации, самоконфигурирования и самолечения. В данной конкретной реализации сервис не управляет І другими сервисами, а только своим состоянием,, т.к; основной целью исследования было управление состоянием приложения, а не окружающей среды. В работе (81) рассматриваются вопросы создания автономного децентрализованного менеджера нагрузки (Workflow Management System, WMS). Т.к. проект- находится только на начальной стадии, в работе приводятся только базовые концептуальные положения, принципы и алгоритмы работы. В (82) авторы предлагают создать автоматическую систему управления грид (autonomic grid management system, AGMS) используя Autonomic Tollkit, разработанный IBM. В работе автономная система рассматривается как совершенно отдельная от общей архитектуры грид-системы. При подобной организации работы грид ничего не знает об этой системе. С одной стороны это очень удобный и простой способ решения большинства задач, однако, скорее всего эбое стандартное приложения столкнется с множеством проблем при работе с JVE андартизированным грид.
