Чайка

Сегодня:

       Чайка по имени Джонатан Ливингстон   

Посвящается истинному Джонатану -
Чайке, живущей в каждом из нас.

главная
реферат
библиотека
ссылки
отчет о поиске
инд.задание


Анатомия грид: создание масштабируемых виртуальных организаций

Я. Фостер, К. Кессельман, С. Тьюке

1 Введение
Термин "грид" стал использоваться с середины 90-х годов для обозначения некой инфраструктуры распределённого компьютинга, предлагаемой для обслуживания передовых научных и инженерных проектов. С тех пор были достигнуты значительные успехи в построении такой инфраструктуры, и толкование термина "грид", по крайней мере, в популярном восприятии существенно расширилось, и стало охватывать всё - от передовых сетевых решений до разработок в области искусственного интеллекта. Возникает сомнение, действительно ли этот термин имеет какое-то реальное содержание и смысл. Действительно ли имеет место отличная от других "грид-проблема", и поэтому нужны новые "грид-технологии"? Если это так, то в чём сущность этих технологий, и какова сфера их применимости? Несмотря на то, что многочисленные группы проявляют интерес к грид-концепциям и, в значительной степени, имеют общее видение грид-архитектуры, мы пока не достигли консенсуса в ответах на поставленные выше вопросы.
Цель нашей статьи показать, что идея грид действительно мотивируется реальной и конкретной проблемой, и что возникает вполне определённая грид-технологическая база, которая ориентирована на наиболее значимые аспекты этой проблемы. В ходе изложения мы представим детальную архитектуру и план развития современных и будущих грид-технологий. Более того, мы покажем, что несмотря на то, что грид-технологии в настоящее время отличаются от других основных технологических направлений таких, как интернет, корпоративный, распределённый и одноранговый компьютинг, эти другие технологии могут извлечь значительную выгоду от врастания в сферу проблем, разрешаемых с помощью грид-технологий.
Реальной и конкретной проблемой, подчёркивающей значимость грид-концепции, является согласованное разделение ресурсов и решение задач в динамичных, многопрофильных виртуальных организациях. Разделение, которое мы имеем в виду, это главным образом не обмен файлами, а скорее прямой доступ к компьютерам, программному обеспечению, данным и другим ресурсам так, как это востребовано рядом возникающих в промышленности, науке и технике стратегий совместного решения задач и посредничества в предоставлении ресурсов. Это разделение обязательно жестко контролируется провайдерами ресурсов и потребителями, ясно и чётко определяющими что разделяется, кому разрешено разделение и условия, на которых разделение выполняется. Объединение отдельных специалистов и/или институтов, определённое такими правилами разделения образует то, что мы называем виртуальной организацией (virtual organization) - ВО.
Приведём следующие примеры ВО:

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

•    участники многолетних, крупных международных объединений в области физики
высоких энергий.
Каждый из этих примеров иллюстрирует основанный на совместном использовании крупного пула вычислительных ресурсов и данных подход к организации вычислений и решению проблем.
Как показывают эти примеры, ВО чрезвычайно разнообразны по своей цели, масштабу, размеру, продолжительности существования, структуре, общественному и социологическому статусу. Тем не менее, внимательное изучение определяющих технологических требований приводит нас к выявлению некоего широкого набора общих для всех ВО интересов и потребностей. В частности, мы можем отметить, что для разделения необходимо обеспечить:

  1. чрезвычайно  гибкие  отношения  в  широком диапазоне  возможных  сетевых
    решений: от схемы "клиент - сервер" до схемы "одноранговая сеть";
  2. сложный и высокоуровневый контроль за тем, как используются разделяемые
    ресурсы, включая средства мелкоструктурного контроля доступа, делегирование и
    применение локальных и глобальных политик;
  3. возможности разделения разнообразных ресурсов: от программ, файлов и данных
    до компьютеров, датчиков и сетей;
  4. разнообразные по критериям производительности и стоимости пользовательские
    режимы       (от       однопользовательского       до       многопользовательского),
    предусматривающие  решение  проблем  обеспечения  качества  обслуживания,
    планирования, совместной загрузки и учёта использования ресурсов.

