 |
"ЖУРНАЛ РАДИОЭЛЕКТРОНИКИ" N 12, 2002 |
 |
Сервисы GRID, как объекты стандартизации
Каменщиков М.А.
Институт радиотехники и электроники РАН
Получена 11.12.03 г.
Аннотация
Обобщен мировой опыт по созданию и применению GRID, приведены основные понятия и определения, выявлены основные проблемы по реализации GRID-технологий, в том числе построение архитектуры GRID, проведена классификация сервисов, рассмотрены вопросы безопасности GRID. Показана необходимость реализации принципов открытых систем.
Содержание
5.1. Стандартные протоколы обеспечения безопасности
5.2. Требования к системам безопасности в распределенной вычислительной среде
Список использованных источников
Введение
Распределенная информационно-вычислительная среда состоит, как правило, из разных аппаратно-программных платформ, содержит компьютеры разных классов, в том числе персональные компьютеры, рабочие станции, мейн-фреймы, супер-ЭВМ, т.е. представляет собой гетерогенную среду. Среди основных проблем, которые необходимо решить в такой среде, обычно называют управление ресурсами, обеспечение защиты информации и обеспечение "прозрачности" среды. Прозрачность следует понимать в том смысле, что должна обеспечиваться межплатформенная переносимость прикладных программ, обмен данными, взаимодействие удаленных систем через согласованные протоколы. Для достижения этих качеств среда должна строиться на основе принципов открытых систем. Существо принципов открытых систем состоит в использовании стандартных интерфейсов. Но, от декларации необходимости реализации принципов открытых систем среда еще не приобретает свойств открытости. Необходимо применить целый набор методов и средств, выполнить ряд этапов, чтобы система стала открытой, т. е. необходимо использовать определенную технологию, которая называется технологией открытых систем. Одним из необходимых условий применения ТОС являеться выбор объектов стандартизации, в данном случае сервисов.
1 Проблема GRID
В настоящее время распределенную информационно-вычислительную среду среду (РИВС) принято называть GRID (вычислительная решетка) (см., например, [1]).
Наиболее характерными свойствами этой информационно-вычислительной среды являются [2-5]:
- масштабы вычислительного ресурса (объем памяти, количество процессоров), которые многократно превосходят ресурсы отдельного компьютера или одного вычислительного комплекса;
- гетерогенность среды; в ее состав могут входить компьютеры различной мощности, работающие под управлением различных операционных систем и собранные на различной элементной базе;
- пространственное (географическое) распределение информационно-вычислительного ресурса;
- объединение ресурсов, которые не могут управляться централизованно (в случае, если они не принадлежат одной организации);
- использование стандартных, открытых, общедоступных протоколов и интерфейсов.
- обеспечение информационной безопасности.
В дальнейшем под термином «GRID-система» будем подразумевать распределенную вычислительную систему, имеющую вышеперечисленные свойства. По своему назначению GRID принято делить на вычислительные системы (computational GRID) и системы, ориентированные на хранение больших массивов информации (data GRID).
К прикладным задачам, которые могут использовать GRID, в частности, относятся:
- сложное моделирование;
- совместная визуализация очень больших наборов научных данных;
- распределенная обработка в целях анализа данных;
- связывание научного инструментария с удаленными компьютерами и архивами данных.
Наиболее эффективно применение РИВС, по-видимому, для решения следующих задач:
- распределенные высокопроизводительные вычисления, решение очень крупных задач, требующих максимальных процессорных ресурсов, памяти и т.д.;
- «высокопоточные» вычисления, позволяющие организовать эффективное использование ресурсов для небольших задач, утилизируя временно простаивающие компьютерные ресурсы;
- проведение крупных разовых расчетов;
- вычисления с привлечением больших объемов распределенных данных, например, в метеорологии, астрономии, физике высоких энергий;
- коллективные вычисления: одновременная работа нескольких взаимодействующих задач разных пользователей.
Анализ мирового опыта построения GRID-систем показывает, что в их основе лежат решения следующих проблем:
- объединение разнородных систем;
- совместное использование данных;
- динамическое выделение ресурсов;
- переносимость приложений в гетерогенной среде;
- обеспечение информационной безопасности.
- следует отметить, что решения, в основном, основываются на применении открытых стандартов.
2 Основные понятия GRID
Понятия GRID, GRID-структура, GRID-система употребляются как синонимы.
2.1 Ресурс
Примерами ресурсов являются вычислительные ресурсы, системы хранения, каталоги, сетевые ресурсы.
Ресурсы могут быть разделены на физические и логические. К физическим относятся: оперативная память, память на долговременных носителях, количество и производительность процессоров и т.д. Примерами логических ресурсов являются распределенная файловая система, компьютерный кластер, распределенный пул компьютеров.
Сетевой протокол - это формальное описание форматов сообщений и набор правил, определяющий обмен сообщениями. Различают сетевые протоколы нижнего (Ethernet и др.), среднего (IP, TCP и др.) и высокого уровня (FTP, HTTP и др.).
Синтаксис - это правила, определяющие порядок и форму записи информации в сообщении.
2.4 Сервис
Сервис – это сущность, которая предоставляет специфическую функциональность.
2.5 Интерфейс прикладных программ
Интерфейс прикладных программ (API) представляет собой набор функций (сервисов), позволяющих прикладной программе осуществлять доступ к ресурсам через обслуживающую операционную систему.
3 Сервисы GRID
Распределенная вычислительная среда должна обладать набором сервисов, обеспечивающих контролируемое выполнение прикладных программ авторизованных пользователей. Специфика сервисов GRID определяется, прежде всего, характером самой вычислительной среды: GRID представляет собой динамическое образование. С течением времени могут быть изменены как количество объединенных вычислительных узлов (например, за счет нештатного сбоя или планового выключения), так и их качественные характеристики (изменение вычислительной нагрузки одного узла).
Для нормального функционирования распределенной системы необходимо обеспечить:
- идентификацию выполняемой программы
Для обеспечения контроля выполнения прикладной программы она должна быть снабжена уникальным номером (идентификатором). Присвоение такого идентификатора и контроль его уникальности должны выполнятся специальным сервисом GRID;
- авторизацию пользователя
В GRID задача авторизации пользователя представляет собой сложную проблему. Сервис авторизации пользователя должен обеспечить уникальность идентификатора пользователя на всех вычислительных узлах, образующих распределенную среду, а также определять относительный приоритет пользователя, необходимый для нормальной работы службы распределения вычислительных ресурсов между прикладными программами;
- поиск ресурсов
Результаты работы этого сервиса определяют размеры доступного в настоящий момент времени вычислительного ресурса, и могут быть использованы для контроля текущего состояния системы;
- описание ресурсов
Сервис осуществляет единое описание разнородных ресурсов, находящихся в текущий момент времени в составе GRID;
- резервирование ресурсов
Данный сервис должен обеспечить «захват» свободных ресурсов для размещения на нем прикладной программы. Его работа тесно связана с работой сервиса поиска ресурсов и сервиса описания ресурсов;
- выполнение распределённых алгоритмов.
Этот сервис обеспечивает выполнение параллельных программ.
- доступ к удалённым данным.
Сервис обеспечивает работу распределенных баз данных
- распределение ресурсов.
Менеджер ресурсов осуществляет разделение существующего ресурса между прикладными программами;
- обнаружение неполадок
Сервис определяет работоспособность включенных в вычислительный процесс узлов. Как только «вычислительное поле» одной из прикладных программ оказалось разрушенным, данный сервис сообщает об этом менеджеру ресурсов и менеджеру управления заданиями.
Количество и характер сервисов, обеспечивающих работу GRID, может изменяться в зависимости от назначения данной вычислительной среды.
4 Архитектура GRID
При описании различных уровней архитектуры GRID, будем следовать модели “песочных часов” [6]. Как показано на рисунке 1, горловина песочных часов соответствует небольшому количеству базовых абстракций и протоколов (таких как TCP и HTTP в Internet), которые необходимы для связи высокоуровневых служб с низкоуровневыми.
Детализируя рисунок 1, архитектуру GRID можно представить в виде иерархической структуры (рисунок 2), состоящей из нескольких уровней [28]. На каждом из представленных уровней существуют свои сервисы, взаимодействующие посредством определенных протоколов.
 |