Современные технологии распределённого компьютинга не рассматривают перечисленных вопросов и требований. Например, современные интернет-технологии адресованы к проблемам коммуникации и информационного обмена между компьютерами, но при вычислениях не обеспечивают интегрированных подходов к согласованному использованию ресурсов, находящихся в разных сайтах. Системы бизнес-партнёрства, так называемые В2В, нацелены на разделение информации (часто через аппарат централизованных услуг). Подобным же образом действуют технологии виртуальных корпораций, хотя здесь разделение со временем может быть расширено до приложений и физических устройств. Технологии распределённого корпоративного компьютинга такие, как CORBA и Enterprise Java, обеспечивают разделение ресурсов внутри одной организации. Технология DCE поддерживает безопасное разделение ресурсов между сайтами, но большинство ВО считают эту технологию слишком тяжёлой и не гибкой. Провайдеры служб хранения (Storage Service Providers - SSP) и Провайдеры служб приложений (Application Service Providers - ASP) предоставляют организациям-клиентам доступ к внешним ресурсам памяти и вычислительным мощностям, но только ограниченными способами: например, ресурсы SSP обычно связаны с потребителем через частную виртуальную сеть (Virtual Private Network - VPN). Появляющиеся компании интернет-компьютинга проводят в международном масштабе поиск простаивающих компьютеров, но до настоящего времени поддерживают только жёстко централизованный доступ к таким ресурсам. Итак, современные технологии либо не охватывают все типы ресурсов, либо не обеспечивают необходимые для создания ВО гибкость и управляемость связями, возникающими при разделении ресурсов.

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

  1. решения по безопасности, которые поддерживают управление полномочиями
    (цифровыми мандатами) и политиками планирования при проведении расчётов на
    пространственно распределённых ресурсах нескольких организаций;
  2. протоколы управления ресурсами и службами, которые поддерживают безопасный
    удалённый доступ к вычислительным мощностям и ресурсам данных, а также
    коаллокацию (совместное распределение - co-allocation) множества ресурсов;
  3. протоколы информационных запросов и службы, предоставляющие информацию о
    конфигурации и статусе ресурсов, организаций и служб;
  4. службы    управления    данными,    которые    осуществляют    размещение    и
    транспортировку наборов данных между системами хранения и приложениями.

Будучи сфокусированы на динамическом, межкорпоративном разделении ресурсов, грид-технологии дополняют, а отнюдь не конкурируют с существующими технологиями распределённого компьютинга. Например, корпоративные системы распределённого компьютинга могут использовать грид-технологии для разделения ресурсов, находящихся вне пределов организации; в области применения систем ASP/SSP грид-технологии могут быть использованы при создании динамичных рынков ресурсов хранения и вычислительных мощностей и тем самым для преодоления ограничений, присущих современным статичным конфигурациям. Ниже мы более подробно обсудим связи грид с этими технологиями.
В последующем материале данной статьи мы расширим рассмотрения по каждой из этих позиций. Наши цели состоят в том, чтобы (1) внести ясность в понимание сути ВО и грид-компьютинга для тех, кто не знаком с этой областью информационных технологий; (2) способствовать становлению грид-компьютинга, как дисциплины, путём введения стандартной терминологии и определения общей архитектурной схемы; и (3) ясно указать, как грид-технологии соотносятся с другими технологиями, объяснив как то, почему существующие технологии до сих пор не решают проблемы грид-компьютинга, так и то, какую пользу они могут извлечь из грид-технологий.
Мы убеждены, что ВО обладает потенциалом, способным драматически изменить наши методы использования компьютеров при решении задач, во многом подобно тому, как Web изменил наши способы информационного обмена. Так, представленные здесь примеры наглядно иллюстрируют, что для многих разных дисциплин и сфер деятельности необходимость вовлечения в процессы сотрудничества является обстоятельством фундаментальным и не ограничивается наукой, технологиями и бизнесом. Вот почему для широкого применения концепций ВО важны грид-технологии.
2 Появление виртуальных организаций
Рассмотрим следующие четыре сценария:
1. Компания, которой необходимо получить обоснованное решение по вопросу размещения нового производства, запрашивает у некоего провайдера ASP сложную программу   финансового   прогнозирования,   обеспечивая   ей   при   этом   доступ   к соответствующим частным историческим сведениям, хранящимся в корпоративной базе данных, размещённой на системах хранения, управляемых неким провайдером SSP. В течение периода выработки решения, сценарии "что-если" проигрываются совместно и интерактивно, даже если руководящие отделения компании, участвующие в подготовке решения, находятся в разных местах. Провайдер ASP сам заключает с Провайдером квантов времени для вычислений (Cycle provider - CP) контракты на дополнительные прогоны, связанные с непредвиденными ситуациями, требуя, разумеется, чтобы эти кванты удовлетворяли соответствующим требованиям безопасности и производительности.
2.     Промышленный   консорциум,   образованный   для   выполнения   анализа осуществимости    сверхзвукового    самолёта    нового    поколения,    проводит    цикл высокоточного многоаспектного моделирования всего самолёта. При этом моделировании объединяются   в   единое   целое   частные   компоненты   программного   обеспечения, разработанные различными участниками, причём каждый из этих компонентов работает на компьютерах его владельца и имеет доступ к соответствующим базам данных проекта и другим данным, предоставленным консорциуму его участниками.
3.   Команда кризисного менеджмента реагирует на чрезвычайную ситуацию, возникшую в результате выброса вредных химических веществ, используя модели локальной погоды и почвы, оценивает распространённость загрязнения, определяет воздействие, оказываемое на местное население, а также и на такие географические объекты, как реки и водохранилища, создаёт (возможно, основанный на моделях химических   реакций)   краткосрочный   план   смягчения   ситуации,   планирует   и координирует процессы эвакуации,  госпитализации и  пр.,  руководит персоналом, ликвидирующим последствия аварии.
4. Тысячи физиков из сотен лабораторий и университетов всего мира объединились с целью проектирования и создания большого детектора в Европейском центре физики высоких энергий (European high energy physics laboratory - CERN), проведения на нём экспериментов и анализа получаемых данных. При обработке данных экспериментов участники этой программы объединяют в общий фонд компьютерные, накопительные и сетевые ресурсы для создания, так называемой среды " Data Grid", способной обеспечить анализ петабайтных объёмов данных. Эти четыре примера различаются во многих отношениях: по числу и профессиям участников, видам деятельности, продолжительности и масштабу взаимодействия и по разделяемым ими ресурсам.
В каждом примере - непредсказуемое число участников, в той или иной степени ранее связанных друг с другом (а, возможно, и вовсе не связанных), хотят разделять ресурсы для выполнения некоторой задачи. Более того, в данном случае разделение подразумевает нечто большее, чем простой обмен документами: оно может быть связано с прямым доступом к удалённым компьютерам, данным, программному обеспечению, датчикам и другим ресурсам. Например, члены консорциума могут обеспечить доступ к специальному программному обеспечению, данным и/или к пулу их вычислительных ресурсов.
Разделение ресурсов обусловлено: каждый владелец ресурсов устанавливает доступность ресурсов, задаёт ограничения, определяющие когда, где и что может быть сделано. Например, участник ВО от P (см. Рисунок 1) мог бы позволить партнёрам запускать их службы моделирования только для "простых" задач. Потребители ресурсов, в свою очередь, могли бы указывать ограничения на свойства ресурсов, к работе с которыми они подготовлены. Например, участник ВО от Q мог бы соглашаться только на объединённые вычислительные ресурсы, сертифицированные как "безопасные". Осуществление таких ограничений требует наличия специальных механизмов для задания политик управления, аутентификации (установления идентичности - authentication) потребителя или ресурса, и авторизации (предоставления права - authorization) выполнения операции в соответствии с установленными отношениями разделения.
Отношения разделения могут со временем динамично изменяться в зависимости от условий применения выделяемых ресурсов, характера разрешённого доступа и состава участников, которым разрешён доступ. И эти отношения вовсе необязательно связаны с необходимостью явного поимённого указания участников, а вполне могут быть неявно определены через политики управления доступом к ресурсам. Например, организация может обеспечить доступ любому, кто докажет, что он "заказчик" или "студент".
Динамичный характер отношений разделения означает, что нам нужны механизмы обнаруживающие и характеризующие сущность связей, которые существуют в данный момент времени. Например, новый участник, вступающий в ВО Q, должен быть в состоянии определить, к каким ресурсам может быть получен доступ, "качество" этих ресурсов и политики управления доступом.
Отношения разделения часто представляются не просто схемой "клиент-сервер", а достаточно развитой одноранговой структурой типа "точка - точка", где провайдеры могут оказаться потребителями, а отношения разделения могут существовать между любым подмножеством участников. Отношения разделения могут объединяться для согласованного использования на многих ресурсах, каждый из которых принадлежит одной из организаций. Например, расчёты, начатые в ВО Q на одном пуле вычислительных ресурсов, могут позже получить доступ к данным или запустить решение подзадач где-либо ещё. В таких ситуациях важной становиться способность контролируемыми способами делегировать полномочия, это же касается механизмов согласования операций (так называемого, совместного планирования - cosheduling) на всём множестве ресурсов.
В зависимости от ограничений, наложенных на разделение, и цели его применения один и тот же ресурс может быть использован разными способами. Например, при одной системе отношений компьютер может быть использован только для прогона определённого блока программного обеспечения, в то время как при другой - его временные кванты могут разделяться для любого счёта. Вследствие отсутствия априорных знаний о том, как некий ресурс может быть использован, показатели производительности, вероятностные характеристики и ограничения (то есть качество обслуживания) могут быть составной частью условий, накладываемых на разделение или использование ресурса.
Эти характеристики и требования определяют то, что мы называем виртуальной организацией, концепцию, которая по нашему убеждению становится фундаментальной для многих современных процессов вычислений и обработки данных. ВО позволяют в корне отличным группам организаций и/или отдельным пользователям контролируемо разделять ресурсы, так чтобы они могли сотрудничать при достижении некой общей цели.
3 Сущность грид-архитектуры
Создание, управление и использование динамичных, межведомственных ВО, разделяющих ресурсы, требует новой технологии. Мы структурируем наше обсуждение этой технологии в терминах грид-архитектуры, которая устанавливает фундаментальные системные компоненты, определяет цели и функции этих компонент и показывает, как эти компоненты взаимодействуют друг с другом.
Определение грид-архитектуры мы начнём с предпосылки, что для обеспечения эффективной деятельности ВО необходимо иметь возможность устанавливать отношения разделения между любыми потенциальными участниками. Таким образом, центральной проблемой, требующей разрешения, оказывается интероперабельность (взаимодействие различных программных и аппаратных средств - interoperability). В контексте рассмотрения сетевых технологий интероперабельность означает общность протоколов. Поэтому наша грид-архитектура, во-первых, прежде всего, является архитектурой протоколов, определяющих базовые механизмы, посредством которых пользователи и ресурсы ВО договариваются, устанавливают, управляют и используют отношения разделения. Основанная на стандартах открытая архитектура способствует расширяемости, интероперабельности, мобильности и совместному использованию общих программ; стандартные протоколы облегчают определение стандартных служб, которые обеспечивают усовершенствование возможностей. Для поддержки программирования абстрактных конструкций, необходимых при создании удобного в использовании грид, мы можем также разработать, так называемые Интерфейсы Прикладного Программирования (Application Programming Interfaces - API) и Инструментарий Разработки Программного обеспечения (Software Development Kits - SDK), определения которых приведены в Приложении. Вместе, эта технология и архитектура составляют то, что часто называется как промежуточное программное обеспечение (службы, необходимые для поддержки общего набора приложений в распределённой сетевой среде - "middleware"), хотя мы избегаем использования этого термина здесь из-за его неопределённости. В последующем мы обсудим каждое из высказанных сейчас соображений.
Почему интероперабельность является столь фундаментальной системной возможностью? Дело состоит в том, что мы должны гарантировать формирование отношений разделения между произвольными группами, вступление новых участников динамично и через различные платформы, языки и программные среды. В таком контексте механизмы приносят мало пользы, если они не определены и не реализованы так, чтобы их интероперабельность не лимитировалась границами организаций, политиками управления и типами ресурсов. Без интероперабельности ВО приложения и участники вынуждены устанавливать двусторонние договорённости о разделении, поскольку нет гарантии, что механизмы, используемые между любыми двумя группами могут быть расширены для любых других групп. Без такой гарантии динамичное создание ВО вовсе невозможно, а количество типов ВО, которые могут быть сформированы, строго ограничено. Точно также как Web революционизировала разделение информации, предоставив для целей информационного обмена универсальный протокол и синтаксис (HTTP и HTML), нам необходимы стандартные протоколы для повсеместного разделения ресурсов.
Почему протоколы крайне необходимы для интероперабельности? Определение протокола устанавливает, как для реализации заданной дисциплины работы элементы одной распределённой системы взаимодействуют с элементами другой, и структуру информации, передаваемой во время этого взаимодействия. Такая нацеленность на внешние факторы (на взаимодействия), а не на внутренние (на программное обеспечение, характеристики ресурсов) имеет важные прагматические достоинства. ВО имеют тенденцию к постоянному изменению, поэтому механизмы, используемые для обнаружения ресурсов, установления идентичности, определения права доступа и инициализации разделения должны быть гибкими и лёгкими настолько, чтобы договорённости о разделении ресурсов можно было бы быстро устанавливать и изменять. Поскольку ВО дополняют, а не заменяют существующие организации, механизмы разделения не могут требовать существенных изменений в локальных политиках управления и должны позволять отдельным институтам поддерживать предельно жёсткий контроль их собственных ресурсов. Поскольку протоколы определяют взаимодействия между компонентами, а не их реализацию, локальное управление сохраняется.
Почему важны службы? Служба (см. Приложение) определяется исключительно протоколом, посредством которого она общается, и дисциплиной, которую она реализует. Определение стандартных служб - для доступа к вычислительным ресурсам, доступа к данным, обнаружения ресурсов, совместного планирования, репликации данных и так далее - позволяет нам усовершенствовать службы, предлагаемые участникам ВО, а также абстрагироваться от специфических деталей ресурсов, которые помешали бы разработке ВО приложений.
Почему мы также обсуждаем здесь возможности API и SDK? Конечно, есть нечто более значимое для ВО чем интероперабельность, протоколы и службы. Разработчики должны иметь возможность создавать изощрённые приложения в сложной и динамичной исполнительной среде. Пользователи должны иметь возможность работать с этими приложениями. Работоспособность приложений, их исправность, стоимость разработки и сопровождения - всё это чрезвычайно важные факторы. Стандартные абстракции, API's и SDK's помогают ускорить разработку программ приложений, обеспечивают совместное использование общих программ и улучшают переносимость приложений. API's и SDK's являются дополнением, а не альтернативой протоколам. Без стандартных протоколов интероперабельность может быть достигнута на уровне API только путём использования всюду единой реализации приложения, что невыполнимо во многих заинтересованных ВО, или на основе знания каждой реализацией деталей каждой другой реализации. (Метод Jini, предлагает загрузку процедуры протокола на удалённый сайт, что не позволяет обойти это требование).
Итак, кратко, в нашем рассмотрении грид-архитектуры особое значение придаётся, во-первых, идентификации и определению протоколов и служб и, во-вторых, API's и SDK's.

[первоисточник]