Рисунок 1 - Модель песочных часов
Рисунок 2 - Многоуровневая Архитектура GRID
4.1 Уровень Fabric
Этот уровень предоставляет ресурсы, совместный доступ к которым обеспечивается через протоколы GRID.
Для доступа к вычислительным ресурсам требуются:
- механизмы для запуска программы и мониторинга ее выполнения.
- механизмы для определения аппаратных и программных характеристик, а также определения текущего состояния (например, рабочей загрузки).
Для доступа к ресурсам хранения требуются:
- механизмы для запуска программы и мониторинга ее выполнения.
- механизмы для посылки/получения файлов, в том числе высокоскоростные многопоточные механизмы [7], механизмы для чтения/записи подмножеств файлов;
- механизмы для проведения удаленной выборки данных [8];
механизмы менеджмента, которые позволили бы контролировать ресурсы, назначенные для пересылки данных;
механизмы, позволяющие узнать аппаратные и программные характеристики и текущую загрузку;
- механизмы улучшенного резервирования.
Для доступа к сетевым ресурсам требуются:
- механизм менеджмента и контроля над ресурсами, назначенными для сетевого трафика (приоритеты, резервирование);
- функции определения характеристик и загрузки сети.
Для доступа к ресурсам репозитория кодов программ требуется механизм управления версиями исходного и объектного кода (например, система CVS).
Для доступа к ресурсам каталогов требуется механизм обеспечения хранения данных, обработки запросов и проведения обновления данных.
4.2 Уровень Connectivity
Уровень Connectivity определяет базовые коммуникационные и идентификационные протоколы, требуемые для проведения специфичных для GRID операций (транзакций). Коммуникационные протоколы позволяют осуществлять обмен данными между ресурсами уровня Fabric. Идентификационные протоколы, построенные на коммуникационных сервисах, предоставляют криптографически защищенный механизм для верифицирования и идентификации пользователей и ресурсов.
Решение проблемы безопасности на уровне Connectivity должно базироваться на существующих стандартах.
Идентификация пользователя может быть осуществлена различными способами [9]. В частности, может быть использовано однократное регистрирование. При использовании этого метода пользователи должны регистрироваться в вычислительной среде только один раз и, после успешного завершения операции, получить доступ к ресурсам уровня Fabric.
Другим способом идентификации является делегирование [10-12]. Программа пользователя должна иметь доступ к ресурсам, на которых он авторизован. Опционально программа должна быть способна передать подмножество своих прав другой программе.
Естественно, каждый провайдер ресурсов может иметь ряд локальных решений по безопасности. Система безопасности вычислительной среды должна взаимодействовать с этим классом локальных решений.
Более подробно принципы построения системы безопасности в распределенных системах изложены в п.4.
4.3 Уровень Resource
Уровень Resource базируется на коммуникационном и авторизационном протоколах уровня Connectivity. Он определяет протоколы для:
- осуществления безопасного обмена информацией;
- инициализации, мониторинга и проведения совместных операций на индивидуальных ресурсах;
- создания учетных записей пользователей;
- проведения учета утилизированного времени для каждого из пользователей.
Для доступа и контроля над локальными ресурсами сервисы уровня Resource используют функции уровня Fabric. Следует отметить, что протоколы уровня Resource полностью связаны с индивидуальными ресурсами.
По своему назначению протоколы уровня Resource могут быть сгруппированы в два класса:
- информационные протоколы, которые используются для обзора информации о структуре и состояниях ресурса (например, конфигурации, текущей загрузке и пр.);
- протоколы менеджмента, которые используются для предоставления доступа к совместным ресурсам. В частности, они обеспечивают выполнение функций резервирования и контроля соответствия ресурсов запрашиваемым требованиям.
Протоколы уровней Resource и Connectivity являются базовыми, образуют «горлышко» в модели «песочных часов» (см. рисунок 1) и должны быть ограничены небольшим, хорошо продуманным множеством. Эти протоколы должны быть спроектированы таким образом, чтобы позволить совместное использование разнородных ресурсов, но при этом не должны слишком ограничивать допустимые типы протоколов более высокого уровня и их производительность.
4.4 Уровень Collective
На уровне Collective сгруппированы протоколы и сервисы, которые не связаны с каким-либо конкретным ресурсом, являются более глобальными по природе и обеспечивают коллективное взаимодействие ресурсов. Примерами сервисов уровня Collective, служат:
- сервис директории, который позволяет участникам GRID исследовать имеющиеся ресурсы и их свойства [5]. Этот сервис использует протокол GRIP уровня Resource.
- сервисы распределения и планирование ресурсов, обработки заявок пользователей позволяют участникам GRID получать доступ к необходимым ресурсам, а также планировать выполнение задач на них. Примерами реализации таких сервисов могут служить AppLeS [13,14], Condor-G [15], Nimrod-G [16] и DRM брокер [17].
- сервисы мониторинга и диагностики, которые позволяют получать информацию о сбоях, попытках нарушить систему безопасности (вторжениях), перегрузки ресурсов и др.
- сервисы репликации данных, которые позволяют управлять хранением информации в GRID, оптимизировать расположение и количество копий данных по таким критериям, как время доступа, надежность, стоимость [18,19].
- сервис загрузки и совместных работ, также известный как “PSE” – Problem Solving Environment, который предоставляет средства для управления потоком задач.
- сервисы поиска программного обеспечения, которые позволяют исследовать и выбрать необходимое для решения проблемы программное обеспечение. Примерами могут служить NetSovle [20] и Nimf [21].
- сервисы авторизации, которые определяют правила использования ресурсов для пользователей GRID. Эти сервисы используют протоколы уровня Resource и протоколы уровня безопасности.
- сервисы регистрации и платежей, которые собирают информацию об использовании ресурсов пользователями.
- сервисы сотрудничества, которые обеспечивают синхронный и асинхронный скоординированный обмен информацией между большими сообществами пользователей. Примерами могут служить CAVERNsoft [22,23], Access GRID [3].
Системы GRID-программирования позволяют использовать уже известные программные модели в GRID-окружении. Они используют различные GRID-сервисы, такие как использование ресурсов, назначение ресурсов, и другие. Примерами могут служить GRID-реализации интерфейса передачи сообщений MPI [24,25] и MWF [26,27]
4.5 Уровень Application
Уровень Application включает в себя приложение пользователя, функционирующее в среде GRID (рисунок 3) [12] .
Рисунок 3 - Взаимодействие прикладной программы с различными
уровнями GRID-системы
Взаимодействие прикладной программы с сервисами различных уровней осуществляется через функции интерфейса прикладных программ этих сервисов.
5 Вопросы безопасности в GRID
Как известно, вопросы безопасности играют в информационных системах большую роль. Этим вопросам посвящено достаточно много литературы, например [36-40]. В том числе монографии [41]. Защита информации в GRID имеет свои особенности. В частности, необходимо обеспечить безопасность совместного использования ресурсов. Для обеспечения безопасности, в частности, необходимо предусмотреть существование механизма исключения анонимного несанкционированного доступа в вычислительную среду.
На каждом уровне архитектуры GRID решения обеспечения безопасности имеют свою специфику. При этом следует учитывать тот факт, что полная система безопасности GRID должна успешно взаимодействовать с уже существующими локальными решениями. Однако, разнородность локальных решений существенно затрудняет создание комплексных систем безопасности. Следует отметить, что одним из возможных путей устранения трудностей такого рода является использование единых стандартизованных подходов при реализации локальных решений обеспечения безопасности [28].
5.1. Стандартные протоколы обеспечения безопасности.
Существует множество стандартов обеспечения безопасности, но ни один из них не удовлетворяет требованиям систем безопасности GRID в полной мере. В этом подразделе рассмотрены основные из существующих стандартов и степень их соответствия требованиям, предъявляемым к GRID-системам.
5.1.1 Kerberos. Kerberos ([29]) – IETF стандарт, который поддерживает безопасность системы через установление подлинности, целостности и конфиденциальности сообщения, созданного при использовании метода разделяемой секретной криптографии.
Данный протокол может обеспечить однократную авторизацию и гибкую защиту сообщений. Однако, выполнение требования интеграции с локальными решениями проблемы безопасности для этого протокола затруднено, так как различные реализации Kerberos имеют тенденцию заменять локальные решения безопасности.
5.1.2 TLS. TLS (Transport Layer Security ) [30] (исходно известный как SSL) – IETF стандарт для установления подлинности, целостности и конфиденциальности сообщения, которое создано с использованием технологии криптографии с открытым ключом. Использование данного протокола затруднительно при реализации однократной авторизации и делегирования.
5.1.3 PKIX. PKIX ([31]) - набор IETF стандартов, которые описывают протоколы и синтаксис управления сертификатами X.509 в инфраструктурах систем безопасности, использующих технологию открытых ключей. Стандарты X.509 обычно используются в сочетании с другими стандартами безопасной связи, например, TLS.
5.1.4 CMS. CMS (Cryptografic Message syntax) [32] - стандарт IETF определяет синтаксис, который позволяет в цифровой форме подписать, подтвердить подлинность, или зашифровать произвольные сообщение.
5.1.5 GSS-API. GSS-API (Generic Security Service API) [33, 34] - стандарт IETF, который определяет интерфейс прикладных программ, обеспечивающий установление подлинности, целостности и конфиденциальности сообщения. Он предполагает, что две стороны, обменивающиеся сообщениями, имеют связь, основанную на протоколе, обеспечивающем надежность доставки информационных пакетов (например, TCP/IP). Данный стандарт может быть использован при реализации любого из основных механизмов безопасности и может быть рекомендован для применения в распределенной вычислительной среде.
Расширением стандарта является стандарт IDUP-GSS-API [35], который обеспечивает поддержку защиты независимых единиц данных.
5.2. Требования к системам безопасности в распределенной вычислительной среде.
Анализ мирового опыта разработок распределенных вычислительных систем показывает, что система безопасности GRID должна обладать следующими свойствами:
5.2.1 Возможность осуществления однократной регистрации пользователей.
Такая регистрация пользователей предполагает, что процедура идентификации проводится только в момент входа пользователя в систему. Все переходы данного пользователя между ресурсами распределенной вычислительной среды совершаются без повторной идентификации.
5.2.2 Возможность делегирования прав.
Делегирование прав заключается в том, что программа пользователя должна иметь доступ к ресурсам, на которых пользователь авторизован, а так же должна иметь возможность передать подмножество своих прав дочернему процессу.
5.2.3 Возможность интеграции с локальными системами безопасности.
Каждый ресурс может использовать любой из существующих способов решения проблемы безопасности системы. Реализация системы безопасности GRID должна взаимодействовать с этими локальными системами безопасности, не изменяя их.
5.2.4 Возможность реализации отношений доверия.
Отношения доверия предполагают, что, если пользователь авторизован на ресурсе А, и ресурс А взаимодействует с ресурсом Б, то данный пользователь должен считаться авторизованным и на ресурсе Б.
Отдельно следует рассматривать проблему защиты связи между различными ресурсами вычислительной среды. На этом уровне должны быть обеспечены:
- Гибкая защита сообщения. Предполагается, что прикладная программа (приложение) должна иметь возможность динамически конфигурировать протокол сервиса безопасности, чтобы использовать различные уровни защиты сообщения: либо определять только целостность сообщения, либо целостность и конфиденциальность. Выбор уровня защиты может мотивироваться различными факторами: типом передаваемых сообщений, требованиями сторон, участвующих в сеансе связи, инфраструктурой, по которой осуществляется передача сообщения.
- Поддержка различных протоколов связи, гарантирующих доставку информационных пакетов. В связи с развитием cети ИНТЕРНЕТ, в настоящее время широкое распространение получил протокол TCP, обеспечивающий гарантированную доставку информационных пакетов. Система безопасности GRID должна иметь возможность использования других протоколов, обладающими аналогичными свойствами.
6 Выводы
1 Проведенный анализ мирового опыта создания распределенных информационно- вычислительных сред (РИВС) и GRID-технологий позволил определить базовый набор сервисов для реализации GRID-технологий. Проведена классификация сервисов на основе имеющихся моделей, типа модели "песочных часов". Обращает на себя внимание то обстоятельство, что значительное количество ключевых слов из области РИВС и GRID-технологий, такие как "объединение разнородных систем", "межплатформенная переносимость приложений" "интерфейсы", "протоколы", "стандарты", относятся к области информационных технологий, называемой "Принципы и технология открытых систем". На основе приведенной классификации сервисов GRID, как объектов стандартизации, можно осуществить разработку модели РИВС как среды открытой системы.
2 Рассмотрены вопросы информационной безопасности в GRID, в том числе стандартные протоколы обеспечения безопасности и требования к системам безопасности в РИВС.
Автор выражает благодарность В.Н. Корниенко, и А.Я. Олейникову за помощь при написании статьи.
Список использованных источников
1 Johnston, W.E., Gannon, D. and Nitzberg, B., GRIDs as Production Computing Environments: The Engineering Aspects of NASA's Information Power GRID. In Proc. 8th IEEE Symposium on High Performance Distributed Computing, 1999, IEEE Press.
2 Chervenak, A., Foster, I., Kesselman, C., Salisbury, C. and Tuecke, S. The Data GRID: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Data Sets. J. Network and Computer Applications, 2001
3 Childers, L., Disz, T., Olson, R., Papka, M.E., Stevens, R. and Udeshi, T. Access GRID: Immersive Group-to-Group Collaborative Visualization. In Proc. 4th International Immersive Projection Technology Workshop, 2000.
4 Clarke, I., Sandberg, O., Wiley, B. and Hong, T.W., Freenet: A Distributed Anonymous Information Storage and Retrieval System. In ICSI Workshop on Design Issues in Anonymity and Unobservability, 1999
5 Czajkowski, K., Fitzgerald, S., Foster, I. and Kesselman, C. GRID Information Services for Distributed Resource Sharing, 2001.
6 Realizing the Information Future: The Internet and Beyond. National Academy Press, 1994. http://www.nap.edu/readingroom/books/rtif/.
7 Tierney, B., Johnston, W., Lee, J. and Hoo, G. Performance Analysis in High-Speed Wide Area IP over ATM Networks: Top-to-Bottom End-to-End Monitoring. IEEE Networking, 1996.
8 Beynon, M., Ferreira, R., Kurc, T., Sussman, A. and Saltz, J., DataCutter: Middleware for Filtering Very Large Scientific Datasets on Archival Storage Systems. In Proc. 8th Goddard Conference on Mass Storage Systems and Technologies/17th IEEE Symposium on Mass Storage Systems, 2000, 119-133.
9 Butler, R., Engert, D., Foster, I., Kesselman, C., Tuecke, S., Volmer, J. and Welch, V. Design and Deployment of a National-Scale Authentication Infrastructure. IEEE Computer, 33(12):60-66. 2000.
10 Foster, I., Kesselman, C., Tsudik, G. and Tuecke, S. A Security Architecture for Computational GRIDs. In ACM Conference on Computers and Security, 1998, 83-91.
11 Gasser, M. and McDermott, E., An Architecture for Practical Delegation in a Distributed System. In Proc. 1990 IEEE Symposium on Research in Security and Privacy, 1990, IEEE Press, 20-30.
12 Howell, J. and Kotz, D., End-to-End Authorization. In Proc. 2000 Symposium on Operating Systems Design and Implementation, 2000, USENIX Association. The Anatomy of the GRID 24
13 Berman, F. High-Performance Schedulers. In Foster, I. and Kesselman, C. eds. The GRID: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 1999, 279-309. The Anatomy of the GRID 22
14 Berman, F., Wolski, R., Figueira, S., Schopf, J. and Shao, G. Application-Level Scheduling on Distributed Heterogeneous Networks. In Proc. Supercomputing '96, 1996.
15 Frey, J., Foster, I., Livny, M., Tannenbaum, T. and Tuecke, S. Condor-G: A Computation Management Agent for Multi-Institutional GRIDs, University of Wisconsin Madison, 2001.
16 Abramson, D., Sosic, R., Giddy, J. and Hall, B. Nimrod: A Tool for Performing Parameterized Simulations Using Distributed Workstations. In Proc. 4th IEEE Symp. on High Performance Distributed Computing, 1995.
17 Beiriger, J., Johnson, W., Bivens, H., Humphreys, S. and Rhea, R., Constructing the ASCI GRID. In Proc. 9th IEEE Symposium on High Performance Distributed Computing, 2000, IEEE Press.
18 Allcock, B., Bester, J., Bresnahan, J., Chervenak, A.L., Foster, I., Kesselman, C., Meder, S., Nefedova, V., Quesnel, D. and Tuecke, S., Secure, Efficient Data Transport and Replica Management for High-Performance Data-Intensive Computing. In Mass Storage Conference, 2001
19 Hoschek, W., Jaen-Martinez, J., Samar, A., Stockinger, H. and Stockinger, K., Data Management in an International Data GRID Project. In Proc. 1st IEEE/ACM International Workshop on GRID Computing, 2000, Springer Verlag Press.
20 Casanova, H. and Dongarra, J. NetSolve: A Network Server for Solving Computational Science Problems. International Journal of Supercomputer Applications and High Performance Computing, 11(3):212-223. 1997.
21 Nakada, H., Sato, M. and Sekiguchi, S. Design and Implementations of Ninf: towards a Global Computing Infrastructure. Future Generation Computing Systems, 1999.
22 DeFanti, T. and Stevens, R. Teleimmersion. In Foster, I. and Kesselman, C. eds. The GRID: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 1999, 131-155. The Anatomy of the GRID 23
23 Leigh, J., Johnson, A. and DeFanti, T.A. CAVERN: A Distributed Architecture for Supporting Scalable Persistence and Interoperability in Collaborative Virtual Environments. Virtual Reality: Research, Development and Applications, 2(2):217-237. 1997.
24 Foster, I. and Karonis, N. A GRID-Enabled MPI: Message Passing in Heterogeneous Distributed Computing Systems. In Proc. SC'98, 1998.
25 Gabriel, E., Resch, M., Beisel, T. and Keller, R. Distributed Computing in a Heterogeneous Computing Environment. In Proc. EuroPVM/MPI'98, 1998.
26 Casanova, H., Obertelli, G., Berman, F. and Wolski, R., The AppLeS Parameter Sweep Template: User-Level Middleware for the GRID. In Proc. SC'2000, 2000.
27 Goux, J.-P., Kulkarni, S., Linderoth, J. and Yoder, M., An Enabling Framework for Master-Worker Applications on the Computational GRID. In Proc. 9th IEEE Symp. on High Performance Distributed Computing, 2000, IEEE Press.
28 I Foster,C Kesselman, S Tuecke, The Anatomy of the GRID; Enabling Scalable Virtual Organisations; 2001
29 Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)," RFC 1510, September 1993.
30 Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0," RFC 2246, January 1999.
31 Arsenault, A. and S. Turner, "Internet X.509 Public Key Infrastructure, PKIX Roadmap," Internet Draft, March 10 2000.
32 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999.
33 Linn, J., "Generic Security Service Application Program Interface, Version 2, Update 1," RFC 2743, January 2000.
34 Wray, J., "Generic Security Service API Version 2, C-bindings," RFC 2744, January 2000.
35 Adams, C., "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS_API," RFC 2479, December 1998.
36 Владимир Галатенко, Информационная безопасность - обзор основных положений Открытые Системы # 3 1996
37 Владимир Галатенко, Информационная безопасность, Открытые Системы # 4 1996
38 Илья Трифаленков, Система информационной безопасности на основе ОС Solaris, Открытые Системы # 3 1996
39 Н. Вьюкова, Hесанкционированный доступ - примеры вторжения, Открытые Системы # 1 1996
40 Беляев В.И. Безопасность в распределенных системах, Открытые Системы # 3 1995
41 Зегжда Д.П., А.М. Ивашко Основы информационной безопасности, Москва Горячая линия-Телеком 2000
 |
 |